From pce-bounces@lists.ietf.org Fri Jul 01 12:55:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoOnX-00072U-Lr; Fri, 01 Jul 2005 12:55:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoOnW-00072M-6H for pce@megatron.ietf.org; Fri, 01 Jul 2005 12:55:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14848 for ; Fri, 1 Jul 2005 12:55:22 -0400 (EDT) Received: from relay1.mail.uk.clara.net ([80.168.70.141]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoPDV-0005CY-6G for pce@ietf.org; Fri, 01 Jul 2005 13:22:18 -0400 Received: from du-069-0090.access.clara.net ([217.158.132.90] helo=Puppy) by relay1.mail.uk.clara.net with smtp (Exim 4.46) id 1DoOnP-0002gb-Gn; Fri, 01 Jul 2005 17:55:20 +0100 Message-ID: <01d601c57e5d$ff058fa0$db849ed9@Puppy> From: "Adrian Farrel" To: "Zhang Renhai" , References: <002501c57082$04f8c9c0$69646e0a@huawei.com> Subject: Re: [Pce] Please comment draft-zhang-pce-comm-app-model-00 Date: Fri, 1 Jul 2005 17:57:37 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 2.9 (++) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: 7bit Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi, Thanks for your draft. I think it is important to contrast the situation where all paths are computed by a central entity, and the case where there are multiple points within the network that could compute a path. The former case is seen in traditional transport networks where a central planning office is responsible for determining paths. It also applies, as you state, where a single PCE is responsible for a whole domain. The latter case occurs, as you say, when there is more than one PCE in a domain. We should note very clearly that this second case arises in pre-PCE MPLS-TE or GMPLS networks where the ingress LSR is often given the responsibility of computing the path of the LSP it is requested to establish. The case you are making is one for universal knowledge, and the you need to make it clear that the trade-off is between the resource contention that you describe, and the problems associated with distributing and collecting a full knowledge set. You should also contrast your requirements with the "stateful" PCE described in the PCE Architecture draft. It is important to observe that the PCE computes paths but does not cause them to be established. A path computation might result in an LSP that fails for some reason (perhaps a new fault in the network), or might never be used to set up an LSP (it might be a path computed for information, or to be kept in readiness for rapid restoration signaling). Thus, knowledge of path computations is not the same as knowledge of current or planned resource status. Note also that not all paths are computed by a PCE. Some may be computed by an LSR, and some may be supplied by an operator or application. I would like your draft to focus more on the problem. What is the likelihood of contention, and what is the consequence. How significant is the consequence? Then you can discuss the tradeoff. Race conditions are annoying, but not significantly harmful. Avoiding race conditions requires centralization of function, or centralization of information. Thanks, Adrian ----- Original Message ----- From: "Zhang Renhai" To: Sent: Tuesday, June 14, 2005 2:40 AM Subject: [Pce] Please comment draft-zhang-pce-comm-app-model-00 > Dear WG, > > A new ID has just been finished and posted > (http://www.ietf.org/internet-drafts/draft-zhang-pce-comm-app-model-00.txt ), > which proposed a application model. Thinking of the satuation where the > network resources are reserved and released frequently, for instance, VoIP > environment,this draft give a mechanisms on this respect, mostly on resolving > race conditions and on computation load balancing. > It's 10 pages long. Comments are very welcome. > > Thanks and Regards. > > Rh Zhang > > -------------------------------------------------------------------------- ------ > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue Jul 05 02:37:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dph44-0001ZM-Br; Tue, 05 Jul 2005 02:37:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dph3o-0001SV-NC for pce@megatron.ietf.org; Tue, 05 Jul 2005 02:37:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26285 for ; Tue, 5 Jul 2005 02:37:32 -0400 (EDT) Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DphUU-0006I2-GC for pce@ietf.org; Tue, 05 Jul 2005 03:05:11 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Tue, 5 Jul 2005 08:37:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE : [Pce] Adoption of draft-leroux-pce-discovery-reqs-01.txt as WG document ? Date: Tue, 5 Jul 2005 08:37:19 +0200 Message-ID: Thread-Topic: [Pce] Adoption of draft-leroux-pce-discovery-reqs-01.txt as WG document ? Thread-Index: AcV9iR1CYrTyShTARFiUpXGIXCycpwDKjHeA From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "Gray, Eric" , "JP Vasseur" X-OriginalArrivalTime: 05 Jul 2005 06:37:20.0816 (UTC) FILETIME=[FECA1300:01C5812B] X-Spam-Score: 0.4 (/) X-Scan-Signature: d094b18a574860cb9e2fe5fedfbcc179 Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0478106307==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0478106307== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5812B.FE9C5088" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5812B.FE9C5088 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Eric =20 We have a security section that is IMHO quite clear in terms of = masquerade, forgery... and indirectly addresses trust models you refer to. But I agree with you that security requirements of a PCE discovery = solution would better be addressed in a dedicated section "PCE Discovery security = requirements" rather than in the default security section. What about the following: =20 "5.9 PCE Discovery Security Requirements =20 The PCE Discovery mechanism MUST address security issues across multiple = ASes. Key consideration MUST be given in terms of how to establish a trusted = model for PCE discovery. The PCE discovery mechanism MUST explicitly support a specific set of = trust models. =20 Particularly, mechanisms MUST be defined to avoid PCE masquerade and = forgery. It MUST be possible for PCEs to authenticate PCCs and for PCCs to = authenticate PCEs. =20 Also, the PCE discovery mechanism MUST be able to restrict the scope of=20 discovery to a set of authorized PCCs. The identity of any PCE MUST only = be learnt by authorized PCCs.=20 It MUST be possible to encrypt discovery information." =20 Note that this requirement also implies the PCC-PCE communication = protocol. =20 Is it fine with you if we add this section for next revision? =20 Best Regards =20 JL =20 =20 =20 =20 -----Message d'origine----- De : pce-bounces@lists.ietf.org [mailto:pce-bounces@lists.ietf.org] De = la part de Gray, Eric Envoy=E9 : jeudi 30 juin 2005 17:27 =C0 : 'JP Vasseur' Cc : pce@ietf.org Objet : RE: [Pce] Adoption of draft-leroux-pce-discovery-reqs-01.txt as = WG document ? JP, =20 I believe this draft needs more work - particularly in the area of = establishing "security requirements" (as opposed to simple inclusion of a security = section) - before it is ready to be adopted as a WG document. [JLLR] =20 =20 Implicit in the PCE concept is the inherently undefined nature of = the trust model that may apply in any given deployment. Consequently it MUST be a requirement that any PCE discovery mechanism explicitly supports a = specific set of trust models and that the complete set of possible solutions = (assuming the _possibility_ that one solution may not satisfy all requirements) = supports every reasonable combination of security trust models. =20 It is imperative that this is established as a "requirement" of PCE = discovery solutions because this requirement will have a very definite effect on = choices the WG might make right away in seeking a solution. =20 For example, assuming that we need to support a model where we = assume that it is possible for a foreign agency to mimic a valid PCE, this = assumption=20 will severely limit the approaches that might be used - as long as it is = also a requirement to avoid approaches that require extensive manual = configuration. =20 To further illustrate this example, this requirement would make a = choice of discovery based on broadcast/multicast announcement mechanisms much less workable - possibly directing us more toward an authenticated = directory service approach. =20 To accept this document as a WG document without first nailing down = the specific security requirements that we want to apply would potentially = send=20 the wrong message to the authors, the WG, the Internet community and -=20 possibly - the IESG. =20 It is far more important to ensure that the work has started in the = right direction than it is to drive the work to conform more closely to a time = table. =20 -- Eric -----Original Message----- From: pce-bounces@lists.ietf.org [mailto:pce-bounces@lists.ietf.org]On = Behalf Of JP Vasseur Sent: Thursday, June 30, 2005 9:53 AM To: pce@ietf.org Subject: [Pce] Adoption of draft-leroux-pce-discovery-reqs-01.txt as WG = document ? Dear WG, draft-leroux-discovery-reqs has just been re-published, addressing = several of comments received during the last meeting and on the list = (very few remaining open items). Could you provide us your feed-back on adopting = draft-leroux-discovery-reqs-01.txt as a WG document ? JP and Adrian. ------_=_NextPart_001_01C5812B.FE9C5088 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
Hi=20 Eric
 
We=20 have a security section that is IMHO quite clear in terms of masquerade, = forgery...
and=20 indirectly addresses trust models you refer to.
But I=20 agree with you that security requirements of a PCE discovery=20 solution would better
be=20 addressed in a dedicated section "PCE Discovery security=20 requirements"  rather than in the default security=20 section.
What=20 about the following:
 
"5.9=20 PCE Discovery Security Requirements
 
The PCE Discovery mechanism MUST address security = issues across=20 multiple ASes.
Key=20 consideration MUST be given in terms of how to establish a trusted model = for PCE=20 discovery.
The PCE discovery mechanism MUST explicitly support a = specific set of trust=20 models.
 
Particularly, mechanisms MUST be defined to avoid PCE = masquerade and=20 forgery.
It MUST be possible for = PCEs to=20 authenticate PCCs and for PCCs to authenticate=20 PCEs.
 
Also, = the PCE discovery mechanism MUST be able to = restrict the=20 scope of 
discovery to a set of authorized PCCs. The identity of = any PCE=20 MUST only be learnt by authorized PCCs.=20
It MUST be = possible to=20 encrypt  discovery information." =20
Note=20 that this requirement also implies the PCC-PCE communication=20 protocol.
 
Is it=20 fine with you if we add this section for next = revision?
 
Best=20 Regards
 
JL
 
 
 
 
-----Message d'origine-----
De :=20 pce-bounces@lists.ietf.org [mailto:pce-bounces@lists.ietf.org] De = la part=20 de Gray, Eric
Envoy=E9 : jeudi 30 juin 2005=20 17:27
=C0 : 'JP Vasseur'
Cc :=20 pce@ietf.org
Objet : RE: [Pce] Adoption of=20 draft-leroux-pce-discovery-reqs-01.txt as WG document = ?

JP,
 
    I believe this draft needs more work - = particularly in=20 the area of establishing
"security requirements" (as opposed to simple inclusion of a = security=20 section)
- before it is ready to be adopted as a WG document.
[JLLR]  =
 
    Implicit in the PCE concept is the inherently = undefined=20 nature of the trust
model that may apply in any given deployment. Consequently it = MUST be=20 a
requirement that any PCE discovery mechanism explicitly = supports a=20 specific
set=20 of trust models and that the complete set of possible solutions=20 (assuming
the=20 _possibility_ that one solution may not satisfy all requirements)=20 supports
every reasonable combination of security trust=20 models.
 
    It is imperative that this is established as = a=20 "requirement" of PCE discovery
solutions because this requirement will have a very definite = effect on=20 choices
the=20 WG might make right away in seeking a = solution.
 
    For example, assuming that we need to support = a model=20 where we assume
that=20 it is possible for a foreign agency to mimic a valid PCE, this = assumption=20
will=20 severely limit the approaches that might be used - as long as it is = also=20 a
requirement to avoid approaches that require = extensive manual=20 configuration.
 
    To further illustrate this example, this = requirement=20 would make a choice of
discovery based on broadcast/multicast announcement = mechanisms=20 much
less=20 workable - possibly directing us more toward an authenticated=20 directory
service approach.
 
    To accept this document as a WG document = without first=20 nailing down the
specific security requirements that we want to apply would = potentially=20 send
the=20 wrong message to the authors, the WG, the Internet community and = -=20
possibly - the IESG.
 
    It is far more important to ensure that the = work has=20 started in the right
direction than it is to drive the work to conform more = closely to a=20 time table.
 
--
Eric
-----Original Message-----
From: = pce-bounces@lists.ietf.org=20 [mailto:pce-bounces@lists.ietf.org]On Behalf Of JP=20 Vasseur
Sent: Thursday, June 30, 2005 9:53 = AM
To:=20 pce@ietf.org
Subject: [Pce] Adoption of=20 draft-leroux-pce-discovery-reqs-01.txt as WG document = ?

Dear WG,

draft-leroux-discovery-reqs has = just been=20 re-published, addressing several of comments received during the = last=20 meeting and on the list (very few remaining open items).

Could you provide us your = feed-back on=20 adopting draft-leroux-discovery-reqs-01.txt as a WG document ?

JP and=20 Adrian.

------_=_NextPart_001_01C5812B.FE9C5088-- --===============0478106307== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============0478106307==-- From pce-bounces@lists.ietf.org Tue Jul 05 03:12:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DphbJ-0002N0-7c; Tue, 05 Jul 2005 03:12:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DphbG-0002Mp-MK for pce@megatron.ietf.org; Tue, 05 Jul 2005 03:12:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04114 for ; Tue, 5 Jul 2005 03:12:09 -0400 (EDT) Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dpi1w-0000eo-Ie for pce@ietf.org; Tue, 05 Jul 2005 03:39:45 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Tue, 5 Jul 2005 09:12:04 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE : [Pce] PCE Disco Reqs v01 Date: Tue, 5 Jul 2005 09:12:02 +0200 Message-ID: Thread-Topic: [Pce] PCE Disco Reqs v01 Thread-Index: AcV/Egq9PEOhG5EfTC2SIKwp2ASO6wCGgosw From: "LE ROUX Jean-Louis RD-CORE-LAN" To: X-OriginalArrivalTime: 05 Jul 2005 07:12:04.0120 (UTC) FILETIME=[D8890980:01C58130] X-Spam-Score: 1.1 (+) X-Scan-Signature: 231d7929942febf3be8fd5be2903302f Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2027313143==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============2027313143== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C58130.D85149DD" This is a multi-part message in MIME format. ------_=_NextPart_001_01C58130.D85149DD Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Dimitri =20 Thanks for these valuable comments =20 Please see inline -----Message d'origine----- De : Dimitri.Papadimitriou@alcatel.be = [mailto:Dimitri.Papadimitriou@alcatel.be]=20 Envoy=E9 : samedi 2 juillet 2005 16:26 =C0 : LE ROUX Jean-Louis RD-CORE-LAN Cc : pce@ietf.org Objet : Re: [Pce] PCE Disco Reqs v01 hi jean-louis thanks for the update, i have the following comments/feedback 1. in the introduction you refer to "some relevant PCE" and it is = important to be more accurate since this plays a specific role in the = discovery context of this document [JLLR] Yes, it means PCE for inter-domain path computation, we will = clarify in next revision=20 2. in the same section the document mentions MPLS-TE and GMPLS capable = PCEs, i wonder whether you not simply mean here path computed such as to = be subsequently used by RSVP-TE and GMPLS RSVP-TE taking into accound = specific set of constraints that can be used by such PCEs;=20 [JLLR] Yes, I think that this is clear for everyone isn't it? also i think there is an inclusion relationship that should be pointed = out here as the latter (a GMPLS-capable PCE) is by definition an MPLS- = capable PCE [JLLR] Agree=20 3. section 5.1.2 it is unclear from this section whether the proposed = discovery mechanism still allows for having multiple PCEs scoping a set = of overlapping domains;=20 [JLLR] The answer is yes,=20 [JLLR] But actually this is a question more related to the PCE = architecture itself. It depends on what you mean by overlapping. In the = inter-area context for instance there is some overlapping between = domains as ABRs belong to two or more domains. and in particular when X PCEs scope a single domain how it is possible = to target a given PCE if there scope in terms of reachable prefixes is = non-overlapping =20 [JLLR] You raise a good point, we should add discovery of domain(s) = towards which a PCE can compute a path For instance in the example of section 4, R9 is a composite PCE that can = take part in inter-AS path=20 computation, responsible for path computation in AS1 towards AS2. PCCs = has to dynamically discover R9 as a PCE for inter-AS path computation as = well as its path computation domain: AS1, and the domain towards which = it can compute paths: AS2=20 This will be added in next revision. 4. section 5.1.3 refers to the capability to handle "request = prioritization" but it is unclear to which priority you are referring is = this a specific and explicit information element as part of the request = itself ?=20 [JLLR] Yes it is Note that actually capability description is out of the scope of this = document, and should be addressed in a separate doc or an implicit prioritization mechanism based on the requestor = identity, the type of request it initiates, etc =20 5. section 4 refers to the PCE liveness detection, there are two issues = here where this 60s come from - why is there a need for emitting such = liveness information every 60s ? [JLLR] I agree that the requirement has to be reformulated. Actually = what we want is a way to discover that a PCE is no longer alive under = 60s, and this does not necessarily require emitting such information = every 60s, this could be event driven by the way. beside the overhead such mechanism would generate it is rather unclear = why a discovery mechanism has to ensure such keep-alive mechanism even = for PCCs that do not make any use of the PCE(s) issuing this information 6. section 5.8 is simply outside of the scope of the present document, = PCE selection is decoupled from their discovery [JLLR] OK, this will be removed By the way do you have any feedback on section 5.5? Again thanks for these useful comments Best Regards JL=20 thanks, - dimitri. "LE ROUX Jean-Louis RD-CORE-LAN" Sent by: pce-bounces@lists.ietf.org 06/29/2005 14:00 ZE2 To: cc:=20 bcc:=20 Subject: [Pce] PCE Disco Reqs v01 Hi all,=20 Version 01 of the PCE discovery reqs ID has just been published=20 http://www.ietf.org/internet-drafts/draft-leroux-pce-discovery-reqs-01.tx= t=20 This version takes into account comments received during Minneapolis = session and on the list.=20 Here are the major changes since 00:=20 -Added multi-area network case in the problem statement=20 -Added application scenario (section 4)=20 -Section 5.1 on capability discovery modified as per discussions on the = list:=20 -Discovery of PCE location, PCE scopes and domain(s) under = control is mandatory=20 -Capability discovery is no longer a MUST=20 The list of capabilities is now out of the scope and should be = addressed in a=20 separate document.=20 =20 -Added section 5.6 on extensibility=20 -Added Security section=20 Section 5.5 (Discovery of PCE capacity and congestion) requires WG = feedback:=20 -Is there a need for the discovery of PCE capacity in terms of = computation power? This static parameter could be used to ensure = weighted load balancing of requests in case PCEs do not have the same = capacity.=20 -Would it be useful that a PCE report its status as "congested" in case = it is too busy? PCCs may then use this dynamic information to prefer a = different PCE.=20 Your comments/feedback would be highly welcome, especially on the above = point=20 Best Regards,=20 JL=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce ------_=_NextPart_001_01C58130.D85149DD Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
Hi=20 Dimitri
 
Thanks=20 for these valuable comments
 
Please=20 see inline
-----Message d'origine-----
De :=20 Dimitri.Papadimitriou@alcatel.be = [mailto:Dimitri.Papadimitriou@alcatel.be]=20
Envoy=E9 : samedi 2 juillet 2005 = 16:26
=C0 : LE=20 ROUX Jean-Louis RD-CORE-LAN
Cc :=20 pce@ietf.org
Objet : Re: [Pce] PCE Disco Reqs=20 v01

hi jean-louis

thanks for the update, i have the = following=20 comments/feedback

1. in the introduction you refer to = "some=20 relevant PCE" and it is important to be more accurate since this plays = a=20 specific role in the discovery context of this = document
[JLLR] =20 Yes, it means PCE for inter-domain path computation, we will clarify = in next=20 revision 

2. in the same section the document = mentions=20 MPLS-TE and GMPLS capable PCEs, i wonder whether you not simply mean = here path=20 computed such as to be subsequently used by RSVP-TE and GMPLS RSVP-TE = taking=20 into accound specific set of constraints that can be used by such = PCEs;=20
[JLLR] Yes, I think that this is clear for everyone = isn't=20 it?

 also i think there is an = inclusion=20 relationship that should be pointed out here as the latter (a = GMPLS-capable=20 PCE) is by definition an MPLS- capable = PCE
[JLLR] Agree 

3. section 5.1.2 it is unclear from = this=20 section whether the proposed discovery mechanism still allows for = having=20 multiple PCEs scoping a set of overlapping domains;
[JLLR] The=20 answer is yes, 
[JLLR] But actually this is = a question=20 more related to the PCE architecture itself. It depends on what you = mean by=20 overlapping. In the inter-area context for = instance there=20 is some overlapping between domains as ABRs belong to two or=20 more domains.

 and in particular when X PCEs = scope a=20 single domain how it is possible to target a given PCE if there scope = in terms=20 of reachable prefixes is non-overlapping
 
[JLLR] You raise a good = point, we=20 should add discovery of domain(s) towards which a PCE can compute = a=20 path

For instance in the example of section 4, R9 is a composite PCE that can take part in = inter-AS=20 path 
computation, responsible for path computation in AS1 = towards=20 AS2. PCCs has to dynamically discover R9 as a PCE for = inter-AS path=20 computation as well as its path computation domain: AS1, = and the=20 domain towards which it can compute paths:=20 AS2 

This=20 will be added in next revision.

4. section 5.1.3 refers to the = capability to=20 handle "request prioritization" but it is unclear to which priority = you are=20 referring is this a specific and explicit information element as part = of the=20 request itself ?
[JLLR] Yes it = is

Note that actually = capability=20 description is out of the scope of this document, and should be = addressed in a=20 separate doc

 or=20 an implicit prioritization mechanism based on the requestor identity, = the type=20 of request it initiates, etc
 

5. section 4 refers to the PCE = liveness=20 detection, there are two issues here where this 60s come from - why is = there a=20 need for emitting such liveness information every 60s ?
[JLLR] I=20 agree that the requirement has to be reformulated. Actually what we = want is a=20 way to discover that a PCE is no longer alive under 60s, and this = does=20 not necessarily require emitting such information every 60s, this = could be=20 event driven by the way.

 =20 beside the overhead such mechanism would generate it is rather unclear = why a=20 discovery mechanism has to ensure such keep-alive mechanism even for = PCCs that=20 do not make any use of the PCE(s) issuing this information

6. section 5.8 is simply outside of = the scope=20 of the present document, PCE selection is decoupled from their=20 discovery
[JLLR] OK, this will be=20 removed

By=20 the way do you have any feedback on section = 5.5?

Again=20 thanks for these useful comments

Best=20 Regards

JL 

thanks,

- dimitri.

"LE=20 ROUX Jean-Louis RD-CORE-LAN"=20 <jeanlouis.leroux@francetelecom.com>
Sent by:=20 pce-bounces@lists.ietf.org
06/29/2005 14:00=20 ZE2

To: <pce@ietf.org>
cc: =
bcc:
Subject: [Pce] PCE=20 Disco Reqs v01


Hi all,

Version 01 of the PCE = discovery reqs ID=20 has just been published
http://www.ietf.org/internet-drafts/draft-leroux-pce-discovery= -reqs-01.txt

This version takes into account = comments=20 received during Minneapolis session and on the list.=20

Here are the major changes since 00:=20
-Added multi-area network case in the problem = statement
-Added application scenario (section 4) =
-Section 5.1 on=20 capability discovery modified as per discussions on the list:=20
       =20 -Discovery of PCE location, PCE scopes and domain(s) under = control is=20 mandatory
        -Capability = discovery=20 is no longer a MUST=20
       The list of = capabilities is=20 now out of the scope and should be addressed in a=20
       separate document.=20
      
-Added section 5.6 = on=20 extensibility
-Added Security section =

Section=20 5.5 (Discovery of PCE capacity and congestion) requires WG = feedback:
-Is there a need for the = discovery of=20 PCE capacity in terms of computation power? This static parameter = could be=20 used to ensure weighted load balancing of requests in case PCEs do not = have=20 the same capacity.

-Would it be useful that a PCE report its = status as=20 "congested" in case it is too busy? PCCs may then use this dynamic = information=20 to prefer a different PCE.

Your comments/feedback would be = highly=20 welcome, especially on the above point =

Best=20 Regards,

JL =

_______________________________________________<= BR>Pce=20 mailing list
Pce@lists.ietf.org
https://www1.ietf.org= /mailman/listinfo/pce

------_=_NextPart_001_01C58130.D85149DD-- --===============2027313143== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============2027313143==-- From pce-bounces@lists.ietf.org Tue Jul 05 09:49:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpnoA-0006X6-QX; Tue, 05 Jul 2005 09:49:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpnnS-0005oV-Kx for pce@megatron.ietf.org; Tue, 05 Jul 2005 09:49:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26458 for ; Tue, 5 Jul 2005 08:51:12 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpmBv-00063b-25 for pce@ietf.org; Tue, 05 Jul 2005 08:06:19 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id j65BbOtB016860; Tue, 5 Jul 2005 07:37:24 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA26914; Tue, 5 Jul 2005 07:37:23 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id ; Tue, 5 Jul 2005 07:37:23 -0400 Message-ID: <313680C9A886D511A06000204840E1CF0C885C99@whq-msgusr-02.pit.comms.marconi.com> From: "Gray, Eric" To: "'LE ROUX Jean-Louis RD-CORE-LAN'" Subject: RE: RE : [Pce] Adoption of draft-leroux-pce-discovery-reqs-01.txt as WG document ? Date: Tue, 5 Jul 2005 07:37:21 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.7 (/) X-Scan-Signature: 0aa23132abbc731e36938583486affe0 Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1659891420==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1659891420== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C58155.E821C93E" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C58155.E821C93E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable JL, =20 As long as we include explicit security requirements, and define = some trust models that we expect to support, then we are definitely moving in the right direction. We can figure out wording details as we go along. In other words, I do not = know that the text=20 you propose is what the WG is looking for, but including your proposed = text gives the WG something to respond to. =20 One relatviely small point is that there is a list of high-level requirements in section=20 3.2 (Requirements Overview) that should include some mention of = security requirements. =20 -- Eric -----Original Message----- From: LE ROUX Jean-Louis RD-CORE-LAN [mailto:jeanlouis.leroux@francetelecom.com] Sent: Tuesday, July 05, 2005 2:37 AM To: Gray, Eric; JP Vasseur Cc: pce@ietf.org Subject: RE : [Pce] Adoption of draft-leroux-pce-discovery-reqs-01.txt = as WG document ? Hi Eric =20 We have a security section that is IMHO quite clear in terms of = masquerade, forgery... and indirectly addresses trust models you refer to. But I agree with you that security requirements of a PCE discovery = solution would better be addressed in a dedicated section "PCE Discovery security = requirements" rather than in the default security section. What about the following: =20 "5.9 PCE Discovery Security Requirements =20 The PCE Discovery mechanism MUST address security issues across = multiple ASes. Key consideration MUST be given in terms of how to establish a trusted = model for PCE discovery. The PCE discovery mechanism MUST explicitly support a specific set of = trust models. =20 Particularly, mechanisms MUST be defined to avoid PCE masquerade and forgery. It MUST be possible for PCEs to authenticate PCCs and for PCCs to authenticate PCEs. =20 Also, the PCE discovery mechanism MUST be able to restrict the scope of = discovery to a set of authorized PCCs. The identity of any PCE MUST = only be learnt by authorized PCCs.=20 It MUST be possible to encrypt discovery information." =20 Note that this requirement also implies the PCC-PCE communication = protocol. =20 Is it fine with you if we add this section for next revision? =20 Best Regards =20 JL =20 =20 =20 =20 -----Message d'origine----- De : pce-bounces@lists.ietf.org [mailto:pce-bounces@lists.ietf.org] De = la part de Gray, Eric Envoy=E9 : jeudi 30 juin 2005 17:27 =C0 : 'JP Vasseur' Cc : pce@ietf.org Objet : RE: [Pce] Adoption of draft-leroux-pce-discovery-reqs-01.txt as = WG document ? JP, =20 I believe this draft needs more work - particularly in the area of establishing "security requirements" (as opposed to simple inclusion of a security section) - before it is ready to be adopted as a WG document. [JLLR] =20 =20 Implicit in the PCE concept is the inherently undefined nature of = the trust model that may apply in any given deployment. Consequently it MUST be a requirement that any PCE discovery mechanism explicitly supports a = specific set of trust models and that the complete set of possible solutions (assuming the _possibility_ that one solution may not satisfy all requirements) supports every reasonable combination of security trust models. =20 It is imperative that this is established as a "requirement" of PCE discovery solutions because this requirement will have a very definite effect on choices the WG might make right away in seeking a solution. =20 For example, assuming that we need to support a model where we = assume that it is possible for a foreign agency to mimic a valid PCE, this assumption=20 will severely limit the approaches that might be used - as long as it = is also a requirement to avoid approaches that require extensive manual = configuration. =20 To further illustrate this example, this requirement would make a = choice of discovery based on broadcast/multicast announcement mechanisms much less workable - possibly directing us more toward an authenticated = directory service approach. =20 To accept this document as a WG document without first nailing down = the specific security requirements that we want to apply would potentially = send=20 the wrong message to the authors, the WG, the Internet community and -=20 possibly - the IESG. =20 It is far more important to ensure that the work has started in the right direction than it is to drive the work to conform more closely to a = time table. =20 -- Eric -----Original Message----- From: pce-bounces@lists.ietf.org [mailto:pce-bounces@lists.ietf.org]On Behalf Of JP Vasseur Sent: Thursday, June 30, 2005 9:53 AM To: pce@ietf.org Subject: [Pce] Adoption of draft-leroux-pce-discovery-reqs-01.txt as WG document ? Dear WG, draft-leroux-discovery-reqs has just been re-published, addressing = several of comments received during the last meeting and on the list (very few remaining open items). Could you provide us your feed-back on adopting draft-leroux-discovery-reqs-01.txt as a WG document ? JP and Adrian. ------_=_NextPart_001_01C58155.E821C93E Content-Type: text/html; charset="iso-8859-1" X-MIME-Autoconverted: from 8bit to quoted-printable by mailgate.pit.comms.marconi.com id j65BbOtB016860 Content-Transfer-Encoding: quoted-printable Message
JL,
 
    As long as we include explicit security requirem= ents, and=20 define some trust models
that=20 we expect to support, then we are definitely moving in the right directio= n. We=20 can
figure=20 out wording details as we go along.  In other words, I do = not=20 know that the text
you=20 propose is what the WG is looking for, but including your proposed text g= ives=20 the
WG=20 something to respond to.
 
    One relatviely small point is that the= re is a=20 list of high-level requirements in section
3.2=20 (Requirements Overview) that should include some mention of secu= rity=20 requirements.
 
--
Eric
-----Original Message-----
From: LE ROUX Jean-Louis=20 RD-CORE-LAN [mailto:jeanlouis.leroux@francetelecom.com]
Sent:= =20 Tuesday, July 05, 2005 2:37 AM
To: Gray, Eric; JP=20 Vasseur
Cc: pce@ietf.org
Subject: RE : [Pce] Adopti= on of=20 draft-leroux-pce-discovery-reqs-01.txt as WG document ?

<= /DIV>
Hi=20 Eric
 
We=20 have a security section that is IMHO quite clear in terms of masquerade= ,=20 forgery...
and=20 indirectly addresses trust models you refer to.
But=20 I agree with you that security requirements of a PCE discovery=20 solution would better
be=20 addressed in a dedicated section "PCE Discovery security= =20 requirements"  rather than in the default security=20 section.
What=20 about the following:
 
"5.9=20 PCE Discovery Security Requirements
 
The PCE Discovery mechanism MUST address security is= sues=20 across multiple ASes.
Key=20 consideration MUST be given in terms of how to establish a trusted mode= l for=20 PCE discovery.
The PCE discovery mechanism MUST explicitly support a spec= ific=20 set of trust=20 models.
 
Particularly, mechanisms MUST be defined to avoid PCE masquera= de and=20 forgery.
It MUST be possible for P= CEs to=20 authenticate PCCs and for PCCs to authenticate=20 PCEs.
 
<= FONT=20 face=3DArial>Also,=20 the PCE discovery mechanism MUST = be able to=20 restrict the scope of 
discovery to a set of authorized PCCs. T= he=20 identity of any PCE MUST only be learnt by authorized PCCs.=20
<= FONT=20 face=3DArial>It MUST=20 be possible to encrypt  discovery information." =20
Note=20 that this requirement also implies the PCC-PCE communication=20 protocol.
 
Is=20 it fine with you if we add this section for next revision?
 
Best=20 Regards
 
JL
 
 
 
 
-----Message d'origine-----
De :=20 pce-bounces@lists.ietf.org [mailto:pce-bounces@lists.ietf.org] De = la part=20 de Gray, Eric
Envoy=E9 : jeudi 30 juin 2005=20 17:27
=C0 : 'JP Vasseur'
Cc :=20 pce@ietf.org
Objet : RE: [Pce] Adoption of=20 draft-leroux-pce-discovery-reqs-01.txt as WG document ?

JP,
 
    I believe this draft needs more work - parti= cularly in=20 the area of establishing
"security requirements" (as opposed to simple inclusion of a= security=20 section)
- before it is ready to be adopted as = a WG=20 document.
[JLLR]  
 
    Implicit in the PCE concept is the inherentl= y undefined=20 nature of the trust
model that may apply in any given deployment. Consequently i= t MUST be=20 a
requirement that any PCE discovery mechanism explicitly supp= orts a=20 specific
set of trust models and that the complete set of possible so= lutions=20 (assuming
the _possibility_ that one solution may not satisfy all requ= irements)=20 supports
every reasonable combination of security trust=20 models.
 
    It is imperative that this is established as= a=20 "requirement" of PCE discovery
solutions because this requirement will have a very definite= effect=20 on choices
the WG might make right away in seeking a=20 solution.
 
    For example, assuming that we need to suppor= t a model=20 where we assume
that it is possible for a foreign agency to mimic a valid PC= E, this=20 assumption
will severely limit the approaches that might be used - as l= ong as it=20 is also a
requirement to avoid approaches that require=20 extensive manual configuration.
 
    To further illustrate this example, this req= uirement=20 would make a choice of
discovery based on broadcast/multicast announcement mec= hanisms=20 much
less workable - possibly directing us more toward an authent= icated=20 directory
service approach.
 
    To accept this document as a WG document wit= hout first=20 nailing down the
specific security requirements that we want to apply would=20 potentially send
the wrong message to the authors, the WG, the Internet=20 community and -
possibly - the IESG.
 
    It is far more important to ensure that the = work has=20 started in the right
direction than it is to drive the work to conform more close= ly to a=20 time table.
 
--
Eric
-----Original Message-----
From:=20 pce-bounces@lists.ietf.org [mailto:pce-bounces@lists.ietf.org]On= Behalf=20 Of JP Vasseur
Sent: Thursday, June 30, 2005 9:53=20 AM
To: pce@ietf.org
Subject: [Pce] Adoption of=20 draft-leroux-pce-discovery-reqs-01.txt as WG document=20 ?

Dear WG,

draft-leroux-discovery-reqs has j= ust been=20 re-published, addressing several of comments received during the la= st=20 meeting and on the list (very few remaining open items).

Could you provide us your feed-ba= ck on=20 adopting draft-leroux-discovery-reqs-01.txt as a WG document ?

JP and=20 Adrian.

------_=_NextPart_001_01C58155.E821C93E-- --===============1659891420== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============1659891420==-- From pce-bounces@lists.ietf.org Tue Jul 05 09:51:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpnpV-0007Sf-9m; Tue, 05 Jul 2005 09:51:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpnnT-0005oV-55 for pce@megatron.ietf.org; Tue, 05 Jul 2005 09:49:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25360 for ; Tue, 5 Jul 2005 08:49:40 -0400 (EDT) Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dpmdn-0001RC-Vz for pce@ietf.org; Tue, 05 Jul 2005 08:35:09 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Tue, 5 Jul 2005 14:06:55 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE : RE : [Pce] Adoption of draft-leroux-pce-discovery-reqs-01.txt as WG document ? Date: Tue, 5 Jul 2005 14:06:54 +0200 Message-ID: Thread-Topic: RE : [Pce] Adoption of draft-leroux-pce-discovery-reqs-01.txt as WG document ? Thread-Index: AcWBVhAIFx8/X2sBTuiVEv2UDv6pqQAA3SOg From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "Gray, Eric" X-OriginalArrivalTime: 05 Jul 2005 12:06:55.0969 (UTC) FILETIME=[09B2F510:01C5815A] X-Spam-Score: 0.4 (/) X-Scan-Signature: ad21aece51aeebf80192250df67eab8a Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1905903535==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1905903535== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5815A.09821CE8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5815A.09821CE8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Eric =20 > One relatviely small point is that there is a list of high-level = requirements in section=20 >3.2 (Requirements Overview) that should include some mention of = security requirements. =20 You are right, this will be done in next revision =20 Thanks for these relevant comments =20 JL =20 -----Message d'origine----- De : Gray, Eric [mailto:Eric.Gray@marconi.com]=20 Envoy=E9 : mardi 5 juillet 2005 13:37 =C0 : LE ROUX Jean-Louis RD-CORE-LAN Cc : pce@ietf.org; JP Vasseur Objet : RE: RE : [Pce] Adoption of = draft-leroux-pce-discovery-reqs-01.txt as WG document ? JL, =20 As long as we include explicit security requirements, and define = some trust models that we expect to support, then we are definitely moving in the right = direction. We can figure out wording details as we go along. In other words, I do not = know that the text=20 you propose is what the WG is looking for, but including your proposed = text gives the WG something to respond to. =20 One relatviely small point is that there is a list of high-level = requirements in section=20 3.2 (Requirements Overview) that should include some mention of security = requirements. =20 -- Eric -----Original Message----- From: LE ROUX Jean-Louis RD-CORE-LAN = [mailto:jeanlouis.leroux@francetelecom.com] Sent: Tuesday, July 05, 2005 2:37 AM To: Gray, Eric; JP Vasseur Cc: pce@ietf.org Subject: RE : [Pce] Adoption of draft-leroux-pce-discovery-reqs-01.txt = as WG document ? Hi Eric =20 We have a security section that is IMHO quite clear in terms of = masquerade, forgery... and indirectly addresses trust models you refer to. But I agree with you that security requirements of a PCE discovery = solution would better be addressed in a dedicated section "PCE Discovery security = requirements" rather than in the default security section. What about the following: =20 "5.9 PCE Discovery Security Requirements =20 The PCE Discovery mechanism MUST address security issues across multiple = ASes. Key consideration MUST be given in terms of how to establish a trusted = model for PCE discovery. The PCE discovery mechanism MUST explicitly support a specific set of = trust models. =20 Particularly, mechanisms MUST be defined to avoid PCE masquerade and = forgery. It MUST be possible for PCEs to authenticate PCCs and for PCCs to = authenticate PCEs. =20 Also, the PCE discovery mechanism MUST be able to restrict the scope of=20 discovery to a set of authorized PCCs. The identity of any PCE MUST only = be learnt by authorized PCCs.=20 It MUST be possible to encrypt discovery information." =20 Note that this requirement also implies the PCC-PCE communication = protocol. =20 Is it fine with you if we add this section for next revision? =20 Best Regards =20 JL =20 =20 =20 =20 -----Message d'origine----- De : pce-bounces@lists.ietf.org [mailto:pce-bounces@lists.ietf.org] De = la part de Gray, Eric Envoy=E9 : jeudi 30 juin 2005 17:27 =C0 : 'JP Vasseur' Cc : pce@ietf.org Objet : RE: [Pce] Adoption of draft-leroux-pce-discovery-reqs-01.txt as = WG document ? JP, =20 I believe this draft needs more work - particularly in the area of = establishing "security requirements" (as opposed to simple inclusion of a security = section) - before it is ready to be adopted as a WG document. [JLLR] =20 =20 Implicit in the PCE concept is the inherently undefined nature of = the trust model that may apply in any given deployment. Consequently it MUST be a requirement that any PCE discovery mechanism explicitly supports a = specific set of trust models and that the complete set of possible solutions = (assuming the _possibility_ that one solution may not satisfy all requirements) = supports every reasonable combination of security trust models. =20 It is imperative that this is established as a "requirement" of PCE = discovery solutions because this requirement will have a very definite effect on = choices the WG might make right away in seeking a solution. =20 For example, assuming that we need to support a model where we = assume that it is possible for a foreign agency to mimic a valid PCE, this = assumption=20 will severely limit the approaches that might be used - as long as it is = also a requirement to avoid approaches that require extensive manual = configuration. =20 To further illustrate this example, this requirement would make a = choice of discovery based on broadcast/multicast announcement mechanisms much less workable - possibly directing us more toward an authenticated = directory service approach. =20 To accept this document as a WG document without first nailing down = the specific security requirements that we want to apply would potentially = send=20 the wrong message to the authors, the WG, the Internet community and -=20 possibly - the IESG. =20 It is far more important to ensure that the work has started in the = right direction than it is to drive the work to conform more closely to a time = table. =20 -- Eric -----Original Message----- From: pce-bounces@lists.ietf.org [mailto:pce-bounces@lists.ietf.org]On = Behalf Of JP Vasseur Sent: Thursday, June 30, 2005 9:53 AM To: pce@ietf.org Subject: [Pce] Adoption of draft-leroux-pce-discovery-reqs-01.txt as WG = document ? Dear WG, draft-leroux-discovery-reqs has just been re-published, addressing = several of comments received during the last meeting and on the list = (very few remaining open items). Could you provide us your feed-back on adopting = draft-leroux-discovery-reqs-01.txt as a WG document ? JP and Adrian. ------_=_NextPart_001_01C5815A.09821CE8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
Hi=20 Eric
 
> One relatviely small point is that there is a list of = high-level requirements in section
>3.2=20 (Requirements Overview) that should=20 include some mention of security=20 requirements.
 
You=20 are right, this will be done in next revision
 
Thanks=20 for these relevant comments
 
JL
 
-----Message d'origine-----
De : Gray, Eric=20 [mailto:Eric.Gray@marconi.com]
Envoy=E9 : mardi 5 = juillet 2005=20 13:37
=C0 : LE ROUX Jean-Louis = RD-CORE-LAN
Cc :=20 pce@ietf.org; JP Vasseur
Objet : RE: RE : [Pce] = Adoption of=20 draft-leroux-pce-discovery-reqs-01.txt as WG document = ?

JL,
 
    As long as we include explicit security = requirements, and=20 define some trust models
that=20 we expect to support, then we are definitely moving in the right = direction. We=20 can
figure out wording details as we go along.  In = other=20 words, I do not know that the text
you=20 propose is what the WG is looking for, but including your proposed = text gives=20 the
WG=20 something to respond to.
 
    One relatviely small point is that = there is a=20 list of high-level requirements in section
3.2=20 (Requirements Overview) that should include=20 some mention of security requirements.
 
--
Eric
-----Original Message-----
From: LE ROUX = Jean-Louis=20 RD-CORE-LAN = [mailto:jeanlouis.leroux@francetelecom.com]
Sent:=20 Tuesday, July 05, 2005 2:37 AM
To: Gray, Eric; JP=20 Vasseur
Cc: pce@ietf.org
Subject: RE : [Pce] = Adoption of=20 draft-leroux-pce-discovery-reqs-01.txt as WG document = ?

Hi=20 Eric
 
We=20 have a security section that is IMHO quite clear in terms of = masquerade,=20 forgery...
and indirectly addresses trust models you refer=20 to.
But I agree with you that security requirements of a = PCE=20 discovery solution would better
be=20 addressed in a dedicated section "PCE Discovery = security=20 requirements"  rather than in the default security=20 section.
What about the following:
 
"5.9 PCE Discovery Security = Requirements
 
The PCE Discovery mechanism MUST address security = issues=20 across multiple ASes.
Key consideration MUST be given in terms of how to = establish a=20 trusted model for PCE discovery.
The PCE discovery mechanism MUST explicitly support a = specific=20 set of trust=20 models.
 
Particularly, mechanisms MUST be defined to avoid PCE = masquerade and=20 = forgery.
It MUST be possible = for PCEs to=20 authenticate PCCs and for PCCs to authenticate=20 PCEs.
 
Also,=20 the PCE discovery mechanism = MUST be able=20 to restrict the scope of 
discovery to a set of authorized = PCCs. The=20 identity of any PCE MUST only be learnt by authorized PCCs.=20
It MUST=20 be possible to encrypt  discovery information." =20
Note that this requirement also implies the PCC-PCE=20 communication protocol.
 
Is=20 it fine with you if we add this section for next=20 revision?
 
Best Regards
 
JL
 
 
 
 
-----Message = d'origine-----
De :=20 pce-bounces@lists.ietf.org [mailto:pce-bounces@lists.ietf.org] = De la=20 part de Gray, Eric
Envoy=E9 : jeudi 30 juin = 2005=20 17:27
=C0 : 'JP Vasseur'
Cc :=20 pce@ietf.org
Objet : RE: [Pce] Adoption of=20 draft-leroux-pce-discovery-reqs-01.txt as WG document=20 ?

JP,
 
    I believe this draft needs more work - = particularly=20 in the area of establishing
"security requirements" (as opposed to simple inclusion = of a=20 security section)
- before it is ready to be adopted = as a WG=20 document.
[JLLR]  =
 
    Implicit in the PCE concept is the = inherently=20 undefined nature of the trust
model that may apply in any given deployment. = Consequently it MUST=20 be a
requirement that any PCE discovery mechanism explicitly = supports a=20 specific
set of trust models and that the complete set of possible = solutions=20 (assuming
the _possibility_ that one solution may not satisfy all=20 requirements) supports
every reasonable combination of security trust=20 models.
 
    It is imperative that this is established = as a=20 "requirement" of PCE discovery
solutions because this requirement will have a very = definite effect=20 on choices
the WG might make right away in seeking a=20 solution.
 
    For example, assuming that we need to = support a model=20 where we assume
that it is possible for a foreign agency to mimic a valid = PCE, this=20 assumption
will severely limit the approaches that might be used - = as long as=20 it is also a
requirement to avoid approaches that require=20 extensive manual configuration.
 
    To further illustrate this example, this = requirement=20 would make a choice of
discovery based on broadcast/multicast announcement = mechanisms=20 much
less workable - possibly directing us more toward an = authenticated=20 directory
service approach.
 
    To accept this document as a WG document = without=20 first nailing down the
specific security requirements that we want to apply = would=20 potentially send
the wrong message to the authors, the WG, the Internet=20 community and -
possibly - the IESG.
 
    It is far more important to ensure that = the work has=20 started in the right
direction than it is to drive the work to conform more = closely to a=20 time table.
 
--
Eric
-----Original Message-----
From:=20 pce-bounces@lists.ietf.org = [mailto:pce-bounces@lists.ietf.org]On=20 Behalf Of JP Vasseur
Sent: Thursday, June 30, 2005 = 9:53=20 AM
To: pce@ietf.org
Subject: [Pce] Adoption = of=20 draft-leroux-pce-discovery-reqs-01.txt as WG document=20 ?

Dear = WG,

draft-leroux-discovery-reqs = has just=20 been re-published, addressing several of comments received = during the=20 last meeting and on the list (very few remaining open = items).

Could you provide us your = feed-back on=20 adopting draft-leroux-discovery-reqs-01.txt as a WG document = ?

JP and=20 = Adrian.

------_=_NextPart_001_01C5815A.09821CE8-- --===============1905903535== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============1905903535==-- From pce-bounces@lists.ietf.org Wed Jul 06 02:40:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dq3a9-0004ZX-RH; Wed, 06 Jul 2005 02:40:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dq3a7-0004W8-M4 for pce@megatron.ietf.org; Wed, 06 Jul 2005 02:40:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17938 for ; Wed, 6 Jul 2005 02:40:26 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dq410-0003kQ-9Z for pce@ietf.org; Wed, 06 Jul 2005 03:08:17 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 05 Jul 2005 23:40:15 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j666eBvM028661 for ; Tue, 5 Jul 2005 23:40:11 -0700 (PDT) Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 6 Jul 2005 02:40:13 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: Re: [Pce] Adoption of draft-leroux-pce-discovery-reqs-01.txt as WGdocument ? Date: Wed, 6 Jul 2005 02:40:13 -0400 Message-ID: Thread-Topic: Re: [Pce] Adoption of draft-leroux-pce-discovery-reqs-01.txt as WGdocument ? Thread-Index: AcWB9Y/rLvuizqLtTsSueH37ijBpvA== From: "Zafar Ali \(zali\)" To: X-OriginalArrivalTime: 06 Jul 2005 06:40:13.0866 (UTC) FILETIME=[905928A0:01C581F5] X-Spam-Score: 0.1 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1591398943==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1591398943== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C581F5.9036C268" This is a multi-part message in MIME format. ------_=_NextPart_001_01C581F5.9036C268 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In favor.=20 =20 Thanks =20 Regards... Zafar ------_=_NextPart_001_01C581F5.9036C268 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
In = favor.=20
 
Thanks
 
Regards...=20 Zafar
------_=_NextPart_001_01C581F5.9036C268-- --===============1591398943== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============1591398943==-- From pce-bounces@lists.ietf.org Wed Jul 06 05:35:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dq6JR-0008CG-T5; Wed, 06 Jul 2005 05:35:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Do31N-0000C0-Ny for pce@megatron.ietf.org; Thu, 30 Jun 2005 13:40:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05074 for ; Thu, 30 Jun 2005 13:40:15 -0400 (EDT) Received: from zcars04e.nortelnetworks.com ([47.129.242.56] helo=zcars04e.ca.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Do3R9-00005A-DE for pce@ietf.org; Thu, 30 Jun 2005 14:06:56 -0400 Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id j5UHcnu15021 for ; Thu, 30 Jun 2005 13:38:49 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Pce] Adoption of draft-leroux-pce-discovery-reqs-01.txt as WGdocument ? Date: Thu, 30 Jun 2005 13:39:58 -0400 Message-ID: <9671A92C3C8B5744BC97F855F7CB646503F6DA70@zcarhxm1.corp.nortel.com> Thread-Topic: [Pce] Adoption of draft-leroux-pce-discovery-reqs-01.txt as WGdocument ? Thread-Index: AcV9e4iHfmMBeIftQtiqEhwOPCpH2gAHt3IQ From: "Dean Frohwerk" To: X-Spam-Score: 0.4 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 X-Mailman-Approved-At: Wed, 06 Jul 2005 05:35:23 -0400 Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0216718625==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0216718625== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C57D9A.BC210098" This is a multi-part message in MIME format. ------_=_NextPart_001_01C57D9A.BC210098 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I support making this a WG document =20 Dean Frohwerk Nortel =20 -----Original Message----- From: pce-bounces@lists.ietf.org [mailto:pce-bounces@lists.ietf.org] On Behalf Of JP Vasseur Sent: Thursday, June 30, 2005 9:53 AM To: pce@ietf.org Subject: [Pce] Adoption of draft-leroux-pce-discovery-reqs-01.txt as WGdocument ? =09 =09 Dear WG, draft-leroux-discovery-reqs has just been re-published, addressing several of comments received during the last meeting and on the list (very few remaining open items). Could you provide us your feed-back on adopting draft-leroux-discovery-reqs-01.txt as a WG document ? JP and Adrian. ------_=_NextPart_001_01C57D9A.BC210098 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
I=20 support making this a WG document
 
Dean=20 Frohwerk
Nortel
 
-----Original Message-----
From:=20 pce-bounces@lists.ietf.org [mailto:pce-bounces@lists.ietf.org] On = Behalf Of=20 JP Vasseur
Sent: Thursday, June 30, 2005 9:53 = AM
To:=20 pce@ietf.org
Subject: [Pce] Adoption of=20 draft-leroux-pce-discovery-reqs-01.txt as WGdocument = ?

Dear = WG,

draft-leroux-discovery-reqs has just = been=20 re-published, addressing several of comments received during the last = meeting=20 and on the list (very few remaining open items).

Could you provide us your feed-back = on=20 adopting draft-leroux-discovery-reqs-01.txt as a WG document ?

JP and = Adrian.

=00 ------_=_NextPart_001_01C57D9A.BC210098-- --===============0216718625== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============0216718625==-- From pce-bounces@lists.ietf.org Wed Jul 06 07:15:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dq7rs-0004i3-U6; Wed, 06 Jul 2005 07:15:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dq7rm-0004ZU-AE for pce@megatron.ietf.org; Wed, 06 Jul 2005 07:14:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00231 for ; Wed, 6 Jul 2005 07:14:51 -0400 (EDT) Received: from mail131.messagelabs.com ([216.82.242.99]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Dq8FT-0002xT-QP for pce@ietf.org; Wed, 06 Jul 2005 07:39:33 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-12.tower-131.messagelabs.com!1120648285!4395226!1 X-StarScan-Version: 5.4.15; banners=-,-,- X-Originating-IP: [192.128.166.71] Received: (qmail 9460 invoked from network); 6 Jul 2005 11:11:25 -0000 Received: from almso2.att.com (HELO almso2.proxy.att.com) (192.128.166.71) by server-12.tower-131.messagelabs.com with SMTP; 6 Jul 2005 11:11:25 -0000 Received: from attrh3i.attrh.att.com ([135.38.62.9]) by almso2.proxy.att.com (AT&T IPNS/MLO-6.0) with ESMTP id j66B7dsb004660 for ; Wed, 6 Jul 2005 07:11:25 -0400 Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by attrh3i.attrh.att.com (7.2.052) id 42BED276001FB8BD for pce@ietf.org; Wed, 6 Jul 2005 07:11:25 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] Adoption of draft-leroux-pce-discovery-reqs-01.txt asWGdocument? Date: Wed, 6 Jul 2005 06:11:25 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA09FA8FFD@KCCLUST06EVS1.ugd.att.com> Thread-Topic: [Pce] Adoption of draft-leroux-pce-discovery-reqs-01.txt asWGdocument? Thread-Index: AcV9e4iHfmMBeIftQtiqEhwOPCpH2gAHt3IQASA1dBA= From: "Ash, Gerald R \(Jerry\), ALABS" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org > Could you provide us your feed-back on adopting=20 > draft-leroux-discovery-reqs-01.txt as a WG document? I support. Jerry _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Jul 06 11:44:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqC48-0007BH-7b; Wed, 06 Jul 2005 11:44:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqC45-00076f-8N for pce@megatron.ietf.org; Wed, 06 Jul 2005 11:43:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12184 for ; Wed, 6 Jul 2005 11:43:54 -0400 (EDT) Received: from webmail.movaz.com ([65.205.166.188] helo=jera.movaz.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DqCRJ-00023h-Jc for pce@ietf.org; Wed, 06 Jul 2005 12:07:58 -0400 Received: from ib (unknown [172.16.24.122]) by jera.movaz.com (Postfix) with SMTP id 4F12C17A5; Wed, 6 Jul 2005 11:39:48 -0400 (EDT) Message-ID: <011501c58240$ea297330$7a1810ac@movaz.com> From: "Igor Bryskin" To: "LE ROUX Jean-Louis RD-CORE-LAN" , References: Subject: Re: [Pce] PCE Disco Reqs v01 Date: Wed, 6 Jul 2005 11:39:36 -0400 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.6 (/) X-Scan-Signature: 7118f330e2af0a096ba071c5e99ca10e Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0930432151==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0930432151== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0112_01C5821F.62EE7940" This is a multi-part message in MIME format. ------=_NextPart_000_0112_01C5821F.62EE7940 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable PCE Disco Reqs v01JL. I have a couple of questions/comments. 1. On more than one occasions you use the term "TE-LSP path computation = request". This sounds like an assumption that paths are computed = separately for each TE-LSP. In reality, though, a single path = computation request for a protected service is expected to determine = paths for multiple LSPs (working and protecting). Furthermore, a single = path computation may be performed for multiple services to make them = possible sharing protection resources. I would suggest dropping the = "TE-LSP" from the "TE-LSP path computation" combination; 2. In section 5.1.3 you mentioned among GMPLS capabilities a capability = to compute multi-layer paths. This sounds inaccurate: paths are always = computed in one network layer, however, a capable PCE may = determine/suggest necessary reconfigurations in lower layer(s) in order = to satisfy a particular path computation request; 3. I believe it should be stated more clearly that 2 stages of PCE = discovery are needed: basic stage and detailed stage. During the basic = stage PCE publishes some basic information about itself (presence, = computation scope, etc.) on the network independently from PCCs. = Interested PCCs should be able to participate in the detailed discovery = stage, that is, to establish communication sessions (via PCC-PCE or a = separate protocol) with the PCE to request/subscribe on the PCE detailed = information (capability, CPU power, capacity, status, etc.). This would = be good IMO both from the scalability and security points of view. 4. Responding to your questions: -Is there a need for the discovery of PCE capacity in terms of =20 computation power? This static parameter could be used to =20 ensure weighted load balancing of requests in case PCEs do not = have the same capacity.=20 Yes. It could be achieved by a direct request from a PCC during the = detailed discovery stage (see above). -Would it be useful that a PCE report its status as "congested" = in case it is too busy? PCCs may then use this dynamic =20 information to prefer a different PCE. =20 Yes. It could be achieved by a subscription of a PCC on the PCE's status = change (also during the detailed discovery stage ). Cheers, Igor ----- Original Message -----=20 From: LE ROUX Jean-Louis RD-CORE-LAN=20 To: pce@ietf.org=20 Sent: Wednesday, June 29, 2005 8:00 AM Subject: [Pce] PCE Disco Reqs v01 Hi all,=20 Version 01 of the PCE discovery reqs ID has just been published=20 = http://www.ietf.org/internet-drafts/draft-leroux-pce-discovery-reqs-01.tx= t=20 This version takes into account comments received during Minneapolis = session and on the list.=20 Here are the major changes since 00:=20 -Added multi-area network case in the problem statement=20 -Added application scenario (section 4)=20 -Section 5.1 on capability discovery modified as per discussions on = the list:=20 -Discovery of PCE location, PCE scopes and domain(s) under = control is mandatory=20 -Capability discovery is no longer a MUST=20 The list of capabilities is now out of the scope and should be = addressed in a=20 separate document.=20 =20 -Added section 5.6 on extensibility=20 -Added Security section=20 Section 5.5 (Discovery of PCE capacity and congestion) requires WG = feedback:=20 -Is there a need for the discovery of PCE capacity in terms of = computation power? This static parameter could be used to ensure = weighted load balancing of requests in case PCEs do not have the same = capacity.=20 -Would it be useful that a PCE report its status as "congested" in = case it is too busy? PCCs may then use this dynamic information to = prefer a different PCE.=20 Your comments/feedback would be highly welcome, especially on the = above point=20 Best Regards,=20 JL=20 -------------------------------------------------------------------------= ----- _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce ------=_NextPart_000_0112_01C5821F.62EE7940 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable PCE Disco Reqs v01
JL.
 
I have a couple of = questions/comments.
 
1. On more than one occasions you use = the term=20 "TE-LSP path computation request". This sounds like an assumption that = paths are=20 computed separately for each TE-LSP. In reality, though, a single path=20 computation request for a protected service is expected to determine = paths for=20 multiple LSPs (working and protecting). Furthermore, a single path = computation=20 may be performed for multiple services to make them = possible sharing=20 protection resources. I would suggest dropping the "TE-LSP" from the = "TE-LSP=20 path computation" combination;
 
2. In section 5.1.3 you mentioned among = GMPLS=20 capabilities a capability to compute multi-layer paths. This sounds = inaccurate:=20 paths are always computed in one network layer, however, a capable PCE = may=20 determine/suggest necessary reconfigurations in lower layer(s) in order = to=20 satisfy a particular path computation request;
 
3. I believe it should be stated more = clearly that=20 2 stages of PCE discovery are needed: basic stage and detailed = stage.=20 During the basic stage PCE publishes some basic information about itself = (presence, computation scope, etc.) on the network independently from = PCCs.=20 Interested PCCs should be able to participate in the detailed discovery = stage,=20 that is, to establish communication sessions (via PCC-PCE or a separate=20 protocol) with the PCE to request/subscribe on the PCE detailed = information=20 (capability, CPU power, capacity, status, etc.). This would be good IMO = both=20 from the scalability and security points of view.
 
4. Responding to your = questions:
        -Is there a need for the = discovery of PCE capacity in terms of =20
         computation power? = This=20 static parameter could be used to =20
         ensure weighted = load=20 balancing of requests in case PCEs do not =20
         have the same = capacity.=20
Yes. It could be achieved by a direct request from a PCC during the = detailed discovery stage (see above).

        -Would it = be useful=20 that a PCE report its status as "congested" =20
         in case it is too = busy?=20 PCCs may then use this dynamic =20
         information to = prefer a=20 different PCE. 
Yes. It could be achieved by a subscription of a PCC on the = PCE's=20 status change (also during the detailed discovery stage ).
 
Cheers,
Igor
 
----- Original Message -----
From:=20 LE ROUX Jean-Louis=20 RD-CORE-LAN
Sent: Wednesday, June 29, 2005 = 8:00=20 AM
Subject: [Pce] PCE Disco Reqs = v01

Hi all,

Version 01 of the PCE discovery = reqs ID has=20 just been published
http://www.ietf.org/internet-drafts/draft-leroux-pce-discovery-r= eqs-01.txt=20

This version takes into account = comments=20 received during Minneapolis session and on the list.

Here are the major changes = since 00:=20
-Added multi-area network case = in the=20 problem statement
-Added=20 application scenario (section 4)
-Section 5.1 on capability discovery modified as per = discussions on the=20 list:
        -Discovery of PCE location, PCE scopes = and domain(s)=20 under control is mandatory=20
        -Capability discovery is no longer a MUST
       The = list of=20 capabilities is now out of the scope and should be addressed in a=20
       separate = document.=20
      =20
-Added section 5.6 on = extensibility=20
-Added Security = section

Section 5.5 (Discovery of PCE = capacity and=20 congestion) requires WG feedback:
-Is = there a need for=20 the discovery of PCE capacity in terms of computation power? This = static=20 parameter could be used to ensure weighted load balancing of requests = in case=20 PCEs do not have the same capacity.

-Would it be useful that a PCE = report its=20 status as "congested" in case it is too busy? PCCs may then use this = dynamic=20 information to prefer a different PCE.

Your comments/feedback would be = highly=20 welcome, especially on the above point

Best Regards,

JL

_______________________________________________
Pce mailing=20 = list
Pce@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce<= BR> ------=_NextPart_000_0112_01C5821F.62EE7940-- --===============0930432151== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============0930432151==-- From pce-bounces@lists.ietf.org Wed Jul 06 12:33:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqCqC-0001fW-CS; Wed, 06 Jul 2005 12:33:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqCpy-0001Tk-5A for pce@megatron.ietf.org; Wed, 06 Jul 2005 12:33:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18191 for ; Wed, 6 Jul 2005 12:33:23 -0400 (EDT) Received: from webmail.movaz.com ([65.205.166.188] helo=jera.movaz.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DqDE6-0008Jm-Fl for pce@ietf.org; Wed, 06 Jul 2005 12:58:22 -0400 Received: from ib (unknown [172.16.24.122]) by jera.movaz.com (Postfix) with SMTP id 447A34734; Wed, 6 Jul 2005 12:30:18 -0400 (EDT) Message-ID: <014f01c58247$f7f42a30$7a1810ac@movaz.com> From: "Igor Bryskin" To: , "JP Vasseur" References: <4163C072-5C4F-4007-927A-CF14657FDB5A@cisco.com> Subject: Re: [Pce] Adoption of draft-leroux-pce-discovery-reqs-01.txt as WGdocument ? Date: Wed, 6 Jul 2005 12:30:06 -0400 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.7 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1698818478==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1698818478== Content-Type: multipart/alternative; boundary="----=_NextPart_000_014C_01C58226.70BF71D0" This is a multi-part message in MIME format. ------=_NextPart_000_014C_01C58226.70BF71D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I support the adopting draft-leroux-discovery-reqs-01.txt as a WG = document. Igor=20 ----- Original Message -----=20 From: JP Vasseur=20 To: pce@ietf.org=20 Sent: Thursday, June 30, 2005 9:53 AM Subject: [Pce] Adoption of draft-leroux-pce-discovery-reqs-01.txt as = WGdocument ? Dear WG, draft-leroux-discovery-reqs has just been re-published, addressing = several of comments received during the last meeting and on the list = (very few remaining open items). Could you provide us your feed-back on adopting = draft-leroux-discovery-reqs-01.txt as a WG document ? JP and Adrian. -------------------------------------------------------------------------= ----- _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce ------=_NextPart_000_014C_01C58226.70BF71D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I support the adopting draft-leroux-discovery-reqs-01.txt as a WG=20 document.
 
Igor 
----- Original Message -----
From:=20 JP = Vasseur=20
Sent: Thursday, June 30, 2005 = 9:53=20 AM
Subject: [Pce] Adoption of=20 draft-leroux-pce-discovery-reqs-01.txt as WGdocument ?

Dear = WG,

draft-leroux-discovery-reqs has just = been=20 re-published, addressing several of comments received during the last = meeting=20 and on the list (very few remaining open items).

Could you provide us your feed-back = on=20 adopting draft-leroux-discovery-reqs-01.txt as a WG document ?

JP and Adrian.

_______________________________________________
Pce mailing=20 = list
Pce@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce<= BR> ------=_NextPart_000_014C_01C58226.70BF71D0-- --===============1698818478== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============1698818478==-- From pce-bounces@lists.ietf.org Wed Jul 06 13:40:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqDsr-0007yF-7L; Wed, 06 Jul 2005 13:40:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqDso-0007wd-Fq for pce@megatron.ietf.org; Wed, 06 Jul 2005 13:40:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27697 for ; Wed, 6 Jul 2005 13:40:22 -0400 (EDT) Received: from webmail.movaz.com ([65.205.166.188] helo=jera.movaz.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DqEDi-0006yQ-RI for pce@ietf.org; Wed, 06 Jul 2005 14:02:03 -0400 Received: from ib (unknown [172.16.24.122]) by jera.movaz.com (Postfix) with SMTP id E3CACDA3; Wed, 6 Jul 2005 13:33:54 -0400 (EDT) Message-ID: <015f01c58250$da9eec50$7a1810ac@movaz.com> From: "Igor Bryskin" To: References: Subject: Re: [Pce] PCE Disco Reqs v01 Date: Wed, 6 Jul 2005 13:33:42 -0400 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.7 (/) X-Scan-Signature: e3ebaaff3b3539efaf29ef65eea2aded Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0332221004==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0332221004== Content-Type: multipart/alternative; boundary="----=_NextPart_000_015C_01C5822F.5360E520" This is a multi-part message in MIME format. ------=_NextPart_000_015C_01C5822F.5360E520 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dimitri, see in-line. ----- Original Message -----=20 From: Dimitri.Papadimitriou@alcatel.be=20 To: Igor Bryskin=20 Cc: LE ROUX Jean-Louis RD-CORE-LAN ; pce@ietf.org=20 Sent: Wednesday, July 06, 2005 12:08 PM Subject: Re: [Pce] PCE Disco Reqs v01 igor, JL - a couple of comments: 1. On more than one occasions you use the term "TE-LSP path = computation request". This sounds like an assumption that paths are = computed separately for each TE-LSP. In reality, though, a single path = computation request for a protected service is expected to determine = paths for multiple LSPs (working and protecting). Furthermore, a single = path computation may be performed for multiple services to make them = possible sharing protection resources. I would suggest dropping the = "TE-LSP" from the "TE-LSP path computation" combination; 2. In section 5.1.3 you mentioned among GMPLS capabilities a = capability to compute multi-layer paths. This sounds inaccurate: paths = are always computed in one network layer, however, a capable PCE may = determine/suggest necessary reconfigurations in lower layer(s) in order = to satisfy a particular path computation request; [dp] i would like to know how you have come to the second sentence = statement - now more specifically, and in the context of the PCE = discovery document, per [LSP-HIER] an incoming ERO may include the path = to the lower SC, procedure is described in section 8.2 of that document = so there is nothing wrong in that sentence it just need a clarification, = that the sequence of hops resulting from this computation may be = covering multiple LSP regions IB>> Come on, we had this argument many times already. Note, first, = that neither me nor the document mentioned the term "region". = Furthermore, a PSC LSP does not "go" through a lambda layer, rather, it = uses H-LSPs created in the lambda layer as PSC data links. These links = are no different from statically provisioned PSC links with an exception = that the former could be installed and removed by the control plane. = This is what I meant by the "lower layer re-configuration". The ERO = subobjects associated with lambda switching capability is just one (and = not the smartest IMO) way to control such re-configuration. An = alternative way, for instance, would be for a PCE to assume the VNT = manager role and request the lambda H-LSP provisioning *before* = responding to the path computation request. 3. I believe it should be stated more clearly that 2 stages of PCE = discovery are needed: basic stage and detailed stage. During the basic = stage PCE publishes some basic information about itself (presence, = computation scope, etc.) on the network independently from PCCs. = Interested PCCs should be able to participate in the detailed discovery = stage, that is, to establish communication sessions (via PCC-PCE or a = separate protocol) with the PCE to request/subscribe on the PCE detailed = information (capability, CPU power, capacity, status, etc.). This would = be good IMO both from the scalability and security points of view. [dp] not sure to understand why an "interested" PCC needs detailed = information on the CPU and memory utilisation at the end why more = classical "admission control" and "back pressure" mechanism can not be = used here ? IB>> In this clause I didn't mean CPU or memory utilisation, rather, = things like PCE sets of constraints that it can honor, optimization = functions, diversity types, etc.=20 4. Responding to your questions: -Is there a need for the discovery of PCE capacity in terms of = =20 computation power? This static parameter could be used to =20 ensure weighted load balancing of requests in case PCEs do = not =20 have the same capacity.=20 Yes. It could be achieved by a direct request from a PCC during the = detailed discovery stage (see above). [dp] this is not the issue, even if the PCC knows the detailed = computation power utilisation the significance of this information for = the PCC itself can not tell to this PCC more than a "don't use" if it = crosses a given threshold since the PCC does not know how much the = request the PCC is going to initiate will consume on the PCE itself - = there is an issue of the significance of the information that needs to = be discussed first before requiring its initial or later stage discovery -Would it be useful that a PCE report its status as = "congested" =20 in case it is too busy? PCCs may then use this dynamic =20 information to prefer a different PCE. =20 Yes. It could be achieved by a subscription of a PCC on the PCE's = status change (also during the detailed discovery stage ). [dp] as also proposed by JL an event driven mechanism would be = advisable=20 IB>> As the document states this information would help a PCC to = choose most suitable PCE. Igor ----- Original Message -----=20 From: LE ROUX Jean-Louis RD-CORE-LAN=20 To: pce@ietf.org=20 Sent: Wednesday, June 29, 2005 8:00 AM Subject: [Pce] PCE Disco Reqs v01 Hi all,=20 Version 01 of the PCE discovery reqs ID has just been published=20 = http://www.ietf.org/internet-drafts/draft-leroux-pce-discovery-reqs-01.tx= t=20 This version takes into account comments received during Minneapolis = session and on the list.=20 Here are the major changes since 00:=20 -Added multi-area network case in the problem statement=20 -Added application scenario (section 4)=20 -Section 5.1 on capability discovery modified as per discussions on = the list:=20 -Discovery of PCE location, PCE scopes and domain(s) under = control is mandatory=20 -Capability discovery is no longer a MUST=20 The list of capabilities is now out of the scope and should be = addressed in a=20 separate document.=20 =20 -Added section 5.6 on extensibility=20 -Added Security section=20 Section 5.5 (Discovery of PCE capacity and congestion) requires WG = feedback:=20 -Is there a need for the discovery of PCE capacity in terms of = computation power? This static parameter could be used to ensure = weighted load balancing of requests in case PCEs do not have the same = capacity.=20 -Would it be useful that a PCE report its status as "congested" in = case it is too busy? PCCs may then use this dynamic information to = prefer a different PCE.=20 Your comments/feedback would be highly welcome, especially on the = above point=20 Best Regards,=20 JL=20 -------------------------------------------------------------------------= ----- _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce ------=_NextPart_000_015C_01C5822F.5360E520 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dimitri, see in-line.
----- Original Message -----
From:=20 Dimitri.Papadimitriou@al= catel.be=20
Cc: LE ROUX Jean-Louis=20 RD-CORE-LAN ; pce@ietf.org
Sent: Wednesday, July 06, 2005 = 12:08=20 PM
Subject: Re: [Pce] PCE Disco = Reqs=20 v01

igor, JL - a couple of = comments:

1. On=20 more than one occasions you use the term "TE-LSP path computation = request".=20 This sounds like an assumption that paths are computed separately for = each=20 TE-LSP. In reality, though, a single path computation request for a = protected=20 service is expected to determine paths for multiple LSPs (working and=20 protecting). Furthermore, a single path computation may be performed = for=20 multiple services to make them possible sharing protection = resources. I=20 would suggest dropping the "TE-LSP" from the "TE-LSP path computation" = combination;

2. In section 5.1.3 you mentioned among GMPLS = capabilities=20 a capability to compute multi-layer paths. This sounds inaccurate: = paths are=20 always computed in one network layer, however, a capable PCE may=20 determine/suggest necessary reconfigurations in lower layer(s) in = order to=20 satisfy a particular path computation request;

[dp] i would like to know how you = have come to=20 the second sentence statement - now more specifically, and in the = context of=20 the PCE discovery document, per [LSP-HIER] an incoming ERO may include = the=20 path to the lower SC, procedure is described in section 8.2 of that = document=20 so there is nothing wrong in that sentence it just need a = clarification, that=20 the sequence of hops resulting from this computation may be covering = multiple=20 LSP regions

IB>> Come on, we had this argument = many=20 times already. Note, first, that neither me nor the document = mentioned=20 the term "region". Furthermore, a PSC LSP does not "go" = through a=20 lambda layer, rather, it uses H-LSPs created in the lambda layer as = PSC data=20 links. These links are no different from statically provisioned PSC = links with=20 an exception that the former could be installed and removed by the = control=20 plane. This is what I meant by the "lower layer re-configuration". The = ERO=20 subobjects associated with lambda switching capability is just one = (and not=20 the smartest IMO) way to control such re-configuration. An alternative = way,=20 for instance, would be for a PCE to assume the VNT manager role = and=20 request the lambda H-LSP provisioning *before* responding to = the path=20 computation request.


3. I believe it should be stated = more=20 clearly that 2 stages of PCE discovery are needed: basic stage = and=20 detailed stage. During the basic stage PCE publishes some basic = information=20 about itself (presence, computation scope, etc.) on the network = independently=20 from PCCs. Interested PCCs should be able to participate in the = detailed=20 discovery stage, that is, to establish communication sessions (via = PCC-PCE or=20 a separate protocol) with the PCE to request/subscribe on the PCE = detailed=20 information (capability, CPU power, capacity, status, etc.). This = would be=20 good IMO both from the scalability and security points of = view.

[dp] not sure to understand why an=20 "interested" PCC needs detailed information on the CPU and memory = utilisation=20 at the end why more classical "admission control" and "back pressure"=20 mechanism can not be used here ?

IB>> In this clause I didn't mean = CPU or=20 memory utilisation, rather, things like PCE sets of constraints = that it=20 can honor, optimization functions, diversity types, = etc. 


4. Responding to your=20 questions:
        -Is there a = need for=20 the discovery of PCE capacity in terms of =20
         computation = power? This=20 static parameter could be used to =20
         ensure weighted = load=20 balancing of requests in case PCEs do not =20
         have the same = capacity.=20
Yes. It could be achieved by a direct request from a PCC during = the=20 detailed discovery stage (see above).

[dp] this is not the issue, even if = the PCC=20 knows the detailed computation power utilisation the significance of = this=20 information for the PCC itself can not tell to this PCC more than a = "don't=20 use" if it crosses a given threshold since the PCC does not know how = much the=20 request the PCC is going to initiate will consume on the PCE itself - = there is=20 an issue of the significance of the information that needs to be = discussed=20 first before requiring its initial or later stage discovery


       =20 -Would it be useful that a PCE report its status as "congested" =20
         in case it is too = busy?=20 PCCs may then use this dynamic =20
         information to = prefer a=20 different PCE. 
Yes. It could be achieved by a subscription = of=20 a PCC on the PCE's status change (also during the detailed = discovery=20 stage ).

[dp] as also proposed by JL an event = driven=20 mechanism would be advisable

IB>> As the document states this = information=20 would help a PCC to choose most suitable PCE.

 

Igor



----- Original Message ----- =
From: LE ROUX Jean-Louis=20 RD-CORE-LAN =
To: pce@ietf.org
Sent: Wednesday, June 29, = 2005 8:00=20 AM
Subject: [Pce] PCE Disco Reqs=20 v01

Hi all,

Version 01 of = the PCE=20 discovery reqs ID has just been published =
http://www.ietf.org/internet-drafts/draft-leroux-pce-discovery= -reqs-01.txt

This version takes into account = comments=20 received during Minneapolis session and on the list.=20

Here are the major changes since 00:=20
-Added multi-area network case in the problem = statement
-Added application scenario (section 4) =
-Section 5.1 on=20 capability discovery modified as per discussions on the list:=20
       =20 -Discovery of PCE location, PCE scopes and domain(s) under = control is=20 mandatory
        -Capability = discovery=20 is no longer a MUST=20
       The list of = capabilities is=20 now out of the scope and should be addressed in a=20
       separate document.=20
      
-Added section 5.6 = on=20 extensibility
-Added Security section =

Section=20 5.5 (Discovery of PCE capacity and congestion) requires WG = feedback:
-Is there a need for the = discovery of=20 PCE capacity in terms of computation power? This static parameter = could be=20 used to ensure weighted load balancing of requests in case PCEs do not = have=20 the same capacity.

-Would it be useful that a PCE report its = status as=20 "congested" in case it is too busy? PCCs may then use this dynamic = information=20 to prefer a different PCE.

Your comments/feedback would be = highly=20 welcome, especially on the above point =

Best=20 Regards,

JL


_______________________________________________
Pce mailing list
Pce@lists.ietf.org
https://www1.ietf.org= /mailman/listinfo/pce

_______________________________________________<= BR>Pce=20 mailing list
Pce@lists.ietf.org
https://www1.ietf.org= /mailman/listinfo/pce

------=_NextPart_000_015C_01C5822F.5360E520-- --===============0332221004== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============0332221004==-- From pce-bounces@lists.ietf.org Wed Jul 06 14:31:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqEfx-00015R-6Y; Wed, 06 Jul 2005 14:31:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqEfv-00012E-Da for pce@megatron.ietf.org; Wed, 06 Jul 2005 14:31:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02138 for ; Wed, 6 Jul 2005 14:31:09 -0400 (EDT) From: Dimitri.Papadimitriou@alcatel.be Received: from smail.alcatel.fr ([64.208.49.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqEwW-0003qr-9e for pce@ietf.org; Wed, 06 Jul 2005 14:48:23 -0400 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id j66IKKDD027838; Wed, 6 Jul 2005 20:20:20 +0200 To: "Igor Bryskin" MIME-Version: 1.0 Subject: Re: [Pce] PCE Disco Reqs v01 Date: Wed, 6 Jul 2005 20:20:15 +0200 Message-ID: X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.12HF788 | September 23, 2004) at 07/06/2005 20:20:19 MIME-Version: 1.0 X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Score: 4.3 (++++) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: Dimitri.Papadimitriou@alcatel.be, pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1777235677==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org --===============1777235677== Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 PFA+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPiZuYnNwOzxCUj48QlI+aWdvcjxCUj48 QlI+MS4gT24gbW9yZSB0aGFuIG9uZSBvY2Nhc2lvbnMgeW91IHVzZSB0aGUgdGVybSAmcXVvdDtU RS1MU1AgcGF0aCBjb21wdXRhdGlvbiByZXF1ZXN0JnF1b3Q7LiBUaGlzIHNvdW5kcyBsaWtlIGFu IGFzc3VtcHRpb24gdGhhdCBwYXRocyBhcmUgY29tcHV0ZWQgc2VwYXJhdGVseSBmb3IgZWFjaCBU RS1MU1AuIEluIHJlYWxpdHksIHRob3VnaCwgYSBzaW5nbGUgcGF0aCBjb21wdXRhdGlvbiByZXF1 ZXN0IGZvciBhIHByb3RlY3RlZCBzZXJ2aWNlIGlzIGV4cGVjdGVkIHRvIGRldGVybWluZSBwYXRo cyBmb3IgbXVsdGlwbGUgTFNQcyAod29ya2luZyBhbmQgcHJvdGVjdGluZykuIEZ1cnRoZXJtb3Jl LCBhIHNpbmdsZSBwYXRoIGNvbXB1dGF0aW9uIG1heSBiZSBwZXJmb3JtZWQgZm9yIG11bHRpcGxl IHNlcnZpY2VzIHRvIG1ha2UgdGhlbSBwb3NzaWJsZSZuYnNwO3NoYXJpbmcgcHJvdGVjdGlvbiBy ZXNvdXJjZXMuIEkgd291bGQgc3VnZ2VzdCBkcm9wcGluZyB0aGUgJnF1b3Q7VEUtTFNQJnF1b3Q7 IGZyb20gdGhlICZxdW90O1RFLUxTUCBwYXRoIGNvbXB1dGF0aW9uJnF1b3Q7IGNvbWJpbmF0aW9u OzxCUj48QlI+Mi4gSW4gc2VjdGlvbiA1LjEuMyB5b3UgbWVudGlvbmVkIGFtb25nIEdNUExTIGNh cGFiaWxpdGllcyBhIGNhcGFiaWxpdHkgdG8gY29tcHV0ZSBtdWx0aS1sYXllciBwYXRocy4gVGhp cyBzb3VuZHMgaW5hY2N1cmF0ZTogcGF0aHMgYXJlIGFsd2F5cyBjb21wdXRlZCBpbiBvbmUgbmV0 d29yayBsYXllciwgaG93ZXZlciwgYSBjYXBhYmxlIFBDRSBtYXkgZGV0ZXJtaW5lL3N1Z2dlc3Qg bmVjZXNzYXJ5IHJlY29uZmlndXJhdGlvbnMgaW4gbG93ZXIgbGF5ZXIocykgaW4gb3JkZXIgdG8g c2F0aXNmeSBhIHBhcnRpY3VsYXIgcGF0aCBjb21wdXRhdGlvbiByZXF1ZXN0OzxCUj48QlI+PEJS PltkcF0gaSB3b3VsZCBsaWtlIHRvIGtub3cgaG93IHlvdSBoYXZlIGNvbWUgdG8gdGhlIHNlY29u ZCBzZW50ZW5jZSBzdGF0ZW1lbnQgLSBub3cgbW9yZSBzcGVjaWZpY2FsbHksIGFuZCBpbiB0aGUg Y29udGV4dCBvZiB0aGUgUENFIGRpc2NvdmVyeSBkb2N1bWVudCwgcGVyIFtMU1AtSElFUl0gYW4g aW5jb21pbmcgRVJPIG1heSBpbmNsdWRlIHRoZSBwYXRoIHRvIHRoZSBsb3dlciBTQywgcHJvY2Vk dXJlIGlzIGRlc2NyaWJlZCBpbiBzZWN0aW9uIDguMiBvZiB0aGF0IGRvY3VtZW50IHNvIHRoZXJl IGlzIG5vdGhpbmcgd3JvbmcgaW4gdGhhdCBzZW50ZW5jZSBpdCBqdXN0IG5lZWQgYSBjbGFyaWZp Y2F0aW9uLCB0aGF0IHRoZSBzZXF1ZW5jZSBvZiBob3BzIHJlc3VsdGluZyBmcm9tIHRoaXMgY29t cHV0YXRpb24gbWF5IGJlIGNvdmVyaW5nIG11bHRpcGxlIExTUCByZWdpb25zPEJSPjxCUj5JQiZn dDsmZ3Q7IENvbWUgb24sIHdlIGhhZCB0aGlzIGFyZ3VtZW50IG1hbnkgdGltZXMgYWxyZWFkeS4g Tm90ZSwgZmlyc3QsIHRoYXQgbmVpdGhlciZuYnNwO21lIG5vciB0aGUgZG9jdW1lbnQgbWVudGlv bmVkIHRoZSB0ZXJtICZxdW90O3JlZ2lvbiZxdW90Oy4mbmJzcDtGdXJ0aGVybW9yZSwmbmJzcDth IFBTQyBMU1AgZG9lcyBub3QgJnF1b3Q7Z28mcXVvdDsgdGhyb3VnaCBhIGxhbWJkYSBsYXllciwg cmF0aGVyLCBpdCB1c2VzIEgtTFNQcyBjcmVhdGVkIGluIHRoZSBsYW1iZGEgbGF5ZXIgYXMgUFND IGRhdGEgbGlua3MuIFRoZXNlIGxpbmtzIGFyZSBubyBkaWZmZXJlbnQgZnJvbSBzdGF0aWNhbGx5 IHByb3Zpc2lvbmVkIFBTQyBsaW5rcyB3aXRoIGFuIGV4Y2VwdGlvbiB0aGF0IHRoZSBmb3JtZXIg Y291bGQgYmUgaW5zdGFsbGVkIGFuZCByZW1vdmVkIGJ5IHRoZSBjb250cm9sIHBsYW5lLiBUaGlz IGlzIHdoYXQgSSBtZWFudCBieSB0aGUgJnF1b3Q7bG93ZXIgbGF5ZXIgcmUtY29uZmlndXJhdGlv biZxdW90Oy4gVGhlIEVSTyBzdWJvYmplY3RzIGFzc29jaWF0ZWQgd2l0aCBsYW1iZGEgc3dpdGNo aW5nIGNhcGFiaWxpdHkgaXMganVzdCBvbmUgKGFuZCBub3QgdGhlIHNtYXJ0ZXN0IElNTykgd2F5 IHRvIGNvbnRyb2wgc3VjaCByZS1jb25maWd1cmF0aW9uLiBBbiBhbHRlcm5hdGl2ZSB3YXksIGZv ciBpbnN0YW5jZSwgd291bGQgYmUgZm9yIGEgUENFIHRvJm5ic3A7YXNzdW1lIHRoZSBWTlQgbWFu YWdlciByb2xlIGFuZCByZXF1ZXN0IHRoZSBsYW1iZGEgSC1MU1AgcHJvdmlzaW9uaW5nICpiZWZv cmUqIHJlc3BvbmRpbmcgdG8gdGhlJm5ic3A7cGF0aCBjb21wdXRhdGlvbiByZXF1ZXN0LjxCUj48 QlI+W2RwMl0gdGhhdCdzIG5vdCBteSBwb2ludCBhbmQgdGhlIHBvaW50IGlzIGNlcnRhaW5seSBu b3Qgd2hldGhlciB5b3UgY2FuIGFjaGlldmUgb3Igbm90IHRoZSBzYW1lIGZ1bmN0aW9uYWxpdHkg d2l0aCBvdGhlciB0ZWNobmlxdWVzIC0gdGhlIGlzc3VlIGlzIHdoZXRoZXIgYSBQQ0UgY2FuIGJl IGJlY29tZSBhIHVzYWJsZSB0b29sIGluIHRoZSBjb250ZXh0IG9mIHRoZSBDQ0FNUCBhbmQgTVBM UyBzaWduYWxpbmcgcHJvY2VkdXJlcyB0aGVuIGl0IG5lZWRzIHRvIGNvdmVyIHdoYXQgdGhlc2Ug cHJvY2VkdXJlcyBoYXZlIGJlZW4gZGVmaW5lZCBhcyBwYXJ0IG9mIHRoZXNlIGRvY3VtZW50cyBv dGhlcndpc2Ugb25lIGlzIGdvaW5nIHRvIGJlIGZhY2VkIHdpdGggdGhlIGlzc3VlIG9mIGEgJnF1 b3Q7R01QTFMtY2FwYWJsZSBQQ0UmcXVvdDsgdGhhdCBkb2VzIG5vdCBhdCB0aGUgZW5kIHByb3Zp ZGVzIHRoZSBleHBlY3RlZCBHTVBMUy9NUExTIGNhcGFiaWxpdGllcyAtIDwvRk9OVD48L1A+PFA+ PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPjxCUj4zLiBJIGJlbGlldmUgaXQgc2hvdWxk IGJlIHN0YXRlZCBtb3JlIGNsZWFybHkgdGhhdCAyIHN0YWdlcyBvZiBQQ0UgZGlzY292ZXJ5Jm5i c3A7YXJlIG5lZWRlZDogYmFzaWMgc3RhZ2UgYW5kIGRldGFpbGVkIHN0YWdlLiBEdXJpbmcgdGhl IGJhc2ljIHN0YWdlIFBDRSBwdWJsaXNoZXMgc29tZSBiYXNpYyBpbmZvcm1hdGlvbiBhYm91dCBp dHNlbGYgKHByZXNlbmNlLCBjb21wdXRhdGlvbiBzY29wZSwgZXRjLikgb24gdGhlIG5ldHdvcmsg aW5kZXBlbmRlbnRseSBmcm9tIFBDQ3MuIEludGVyZXN0ZWQgUENDcyBzaG91bGQgYmUgYWJsZSB0 byBwYXJ0aWNpcGF0ZSBpbiB0aGUgZGV0YWlsZWQgZGlzY292ZXJ5IHN0YWdlLCB0aGF0IGlzLCB0 byBlc3RhYmxpc2ggY29tbXVuaWNhdGlvbiBzZXNzaW9ucyAodmlhIFBDQy1QQ0Ugb3IgYSBzZXBh cmF0ZSBwcm90b2NvbCkgd2l0aCB0aGUgUENFIHRvIHJlcXVlc3Qvc3Vic2NyaWJlIG9uIHRoZSBQ Q0UgZGV0YWlsZWQgaW5mb3JtYXRpb24gKGNhcGFiaWxpdHksIENQVSBwb3dlciwgY2FwYWNpdHks IHN0YXR1cywgZXRjLikuIFRoaXMgd291bGQgYmUgZ29vZCBJTU8gYm90aCBmcm9tIHRoZSBzY2Fs YWJpbGl0eSBhbmQgc2VjdXJpdHkgcG9pbnRzIG9mIHZpZXcuPEJSPjxCUj48QlI+W2RwXSBub3Qg c3VyZSB0byB1bmRlcnN0YW5kIHdoeSBhbiAmcXVvdDtpbnRlcmVzdGVkJnF1b3Q7IFBDQyBuZWVk cyBkZXRhaWxlZCBpbmZvcm1hdGlvbiBvbiB0aGUgQ1BVIGFuZCBtZW1vcnkgdXRpbGlzYXRpb24g YXQgdGhlIGVuZCB3aHkgbW9yZSBjbGFzc2ljYWwgJnF1b3Q7YWRtaXNzaW9uIGNvbnRyb2wmcXVv dDsgYW5kICZxdW90O2JhY2sgcHJlc3N1cmUmcXVvdDsgbWVjaGFuaXNtIGNhbiBub3QgYmUgdXNl ZCBoZXJlID88QlI+PEJSPklCJmd0OyZndDsgSW4gdGhpcyBjbGF1c2UgSSBkaWRuJ3QgbWVhbiBD UFUgb3IgbWVtb3J5IHV0aWxpc2F0aW9uLCByYXRoZXIsJm5ic3A7dGhpbmdzIGxpa2UgUENFIHNl dHMgb2YgY29uc3RyYWludHMgdGhhdCBpdCBjYW4gaG9ub3IsIG9wdGltaXphdGlvbiBmdW5jdGlv bnMsIGRpdmVyc2l0eSB0eXBlcywgZXRjLiZuYnNwOzwvRk9OVD48L1A+PFA+PEZPTlQgRkFDRT0i TW9ub3NwYWNlLENvdXJpZXIiPjxCUj40LiBSZXNwb25kaW5nIHRvIHlvdXIgcXVlc3Rpb25zOjxC Uj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLUlzIHRoZXJlIGEg bmVlZCBmb3IgdGhlIGRpc2NvdmVyeSBvZiBQQ0UgY2FwYWNpdHkgaW4gdGVybXMgb2YmbmJzcDsg PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBjb21w dXRhdGlvbiBwb3dlcj8gVGhpcyBzdGF0aWMgcGFyYW1ldGVyIGNvdWxkIGJlIHVzZWQgdG8mbmJz cDsgPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBl bnN1cmUgd2VpZ2h0ZWQgbG9hZCBiYWxhbmNpbmcgb2YgcmVxdWVzdHMgaW4gY2FzZSBQQ0VzIGRv IG5vdCZuYnNwOyA8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IGhhdmUgdGhlIHNhbWUgY2FwYWNpdHkuIDxCUj5ZZXMuIEl0IGNvdWxkIGJlIGFjaGll dmVkIGJ5IGEgZGlyZWN0IHJlcXVlc3QgZnJvbSBhIFBDQyBkdXJpbmcgdGhlIGRldGFpbGVkIGRp c2NvdmVyeSBzdGFnZSAoc2VlIGFib3ZlKS48QlI+PEJSPjxCUj5bZHBdIHRoaXMgaXMgbm90IHRo ZSBpc3N1ZSwgZXZlbiBpZiB0aGUgUENDIGtub3dzIHRoZSBkZXRhaWxlZCBjb21wdXRhdGlvbiBw b3dlciB1dGlsaXNhdGlvbiB0aGUgc2lnbmlmaWNhbmNlIG9mIHRoaXMgaW5mb3JtYXRpb24gZm9y IHRoZSBQQ0MgaXRzZWxmIGNhbiBub3QgdGVsbCB0byB0aGlzIFBDQyBtb3JlIHRoYW4gYSAmcXVv dDtkb24ndCB1c2UmcXVvdDsgaWYgaXQgY3Jvc3NlcyBhIGdpdmVuIHRocmVzaG9sZCBzaW5jZSB0 aGUgUENDIGRvZXMgbm90IGtub3cgaG93IG11Y2ggdGhlIHJlcXVlc3QgdGhlIFBDQyBpcyBnb2lu ZyB0byBpbml0aWF0ZSB3aWxsIGNvbnN1bWUgb24gdGhlIFBDRSBpdHNlbGYgLSB0aGVyZSBpcyBh biBpc3N1ZSBvZiB0aGUgc2lnbmlmaWNhbmNlIG9mIHRoZSBpbmZvcm1hdGlvbiB0aGF0IG5lZWRz IHRvIGJlIGRpc2N1c3NlZCBmaXJzdCBiZWZvcmUgcmVxdWlyaW5nIGl0cyBpbml0aWFsIG9yIGxh dGVyIHN0YWdlIGRpc2NvdmVyeTxCUj48QlI+PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAtV291bGQgaXQgYmUgdXNlZnVsIHRoYXQgYSBQQ0UgcmVwb3J0IGl0 cyBzdGF0dXMgYXMgJnF1b3Q7Y29uZ2VzdGVkJnF1b3Q7Jm5ic3A7IDxCUj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaW4gY2FzZSBpdCBpcyB0b28gYnVz eT8gUENDcyBtYXkgdGhlbiB1c2UgdGhpcyBkeW5hbWljJm5ic3A7IDxCUj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaW5mb3JtYXRpb24gdG8gcHJlZmVy IGEgZGlmZmVyZW50IFBDRS4mbmJzcDsgPEJSPlllcy4gSXQgY291bGQgYmUgYWNoaWV2ZWQgYnkg YSBzdWJzY3JpcHRpb24gb2YgYSZuYnNwO1BDQyBvbiB0aGUgUENFJ3Mgc3RhdHVzIGNoYW5nZSAo YWxzbyBkdXJpbmcgdGhlIGRldGFpbGVkIGRpc2NvdmVyeSBzdGFnZSApLjxCUj48QlI+PEJSPltk cF0gYXMgYWxzbyBwcm9wb3NlZCBieSBKTCBhbiBldmVudCBkcml2ZW4gbWVjaGFuaXNtIHdvdWxk IGJlIGFkdmlzYWJsZSA8QlI+PEJSPklCJmd0OyZndDsgQXMgdGhlIGRvY3VtZW50IHN0YXRlcyB0 aGlzIGluZm9ybWF0aW9uIHdvdWxkIGhlbHAgYSBQQ0MgdG8gY2hvb3NlIG1vc3Qgc3VpdGFibGUg UENFLjxCUj48QlI+W2RwMl0gdGhlIGtleSBpc3N1ZSBpcyB0aGF0ICZxdW90O21vc3Qgc3VpdGFi bGUmcXVvdDsgYmVjb21lcyB0aGVuIGEgdGltZS1kZXBlbmRlbnQgcHJvYmxlbSBhdCB0aGUgZW5k IHRoZSBkaXNjb3ZlcnkgZG9jdW1lbnQgY291bGQgYmUgc2ltcGx5IHN0YXRlIHRoYXQgdGhlcmUg c2hvdWxkIGJlIGEgbWVjaGFuaXNtIHRoYXQgbWFpbnRhaW5zIChhcyBwYXJ0IG9mIGl0cyBzZWNv bmQgc3RhZ2UgZXhjaGFuZ2Ugd2l0aCB0aGUgJnF1b3Q7c3Vic2NyaWJpbmcgUENDcyZxdW90Oykg dGhlIGxpdmVuZXNzL3N0YXR1cyByZXBvcnQgb2YgdGhlIGluaXRpYWxseSAmcXVvdDtkaXNjb3Zl cnkgaW5mb3JtYXRpb24mcXVvdDsgd2l0aG91dCBkZWx2aW5nIGludG8gdGhlIGRldGFpbGVkIGlt cGxlbWVudGF0aW9uIGFzcGVjdHM8L0ZPTlQ+IDxCUj48L1A+ --===============1777235677== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============1777235677==-- From pce-bounces@lists.ietf.org Wed Jul 06 20:22:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqKA0-00029J-Vb; Wed, 06 Jul 2005 20:22:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqK9y-00028j-Pj for pce@megatron.ietf.org; Wed, 06 Jul 2005 20:22:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17948 for ; Wed, 6 Jul 2005 20:22:33 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqKb3-00086i-1R for pce@ietf.org; Wed, 06 Jul 2005 20:50:34 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-4.cisco.com with ESMTP; 06 Jul 2005 17:22:09 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j670M1on020146; Wed, 6 Jul 2005 17:22:03 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 6 Jul 2005 20:22:05 -0400 Received: from [192.168.1.100] ([10.86.240.89]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 6 Jul 2005 20:22:04 -0400 Mime-Version: 1.0 (Apple Message framework v730) Content-Transfer-Encoding: 7bit Message-Id: <2626A1D9-5FCB-49CB-A09C-987C17A3E280@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: LE ROUX Jean-Louis RD-CORE-LAN , Paul Mabey , raymond.zhang@bt.infonet.com, Eiji Oki , Ting_Wo Chung , Richard Rabbat , pce@ietf.org From: JP Vasseur Date: Wed, 6 Jul 2005 20:22:24 -0400 X-Mailer: Apple Mail (2.730) X-OriginalArrivalTime: 07 Jul 2005 00:22:04.0685 (UTC) FILETIME=[E6F4A3D0:01C58289] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Cc: Subject: [Pce] New Working Group document: draft-leroux-pce-discovery-reqs-01.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi, Considering the WG consensus on this ID, please re-publish as a WG document (with no content change). Authors, several comments have been made of the list regarding this document. Please make sure to address all the concerns in a new revision right after having re-published as a WG document (before July 18th). Thanks. JP. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Jul 07 04:47:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqS2z-0000Ip-60; Thu, 07 Jul 2005 04:47:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqS2x-0000I8-C1 for pce@megatron.ietf.org; Thu, 07 Jul 2005 04:47:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12923 for ; Thu, 7 Jul 2005 04:47:49 -0400 (EDT) From: neil.2.harrison@bt.com Received: from smtp4.smtp.bt.com ([217.32.164.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqSU5-0005VQ-OP for pce@ietf.org; Thu, 07 Jul 2005 05:15:55 -0400 Received: from i2km99-ukbr.domain1.systemhost.net ([193.113.197.31]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 7 Jul 2005 09:47:34 +0100 Received: from i2km07-ukbr.domain1.systemhost.net ([193.113.197.26]) by i2km99-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Thu, 7 Jul 2005 09:47:04 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] PCE Disco Reqs v01 Date: Thu, 7 Jul 2005 09:47:04 +0100 Message-ID: <0536FC9B908BEC4597EE721BE6A353890A9F1D84@i2km07-ukbr.domain1.systemhost.net> Thread-Topic: [Pce] PCE Disco Reqs v01 Thread-Index: AcWCUeRWjf821ldzQEmbOCU8De6zJgAbl6Ng To: , X-OriginalArrivalTime: 07 Jul 2005 08:47:04.0672 (UTC) FILETIME=[7327BE00:01C582D0] X-Spam-Score: 0.3 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: quoted-printable Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Igor wrote 06 July 2005 18:34 =3D=3D=3D 2. In section 5.1.3 you mentioned among GMPLS capabilities a capability to compute multi-layer paths. This sounds inaccurate: paths are always computed in one network layer, however, a capable PCE may determine/suggest necessary reconfigurations in lower layer(s) in order to satisfy a particular path computation request; [dp] i would like to know how you have come to the second sentence statement - now more specifically, and in the context of the PCE discovery document, per [LSP-HIER] an incoming ERO may include the path to the lower SC, procedure is described in section 8.2 of that document so there is nothing wrong in that sentence it just need a clarification, that the sequence of hops resulting from this computation may be covering multiple LSP regions. IB>> Come on, we had this argument many times already. Note, first, that neither me nor the document mentioned the term "region". Furthermore, a PSC LSP does not "go" through a lambda layer, rather, it uses H-LSPs created in the lambda layer as PSC data links. =3D=3D=3D =20 NH=3D> I am, quite frankly, amazed to find there are still some folks, like Dimitri apparently, who believe in the fairy-tale that you can create 'topology on the fly' in a set of layer networks. You get the same broken notion in PWE3 with the 'revelation' that a new layer network (the PW layer) has been created and there is now a >=3D2 layer network routing/signalling problem (and the rest function-wise) to address.....never mind the madness of now having now created a peer-partition interworking problem wrt XoverMPLS/LDP and XoverIP/l2tpv3 cases. {Also see footnote reference if anyone wants to know more about this and some of the points in what follows.} And of course, as you rightly point out Igor a client layer link is created by, and can only exist when there is, an *already* provisioned server layer trail....and this client/server relationship is recursive right down to the duct. This is how we create a client layer topology. Indeed, with the additional requirement for client and server layer functional decoupling, this is precisely what the well-known remark 'IP over everything' demands. Aside - Even if any folks are foolish enough dismisses the commercial requirements for different party operating independence and the technical issues relating to client/server layer network relationships, I'd suggest they go try and build a business model for doing BoD trails at large BWs (eg optics). We did the math on this a few years ago....think you may get an important conclusion. Bottom-line: Trail holding times must increase (and significantly so) as one approaches the duct. Now I think trying to calculate routes across a topology that does not exist is very fine conjuring trick....maybe David Copperfield or David Blaine might be interested in this illusion? ;-)=20 We are, however, very fortunate that co-cs mode protects itself to a large extent against folks doing too many daft things to it. For example, you can't do merging violations, hierarchy is forced (so we can have proper client/server layer functional decoupling), OOB control/management is forced (which has important resilience/stability/security design implications) and folks can't spend lots of time/money creating a load of traffic/QoS classes that are largely useless. =20 Sadly the co-ps mode offers no such strong self-protection and you can do all manner of bad things to it (I'll spare you a long list). However, in the context of this mail and topic of 'topology on the fly', you may like to note that MPLS is based on the concept of a digital wrapper. And if it's never struck you before just how bizarre this is (and I'll point out right now that, so far, this has been essentially latent, because when operating in a constrained operator/service environment where the *effective networked* depth is 1 the wrapper largely looks like a normal layer network), just note that in every other case where we want to create a client layer network the server layer trails (that provide the inter-node client layer links) MUST be provided 1st...in other words the client goes inside an *already* provided/existing server trail. Now go look at MPLS....here we can 'add a label at will' to an existing LSP and create a lower (outer) level server layer trail AFTER our (inner) client layer trail exists. Try following that line of logic down to the duct and see what happens! =20 However, our PWE3 colleagues seems more interested right now in arguing the toss on 'LDP signalling vs RSVP-TE signalling' and don't seem to see/grasp the deeper and far more serious issue here. Anyway, it's nice to know there is at least one other person out there Igor who seems to have a grip on reality (actually I know many folks who do understand the points above....most however choose to remain silent for one reason or another). Footnote - If anyone is interested to learn more about the stuff I am referring to here, please see my mail on a 'Network Builder Capability' at http://www1.ietf.org/mail-archive/web/pwe3/current/msg07065.html regards, Neil _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Jul 07 05:01:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqSFn-0003z7-RD; Thu, 07 Jul 2005 05:01:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqSFm-0003xq-8U for pce@megatron.ietf.org; Thu, 07 Jul 2005 05:01:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13784 for ; Thu, 7 Jul 2005 05:01:03 -0400 (EDT) From: Dimitri.Papadimitriou@alcatel.be Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqSgs-0000IN-P2 for pce@ietf.org; Thu, 07 Jul 2005 05:29:10 -0400 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id j6790uDD019840; Thu, 7 Jul 2005 11:00:56 +0200 To: Subject: RE: [Pce] PCE Disco Reqs v01 MIME-Version: 1.0 Date: Thu, 7 Jul 2005 11:00:48 +0200 Message-ID: X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.12HF788 | September 23, 2004) at 07/07/2005 11:00:56 Content-type: text/plain; charset=us-ascii X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Score: 0.3 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: pce@ietf.org, Dimitri.Papadimitriou@alcatel.be X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org neil - see in-line because we are not discussing the same issue === 2. In section 5.1.3 you mentioned among GMPLS capabilities a capability to compute multi-layer paths. This sounds inaccurate: paths are always computed in one network layer, however, a capable PCE may determine/suggest necessary reconfigurations in lower layer(s) in order to satisfy a particular path computation request; [dp] i would like to know how you have come to the second sentence statement - now more specifically, and in the context of the PCE discovery document, per [LSP-HIER] an incoming ERO may include the path to the lower SC, procedure is described in section 8.2 of that document so there is nothing wrong in that sentence it just need a clarification, that the sequence of hops resulting from this computation may be covering multiple LSP regions. IB>> Come on, we had this argument many times already. Note, first, that neither me nor the document mentioned the term "region". Furthermore, a PSC LSP does not "go" through a lambda layer, rather, it uses H-LSPs created in the lambda layer as PSC data links. === NH=> I am, quite frankly, amazed to find there are still some folks, like Dimitri apparently, who believe in the fairy-tale that you can create 'topology on the fly' in a set of layer networks. DP> neil, i just mention that the procedure for processing an ERO whose hops cover multiple regions is described in section 8.2 of [LSP-HIER]; so the issue is whether a PCE can be become a usable tool in the context of the CCAMP and MPLS signaling procedures then it needs to cover what these procedures have been defined as part of these documents otherwise one is going to be faced with the issue of a "GMPLS-capable PCE" that does not provides the expected GMPLS/MPLS capabilities - now, if for a set of reasons (to be discussed) this mechanism is abandoned it should be first reflected as part of the above mentioned document; at the end, the point, is afaik that the PCE WG is not chartered to revise or select the signaling procedures and mechanisms defined by the MPLS and CCAMP WG (but in case extend them to cover its needs) _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Jul 07 06:15:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqTQ6-00078l-9w; Thu, 07 Jul 2005 06:15:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqTQ5-00078d-SL for pce@megatron.ietf.org; Thu, 07 Jul 2005 06:15:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19293 for ; Thu, 7 Jul 2005 06:15:47 -0400 (EDT) From: neil.2.harrison@bt.com Received: from smtp5.smtp.bt.com ([217.32.164.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqTrF-0007kb-15 for pce@ietf.org; Thu, 07 Jul 2005 06:43:54 -0400 Received: from i2km99-ukbr.domain1.systemhost.net ([193.113.197.31]) by smtp5.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 7 Jul 2005 11:15:32 +0100 Received: from i2km07-ukbr.domain1.systemhost.net ([193.113.197.26]) by i2km99-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Thu, 7 Jul 2005 11:15:27 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] PCE Disco Reqs v01 Date: Thu, 7 Jul 2005 11:15:20 +0100 Message-ID: <0536FC9B908BEC4597EE721BE6A353890A9F1D85@i2km07-ukbr.domain1.systemhost.net> Thread-Topic: [Pce] PCE Disco Reqs v01 Thread-Index: AcWC0mXaL8MzrPeMSWuIgqwHjEX0IgAAgklA To: X-OriginalArrivalTime: 07 Jul 2005 10:15:27.0497 (UTC) FILETIME=[CBE29F90:01C582DC] X-Spam-Score: 0.3 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: quoted-printable Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Dimitri, > neil - see in-line because we are not discussing the same issue NH=3D> Its no use attempting to work on the roof of a house when the = walls and foundations are not in place...now please see below >=20 > =3D=3D=3D > 2. In section 5.1.3 you mentioned among GMPLS capabilities a=20 > capability to compute multi-layer paths. This sounds=20 > inaccurate: paths are always computed in one network layer,=20 > however, a capable PCE may determine/suggest necessary=20 > reconfigurations in lower layer(s) in order to satisfy a=20 > particular path computation request; >=20 > [dp] i would like to know how you have come to the second=20 > sentence statement - now more specifically, and in the=20 > context of the PCE discovery document, per [LSP-HIER] an=20 > incoming ERO may include the path to the lower SC, procedure=20 > is described in section 8.2 of that document so there is=20 > nothing wrong in that sentence it just need a clarification,=20 > that the sequence of hops resulting from this computation may=20 > be covering multiple LSP regions. >=20 > IB>> Come on, we had this argument many times already. Note,=20 > first, that > neither me nor the document mentioned the term "region".=20 > Furthermore, a PSC LSP does not "go" through a lambda layer,=20 > rather, it uses H-LSPs created in the lambda layer as PSC=20 > data links. =3D=3D=3D >=20 >=20 > NH=3D> I am, quite frankly, amazed to find there are still some=20 > folks, like Dimitri apparently, who believe in the fairy-tale=20 > that you can create 'topology on the fly' in a set of layer networks. >=20 > DP> neil, i just mention that the procedure for processing an=20 > ERO whose > hops cover multiple regions is described in section 8.2 of=20 > [LSP-HIER]; so the issue is whether a PCE can be become a=20 > usable tool in the context of the CCAMP and MPLS signaling=20 > procedures then it needs to cover what these procedures have=20 > been defined as part of these documents otherwise one is=20 > going to be faced with the issue of a "GMPLS-capable PCE"=20 > that does not provides the expected GMPLS/MPLS capabilities -=20 > now, if for a set of reasons (to be discussed) this mechanism=20 > is abandoned it should be first reflected as part of the=20 > above mentioned document; at the end, the point, is afaik=20 > that the PCE WG is not chartered to revise or select the=20 > signaling procedures and mechanisms defined by the MPLS and=20 > CCAMP WG (but in case extend them to cover its needs) NH=3D> Dimitri....Don't you think its a good idea to question whether something is valid or not before acting on it? It's not very wise IMO (esp for a supplier) to follow stuff blindly if either (i) you don't understand it and accept it on 'blind faith', or (worse) (ii) know its a nonsense but carry on regardless. And from your response above I'm not quite sure which case applies here.=20 Can I therefore ask you specifically: Do *you* believe (not what someone else has said) that we can have a common/single instance of routing across all network modes/technolgies such that on some client layer demand all the required layers below this are magically installed....because without this there is no topology basis in the client across which any routing decisions can be calculated. Noting that this remarkable routing instance must be capable of: digging trenches, laying ducts, installing fibres, installing optics/SDH/whatever nodes, setting up lambda paths (say) between SDH nodes (say), setting up VC4 paths (say) between VC12 (say) nodes, installing client X nodes and setting up VC12 paths between client X nodes, or whatever layer networks we wish to include in this list...right up to the client who wishes to place a demand. And this is even in a SINGLE operator case.....goodness know how you reconcile this when different operating parties own different layers. A simple yes or no answer will suffice. regards, Neil _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Jul 07 06:37:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqTl7-00024e-HE; Thu, 07 Jul 2005 06:37:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqTl6-00020I-GB for pce@megatron.ietf.org; Thu, 07 Jul 2005 06:37:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21023 for ; Thu, 7 Jul 2005 06:37:29 -0400 (EDT) From: Dimitri.Papadimitriou@alcatel.be Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqUCF-00040P-PR for pce@ietf.org; Thu, 07 Jul 2005 07:05:37 -0400 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id j67AbQDD020774; Thu, 7 Jul 2005 12:37:26 +0200 To: neil.2.harrison@bt.com Subject: RE: [Pce] PCE Disco Reqs v01 MIME-Version: 1.0 Date: Thu, 7 Jul 2005 12:37:19 +0200 Message-ID: X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.12HF788 | September 23, 2004) at 07/07/2005 12:37:25 Content-type: text/plain; charset=us-ascii X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Score: 0.3 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: Dimitri.Papadimitriou@alcatel.be, pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Neil > neil - see in-line because we are not discussing the same issue NH=> Its no use attempting to work on the roof of a house when the walls and foundations are not in place...now please see below > > === > 2. In section 5.1.3 you mentioned among GMPLS capabilities a > capability to compute multi-layer paths. This sounds > inaccurate: paths are always computed in one network layer, > however, a capable PCE may determine/suggest necessary > reconfigurations in lower layer(s) in order to satisfy a > particular path computation request; > > [dp] i would like to know how you have come to the second > sentence statement - now more specifically, and in the > context of the PCE discovery document, per [LSP-HIER] an > incoming ERO may include the path to the lower SC, procedure > is described in section 8.2 of that document so there is > nothing wrong in that sentence it just need a clarification, > that the sequence of hops resulting from this computation may > be covering multiple LSP regions. > > IB>> Come on, we had this argument many times already. Note, > first, that > neither me nor the document mentioned the term "region". > Furthermore, a PSC LSP does not "go" through a lambda layer, > rather, it uses H-LSPs created in the lambda layer as PSC > data links. === > > > NH=> I am, quite frankly, amazed to find there are still some > folks, like Dimitri apparently, who believe in the fairy-tale > that you can create 'topology on the fly' in a set of layer networks. > > DP> neil, i just mention that the procedure for processing an > ERO whose > hops cover multiple regions is described in section 8.2 of > [LSP-HIER]; so the issue is whether a PCE can be become a > usable tool in the context of the CCAMP and MPLS signaling > procedures then it needs to cover what these procedures have > been defined as part of these documents otherwise one is > going to be faced with the issue of a "GMPLS-capable PCE" > that does not provides the expected GMPLS/MPLS capabilities - > now, if for a set of reasons (to be discussed) this mechanism > is abandoned it should be first reflected as part of the > above mentioned document; at the end, the point, is afaik > that the PCE WG is not chartered to revise or select the > signaling procedures and mechanisms defined by the MPLS and > CCAMP WG (but in case extend them to cover its needs) NH=> Dimitri....Don't you think its a good idea to question whether something is valid or not before acting on it? It's not very wise IMO (esp for a supplier) to follow stuff blindly if either (i) you don't understand it and accept it on 'blind faith', or (worse) (ii) know its a nonsense but carry on regardless. And from your response above I'm not quite sure which case applies here. DP=> i am just say this goes beyond the scope of the PCE WG discussion on requirement for the discovery protocol requirements Can I therefore ask you specifically: Do *you* believe (not what someone else has said) that we can have a common/single instance of routing across all network modes/technolgies such that on some client layer demand all the required layers below this are magically installed....because without this there is no topology basis in the client across which any routing decisions can be calculated. Noting that this remarkable routing instance must be capable of: digging trenches, laying ducts, installing fibres, installing optics/SDH/whatever nodes, setting up lambda paths (say) between SDH nodes (say), setting up VC4 paths (say) between VC12 (say) nodes, installing client X nodes and setting up VC12 paths between client X nodes, or whatever layer networks we wish to include in this list...right up to the client who wishes to place a demand. And this is even in a SINGLE operator case.....goodness know how you reconcile this when different operating parties own different layers. DP=> what you depict here goes beyond what any unified or integrated approach has ever considered which is typically the trigger of a VC-4 upon a VC-12 incoming request or trigger a VC-4 upon an MPLS LSP request; what you describe here above is really caricaturing the picture, an integrated model is not meant to dig trenches or lay ducts or whatsoever; in brief, is not the definition of an unified or integrated TE model A simple yes or no answer will suffice. DP=> so it yes, but not based on your definition _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Jul 07 07:16:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqUN5-0003Ex-Dw; Thu, 07 Jul 2005 07:16:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqUN4-0003Dn-2w for pce@megatron.ietf.org; Thu, 07 Jul 2005 07:16:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24715 for ; Thu, 7 Jul 2005 07:16:42 -0400 (EDT) From: benjamin.niven-jenkins@bt.com Received: from smtp5.smtp.bt.com ([217.32.164.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqUoC-0004Kk-Ps for pce@ietf.org; Thu, 07 Jul 2005 07:44:51 -0400 Received: from i2km98-ukbr.domain1.systemhost.net ([193.113.197.85]) by smtp5.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 7 Jul 2005 12:16:33 +0100 Received: from i2km86-ukdy.domain1.systemhost.net ([193.113.30.79]) by i2km98-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Thu, 7 Jul 2005 12:16:33 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] PCE Disco Reqs v01 Date: Thu, 7 Jul 2005 12:17:14 +0100 Message-ID: Thread-Topic: [Pce] PCE Disco Reqs v01 Thread-Index: AcWC4CExkvRuaU01SeyUme8AnzQjHAAA3eYA To: , X-OriginalArrivalTime: 07 Jul 2005 11:16:33.0123 (UTC) FILETIME=[54C4C330:01C582E5] X-Spam-Score: 0.3 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: quoted-printable Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org > DP=3D> what you depict here goes beyond what any unified or=20 > integrated approach has ever considered which is typically=20 > the trigger of a VC-4 upon a VC-12 incoming request or=20 > trigger a VC-4 upon an MPLS LSP request; what you describe=20 > here above is really caricaturing the picture, an integrated=20 > model is not meant to dig trenches or lay ducts or=20 > whatsoever; in brief, is not the definition of an unified or=20 > integrated TE model Is this documented anywhere? It's been a while since I read through any GMPLS/PCE drafts in detail, but I don't remember the scope of the unified/integrated TE model being limited as you describe. Where does this stop? Are you saying that the scope is restricted such that one layer (e.g. MPLS) may only trigger a connection/trail setup event in its immediate server layer (e.g. VC-12)? Then what is to stop that immediate server layer (e.g. VC-12) triggering a connection/trail setup event in it's immediate server layer (e.g. VC-4) and so on? As you can see this 'one layer triggering events in a lower layer' behaviour is recursive to the duct (which I think is the point Neil was trying to make). Where is the line drawn and where is this 'line' documented? I would also question the commercials & economics of this approach, but that is another argument/discussion entirely. However if the economics/commercials don't add up then no operator in their right mind is going to deploy the unified/integrated TE model which I believe is the crux of Neil's point regarding not following things blindly without understanding its full impact. Ben --=20 Ben Niven-Jenkins Networking Specialist, BT Exact =20 =20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Jul 07 12:08:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqYv8-00050w-Q5; Thu, 07 Jul 2005 12:08:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqYv7-00050S-7H for pce@megatron.ietf.org; Thu, 07 Jul 2005 12:08:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21525 for ; Thu, 7 Jul 2005 12:08:10 -0400 (EDT) Received: from mail131.messagelabs.com ([216.82.242.99]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1DqZMD-0003B0-BU for pce@ietf.org; Thu, 07 Jul 2005 12:36:21 -0400 X-VirusChecked: Checked X-Env-Sender: dbrungard@att.com X-Msg-Ref: server-9.tower-131.messagelabs.com!1120752470!4595737!1 X-StarScan-Version: 5.4.15; banners=-,-,- X-Originating-IP: [192.128.134.71] Received: (qmail 25501 invoked from network); 7 Jul 2005 16:07:50 -0000 Received: from kcmso2.att.com (HELO kcmso2.proxy.att.com) (192.128.134.71) by server-9.tower-131.messagelabs.com with SMTP; 7 Jul 2005 16:07:50 -0000 Received: from attrh3i.attrh.att.com ([135.38.62.9]) by kcmso2.proxy.att.com (AT&T IPNS/MLO-6.0) with ESMTP id j67G7iTh025248 for ; Thu, 7 Jul 2005 11:07:50 -0500 Received: from OCCLUST04EVS1.ugd.att.com (135.38.164.13) by attrh3i.attrh.att.com (7.2.052) id 42BED27600236A7F; Thu, 7 Jul 2005 12:07:50 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] PCE Disco Reqs v01 Date: Thu, 7 Jul 2005 11:07:49 -0500 Message-ID: <449B2580D802A443A923DABF3EAB82AF09FBA23F@OCCLUST04EVS1.ugd.att.com> Thread-Topic: [Pce] PCE Disco Reqs v01 Thread-Index: AcWC4CExkvRuaU01SeyUme8AnzQjHAAA3eYAAAduvgA= From: "Brungard, Deborah A, ALABS" To: , , X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Content-Transfer-Encoding: quoted-printable Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi Ben, Neil, My take, Dimitri's and Igor's debate is on the semantics if a computation is one physical layer or multiple layers for a PSC LSP comprising FA-LSPs (consisting physically of one or more server layers) - especially for FAs dynamically triggered. On (physical) multi-layer computation, there's multiple documents covering GMPLS's integrated model including [3945]/8.3: Path computation may take into account region boundaries when computing a path for an LSP. For example, path computation may restrict the path taken by an LSP to only the links whose multiplexing/demultiplexing capability is PSC. When an LSP need to cross a region boundary, it can trigger the establishment of an FA at the underlying layer (i.e., the L2SC layer). This can trigger a cascading of FAs between layers with the following obvious order: L2SC, then TDM, then LSC, and then finally FSC. The PCE generic requirements also included, as a deployment service requirement, the need for multi-layer topology computation. And ASON (G8080 Am2/6.5) on multi-layer defines the same concept of a recursive control plane - and with no limits on recursion. Is your concern more on how to manage the control plane's resources and map the different TE information? This is the difficulty (for the operator)- not the protocol aspects for triggering/computation. And I agree without procedures (intra-domain and interdomain), the reality is questionable. Actual policies are out of scope of this work, is there text can add with more details on what's needed to ensure the pce can support? Deborah =20 -----Original Message----- From: pce-bounces@lists.ietf.org [mailto:pce-bounces@lists.ietf.org] On Behalf Of benjamin.niven-jenkins@bt.com Sent: Thursday, July 07, 2005 7:17 AM To: Dimitri.Papadimitriou@alcatel.be; neil.2.harrison@bt.com Cc: pce@ietf.org Subject: RE: [Pce] PCE Disco Reqs v01 > DP=3D> what you depict here goes beyond what any unified or=20 > integrated approach has ever considered which is typically=20 > the trigger of a VC-4 upon a VC-12 incoming request or=20 > trigger a VC-4 upon an MPLS LSP request; what you describe=20 > here above is really caricaturing the picture, an integrated=20 > model is not meant to dig trenches or lay ducts or=20 > whatsoever; in brief, is not the definition of an unified or=20 > integrated TE model Is this documented anywhere? It's been a while since I read through any GMPLS/PCE drafts in detail, but I don't remember the scope of the unified/integrated TE model being limited as you describe. Where does this stop? Are you saying that the scope is restricted such that one layer (e.g. MPLS) may only trigger a connection/trail setup event in its immediate server layer (e.g. VC-12)? Then what is to stop that immediate server layer (e.g. VC-12) triggering a connection/trail setup event in it's immediate server layer (e.g. VC-4) and so on? As you can see this 'one layer triggering events in a lower layer' behaviour is recursive to the duct (which I think is the point Neil was trying to make). Where is the line drawn and where is this 'line' documented? I would also question the commercials & economics of this approach, but that is another argument/discussion entirely. However if the economics/commercials don't add up then no operator in their right mind is going to deploy the unified/integrated TE model which I believe is the crux of Neil's point regarding not following things blindly without understanding its full impact. Ben --=20 Ben Niven-Jenkins Networking Specialist, BT Exact =20 =20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Jul 07 13:13:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqZwC-0004Ox-B6; Thu, 07 Jul 2005 13:13:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqZwA-0004O4-RG for pce@megatron.ietf.org; Thu, 07 Jul 2005 13:13:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26665 for ; Thu, 7 Jul 2005 13:13:19 -0400 (EDT) From: benjamin.niven-jenkins@bt.com Received: from smtp2.smtp.bt.com ([217.32.164.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqaNL-0002UA-HD for pce@ietf.org; Thu, 07 Jul 2005 13:41:30 -0400 Received: from i2km97-ukbr.domain1.systemhost.net ([193.113.197.30]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 7 Jul 2005 18:13:08 +0100 Received: from i2km86-ukdy.domain1.systemhost.net ([193.113.30.79]) by i2km97-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Thu, 7 Jul 2005 18:13:08 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] PCE Disco Reqs v01 Date: Thu, 7 Jul 2005 18:13:50 +0100 Message-ID: Thread-Topic: [Pce] PCE Disco Reqs v01 Thread-Index: AcWC4CExkvRuaU01SeyUme8AnzQjHAAA3eYAAAduvgAABQov4A== To: X-OriginalArrivalTime: 07 Jul 2005 17:13:08.0740 (UTC) FILETIME=[258CD440:01C58317] X-Spam-Score: 0.3 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Deborah et al, > Is your concern more on how to manage the control plane's=20 > resources and map the different TE information? I was merely supporting the assertion of my colleague that 'topology on the fly' will not work in reality for a variety of technical, operational, commercial and economic reasons. My comments were not specific to any particular piece of PCE or GMPLS related work (and are probably therefore out-of-scope of this discussion/mailing list in general). My personal view is that the peer/integrated model will not work and is not practical or deployable (except possibly on a very small scale). Topology must be driven using a bottom-up process where trails in a server layer must exist before link connections in a client layer can be provisioned. IMO the technical reasons against the peer/integrated model are just the tip of the iceberg, the operational, commercial and economic reasons are what really (and in my view unquestionably) will cause it to sink. I won't say any more on this topic as this probably isn't the right place for such a discussion. Ben --=20 Ben Niven-Jenkins Networking Specialist, BT Exact =20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Jul 07 13:35:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqaHN-00082G-Ij; Thu, 07 Jul 2005 13:35:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqaHM-00082B-3I for pce@megatron.ietf.org; Thu, 07 Jul 2005 13:35:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28104 for ; Thu, 7 Jul 2005 13:35:12 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqaiZ-0004w2-GH for pce@ietf.org; Thu, 07 Jul 2005 14:03:24 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 07 Jul 2005 10:34:52 -0700 X-IronPort-AV: i="3.93,270,1115017200"; d="scan'208"; a="293447338:sNHT1123050362" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j67HYoVX015220; Thu, 7 Jul 2005 10:34:50 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 7 Jul 2005 13:34:49 -0400 Received: from cisco.com ([10.86.242.240]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 7 Jul 2005 13:34:49 -0400 Date: Thu, 7 Jul 2005 13:33:54 -0400 From: Scott W Brim To: benjamin.niven-jenkins@bt.com Subject: Re: [Pce] PCE Disco Reqs v01 Message-ID: <20050707173354.GB2956@sbrim-wxp01> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-OriginalArrivalTime: 07 Jul 2005 17:34:49.0631 (UTC) FILETIME=[2CF10AF0:01C5831A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org On Thu, Jul 07, 2005 06:13:50PM +0100, benjamin.niven-jenkins@bt.com allegedly wrote: > Deborah et al, > > > Is your concern more on how to manage the control plane's > > resources and map the different TE information? > > I was merely supporting the assertion of my colleague that 'topology > on the fly' will not work in reality for a variety of technical, > operational, commercial and economic reasons. My comments were not > specific to any particular piece of PCE or GMPLS related work (and > are probably therefore out-of-scope of this discussion/mailing list > in general). Ben, as I said to your colleague a few weeks ago, even though you cannot dig trenches you can present available resources in different ways. Some client layers have a much easier time of allocating resources if the resources are presented to them already distinct, as opposed to having to manage the multiplexing themselves. So even though you cannot create lower layer diversity in an upper layer, you can create diversity for the layer(s) above you, and that does have merit. Scott _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Jul 07 14:48:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqbQb-0003Ql-1H; Thu, 07 Jul 2005 14:48:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqbQY-0003PI-Ps for pce@megatron.ietf.org; Thu, 07 Jul 2005 14:48:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07651 for ; Thu, 7 Jul 2005 14:48:49 -0400 (EDT) Received: from webmail.movaz.com ([65.205.166.188] helo=jera.movaz.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dqbrn-00061Z-IQ for pce@ietf.org; Thu, 07 Jul 2005 15:17:00 -0400 Received: from ib (unknown [172.16.24.122]) by jera.movaz.com (Postfix) with SMTP id F071416AE6; Thu, 7 Jul 2005 14:48:31 -0400 (EDT) Message-ID: <013201c58324$6dfdad50$7a1810ac@movaz.com> From: "Igor Bryskin" To: , References: <0536FC9B908BEC4597EE721BE6A353890A9F1D85@i2km07-ukbr.domain1.systemhost.net> Subject: Re: [Pce] PCE Disco Reqs v01 Date: Thu, 7 Jul 2005 14:48:09 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Content-Transfer-Encoding: 7bit Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Neil. I'd like to explain a bit more my views on the network topology management and why the discussion is IMO important in the PCE context. I agree that topology should be built bottom-up. I also think that path computation for a particular LSP (connection) should be constrained to the network layer where the LSP is provisioned, and it could succeed only if there is necessary network flexibility (at least one that is advertised) in this layer in place. However, provided that the same instance of control plane (e.g. GMPLS) manages multiple layers, and PCE has sufficient TE visibility, and TE link advertisements include such attributes as termination and adaptation capabilities, PCE could determine necessary reconfigurations in lower layer(s) in order to have original PCE request satisfied. This extra information could be used by a special application (let's call it Virtual Network Topology (VNT) Manager), which could verify that the specified re-configurations are, indeed, feasible, optimal, do not affect active services, do not cause network de-stabilization, etc. and instruct (if authorized) appropriate controllers to establish H-LSPs (trails) and advertise them as TE links. Only once the TE links are advertised, the original path computation request can succeed. Note that the H-LSPs could be virtual (not provisioned) or soft (resources are allocated but not bound into cross-connects, they are shared with other LSPs or even carry extra traffic) and become hard (that is, fully provisioned) when the Setup message of the first LSP they suppose to carry arrives on the H-LSP ingress nodes. The important thing is that TE links associated with such H-LSPs are advertised and available for the original path computation. The VNT manager also decides when the H-LSPs should be removed and associated TE links withdrawn, so that the network is not de-stabilized by frequent re-configurations. Hope this helps rather that brings more confusion. Igor ----- Original Message ----- From: To: Cc: ; Sent: Thursday, July 07, 2005 6:15 AM Subject: RE: [Pce] PCE Disco Reqs v01 Dimitri, > neil - see in-line because we are not discussing the same issue NH=> Its no use attempting to work on the roof of a house when the walls and foundations are not in place...now please see below > > === > 2. In section 5.1.3 you mentioned among GMPLS capabilities a > capability to compute multi-layer paths. This sounds > inaccurate: paths are always computed in one network layer, > however, a capable PCE may determine/suggest necessary > reconfigurations in lower layer(s) in order to satisfy a > particular path computation request; > > [dp] i would like to know how you have come to the second > sentence statement - now more specifically, and in the > context of the PCE discovery document, per [LSP-HIER] an > incoming ERO may include the path to the lower SC, procedure > is described in section 8.2 of that document so there is > nothing wrong in that sentence it just need a clarification, > that the sequence of hops resulting from this computation may > be covering multiple LSP regions. > > IB>> Come on, we had this argument many times already. Note, > first, that > neither me nor the document mentioned the term "region". > Furthermore, a PSC LSP does not "go" through a lambda layer, > rather, it uses H-LSPs created in the lambda layer as PSC > data links. === > > > NH=> I am, quite frankly, amazed to find there are still some > folks, like Dimitri apparently, who believe in the fairy-tale > that you can create 'topology on the fly' in a set of layer networks. > > DP> neil, i just mention that the procedure for processing an > ERO whose > hops cover multiple regions is described in section 8.2 of > [LSP-HIER]; so the issue is whether a PCE can be become a > usable tool in the context of the CCAMP and MPLS signaling > procedures then it needs to cover what these procedures have > been defined as part of these documents otherwise one is > going to be faced with the issue of a "GMPLS-capable PCE" > that does not provides the expected GMPLS/MPLS capabilities - > now, if for a set of reasons (to be discussed) this mechanism > is abandoned it should be first reflected as part of the > above mentioned document; at the end, the point, is afaik > that the PCE WG is not chartered to revise or select the > signaling procedures and mechanisms defined by the MPLS and > CCAMP WG (but in case extend them to cover its needs) NH=> Dimitri....Don't you think its a good idea to question whether something is valid or not before acting on it? It's not very wise IMO (esp for a supplier) to follow stuff blindly if either (i) you don't understand it and accept it on 'blind faith', or (worse) (ii) know its a nonsense but carry on regardless. And from your response above I'm not quite sure which case applies here. Can I therefore ask you specifically: Do *you* believe (not what someone else has said) that we can have a common/single instance of routing across all network modes/technolgies such that on some client layer demand all the required layers below this are magically installed....because without this there is no topology basis in the client across which any routing decisions can be calculated. Noting that this remarkable routing instance must be capable of: digging trenches, laying ducts, installing fibres, installing optics/SDH/whatever nodes, setting up lambda paths (say) between SDH nodes (say), setting up VC4 paths (say) between VC12 (say) nodes, installing client X nodes and setting up VC12 paths between client X nodes, or whatever layer networks we wish to include in this list...right up to the client who wishes to place a demand. And this is even in a SINGLE operator case.....goodness know how you reconcile this when different operating parties own different layers. A simple yes or no answer will suffice. regards, Neil _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Jul 07 14:51:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqbSn-0004aX-6K; Thu, 07 Jul 2005 14:51:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqbSk-0004WB-DB for pce@megatron.ietf.org; Thu, 07 Jul 2005 14:51:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07907 for ; Thu, 7 Jul 2005 14:51:04 -0400 (EDT) From: neil.2.harrison@bt.com Received: from smtp4.smtp.bt.com ([217.32.164.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dqbtx-0006LM-Pn for pce@ietf.org; Thu, 07 Jul 2005 15:19:15 -0400 Received: from i2km95-ukbr.domain1.systemhost.net ([193.113.197.29]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 7 Jul 2005 19:50:55 +0100 Received: from i2km07-ukbr.domain1.systemhost.net ([193.113.197.26]) by i2km95-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Thu, 7 Jul 2005 19:50:54 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] PCE Disco Reqs v01 Date: Thu, 7 Jul 2005 19:50:54 +0100 Message-ID: <0536FC9B908BEC4597EE721BE6A353890A9F1D89@i2km07-ukbr.domain1.systemhost.net> Thread-Topic: [Pce] PCE Disco Reqs v01 Thread-Index: AcWC4CExkvRuaU01SeyUme8AnzQjHAAA3eYAAAduvgAAA/730A== To: X-OriginalArrivalTime: 07 Jul 2005 18:50:54.0952 (UTC) FILETIME=[CE15BE80:01C58324] X-Spam-Score: 0.3 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Content-Transfer-Encoding: quoted-printable Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Deborah....you don't seriously still believe in this stuff do you? I wonder if you understood my original post? We CANNOT create topology on the fly...that is just a plain/obvious truth. But even if we ignore this fact there is still no strong commercial/service basis for adding a control-plane to these networks due to the long trail holding times required. Do the math on the business case for a reasonable BoD GoS and see what comes out...and remember, even here in the layer network which is under consideration for SVCs, all the kit both here and everything below this to the duct MUST be already in place.....we can't route across links that do not exist. To help, here's a big hint from our traffic/maths modelling folks: Post-demand delay needs to be of at least the same order as the expected holding time (hours/days/weeks/months?), and we don't have the laws of large numbers here nor any good information of calling/holding rates, so the modelling has to be quite general. =20 The lion's share of the issues are related to the management-plane anyway...and even if we add a control-plane this is still true, which may be very disappointing news to some folk (and I am well aware this a big area of concern for some operators, though we are fortunately not in this position). It does not apply for client/server layer network relationships when different operating parties are involved....which is THE critical base case to get right anyway. I would not want to try telling some of our major customers that they needed to peer (somehow) with our networks (not that my own folks would even allow this anyway) when all they wanted was a functionally decoupled network builder service from us. And this is all in addition to all the stuff I pointed about regarding the nonsense of topology on the fly. In our view the main reason why adding a control-plane to large BW co-cs mode networks is useful is to help automate provisioning under NMS control (ie S-PVCs) and resilience. If you have better reasons that you can justify then fine.....but I don't think folks should try and sell this on the back of some flawed notion that we can create topology on the fly across a set of layer networks from IP to Optics, as IMO this is starting to border on being 'somewhat economical with the truth'.=20 I normally don't bother responding to stuff in this area any more because we've done our homework and know what the score is here.....but I thought Igor might appreciate some support in trying to defend what Dimitri said, because I did detect at least one voice of reason here (though to reassure Igor, I know plenty of folks who do understand this stuff, and you are far from alone, at least in other quarters). Anyway, I'll leave you guys to it now..... regards, Neil > -----Original Message----- > From: Brungard, Deborah A, ALABS [mailto:dbrungard@att.com] > Sent: 07 July 2005 17:08 > To: Niven-jenkins,B,Ben,XDE73 R;=20 > Dimitri.Papadimitriou@alcatel.be; Harrison,N,Neil,IKM1 R > Cc: pce@ietf.org > Subject: RE: [Pce] PCE Disco Reqs v01 >=20 >=20 > Hi Ben, Neil, >=20 > My take, Dimitri's and Igor's debate is on the semantics if a > computation is one physical layer or multiple layers for a=20 > PSC LSP comprising FA-LSPs (consisting physically of one or=20 > more server layers) > - especially for FAs dynamically triggered. >=20 > On (physical) multi-layer computation, there's multiple > documents covering GMPLS's integrated model including=20 > [3945]/8.3: Path computation may take into account region=20 > boundaries when > computing a path for an LSP. For example, path computation may > restrict the path taken by an LSP to only the links whose > multiplexing/demultiplexing capability is PSC. When an LSP need to > cross a region boundary, it can trigger the establishment=20 > of an FA at > the underlying layer (i.e., the L2SC layer). This can trigger a > cascading of FAs between layers with the following obvious order: > L2SC, then TDM, then LSC, and then finally FSC. >=20 > The PCE generic requirements also included, as a deployment > service requirement, the need for multi-layer topology computation. >=20 > And ASON (G8080 Am2/6.5) on multi-layer defines the same > concept of a recursive control plane - and with no limits on=20 > recursion. >=20 > Is your concern more on how to manage the control plane's > resources and map the different TE information? This is the=20 > difficulty (for the > operator)- not the protocol aspects for=20 > triggering/computation. And I agree without procedures=20 > (intra-domain and interdomain), the reality is questionable.=20 > Actual policies are out of scope of this work, is there text=20 > can add with more details on what's needed to ensure the pce=20 > can support? >=20 > Deborah >=20 >=20 >=20 >=20 > =20 >=20 > -----Original Message----- > From: pce-bounces@lists.ietf.org > [mailto:pce-bounces@lists.ietf.org] On Behalf Of=20 > benjamin.niven-jenkins@bt.com > Sent: Thursday, July 07, 2005 7:17 AM > To: Dimitri.Papadimitriou@alcatel.be; neil.2.harrison@bt.com > Cc: pce@ietf.org > Subject: RE: [Pce] PCE Disco Reqs v01 >=20 > > DP=3D> what you depict here goes beyond what any unified or = integrated > > approach has ever considered which is typically the trigger of a=20 > > VC-4 upon a VC-12 incoming request or trigger a VC-4 upon an MPLS=20 > > LSP request; what you describe here above is really caricaturing the > > picture, an integrated model is not meant to dig trenches or lay=20 > > ducts or whatsoever; in brief, is not the definition of an unified=20 > > or integrated TE model >=20 > Is this documented anywhere? It's been a while since I read > through any GMPLS/PCE drafts in detail, but I don't remember=20 > the scope of the unified/integrated TE model being limited as=20 > you describe. >=20 > Where does this stop? Are you saying that the scope is > restricted such that one layer (e.g. MPLS) may only trigger a=20 > connection/trail setup event in its immediate server layer=20 > (e.g. VC-12)? Then what is to stop that immediate server=20 > layer (e.g. VC-12) triggering a connection/trail setup event=20 > in it's immediate server layer (e.g. VC-4) and so on? As you=20 > can see this 'one layer triggering events in a lower layer'=20 > behaviour is recursive to the duct (which I think is the=20 > point Neil was trying to make). Where is the line drawn and=20 > where is this 'line' documented? >=20 > I would also question the commercials & economics of this > approach, but that is another argument/discussion entirely. =20 > However if the economics/commercials don't add up then no=20 > operator in their right mind is going to deploy the=20 > unified/integrated TE model which I believe is the crux of=20 > Neil's point regarding not following things blindly without=20 > understanding its full impact. >=20 > Ben >=20 > -- > Ben Niven-Jenkins > Networking Specialist, BT Exact > =20 >=20 > =20 >=20 > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Jul 07 14:51:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqbSn-0004aw-HK; Thu, 07 Jul 2005 14:51:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqbSl-0004Yx-WC for pce@megatron.ietf.org; Thu, 07 Jul 2005 14:51:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07910 for ; Thu, 7 Jul 2005 14:51:06 -0400 (EDT) From: neil.2.harrison@bt.com Received: from smtp4.smtp.bt.com ([217.32.164.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dqbtz-0006LM-So for pce@ietf.org; Thu, 07 Jul 2005 15:19:17 -0400 Received: from i2km95-ukbr.domain1.systemhost.net ([193.113.197.29]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 7 Jul 2005 19:50:55 +0100 Received: from i2km07-ukbr.domain1.systemhost.net ([193.113.197.26]) by i2km95-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Thu, 7 Jul 2005 19:50:55 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] PCE Disco Reqs v01 Date: Thu, 7 Jul 2005 19:50:54 +0100 Message-ID: <0536FC9B908BEC4597EE721BE6A353890A9F1D8A@i2km07-ukbr.domain1.systemhost.net> Thread-Topic: [Pce] PCE Disco Reqs v01 Thread-Index: AcWDGldGA3r49+fCTFGC+ju6Da+oUgACA3Vg To: , X-OriginalArrivalTime: 07 Jul 2005 18:50:55.0171 (UTC) FILETIME=[CE372930:01C58324] X-Spam-Score: 0.3 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: quoted-printable Cc: pce@ietf.org, alan.mcguire@bt.com X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi Scott.... > Ben, as I said to your colleague a few weeks ago, even though=20 > you cannot dig trenches you can present available resources=20 > in different ways. NH=3D> Can you please explain the scope/size of these idle resources (noting that if they are not free you cannot use them), and who is paying for them, that are sitting around waiting to be used? Have you actually tried to model this situation? We have. In any case, the technical observations I gave on how one builds a given layer network's topology are accurate. You know Alan McGuire here well, so if you want a second opinion please talk to him. I'll copy Alan in so he is aware. > Some client layers have a much easier=20 > time of allocating resources if the resources are presented=20 > to them already distinct, as opposed to having to manage the=20 > multiplexing themselves. NH=3D> Not sure I get this point. Muxing belongs to the client->server adaptation process.....but its the server that defines the muxing regime (which is quite different for different network modes/technologies). In any case, the prior point remains, ie to what level of redundancy are you willing to build out the server layer network so that a given client on-demand request can be met in a *reasonable* time period? For you as a vendor this is not a problem, for me as an operator its a very important issue. > So even though you cannot create=20 > lower layer diversity in an upper layer, you can create=20 > diversity for the layer(s) above you, and that does have merit. NH=3D> This is a difference topic, ie that of performance and = availability inheritance. Can go here if you want....big topic. regards, Neil >=20 > Scott >=20 > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Jul 07 21:30:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dqhgr-0001q6-DW; Thu, 07 Jul 2005 21:30:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dqhgp-0001oT-B4 for pce@megatron.ietf.org; Thu, 07 Jul 2005 21:30:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23876 for ; Thu, 7 Jul 2005 21:30:01 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dqi85-0000YQ-Lv for pce@ietf.org; Thu, 07 Jul 2005 21:58:16 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 07 Jul 2005 18:29:53 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,272,1115017200"; d="scan'208,217"; a="927647:sNHT35360668" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j681Tpk6007491; Thu, 7 Jul 2005 21:29:51 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 7 Jul 2005 21:29:41 -0400 Received: from [192.168.1.100] ([10.86.240.250]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 7 Jul 2005 21:29:51 -0400 Mime-Version: 1.0 (Apple Message framework v730) References: <7368E622-DB56-40F7-A235-7FEBCEC3D962@cisco.com> Message-Id: <769F50C5-7C19-49AC-9E58-0212AE07B0E8@cisco.com> From: JP Vasseur Date: Thu, 7 Jul 2005 21:30:11 -0400 To: "ALABS Ash Gerald R ((Jerry))" , LE ROUX Jean-Louis RD-CORE-LAN X-Mailer: Apple Mail (2.730) X-OriginalArrivalTime: 08 Jul 2005 01:29:51.0217 (UTC) FILETIME=[8935EE10:01C5835C] X-Spam-Score: 0.2 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: pce@ietf.org Subject: [Pce] Fwd: Missing Requirement in draft-ietf-pce-comm-protocol-gen-reqs-00.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1149091579==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org --===============1149091579== Content-Type: multipart/alternative; boundary=Apple-Mail-77-745090573 --Apple-Mail-77-745090573 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit resending. JP. Begin forwarded message: > From: JP Vasseur > Date: July 5, 2005 5:28:37 PM EDT > To: "ALABS Ash Gerald R ((Jerry))" , LE ROUX Jean- > Louis RD-CORE-LAN > Cc: Adrian Farrel > Subject: Missing Requirement in draft-ietf-pce-comm-protocol-gen- > reqs-00.txt > > > Dear DT, > > During a discussion that I had with Adrian, I noticed that there > was no requirement for PCE communication protocol to support the > ability to request a TE LSP path reoptimization. If the path of an > existing TE LSP to be reoptimized is not provided to a stateless > PCE, then this may lead to sub-optimal routing and thus in no > reoptimization of the existing path although a more optimal path > may exist. > > Isn't a requirement to able to support reoptimization requests > whereby the head-end has the ability to provide the existing path ? > > Thanks. > > JP. > --Apple-Mail-77-745090573 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable resending.

JP.

Begin = forwarded message:

From: = JP Vasseur <jvasseur@cisco.com>
=
Date: = July 5, 2005 5:28:37 PM EDT
To: "ALABS = Ash Gerald R ((Jerry))" <gash@att.com>, LE ROUX Jean-Louis = RD-CORE-LAN <jeanlouis.leroux@france= telecom.com>
Cc: Adrian Farrel <adrian@olddog.co.uk>
Subject: = Missing Requirement in = draft-ietf-pce-comm-protocol-gen-reqs-00.txt


Dear = DT,

During a discussion that I had with Adrian, I = noticed that there was no requirement for PCE communication protocol to = support the ability to request a TE LSP path reoptimization. If the path = of an existing TE LSP to be reoptimized is not provided to a stateless = PCE, then this may lead to sub-optimal routing and thus in no = reoptimization of the existing path although a more optimal path may = exist.

Isn't a requirement to able to support = reoptimization requests whereby the head-end has the ability to provide = the existing path ?
Thanks.


= --Apple-Mail-77-745090573-- --===============1149091579== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============1149091579==-- From pce-bounces@lists.ietf.org Fri Jul 08 03:41:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqnTo-0002rH-CL; Fri, 08 Jul 2005 03:41:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqnTl-0002r4-P7 for pce@megatron.ietf.org; Fri, 08 Jul 2005 03:40:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06488 for ; Fri, 8 Jul 2005 03:40:56 -0400 (EDT) Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dqnv5-0001Rp-FX for pce@ietf.org; Fri, 08 Jul 2005 04:09:13 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Fri, 8 Jul 2005 09:40:15 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE : [Pce] PCE Disco Reqs v01 Date: Fri, 8 Jul 2005 09:40:12 +0200 Message-ID: Thread-Topic: [Pce] PCE Disco Reqs v01 Thread-Index: AcWCQPUN4K4VTG2YTC2PW6EgN+HMiABSGniA From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "Igor Bryskin" , X-OriginalArrivalTime: 08 Jul 2005 07:40:15.0801 (UTC) FILETIME=[48185290:01C58390] X-Spam-Score: 0.9 (/) X-Scan-Signature: 4b6c13497db1e4e7b275c86cfcdad7bb Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1267769381==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1267769381== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C58390.47E57FD8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C58390.47E57FD8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Igor =20 Thanks for these useful comments/suggestions =20 Please see inline, =20 =20 -----Message d'origine----- De : Igor Bryskin [mailto:ibryskin@movaz.com]=20 Envoy=E9 : mercredi 6 juillet 2005 17:40 =C0 : LE ROUX Jean-Louis RD-CORE-LAN; pce@ietf.org Objet : Re: [Pce] PCE Disco Reqs v01 JL. =20 I have a couple of questions/comments. =20 1. On more than one occasions you use the term "TE-LSP path computation = request". This sounds like an assumption that paths are computed = separately for each TE-LSP. In reality, though, a single path = computation request for a protected service is expected to determine = paths for multiple LSPs (working and protecting). Furthermore, a single = path computation may be performed for multiple services to make them = possible sharing protection resources. I would suggest dropping the = "TE-LSP" from the "TE-LSP path computation" combination; =20 [JLLR] This is a valid point, I will update as per your proposal=20 =20 2. In section 5.1.3 you mentioned among GMPLS capabilities a capability = to compute multi-layer paths. This sounds inaccurate: paths are always = computed in one network layer, however, a capable PCE may = determine/suggest necessary reconfigurations in lower layer(s) in order = to satisfy a particular path computation request; [JLLR] I'm not sure I follow you here. The PCE may be aware of topology = in multiple layers and compute a multi-layer path. As per defined in LSP-HIER an ERO can contain elements with distinct = ISCs. Actually this will trigger LSP nesting at region boundaries.=20 But I agree with you that "this may require the PCE to = determine/suggest necessary reconfigurations in lower layer(s) in order = to satisfy a particular path computation request"; This is actually what = we call VNT reconfiguration in MRN. Also note that the objective here in this doc is not to explain the = capabilities, this will actually be done in a separate document. =20 3. I believe it should be stated more clearly that 2 stages of PCE = discovery are needed: basic stage and detailed stage. During the basic = stage PCE publishes some basic information about itself (presence, = computation scope, etc.) on the network independently from PCCs. = Interested PCCs should be able to participate in the detailed discovery = stage, that is, to establish communication sessions (via PCC-PCE or a = separate protocol) with the PCE to request/subscribe on the PCE detailed = information (capability, CPU power, capacity, status, etc.). This would = be good IMO both from the scalability and security points of view. [JLLR] Note that this is already partially addressed in the capability = section: " It is paramount that dynamic capability discovery MUST NOT generate=20 an excessive amount of information... =20 If required, the exhaustive discovery of detailed capabilities could be = ensured by means of the PCC-PCE communication protocol. Actually a tradeoff should be found between capability discovery by the = PCE discovery mechanism and by the PCC-PCE communication protocol. One = of the objectives of the PCE discovery mechanism is to help PCCs to = select appropriate PCEs and limit the likelihood of PCC-PCE = communication rejections that may occur in case a PCE cannot support a = given capability. "=20 =20 I intend to agree with your proposal, but this may be too solution = oriented=20 "Interested PCCs should be able to participate in the detailed discovery = stage, that is, to establish communication sessions (via PCC-PCE or a = separate protocol) with the PCE to request/subscribe on the PCE detailed = information (capability, CPU power, capacity, status, etc.). This would = be good IMO both from the scalability and security points of view." Why mandating the use of a PCC-PCE communication sessions for detailed = discovery? This may be too solution oriented. One could argue that this = may not scale, as you would have to setup a session with all PCEs in = order to now their capabilities and that this could rather be done more = efficiently thanks to IGP flooding, using a set of bit flags, at least = for simple capabilities... =20 Hence, what about saying that there are too stages in PCE discovery = (Basic, detailed...) that can be ensured either with the same discovery = mechanism or using distinct mechnanisms? =20 =20 4. Responding to your questions: -Is there a need for the discovery of PCE capacity in terms of =20 computation power? This static parameter could be used to =20 ensure weighted load balancing of requests in case PCEs do not = have the same capacity.=20 Yes. It could be achieved by a direct request from a PCC during the = detailed discovery stage (see above). [JLLR] So you consider that this necessarily requires a PCC-PCE session? One could argue that this may also be done in an efficient way thanks to = IGP flooding: For instance one could argue that a flag flooded into the IGP, is more = efficient than N notifications sent by a PCE to its N PCCs using a = PCC-PCE communication session... -Would it be useful that a PCE report its status as "congested" = in case it is too busy? PCCs may then use this dynamic =20 information to prefer a different PCE. =20 Yes. It could be achieved by a subscription of a PCC on the PCE's status = change (also during the detailed discovery stage ). [JLLR] Same remark =20 Thanks a lot for these valuable comments, =20 Regards =20 JL=20 =20 Cheers, Igor =20 ----- Original Message -----=20 From: LE ROUX Jean-Louis = RD-CORE-LAN=20 To: pce@ietf.org=20 Sent: Wednesday, June 29, 2005 8:00 AM Subject: [Pce] PCE Disco Reqs v01 Hi all,=20 Version 01 of the PCE discovery reqs ID has just been published=20 = = http://www.ietf.org/internet-drafts/draft-leroux-pce-discovery-reqs-01.tx= t=20 This version takes into account comments received during Minneapolis = session and on the list.=20 Here are the major changes since 00:=20 -Added multi-area network case in the problem statement=20 -Added application scenario (section 4)=20 -Section 5.1 on capability discovery modified as per discussions on the = list:=20 -Discovery of PCE location, PCE scopes and domain(s) under = control is mandatory=20 -Capability discovery is no longer a MUST=20 The list of capabilities is now out of the scope and should be = addressed in a=20 separate document.=20 =20 -Added section 5.6 on extensibility=20 -Added Security section=20 Section 5.5 (Discovery of PCE capacity and congestion) requires WG = feedback:=20 -Is there a need for the discovery of PCE capacity in terms of = computation power? This static parameter could be used to ensure = weighted load balancing of requests in case PCEs do not have the same = capacity.=20 -Would it be useful that a PCE report its status as "congested" in case = it is too busy? PCCs may then use this dynamic information to prefer a = different PCE.=20 Your comments/feedback would be highly welcome, especially on the above = point=20 Best Regards,=20 JL=20 _____ =20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce ------_=_NextPart_001_01C58390.47E57FD8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
Hi=20 Igor
 
Thanks=20 for these useful comments/suggestions
 
Please=20 see inline,
 
 
-----Message d'origine-----
De : Igor Bryskin=20 [mailto:ibryskin@movaz.com]
Envoy=E9 : mercredi 6 = juillet 2005=20 17:40
=C0 : LE ROUX Jean-Louis RD-CORE-LAN;=20 pce@ietf.org
Objet : Re: [Pce] PCE Disco Reqs=20 v01

JL.
 
I have a couple of=20 questions/comments.
 
1. On more than one occasions = you use the=20 term "TE-LSP path computation request". This sounds like an assumption = that=20 paths are computed separately for each TE-LSP. In reality, though, a = single=20 path computation request for a protected service is expected to = determine=20 paths for multiple LSPs (working and protecting). Furthermore, a = single path=20 computation may be performed for multiple services to make them=20 possible sharing protection resources. I would suggest dropping = the=20 "TE-LSP" from the "TE-LSP path computation" combination;
 
[JLLR] This is a = valid=20 point, I will update as per your=20 proposal 
 
2. In section 5.1.3 you = mentioned among=20 GMPLS capabilities a capability to compute multi-layer paths. This = sounds=20 inaccurate: paths are always computed in one network layer, however, a = capable=20 PCE may determine/suggest necessary reconfigurations in lower layer(s) = in=20 order to satisfy a particular path computation request;
[JLLR] I'm not = sure I follow=20 you here. The PCE may be aware of topology in multiple layers and = compute=20 a multi-layer path.
As per defined in LSP-HIER an ERO can contain = elements with=20 distinct ISCs. Actually this=20 will trigger LSP nesting at region=20 boundaries. 
But I agree with you that "this may require the = PCE=20 to  determine/suggest necessary = reconfigurations in lower layer(s) in order to satisfy a particular = path=20 computation request"; This is actually what we call VNT = reconfiguration in=20 MRN.
Also note that the objective here in this doc is = not to=20 explain the capabilities, this will actually be done in a = separate=20 document.
 
3. I believe it should be = stated more=20 clearly that 2 stages of PCE discovery are needed: basic stage = and=20 detailed stage. During the basic stage PCE publishes some basic = information=20 about itself (presence, computation scope, etc.) on the network = independently=20 from PCCs. Interested PCCs should be able to participate in the = detailed=20 discovery stage, that is, to establish communication sessions (via = PCC-PCE or=20 a separate protocol) with the PCE to request/subscribe on the PCE = detailed=20 information (capability, CPU power, capacity, status, etc.). This = would be=20 good IMO both from the scalability and security points of = view.
[JLLR] Note = that this=20 is already partially addressed in the capability=20 section:

" It is paramount that dynamic = capability=20 discovery MUST NOT generate

an excessive=20 amount of information...  

 If = required, the=20 exhaustive discovery of detailed capabilities could be ensured by = means of the=20 PCC-PCE communication = protocol.

Actually a=20 tradeoff should be found between capability discovery by the PCE = discovery=20 mechanism and by the PCC-PCE communication protocol. One of the = objectives of=20 the PCE discovery mechanism is to help PCCs to select appropriate PCEs = and=20 limit the likelihood of PCC-PCE communication rejections that may = occur in=20 case a PCE cannot support a given capability. " 

=

=  

I intend to agree with your proposal, but this may be too solution = oriented=20

"Interested PCCs=20 should be able to participate in the detailed discovery stage, that = is, to=20 establish communication sessions (via PCC-PCE or a separate protocol) = with the=20 PCE to request/subscribe on the PCE detailed information (capability, = CPU=20 power, capacity, status, etc.). This would be good IMO both from the=20 scalability and security points of=20 = view."

Why mandating the use of a = PCC-PCE=20 communication sessions for detailed discovery? This may be too = solution=20 oriented. One could argue that this may not scale, as = you would have=20 to setup a session with all PCEs in order to now their capabilities = and that=20 this could rather be done more efficiently thanks to IGP = flooding, using=20 a set of bit flags, at least for simple=20 = capabilities...

 

Hence, what about saying = that there are=20 too stages in PCE discovery (Basic, detailed...) that can be = ensured=20 either with the same discovery mechanism or using distinct=20 = mechnanisms?

 
 
4. Responding to your = questions:
        -Is there a need for = the=20 discovery of PCE capacity in terms of =20
         computation = power? This=20 static parameter could be used to =20
         ensure weighted = load=20 balancing of requests in case PCEs do not =20
         have the same = capacity.=20
Yes. It could be achieved by a direct request from a PCC during = the=20 detailed discovery stage (see above).
[JLLR] So you consider = that this=20 necessarily requires a PCC-PCE session?
One=20 could argue that this may also be done in an efficient = way thanks to=20 IGP flooding:
For=20 instance one could argue that a flag flooded into the IGP, is = more=20 efficient than N notifications sent by a PCE to its N PCCs using=20 a PCC-PCE communication session...

        -Would = it be=20 useful that a PCE report its status as "congested" =20
         in case it is too = busy?=20 PCCs may then use this dynamic =20
         information to = prefer a=20 different PCE. 
Yes. It could be achieved by a subscription of a PCC on the = PCE's=20 status change (also during the detailed discovery stage ).
[JLLR] Same remark
 
Thanks a lot for these valuable comments,
 
Regards
 
JL 
 
Cheers,
Igor
 
----- Original Message -----
From:=20 LE ROUX = Jean-Louis=20 RD-CORE-LAN
Sent: Wednesday, June 29, = 2005 8:00=20 AM
Subject: [Pce] PCE Disco Reqs = v01

Hi all,

Version 01 of the PCE = discovery reqs ID=20 has just been published
http://www.ietf.org/internet-drafts/draft-leroux-pce-discovery-r= eqs-01.txt=20

This version takes into = account comments=20 received during Minneapolis session and on the list.

Here are the major changes = since=20 00:
-Added multi-area = network=20 case in the problem statement
-Added application scenario (section 4)
-Section 5.1 on capability discovery = modified as=20 per discussions on the list:=20
        -Discovery of PCE location, PCE scopes and domain(s) under = control is=20 mandatory
        = -Capability discovery is no longer a = MUST=20
       The=20 list of capabilities is now out of the scope and should be addressed = in a=20
       separate = document.=20
      =20
-Added section 5.6 on = extensibility
-Added = Security=20 section

Section 5.5 (Discovery of PCE = capacity=20 and congestion) requires WG feedback:
-Is = there a need=20 for the discovery of PCE capacity in terms of computation power? = This static=20 parameter could be used to ensure weighted load balancing of = requests in=20 case PCEs do not have the same capacity.

-Would it be useful that a = PCE report its=20 status as "congested" in case it is too busy? PCCs may then use this = dynamic=20 information to prefer a different PCE.

Your comments/feedback would = be highly=20 welcome, especially on the above point

Best Regards,

JL

_______________________________________________
Pce = mailing=20 = list
Pce@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce<= BR>
------_=_NextPart_001_01C58390.47E57FD8-- --===============1267769381== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============1267769381==-- From pce-bounces@lists.ietf.org Fri Jul 08 04:56:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dqoea-00028H-Cy; Fri, 08 Jul 2005 04:56:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqoeV-00022L-IZ for pce@megatron.ietf.org; Fri, 08 Jul 2005 04:56:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11748 for ; Fri, 8 Jul 2005 04:56:05 -0400 (EDT) From: neil.2.harrison@bt.com Received: from smtp2.smtp.bt.com ([217.32.164.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dqp5r-0000i2-BA for pce@ietf.org; Fri, 08 Jul 2005 05:24:24 -0400 Received: from i2km97-ukbr.domain1.systemhost.net ([193.113.197.30]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 8 Jul 2005 09:55:56 +0100 Received: from i2km07-ukbr.domain1.systemhost.net ([193.113.197.26]) by i2km97-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Fri, 8 Jul 2005 09:55:56 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] PCE Disco Reqs v01 Date: Fri, 8 Jul 2005 09:55:56 +0100 Message-ID: <0536FC9B908BEC4597EE721BE6A353890A9F1D8B@i2km07-ukbr.domain1.systemhost.net> Thread-Topic: [Pce] PCE Disco Reqs v01 Thread-Index: AcWDJHx6VmNwZx26RvyS1jRkjVrq6gAATJPQ To: , X-OriginalArrivalTime: 08 Jul 2005 08:55:56.0533 (UTC) FILETIME=[DA950A50:01C5839A] X-Spam-Score: 0.3 (/) X-Scan-Signature: 7118f330e2af0a096ba071c5e99ca10e Content-Transfer-Encoding: quoted-printable Cc: pce@ietf.org, alan.mcguire@bt.com X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Thanks Igor..... Please see in-line. > I'd like to explain a bit more my views on the network > topology management and why the discussion is IMO important=20 > in the PCE context. NH=3D> OK >=20 > I agree that topology should be built bottom-up. NH=3D> Well, no arguments from me as 'it's obviously true'. However, I have to emphasise that when creating topology in a set of nested layer networks this cannot be driven solely by some idealistic 'common control plane mindset'.....I know this is how the idea (of working on non-cl-ps technologies) has been 'sold' to IETF to justify doing this stuff here, but there are some crucial issues relating to: - the basic economics of network design (see my comments on GoS design in previous mails, and its something I will return to repeatedly below because its so important)...remember - someone has to ultimately pay real money for this stuff - the differences between the 3 major modes of networking.....these differences are actually the important bits....which means we cannot have a truly 'common' approach in all cases if we want to exploiut these differences to maximum advantage - the fact that for both scaling reasons and operating reasons (which also contains facets like security and legal/regulatory considerations for major opreators) functionally decoupled client/server relationships are an ESSENTIAL starting point. This is what I was referring to in my earlier mail on a 'network builder capability'. And whilst this is ALWAYS achievable in the co-cs mode (purely due to the modal constraints here)...and BTW this is also true for the cl-ps mode..... this can be made NOT so in the co-ps mode if a digital wrapper idea is used to create 'hierarchy' (which is precisely why folks are now hitting problems with the multi-hop PW stuff based on MPLS). So when we create topology using client/server layer network relationships we MUST bear the above points in mind. Now if I was to make some very general observations on the architectural/commercial design rules that should govern our thinking here, they would run along these lines: - don't try and seek complete functional convergence across all 3 networking modes....use their differences wisely to solve (what could be) otherwise very hard problems (like QoS, security, etc) - don't have lots of technologies belonging to the SAME mode....as they will simply be replicating each other's modus operandi and it will lead to (i) the so-called stove-pipe problem (ie a vertically complete (ie inc NMS/OSS) networking platform where 'the technology' effectively becomes 'the service' and (ii) nasty peer-partition interworking/migration problems - recognise that as we move down towards the duct the holding-times of trails will, of necessity, increase.....the converse is also true - recognise that as we move down towards the duct the 'routing' function becomes far less important than in the higher layer networks.....or more generally, there is less need for a control-plane than having a good management-plane story. This does NOT mean we don't need a control-plane here, eg signalling is a useful function, but the time constants of the topology here are such (ie long of commercial necessity) that the routing function (whilst still required) is far less important than other components > I also think > that path computation for a particular LSP (connection)=20 > should be constrained to the network layer where the LSP is=20 > provisioned, NH=3D> Yes, agreed again. This is indeed a critical design requirement, ie we MUST always be able to run each layer network independently from other layer networks. This is also a clear recognition that there cannot be a singular control-plane...or more accurately a singular routing instance (which, by definition, means there is no single 'addressing' instance across each of the layer networks). > and it could succeed only if there is necessary=20 > network flexibility (at least one that is advertised) in this=20 > layer in place. NH=3D> See my response to Scott. But to summarise.....Who is actually paying for all this idle BW at some layer N, and below which we agree (as per above) everything from here on down MUST already be in place? >=20 > However, provided that the same instance of control plane=20 > (e.g. GMPLS) manages multiple layers, NH=3D> I have no problem with re-using the best-of-breed functional components in each networking mode WHERE this is applicable, eg use the same *base* signalling protocol and OOB solution for both the co-cs and co-ps modes (the word 'base' is highlighted here to indicate that the message set is not identical for each mode).....in fact I strongly encourage this type of practice. Where I do object however is when folks try and tell me there is a 'common' instance of functional components running from top to bottom. This will neither work well per se nor does it satisfy important commercial and operational requirements. > and PCE has sufficient=20 > TE visibility, and TE link advertisements include such=20 > attributes as termination and adaptation capabilities, PCE=20 > could determine necessary reconfigurations in lower > layer(s) in order to have original PCE request satisfied. NH=3D> This seems to be asking me as an operator to build out some = server layer networks with lots of capacity just so as we can prove that a given client can present some ad hoc demand to those server layer and have it satisfied right? And, as you agreed at the outset, below *this* layer network (wherever this is) everything else must be already hard provisioned.....because, as we agreed, topology is created from the duct upward. Not only do I think this is commercially unrealistic without some idea of the GoS one could realistically achieve (I have to pay to build this GoS remember), I think it is underestimating (and very much so) the impact, and relationship with, the management-plane. I would strongly advise having a talk to the folks in large operators who are responsible for running and *paying* for their major transport networks (eg SDH) rather than the folks from more of a 'R&D' background in those operators....you may get a very different perspective on what is important here and what is not. =20 > This extra information could be used by a special application=20 > (let's call it Virtual Network Topology (VNT) Manager), which=20 > could verify that the specified re-configurations are,=20 > indeed, feasible, optimal, do not affect active services, do=20 > not cause network de-stabilization, etc. NH=3D> If I was being slightly cynical here I could say 'This reads like the dawning of the realisation that it's network management that is key here'. > and instruct (if > authorized) appropriate controllers to establish H-LSPs=20 > (trails) and advertise them as TE links.=20 NH=3D> I've never understood what these 'TE links' are......they are woolly defined at best IMO. What you appear to be describing is basic G.805 stuff (if I have this right), ie you are creating a link in client layer network using trails of some server layer network. Fine, nothing wrong with that. But I'm sensing some desperation here to find a role for this GMPLS stuff that has been generated. For example, if client layer network X does not need capacity during time T we can reallocate that capacity to client layer Y. Sounds nice in principle....ain't so simple in practice (for many reasons, esp wrt the costs associated with providing some *acceptable* on-demand GoS). And as I observed earlier, this looks to me as though its the dawning of the realisation that network management is the key issue here....which of course it is. > Only once the TE=20 > links are advertised, the original path computation request=20 > can succeed. NH=3D> Very much so....at least wrt to my understanding of what 'TE = links' ought to mean in practice, ie you can't calculate routes over a topology that does not exist. But this all comes back to 'in which layer network does the hard provisioning start?' And then 'to what level of (client) on-demand GoS is *that* server layer network supposed to be designed against?' And do you really think we need a control-plane solution to provide this as we approach the duct (given the current realities of commercial models of BoD)? And what about client/server relationships between different parties? I actually think this work is now clutching at straws to justify its continued existence. Nice theoretical work perhaps....and I could postulate some future where certain *public* services in end-systems (based on large file transfer or stream applications say) might be able to call-up some simple on-demand SVCs in some co-cs or co-ps (here CBR-like) layer network (think of it as BB PSTN if you like)....now that scenario might warrant closer scutinity (in fact I'd say this is an area well worth looking at as it will address some otherwise very hard QoS/pricing problems that will not be satisfactorily solved by current direction). However, as a private network builder service capability in today's environment....whether this is aimed at self-owned or other-party-owned client layer networks.....I don't think this is currently that viable. However it does seem to be the basis on which you would sell this notion right now. > Note that the H-LSPs could be virtual (not=20 > provisioned) or soft (resources are allocated but not bound=20 > into cross-connects, they are shared with other LSPs or even=20 > carry extra > traffic) and become hard (that is, fully provisioned) when=20 > the Setup message of the first LSP they suppose to carry=20 > arrives on the H-LSP ingress nodes. NH=3D> Yes, but have you done the business case to warrant the build-out creation of these underpinning transport layer networks that are there sitting there idle waiting to satisfy these hopeful client layer demands? I was talking about this topic to one of my colleagues who has done this type of study here in BT and we might see if we can publish some of our findings. > The important thing is=20 > that TE links associated with such H-LSPs are advertised and=20 > available for the original path computation. The VNT manager=20 > also decides when the H-LSPs should be removed and associated=20 > TE links withdrawn, so that the network is not de-stabilized=20 > by frequent re-configurations. NH=3D> Withdrawn?! I'll believe it when I see it. IMO, no IM STRONG O, if you provide some server layer capacity to a given client layer network you will NEVER withdraw it (not unless the client is in decline).....as it impacts that client layer's topology and what it (ie the client layer network) does with route calculations from this moment onwards. >=20 > Hope this helps rather that brings more confusion. NH=3D> I think your engineering heart is in the right place Igor. But I think the commercial justifications are misplaced. I don't know why we can't have a simpler model of where we want to head wrt networking. I have a fairly clear model in my mind of what this ought to look like (so we can all benefit), where all 3 networking modes work in concert across private and public services, but I think we are some way off acheiving this. Maybe for another day a few years hence. In the meantime, I'd suggest sitting down with the folks in large operators who are really responsible for operating/designing and paying for these major transport networks. regards, Neil >=20 > Igor >=20 > ----- Original Message -----=20 > From: > To: > Cc: ; > Sent: Thursday, July 07, 2005 6:15 AM > Subject: RE: [Pce] PCE Disco Reqs v01 >=20 >=20 > Dimitri, >=20 > > neil - see in-line because we are not discussing the same issue > NH=3D> Its no use attempting to work on the roof of a house=20 > when the walls and foundations are not in place...now please see below > > > > =3D=3D=3D > > 2. In section 5.1.3 you mentioned among GMPLS capabilities a=20 > > capability to compute multi-layer paths. This sounds > > inaccurate: paths are always computed in one network layer,=20 > however, a=20 > > capable PCE may determine/suggest necessary=20 > reconfigurations in lower=20 > > layer(s) in order to satisfy a particular path computation request; > > > > [dp] i would like to know how you have come to the second sentence=20 > > statement - now more specifically, and in the context of the PCE=20 > > discovery document, per [LSP-HIER] an incoming ERO may include the=20 > > path to the lower SC, procedure is described in section 8.2 of that=20 > > document so there is nothing wrong in that sentence it just need a=20 > > clarification, that the sequence of hops resulting from this=20 > > computation may be covering multiple LSP regions. > > > > IB>> Come on, we had this argument many times already. Note, > > first, that > > neither me nor the document mentioned the term "region".=20 > Furthermore,=20 > > a PSC LSP does not "go" through a lambda layer, rather, it=20 > uses H-LSPs=20 > > created in the lambda layer as PSC data links. =3D=3D=3D > > > > > > NH=3D> I am, quite frankly, amazed to find there are still=20 > some folks,=20 > > like Dimitri apparently, who believe in the fairy-tale that you can=20 > > create 'topology on the fly' in a set of layer networks. > > > > DP> neil, i just mention that the procedure for processing an > > ERO whose > > hops cover multiple regions is described in section 8.2 of=20 > [LSP-HIER];=20 > > so the issue is whether a PCE can be become a usable tool in the=20 > > context of the CCAMP and MPLS signaling procedures then it needs to=20 > > cover what these procedures have been defined as part of these=20 > > documents otherwise one is going to be faced with the issue of a=20 > > "GMPLS-capable PCE" that does not provides the expected GMPLS/MPLS=20 > > capabilities - now, if for a set of reasons (to be discussed) this=20 > > mechanism is abandoned it should be first reflected as part of the > > above mentioned document; at the end, the point, is afaik > > that the PCE WG is not chartered to revise or select the > > signaling procedures and mechanisms defined by the MPLS and > > CCAMP WG (but in case extend them to cover its needs) >=20 > NH=3D> Dimitri....Don't you think its a good idea to question=20 > whether something is valid or not before acting on it? It's=20 > not very wise IMO (esp for a supplier) to follow stuff=20 > blindly if either (i) you don't understand it and accept it=20 > on 'blind faith', or (worse) (ii) know its a nonsense but=20 > carry on regardless. And from your response above I'm not=20 > quite sure which case applies here. >=20 > Can I therefore ask you specifically: >=20 > Do *you* believe (not what someone else has said) that we can=20 > have a common/single instance of routing across all network=20 > modes/technolgies such that on some client layer demand all=20 > the required layers below this are magically=20 > installed....because without this there is no topology basis=20 > in the client across which any routing decisions can be=20 > calculated. Noting that this remarkable routing instance=20 > must be capable of: digging trenches, laying ducts,=20 > installing fibres, installing optics/SDH/whatever nodes,=20 > setting up lambda paths (say) between SDH nodes (say),=20 > setting up VC4 paths (say) between VC12 (say) nodes,=20 > installing client X nodes and setting up VC12 paths between=20 > client X nodes, or whatever layer networks we wish to include=20 > in this list...right up to the client who wishes to place a=20 > demand. And this is even in a SINGLE operator=20 > case.....goodness know how you reconcile this when different=20 > operating parties own different layers. >=20 > A simple yes or no answer will suffice. >=20 > regards, Neil >=20 >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Jul 08 07:49:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqrMW-00026Z-KJ; Fri, 08 Jul 2005 07:49:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqrMU-00026U-9p for pce@megatron.ietf.org; Fri, 08 Jul 2005 07:49:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23796 for ; Fri, 8 Jul 2005 07:49:41 -0400 (EDT) Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Dqrnn-0008DU-3M for pce@ietf.org; Fri, 08 Jul 2005 08:18:00 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-2.tower-121.messagelabs.com!1120823366!3074812!1 X-StarScan-Version: 5.4.15; banners=-,-,- X-Originating-IP: [192.128.133.69] Received: (qmail 8227 invoked from network); 8 Jul 2005 11:49:27 -0000 Received: from kcmso1.att.com (HELO kcmso1.proxy.att.com) (192.128.133.69) by server-2.tower-121.messagelabs.com with SMTP; 8 Jul 2005 11:49:27 -0000 Received: from attrh3i.attrh.att.com ([135.38.62.9]) by kcmso1.proxy.att.com (AT&T IPNS/MLO-6.0) with ESMTP id j68BldEf015985 for ; Fri, 8 Jul 2005 06:49:26 -0500 Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by attrh3i.attrh.att.com (7.2.052) id 42BED27600252E63; Fri, 8 Jul 2005 07:49:26 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 8 Jul 2005 06:49:26 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA060CE665@KCCLUST06EVS1.ugd.att.com> Thread-Topic: Missing Requirement in draft-ietf-pce-comm-protocol-gen-reqs-00.txt Thread-Index: AcWDXNWF6A8cKKnFTyyhgNozg5rVPgAU/FAw From: "Ash, Gerald R \(Jerry\), ALABS" To: "JP Vasseur" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: quoted-printable Cc: pce@ietf.org Subject: [Pce] RE: Missing Requirement in draft-ietf-pce-comm-protocol-gen-reqs-00.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org JP, > During a discussion that I had with Adrian, I noticed > that there was no requirement for PCE communication > protocol to support the ability to request a TE LSP path > reoptimization. If the path of an existing TE LSP to be > reoptimized is not provided to a stateless PCE, then this > may lead to sub-optimal routing and thus in no > reoptimization of the existing path although a more > optimal path may exist. > > Isn't a requirement to able to support reoptimization > requests whereby the head-end has the ability to provide > the existing path? Yes, I agree. I think we can add the requirement to Section 6.1.4 'Path Computation Requests', such as: "The path computation request message MUST support TE LSP path reoptimization. Furthermore, reoptimization requests MUST include the ability to provide the existing path, in order to ensure optimal path routing." OK? Thanks, Jerry _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Jul 08 08:17:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqrnD-0001A3-R0; Fri, 08 Jul 2005 08:17:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqrnB-00019y-Lu for pce@megatron.ietf.org; Fri, 08 Jul 2005 08:17:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26192 for ; Fri, 8 Jul 2005 08:17:16 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqsEX-0001yd-Ru for pce@ietf.org; Fri, 08 Jul 2005 08:45:36 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 08 Jul 2005 08:17:06 -0400 X-IronPort-AV: i="3.93,273,1115006400"; d="scan'208"; a="61517031:sNHT27853728" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j68CH6Vu022532; Fri, 8 Jul 2005 08:17:06 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 8 Jul 2005 08:17:00 -0400 Received: from [192.168.1.100] ([10.86.242.166]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 8 Jul 2005 08:17:05 -0400 In-Reply-To: <9473683187ADC049A855ED2DA739ABCA060CE665@KCCLUST06EVS1.ugd.att.com> References: <9473683187ADC049A855ED2DA739ABCA060CE665@KCCLUST06EVS1.ugd.att.com> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <84CD5BA3-E164-43D7-A113-DDC42AD647A6@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Date: Fri, 8 Jul 2005 08:17:26 -0400 To: "Ash, Gerald R \(Jerry\), ALABS" X-Mailer: Apple Mail (2.730) X-OriginalArrivalTime: 08 Jul 2005 12:17:06.0024 (UTC) FILETIME=[F48F3680:01C583B6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Cc: pce@ietf.org Subject: [Pce] Re: Missing Requirement in draft-ietf-pce-comm-protocol-gen-reqs-00.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi Jerry, On Jul 8, 2005, at 7:49 AM, Ash, Gerald R ((Jerry)), ALABS wrote: > JP, > > >> During a discussion that I had with Adrian, I noticed >> that there was no requirement for PCE communication >> protocol to support the ability to request a TE LSP path >> reoptimization. If the path of an existing TE LSP to be >> reoptimized is not provided to a stateless PCE, then this >> may lead to sub-optimal routing and thus in no >> reoptimization of the existing path although a more >> optimal path may exist. >> >> Isn't a requirement to able to support reoptimization >> requests whereby the head-end has the ability to provide >> the existing path? >> > > Yes, I agree. > > I think we can add the requirement to Section 6.1.4 'Path Computation > Requests', such as: > > "The path computation request message MUST support TE LSP path > reoptimization. Furthermore, reoptimization requests MUST include the > ability to provide the existing path, in order to ensure optimal path > routing." > > OK? > Sure, Thanks. JP. > Thanks, > Jerry > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Jul 08 10:17:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqtYy-0000uJ-JK; Fri, 08 Jul 2005 10:10:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqtYu-0000te-6c for pce@megatron.ietf.org; Fri, 08 Jul 2005 10:10:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04721 for ; Fri, 8 Jul 2005 10:10:38 -0400 (EDT) Received: from webmail.movaz.com ([65.205.166.188] helo=jera.movaz.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dqu0I-0002Ag-5a for pce@ietf.org; Fri, 08 Jul 2005 10:38:59 -0400 Received: from ib (vpn14.atlanta.movaz.com [172.18.0.14]) by jera.movaz.com (Postfix) with SMTP id 118AB144EB; Fri, 8 Jul 2005 10:10:27 -0400 (EDT) Message-ID: <00c801c583c6$c703b780$6501a8c0@movaz.com> From: "Igor Bryskin" To: "LE ROUX Jean-Louis RD-CORE-LAN" , References: Subject: Re: [Pce] PCE Disco Reqs v01 Date: Fri, 8 Jul 2005 10:10:21 -0400 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.6 (/) X-Scan-Signature: 7a9d8f61f7718176ef97b85bbcc64331 Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1199956555==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1199956555== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C5_01C583A5.3FB4E770" This is a multi-part message in MIME format. ------=_NextPart_000_00C5_01C583A5.3FB4E770 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MessageJL, Please, see inline. ----- Original Message -----=20 From: LE ROUX Jean-Louis RD-CORE-LAN=20 To: Igor Bryskin ; pce@ietf.org=20 Sent: Friday, July 08, 2005 3:40 AM Subject: RE : [Pce] PCE Disco Reqs v01 Hi Igor Thanks for these useful comments/suggestions Please see inline, -----Message d'origine----- De : Igor Bryskin [mailto:ibryskin@movaz.com]=20 Envoy=E9 : mercredi 6 juillet 2005 17:40 =C0 : LE ROUX Jean-Louis RD-CORE-LAN; pce@ietf.org Objet : Re: [Pce] PCE Disco Reqs v01 JL. I have a couple of questions/comments. 1. On more than one occasions you use the term "TE-LSP path = computation request". This sounds like an assumption that paths are = computed separately for each TE-LSP. In reality, though, a single path = computation request for a protected service is expected to determine = paths for multiple LSPs (working and protecting). Furthermore, a single = path computation may be performed for multiple services to make them = possible sharing protection resources. I would suggest dropping the = "TE-LSP" from the "TE-LSP path computation" combination; =20 [JLLR] This is a valid point, I will update as per your proposal=20 2. In section 5.1.3 you mentioned among GMPLS capabilities a = capability to compute multi-layer paths. This sounds inaccurate: paths = are always computed in one network layer, however, a capable PCE may = determine/suggest necessary reconfigurations in lower layer(s) in order = to satisfy a particular path computation request; [JLLR] I'm not sure I follow you here. The PCE may be aware of = topology in multiple layers and compute a multi-layer path. IB>> By computing a multi-layer path we actually mean computing path = in the layer in question (that is, layer where the LSP will be = provisioned) + necessary re-configurations in lower layers, would you = agree with that ?=20 As per defined in LSP-HIER an ERO can contain elements with distinct = ISCs.=20 IB>> This is just one way - top_to_bottom - to achieve dynamic lower = layer re-configurations. As you correctly pointed out the VNT approach = is another alternative, IMO much more reasonable and realistic. My point = was that by PCE multi-layer capabilities we mean the support of dynamic = re-configurations of multiple layers according to all feasible = scenarios, and "the capability to compute multi-layer paths" is not = adequate and somehow confusing term.=20 Actually this will trigger LSP nesting at region boundaries.=20 IB>> Correction, on layer boundaries :=3D) But I agree with you that "this may require the PCE to = determine/suggest necessary reconfigurations in lower layer(s) in order = to satisfy a particular path computation request"; This is actually what = we call VNT reconfiguration in MRN. Also note that the objective here in this doc is not to explain the = capabilities, this will actually be done in a separate document. IB>> If you require capabilities without explaining what these = capabilities mean, there will be a room for misinterpretation. I think = it would be reasonable to request the definition in the" PCE = architecture" document and make a reference to it. 3. I believe it should be stated more clearly that 2 stages of PCE = discovery are needed: basic stage and detailed stage. During the basic = stage PCE publishes some basic information about itself (presence, = computation scope, etc.) on the network independently from PCCs. = Interested PCCs should be able to participate in the detailed discovery = stage, that is, to establish communication sessions (via PCC-PCE or a = separate protocol) with the PCE to request/subscribe on the PCE detailed = information (capability, CPU power, capacity, status, etc.). This would = be good IMO both from the scalability and security points of view. [JLLR] Note that this is already partially addressed in the = capability section: " It is paramount that dynamic capability discovery MUST NOT = generate=20 an excessive amount of information... =20 IB>> Scalability is just one of the problems. As Eric correctly = pointed out the security concerns are very serious. PCE can disclose all = information about itself only to PCCs it trusts. If required, the exhaustive discovery of detailed capabilities = could be ensured by means of the PCC-PCE communication protocol. [IB>> It does not have to be the same protocol as used to request = path computations. However, I can see the benefits of combining the two = protocols togather. This, for instance, would make introduction of new = constraints or optimization criterias simpler]=20 Actually a tradeoff should be found between capability discovery by = the PCE discovery mechanism and by the PCC-PCE communication protocol. = One of the objectives of the PCE discovery mechanism is to help PCCs to = select appropriate PCEs and limit the likelihood of PCC-PCE = communication rejections that may occur in case a PCE cannot support a = given capability. "=20 =20 I intend to agree with your proposal, but this may be too solution = oriented=20 IB>> Well, this is a very popular statement in discussions around = any requirements document. However, I don't see how it could be applied = in this case. I was only asking to break the discovery process into 2 = stages - basic (lightweighted and unsecure) and detailed, so that on one = hand the scalability and secirity issues could be addresseb, and on the = other hand PCCs could obtain all necessary information to choose the PCE = to work with. =20 "Interested PCCs should be able to participate in the detailed = discovery stage, that is, to establish communication sessions (via = PCC-PCE or a separate protocol) with the PCE to request/subscribe on the = PCE detailed information (capability, CPU power, capacity, status, = etc.). This would be good IMO both from the scalability and security = points of view." Why mandating the use of a PCC-PCE communication sessions for = detailed discovery? This may be too solution oriented. One could argue = that this may not scale, as you would have to setup a session with all = PCEs in order to now their capabilities and that this could rather be = done more efficiently thanks to IGP flooding, using a set of bit flags, = at least for simple capabilities... IB>> See the comment above. Note, also, that in order to request a = path computation PCC will have to setup a session anyway. Besides, if a = PCC will install sessions with all PCEs it knows about, would it be a = signifficant overhead ? =20 =20 Hence, what about saying that there are too stages in PCE discovery = (Basic, detailed...) that can be ensured either with the same discovery = mechanism or using distinct mechnanisms? IB>> Sounds good. =20 4. Responding to your questions: -Is there a need for the discovery of PCE capacity in terms = of =20 computation power? This static parameter could be used to =20 ensure weighted load balancing of requests in case PCEs do = not =20 have the same capacity.=20 Yes. It could be achieved by a direct request from a PCC during the = detailed discovery stage (see above). [JLLR] So you consider that this necessarily requires a PCC-PCE = session? One could argue that this may also be done in an efficient way = thanks to IGP flooding: For instance one could argue that a flag flooded into the IGP, is = more efficient than N notifications sent by a PCE to its N PCCs using a = PCC-PCE communication session... IB>> a) security; b) one flag is probably not enough; c) what if the = PCC is not an IGP-TE speaker? Have agreat weekend Igor -Would it be useful that a PCE report its status as = "congested" =20 in case it is too busy? PCCs may then use this dynamic =20 information to prefer a different PCE. =20 Yes. It could be achieved by a subscription of a PCC on the PCE's = status change (also during the detailed discovery stage ). [JLLR] Same remark Thanks a lot for these valuable comments, Regards JL=20 Cheers, Igor ----- Original Message -----=20 From: LE ROUX Jean-Louis RD-CORE-LAN=20 To: pce@ietf.org=20 Sent: Wednesday, June 29, 2005 8:00 AM Subject: [Pce] PCE Disco Reqs v01 Hi all,=20 Version 01 of the PCE discovery reqs ID has just been published=20 = http://www.ietf.org/internet-drafts/draft-leroux-pce-discovery-reqs-01.tx= t=20 This version takes into account comments received during = Minneapolis session and on the list.=20 Here are the major changes since 00:=20 -Added multi-area network case in the problem statement=20 -Added application scenario (section 4)=20 -Section 5.1 on capability discovery modified as per discussions = on the list:=20 -Discovery of PCE location, PCE scopes and domain(s) under = control is mandatory=20 -Capability discovery is no longer a MUST=20 The list of capabilities is now out of the scope and should = be addressed in a=20 separate document.=20 =20 -Added section 5.6 on extensibility=20 -Added Security section=20 Section 5.5 (Discovery of PCE capacity and congestion) requires WG = feedback:=20 -Is there a need for the discovery of PCE capacity in terms of = computation power? This static parameter could be used to ensure = weighted load balancing of requests in case PCEs do not have the same = capacity.=20 -Would it be useful that a PCE report its status as "congested" in = case it is too busy? PCCs may then use this dynamic information to = prefer a different PCE.=20 Your comments/feedback would be highly welcome, especially on the = above point=20 Best Regards,=20 JL=20 -------------------------------------------------------------------------= - _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce ------=_NextPart_000_00C5_01C583A5.3FB4E770 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
JL,
 
Please, see inline.
----- Original Message -----
From:=20 LE ROUX Jean-Louis=20 RD-CORE-LAN
Sent: Friday, July 08, 2005 = 3:40 AM
Subject: RE : [Pce] PCE Disco = Reqs=20 v01

Hi=20 Igor
 
Thanks for these useful = comments/suggestions
 
Please see inline,
 
 
-----Message d'origine-----
De : Igor = Bryskin=20 [mailto:ibryskin@movaz.com]
Envoy=E9 : mercredi 6 = juillet 2005=20 17:40
=C0 : LE ROUX Jean-Louis RD-CORE-LAN; pce@ietf.org
Objet : = Re: [Pce]=20 PCE Disco Reqs v01

JL.
 
I have a couple of=20 questions/comments.
 
1. On more than one occasions = you use the=20 term "TE-LSP path computation request". This sounds like an = assumption that=20 paths are computed separately for each TE-LSP. In reality, though, a = single=20 path computation request for a protected service is expected to = determine=20 paths for multiple LSPs (working and protecting). Furthermore, a = single path=20 computation may be performed for multiple services to make them=20 possible sharing protection resources. I would suggest dropping = the=20 "TE-LSP" from the "TE-LSP path computation" combination;
 
[JLLR] This is = a valid=20 point, I will update as per your=20 proposal 
 
2. In section 5.1.3 you = mentioned among=20 GMPLS capabilities a capability to compute multi-layer paths. This = sounds=20 inaccurate: paths are always computed in one network layer, however, = a=20 capable PCE may determine/suggest necessary reconfigurations in = lower=20 layer(s) in order to satisfy a particular path computation = request;
[JLLR] I'm not = sure I=20 follow you here. The PCE may be aware of topology in multiple=20 layers and compute a multi-layer=20 path.
IB>> By computing a multi-layer = path we=20 actually mean computing path in the layer in question (that is, = layer where=20 the LSP will be provisioned) + necessary re-configurations in lower = layers,=20 would you agree with that ? 
 
As per defined in LSP-HIER an ERO can contain = elements=20 with distinct ISCs.
IB>> This is just one way - top_to_bottom -=20 to achieve dynamic lower layer re-configurations. As you = correctly=20 pointed out the VNT approach is another alternative, IMO much more=20 reasonable and realistic. My point was that by PCE multi-layer = capabilities=20 we mean the support of dynamic re-configurations of multiple layers=20 according to all feasible scenarios, and "the capability to=20 compute multi-layer paths" is not adequate and somehow = confusing=20 term. 
 
Actually this=20 will trigger LSP nesting at region=20 boundaries. 
IB>> Correction, on layer = boundaries=20 :=3D)
 
But I agree with you that "this may require the = PCE=20 to  determine/suggest = necessary=20 reconfigurations in lower layer(s) in order to satisfy a particular = path=20 computation request"; This is actually what we call VNT = reconfiguration in=20 MRN.
Also note that the objective here in this doc = is not to=20 explain the capabilities, this will actually be done in a = separate=20 document.
IB>> If you require = capabilities without=20 explaining what these capabilities mean, there will be a room for=20 misinterpretation. I think it would be reasonable to request = the=20 definition in the" PCE architecture" document and make a reference = to=20 it.
 
3. I believe it should be = stated more=20 clearly that 2 stages of PCE discovery are needed: basic stage = and=20 detailed stage. During the basic stage PCE publishes some basic = information=20 about itself (presence, computation scope, etc.) on the network=20 independently from PCCs. Interested PCCs should be able to = participate in=20 the detailed discovery stage, that is, to establish communication = sessions=20 (via PCC-PCE or a separate protocol) with the PCE to = request/subscribe on=20 the PCE detailed information (capability, CPU power, capacity, = status,=20 etc.). This would be good IMO both from the scalability and security = points=20 of view.
[JLLR] Note = that this is already partially addressed in the=20 capability section:

" It is paramount that = dynamic=20 capability discovery MUST NOT generate=20

an excessive=20 amount of information...  

IB>> Scalability is just one of the = problems.=20 As Eric correctly pointed out the security concerns are very = serious. PCE=20 can disclose all information about itself only to PCCs it=20 trusts.

 

 If = required,=20 the exhaustive discovery of detailed capabilities could be ensured = by means=20 of the PCC-PCE communication = protocol.

[IB>> It=20 does not have to be the same protocol as used to request path=20 computations. However, I can see the benefits of combining the two = protocols=20 togather. This, for instance, would make introduction of new = constraints or=20 optimization criterias = simpler] 

 

Actually a=20 tradeoff should be found between capability discovery by the PCE = discovery=20 mechanism and by the PCC-PCE communication protocol. One of the = objectives=20 of the PCE discovery mechanism is to help PCCs to select appropriate = PCEs=20 and limit the likelihood of PCC-PCE communication rejections that = may occur=20 in case a PCE cannot support a given capability. " 

=

=  

I intend to agree with your proposal, but this may be too solution = oriented=20

IB>> Well,=20 this is a very popular statement in discussions around any = requirements=20 document. However, I don't see how it could be applied in this case. = I was=20 only asking to break the discovery process into 2 stages - = basic=20 (lightweighted and unsecure) and detailed, so that on one hand the=20 scalability and secirity issues could be addresseb, and on the other = hand=20 PCCs could obtain all necessary information to choose the PCE = to work=20 with.

  =

"Interested PCCs should be able to participate in = the detailed=20 discovery stage, that is, to establish communication sessions (via = PCC-PCE=20 or a separate protocol) with the PCE to request/subscribe on the PCE = detailed information (capability, CPU power, capacity, status, = etc.). This=20 would be good IMO both from the scalability and security points of=20 = view."

Why=20 mandating the use of a PCC-PCE communication sessions for detailed=20 discovery? This may be too solution oriented. One could argue that = this may=20 not scale, as you would have to setup a session with all = PCEs in=20 order to now their capabilities and that this could rather be = done more=20 efficiently thanks to IGP flooding, using a set of bit flags, at = least for=20 simple=20 = capabilities...

 

IB>>=20 See the comment above. Note, also, that in order to request a path=20 computation PCC will have to setup a session anyway. Besides, if a = PCC will=20 install sessions with all PCEs it knows about, would it be = a=20 signifficant overhead=20 ?

 

 

Hence,=20 what about saying that there are too stages in PCE discovery (Basic, = detailed...) that can be ensured either with the same discovery = mechanism or using distinct=20 = mechnanisms?

 

IB>>=20 Sounds=20 = good.

 
 
4. Responding to your = questions:
        -Is there a need for = the=20 discovery of PCE capacity in terms of =20
         computation = power? This=20 static parameter could be used to =20
         ensure weighted = load=20 balancing of requests in case PCEs do not =20
         have the same = capacity.=20
Yes. It could be achieved by a direct request from a PCC during = the=20 detailed discovery stage (see above).
[JLLR] So you consider that this necessarily = requires a=20 PCC-PCE session?
One could argue that this may also be done in an = efficient=20 way thanks to IGP flooding:
For instance one could argue that a flag flooded into the=20 IGP, is more efficient than N notifications sent by a PCE to = its N PCCs=20 using a PCC-PCE communication session...
IB>> a) security; b) one flag = is probably=20 not enough; c) what if the PCC is not an IGP-TE = speaker?
 
Have agreat = weekend
Igor

        = -Would it be=20 useful that a PCE report its status as "congested" =20
         in case it is = too busy?=20 PCCs may then use this dynamic =20
         information to = prefer a=20 different PCE. 
Yes. It could be achieved by a subscription of a PCC on = the PCE's=20 status change (also during the detailed discovery stage ).
[JLLR] Same remark
 
Thanks a lot for these valuable = comments,
 
Regards
 
JL 
 
Cheers,
Igor
 
----- Original Message ----- =
From:=20 LE ROUX = Jean-Louis=20 RD-CORE-LAN
Sent: Wednesday, June 29, = 2005 8:00=20 AM
Subject: [Pce] PCE Disco = Reqs=20 v01

Hi all,

Version 01 of the PCE = discovery reqs ID=20 has just been published
http://www.ietf.org/internet-drafts/draft-leroux-pce-discovery-r= eqs-01.txt=20

This version takes into = account=20 comments received during Minneapolis session and on the = list.

Here are the major changes = since=20 00:
-Added = multi-area network=20 case in the problem statement
-Added application scenario (section 4)
-Section 5.1 on capability discovery = modified as=20 per discussions on the list:=20
        -Discovery of PCE location, PCE scopes and domain(s) = under control=20 is mandatory
        = -Capability discovery is no longer a = MUST=20
      =20 The list of capabilities is now out of the scope and should be = addressed=20 in a
       separate = document.=20
      =20
-Added section 5.6 = on=20 extensibility
-Added Security=20 section

Section 5.5 (Discovery of = PCE capacity=20 and congestion) requires WG feedback:
-Is there a need=20 for the discovery of PCE capacity in terms of computation power? = This=20 static parameter could be used to ensure weighted load balancing = of=20 requests in case PCEs do not have the same capacity.

-Would it be useful that a = PCE report=20 its status as "congested" in case it is too busy? PCCs may then = use this=20 dynamic information to prefer a different PCE.

Your comments/feedback = would be highly=20 welcome, especially on the above point

Best Regards,

JL

_______________________________________________
Pce = mailing=20 = list
Pce@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce<= BR>
------=_NextPart_000_00C5_01C583A5.3FB4E770-- --===============1199956555== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============1199956555==-- From pce-bounces@lists.ietf.org Fri Jul 08 11:02:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DquNH-0002YT-Jj; Fri, 08 Jul 2005 11:02:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DquNE-0002YA-1f for pce@megatron.ietf.org; Fri, 08 Jul 2005 11:02:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10906 for ; Fri, 8 Jul 2005 11:02:38 -0400 (EDT) Received: from webmail.movaz.com ([65.205.166.188] helo=jera.movaz.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dquoc-0005PG-Pb for pce@ietf.org; Fri, 08 Jul 2005 11:30:59 -0400 Received: from ib (vpn14.atlanta.movaz.com [172.18.0.14]) by jera.movaz.com (Postfix) with SMTP id 5C0A81877; Fri, 8 Jul 2005 11:02:29 -0400 (EDT) Message-ID: <00d501c583ce$0be81d30$6501a8c0@movaz.com> From: "Igor Bryskin" To: , References: <0536FC9B908BEC4597EE721BE6A353890A9F1D8B@i2km07-ukbr.domain1.systemhost.net> Subject: Re: [Pce] PCE Disco Reqs v01 Date: Fri, 8 Jul 2005 11:02:23 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: 07e9b4af03a165a413ec6e4d37ae537b Content-Transfer-Encoding: 7bit Cc: pce@ietf.org, alan.mcguire@bt.com X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Neil, Thanks for your comments, they help a lot. See my comments in-line. Igor ----- Original Message ----- From: To: ; Cc: ; Sent: Friday, July 08, 2005 4:55 AM Subject: RE: [Pce] PCE Disco Reqs v01 Thanks Igor..... Please see in-line. > I'd like to explain a bit more my views on the network > topology management and why the discussion is IMO important > in the PCE context. NH=> OK > > I agree that topology should be built bottom-up. NH=> Well, no arguments from me as 'it's obviously true'. However, I have to emphasise that when creating topology in a set of nested layer networks this cannot be driven solely by some idealistic 'common control plane mindset'.....I know this is how the idea (of working on non-cl-ps technologies) has been 'sold' to IETF to justify doing this stuff here, but there are some crucial issues relating to: - the basic economics of network design (see my comments on GoS design in previous mails, and its something I will return to repeatedly below because its so important)...remember - someone has to ultimately pay real money for this stuff - the differences between the 3 major modes of networking.....these differences are actually the important bits....which means we cannot have a truly 'common' approach in all cases if we want to exploiut these differences to maximum advantage - the fact that for both scaling reasons and operating reasons (which also contains facets like security and legal/regulatory considerations for major opreators) functionally decoupled client/server relationships are an ESSENTIAL starting point. This is what I was referring to in my earlier mail on a 'network builder capability'. And whilst this is ALWAYS achievable in the co-cs mode (purely due to the modal constraints here)...and BTW this is also true for the cl-ps mode..... this can be made NOT so in the co-ps mode if a digital wrapper idea is used to create 'hierarchy' (which is precisely why folks are now hitting problems with the multi-hop PW stuff based on MPLS). So when we create topology using client/server layer network relationships we MUST bear the above points in mind. Now if I was to make some very general observations on the architectural/commercial design rules that should govern our thinking here, they would run along these lines: - don't try and seek complete functional convergence across all 3 networking modes....use their differences wisely to solve (what could be) otherwise very hard problems (like QoS, security, etc) - don't have lots of technologies belonging to the SAME mode....as they will simply be replicating each other's modus operandi and it will lead to (i) the so-called stove-pipe problem (ie a vertically complete (ie inc NMS/OSS) networking platform where 'the technology' effectively becomes 'the service' and (ii) nasty peer-partition interworking/migration problems - recognise that as we move down towards the duct the holding-times of trails will, of necessity, increase.....the converse is also true - recognise that as we move down towards the duct the 'routing' function becomes far less important than in the higher layer networks.....or more generally, there is less need for a control-plane than having a good management-plane story. This does NOT mean we don't need a control-plane here, eg signalling is a useful function, but the time constants of the topology here are such (ie long of commercial necessity) that the routing function (whilst still required) is far less important than other components IB>> Let me ask you something. Suppose we have VC12 layer and VC4 layer. Is it unrealistic to expect that the same instance of the control plane manages both of them? If, say, PCE fails a path computation for a VC12 connection, could it suggest a reconfiguration in the VC4 layer, pass this suggestion to a VNT Manager (application/entity that has security, budget, etc. authorization) to add trails in VC4 layer and provide extra flexibility in the VC12 layer? Correct me if I am wrong, but you sound like always require NMS+human in the inter-layer relationships. Why the process could not be autometed via control plane ? > I also think > that path computation for a particular LSP (connection) > should be constrained to the network layer where the LSP is > provisioned, NH=> Yes, agreed again. This is indeed a critical design requirement, ie we MUST always be able to run each layer network independently from other layer networks. IB>> This is not what I said (at least, meant). See the comment above. This is also a clear recognition that there cannot be a singular control-plane...or more accurately a singular routing instance (which, by definition, means there is no single 'addressing' instance across each of the layer networks). IB>> Agaian, this is not what I meant.. > and it could succeed only if there is necessary > network flexibility (at least one that is advertised) in this > layer in place. NH=> See my response to Scott. But to summarise.....Who is actually paying for all this idle BW at some layer N, and below which we agree (as per above) everything from here on down MUST already be in place? IB>> An application/ architectural construct (I call it VNT Manager) authorized to do so. This application has policies what to do with unused BW. For instance, it decides what to do whith dynamically created trail when the last client layer connection is gone. > > However, provided that the same instance of control plane > (e.g. GMPLS) manages multiple layers, NH=> I have no problem with re-using the best-of-breed functional components in each networking mode WHERE this is applicable, eg use the same *base* signalling protocol and OOB solution for both the co-cs and co-ps modes (the word 'base' is highlighted here to indicate that the message set is not identical for each mode).....in fact I strongly encourage this type of practice. Where I do object however is when folks try and tell me there is a 'common' instance of functional components running from top to bottom. This will neither work well per se nor does it satisfy important commercial and operational requirements. IB>> See my example above. Furthermore, GMPLS introduces a notion of "region" for layers associated, say, with different data plane technology where the bulk of control plane functionality is the same, but subtelties needs to be performed differently (slightly different set of signaling objects, different path computation constraints, etc.) > and PCE has sufficient > TE visibility, and TE link advertisements include such > attributes as termination and adaptation capabilities, PCE > could determine necessary reconfigurations in lower > layer(s) in order to have original PCE request satisfied. NH=> This seems to be asking me as an operator to build out some server layer networks with lots of capacity just so as we can prove that a given client can present some ad hoc demand to those server layer and have it satisfied right? And, as you agreed at the outset, below *this* layer network (wherever this is) everything else must be already hard provisioned.....because, as we agreed, topology is created from the duct upward. IB>> Nobody said that GMPLS must control all layers, it could control for instance all/some SDH layers. Network topology in lower layers it does not control, of course, needs to be in place. Not only do I think this is commercially unrealistic without some idea of the GoS one could realistically achieve (I have to pay to build this GoS remember), I think it is underestimating (and very much so) the impact, and relationship with, the management-plane. I would strongly advise having a talk to the folks in large operators who are responsible for running and *paying* for their major transport networks (eg SDH) rather than the folks from more of a 'R&D' background in those operators....you may get a very different perspective on what is important here and what is not. IB>> Agree, this would be extreamely useful. > This extra information could be used by a special application > (let's call it Virtual Network Topology (VNT) Manager), which > could verify that the specified re-configurations are, > indeed, feasible, optimal, do not affect active services, do > not cause network de-stabilization, etc. NH=> If I was being slightly cynical here I could say 'This reads like the dawning of the realisation that it's network management that is key here'. > and instruct (if > authorized) appropriate controllers to establish H-LSPs > (trails) and advertise them as TE links. NH=> I've never understood what these 'TE links' are......they are woolly defined at best IMO. IB>> In the lexicography draft we (Adrian and myself) tried very hard to explain what the TE link means. In ASON terminology it is SNPP link What you appear to be describing is basic G.805 stuff (if I have this right), ie you are creating a link in client layer network using trails of some server layer network. IB>> Those are data links. GMPLS data link = ASON link supported by a single trail in the server layer. Those are collection of network resources but not something path computation works with. PCE works with graphs built of TE links - logical grouping of resources. Fine, nothing wrong with that. But I'm sensing some desperation here to find a role for this GMPLS stuff that has been generated. For example, if client layer network X does not need capacity during time T we can reallocate that capacity to client layer Y. Sounds nice in principle....ain't so simple in practice (for many reasons, esp wrt the costs associated with providing some *acceptable* on-demand GoS). And as I observed earlier, this looks to me as though its the dawning of the realisation that network management is the key issue here....which of course it is. > Only once the TE > links are advertised, the original path computation request > can succeed. NH=> Very much so....at least wrt to my understanding of what 'TE links' ought to mean in practice, ie you can't calculate routes over a topology that does not exist. But this all comes back to 'in which layer network does the hard provisioning start?' And then 'to what level of (client) on-demand GoS is *that* server layer network supposed to be designed against?' And do you really think we need a control-plane solution to provide this as we approach the duct (given the current realities of commercial models of BoD)? And what about client/server relationships between different parties? I actually think this work is now clutching at straws to justify its continued existence. Nice theoretical work perhaps....and I could postulate some future where certain *public* services in end-systems (based on large file transfer or stream applications say) might be able to call-up some simple on-demand SVCs in some co-cs or co-ps (here CBR-like) layer network (think of it as BB PSTN if you like)....now that scenario might warrant closer scutinity (in fact I'd say this is an area well worth looking at as it will address some otherwise very hard QoS/pricing problems that will not be satisfactorily solved by current direction). However, as a private network builder service capability in today's environment....whether this is aimed at self-owned or other-party-owned client layer networks.....I don't think this is currently that viable. However it does seem to be the basis on which you would sell this notion right now. > Note that the H-LSPs could be virtual (not > provisioned) or soft (resources are allocated but not bound > into cross-connects, they are shared with other LSPs or even > carry extra > traffic) and become hard (that is, fully provisioned) when > the Setup message of the first LSP they suppose to carry > arrives on the H-LSP ingress nodes. NH=> Yes, but have you done the business case to warrant the build-out creation of these underpinning transport layer networks that are there sitting there idle waiting to satisfy these hopeful client layer demands? I was talking about this topic to one of my colleagues who has done this type of study here in BT and we might see if we can publish some of our findings. > The important thing is > that TE links associated with such H-LSPs are advertised and > available for the original path computation. The VNT manager > also decides when the H-LSPs should be removed and associated > TE links withdrawn, so that the network is not de-stabilized > by frequent re-configurations. NH=> Withdrawn?! I'll believe it when I see it. IMO, no IM STRONG O, if you provide some server layer capacity to a given client layer network you will NEVER withdraw it (not unless the client is in decline).....as it impacts that client layer's topology and what it (ie the client layer network) does with route calculations from this moment onwards. IB>> Again, this is upto VNT Manager to decide. Dynamically advertised TE links surely could be withdrawn. It should be done with a caution not to destabilize the client layer, but this still could be done. > > Hope this helps rather that brings more confusion. NH=> I think your engineering heart is in the right place Igor. But I think the commercial justifications are misplaced. I don't know why we can't have a simpler model of where we want to head wrt networking. I have a fairly clear model in my mind of what this ought to look like (so we can all benefit), where all 3 networking modes work in concert across private and public services, but I think we are some way off acheiving this. Maybe for another day a few years hence. IB>> Whould be very interested to see your model In the meantime, I'd suggest sitting down with the folks in large operators who are really responsible for operating/designing and paying for these major transport networks. regards, Neil > IB>> Cheers, Igor > > ----- Original Message ----- > From: > To: > Cc: ; > Sent: Thursday, July 07, 2005 6:15 AM > Subject: RE: [Pce] PCE Disco Reqs v01 > > > Dimitri, > > > neil - see in-line because we are not discussing the same issue > NH=> Its no use attempting to work on the roof of a house > when the walls and foundations are not in place...now please see below > > > > === > > 2. In section 5.1.3 you mentioned among GMPLS capabilities a > > capability to compute multi-layer paths. This sounds > > inaccurate: paths are always computed in one network layer, > however, a > > capable PCE may determine/suggest necessary > reconfigurations in lower > > layer(s) in order to satisfy a particular path computation request; > > > > [dp] i would like to know how you have come to the second sentence > > statement - now more specifically, and in the context of the PCE > > discovery document, per [LSP-HIER] an incoming ERO may include the > > path to the lower SC, procedure is described in section 8.2 of that > > document so there is nothing wrong in that sentence it just need a > > clarification, that the sequence of hops resulting from this > > computation may be covering multiple LSP regions. > > > > IB>> Come on, we had this argument many times already. Note, > > first, that > > neither me nor the document mentioned the term "region". > Furthermore, > > a PSC LSP does not "go" through a lambda layer, rather, it > uses H-LSPs > > created in the lambda layer as PSC data links. === > > > > > > NH=> I am, quite frankly, amazed to find there are still > some folks, > > like Dimitri apparently, who believe in the fairy-tale that you can > > create 'topology on the fly' in a set of layer networks. > > > > DP> neil, i just mention that the procedure for processing an > > ERO whose > > hops cover multiple regions is described in section 8.2 of > [LSP-HIER]; > > so the issue is whether a PCE can be become a usable tool in the > > context of the CCAMP and MPLS signaling procedures then it needs to > > cover what these procedures have been defined as part of these > > documents otherwise one is going to be faced with the issue of a > > "GMPLS-capable PCE" that does not provides the expected GMPLS/MPLS > > capabilities - now, if for a set of reasons (to be discussed) this > > mechanism is abandoned it should be first reflected as part of the > > above mentioned document; at the end, the point, is afaik > > that the PCE WG is not chartered to revise or select the > > signaling procedures and mechanisms defined by the MPLS and > > CCAMP WG (but in case extend them to cover its needs) > > NH=> Dimitri....Don't you think its a good idea to question > whether something is valid or not before acting on it? It's > not very wise IMO (esp for a supplier) to follow stuff > blindly if either (i) you don't understand it and accept it > on 'blind faith', or (worse) (ii) know its a nonsense but > carry on regardless. And from your response above I'm not > quite sure which case applies here. > > Can I therefore ask you specifically: > > Do *you* believe (not what someone else has said) that we can > have a common/single instance of routing across all network > modes/technolgies such that on some client layer demand all > the required layers below this are magically > installed....because without this there is no topology basis > in the client across which any routing decisions can be > calculated. Noting that this remarkable routing instance > must be capable of: digging trenches, laying ducts, > installing fibres, installing optics/SDH/whatever nodes, > setting up lambda paths (say) between SDH nodes (say), > setting up VC4 paths (say) between VC12 (say) nodes, > installing client X nodes and setting up VC12 paths between > client X nodes, or whatever layer networks we wish to include > in this list...right up to the client who wishes to place a > demand. And this is even in a SINGLE operator > case.....goodness know how you reconcile this when different > operating parties own different layers. > > A simple yes or no answer will suffice. > > regards, Neil > > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Jul 08 11:40:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dquy7-0006yp-1o; Fri, 08 Jul 2005 11:40:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dquy4-0006yH-TQ for pce@megatron.ietf.org; Fri, 08 Jul 2005 11:40:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22296 for ; Fri, 8 Jul 2005 11:40:42 -0400 (EDT) From: benjamin.niven-jenkins@bt.com Received: from smtp4.smtp.bt.com ([217.32.164.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqvPS-0001t0-LO for pce@ietf.org; Fri, 08 Jul 2005 12:09:05 -0400 Received: from i2km99-ukbr.domain1.systemhost.net ([193.113.197.31]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 8 Jul 2005 16:40:32 +0100 Received: from i2km86-ukdy.domain1.systemhost.net ([193.113.30.79]) by i2km99-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Fri, 8 Jul 2005 16:40:32 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] PCE Disco Reqs v01 Date: Fri, 8 Jul 2005 16:41:15 +0100 Message-ID: Thread-Topic: [Pce] PCE Disco Reqs v01 Thread-Index: AcWD0GX3CcaStyTATv2qLmyHlBKRIwAAXrkQ To: X-OriginalArrivalTime: 08 Jul 2005 15:40:32.0594 (UTC) FILETIME=[603DFB20:01C583D3] X-Spam-Score: 0.3 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Igor et al, > IB>> Let me ask you something. Suppose we have VC12 layer and=20 > VC4 layer.=20 > IB>> Is > it unrealistic to expect that the same instance of the=20 > control plane manages both of them? In theory, yes the same control plane instance could be expected to manage both of them. In practice I don't believe this is possible in an awful lot of (if not all) cases due to operational (e.g. different layers are internally 'owned' by different folks), commercial (e.g. network builder type services need to supported with clear functional decoupling between the layer as each layer may be used by different commercial entities) and (possibly) regulatory reasons (e.g. what an operator uses themselves they must also offer to other operators on fair and reasonable grounds - which goes back to the operational and commercial reasons). There are plenty of other reasons too but I don't have the time/inclination to cover those.=20 There is a large and distinct difference between what is academically interesting and what is operationally possible in a commercial environment. At the end of the day it is operators that will end up fotting the bill for this not academics/vendors (even if the operators don't deploy it)! I would like to know if any operator actually intends to deploy a peer/integrated model with a single control plane instance controlling >1 layer network. =20 Ben _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Jul 08 12:40:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dqvts-00085X-DY; Fri, 08 Jul 2005 12:40:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dqvtr-00085K-18 for pce@megatron.ietf.org; Fri, 08 Jul 2005 12:40:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26856 for ; Fri, 8 Jul 2005 12:40:24 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqwL8-0004r9-JH for pce@ietf.org; Fri, 08 Jul 2005 13:08:47 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 08 Jul 2005 09:40:05 -0700 X-IronPort-AV: i="3.93,274,1115017200"; d="scan'208"; a="197164473:sNHT28035740" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j68Gdg75008970 for ; Fri, 8 Jul 2005 09:40:03 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 8 Jul 2005 12:40:02 -0400 Received: from [192.168.1.100] ([10.86.242.166]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 8 Jul 2005 12:40:02 -0400 Mime-Version: 1.0 (Apple Message framework v730) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1BA36A08-F151-478C-8A91-1EE534C1CFFB@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: [Pce] PCE Disco Reqs v01 Date: Fri, 8 Jul 2005 12:40:23 -0400 To: pce@ietf.org X-Mailer: Apple Mail (2.730) X-OriginalArrivalTime: 08 Jul 2005 16:40:02.0637 (UTC) FILETIME=[B0274FD0:01C583DB] X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi, If possible, please change the "Subject" since the discussion is no longer related to the PCE Discovery ID. JP. On Jul 8, 2005, at 11:41 AM, benjamin.niven-jenkins@bt.com wrote: > Igor et al, > > >> IB>> Let me ask you something. Suppose we have VC12 layer and >> VC4 layer. >> IB>> Is >> it unrealistic to expect that the same instance of the >> control plane manages both of them? >> > > In theory, yes the same control plane instance could be expected to > manage both of them. In practice I don't believe this is possible > in an > awful lot of (if not all) cases due to operational (e.g. different > layers are internally 'owned' by different folks), commercial (e.g. > network builder type services need to supported with clear functional > decoupling between the layer as each layer may be used by different > commercial entities) and (possibly) regulatory reasons (e.g. what an > operator uses themselves they must also offer to other operators on > fair > and reasonable grounds - which goes back to the operational and > commercial reasons). There are plenty of other reasons too but I > don't > have the time/inclination to cover those. > > There is a large and distinct difference between what is academically > interesting and what is operationally possible in a commercial > environment. At the end of the day it is operators that will end up > fotting the bill for this not academics/vendors (even if the operators > don't deploy it)! > > I would like to know if any operator actually intends to deploy a > peer/integrated model with a single control plane instance controlling > >> 1 layer network. >> > > Ben > > > > > > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Jul 08 13:43:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqwsT-0001YT-Kh; Fri, 08 Jul 2005 13:43:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqwsS-0001SX-6x for pce@megatron.ietf.org; Fri, 08 Jul 2005 13:43:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00531 for ; Fri, 8 Jul 2005 13:43:01 -0400 (EDT) Received: from webmail.movaz.com ([65.205.166.188] helo=jera.movaz.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqxJr-0007Qs-MI for pce@ietf.org; Fri, 08 Jul 2005 14:11:25 -0400 Received: from ib (vpn14.atlanta.movaz.com [172.18.0.14]) by jera.movaz.com (Postfix) with SMTP id 3E381F77; Fri, 8 Jul 2005 13:42:37 -0400 (EDT) Message-ID: <003401c583e4$6d187a30$6501a8c0@movaz.com> From: "Igor Bryskin" To: , References: Date: Fri, 8 Jul 2005 13:42:35 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Cc: Subject: [Pce] Multi-layer dynamic provisioning X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Ben, Are you saying that realistically it could not be the case when the same operator owns both VC12 and VC4 layers ? Thanks, Igor ----- Original Message ----- From: To: Sent: Friday, July 08, 2005 11:41 AM Subject: RE: [Pce] PCE Disco Reqs v01 Igor et al, > IB>> Let me ask you something. Suppose we have VC12 layer and > VC4 layer. > IB>> Is > it unrealistic to expect that the same instance of the > control plane manages both of them? In theory, yes the same control plane instance could be expected to manage both of them. In practice I don't believe this is possible in an awful lot of (if not all) cases due to operational (e.g. different layers are internally 'owned' by different folks), commercial (e.g. network builder type services need to supported with clear functional decoupling between the layer as each layer may be used by different commercial entities) and (possibly) regulatory reasons (e.g. what an operator uses themselves they must also offer to other operators on fair and reasonable grounds - which goes back to the operational and commercial reasons). There are plenty of other reasons too but I don't have the time/inclination to cover those. There is a large and distinct difference between what is academically interesting and what is operationally possible in a commercial environment. At the end of the day it is operators that will end up fotting the bill for this not academics/vendors (even if the operators don't deploy it)! I would like to know if any operator actually intends to deploy a peer/integrated model with a single control plane instance controlling >1 layer network. Ben _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Jul 08 15:50:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqyrX-0007AL-Rx; Fri, 08 Jul 2005 15:50:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqyrR-00077h-4s; Fri, 08 Jul 2005 15:50:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11675; Fri, 8 Jul 2005 15:50:07 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqzIs-0004VB-GM; Fri, 08 Jul 2005 16:18:31 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1DqyrJ-0002qs-TA; Fri, 08 Jul 2005 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 08 Jul 2005 15:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-discovery-reqs-00.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org --NextPart 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 : Requirements for Path Computation Element (PCE) Discovery Author(s) : J. Le Roux Filename : draft-ietf-pce-discovery-reqs-00.txt Pages : 13 Date : 2005-7-8 This document presents a set of requirements for a Path Computation Element (PCE) discovery mechanism that would allow a Path Computation Client (PCC) to discover dynamically and automatically a set of PCEs along with their capabilities. It is intended that solutions that specify procedures and protocol extensions for such PCE discovery satisfy these requirements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-discovery-reqs-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pce-discovery-reqs-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pce-discovery-reqs-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-7-8115144.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pce-discovery-reqs-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pce-discovery-reqs-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-7-8115144.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --NextPart-- From pce-bounces@lists.ietf.org Sat Jul 09 09:53:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrFlh-0008NE-IC; Sat, 09 Jul 2005 09:53:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrFle-0008N2-Vm for pce@megatron.ietf.org; Sat, 09 Jul 2005 09:53:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01558 for ; Sat, 9 Jul 2005 09:53:16 -0400 (EDT) From: neil.2.harrison@bt.com Received: from smtp2.smtp.bt.com ([217.32.164.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DrGDF-0004Ju-4L for pce@ietf.org; Sat, 09 Jul 2005 10:21:50 -0400 Received: from i2km99-ukbr.domain1.systemhost.net ([193.113.197.31]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 9 Jul 2005 14:53:07 +0100 Received: from i2km07-ukbr.domain1.systemhost.net ([193.113.197.26]) by i2km99-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Sat, 9 Jul 2005 14:53:07 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] Multi-layer dynamic provisioning Date: Sat, 9 Jul 2005 14:53:06 +0100 Message-ID: <0536FC9B908BEC4597EE721BE6A353890A9F1D96@i2km07-ukbr.domain1.systemhost.net> Thread-Topic: [Pce] Multi-layer dynamic provisioning Thread-Index: AcWD5JXDiMZUI2UQQp2fI/0OtGr7wgAolX1Q To: , , X-OriginalArrivalTime: 09 Jul 2005 13:53:07.0067 (UTC) FILETIME=[88D25CB0:01C5848D] X-Spam-Score: 0.3 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Igor...I will be responding in some detail to you on this one as soon as I get chance.....little bit busy at the moment, my apoplogies. regards, neil > -----Original Message----- > From: pce-bounces@lists.ietf.org=20 > [mailto:pce-bounces@lists.ietf.org] On Behalf Of Igor Bryskin > Sent: 08 July 2005 18:43 > To: Niven-jenkins,B,Ben,XDE73 R; pce@ietf.org > Subject: [Pce] Multi-layer dynamic provisioning >=20 >=20 > Ben, >=20 > Are you saying that realistically it could not be the case=20 > when the same operator owns both VC12 and VC4 layers ? >=20 > Thanks, > Igor >=20 > ----- Original Message -----=20 > From: > To: > Sent: Friday, July 08, 2005 11:41 AM > Subject: RE: [Pce] PCE Disco Reqs v01 >=20 >=20 > Igor et al, >=20 > > IB>> Let me ask you something. Suppose we have VC12 layer and > > VC4 layer. > > IB>> Is > > it unrealistic to expect that the same instance of the=20 > control plane=20 > > manages both of them? >=20 > In theory, yes the same control plane instance could be=20 > expected to manage both of them. In practice I don't believe=20 > this is possible in an awful lot of (if not all) cases due to=20 > operational (e.g. different layers are internally 'owned' by=20 > different folks), commercial (e.g. network builder type=20 > services need to supported with clear functional decoupling=20 > between the layer as each layer may be used by different=20 > commercial entities) and (possibly) regulatory reasons (e.g.=20 > what an operator uses themselves they must also offer to=20 > other operators on fair and reasonable grounds - which goes=20 > back to the operational and commercial reasons). There are=20 > plenty of other reasons too but I don't have the=20 > time/inclination to cover those. >=20 > There is a large and distinct difference between what is=20 > academically interesting and what is operationally possible=20 > in a commercial environment. At the end of the day it is=20 > operators that will end up fotting the bill for this not=20 > academics/vendors (even if the operators don't deploy it)! >=20 > I would like to know if any operator actually intends to=20 > deploy a peer/integrated model with a single control plane=20 > instance controlling > >1 layer network. >=20 > Ben >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce >=20 >=20 > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Sun Jul 10 16:54:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Drioc-0005jK-Uh; Sun, 10 Jul 2005 16:54:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Drioa-0005jF-Eh for pce@megatron.ietf.org; Sun, 10 Jul 2005 16:54:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24313 for ; Sun, 10 Jul 2005 16:54:14 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DrjGR-000617-F9 for pce@ietf.org; Sun, 10 Jul 2005 17:23:04 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 10 Jul 2005 16:54:07 -0400 X-IronPort-AV: i="3.93,277,1115006400"; d="scan'208"; a="61732619:sNHT26189220" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j6AKs6k6007195; Sun, 10 Jul 2005 16:54:06 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 10 Jul 2005 16:54:06 -0400 Received: from [192.168.1.100] ([10.86.240.213]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 10 Jul 2005 16:54:06 -0400 Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <84D4AA06-EAB8-450F-AB7D-6FF05DE040A6@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Date: Sun, 10 Jul 2005 16:54:25 -0400 To: pce@ietf.org X-Mailer: Apple Mail (2.730) X-OriginalArrivalTime: 10 Jul 2005 20:54:06.0121 (UTC) FILETIME=[82CDE190:01C58591] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: Subject: [Pce] Requirement for less-constrained path in draft-ietf-pce-comm-protocol-gen-reqs-00.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi, Quick question ... I do not see any requirement to get less- constrained TE LSP path in draft-ietf-pce-comm-protocol-gen-reqs-00.txt. In most of the cases, when configuring a TE LSP with specific attributes, one of the most challenging part consists of determining the attributes values which will not result in the inability to find a path in some circumstances (such as network element failures). The typical case is the bandwidth. The first approach is to try to compute the "closest" solutions. Another approach relies on the configuration of multiple set of attributes: 1) The preferred set of attributes 2) One or more less-preferred set of attributes 3) Un-constrained TE LSP When a PCE is used for TE LSP path computation, it looks to me that it could be quite useful to be able to specify interest in less- constrained path rather than potentially have to configure a set of attributes (less optimal) which would result in several rounds of PCC/ PCE communication. Isn't it a requirement that should be listed in draft-ietf-pce-comm- protocol-gen-reqs-00.txt? Thanks. JP. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Jul 11 07:27:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrwRY-0000Sg-Qb; Mon, 11 Jul 2005 07:27:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrwRX-0000SW-8x for pce@megatron.ietf.org; Mon, 11 Jul 2005 07:27:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01578 for ; Mon, 11 Jul 2005 07:27:21 -0400 (EDT) Received: from mail120.messagelabs.com ([216.82.255.211]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1DrwtT-0001yG-FH for pce@ietf.org; Mon, 11 Jul 2005 07:56:18 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-10.tower-120.messagelabs.com!1121081159!3508831!10 X-StarScan-Version: 5.4.15; banners=-,-,- X-Originating-IP: [192.128.133.132] Received: (qmail 14468 invoked from network); 11 Jul 2005 11:27:08 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (192.128.133.132) by server-10.tower-120.messagelabs.com with SMTP; 11 Jul 2005 11:27:08 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by attrh3i.attrh.att.com (7.2.052) id 42BED276002D0870; Mon, 11 Jul 2005 07:27:08 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] Requirement for less-constrained path indraft-ietf-pce-comm-protocol-gen-reqs-00.txt Date: Mon, 11 Jul 2005 06:27:08 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA09FA9039@KCCLUST06EVS1.ugd.att.com> Thread-Topic: [Pce] Requirement for less-constrained path indraft-ietf-pce-comm-protocol-gen-reqs-00.txt Thread-Index: AcWFkaph0kIxKPg7QW6v+or3+VvogwAeWA9g From: "Ash, Gerald R \(Jerry\), ALABS" To: "JP Vasseur" , X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi JP, > Quick question ... I do not see any requirement to get less-=20 > constrained TE LSP path in=20 > draft-ietf-pce-comm-protocol-gen-reqs-00.txt. > In most of the cases, when configuring a TE LSP with specific =20 > attributes, one of the most challenging part consists of determining =20 > the attributes values which will not result in the inability to find =20 > a path in some circumstances (such as network element failures). The =20 > typical case is the bandwidth. The first approach is to try to =20 > compute the "closest" solutions. Another approach relies on the =20 > configuration of multiple set of attributes: > 1) The preferred set of attributes > 2) One or more less-preferred set of attributes > 3) Un-constrained TE LSP >=20 > When a PCE is used for TE LSP path computation, it looks to me that =20 > it could be quite useful to be able to specify interest in less-=20 > constrained path rather than potentially have to configure a set of =20 > attributes (less optimal) which would result in several=20 > rounds of PCC/=20 > PCE communication. >=20 > Isn't it a requirement that should be listed in draft-ietf-pce-comm-=20 > protocol-gen-reqs-00.txt? Sounds OK to me. It would help if you suggested some specific text to insert in the updated draft sent out last Thursday. Thanks, Jerry _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Jul 11 11:09:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Drzue-0004aV-CQ; Mon, 11 Jul 2005 11:09:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Drzud-0004Zh-Mb for pce@megatron.ietf.org; Mon, 11 Jul 2005 11:09:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20509 for ; Mon, 11 Jul 2005 11:09:37 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ds0MZ-0003av-6w for pce@ietf.org; Mon, 11 Jul 2005 11:38:37 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id j6BF8Eb6002667; Mon, 11 Jul 2005 11:08:14 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA21165; Mon, 11 Jul 2005 11:08:16 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id ; Mon, 11 Jul 2005 11:08:15 -0400 Message-ID: <313680C9A886D511A06000204840E1CF0C885CBD@whq-msgusr-02.pit.comms.marconi.com> From: "Gray, Eric" To: "'Ash, Gerald R (Jerry), ALABS'" , JP Vasseur Subject: RE: [Pce] Requirement for less-constrained path indraft-ietf-pce- comm-protocol-gen-reqs-00.txt Date: Mon, 11 Jul 2005 11:08:15 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Jerry & JP, I am not so sure that this should be a requirement. Requiring the protocol to support finding alternate paths (by a near-arbitrary collections of fuzzy parameters) is very likely to push both the process of coming up with any proposed solution that meets this requirement - and yet remains scalable - and the process of getting agreement for any such proposed solution. I suggest that we might want to better understand the specific customer need - and what the customer is willing to sacrifice in other areas - before we include something like this as a requirement. Short of getting that information, simply stating that this might be a preference - or a desirable goal - is about as strong as I would put it. -- Eric --> -----Original Message----- --> From: pce-bounces@lists.ietf.org --> [mailto:pce-bounces@lists.ietf.org]On --> Behalf Of Ash, Gerald R (Jerry), ALABS --> Sent: Monday, July 11, 2005 7:27 AM --> To: JP Vasseur; pce@ietf.org --> Subject: RE: [Pce] Requirement for less-constrained path --> indraft-ietf-pce-comm-protocol-gen-reqs-00.txt --> --> --> Hi JP, --> --> > Quick question ... I do not see any requirement to get less- --> > constrained TE LSP path in --> > draft-ietf-pce-comm-protocol-gen-reqs-00.txt. --> > In most of the cases, when configuring a TE LSP with specific --> > attributes, one of the most challenging part consists of --> determining --> > the attributes values which will not result in the --> inability to find --> > a path in some circumstances (such as network element --> failures). The --> > typical case is the bandwidth. The first approach is to try to --> > compute the "closest" solutions. Another approach relies on the --> > configuration of multiple set of attributes: --> > 1) The preferred set of attributes --> > 2) One or more less-preferred set of attributes --> > 3) Un-constrained TE LSP --> > --> > When a PCE is used for TE LSP path computation, it looks --> to me that --> > it could be quite useful to be able to specify interest in less- --> > constrained path rather than potentially have to --> configure a set of --> > attributes (less optimal) which would result in several --> > rounds of PCC/ --> > PCE communication. --> > --> > Isn't it a requirement that should be listed in --> draft-ietf-pce-comm- --> > protocol-gen-reqs-00.txt? --> --> Sounds OK to me. It would help if you suggested some --> specific text to --> insert in the updated draft sent out last Thursday. --> --> Thanks, --> Jerry --> --> _______________________________________________ --> Pce mailing list --> Pce@lists.ietf.org --> https://www1.ietf.org/mailman/listinfo/pce --> _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Jul 11 12:57:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds1ar-0001mO-Gm; Mon, 11 Jul 2005 12:57:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds1ap-0001m4-B9 for pce@megatron.ietf.org; Mon, 11 Jul 2005 12:57:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29458 for ; Mon, 11 Jul 2005 12:57:16 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ds22r-000895-26 for pce@ietf.org; Mon, 11 Jul 2005 13:26:18 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Ds1al-0007mT-MY for pce@ietf.org; Mon, 11 Jul 2005 12:57:15 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 11 Jul 2005 09:51:25 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,279,1115017200"; d="scan'208"; a="1298580:sNHT23095648" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j6BGpPVu001747; Mon, 11 Jul 2005 12:51:25 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 11 Jul 2005 12:51:25 -0400 Received: from [161.44.70.216] ([161.44.70.216]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 11 Jul 2005 12:51:24 -0400 In-Reply-To: <313680C9A886D511A06000204840E1CF0C885CBD@whq-msgusr-02.pit.comms.marconi.com> References: <313680C9A886D511A06000204840E1CF0C885CBD@whq-msgusr-02.pit.comms.marconi.com> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: [Pce] Requirement for less-constrained path indraft-ietf-pce- comm-protocol-gen-reqs-00.txt Date: Mon, 11 Jul 2005 12:51:43 -0400 To: "Gray, Eric" X-Mailer: Apple Mail (2.730) X-OriginalArrivalTime: 11 Jul 2005 16:51:24.0572 (UTC) FILETIME=[C5DB95C0:01C58638] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Content-Transfer-Encoding: 7bit Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi Eric, On Jul 11, 2005, at 11:08 AM, Gray, Eric wrote: > Jerry & JP, > > I am not so sure that this should be a requirement. > > Requiring the protocol to support finding alternate > paths (by a near-arbitrary collections of fuzzy parameters) > Does not have to be arbitrary ;-) See the related section in the PCEP protocol ... > is very likely to push both the process of coming up with > any proposed solution that meets this requirement - and yet > remains scalable - and the process of getting agreement for > any such proposed solution. Ah but this is the opposite goal: to increase the scalability. What would a PCC receiving a negative reply do unless resending additional path computation request(s) with different parameter(s) ? Thus having such capability would be quite useful but I'll let the Service Providers who will actually use that solution voice their opinion. In my previous email, I was just reflecting the outcome of some discussions that I had with several of them, thus asking whether such requirement had not be missed ? JP. > I suggest that we might want to better understand the > specific customer need - and what the customer is willing > to sacrifice in other areas - before we include something > like this as a requirement. > > Short of getting that information, simply stating that > this might be a preference - or a desirable goal - is about > as strong as I would put it. > > -- > Eric > > --> -----Original Message----- > --> From: pce-bounces@lists.ietf.org > --> [mailto:pce-bounces@lists.ietf.org]On > --> Behalf Of Ash, Gerald R (Jerry), ALABS > --> Sent: Monday, July 11, 2005 7:27 AM > --> To: JP Vasseur; pce@ietf.org > --> Subject: RE: [Pce] Requirement for less-constrained path > --> indraft-ietf-pce-comm-protocol-gen-reqs-00.txt > --> > --> > --> Hi JP, > --> > --> > Quick question ... I do not see any requirement to get less- > --> > constrained TE LSP path in > --> > draft-ietf-pce-comm-protocol-gen-reqs-00.txt. > --> > In most of the cases, when configuring a TE LSP with specific > --> > attributes, one of the most challenging part consists of > --> determining > --> > the attributes values which will not result in the > --> inability to find > --> > a path in some circumstances (such as network element > --> failures). The > --> > typical case is the bandwidth. The first approach is to try to > --> > compute the "closest" solutions. Another approach relies on the > --> > configuration of multiple set of attributes: > --> > 1) The preferred set of attributes > --> > 2) One or more less-preferred set of attributes > --> > 3) Un-constrained TE LSP > --> > > --> > When a PCE is used for TE LSP path computation, it looks > --> to me that > --> > it could be quite useful to be able to specify interest in less- > --> > constrained path rather than potentially have to > --> configure a set of > --> > attributes (less optimal) which would result in several > --> > rounds of PCC/ > --> > PCE communication. > --> > > --> > Isn't it a requirement that should be listed in > --> draft-ietf-pce-comm- > --> > protocol-gen-reqs-00.txt? > --> > --> Sounds OK to me. It would help if you suggested some > --> specific text to > --> insert in the updated draft sent out last Thursday. > --> > --> Thanks, > --> Jerry > --> > --> _______________________________________________ > --> Pce mailing list > --> Pce@lists.ietf.org > --> https://www1.ietf.org/mailman/listinfo/pce > --> > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Jul 11 13:03:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds1hC-0004VW-Ks; Mon, 11 Jul 2005 13:03:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds1hB-0004VK-6i for pce@megatron.ietf.org; Mon, 11 Jul 2005 13:03:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00720 for ; Mon, 11 Jul 2005 13:03:50 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ds29C-0008Ss-A1 for pce@ietf.org; Mon, 11 Jul 2005 13:32:52 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 11 Jul 2005 13:03:40 -0400 X-IronPort-AV: i="3.93,279,1115006400"; d="scan'208"; a="61838977:sNHT29949116" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j6BH3ek6015813; Mon, 11 Jul 2005 13:03:40 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 11 Jul 2005 13:03:40 -0400 Received: from [161.44.70.216] ([161.44.70.216]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 11 Jul 2005 13:03:40 -0400 Mime-Version: 1.0 (Apple Message framework v730) In-Reply-To: <9473683187ADC049A855ED2DA739ABCA09FA9039@KCCLUST06EVS1.ugd.att.com> References: <9473683187ADC049A855ED2DA739ABCA09FA9039@KCCLUST06EVS1.ugd.att.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2C689750-E158-4012-BED4-95D9D8EC6846@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Date: Mon, 11 Jul 2005 13:03:58 -0400 To: "Ash, Gerald R ((Jerry)), ALABS" , pce@ietf.org X-Mailer: Apple Mail (2.730) X-OriginalArrivalTime: 11 Jul 2005 17:03:40.0032 (UTC) FILETIME=[7C39E000:01C5863A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Cc: Subject: [Pce] WG opinion on Requirement for less-constrained path indraft-ietf-pce-comm-protocol-gen-reqs-00.txt ??? X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi Jerry, On Jul 11, 2005, at 7:27 AM, Ash, Gerald R ((Jerry)), ALABS wrote: > Hi JP, > > >> Quick question ... I do not see any requirement to get less- >> constrained TE LSP path in >> draft-ietf-pce-comm-protocol-gen-reqs-00.txt. >> In most of the cases, when configuring a TE LSP with specific >> attributes, one of the most challenging part consists of determining >> the attributes values which will not result in the inability to find >> a path in some circumstances (such as network element failures). The >> typical case is the bandwidth. The first approach is to try to >> compute the "closest" solutions. Another approach relies on the >> configuration of multiple set of attributes: >> 1) The preferred set of attributes >> 2) One or more less-preferred set of attributes >> 3) Un-constrained TE LSP >> >> When a PCE is used for TE LSP path computation, it looks to me that >> it could be quite useful to be able to specify interest in less- >> constrained path rather than potentially have to configure a set of >> attributes (less optimal) which would result in several >> rounds of PCC/ >> PCE communication. >> >> Isn't it a requirement that should be listed in draft-ietf-pce-comm- >> protocol-gen-reqs-00.txt? >> > > Sounds OK to me. It would help if you suggested some specific text to > insert in the updated draft sent out last Thursday. > Of course, I do not want to request for additional requirements if SPs do not require such capabilities of course, thus I'll let SPs voice their opinion and in particular whether it should be a MAY, SHOULD or MUST. Opinion from the WG ? JP. > Thanks, > Jerry > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Jul 11 13:18:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds1vY-0008VS-BF; Mon, 11 Jul 2005 13:18:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds1vW-0008VJ-Qm for pce@megatron.ietf.org; Mon, 11 Jul 2005 13:18:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02688 for ; Mon, 11 Jul 2005 13:18:38 -0400 (EDT) Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ds2NW-0000ZR-Bc for pce@ietf.org; Mon, 11 Jul 2005 13:47:40 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Mon, 11 Jul 2005 19:18:23 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE : [Pce] Requirement for less-constrained path indraft-ietf-pce-comm-protocol-gen-reqs-00.txt Date: Mon, 11 Jul 2005 19:18:17 +0200 Message-ID: Thread-Topic: [Pce] Requirement for less-constrained path indraft-ietf-pce-comm-protocol-gen-reqs-00.txt Thread-Index: AcWGKrKZ5kxZ7HUfRcO466KE/PJ2UgAEYNIw From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "Gray, Eric" , "Ash, Gerald R \(Jerry\), ALABS" , "JP Vasseur" X-OriginalArrivalTime: 11 Jul 2005 17:18:23.0421 (UTC) FILETIME=[8AC456D0:01C5863C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Content-Transfer-Encoding: quoted-printable Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi Eric, It seems that this is a well knwow MPLS-TE problem. When one cannot find = a path satifying a set of constraints it tries to relax some = constraints. IMHO communication of less constrained path is at least a = "SHOULD" requirement... This will avoid useless PCC-PCE round trips. >is very likely to push both the process of coming up with >any proposed solution that meets this requirement This is IMHO a simple problem (at least w.r.t the communication = protocol, for the algorithm this is another issue but out of the scope = of this draft) and we can find simple ways to address it. I don't think = that there are so many solutions to address this requirement in the = communication protocol. Anyway this is not our problem in a requirement = draft... > - and yet >remains scalable - and the process of getting agreement for=20 >any such proposed solution. I don't actually see why this should make us renounce to this = requirement... > I suggest that we might want to better understand the specific=20 >customer need - and what the customer is willing to sacrifice in other=20 >areas - before we include something like this as a requirement. Detailed motivations and needs will be addressed in the requirement doc Best Regards, JL >-----Message d'origine----- >De : pce-bounces@lists.ietf.org=20 >[mailto:pce-bounces@lists.ietf.org] De la part de Gray, Eric >Envoy=E9 : lundi 11 juillet 2005 17:08 >=C0 : 'Ash, Gerald R (Jerry), ALABS'; JP Vasseur >Cc : pce@ietf.org >Objet : RE: [Pce] Requirement for less-constrained path=20 >indraft-ietf-pce-comm-protocol-gen-reqs-00.txt > > >Jerry & JP, > > I am not so sure that this should be a requirement. > > Requiring the protocol to support finding alternate >paths (by a near-arbitrary collections of fuzzy parameters) >is very likely to push both the process of coming up with=20 >any proposed solution that meets this requirement - and yet=20 >remains scalable - and the process of getting agreement for=20 >any such proposed solution. > > I suggest that we might want to better understand the >specific customer need - and what the customer is willing=20 >to sacrifice in other areas - before we include something=20 >like this as a requirement. > > Short of getting that information, simply stating that=20 >this might be a preference - or a desirable goal - is about >as strong as I would put it. > >-- >Eric > >--> -----Original Message----- >--> From: pce-bounces@lists.ietf.org >--> [mailto:pce-bounces@lists.ietf.org]On >--> Behalf Of Ash, Gerald R (Jerry), ALABS >--> Sent: Monday, July 11, 2005 7:27 AM >--> To: JP Vasseur; pce@ietf.org >--> Subject: RE: [Pce] Requirement for less-constrained path >--> indraft-ietf-pce-comm-protocol-gen-reqs-00.txt >-->=20 >-->=20 >--> Hi JP, >-->=20 >--> > Quick question ... I do not see any requirement to get less- >--> > constrained TE LSP path in=20 >--> > draft-ietf-pce-comm-protocol-gen-reqs-00.txt. >--> > In most of the cases, when configuring a TE LSP with specific =20 >--> > attributes, one of the most challenging part consists of=20 >--> determining >--> > the attributes values which will not result in the >--> inability to find >--> > a path in some circumstances (such as network element >--> failures). The >--> > typical case is the bandwidth. The first approach is to try to >--> > compute the "closest" solutions. Another approach relies on the =20 >--> > configuration of multiple set of attributes: >--> > 1) The preferred set of attributes >--> > 2) One or more less-preferred set of attributes >--> > 3) Un-constrained TE LSP >--> >=20 >--> > When a PCE is used for TE LSP path computation, it looks >--> to me that >--> > it could be quite useful to be able to specify interest in less- >--> > constrained path rather than potentially have to=20 >--> configure a set of >--> > attributes (less optimal) which would result in several >--> > rounds of PCC/=20 >--> > PCE communication. >--> >=20 >--> > Isn't it a requirement that should be listed in >--> draft-ietf-pce-comm- >--> > protocol-gen-reqs-00.txt? >-->=20 >--> Sounds OK to me. It would help if you suggested some >--> specific text to >--> insert in the updated draft sent out last Thursday. >-->=20 >--> Thanks, >--> Jerry >-->=20 >--> _______________________________________________ >--> Pce mailing list >--> Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce >-->=20 > >_______________________________________________ >Pce mailing list >Pce@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/pce > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Jul 11 14:50:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds3MF-0007PO-Vp; Mon, 11 Jul 2005 14:50:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds3ME-0007PJ-0t for pce@megatron.ietf.org; Mon, 11 Jul 2005 14:50:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10197 for ; Mon, 11 Jul 2005 14:50:20 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ds3oD-0004Em-6L for pce@ietf.org; Mon, 11 Jul 2005 15:19:21 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 11 Jul 2005 11:45:48 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j6BIjivY023155 for ; Mon, 11 Jul 2005 11:45:45 -0700 (PDT) Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 11 Jul 2005 11:45:40 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Pce] Adoption of draft-leroux-pce-discovery-reqs-01.txt as WGdocument ? Date: Mon, 11 Jul 2005 11:45:40 -0700 Message-ID: <70BC84B185C3EE448EDB7AB8956D3B0E5E3B8A@xmb-sjc-234.amer.cisco.com> Thread-Topic: [Pce] Adoption of draft-leroux-pce-discovery-reqs-01.txt as WGdocument ? Thread-Index: AcV9e5OEGHXT1RhnQYWof4TwtjFbzAIzPQOw From: "Dean Cheng \(dcheng\)" To: "Jean Philippe Vasseur \(jvasseur\)" , X-OriginalArrivalTime: 11 Jul 2005 18:45:40.0965 (UTC) FILETIME=[BC962150:01C58648] X-Spam-Score: 0.7 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1312344842==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1312344842== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C58648.BC83E6BC" This is a multi-part message in MIME format. ------_=_NextPart_001_01C58648.BC83E6BC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > Could you provide us your feed-back on adopting draft-leroux-discovery-reqs-01.txt as a WG document? I support it to be a WG document. Dean ________________________________ From: pce-bounces@lists.ietf.org [mailto:pce-bounces@lists.ietf.org] On Behalf Of Jean Philippe Vasseur (jvasseur) Sent: Thursday, June 30, 2005 6:53 AM To: pce@ietf.org Subject: [Pce] Adoption of draft-leroux-pce-discovery-reqs-01.txt as WGdocument ? =09 =09 Dear WG, draft-leroux-discovery-reqs has just been re-published, addressing several of comments received during the last meeting and on the list (very few remaining open items). Could you provide us your feed-back on adopting draft-leroux-discovery-reqs-01.txt as a WG document ? JP and Adrian. ------_=_NextPart_001_01C58648.BC83E6BC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

> Could you provide us your feed-back on adopting=20 draft-leroux-discovery-reqs-01.txt as a WG=20 document?

I support it to be a = WG=20 document.

Dean


From: pce-bounces@lists.ietf.org=20 [mailto:pce-bounces@lists.ietf.org] On Behalf Of Jean Philippe = Vasseur=20 (jvasseur)
Sent: Thursday, June 30, 2005 6:53 = AM
To:=20 pce@ietf.org
Subject: [Pce] Adoption of=20 draft-leroux-pce-discovery-reqs-01.txt as WGdocument = ?

Dear = WG,

draft-leroux-discovery-reqs has just = been=20 re-published, addressing several of comments received during the last = meeting=20 and on the list (very few remaining open items).

Could you provide us your feed-back = on=20 adopting draft-leroux-discovery-reqs-01.txt as a WG document ?

JP and = Adrian.

------_=_NextPart_001_01C58648.BC83E6BC-- --===============1312344842== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============1312344842==-- From pce-bounces@lists.ietf.org Mon Jul 11 15:04:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds3Zk-0002Z8-9j; Mon, 11 Jul 2005 15:04:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds3Zi-0002YD-GO for pce@megatron.ietf.org; Mon, 11 Jul 2005 15:04:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11446 for ; Mon, 11 Jul 2005 15:04:16 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ds41j-0004oH-TV for pce@ietf.org; Mon, 11 Jul 2005 15:33:18 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id j6BJ41b6008700; Mon, 11 Jul 2005 15:04:01 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA20064; Mon, 11 Jul 2005 15:04:03 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id ; Mon, 11 Jul 2005 15:04:02 -0400 Message-ID: <313680C9A886D511A06000204840E1CF0C885CC0@whq-msgusr-02.pit.comms.marconi.com> From: "Gray, Eric" To: "'JP Vasseur'" Subject: RE: [Pce] Requirement for less-constrained path indraft-ietf-pce- comm-protocol-gen-reqs-00.txt Date: Mon, 11 Jul 2005 15:04:01 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org JP, I assume from your reply that I understood correctly what you are asking about, but let me check. I believe you are asking for one of two things: an information bearing NAK used to narrow down the PCC choices for subsequent requests or a menu-selection request followed by somewhat complicated PCE response handling. In the first case, the idea is to have the PCE return additional information about "less than requested" Path capabilities as opposed to simply returning a NAK for the unsatisfiable request. In theory, this would reduce request- response transactions if you make two or three assumptions: 1) The PCC will make subsequent requests for a Path that might also be unsatisfiable if its initial request fails, AND 2) The fail-back options are uniform through-out a service and well understood prior to protocol definition, implementation and deployment, negotiable on a case-by-case basis within the protocol, or both reasonably well understood in advance and negotiable in signaling; 3) It may also be necessary to assume that Path requests do not arrive from PCCs at a frequent enough rate to result in inconsistent behavior. If the fail-back approach is to request a Path with no committed resources if initial requests fail for Paths with committed resources, then subsequent requests will succeed (if there is a route) and there would be no reduction in dialogue with information about alternative Path availability - nor any particularly useful information to offer - in a NAK. Therefore we must assume that the second request would also require some commitment of resources. If the PCC might wish to make a subsequent request, then the PCE needs to know what the sensitive parameters are and how much tolerance there is in order to provide useful information in a NAK. This would be complex. Finally, depending on the frequency with which the PCE is bombarded with requests, it (the PCE) may be unable to satisfy a second request as a result of resource commitments made after the first response and before the second request. All that taken into account, I believe you are suggesting the second alternative - requests with menu-selection options. That is, "if you can't get me a Path that looks like this, then I'll take one that looks like that; if you can't get me a path that looks like that, ... then I'll take just any old path you can give me." I can well imagine that service providers may want this, even given the complexity associated with defining a service around it, but that is not the only question we need to have answered. The other question is what are customers willing to give up to get it? There can be no question that this adds complexity to the protocol. Is the PCE useless without it? Is the PCE sufficiently hampered without it that it's worth additional time to include it? Is there no service provider out there that is interested in a less complex (and expensive) approach? And - perhaps the most important question of all - is it necessary to include this capability in a first go round, or can we define extension and compatibility mechanisms that will allow us to include it in a subsequent iteration? These questions are among those that should be asked before we decide to accept this as a requirement... -- Eric --> -----Original Message----- --> From: JP Vasseur [mailto:jvasseur@cisco.com] --> Sent: Monday, July 11, 2005 12:52 PM --> To: Gray, Eric --> Cc: 'Ash, Gerald R (Jerry), ALABS'; pce@ietf.org --> Subject: Re: [Pce] Requirement for less-constrained path --> indraft-ietf-pce- comm-protocol-gen-reqs-00.txt --> --> --> Hi Eric, --> --> On Jul 11, 2005, at 11:08 AM, Gray, Eric wrote: --> --> > Jerry & JP, --> > --> > I am not so sure that this should be a requirement. --> > --> > Requiring the protocol to support finding alternate --> > paths (by a near-arbitrary collections of fuzzy parameters) --> > --> --> Does not have to be arbitrary ;-) See the related section --> in the PCEP --> protocol ... --> --> > is very likely to push both the process of coming up with --> > any proposed solution that meets this requirement - and yet --> > remains scalable - and the process of getting agreement for --> > any such proposed solution. --> --> Ah but this is the opposite goal: to increase the --> scalability. What --> would a PCC receiving a negative reply do unless resending --> additional --> path computation request(s) with different parameter(s) ? --> Thus having --> such capability would be quite useful but I'll let the Service --> Providers who will actually use that solution voice their --> opinion. In --> my previous email, I was just reflecting the outcome of some --> discussions that I had with several of them, thus asking --> whether such --> requirement had not be missed ? --> --> JP. --> --> > I suggest that we might want to better understand the --> > specific customer need - and what the customer is willing --> > to sacrifice in other areas - before we include something --> > like this as a requirement. --> > --> > Short of getting that information, simply stating that --> > this might be a preference - or a desirable goal - is about --> > as strong as I would put it. --> > --> > -- --> > Eric --> > --> > --> -----Original Message----- --> > --> From: pce-bounces@lists.ietf.org --> > --> [mailto:pce-bounces@lists.ietf.org]On --> > --> Behalf Of Ash, Gerald R (Jerry), ALABS --> > --> Sent: Monday, July 11, 2005 7:27 AM --> > --> To: JP Vasseur; pce@ietf.org --> > --> Subject: RE: [Pce] Requirement for less-constrained path --> > --> indraft-ietf-pce-comm-protocol-gen-reqs-00.txt --> > --> --> > --> --> > --> Hi JP, --> > --> --> > --> > Quick question ... I do not see any requirement to get less- --> > --> > constrained TE LSP path in --> > --> > draft-ietf-pce-comm-protocol-gen-reqs-00.txt. --> > --> > In most of the cases, when configuring a TE LSP --> with specific --> > --> > attributes, one of the most challenging part consists of --> > --> determining --> > --> > the attributes values which will not result in the --> > --> inability to find --> > --> > a path in some circumstances (such as network element --> > --> failures). The --> > --> > typical case is the bandwidth. The first approach --> is to try to --> > --> > compute the "closest" solutions. Another approach --> relies on the --> > --> > configuration of multiple set of attributes: --> > --> > 1) The preferred set of attributes --> > --> > 2) One or more less-preferred set of attributes --> > --> > 3) Un-constrained TE LSP --> > --> > --> > --> > When a PCE is used for TE LSP path computation, it looks --> > --> to me that --> > --> > it could be quite useful to be able to specify --> interest in less- --> > --> > constrained path rather than potentially have to --> > --> configure a set of --> > --> > attributes (less optimal) which would result in several --> > --> > rounds of PCC/ --> > --> > PCE communication. --> > --> > --> > --> > Isn't it a requirement that should be listed in --> > --> draft-ietf-pce-comm- --> > --> > protocol-gen-reqs-00.txt? --> > --> --> > --> Sounds OK to me. It would help if you suggested some --> > --> specific text to --> > --> insert in the updated draft sent out last Thursday. --> > --> --> > --> Thanks, --> > --> Jerry --> > --> --> > --> _______________________________________________ --> > --> Pce mailing list --> > --> Pce@lists.ietf.org --> > --> https://www1.ietf.org/mailman/listinfo/pce --> > --> --> > --> _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Jul 11 18:29:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds6lu-00010T-W4; Mon, 11 Jul 2005 18:29:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds6lt-0000w5-7V for pce@megatron.ietf.org; Mon, 11 Jul 2005 18:29:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26753 for ; Mon, 11 Jul 2005 18:29:02 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ds7Dy-0005Fb-8k for pce@ietf.org; Mon, 11 Jul 2005 18:58:06 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 11 Jul 2005 15:28:56 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,280,1115017200"; d="scan'208"; a="1349106:sNHT25684764" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j6BMStk6009920; Mon, 11 Jul 2005 18:28:55 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 11 Jul 2005 18:28:54 -0400 Received: from [161.44.70.216] ([161.44.70.216]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 11 Jul 2005 18:28:54 -0400 In-Reply-To: <313680C9A886D511A06000204840E1CF0C885CC0@whq-msgusr-02.pit.comms.marconi.com> References: <313680C9A886D511A06000204840E1CF0C885CC0@whq-msgusr-02.pit.comms.marconi.com> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <01C7FD07-D870-4A95-BBBD-7C9F2CC30DE2@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: [Pce] Requirement for less-constrained path indraft-ietf-pce- comm-protocol-gen-reqs-00.txt Date: Mon, 11 Jul 2005 18:29:13 -0400 To: "Gray, Eric" X-Mailer: Apple Mail (2.730) X-OriginalArrivalTime: 11 Jul 2005 22:28:54.0779 (UTC) FILETIME=[EBEBF4B0:01C58667] X-Spam-Score: 2.0 (++) X-Scan-Signature: 83e9494d829b08cc3f644ef6ac1b9bd4 Content-Transfer-Encoding: 7bit Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi Eric, On Jul 11, 2005, at 3:04 PM, Gray, Eric wrote: > JP, > > I assume from your reply that I understood correctly > what you are asking about, but let me check. I believe you > are asking for one of two things: an information bearing NAK > used to narrow down the PCC choices for subsequent requests > or a menu-selection request followed by somewhat complicated > PCE response handling. > > In the first case, the idea is to have the PCE return > additional information about "less than requested" Path > capabilities as opposed to simply returning a NAK for the > unsatisfiable request. In theory, this would reduce request- > response transactions if you make two or three assumptions: > > 1) The PCC will make subsequent requests for a Path > that might also be unsatisfiable if its initial > request fails, AND And this will likely to be the case ... There are of course various possible scenarios but consider the case of a PCE-based inter-area TE LSP path computation. What would you expect the PCC to do, should it receive a negative reply from the PCE ? Probably try to give up on some constraints so as to find a path and signal the TE LSP (you may also fall-back to IGP routing but give up on FRR in this case). Thus getting a less constrained path from the PCE could be of interested, effectively cutting down the communication protocol overhead and signalling delay. This is of course especially true if the PCC has to go through multiple rounds before getting a path. > 2) The fail-back options are uniform through-out a > service and well understood prior to protocol > definition, implementation and deployment, > negotiable on a case-by-case basis within the > protocol, or both reasonably well understood in > advance and negotiable in signaling; Quite realistic. > 3) It may also be necessary to assume that Path > requests do not arrive from PCCs at a frequent > enough rate to result in inconsistent behavior. > I do not think so. I'd like to stress the following fact: having such capability would actually drastically reduce the communication overhead compared to the co-located PCE scenario in case of path computation failure. > If the fail-back approach is to request a Path with no > committed resources if initial requests fail for Paths with > committed resources, then subsequent requests will succeed (if > there is a route) and there would be no reduction in dialogue > with information about alternative Path availability - nor any > particularly useful information to offer - in a NAK. No, this is not correct. You may still want to know the shortest unconstrained path (consider the case of inter-domain for example). Furthermore, you do not need to go from "fully satisfied" to "No committed resources". If the PCC wants to get the shortest path for a TE LSP of X Mbits/s. Don't you think that it would be valuable to know the shortest path with the closest bandwidth value to the initial request (X) ? > Therefore > we must assume that the second request would also require some > commitment of resources. > See above. > If the PCC might wish to make a subsequent request, then > the PCE needs to know what the sensitive parameters are and how > much tolerance there is in order to provide useful information > in a NAK. This would be complex. > You can either provide a boolean behavior to start with (Full satisfied to Unconstrained -> Still valuable) or provide the ability for the PCC to specify a hierarchical constraints relaxation policy. You usually do not have that many constraints, and SP do know their order of preference in term of constraints relaxation. > Finally, depending on the frequency with which the PCE is > bombarded with requests, it (the PCE) may be unable to satisfy > a second request as a result of resource commitments made after > the first response and before the second request. > It really depends of your PCE implementation. You can reduce that probability. > All that taken into account, I believe you are suggesting > the second alternative - requests with menu-selection options. > That is, "if you can't get me a Path that looks like this, then > I'll take one that looks like that; if you can't get me a path > that looks like that, ... then I'll take just any old path you > can give me." > > I can well imagine that service providers may want this, > even given the complexity associated with defining a service > around it, Note that there are many such deployments already. > but that is not the only question we need to have > answered. The other question is what are customers willing to > give up to get it? This is a completely different question. In any case, if you do not have a path satisfying your constraints, you have to give up on something but this has nothing to do with the PCE-based path computation. > > There can be no question that this adds complexity to the > protocol. Is the PCE useless without it? Is the PCE sufficiently > hampered without it that it's worth additional time to include it? > Is there no service provider out there that is interested in a > less complex (and expensive) approach? > > And - perhaps the most important question of all - is it > necessary to include this capability in a first go round, or can > we define extension and compatibility mechanisms that will allow > us to include it in a subsequent iteration? > The discussion on protocol overhead, complexity and so on should follow once we discuss communication protocol. My question was related to the requirement for such capability ? > These questions are among those that should be asked before > we decide to accept this as a requirement... > Again, note that I did not ask to add this as a requirement. Just a question to the WG on whether this was a requirement. JP. > -- > Eric > > --> -----Original Message----- > --> From: JP Vasseur [mailto:jvasseur@cisco.com] > --> Sent: Monday, July 11, 2005 12:52 PM > --> To: Gray, Eric > --> Cc: 'Ash, Gerald R (Jerry), ALABS'; pce@ietf.org > --> Subject: Re: [Pce] Requirement for less-constrained path > --> indraft-ietf-pce- comm-protocol-gen-reqs-00.txt > --> > --> > --> Hi Eric, > --> > --> On Jul 11, 2005, at 11:08 AM, Gray, Eric wrote: > --> > --> > Jerry & JP, > --> > > --> > I am not so sure that this should be a requirement. > --> > > --> > Requiring the protocol to support finding alternate > --> > paths (by a near-arbitrary collections of fuzzy parameters) > --> > > --> > --> Does not have to be arbitrary ;-) See the related section > --> in the PCEP > --> protocol ... > --> > --> > is very likely to push both the process of coming up with > --> > any proposed solution that meets this requirement - and yet > --> > remains scalable - and the process of getting agreement for > --> > any such proposed solution. > --> > --> Ah but this is the opposite goal: to increase the > --> scalability. What > --> would a PCC receiving a negative reply do unless resending > --> additional > --> path computation request(s) with different parameter(s) ? > --> Thus having > --> such capability would be quite useful but I'll let the Service > --> Providers who will actually use that solution voice their > --> opinion. In > --> my previous email, I was just reflecting the outcome of some > --> discussions that I had with several of them, thus asking > --> whether such > --> requirement had not be missed ? > --> > --> JP. > --> > --> > I suggest that we might want to better understand the > --> > specific customer need - and what the customer is willing > --> > to sacrifice in other areas - before we include something > --> > like this as a requirement. > --> > > --> > Short of getting that information, simply stating that > --> > this might be a preference - or a desirable goal - is about > --> > as strong as I would put it. > --> > > --> > -- > --> > Eric > --> > > --> > --> -----Original Message----- > --> > --> From: pce-bounces@lists.ietf.org > --> > --> [mailto:pce-bounces@lists.ietf.org]On > --> > --> Behalf Of Ash, Gerald R (Jerry), ALABS > --> > --> Sent: Monday, July 11, 2005 7:27 AM > --> > --> To: JP Vasseur; pce@ietf.org > --> > --> Subject: RE: [Pce] Requirement for less-constrained path > --> > --> indraft-ietf-pce-comm-protocol-gen-reqs-00.txt > --> > --> > --> > --> > --> > --> Hi JP, > --> > --> > --> > --> > Quick question ... I do not see any requirement to get > less- > --> > --> > constrained TE LSP path in > --> > --> > draft-ietf-pce-comm-protocol-gen-reqs-00.txt. > --> > --> > In most of the cases, when configuring a TE LSP > --> with specific > --> > --> > attributes, one of the most challenging part consists of > --> > --> determining > --> > --> > the attributes values which will not result in the > --> > --> inability to find > --> > --> > a path in some circumstances (such as network element > --> > --> failures). The > --> > --> > typical case is the bandwidth. The first approach > --> is to try to > --> > --> > compute the "closest" solutions. Another approach > --> relies on the > --> > --> > configuration of multiple set of attributes: > --> > --> > 1) The preferred set of attributes > --> > --> > 2) One or more less-preferred set of attributes > --> > --> > 3) Un-constrained TE LSP > --> > --> > > --> > --> > When a PCE is used for TE LSP path computation, it looks > --> > --> to me that > --> > --> > it could be quite useful to be able to specify > --> interest in less- > --> > --> > constrained path rather than potentially have to > --> > --> configure a set of > --> > --> > attributes (less optimal) which would result in several > --> > --> > rounds of PCC/ > --> > --> > PCE communication. > --> > --> > > --> > --> > Isn't it a requirement that should be listed in > --> > --> draft-ietf-pce-comm- > --> > --> > protocol-gen-reqs-00.txt? > --> > --> > --> > --> Sounds OK to me. It would help if you suggested some > --> > --> specific text to > --> > --> insert in the updated draft sent out last Thursday. > --> > --> > --> > --> Thanks, > --> > --> Jerry > --> > --> > --> > --> _______________________________________________ > --> > --> Pce mailing list > --> > --> Pce@lists.ietf.org > --> > --> https://www1.ietf.org/mailman/listinfo/pce > --> > --> > --> > > --> > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Jul 11 18:36:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds6sc-0004I3-Qv; Mon, 11 Jul 2005 18:36:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds6sb-0004Gz-HN for pce@megatron.ietf.org; Mon, 11 Jul 2005 18:36:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27179 for ; Mon, 11 Jul 2005 18:35:58 -0400 (EDT) Received: from relay2.mail.uk.clara.net ([80.168.70.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ds7Kf-0005UU-V3 for pce@ietf.org; Mon, 11 Jul 2005 19:05:03 -0400 Received: from du-069-0214.access.clara.net ([217.158.132.214] helo=Puppy) by relay2.mail.uk.clara.net with smtp (Exim 4.50) id 1Ds6sM-000DN3-70 for pce@ietf.org; Mon, 11 Jul 2005 23:35:46 +0100 Message-ID: <004001c58669$396007d0$d6849ed9@Puppy> From: "Adrian Farrel" To: Date: Mon, 11 Jul 2005 23:27:20 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Cc: Subject: [Pce] Provisional scheduling for Paris X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi, PCE has been *provisionally* scheduled for Monday at 4.30pm. This clashes with one of the two L3VPN sessions and I'd like to know if this causes a problem for anyone. We cannot guarantee that this slot will be held. Cheers, Adrian _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue Jul 12 03:46:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsFTA-0002eH-8c; Tue, 12 Jul 2005 03:46:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsFT8-0002e4-ID for pce@megatron.ietf.org; Tue, 12 Jul 2005 03:46:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27844 for ; Tue, 12 Jul 2005 03:46:17 -0400 (EDT) From: benjamin.niven-jenkins@bt.com Received: from smtp1.smtp.bt.com ([217.32.164.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsFvH-00088H-KT for pce@ietf.org; Tue, 12 Jul 2005 04:15:24 -0400 Received: from i2km95-ukbr.domain1.systemhost.net ([193.113.197.29]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 12 Jul 2005 08:46:03 +0100 Received: from i2km86-ukdy.domain1.systemhost.net ([193.113.30.79]) by i2km95-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 12 Jul 2005 08:46:02 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 12 Jul 2005 08:46:47 +0100 Message-ID: Thread-Topic: Multi-layer dynamic provisioning Thread-Index: AcWD5G+mymMFMsSDTpWOgcXNN8Eq4wCzc0tg To: , X-OriginalArrivalTime: 12 Jul 2005 07:46:02.0966 (UTC) FILETIME=[C0AC7F60:01C586B5] X-Spam-Score: 0.3 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: quoted-printable Cc: Subject: [Pce] RE: Multi-layer dynamic provisioning X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Igor, > Ben, >=20 > Are you saying that realistically it could not be the case=20 > when the same operator owns both VC12 and VC4 layers ? I'll leave Neil to provide a more detailed & comprehensive response. I entered into this topic to argue that it is not realistic for a VC12 request to trigger a VC4 request using the same control plane instance (i.e. 'topology on the fly' does not work). Essentially (to my mind) whether it is theoretically or realistically possible for a single control plane instance to control both the VC12 and VC4 layers is irrelevant. I would repeat/reword the question I posed previously "Is any operator actually intending to deploy a peer/integrated model with a single control plane instance controlling >1 layer network and therefore is any operator requesting a GMPLS implementation that uses the same control plane instance to control >1 layer network?" If the answer is yes, then fine that's up to them (but I believe they will encounter some major problems both technically and commercially/economically), carry on as you were because nothing I say will make a difference. If the answer is no then the work (and this discussion) is purely academic, however seeing as it is the operators that will end up paying for this work, and seeing as all operators are generally trying to reduce costs then if no operator is asking for this then I would have thought no operator would want to pay for a solution that neither they nor any other operator is asking for or intending to use/deploy. I am not in a position to speak on behalf of BT on this topic but it is my personal view that BT (as an operator) has no intention of deploying a single control plane instance that spans >1 layer network. Ben _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Jul 13 12:59:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DskZk-0001Rh-Uk; Wed, 13 Jul 2005 12:59:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DskZj-0001NE-7D for pce@megatron.ietf.org; Wed, 13 Jul 2005 12:59:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03446 for ; Wed, 13 Jul 2005 12:59:08 -0400 (EDT) From: neil.2.harrison@bt.com Received: from smtp5.smtp.bt.com ([217.32.164.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dsl29-0003BG-QH for pce@ietf.org; Wed, 13 Jul 2005 13:28:34 -0400 Received: from i2km95-ukbr.domain1.systemhost.net ([193.113.197.29]) by smtp5.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 13 Jul 2005 17:58:55 +0100 Received: from i2km07-ukbr.domain1.systemhost.net ([193.113.197.26]) by i2km95-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 13 Jul 2005 17:58:55 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 13 Jul 2005 17:58:54 +0100 Message-ID: <0536FC9B908BEC4597EE721BE6A353890A9F1DC0@i2km07-ukbr.domain1.systemhost.net> Thread-Topic: Network modes and layer network relationships Thread-Index: AcWDzhHh7ru0bD/TQaayL5K04e6aEQD8ggQA To: X-OriginalArrivalTime: 13 Jul 2005 16:58:55.0056 (UTC) FILETIME=[27317D00:01C587CC] X-Spam-Score: 0.3 (/) X-Scan-Signature: 1c0c3d540ad9f95212b1c2a9a2cc2595 Content-Transfer-Encoding: quoted-printable Cc: pce@ietf.org, alan.mcguire@bt.com Subject: [Pce] Network modes and layer network relationships X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Note - change of thread title Thanks Igor, I've snipped this to where further remarks are required. I refer to your mail 08 July 2005 16:02, Subject: Re: [Pce] PCE Disco Reqs v01. > IB>> Let me ask you something. Suppose we have VC12 layer and > VC4 layer. Is it unrealistic to expect that the same instance of the > control plane manages both of them? NH=3D> I see Ben has already responded.....however I want to say = something more here (quite a bit more in fact). The trite answer to your question is 'yes'. However, in order to fully understand the reasons why I say this, we need to look to the general case and not a specific and tightly constrained case. Indeed, much of the GMPLS stuff (and certainly when you see the remarks from folks like Dimitri that caused me to react and support what you were saying initially) have an assumption (maybe much weaker now than some time ago) that it is possible to have a single control-plane running from IP to optics across all layer networks. Well, I do not buy into this general case view at all....in fact I don't know many folks that do, but I do know loads of folks that don't. Now let me try and answer your specific question in this general case context. However, you still need to refer to what I said in previous mails as these other factors are also important here, eg who owns which layer?, have folks really done the cost models for assuming a BoD server layer GoS is viable?, etc...... First, let us be very clear about the architectural situation we are dealing with wrt the co-cs networking mode. We should NOT dive in with the specifics of how one technology embodiment (here SDH) of the co-cs mode has been defined, as our solution should be generic to all cases of the co-cs mode. This is because: (i) We want a generic solution that provides maximal functional reuse.....and this becomes particularly critical once we look at the downstream NMS/OSS impact of network architecture. Let me put this point another way: Opex costs are the most crucial costs to control/minimise, and if the underpinning network architecture is not right (eg violations, deficiencies....which will also add complexity costs) then no amount of money thrown at the NMS/OSS piece later can recover the situation....if you start with junk, massaging junk does not really improve it. (ii) We MUST respect the overriding requirement for functional decoupling in a client/server layer network relationship between different operating parties.....this is the base starting point of a (private) network builder service, which one can then add functionality to (eg an rfc2547-style VPN say) IFF the client wants this (and many customers don't). This is crucial, and I make no excuses for repeatedly making this point. IMPORTANT NOTE: The above (client/server) case is VERY different to a *public* service case where we have a peer-partition interworking situation between independent operating parties in the SAME layer network, ie this is an External NNI case (and it is different to an Internal NNI case wrt to what is allowed to be advertised/controlled across the NNI). These cases MUST NOT be confused....and they are by some folks IMO, cf those blundering into 'MPLS NNIs' because we cannot create functional decoupling at the LSP level in MPLS due to the way it has been defined, ie the wrapper. This (wrapper) case DOES NOT apply to the co-cs mode because the co-cs mode simply does not allow it. We must first observe that in the co-cs mode the CI (characteristic information, see G.805) of the trail we are networking is a constant stream of bits with a precisely controlled temporal specification, ie the trail rate is constrained to lie within a range of X bits/s +/- delta ppm. I will ignore the jitter/wander impairments that can be induced on this trail by lower layer networks (due to muxing in a client->server adaptation function) or (right at the bottom of the stack on the physical section layer) due to diurnal temperature cycles. However, these must also be carefully controlled (esp if client timing information is to be carried), and this is why certain client/server relationships between the 3 modes will not make much sense despite what some folks are doing in PWE3. And I don't say this as conjecture either, this is based on current lab testing here in BT. Now in a co mode network (ie applies to both co-cs and co-ps) there are well defined (ie identifiable) connection points associated with links and subnetworks. When these connection points are bound together in a concatenated sequence between network access points an important networking entity called a trail is created (strictly speaking in G.805 sense, the trail goes between a pair of trail termination points, and between these points the trail's CI must be transported transparently). This also implies the co mode MUST preserve traffic unit ordering....and in turn, this implies that the ONLY allowable trail constructions in the co mode are p2p and p2mp. Further, because of the fixed/known bit rate you are forced into a hierarchy based on well-defined layer networks, ie we cannot have the wrapper behaviour in the co-cs mode. Now although we cannot violate the 'ordering' requirement in the co-cs mode we can in the co-ps mode and, if we do this, there are significant implications for traffic/performance/fault management. At this point you may be saying 'where the heck is this leading to?'. Well, the reason I went through the stuff above is to make the point that this trail that we have constructed in some arbitrary co-cs mode technology belongs to the traffic data-plane....in other words, it is fully utilised and CANNOT carry the control-plane nor the management-plane protocols for THIS layer network. Thus, for THIS layer network we must have a SEPARATE data-plane layer network (often referred to as 'OOB'...Out-Of-Band) that conveys the control and management plane protocols to each node (which is the smallest G.805 subnetwork of practical interest in THIS layer network) where the trail will be networked, ie switched. Ok, so what does this mean? Well, it means that the only practical way you can do this for THIS layer network is to look for some LOWER server layer network (or networks) to carry both the traffic data-plane network and the control/management data-plane network of THIS layer network system. Now let's assume you want to make life simple, and don't want to worry whether the performance of the server layer will have any significant impact on the performance achievable in THIS layer network, so you choose a co-cs mode server layer network for this purpose....noting that any layer network will recursively inherit the performance behaviour of ALL server layers right down to the duct. Indeed, it's no co-incidence that when it comes to bulk transport of ANY types of traffic in a WAN environment you will find a co-cs mode technology at the bottom of the stack....this also applies to the Internet traffic just in case anyone was wondering. And also bear in mind my earlier observation wrt the case that there is a requirement in some client layer network for timing transport. Now, in order to make it easy to see, let me give a well-known example of what the above means....and which is almost identical to the SDH case mentioned (which I will shortly return to wrt specifics here). Consider the PSTN. This is a 64kbit/s co-cs mode layer network wrt to the traffic data-plane. So how does control/management traffic get transported between PSTN nodes? Well, it could use a whole range of different OOB server layer networks to do this. But let me pick a specific and very familiar case (for Europe at least) of an E1 server layer network (and yes this IS a different layer network to the 64k layer network). When we adapt the 64k layer network client link connections (ie the things that connect 64k layer nodes together) to an E1 server layer trail the 1st thing we have to note is the bit rate specification of the server, as there must be a known/fixed and carefully controlled relationship here (Aside: In this particular case the client and server layer networks are synchronised and thus locked together wrt timing, but when these are plesiochronous 'justification processes' are used to align the client and server layer bit rates). In other words the server layer determines how the adaptation muxing regime works. Now, I assume most folks will know (which is why I picked this example) that there are 32 timeslots (TS) in an E1 frame. Each TS represents a specific client layer link connection, and as noted for this case, it will be carried on a E1 server layer trail. By convention (ie so we where know where stuff is): - TS0 carries the E1 trail framing and other trail CI OAM/integrity-checking information overhead like a CRC4 (this belongs to the E1 layer network, and if one drew out the G.805 func model of this you would see that it is generated/terminated at the E1 trail termination points), - TSs 1-15 and 17-31 carry 64k client traffic link connections, and - TS16 carries the control-plane protocols for the 64k layer network. So, TS16 is a logical OOB link that goes between the subnetwork controllers of the 64k (traffic) layer network that is carried by an E1 server layer trail between 64k nodes. What sort of control-plane (or in a more general case also management-plane) protocols run on this OOB network is of no concern of the 64k traffic data-plane nor indeed the (server) E1 trail. I can select any appropriate signalling protocol and routing process I like here. HOWEVER, the design of this network is a big concern....especially wrt to resilience, and because it is so critical it must take its design cues directly from the duct network. Further note that because it is logically OOB wrt the traffic data-plane network it controls (i) it can be made very stable (ie wrt to traffic loadings), (ii) it can be made very secure to attack and (iii) it needs its own addressing scheme which is NOT the same addressing scheme/space as that used/occupied by the traffic data-plane network it controls.....and it also has nothing to do with the addressing scheme used on the lower E1 layer network. Now let's go back to the SDH case you mentioned. And let's start by considering the VC4 layer network....and think of this as analogous to the 64k layer network of the above example. So, as we now know, we are going to have to find some LOWER layer network to carry the control/management plane protocols between the VC4 subnetwork nodes. In the SDH networking system the most obvious choice for this (and it does NOT have to use this) is the STM layer network. This is a real layer network of its own right, however it is degenerate because we do not network STM trail constructs....these simply go p2p between (in the case I have selected) the VC4 nodes. So, the STM trail is the analogy for the VC4 client layer of what the E1 trail was for the 64k client layer in the previous example. There are, again by convention, well known 'TSs' in the STM section overhead that could be used to carry the control/management protocols for the VC4 layer network.....these are often referred to as the DDC (data communications channel). So these are the analogy of what TS16 is for the 64k/E1 client/server case. Now let's assume I own the VC4 layer network and I use the STM overhead to carry my OOB control/management plane protocols for this VC4 layer network. If I also own the VC12 layer network (and indeed all the possible VCx layer networks I could create within the SDH networking system) I could also consider using this same OOB network to carry control/management plane protocols for these too. I would have to devise a scheme that logically separated control/management for each of the different VCx layer networks because they are DIFFERENT layer networks and their (subnetwork) switching nodes and trail terminations points will be in different places. Note also that because they are different layer networks their addresses belong to separate spaces...even if they use the same structure....which is rather obvious by noting that it clearly makes no sense to attempt to connect a VC4 trail termination point to a VC12 trail termination point. I could, however, conceive of an alternative way of doing this where the STM server layer overhead carried the control/management for the VC4 layer network as before, but I now use the VC4 layer network as the server layer to the VC12 layer network.....in other words I could use the VC4 overhead (say) to carry an OOB control/management plane network for the VC12 layer network, or I could even postulate a scheme whereby I carved up a VC4 into VC12s and dedicated one of the VC12 channels to carry the control/management of the VC12 layer network.=20 In all these cases the same principle that I outlined with the 64k client and E1 server case remains, ie we need to define some way of carrying the control/management OOB, and there are many ways this could be achieved. Indeed, these do not even need to be within the SDH networking system....though it obviously makes sense to use this where possible simply for practical convenience. Now suppose I do not own the VC12 layer (which I suspect would be an unusual case), or say some other non-SDH-based layer network such as ATM, PDH, FR, whatever that was carried over my SDH VC4 layer network (which is a far more usual case). It should be obvious that there is no way I could contemplate sharing my STM-based OOB VC4 control/management plane layer network with some other operator. In any case, for the non-SDH-based layer networks such as ATM say its obvious that their span would not be congruent (invariably larger) than my (server) SDH layer network anyway. Remember - a link connection in a client layer network is created by a trail in a server layer network...so trail spans of different layer networks are generally not congruent. So, to wrap-up here....when you have a client/server layer networking case between 2 *different* operating parties there must be full functional decoupling between the 2 layer networks. This is not for debate it's a must-have starting point requirement. What this means in practice is that all 3 planes of the client layer network must be carried transparently by the *traffic* data-plane component of some other server layer network (or networks....though in most practical cases the SAME server layer trail will carry all 3 client layer planes). And how this is determined is a function of the client->server muxing adaptation function of the link-connections that form the topology of the client layer network (be this the client traffic data-plane network or the control/management plane network). Note - Not sure if I have done a good job at explaining all this, and I guess to some folks this will be obvious but to many others (in my experience at least) some of this won't be that obvious. If anyone wants to know more about functional architecture stuff (or control-plane stuff) the best source of information I know of is Reid/Sexton 'Broadband networking', esp the stuff covered in the early chapters (Andy Reid is a colleague of mine in BT/CTO, but this is not the reason I am mentioning his book ;-)).=20 > If, say, PCE fails a path=20 > computation for a VC12 connection, could it suggest a=20 > reconfiguration in the VC4 layer, pass this suggestion to a=20 > VNT Manager (application/entity that has security, budget, etc. > authorization) to add trails in VC4 layer and provide extra=20 > flexibility in the VC12 layer? NH=3D> If the same party owns both VC12 and VC4 layer networks you may = be able to do this, ie change the VC12 topology (subject to GoS issues), but this is a very different case to where the same party does NOT own all the layer networks......and the latter is the more general case of leasing capacity off some other operator. This is why I repeatedly keep making the point that a network builder service is THE starting point.....this capability MUST be available. BTW - You should note that operators are looking to phase out the lower layer co-cs networks, eg VC12. This creates a very important responsibility for the co-ps mode technology to step up to this job.....and you can probably guess what I could say next here about certain co-ps technologies! > Correct me if I am wrong, but=20 > you sound like always require > NMS+human in the inter-layer relationships. Why the process=20 > could not be > autometed via control plane ? NH=3D> Well, it depends on who owns which layer networks. And in all cases you still have a the problem of designing the lower layer network to some GoS such that client demands can be serviced in some acceptable period and at some acceptable cost. Further, as Alan McGuire here pointed out (off list) if you have got to the stage where circuitous client layer routings are required your network design/planning process is already in rather serious trouble. But have any folks got any good models they are working to for this (also see aside below)? We've looked at this problem in some detail and concluded its a no-go area right now. But even if/when you do this, I am afraid you will still find that the NMS is king here and it MUST know what actions have been taken by the control-plane. Aside - If, instead of just considering the private network builder service case, you looked at the potential population of the public network serve case for SVCs (ie mode selection in end-systems) and the likely greater calling rates and far shorter holding times of trails here, then there could be a more sound commercial proposition here. Especially noting that mode selection can solve what are otherwise very hard QoS/pricing problems that are facing operators. I note the proposals from Jaihyung Cho (on the 'end-to-end L2-LSP' thread) are starting to give some hints in this direction. > IB>> Nobody said that GMPLS must control all layers, NH=3D> This is not how I would interpret some of the statements I have seen in the past from some folks, nor IMO how this general topic areas was initially 'sold' to the masses. =20 > IB>> for > instance all/some SDH layers. Network topology in lower=20 > layers it does not control, of course, needs to be in place. NH=3D> Agreed. But what about higher layer networks that are NOT owned = by the same party....what do you say here? regards, Neil _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Jul 13 15:41:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dsn6u-0007NU-VM; Wed, 13 Jul 2005 15:41:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dsn6s-0007NO-T7 for pce@megatron.ietf.org; Wed, 13 Jul 2005 15:41:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15076 for ; Wed, 13 Jul 2005 15:41:33 -0400 (EDT) Received: from webmail.movaz.com ([65.205.166.188] helo=jera.movaz.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsnZL-0000A2-Fk for pce@ietf.org; Wed, 13 Jul 2005 16:11:00 -0400 Received: from ib (unknown [172.16.24.122]) by jera.movaz.com (Postfix) with SMTP id C461656D7; Wed, 13 Jul 2005 15:41:14 -0400 (EDT) Message-ID: <00ec01c587e2$d4f805b0$7a1810ac@movaz.com> From: "Igor Bryskin" To: References: <0536FC9B908BEC4597EE721BE6A353890A9F1DC0@i2km07-ukbr.domain1.systemhost.net> Date: Wed, 13 Jul 2005 15:41:14 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4166dd0e0c668adc975c3d3e0f1bce3b Content-Transfer-Encoding: 7bit Cc: pce@ietf.org, alan.mcguire@bt.com Subject: [Pce] Re: Network modes and layer network relationships X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi Neil, Thanks for such a detailed information. I hope you will come to Paris (IETF) and we can continue the discussion. While reading your response I realized that I should've been more specific describing the example. For instance. I never assumed using overhead bits for the control plane connectivity for neither of layers. My example was as follows: 1. A single transport network operator owns VC4, VC12, etc. layers, so that a single control plane domain (signaling, routing, TE, path computation. etc.) manages all of them. (Surely there must be commercial benefits for the operator to own multiple layers that can establish server/client relationships); 2. This is *not* a public service case: there are no control plane relationships with other operators for the layers in question; 3. For the control and management plane connectivity the *out-of-band-out-of-fiber* DCN is used - no overhead bits of neither of layers! 4. The control plane contains a logical construct - VNT Manager (centralized or distributed). Only this entity is entitled to perform dynamic server layer re-configurations to satisfy client layer connection requests (provided, that the server layer is under control of the operator in question. The re-configuration of a server layer that does not belong to the operator is out of scope of this discussion, although it could be an interesting discussion in future). The VNT Manager has an access to: a) resources available in each of the layers including their termination and adaptation capabilities. The resources are clearly broken into two groups: ones that could be used for dynamic re-configuration and ones that could be used only under the management control; b) service demand and it's dynamics (e.g. mean active time); c) policies wrt use of the resources; d) network planning tools for verification of validity/feasibility of possible re-configurations I understand that you agree that such a setup is possible. The question is this scenario is *commercially realistic* today? 3-5 years from now? Hope will see you, Alan or Ben in Paris. Igor ----- Original Message ----- From: To: Cc: ; ; ; Sent: Wednesday, July 13, 2005 12:58 PM Subject: Network modes and layer network relationships Note - change of thread title Thanks Igor, I've snipped this to where further remarks are required. I refer to your mail 08 July 2005 16:02, Subject: Re: [Pce] PCE Disco Reqs v01. > IB>> Let me ask you something. Suppose we have VC12 layer and > VC4 layer. Is it unrealistic to expect that the same instance of the > control plane manages both of them? NH=> I see Ben has already responded.....however I want to say something more here (quite a bit more in fact). The trite answer to your question is 'yes'. However, in order to fully understand the reasons why I say this, we need to look to the general case and not a specific and tightly constrained case. Indeed, much of the GMPLS stuff (and certainly when you see the remarks from folks like Dimitri that caused me to react and support what you were saying initially) have an assumption (maybe much weaker now than some time ago) that it is possible to have a single control-plane running from IP to optics across all layer networks. Well, I do not buy into this general case view at all....in fact I don't know many folks that do, but I do know loads of folks that don't. Now let me try and answer your specific question in this general case context. However, you still need to refer to what I said in previous mails as these other factors are also important here, eg who owns which layer?, have folks really done the cost models for assuming a BoD server layer GoS is viable?, etc...... First, let us be very clear about the architectural situation we are dealing with wrt the co-cs networking mode. We should NOT dive in with the specifics of how one technology embodiment (here SDH) of the co-cs mode has been defined, as our solution should be generic to all cases of the co-cs mode. This is because: (i) We want a generic solution that provides maximal functional reuse.....and this becomes particularly critical once we look at the downstream NMS/OSS impact of network architecture. Let me put this point another way: Opex costs are the most crucial costs to control/minimise, and if the underpinning network architecture is not right (eg violations, deficiencies....which will also add complexity costs) then no amount of money thrown at the NMS/OSS piece later can recover the situation....if you start with junk, massaging junk does not really improve it. (ii) We MUST respect the overriding requirement for functional decoupling in a client/server layer network relationship between different operating parties.....this is the base starting point of a (private) network builder service, which one can then add functionality to (eg an rfc2547-style VPN say) IFF the client wants this (and many customers don't). This is crucial, and I make no excuses for repeatedly making this point. IMPORTANT NOTE: The above (client/server) case is VERY different to a *public* service case where we have a peer-partition interworking situation between independent operating parties in the SAME layer network, ie this is an External NNI case (and it is different to an Internal NNI case wrt to what is allowed to be advertised/controlled across the NNI). These cases MUST NOT be confused....and they are by some folks IMO, cf those blundering into 'MPLS NNIs' because we cannot create functional decoupling at the LSP level in MPLS due to the way it has been defined, ie the wrapper. This (wrapper) case DOES NOT apply to the co-cs mode because the co-cs mode simply does not allow it. We must first observe that in the co-cs mode the CI (characteristic information, see G.805) of the trail we are networking is a constant stream of bits with a precisely controlled temporal specification, ie the trail rate is constrained to lie within a range of X bits/s +/- delta ppm. I will ignore the jitter/wander impairments that can be induced on this trail by lower layer networks (due to muxing in a client->server adaptation function) or (right at the bottom of the stack on the physical section layer) due to diurnal temperature cycles. However, these must also be carefully controlled (esp if client timing information is to be carried), and this is why certain client/server relationships between the 3 modes will not make much sense despite what some folks are doing in PWE3. And I don't say this as conjecture either, this is based on current lab testing here in BT. Now in a co mode network (ie applies to both co-cs and co-ps) there are well defined (ie identifiable) connection points associated with links and subnetworks. When these connection points are bound together in a concatenated sequence between network access points an important networking entity called a trail is created (strictly speaking in G.805 sense, the trail goes between a pair of trail termination points, and between these points the trail's CI must be transported transparently). This also implies the co mode MUST preserve traffic unit ordering....and in turn, this implies that the ONLY allowable trail constructions in the co mode are p2p and p2mp. Further, because of the fixed/known bit rate you are forced into a hierarchy based on well-defined layer networks, ie we cannot have the wrapper behaviour in the co-cs mode. Now although we cannot violate the 'ordering' requirement in the co-cs mode we can in the co-ps mode and, if we do this, there are significant implications for traffic/performance/fault management. At this point you may be saying 'where the heck is this leading to?'. Well, the reason I went through the stuff above is to make the point that this trail that we have constructed in some arbitrary co-cs mode technology belongs to the traffic data-plane....in other words, it is fully utilised and CANNOT carry the control-plane nor the management-plane protocols for THIS layer network. Thus, for THIS layer network we must have a SEPARATE data-plane layer network (often referred to as 'OOB'...Out-Of-Band) that conveys the control and management plane protocols to each node (which is the smallest G.805 subnetwork of practical interest in THIS layer network) where the trail will be networked, ie switched. Ok, so what does this mean? Well, it means that the only practical way you can do this for THIS layer network is to look for some LOWER server layer network (or networks) to carry both the traffic data-plane network and the control/management data-plane network of THIS layer network system. Now let's assume you want to make life simple, and don't want to worry whether the performance of the server layer will have any significant impact on the performance achievable in THIS layer network, so you choose a co-cs mode server layer network for this purpose....noting that any layer network will recursively inherit the performance behaviour of ALL server layers right down to the duct. Indeed, it's no co-incidence that when it comes to bulk transport of ANY types of traffic in a WAN environment you will find a co-cs mode technology at the bottom of the stack....this also applies to the Internet traffic just in case anyone was wondering. And also bear in mind my earlier observation wrt the case that there is a requirement in some client layer network for timing transport. Now, in order to make it easy to see, let me give a well-known example of what the above means....and which is almost identical to the SDH case mentioned (which I will shortly return to wrt specifics here). Consider the PSTN. This is a 64kbit/s co-cs mode layer network wrt to the traffic data-plane. So how does control/management traffic get transported between PSTN nodes? Well, it could use a whole range of different OOB server layer networks to do this. But let me pick a specific and very familiar case (for Europe at least) of an E1 server layer network (and yes this IS a different layer network to the 64k layer network). When we adapt the 64k layer network client link connections (ie the things that connect 64k layer nodes together) to an E1 server layer trail the 1st thing we have to note is the bit rate specification of the server, as there must be a known/fixed and carefully controlled relationship here (Aside: In this particular case the client and server layer networks are synchronised and thus locked together wrt timing, but when these are plesiochronous 'justification processes' are used to align the client and server layer bit rates). In other words the server layer determines how the adaptation muxing regime works. Now, I assume most folks will know (which is why I picked this example) that there are 32 timeslots (TS) in an E1 frame. Each TS represents a specific client layer link connection, and as noted for this case, it will be carried on a E1 server layer trail. By convention (ie so we where know where stuff is): - TS0 carries the E1 trail framing and other trail CI OAM/integrity-checking information overhead like a CRC4 (this belongs to the E1 layer network, and if one drew out the G.805 func model of this you would see that it is generated/terminated at the E1 trail termination points), - TSs 1-15 and 17-31 carry 64k client traffic link connections, and - TS16 carries the control-plane protocols for the 64k layer network. So, TS16 is a logical OOB link that goes between the subnetwork controllers of the 64k (traffic) layer network that is carried by an E1 server layer trail between 64k nodes. What sort of control-plane (or in a more general case also management-plane) protocols run on this OOB network is of no concern of the 64k traffic data-plane nor indeed the (server) E1 trail. I can select any appropriate signalling protocol and routing process I like here. HOWEVER, the design of this network is a big concern....especially wrt to resilience, and because it is so critical it must take its design cues directly from the duct network. Further note that because it is logically OOB wrt the traffic data-plane network it controls (i) it can be made very stable (ie wrt to traffic loadings), (ii) it can be made very secure to attack and (iii) it needs its own addressing scheme which is NOT the same addressing scheme/space as that used/occupied by the traffic data-plane network it controls.....and it also has nothing to do with the addressing scheme used on the lower E1 layer network. Now let's go back to the SDH case you mentioned. And let's start by considering the VC4 layer network....and think of this as analogous to the 64k layer network of the above example. So, as we now know, we are going to have to find some LOWER layer network to carry the control/management plane protocols between the VC4 subnetwork nodes. In the SDH networking system the most obvious choice for this (and it does NOT have to use this) is the STM layer network. This is a real layer network of its own right, however it is degenerate because we do not network STM trail constructs....these simply go p2p between (in the case I have selected) the VC4 nodes. So, the STM trail is the analogy for the VC4 client layer of what the E1 trail was for the 64k client layer in the previous example. There are, again by convention, well known 'TSs' in the STM section overhead that could be used to carry the control/management protocols for the VC4 layer network.....these are often referred to as the DDC (data communications channel). So these are the analogy of what TS16 is for the 64k/E1 client/server case. Now let's assume I own the VC4 layer network and I use the STM overhead to carry my OOB control/management plane protocols for this VC4 layer network. If I also own the VC12 layer network (and indeed all the possible VCx layer networks I could create within the SDH networking system) I could also consider using this same OOB network to carry control/management plane protocols for these too. I would have to devise a scheme that logically separated control/management for each of the different VCx layer networks because they are DIFFERENT layer networks and their (subnetwork) switching nodes and trail terminations points will be in different places. Note also that because they are different layer networks their addresses belong to separate spaces...even if they use the same structure....which is rather obvious by noting that it clearly makes no sense to attempt to connect a VC4 trail termination point to a VC12 trail termination point. I could, however, conceive of an alternative way of doing this where the STM server layer overhead carried the control/management for the VC4 layer network as before, but I now use the VC4 layer network as the server layer to the VC12 layer network.....in other words I could use the VC4 overhead (say) to carry an OOB control/management plane network for the VC12 layer network, or I could even postulate a scheme whereby I carved up a VC4 into VC12s and dedicated one of the VC12 channels to carry the control/management of the VC12 layer network. In all these cases the same principle that I outlined with the 64k client and E1 server case remains, ie we need to define some way of carrying the control/management OOB, and there are many ways this could be achieved. Indeed, these do not even need to be within the SDH networking system....though it obviously makes sense to use this where possible simply for practical convenience. Now suppose I do not own the VC12 layer (which I suspect would be an unusual case), or say some other non-SDH-based layer network such as ATM, PDH, FR, whatever that was carried over my SDH VC4 layer network (which is a far more usual case). It should be obvious that there is no way I could contemplate sharing my STM-based OOB VC4 control/management plane layer network with some other operator. In any case, for the non-SDH-based layer networks such as ATM say its obvious that their span would not be congruent (invariably larger) than my (server) SDH layer network anyway. Remember - a link connection in a client layer network is created by a trail in a server layer network...so trail spans of different layer networks are generally not congruent. So, to wrap-up here....when you have a client/server layer networking case between 2 *different* operating parties there must be full functional decoupling between the 2 layer networks. This is not for debate it's a must-have starting point requirement. What this means in practice is that all 3 planes of the client layer network must be carried transparently by the *traffic* data-plane component of some other server layer network (or networks....though in most practical cases the SAME server layer trail will carry all 3 client layer planes). And how this is determined is a function of the client->server muxing adaptation function of the link-connections that form the topology of the client layer network (be this the client traffic data-plane network or the control/management plane network). Note - Not sure if I have done a good job at explaining all this, and I guess to some folks this will be obvious but to many others (in my experience at least) some of this won't be that obvious. If anyone wants to know more about functional architecture stuff (or control-plane stuff) the best source of information I know of is Reid/Sexton 'Broadband networking', esp the stuff covered in the early chapters (Andy Reid is a colleague of mine in BT/CTO, but this is not the reason I am mentioning his book ;-)). > If, say, PCE fails a path > computation for a VC12 connection, could it suggest a > reconfiguration in the VC4 layer, pass this suggestion to a > VNT Manager (application/entity that has security, budget, etc. > authorization) to add trails in VC4 layer and provide extra > flexibility in the VC12 layer? NH=> If the same party owns both VC12 and VC4 layer networks you may be able to do this, ie change the VC12 topology (subject to GoS issues), but this is a very different case to where the same party does NOT own all the layer networks......and the latter is the more general case of leasing capacity off some other operator. This is why I repeatedly keep making the point that a network builder service is THE starting point.....this capability MUST be available. BTW - You should note that operators are looking to phase out the lower layer co-cs networks, eg VC12. This creates a very important responsibility for the co-ps mode technology to step up to this job.....and you can probably guess what I could say next here about certain co-ps technologies! > Correct me if I am wrong, but > you sound like always require > NMS+human in the inter-layer relationships. Why the process > could not be > autometed via control plane ? NH=> Well, it depends on who owns which layer networks. And in all cases you still have a the problem of designing the lower layer network to some GoS such that client demands can be serviced in some acceptable period and at some acceptable cost. Further, as Alan McGuire here pointed out (off list) if you have got to the stage where circuitous client layer routings are required your network design/planning process is already in rather serious trouble. But have any folks got any good models they are working to for this (also see aside below)? We've looked at this problem in some detail and concluded its a no-go area right now. But even if/when you do this, I am afraid you will still find that the NMS is king here and it MUST know what actions have been taken by the control-plane. Aside - If, instead of just considering the private network builder service case, you looked at the potential population of the public network serve case for SVCs (ie mode selection in end-systems) and the likely greater calling rates and far shorter holding times of trails here, then there could be a more sound commercial proposition here. Especially noting that mode selection can solve what are otherwise very hard QoS/pricing problems that are facing operators. I note the proposals from Jaihyung Cho (on the 'end-to-end L2-LSP' thread) are starting to give some hints in this direction. > IB>> Nobody said that GMPLS must control all layers, NH=> This is not how I would interpret some of the statements I have seen in the past from some folks, nor IMO how this general topic areas was initially 'sold' to the masses. > IB>> for > instance all/some SDH layers. Network topology in lower > layers it does not control, of course, needs to be in place. NH=> Agreed. But what about higher layer networks that are NOT owned by the same party....what do you say here? regards, Neil _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Jul 13 17:25:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dsojr-0003JH-2f; Wed, 13 Jul 2005 17:25:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dsojp-0003J9-7Q for pce@megatron.ietf.org; Wed, 13 Jul 2005 17:25:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15359 for ; Wed, 13 Jul 2005 17:25:51 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DspCH-00034i-Aj for pce@ietf.org; Wed, 13 Jul 2005 17:55:19 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 13 Jul 2005 14:25:42 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j6DLP9Vt018373 for ; Wed, 13 Jul 2005 14:25:40 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 13 Jul 2005 17:25:36 -0400 Received: from [192.168.1.100] ([10.86.240.94]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 13 Jul 2005 17:25:36 -0400 Mime-Version: 1.0 (Apple Message framework v730) Content-Transfer-Encoding: 7bit Message-Id: <9CBBDAE5-29CA-4033-B456-41A4EDB76020@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: pce@ietf.org From: JP Vasseur Date: Wed, 13 Jul 2005 17:25:54 -0400 X-Mailer: Apple Mail (2.730) X-OriginalArrivalTime: 13 Jul 2005 21:25:36.0864 (UTC) FILETIME=[69039E00:01C587F1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: Subject: [Pce] PCE Working Meeting Agenda X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Dear WG, Please find below the PCE Working Group meeting agenda - IETF-63 Duration - 90mn 1) Agenda/Admin (10mn) 2) Progress against milestones (5mn) 3) Drafts: - draft-ietf-pce-architecture-01.txt (Farrel - 5mn) - draft-ietf-pce-discovery-reqs-01.txt (Le Roux - 5mn) - draft-ietf-pce-comm-protocol-gen-reqs-01.txt (Ash - 5mn) - draft-zhang-pce-comm-app-model-01.txt (Zhang - 5mn) - draft-vasseur-pce-pcep-01.txt (Vasseur - 10mn) - draft-choi-pce-metric-protocol-02.txt (Choi - 10mn) 4) Working Group next steps - 20mn Presenters, please provide us your slides by July 28th. JP. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Jul 14 12:27:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt6YB-0008Bx-Gu; Thu, 14 Jul 2005 12:27:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt6Y9-0008BP-Ef for pce@megatron.ietf.org; Thu, 14 Jul 2005 12:27:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26804 for ; Thu, 14 Jul 2005 12:26:58 -0400 (EDT) Received: from relay1.mail.uk.clara.net ([80.168.70.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dt70m-0000mF-LB for pce@ietf.org; Thu, 14 Jul 2005 12:56:37 -0400 Received: from du-069-0185.access.clara.net ([217.158.132.185] helo=Puppy) by relay1.mail.uk.clara.net with smtp (Exim 4.46) id 1Dt6Xm-00080j-Ge; Thu, 14 Jul 2005 17:26:48 +0100 Message-ID: <05dd01c58891$289b29a0$d6849ed9@Puppy> From: "Adrian Farrel" To: "JP Vasseur" , "Gray, Eric" References: <313680C9A886D511A06000204840E1CF0C885CC0@whq-msgusr-02.pit.comms.marconi.com> <01C7FD07-D870-4A95-BBBD-7C9F2CC30DE2@cisco.com> Subject: Re: [Pce] Requirement for less-constrained path indraft-ietf-pce-comm-protocol-gen-reqs-00.txt Date: Thu, 14 Jul 2005 17:26:06 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 2.1 (++) X-Scan-Signature: 32a65c0bf5eb4ec26489239c7cdd0636 Content-Transfer-Encoding: 7bit Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org I want to pitch in on this thread because I think i see where both JP and Eric are coming from. JP's proposals have the potential to significantly reduce the PCE processing and cut down number of PCC-PCE transactions, but they also have the ability to massively increase the processing and the size of the PCC-PCE transactions. Thus we need to be quite careful in the specification of the protocol requirements and the protocol itself. It is not OK for us to say that if an individual PCC is irresponsible or stupid that is its problem, because such an implementation would break the accessibility to the PCE for other 'normal' PCCs. Unless there are "standard" constraint back-off functions it is hard to conceive of a PCE guessing the correct back-off for the PCC that issued the request. Note that the more "speculative paths" the PCE computes the more CPU it uses. So we must keep good control on this. It is a computational myth that it is possible to relax different constraints on a single computational pass. In fact, the question "where did my computation fail" is notoriously impossible to answer except with the response "in the network". Thus we should give full control to the PCC, and let the PCE choose to supply less information if it thinks that the PCC is asking too much. This control includes: a. The ability to say "this or nothing" b. The ability to say "tell me what constraints I might relax to get a path" c. The ability to say "give me n alternate paths with your choice of relaxed constraints" (c. is like b but with the paths supplied, and it is important to control the number) d. A way to state which constraints may be relaxed absolutely (this is easy) e. A way to replace one constraint supplied by the PCC with another also supplied by the PCC f. A way to specify an ordering for relaxation in recomputation attempts. My feeling is that e might be satisfied in the protocol simply by listing the same object multiple times. But f is very messy. As soon as I have a few constraints and I am willing to relax each of them by degrees I have a very complex relaxation problem to express. This is a problem that it is very easy for the PCC to handle by issuing successive requests, but very hard for the PCC to communicate to the PCE in a single request. So, I'd like to see some text from SPs on this subject before we add anything to the requirements I-D. Cheers, Adrian ----- Original Message ----- From: "JP Vasseur" To: "Gray, Eric" Cc: Sent: Monday, July 11, 2005 11:29 PM Subject: Re: [Pce] Requirement for less-constrained path indraft-ietf-pce-comm-protocol-gen-reqs-00.txt > Hi Eric, > > On Jul 11, 2005, at 3:04 PM, Gray, Eric wrote: > > > JP, > > > > I assume from your reply that I understood correctly > > what you are asking about, but let me check. I believe you > > are asking for one of two things: an information bearing NAK > > used to narrow down the PCC choices for subsequent requests > > or a menu-selection request followed by somewhat complicated > > PCE response handling. > > > > In the first case, the idea is to have the PCE return > > additional information about "less than requested" Path > > capabilities as opposed to simply returning a NAK for the > > unsatisfiable request. In theory, this would reduce request- > > response transactions if you make two or three assumptions: > > > > 1) The PCC will make subsequent requests for a Path > > that might also be unsatisfiable if its initial > > request fails, AND > > And this will likely to be the case ... There are of course various > possible scenarios but consider the case of a PCE-based inter-area TE > LSP path computation. What would you expect the PCC to do, should it > receive a negative reply from the PCE ? Probably try to give up on > some constraints so as to find a path and signal the TE LSP (you may > also fall-back to IGP routing but give up on FRR in this case). Thus > getting a less constrained path from the PCE could be of interested, > effectively cutting down the communication protocol overhead and > signalling delay. This is of course especially true if the PCC has to > go through multiple rounds before getting a path. > > > 2) The fail-back options are uniform through-out a > > service and well understood prior to protocol > > definition, implementation and deployment, > > negotiable on a case-by-case basis within the > > protocol, or both reasonably well understood in > > advance and negotiable in signaling; > > Quite realistic. > > > 3) It may also be necessary to assume that Path > > requests do not arrive from PCCs at a frequent > > enough rate to result in inconsistent behavior. > > > > I do not think so. > > I'd like to stress the following fact: having such capability would > actually drastically reduce the communication overhead compared to > the co-located PCE scenario in case of path computation failure. > > > If the fail-back approach is to request a Path with no > > committed resources if initial requests fail for Paths with > > committed resources, then subsequent requests will succeed (if > > there is a route) and there would be no reduction in dialogue > > with information about alternative Path availability - nor any > > particularly useful information to offer - in a NAK. > > No, this is not correct. You may still want to know the shortest > unconstrained path (consider the case of inter-domain for example). > Furthermore, you do not need to go from "fully satisfied" to "No > committed resources". If the PCC wants to get the shortest path for a > TE LSP of X Mbits/s. Don't you think that it would be valuable to > know the shortest path with the closest bandwidth value to the > initial request (X) ? > > > Therefore > > we must assume that the second request would also require some > > commitment of resources. > > > > See above. > > > If the PCC might wish to make a subsequent request, then > > the PCE needs to know what the sensitive parameters are and how > > much tolerance there is in order to provide useful information > > in a NAK. This would be complex. > > > > You can either provide a boolean behavior to start with (Full > satisfied to Unconstrained -> Still valuable) or provide the ability > for the PCC to specify a hierarchical constraints relaxation policy. > You usually do not have that many constraints, and SP do know their > order of preference in term of constraints relaxation. > > > Finally, depending on the frequency with which the PCE is > > bombarded with requests, it (the PCE) may be unable to satisfy > > a second request as a result of resource commitments made after > > the first response and before the second request. > > > > It really depends of your PCE implementation. You can reduce that > probability. > > > All that taken into account, I believe you are suggesting > > the second alternative - requests with menu-selection options. > > That is, "if you can't get me a Path that looks like this, then > > I'll take one that looks like that; if you can't get me a path > > that looks like that, ... then I'll take just any old path you > > can give me." > > > > I can well imagine that service providers may want this, > > even given the complexity associated with defining a service > > around it, > > Note that there are many such deployments already. > > > but that is not the only question we need to have > > answered. The other question is what are customers willing to > > give up to get it? > > This is a completely different question. In any case, if you do not > have a path satisfying your constraints, you have to give up on > something but this has nothing to do with the PCE-based path > computation. > > > > > There can be no question that this adds complexity to the > > protocol. Is the PCE useless without it? Is the PCE sufficiently > > hampered without it that it's worth additional time to include it? > > Is there no service provider out there that is interested in a > > less complex (and expensive) approach? > > > > And - perhaps the most important question of all - is it > > necessary to include this capability in a first go round, or can > > we define extension and compatibility mechanisms that will allow > > us to include it in a subsequent iteration? > > > > The discussion on protocol overhead, complexity and so on should > follow once we discuss communication protocol. My question was > related to the requirement for such capability ? > > > These questions are among those that should be asked before > > we decide to accept this as a requirement... > > > > Again, note that I did not ask to add this as a requirement. Just a > question to the WG on whether this was a requirement. > > JP. > > > -- > > Eric > > > > --> -----Original Message----- > > --> From: JP Vasseur [mailto:jvasseur@cisco.com] > > --> Sent: Monday, July 11, 2005 12:52 PM > > --> To: Gray, Eric > > --> Cc: 'Ash, Gerald R (Jerry), ALABS'; pce@ietf.org > > --> Subject: Re: [Pce] Requirement for less-constrained path > > --> indraft-ietf-pce- comm-protocol-gen-reqs-00.txt > > --> > > --> > > --> Hi Eric, > > --> > > --> On Jul 11, 2005, at 11:08 AM, Gray, Eric wrote: > > --> > > --> > Jerry & JP, > > --> > > > --> > I am not so sure that this should be a requirement. > > --> > > > --> > Requiring the protocol to support finding alternate > > --> > paths (by a near-arbitrary collections of fuzzy parameters) > > --> > > > --> > > --> Does not have to be arbitrary ;-) See the related section > > --> in the PCEP > > --> protocol ... > > --> > > --> > is very likely to push both the process of coming up with > > --> > any proposed solution that meets this requirement - and yet > > --> > remains scalable - and the process of getting agreement for > > --> > any such proposed solution. > > --> > > --> Ah but this is the opposite goal: to increase the > > --> scalability. What > > --> would a PCC receiving a negative reply do unless resending > > --> additional > > --> path computation request(s) with different parameter(s) ? > > --> Thus having > > --> such capability would be quite useful but I'll let the Service > > --> Providers who will actually use that solution voice their > > --> opinion. In > > --> my previous email, I was just reflecting the outcome of some > > --> discussions that I had with several of them, thus asking > > --> whether such > > --> requirement had not be missed ? > > --> > > --> JP. > > --> > > --> > I suggest that we might want to better understand the > > --> > specific customer need - and what the customer is willing > > --> > to sacrifice in other areas - before we include something > > --> > like this as a requirement. > > --> > > > --> > Short of getting that information, simply stating that > > --> > this might be a preference - or a desirable goal - is about > > --> > as strong as I would put it. > > --> > > > --> > -- > > --> > Eric > > --> > > > --> > --> -----Original Message----- > > --> > --> From: pce-bounces@lists.ietf.org > > --> > --> [mailto:pce-bounces@lists.ietf.org]On > > --> > --> Behalf Of Ash, Gerald R (Jerry), ALABS > > --> > --> Sent: Monday, July 11, 2005 7:27 AM > > --> > --> To: JP Vasseur; pce@ietf.org > > --> > --> Subject: RE: [Pce] Requirement for less-constrained path > > --> > --> indraft-ietf-pce-comm-protocol-gen-reqs-00.txt > > --> > --> > > --> > --> > > --> > --> Hi JP, > > --> > --> > > --> > --> > Quick question ... I do not see any requirement to get > > less- > > --> > --> > constrained TE LSP path in > > --> > --> > draft-ietf-pce-comm-protocol-gen-reqs-00.txt. > > --> > --> > In most of the cases, when configuring a TE LSP > > --> with specific > > --> > --> > attributes, one of the most challenging part consists of > > --> > --> determining > > --> > --> > the attributes values which will not result in the > > --> > --> inability to find > > --> > --> > a path in some circumstances (such as network element > > --> > --> failures). The > > --> > --> > typical case is the bandwidth. The first approach > > --> is to try to > > --> > --> > compute the "closest" solutions. Another approach > > --> relies on the > > --> > --> > configuration of multiple set of attributes: > > --> > --> > 1) The preferred set of attributes > > --> > --> > 2) One or more less-preferred set of attributes > > --> > --> > 3) Un-constrained TE LSP > > --> > --> > > > --> > --> > When a PCE is used for TE LSP path computation, it looks > > --> > --> to me that > > --> > --> > it could be quite useful to be able to specify > > --> interest in less- > > --> > --> > constrained path rather than potentially have to > > --> > --> configure a set of > > --> > --> > attributes (less optimal) which would result in several > > --> > --> > rounds of PCC/ > > --> > --> > PCE communication. > > --> > --> > > > --> > --> > Isn't it a requirement that should be listed in > > --> > --> draft-ietf-pce-comm- > > --> > --> > protocol-gen-reqs-00.txt? > > --> > --> > > --> > --> Sounds OK to me. It would help if you suggested some > > --> > --> specific text to > > --> > --> insert in the updated draft sent out last Thursday. > > --> > --> > > --> > --> Thanks, > > --> > --> Jerry > > --> > --> > > --> > --> _______________________________________________ > > --> > --> Pce mailing list > > --> > --> Pce@lists.ietf.org > > --> > --> https://www1.ietf.org/mailman/listinfo/pce > > --> > --> > > --> > > > --> > > > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Jul 14 21:18:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtEqi-00040o-Ee; Thu, 14 Jul 2005 21:18:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtEqf-0003xC-DX for pce@megatron.ietf.org; Thu, 14 Jul 2005 21:18:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26873 for ; Thu, 14 Jul 2005 21:18:39 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtFJM-0001oK-Hw for pce@ietf.org; Thu, 14 Jul 2005 21:48:22 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 14 Jul 2005 18:18:32 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,291,1115017200"; d="scan'208"; a="1875654:sNHT28223908" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j6F1IUVu029303; Thu, 14 Jul 2005 21:18:30 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 14 Jul 2005 21:18:29 -0400 Received: from [192.168.1.100] ([10.86.240.94]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 14 Jul 2005 21:18:29 -0400 In-Reply-To: <05dd01c58891$289b29a0$d6849ed9@Puppy> References: <313680C9A886D511A06000204840E1CF0C885CC0@whq-msgusr-02.pit.comms.marconi.com> <01C7FD07-D870-4A95-BBBD-7C9F2CC30DE2@cisco.com> <05dd01c58891$289b29a0$d6849ed9@Puppy> Mime-Version: 1.0 (Apple Message framework v730) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <87E58674-E591-444A-8F93-E578957A3D83@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: [Pce] Requirement for less-constrained path indraft-ietf-pce-comm-protocol-gen-reqs-00.txt Date: Thu, 14 Jul 2005 21:18:47 -0400 To: "Adrian Farrel" X-Mailer: Apple Mail (2.730) X-OriginalArrivalTime: 15 Jul 2005 01:18:29.0212 (UTC) FILETIME=[1B9879C0:01C588DB] X-Spam-Score: 2.0 (++) X-Scan-Signature: 75ac86d24bd0a3cd8a26e327ae61143e Content-Transfer-Encoding: 7bit Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org On Jul 14, 2005, at 12:26 PM, Adrian Farrel wrote: > I want to pitch in on this thread because I think i see where both > JP and > Eric are coming from. JP's proposals have the potential to > significantly > reduce the PCE processing and cut down number of PCC-PCE > transactions, but > they also have the ability to massively increase the processing and > the > size of the PCC-PCE transactions. > that said, it it pretty straightforward to see that the benefits undoubtedly outweigh the drawbacks. The request processing is definitely negligible compared to the communication overhead. Actually, it could be shown that the non support of such capability would have a drastic scalability impact on the solution especially upon resource contention. > Thus we need to be quite careful in the specification of the protocol > requirements and the protocol itself. It is not OK for us to say > that if > an individual PCC is irresponsible or stupid that is its problem, > because > such an implementation would break the accessibility to the PCE for > other > 'normal' PCCs. > On this aspect, I do agree ! > Unless there are "standard" constraint back-off functions it is > hard to > conceive of a PCE guessing the correct back-off for the PCC that > issued > the request. Note that the more "speculative paths" the PCE > computes the > more CPU it uses. Speculative paths is definitely not an option considering the number of permutations ... we would unavoidably quickly fall into some NP- Complete issues ;-) ... This is why the suggestion is made to start some discussion on the hierarchical relaxation policy. Note that it does not have to be awfully complex ... > So we must keep good control on this. It is a > computational myth that it is possible to relax different > constraints on a > single computational pass. Ah no ... there are several constraints for which constraint can be relaxed and closest match can be found in on-go. That said, even if it were not the case, the solution would still be valuable to cut-down the communication overhead and amount of processing signaling be the PCE's scheduler. > In fact, the question "where did my computation > fail" is notoriously impossible to answer except with the response > "in the > network". > > Thus we should give full control to the PCC, and let the PCE choose to > supply less information if it thinks that the PCC is asking too > much. This > control includes: > > a. The ability to say "this or nothing" > b. The ability to say "tell me what constraints I might relax to get a > path" > c. The ability to say "give me n alternate paths with your choice of > relaxed constraints" > (c. is like b but with the paths supplied, and it is important to > control the number) > d. A way to state which constraints may be relaxed absolutely (this is > easy) > e. A way to replace one constraint supplied by the PCC with another > also > supplied by the PCC > f. A way to specify an ordering for relaxation in recomputation > attempts. > > My feeling is that e might be satisfied in the protocol simply by > listing > the same object multiple times. But f is very messy. As soon as I > have a > few constraints and I am willing to relax each of them by degrees I > have a > very complex relaxation problem to express. Well not so sure ... Let's wait for the meeting in Paris to have an open discussion. I'd be happy to provide some ideas. Actually, one could point out that such constraint relaxation are used TODAY in operational networks (with CSPF). > > This is a problem that it is very easy for the PCC to handle by > issuing > successive requests, but very hard for the PCC to communicate to > the PCE > in a single request. I do not think that it is hard for the PCC to communicate to the PCE in a single request. > > So, I'd like to see some text from SPs on this subject before we add > anything to the requirements I-D. > I think that the DT is working on it. Cheers, JP. > Cheers, > Adrian > > ----- Original Message ----- > From: "JP Vasseur" > To: "Gray, Eric" > Cc: > Sent: Monday, July 11, 2005 11:29 PM > Subject: Re: [Pce] Requirement for less-constrained path > indraft-ietf-pce-comm-protocol-gen-reqs-00.txt > > > >> Hi Eric, >> >> On Jul 11, 2005, at 3:04 PM, Gray, Eric wrote: >> >> >>> JP, >>> >>> I assume from your reply that I understood correctly >>> what you are asking about, but let me check. I believe you >>> are asking for one of two things: an information bearing NAK >>> used to narrow down the PCC choices for subsequent requests >>> or a menu-selection request followed by somewhat complicated >>> PCE response handling. >>> >>> In the first case, the idea is to have the PCE return >>> additional information about "less than requested" Path >>> capabilities as opposed to simply returning a NAK for the >>> unsatisfiable request. In theory, this would reduce request- >>> response transactions if you make two or three assumptions: >>> >>> 1) The PCC will make subsequent requests for a Path >>> that might also be unsatisfiable if its initial >>> request fails, AND >>> >> >> And this will likely to be the case ... There are of course various >> possible scenarios but consider the case of a PCE-based inter-area TE >> LSP path computation. What would you expect the PCC to do, should it >> receive a negative reply from the PCE ? Probably try to give up on >> some constraints so as to find a path and signal the TE LSP (you may >> also fall-back to IGP routing but give up on FRR in this case). Thus >> getting a less constrained path from the PCE could be of interested, >> effectively cutting down the communication protocol overhead and >> signalling delay. This is of course especially true if the PCC has to >> go through multiple rounds before getting a path. >> >> >>> 2) The fail-back options are uniform through-out a >>> service and well understood prior to protocol >>> definition, implementation and deployment, >>> negotiable on a case-by-case basis within the >>> protocol, or both reasonably well understood in >>> advance and negotiable in signaling; >>> >> >> Quite realistic. >> >> >>> 3) It may also be necessary to assume that Path >>> requests do not arrive from PCCs at a frequent >>> enough rate to result in inconsistent behavior. >>> >>> >> >> I do not think so. >> >> I'd like to stress the following fact: having such capability would >> actually drastically reduce the communication overhead compared to >> the co-located PCE scenario in case of path computation failure. >> >> >>> If the fail-back approach is to request a Path with no >>> committed resources if initial requests fail for Paths with >>> committed resources, then subsequent requests will succeed (if >>> there is a route) and there would be no reduction in dialogue >>> with information about alternative Path availability - nor any >>> particularly useful information to offer - in a NAK. >>> >> >> No, this is not correct. You may still want to know the shortest >> unconstrained path (consider the case of inter-domain for example). >> Furthermore, you do not need to go from "fully satisfied" to "No >> committed resources". If the PCC wants to get the shortest path for a >> TE LSP of X Mbits/s. Don't you think that it would be valuable to >> know the shortest path with the closest bandwidth value to the >> initial request (X) ? >> >> >>> Therefore >>> we must assume that the second request would also require some >>> commitment of resources. >>> >>> >> >> See above. >> >> >>> If the PCC might wish to make a subsequent request, then >>> the PCE needs to know what the sensitive parameters are and how >>> much tolerance there is in order to provide useful information >>> in a NAK. This would be complex. >>> >>> >> >> You can either provide a boolean behavior to start with (Full >> satisfied to Unconstrained -> Still valuable) or provide the ability >> for the PCC to specify a hierarchical constraints relaxation policy. >> You usually do not have that many constraints, and SP do know their >> order of preference in term of constraints relaxation. >> >> >>> Finally, depending on the frequency with which the PCE is >>> bombarded with requests, it (the PCE) may be unable to satisfy >>> a second request as a result of resource commitments made after >>> the first response and before the second request. >>> >>> >> >> It really depends of your PCE implementation. You can reduce that >> probability. >> >> >>> All that taken into account, I believe you are suggesting >>> the second alternative - requests with menu-selection options. >>> That is, "if you can't get me a Path that looks like this, then >>> I'll take one that looks like that; if you can't get me a path >>> that looks like that, ... then I'll take just any old path you >>> can give me." >>> >>> I can well imagine that service providers may want this, >>> even given the complexity associated with defining a service >>> around it, >>> >> >> Note that there are many such deployments already. >> >> >>> but that is not the only question we need to have >>> answered. The other question is what are customers willing to >>> give up to get it? >>> >> >> This is a completely different question. In any case, if you do not >> have a path satisfying your constraints, you have to give up on >> something but this has nothing to do with the PCE-based path >> computation. >> >> >>> >>> There can be no question that this adds complexity to the >>> protocol. Is the PCE useless without it? Is the PCE sufficiently >>> hampered without it that it's worth additional time to include it? >>> Is there no service provider out there that is interested in a >>> less complex (and expensive) approach? >>> >>> And - perhaps the most important question of all - is it >>> necessary to include this capability in a first go round, or can >>> we define extension and compatibility mechanisms that will allow >>> us to include it in a subsequent iteration? >>> >>> >> >> The discussion on protocol overhead, complexity and so on should >> follow once we discuss communication protocol. My question was >> related to the requirement for such capability ? >> >> >>> These questions are among those that should be asked before >>> we decide to accept this as a requirement... >>> >>> >> >> Again, note that I did not ask to add this as a requirement. Just a >> question to the WG on whether this was a requirement. >> >> JP. >> >> >>> -- >>> Eric >>> >>> --> -----Original Message----- >>> --> From: JP Vasseur [mailto:jvasseur@cisco.com] >>> --> Sent: Monday, July 11, 2005 12:52 PM >>> --> To: Gray, Eric >>> --> Cc: 'Ash, Gerald R (Jerry), ALABS'; pce@ietf.org >>> --> Subject: Re: [Pce] Requirement for less-constrained path >>> --> indraft-ietf-pce- comm-protocol-gen-reqs-00.txt >>> --> >>> --> >>> --> Hi Eric, >>> --> >>> --> On Jul 11, 2005, at 11:08 AM, Gray, Eric wrote: >>> --> >>> --> > Jerry & JP, >>> --> > >>> --> > I am not so sure that this should be a requirement. >>> --> > >>> --> > Requiring the protocol to support finding alternate >>> --> > paths (by a near-arbitrary collections of fuzzy parameters) >>> --> > >>> --> >>> --> Does not have to be arbitrary ;-) See the related section >>> --> in the PCEP >>> --> protocol ... >>> --> >>> --> > is very likely to push both the process of coming up with >>> --> > any proposed solution that meets this requirement - and yet >>> --> > remains scalable - and the process of getting agreement for >>> --> > any such proposed solution. >>> --> >>> --> Ah but this is the opposite goal: to increase the >>> --> scalability. What >>> --> would a PCC receiving a negative reply do unless resending >>> --> additional >>> --> path computation request(s) with different parameter(s) ? >>> --> Thus having >>> --> such capability would be quite useful but I'll let the Service >>> --> Providers who will actually use that solution voice their >>> --> opinion. In >>> --> my previous email, I was just reflecting the outcome of some >>> --> discussions that I had with several of them, thus asking >>> --> whether such >>> --> requirement had not be missed ? >>> --> >>> --> JP. >>> --> >>> --> > I suggest that we might want to better understand the >>> --> > specific customer need - and what the customer is willing >>> --> > to sacrifice in other areas - before we include something >>> --> > like this as a requirement. >>> --> > >>> --> > Short of getting that information, simply stating that >>> --> > this might be a preference - or a desirable goal - is about >>> --> > as strong as I would put it. >>> --> > >>> --> > -- >>> --> > Eric >>> --> > >>> --> > --> -----Original Message----- >>> --> > --> From: pce-bounces@lists.ietf.org >>> --> > --> [mailto:pce-bounces@lists.ietf.org]On >>> --> > --> Behalf Of Ash, Gerald R (Jerry), ALABS >>> --> > --> Sent: Monday, July 11, 2005 7:27 AM >>> --> > --> To: JP Vasseur; pce@ietf.org >>> --> > --> Subject: RE: [Pce] Requirement for less-constrained path >>> --> > --> indraft-ietf-pce-comm-protocol-gen-reqs-00.txt >>> --> > --> >>> --> > --> >>> --> > --> Hi JP, >>> --> > --> >>> --> > --> > Quick question ... I do not see any requirement to get >>> less- >>> --> > --> > constrained TE LSP path in >>> --> > --> > draft-ietf-pce-comm-protocol-gen-reqs-00.txt. >>> --> > --> > In most of the cases, when configuring a TE LSP >>> --> with specific >>> --> > --> > attributes, one of the most challenging part consists of >>> --> > --> determining >>> --> > --> > the attributes values which will not result in the >>> --> > --> inability to find >>> --> > --> > a path in some circumstances (such as network element >>> --> > --> failures). The >>> --> > --> > typical case is the bandwidth. The first approach >>> --> is to try to >>> --> > --> > compute the "closest" solutions. Another approach >>> --> relies on the >>> --> > --> > configuration of multiple set of attributes: >>> --> > --> > 1) The preferred set of attributes >>> --> > --> > 2) One or more less-preferred set of attributes >>> --> > --> > 3) Un-constrained TE LSP >>> --> > --> > >>> --> > --> > When a PCE is used for TE LSP path computation, it looks >>> --> > --> to me that >>> --> > --> > it could be quite useful to be able to specify >>> --> interest in less- >>> --> > --> > constrained path rather than potentially have to >>> --> > --> configure a set of >>> --> > --> > attributes (less optimal) which would result in several >>> --> > --> > rounds of PCC/ >>> --> > --> > PCE communication. >>> --> > --> > >>> --> > --> > Isn't it a requirement that should be listed in >>> --> > --> draft-ietf-pce-comm- >>> --> > --> > protocol-gen-reqs-00.txt? >>> --> > --> >>> --> > --> Sounds OK to me. It would help if you suggested some >>> --> > --> specific text to >>> --> > --> insert in the updated draft sent out last Thursday. >>> --> > --> >>> --> > --> Thanks, >>> --> > --> Jerry >>> --> > --> >>> --> > --> _______________________________________________ >>> --> > --> Pce mailing list >>> --> > --> Pce@lists.ietf.org >>> --> > --> https://www1.ietf.org/mailman/listinfo/pce >>> --> > --> >>> --> > >>> --> >>> >>> >> >> _______________________________________________ >> Pce mailing list >> Pce@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/pce >> >> > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Jul 15 15:50:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtWCd-0005zD-5M; Fri, 15 Jul 2005 15:50:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtWCC-0005pO-V5; Fri, 15 Jul 2005 15:50:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10844; Fri, 15 Jul 2005 15:50:01 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtWf2-0007ol-Sc; Fri, 15 Jul 2005 16:19:54 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1DtWC9-0001r8-KS; Fri, 15 Jul 2005 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 15 Jul 2005 15:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-01.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org --NextPart 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 : PCE Communication Protocol Generic Requirements Author(s) : J. Le Roux, J. Ash Filename : draft-ietf-pce-comm-protocol-gen-reqs-01.txt Pages : 19 Date : 2005-7-15 The PCE model is described in the "PCE Architecture" document and facilitates path computation requests from Path Computation Clients (PCCs) to Path Computation Elements (PCEs). This document specifies generic requirements for a communication protocol between PCCs and PCEs, and also between PCEs where cooperation between PCEs is desirable. Subsequent documents will specify application-specific requirements for the PCE communication protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protocol-gen-reqs-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pce-comm-protocol-gen-reqs-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pce-comm-protocol-gen-reqs-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-7-15114417.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pce-comm-protocol-gen-reqs-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pce-comm-protocol-gen-reqs-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-7-15114417.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --NextPart-- From pce-bounces@lists.ietf.org Fri Jul 15 18:16:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtYR9-00024u-EK; Fri, 15 Jul 2005 18:13:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtYR7-00020Z-99 for pce@megatron.ietf.org; Fri, 15 Jul 2005 18:13:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29830 for ; Fri, 15 Jul 2005 18:13:33 -0400 (EDT) Received: from mail131.messagelabs.com ([216.82.242.99]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1DtYty-0000KC-Mm for pce@ietf.org; Fri, 15 Jul 2005 18:43:29 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-6.tower-131.messagelabs.com!1121465578!5299066!11 X-StarScan-Version: 5.4.15; banners=-,-,- X-Originating-IP: [192.128.133.132] Received: (qmail 22254 invoked from network); 15 Jul 2005 22:13:25 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (192.128.133.132) by server-6.tower-131.messagelabs.com with SMTP; 15 Jul 2005 22:13:25 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by attrh3i.attrh.att.com (7.2.052) id 42BED276003A4591 for pce@ietf.org; Fri, 15 Jul 2005 18:13:25 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-01.txt Date: Fri, 15 Jul 2005 17:13:24 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA060CE67D@KCCLUST06EVS1.ugd.att.com> Thread-Topic: [Pce] I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-01.txt Thread-Index: AcWJfqyfvT4xQsx4THuiSTVcy+e19QAAai2w From: "Ash, Gerald R \(Jerry\), ALABS" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi All, Please review and comment on "PCE Communication Protocol Generic Requirements" http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protocol-gen-req s-01.txt The update incorporates comments on the list and Adrian's very thorough review for the DT -- the main changes are as follows: 1. significant (but mostly editorial) updates to Section 6 'PCEP Generic Requirements', 2. added requirements summary at beginning of Section 6, 3. added requirement on path reoptimization to Section 6.1.4 'Path Computation Requests',=20 4. added requirement for 'less constrained paths' in Section 6.1.4 (Path Computation Requests) and 6.1.5 (Path Computation Responses), as suggested by JP in http://www1.ietf.org/mail-archive/web/pce/current/msg00254.html, 5. added Section 6.1.16 'Constraints'. Open Issues: 1. Regarding item #4 on 'less constrained paths', there were several expressions of support for this requirement from SP's, however, there were countering views from Eric Gray http://www1.ietf.org/mail-archive/web/pce/current/msg00256.html and Adrian http://www1.ietf.org/mail-archive/web/pce/current/msg00268.html. Please review and offer your comments/suggestions. Please review and comment on the I-D. =20 Thanks, Regards, Jerry -----Original Message----- From: pce-bounces@lists.ietf.org [mailto:pce-bounces@lists.ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Friday, July 15, 2005 3:50 PM To: i-d-announce@ietf.org Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-01.txt=20 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 : PCE Communication Protocol Generic Requirements Author(s) : J. Le Roux, J. Ash Filename : draft-ietf-pce-comm-protocol-gen-reqs-01.txt Pages : 19 Date : 2005-7-15 =09 The PCE model is described in the "PCE Architecture" document and facilitates path computation requests from Path Computation Clients (PCCs) to Path Computation Elements (PCEs). This document specifies generic requirements for a communication protocol between PCCs and PCEs, and also between PCEs where cooperation between PCEs is desirable. Subsequent documents will specify application-specific requirements for the PCE communication protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protocol-gen-req s-01.txt _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Sat Jul 16 06:28:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dtjue-0003Yj-Tp; Sat, 16 Jul 2005 06:28:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dtjuc-0003WT-W6 for pce@megatron.ietf.org; Sat, 16 Jul 2005 06:28:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06739 for ; Sat, 16 Jul 2005 06:28:48 -0400 (EDT) From: Dimitri.Papadimitriou@alcatel.be Received: from smail.alcatel.fr ([64.208.49.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtkNb-0002Bq-Nf for pce@ietf.org; Sat, 16 Jul 2005 06:58:49 -0400 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id j6GASfDD028008; Sat, 16 Jul 2005 12:28:42 +0200 MIME-Version: 1.0 To: "Ash, Gerald R \(Jerry\), ALABS" Subject: RE: [Pce] I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-01.txt Date: Sat, 16 Jul 2005 12:28:40 +0200 Message-ID: X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.12HF788 | September 23, 2004) at 07/16/2005 12:28:41 MIME-Version: 1.0 X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Score: 4.3 (++++) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0520737924==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org --===============0520737924== Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 PFA+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPmhpIGplcnJ5LCBhdXRob3JzPEJSPjxC Uj50aGFua3MgZm9yIHRoZSB1cGRhdGUgLSBpIGhhdmUgc2V2ZXJhbCBjb21tZW50czo8QlI+PEJS PnNlY3Rpb24gNi4xLjI8QlI+PEJSPiZxdW90OyBUaGVyZSBpcyBubyByZXF1aXJlbWVudCB0byBt YWludGFpbiBhIHNlc3Npb24gb3IgYXNzb2NpYXRpb24gYmV0d2VlbjxCUj5jb21tdW5pY2F0aW5n IFBDQyBhbmQgUENFLCBub3IgYmV0d2VlbiBjb21tdW5pY2F0aW5nIFBDRXMuIFRoZTxCUj5yZXF1 ZXN0L3Jlc3BvbnNlIGV4Y2hhbmdlIGRlZmluZXMgYSBsaW1pdGVkIGFzc29jaWF0aW9uIGJldHdl ZW48QlI+cmVxdWVzdGVyIGFuZCByZXNwb25kZXIuJnF1b3Q7PEJSPjxCUj5vayBidXQgdGhpcyBp cyB0aGUgcmVzdWx0aW5nIHJlcXVpcmVtZW50IHdoYXQgYWJvdXQgcmVxdWlyZW1lbnRzIGluIHRl cm1zIG9mIHJlc3BvbnNpdm5lc3MgKGluIHBhcnRpY3VsYXIgd2hlbiBhIHNlcXVlbmNlIG9mIFBD RXMgaXMgaW52b2x2ZWQpIGFuZCBtYWludGVuYW5jZSA/IGFsc28gdGhlcmUgaXMgYSB0b28gaGln aCBleHBlY3RhdGlvbiBpbiB0ZXJtcyBvZiB3aGF0IHRoZSBkaXNjb3ZlcnkgcHJvY2VzcyB3aWxs IGRlbGl2ZXIgaGVyZSAtIHRoaXMgcG9pbnQgaGFzIGFscmVhZHkgYmVlbiBkaXNjdXNzZWQgb24g dGhpcyBsaXN0IC08QlI+PEJSPndoYXQgdGhlICZxdW90O2Fzc29jaWF0aW9uJnF1b3Q7IG1lYW5z IGhlcmUgPzxCUj48QlI+c2VjdGlvbiA2LjEuNDxCUj48QlI+JnF1b3Q7IFRoZSByZXF1ZXN0IG1l c3NhZ2UgTVVTVCBpbmNsdWRlLCBhdCBsZWFzdCwgYSBzb3VyY2UgYW5kIGE8QlI+ZGVzdGluYXRp b24uICZxdW90OzxCUj48QlI+aXQgc2VlbXMgdG8gbWUgdGhpcyBpcyBub3QgdGhlIG9ubHkgcmVx dWlyZW1lbnQgb25lIGhhcyB0byBkZWFsIHdpdGggYXMgdGhlcmUgaXMgYW4gaW1wbGljaXQgYXNz dW1wdGlvbiB0aGF0IHRoZSByZWNlaXZpbmcgUENFIGFzIGZ1bGwgdmlzaW9uIG9mIHRoZSBzb3Vy Y2UvZGVzdCBkb21haW4gdG9wb2xvZ3kgLSBpcyB0aGF0IGEgc2FmZSBhc3N1bXB0aW9uID8gLSB3 aGF0IGFib3V0IFBDRSBob3N0aW5nIHVuY29tcGxldGUgdG9wb2xvZ2ljYWwgaW5mb3JtYXRpb24g b2YgZS5nLiBwZXJpcGhlcmljYWwgbmV0d29ya3MgPEJSPjxCUj5zZWN0aW9uIDYuMS44PEJSPjxC Uj4mcXVvdDsgLSBGbG93IGNvbnRyb2wgYW5kIGJhY2stcHJlc3N1cmUsIGFzIHNwZWNpZmllZCBh Ym92ZSB3aXRoIHRoZTxCUj50aHJvdHRsaW5nIG9mIHJlcXVlc3RzLiZxdW90OzxCUj48QlI+aSBh bSBsb29raW5nIGFib3ZlIGJ1dCBkbyBub3Qgc2VlIG11Y2ggZGV0YWlscyBhYm91dCB0aGlzIHJl cXVpcmVtZW50LCB3aGljaCBpcyB0aGUgY29ybmVyc3RvbmUgZm9yIGhhbmRsaW5nIG92ZXJsb2Fk czxCUj48QlI+c2VjdGlvbiA2LjEuMTE8QlI+PEJSPndoeSB1bnNvbGljaXRlZCBub3RpZmljYXRp b25zIHNoYWxsIGFsc28gY292ZXIgJnF1b3Q7dXBkYXRlZCBwYXRoJnF1b3Q7IGlzIHRoZXJlIGEg cmVxdWlyZW1lbnQgdGhhdCBvbmNlIGNvbXB1dGVkIHRoZSBQQ0Ugc2hhbGwgdGhlIFBDQyB1cGRh dGVkIHdpdGggbmV3IChhbmQgdW5zb2xpY2l0ZWQpIGNvbXB1dGF0aW9uYWwgcmVzdWx0cyA/PEJS PjxCUj5zZWN0aW9uIDYuMS4xNTxCUj48QlI+JnF1b3Q7VGhlIFBDRVAgTVVTVCBzY2FsZSB3ZWxs LCBhdCBsZWFzdCBhcyBnb29kIGFzIGxpbmVhcmx5LCB3aXRoIGFuPEJSPmluY3JlYXNlIG9mIGFu eSBvZiB0aGUgZm9sbG93aW5nIHBhcmFtZXRlcnM6PEJSPjxCUj4tIG51bWJlciBvZiBQQ0NzPEJS Pi0gbnVtYmVyIG9mIFBDRXM8QlI+LSBudW1iZXIgb2YgUENDcyBjb21tdW5pY2F0aW5nIHdpdGgg YSBzaW5nbGUgUENFPEJSPi0gbnVtYmVyIG9mIFBDRXMgY29tbXVuaWNhdGVkIHRvIGJ5IGEgc2lu Z2xlIFBDQzxCUj4tIG51bWJlciBvZiBQQ0VzIGNvbW11bmljYXRlZCB0byBieSBhbm90aGVyIFBD RTxCUj4tIG51bWJlciBvZiBkb21haW5zPEJSPi0gbnVtYmVyIG9mIHBhdGggcmVxdWVzdHM8QlI+ LSBoYW5kbGluZyBidXJzdHMgb2YgcmVxdWVzdHMuJnF1b3Q7PEJSPjxCUj5pdCB3b3VsZCBoYXZl IHN1cnByaXNlZCBtZSBzb21lb25lIHdvdWxkIGhhdmUgc2FpZCB0aGUgc3lzdGVtIHNob3VsZCBu b3QgYmUgc2NhbGFibGUgLSBtb3JlIGluZGljYXRpdmUgaXMgdGhlIGV4cGVjdGF0aW9uIGluIHRl cm1zIG9mIG51bWJlciBvZiByZXF1ZXN0cyBwZXIgdW5pdCBvZiB0aW1lIChhdmVyYWdlL21pbi9t YXgpIGFuZCB0aGUgbnVtYmVyIG9mIFBDRXMgaW52b2x2ZWQgaW4gdGhlIHByb2Nlc3MgcGVyIHJl cXVlc3QgKG5vdGUgdGhhdCBjb25jZXJuaW5nIHRoZSBQQ0Mgd2UgaGF2ZSBhIHJvdWdoIGlkZWEg YWJvdXQgdGhlIHRvcG9sb2dpZXMgUENFIFdHIGlzIGV4cGVjdGVkIHRvIGNvdmVyKSAtIHRoaXMg c2FpZCBzb21lIGluZGljYXRpdmUgYm91bmRhcnkgbnVtYmVycyBjb3VsZCBiZSBoZWxwZnVsIGZv ciB0aGUgZGVzaWduIGl0c2VsZjxCUj48QlI+bGFzdCBwb2ludDogY29uY2VybmluZyB0aGUgb3Bl biBwb2ludCB5b3VyIGFyZSBtZW50aW9uaW5nIGkgaGF2ZSB0aGUgZ2VuZXJhbCBmZWVsaW5nIHRo YXQgdGhlIGJhciBoYXMgYmVlbiBwdXQgdG8gaGlnaCBpbiB0ZXJtcyBvZiBQQ0UgY2FwYWJpbGl0 aWVzIHdoaWNoIGF0IHRoZSBlbmQgc29tZWhvdyBtYWtlcyB0aGUgYWNoaWV2YWJpbGl0eSBvZiBy ZXF1aXJlbWVudCBzdGF0ZWQgaW4gc2VjdGlvbiA2LjEuMTMgZGlmZmljdWx0PC9GT05UPjwvUD4= --===============0520737924== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============0520737924==-- From pce-bounces@lists.ietf.org Sat Jul 16 20:09:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dtwih-0005wF-Or; Sat, 16 Jul 2005 20:09:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dtwif-0005wA-62 for pce@megatron.ietf.org; Sat, 16 Jul 2005 20:09:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09430 for ; Sat, 16 Jul 2005 20:09:17 -0400 (EDT) Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1DtxBg-0000yI-SP for pce@ietf.org; Sat, 16 Jul 2005 20:39:26 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-13.tower-121.messagelabs.com!1121558943!3379090!2 X-StarScan-Version: 5.4.15; banners=-,-,- X-Originating-IP: [192.128.133.132] Received: (qmail 31108 invoked from network); 17 Jul 2005 00:09:03 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (192.128.133.132) by server-13.tower-121.messagelabs.com with SMTP; 17 Jul 2005 00:09:03 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by attrh3i.attrh.att.com (7.2.052) id 42BED276003AFFCA; Sat, 16 Jul 2005 20:09:03 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-01.txt Date: Sat, 16 Jul 2005 19:09:02 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA09FA90C8@KCCLUST06EVS1.ugd.att.com> Thread-Topic: [Pce] I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-01.txt Thread-Index: AcWJ8SYzvDKrE0vDRNayFSuaOgFTEAAbheowAAAIYvA= From: "Ash, Gerald R \(Jerry\), ALABS" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Content-Transfer-Encoding: quoted-printable Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi Dimitri, Thanks a lot for your review and comments. > i have several comments: >=20 > section 6.1.2 >=20 > " There is no requirement to maintain a session or association between > communicating PCC and PCE, nor between communicating PCEs. The > request/response exchange defines a limited association between > requester and responder." >=20 > ok but this is the resulting requirement what about=20 > requirements in terms of responsiveness (in particular when a=20 > sequence of PCEs is involved) and maintenance? Agree, requirements on responsiveness would be good, but may be difficult to quantify in general (especially with multiple PCE computations). Not sure what requirements you are suggesting for 'maintenance', as related to PCEP? Maintenance of what? > also there is=20 > a too high expectation in terms of what the discovery process=20 > will deliver here - this point has already been discussed on=20 > this list - Not sure what point you're referring to here RE the discovery process? =20 > what the "association" means here? Right, needs to be stated more precisely. > section 6.1.4 >=20 > " The request message MUST include, at least, a source and a > destination. " >=20 > it seems to me this is not the only requirement one has to=20 > deal with as there is an implicit assumption that the=20 > receiving PCE as full vision of the source/dest domain=20 > topology - is that a safe assumption? No, especially in the multiple PCE path computation model (see Sections 6.3 and 6.4 of the PCE architecture document http://www.ietf.org/internet-drafts/draft-ietf-pce-architecture-00.txt). I see your point, needs to be clarified. > - what about PCE=20 > hosting uncomplete topological information of e.g.=20 > peripherical networks=20 Right, this is a typical case IMO. > section 6.1.8 >=20 > " - Flow control and back-pressure, as specified above with the > throttling of requests." >=20 > i am looking above but do not see much details about this=20 > requirement, which is the cornerstone for handling overloads Correct, there is not much detail or specifics on 'throttling of requests', just a requirement to be able to throttle messages. What detail do you suggest for this requirement? =20 > section 6.1.11 >=20 > why unsolicited notifications shall also cover "updated path"=20 > is there a requirement that once computed the PCE shall the=20 > PCC updated with new (and unsolicited) computational results? It is not a SHALL requirement for the PCE to update the PCC in an unsolicited manner, just a required capability. =20 > section 6.1.15 >=20 > "The PCEP MUST scale well, at least as good as linearly, with an > increase of any of the following parameters: >=20 > - number of PCCs > - number of PCEs > - number of PCCs communicating with a single PCE > - number of PCEs communicated to by a single PCC > - number of PCEs communicated to by another PCE > - number of domains > - number of path requests > - handling bursts of requests." >=20 > it would have surprised me someone would have said the system=20 > should not be scalable - more indicative is the expectation=20 > in terms of number of requests per unit of time=20 > (average/min/max) and the number of PCEs involved in the=20 > process per request (note that concerning the PCC we have a=20 > rough idea about the topologies PCE WG is expected to cover)=20 > - this said some indicative boundary numbers could be helpful=20 > for the design itself Agreed it would be good to plug in 'boundary' numbers here to quantify scalability. However, I'm skeptical that can agree on the right numbers, but one can try :-) =20 > last point: concerning the open point your are mentioning i=20 > have the general feeling that the bar has been put to high in=20 > terms of PCE capabilities which at the end somehow makes the=20 > achievability of requirement stated in section 6.1.13 difficult Agreed, we need to be sensitive to (too much) feature creep. Thanks, Regards, Jerry _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Sun Jul 17 07:39:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Du7Us-0000Dy-UK; Sun, 17 Jul 2005 07:39:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Du7Us-0000Dt-6T for pce@megatron.ietf.org; Sun, 17 Jul 2005 07:39:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28470 for ; Sun, 17 Jul 2005 07:39:49 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Du7y3-0000IU-I8 for pce@ietf.org; Sun, 17 Jul 2005 08:10:01 -0400 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1Du7Ul-000Owh-FW; Sun, 17 Jul 2005 11:39:43 +0000 Message-ID: <42DA4389.8080304@psg.com> Date: Sun, 17 Jul 2005 13:39:53 +0200 From: dimitri papadimitriou User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Ash, Gerald R \(Jerry\), ALABS" Subject: Re: [Pce] I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-01.txt References: <9473683187ADC049A855ED2DA739ABCA09FA90C8@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <9473683187ADC049A855ED2DA739ABCA09FA90C8@KCCLUST06EVS1.ugd.att.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb Content-Transfer-Encoding: 7bit Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org hi jerry - see in-line for some clarifications: Ash, Gerald R (Jerry), ALABS wrote: > Hi Dimitri, > > Thanks a lot for your review and comments. > >>i have several comments: >> >>section 6.1.2 >> >>" There is no requirement to maintain a session or association between >>communicating PCC and PCE, nor between communicating PCEs. The >>request/response exchange defines a limited association between >>requester and responder." >> >>ok but this is the resulting requirement what about >>requirements in terms of responsiveness (in particular when a >>sequence of PCEs is involved) and maintenance? > > Agree, requirements on responsiveness would be good, but may be > difficult to quantify in general (especially with multiple PCE > computations). > > Not sure what requirements you are suggesting for 'maintenance', as > related to PCEP? Maintenance of what? maintenance of the relationship between PCEs, if such mechanism is not in place the "local" PCE may receive request that it can not further send to other peering PCE(s) while during the time the local PCE discovers its peering PCE(s) are down such amount of request may be quite high - in brief, the "local PCE" should minimize the number of incoming request it can not (temporarily) process otherwise - note: the term "limited" in the above paragraph does not tell if a PCC sends multiple requests to the PCE whether these are making use of the same "transport" connection or whether a new one is established for each request >>also there is >>a too high expectation in terms of what the discovery process >>will deliver here - this point has already been discussed on >>this list - > > Not sure what point you're referring to here RE the discovery process? yes - in part. section 6.4 and 6.5 of the discovery document >>what the "association" means here? > > Right, needs to be stated more precisely. > >>section 6.1.4 >> >>" The request message MUST include, at least, a source and a >>destination. " >> >>it seems to me this is not the only requirement one has to >>deal with as there is an implicit assumption that the >>receiving PCE as full vision of the source/dest domain >>topology - is that a safe assumption? > > No, especially in the multiple PCE path computation model (see Sections > 6.3 and 6.4 of the PCE architecture document > http://www.ietf.org/internet-drafts/draft-ietf-pce-architecture-00.txt). > I see your point, needs to be clarified. > >>- what about PCE >>hosting uncomplete topological information of e.g. >>peripherical networks > > Right, this is a typical case IMO. > >>section 6.1.8 >> >>" - Flow control and back-pressure, as specified above with the >>throttling of requests." >> >>i am looking above but do not see much details about this >>requirement, which is the cornerstone for handling overloads > > Correct, there is not much detail or specifics on 'throttling of > requests', just a requirement to be able to throttle messages. What > detail do you suggest for this requirement? > >>section 6.1.11 >> >>why unsolicited notifications shall also cover "updated path" >>is there a requirement that once computed the PCE shall the >>PCC updated with new (and unsolicited) computational results? > > It is not a SHALL requirement for the PCE to update the PCC in an > unsolicited manner, just a required capability. > >>section 6.1.15 >> >>"The PCEP MUST scale well, at least as good as linearly, with an >>increase of any of the following parameters: >> >>- number of PCCs >>- number of PCEs >>- number of PCCs communicating with a single PCE >>- number of PCEs communicated to by a single PCC >>- number of PCEs communicated to by another PCE >>- number of domains >>- number of path requests >>- handling bursts of requests." >> >>it would have surprised me someone would have said the system >>should not be scalable - more indicative is the expectation >>in terms of number of requests per unit of time >>(average/min/max) and the number of PCEs involved in the >>process per request (note that concerning the PCC we have a >>rough idea about the topologies PCE WG is expected to cover) >>- this said some indicative boundary numbers could be helpful >>for the design itself > > Agreed it would be good to plug in 'boundary' numbers here to quantify > scalability. However, I'm skeptical that can agree on the right > numbers, but one can try :-) yes - this is what i would suggest as this work is driven by the user community i hope one could come with a representative sample >>last point: concerning the open point your are mentioning i >>have the general feeling that the bar has been put to high in >>terms of PCE capabilities which at the end somehow makes the >>achievability of requirement stated in section 6.1.13 difficult > > Agreed, we need to be sensitive to (too much) feature creep. this is also the approach i would make use of i.e. a less featured PCE but more robust protocol construction - at least in a first phase - thanks, - dimitri. > Thanks, > Regards, > Jerry > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > > . > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Jul 18 08:54:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuV8h-0002uF-V1; Mon, 18 Jul 2005 08:54:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuV8d-0002sM-6D for pce@megatron.ietf.org; Mon, 18 Jul 2005 08:54:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07589 for ; Mon, 18 Jul 2005 08:54:25 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DuVc0-0006Xh-TN for pce@ietf.org; Mon, 18 Jul 2005 09:24:52 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 18 Jul 2005 08:54:16 -0400 X-IronPort-AV: i="3.93,297,1115006400"; d="scan'208"; a="62817660:sNHT27546244" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j6ICs5W6017757; Mon, 18 Jul 2005 08:54:13 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 18 Jul 2005 08:54:12 -0400 Received: from [192.168.1.100] ([10.86.240.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 18 Jul 2005 08:54:11 -0400 Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8BDFACD0-7ED4-46B4-9DB1-195C9AD8EFFB@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Date: Mon, 18 Jul 2005 08:54:28 -0400 To: pce@ietf.org X-Mailer: Apple Mail (2.730) X-OriginalArrivalTime: 18 Jul 2005 12:54:11.0872 (UTC) FILETIME=[CB662A00:01C58B97] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: akatlas@alum.mit.edu Subject: [Pce] New revision of PCEP protocol published X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi, FYI, a new revision of the PCEP protocol has been published: http:// www.ietf.org/internet-drafts/draft-vasseur-pce-pcep-01.txt Main changes compared to the previous revision: 1) Support of Multiple requests per PCReq message, multiple set of computed paths per PCRep message, multiple notifications per PCNtf message, multiple Errors per PCErr message => Thus, object ordering is now required. 2) Several sections were re-written, text added/removed, ... for the sake of clarity. 3) Various errors fixed, 4) Change in the rules specifying whether some objects are required or optional in various PCEP message 5) New objects added: ENCAP (to carry other protocol's objects, when relevant), NO-PATH object (used in negative reply) 6) New section added that provides an "overall protocol architecture" (Protocol Model - RFC 4101) 7) New section related to Security 8) New section related to Manageability The comments received from Adrian Farrel, Jerry Ash, Igor Bryskin have been incorporated. Any comment is as usual very welcome. JP. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Jul 18 15:50:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dubdj-0008HC-DG; Mon, 18 Jul 2005 15:50:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dubcs-0007ve-W6; Mon, 18 Jul 2005 15:50:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10382; Mon, 18 Jul 2005 15:50:05 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Duc6J-0006XB-0l; Mon, 18 Jul 2005 16:20:32 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1Dubcn-0002HJ-UO; Mon, 18 Jul 2005 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 18 Jul 2005 15:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-discovery-reqs-01.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org --NextPart 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 : Requirements for Path Computation Element (PCE) Discovery Author(s) : J. Le Roux Filename : draft-ietf-pce-discovery-reqs-01.txt Pages : 13 Date : 2005-7-18 This document presents a set of requirements for a Path Computation Element (PCE) discovery mechanism that would allow a Path Computation Client (PCC) to discover dynamically and automatically a set of PCEs along with certain information relevant for PCE selection. It is intended that solutions that specify procedures and protocol(s) or protocol(s) extensions for such PCE discovery satisfy these requirements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-discovery-reqs-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pce-discovery-reqs-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pce-discovery-reqs-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-7-18150612.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pce-discovery-reqs-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pce-discovery-reqs-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-7-18150612.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --NextPart-- From pce-bounces@lists.ietf.org Mon Jul 18 15:57:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dubk6-0001ZK-SD; Mon, 18 Jul 2005 15:57:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dubk3-0001Z5-SM for pce@megatron.ietf.org; Mon, 18 Jul 2005 15:57:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11817 for ; Mon, 18 Jul 2005 15:57:30 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DucDX-00078B-PD for pce@ietf.org; Mon, 18 Jul 2005 16:28:00 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id j6IJvC79007387; Mon, 18 Jul 2005 15:57:12 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA24504; Mon, 18 Jul 2005 15:57:14 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id ; Mon, 18 Jul 2005 15:57:13 -0400 Message-ID: <313680C9A886D511A06000204840E1CF0C885D02@whq-msgusr-02.pit.comms.marconi.com> From: "Gray, Eric" To: "'JP Vasseur'" , Adrian Farrel Subject: RE: [Pce] Requirement for less-constrained path indraft-ietf-pce- comm-protocol-gen-reqs-00.txt Date: Mon, 18 Jul 2005 15:57:10 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 65bc4909d78e8b10349def623cf7a1d1 Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org JP, From your earlier response, I see that you're aiming at the "greater of two evil" solutions. Tch, tch, tch!! Please see below... --> -----Original Message----- --> From: JP Vasseur [mailto:jvasseur@cisco.com] --> Sent: Thursday, July 14, 2005 9:19 PM --> To: Adrian Farrel --> Cc: Gray, Eric; pce@ietf.org --> Subject: Re: [Pce] Requirement for less-constrained path --> indraft-ietf-pce-comm-protocol-gen-reqs-00.txt --> --> --> --> On Jul 14, 2005, at 12:26 PM, Adrian Farrel wrote: --> --> > I want to pitch in on this thread because I think (I) see --> > where both JP and Eric are coming from. JP's proposals have --> > the potential to significantly reduce the PCE processing --> > and cut down number of PCC-PCE transactions, but they also --> > have the ability to massively increase the processing and --> > the size of the PCC-PCE transactions. --> > --> --> that said, it it pretty straightforward to see that the benefits --> undoubtedly outweigh the drawbacks. The request processing is --> definitely negligible compared to the communication overhead. This is the point of obvious disagreement. --> Actually, it could be shown that the non support of such capability --> would have a drastic scalability impact on the solution especially --> upon resource contention. Only if you assume that communication is the bottleneck. Reality is that messaging only becomes a bottleneck if message processing is excessively complex and/or it is done in a poorly thought out way. If the communication issue is not with messaging, then what is it? --> --> > Thus we need to be quite careful in the specification of the --> > protocol requirements and the protocol itself. It is not OK --> > for us to say that if an individual PCC is irresponsible or --> > stupid that is its problem, because such an implementation --> > would break the accessibility to the PCE for other 'normal' --> > PCCs. --> > --> --> On this aspect, I do agree ! --> --> > Unless there are "standard" constraint back-off functions --> > it is hard to conceive of a PCE guessing the correct back- --> > off for the PCC that issued the request. Note that the more --> > "speculative paths" the PCE computes the more CPU it uses. --> --> Speculative paths is definitely not an option considering the --> number of permutations ... we would unavoidably quickly fall --> into some NP-Complete issues ;-) ... This is why the suggestion --> is made to start some discussion on the hierarchical relaxation --> policy. Note that it does not have to be awfully complex ... Here we have many things said in few words. I know, because I can identify numerous points for both agreement and disagreement. :-) The issue with permutations (and NP-complete issues) is one part on which I think we agree. The notion that a hierarchical relaxation approach avoids this is one part on which I think we disagree. Finally, the "wish" that it does not have to be complex is quite interesting. The only way that it will not be complex, is if the actual decision making process is very simple in every case. The point of contention is the fact that - while it probably can be very simple in most cases - it will almost certainly not be 1) the same in every case and 2) good enough in every case. If a different hierarchical relaxation policy might apply under different circumstances, then the complexity of the protocol is going to be greater than the combination of all "simple cases". If the approach is not "good enough", then a PCC is forced to fall back on the multiple messages approach. Net gain: ~zero. --> --> > So we must keep good control on this. It is a --> > computational myth that it is possible to relax different --> > constraints on a --> > single computational pass. --> --> Ah no ... there are several constraints for which --> constraint can be relaxed and closest match can be --> found in on-go. --> --> That said, even if it were not the case, the solution --> would still be valuable to cut-down the communication --> overhead and amount of processing signaling be the --> PCE's scheduler. --> --> > In fact, the question "where did my computation fail" --> > is notoriously impossible to answer except with the --> > response "in the network". --> > --> > Thus we should give full control to the PCC, and let --> > the PCE choose to supply less information if it thinks --> > that the PCC is asking too much. This control includes: --> > --> > a. The ability to say "this or nothing" --> > b. The ability to say "tell me what constraints I --> > might relax to get a path" --> > c. The ability to say "give me n alternate paths with --> > with your choice of relaxed constraints" (c. is --> > like b but with the paths supplied, and it is --> > important to control the number) --> > d. A way to state which constraints may be relaxed --> > absolutely (this is easy) --> > e. A way to replace one constraint supplied by the --> > PCC with another also supplied by the PCC --> > f. A way to specify an ordering for relaxation in --> > recomputation attempts. --> > --> > My feeling is that e might be satisfied in the protocol --> > simply by listing the same object multiple times. But f --> > is very messy. As soon as I have a few constraints and --> > I am willing to relax each of them by degrees I have a --> > very complex relaxation problem to express. --> --> Well not so sure ... Let's wait for the meeting in Paris to --> have an open discussion. I'd be happy to provide some ideas. --> Actually one could point out that such constraint relaxation --> are used TODAY in operational networks (with CSPF). One could point that out, if one wants to show that having a PCC make separate requests is the right way to go. I was under the impression you were arguing the opposition point of view. In the CSPF case you identify, the Traffic Engineer is both a PCC and a PCE and - with respect to the relaxation mode, it is much more likely to act like a PCC than a PCE. In other words, given a requirement for TE tunnel routing, it will most likely complete a computation based on a single set of constraints and - if that fails - it may elect to relax the path requirements and try again with different constraints. This is essentially PCC behavior. Pushing this behavior into the PCE saves on external messaging overhead, but at a huge cost in complexity. Now, instead of having a self-contained entity (the PCC) deciding how next to proceed in getting a Path (should any attempt fail), it must communicate a decision making process to a delegate (the PCE) for every Path request - irrespective of whether or not that Path Request would fail. Unless the decision making options are very limited, this must impose a higher level of processing on the PCE just to decode, store and - eventually - act on the decision making process. I doubt that the communication overhead is the bottle-neck for PCE-PCC transactions, or the network over which they transpire. I also strongly suspect that deployments will tend toward more PCCs than PCEs, so - assuming that (for example) there are ten times as many PCCs as PCEs - what is the advantage gained by pushing the work of 1,000 PCCs onto 100 PCEs, especially if you assume that most path requests will be satisfied prior to a PCC traversal of the decision tree. --> --> > --> > This is a problem that it is very easy for the PCC to --> > handle by issuing successive requests, but very hard for --> > the PCC to communicate to the PCE in a single request. --> --> I do not think that it is hard for the PCC to communicate --> to the PCE in a single request. You miss the point. If "communication" was easy, you wouldn't have started this discussion, and I wouldn't be continuing it. :-) Let's say that PCC X follows this scheme for one subset of its requests: scheme (a) Request a path with constraints A, B and C. On failure for A, request a path with constraint A1 that still satisfies B and C. On failure for A1, B or C, fail. To cut down on communication overhead, we could communicate this decision making policy to the PCE and make a single request that either succeeds or fails according to this policy. But this PCC (or another) also has a decision making schemes as follows for other types of services: scheme (b) Request a path with constraint A, C and D. On failure for C, request a path with constraints A and D only On failure for A or D, fail. scheme (c) Request a path with constraints B, C and D. On failure (for B, C or D) request an unconstrained shortest path. ... and so on ... Hence, given any arbitrary number of potential constraints, the number of possible decision making policies we need to define is clearly combinatorial (i.e. - NP) in the number of possible constraints (and possible relaxations of each). However, if we do not cover all of the possibilities, then we constrain the services that our customers can sell, their ability to differentiate themselves from their competitors and even the service pricing structures that are available to their customers in turn. To eliminate this concern, all we need to do is define a language for describing a decision making process. Done much work in the area of defining languages like this? :-) --> --> > --> > So, I'd like to see some text from SPs on this subject --> > before we add anything to the requirements I-D. --> > --> --> I think that the DT is working on it. So, this is confusing. Are you saying that it's out of the hands of the WG because the authors are taking this work on anyway? --> --> Cheers, --> --> JP. --> --> > Cheers, --> > Adrian --> > --> > --- [SNIP] --- _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue Jul 19 03:37:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dumf6-00080f-Ne; Tue, 19 Jul 2005 03:37:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dumf5-00080J-AI for pce@megatron.ietf.org; Tue, 19 Jul 2005 03:37:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16832 for ; Tue, 19 Jul 2005 03:37:05 -0400 (EDT) Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dun8f-0000GR-00 for pce@ietf.org; Tue, 19 Jul 2005 04:07:42 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Tue, 19 Jul 2005 09:35:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE : [Pce] I-D ACTION:draft-ietf-pce-discovery-reqs-01.txt Date: Tue, 19 Jul 2005 09:35:28 +0200 Message-ID: Thread-Topic: [Pce] I-D ACTION:draft-ietf-pce-discovery-reqs-01.txt Thread-Index: AcWL1ewXb8kunvPATVCeJZPugmzTOAAWTxIA From: "LE ROUX Jean-Louis RD-CORE-LAN" To: X-OriginalArrivalTime: 19 Jul 2005 07:35:30.0591 (UTC) FILETIME=[70A3FAF0:01C58C34] X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi all, Here are the major changes in this new revision: -The PCE discovery mechanism MUST support discovery of basic PCE = information:PCE location, domain(s) under control, and path comp scope(s); and MAY also be used = so=20 as to disclose some PCE path computation capabilities=20 -Added discovery of the set of one ore more domain(s) towards which a = PCE=20 can compute paths -Added a security requirements section -Plus several rewordings for the sake of clarity This takes into account comments from Eric, Igor and Dimitri. Your comments on this new version would be welcome. Best Regards, JL =09 >-----Message d'origine----- >De : pce-bounces@lists.ietf.org=20 >[mailto:pce-bounces@lists.ietf.org] De la part de=20 >Internet-Drafts@ietf.org >Envoy=E9 : lundi 18 juillet 2005 21:50 >=C0 : i-d-announce@ietf.org >Cc : pce@ietf.org >Objet : [Pce] I-D ACTION:draft-ietf-pce-discovery-reqs-01.txt=20 > > >A New Internet-Draft is available from the on-line=20 >Internet-Drafts directories. This draft is a work item of the=20 >Path Computation Element Working Group of the IETF. > > Title : Requirements for Path Computation=20 >Element (PCE) Discovery > Author(s) : J. Le Roux > Filename : draft-ietf-pce-discovery-reqs-01.txt > Pages : 13 > Date : 2005-7-18 >=09 >This document presents a set of requirements for a Path Computation=20 > Element (PCE) discovery mechanism that would allow a Path=20 >Computation=20 > Client (PCC) to discover dynamically and automatically a=20 >set of PCEs=20 > along with certain information relevant for PCE selection. It is=20 > intended that solutions that specify procedures and protocol(s) or=20 > protocol(s) extensions for such PCE discovery satisfy these=20 > requirements. > >A URL for this Internet-Draft is:=20 >http://www.ietf.org/internet-drafts/draft-ietf-pce-discovery-reqs-01.txt= To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of = the message. =20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the = username "anonymous" and a password of your e-mail address. After = logging in, type "cd internet-drafts" and then "get draft-ietf-pce-discovery-reqs-01.txt". A list of Internet-Drafts directories can be found in = http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pce-discovery-reqs-01.txt". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. =09 =09 Below is the data which will enable a MIME compliant mail reader = implementation to automatically retrieve the ASCII version of the = Internet-Draft. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue Jul 19 07:49:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuqbV-00031M-LD; Tue, 19 Jul 2005 07:49:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuqbT-0002z3-2f; Tue, 19 Jul 2005 07:49:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04942; Tue, 19 Jul 2005 07:49:38 -0400 (EDT) Received: from [12.16.56.39] (helo=afir) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dur2y-0002gx-Ak; Tue, 19 Jul 2005 08:18:04 -0400 Received: from mail pickup service by afir with Microsoft SMTPSVC; Tue, 19 Jul 2005 07:47:56 -0400 Received: from mail53.messagelabs.com ([216.82.255.35]) by afir with Microsoft SMTPSVC(5.0.2195.6713); Mon, 18 Jul 2005 16:04:23 -0400 X-VirusChecked: Checked X-Env-Sender: i-d-announce-bounces@ietf.org X-Msg-Ref: server-5.tower-53.messagelabs.com!1121716982!65376323!1 X-StarScan-Version: 5.4.15; banners=-,-,anspach.com X-Originating-IP: [132.151.6.71] X-SpamReason: No, hits=2.3 required=7.0 tests=MIME_BOUND_NEXTPART, NO_REAL_NAME,SUBJECT_RANDOMQ Received: (qmail 22353 invoked from network); 18 Jul 2005 20:03:02 -0000 Received: from megatron.ietf.org (132.151.6.71) by server-5.tower-53.messagelabs.com with SMTP; 18 Jul 2005 20:03:02 -0000 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DubdZ-0008ES-8h; Mon, 18 Jul 2005 15:50:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dubcs-0007ve-W6; Mon, 18 Jul 2005 15:50:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10382; Mon, 18 Jul 2005 15:50:05 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Duc6J-0006XB-0l; Mon, 18 Jul 2005 16:20:32 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1Dubcn-0002HJ-UO; Mon, 18 Jul 2005 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 18 Jul 2005 15:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-OriginalArrivalTime: 18 Jul 2005 20:04:23.0640 (UTC) FILETIME=[E4696580:01C58BD3] X-Spam-Score: 0.4 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-discovery-reqs-01.txt X-BeenThere: pce@lists.ietf.org Reply-To: internet-drafts@ietf.org List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org --NextPart 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 : Requirements for Path Computation Element (PCE) Discovery Author(s) : J. Le Roux Filename : draft-ietf-pce-discovery-reqs-01.txt Pages : 13 Date : 2005-7-18 This document presents a set of requirements for a Path Computation Element (PCE) discovery mechanism that would allow a Path Computation Client (PCC) to discover dynamically and automatically a set of PCEs along with certain information relevant for PCE selection. It is intended that solutions that specify procedures and protocol(s) or protocol(s) extensions for such PCE discovery satisfy these requirements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-discovery-reqs-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pce-discovery-reqs-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pce-discovery-reqs-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ______________________________________________________________________ This e-mail has been scanned by MCI Managed Email Content Service, using Skeptic(tm) technology powered by MessageLabs. For more information on MCI's Managed Email Content Service, visit http://www.mci.com. ______________________________________________________________________ --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-7-18150612.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pce-discovery-reqs-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pce-discovery-reqs-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-7-18150612.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --NextPart-- From pce-bounces@lists.ietf.org Tue Jul 19 10:03:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dusgq-0002ke-IK; Tue, 19 Jul 2005 10:03:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DusRS-0005SI-1d for pce@megatron.ietf.org; Tue, 19 Jul 2005 09:47:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14315 for ; Tue, 19 Jul 2005 09:47:24 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dusv1-0007jM-U4 for pce@ietf.org; Tue, 19 Jul 2005 10:18:04 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 19 Jul 2005 09:47:12 -0400 X-IronPort-AV: i="3.93,299,1115006400"; d="scan'208,217"; a="62999096:sNHT63926396" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j6JDlCk6018189; Tue, 19 Jul 2005 09:47:12 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 19 Jul 2005 09:47:12 -0400 Received: from [192.168.1.100] ([10.86.242.2]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 19 Jul 2005 09:47:09 -0400 In-Reply-To: <313680C9A886D511A06000204840E1CF0C885D02@whq-msgusr-02.pit.comms.marconi.com> References: <313680C9A886D511A06000204840E1CF0C885D02@whq-msgusr-02.pit.comms.marconi.com> Mime-Version: 1.0 (Apple Message framework v730) Message-Id: <3915FA68-6E86-4858-8118-84B2FAF7B76D@cisco.com> From: JP Vasseur Subject: Re: [Pce] Requirement for less-constrained path indraft-ietf-pce- comm-protocol-gen-reqs-00.txt Date: Tue, 19 Jul 2005 09:47:25 -0400 To: "Gray, Eric" X-Mailer: Apple Mail (2.730) X-OriginalArrivalTime: 19 Jul 2005 13:47:09.0130 (UTC) FILETIME=[5B9B02A0:01C58C68] X-Spam-Score: 2.2 (++) X-Scan-Signature: 39129b0eaa27307d3f956bfe9de757e2 X-Mailman-Approved-At: Tue, 19 Jul 2005 10:03:18 -0400 Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0928901708==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org --===============0928901708== Content-Type: multipart/alternative; boundary=Apple-Mail-38--407758996 --Apple-Mail-38--407758996 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Hi Eric, On Jul 18, 2005, at 3:57 PM, Gray, Eric wrote: > JP, > > From your earlier response, I see that you're aiming > at the "greater of two evil" solutions. Tch, tch, tch!! > > Please see below... > > --> -----Original Message----- > --> From: JP Vasseur [mailto:jvasseur@cisco.com] > --> Sent: Thursday, July 14, 2005 9:19 PM > --> To: Adrian Farrel > --> Cc: Gray, Eric; pce@ietf.org > --> Subject: Re: [Pce] Requirement for less-constrained path > --> indraft-ietf-pce-comm-protocol-gen-reqs-00.txt > --> > --> > --> > --> On Jul 14, 2005, at 12:26 PM, Adrian Farrel wrote: > --> > --> > I want to pitch in on this thread because I think (I) see > --> > where both JP and Eric are coming from. JP's proposals have > --> > the potential to significantly reduce the PCE processing > --> > and cut down number of PCC-PCE transactions, but they also > --> > have the ability to massively increase the processing and > --> > the size of the PCC-PCE transactions. > --> > > --> > --> that said, it it pretty straightforward to see that the benefits > --> undoubtedly outweigh the drawbacks. The request processing is > --> definitely negligible compared to the communication overhead. > > This is the point of obvious disagreement. > Good so at least we agree on the disagreement ;-) > --> Actually, it could be shown that the non support of such > capability > --> would have a drastic scalability impact on the solution especially > --> upon resource contention. > > Only if you assume that communication is the bottleneck. Just try to decompose the various steps occurring during a path computation (request/reply) especially when the constraints cannot be fully satisfied: 1) Path computation request sent to the PCE 2) PCE processing which includes: - queueing delay (PCE scheduler) - service time (PCE scheduler) 3) Path computation reply sent to the PCE. Then repeat such cycle until a path is successfully computed. Now consider the two cases where: A- The PCC has to send multiple requests trying to guess the set of constraints that could lead to a successful path computation. B- The PCC specifies a set of rules and the PCE tries to find a path by means of a single request A few important facts: - In case of A, when the constraint is not a boolean (e.g. bandwidth), it is really a guess and even an approach based on dichotomy would unavoidably lead to a non negligible number of cycles. - Some path computation algorithms have the capability to relax constraints "on the fly" thus saving CPU cycles compared to serialized path computations. - Without entering into some gory details about network analysis, queueing systems and implementation-specific algorithms, try to decompose the steps 1), 2) and 3), and you'll easily identify where the bottlenecks are when comparing the two approaches (especially 2). - The set of rules does not have to be complex (see an example below) and more importantly does not have to be used when inappropriate > Reality is that messaging only becomes a bottleneck if > message processing is excessively complex and/or it is > done in a poorly thought out way. If the communication > issue is not with messaging, then what is it? > I'm of course not suggesting to design poorly thought out and excessively complex messaging ;-) > --> > --> > Thus we need to be quite careful in the specification of the > --> > protocol requirements and the protocol itself. It is not OK > --> > for us to say that if an individual PCC is irresponsible or > --> > stupid that is its problem, because such an implementation > --> > would break the accessibility to the PCE for other 'normal' > --> > PCCs. > --> > > --> > --> On this aspect, I do agree ! > --> > --> > Unless there are "standard" constraint back-off functions > --> > it is hard to conceive of a PCE guessing the correct back- > --> > off for the PCC that issued the request. Note that the more > --> > "speculative paths" the PCE computes the more CPU it uses. > --> > --> Speculative paths is definitely not an option considering the > --> number of permutations ... we would unavoidably quickly fall > --> into some NP-Complete issues ;-) ... This is why the suggestion > --> is made to start some discussion on the hierarchical relaxation > --> policy. Note that it does not have to be awfully complex ... > > Here we have many things said in few words. I know, because I can > identify numerous points for both agreement and disagreement. :-) > > The issue with permutations (and NP-complete issues) is one part > on which I think we agree. > > The notion that a hierarchical relaxation approach avoids this is > one part on which I think we disagree. > > Finally, the "wish" that it does not have to be complex is quite > interesting. The only way that it will not be complex, is if the > actual decision making process is very simple in every case. The > point of contention is the fact that - while it probably can be > very simple in most cases - it will almost certainly not be 1) the > same in every case and 2) good enough in every case. > Ah here I fully agree with you (last paragraph ;-)). The goal may not be to design a solution that will address *all* cases and that will be good in *all* cases. As a system designer, I'd be very happy if the proposed solution solves the vast majority of the issues in an simple way. When not appropriate, just do not use it. Vendor implementations should be able to be flexible enough so that the operator could choose when to use such approach. See other similar examples with hierarchical BGP policy rules, ACLs, ... > If a different hierarchical relaxation policy might apply under > different circumstances, then the complexity of the protocol is > going to be greater than the combination of all "simple cases". > > If the approach is not "good enough", then a PCC is forced to > fall back on the multiple messages approach. Net gain: ~zero. > Indeed, we agree on the fact that we could make it awfully complex and consequently not practically usable. I could also come up with many such examples ... Conversely, one could easily come up with *real*life*use*of*TE*scenario where such approach would be quite useful. *Again*, think of how Service Providers use TE today ... Let me give you a simple example here (which by the way would cover a good % of current needs): Packet LSPs, Two constraints: affinity=RED and bandwidth=10 The set of constraints cannot be fully satisfied because of resource contention. Case A: The PCC sends multiple requests until a path can be found. Case B: The PCC sends one request (affinity=RED, bandwidth=10) and specifies to first relax the affinity, then find the closest bandwidth match. Note that a different policy may be adopted different LSP types. With such a simple example, you can easily see the benefit of B- -> Reduced PCE processing (delay and service time) -> Cut-down the number of transactions -> Simple constraint relaxation rule => consequently reduced path computation delay Again, I'm not claiming that all problems could be solved this way and that an operator should/could always use such hierarchical constraints approach but there are many circumstances whereby such approach would be IMO highly valuable. Of course, I'll wait for service providers to confirm that statement. > --> > --> > So we must keep good control on this. It is a > --> > computational myth that it is possible to relax different > --> > constraints on a > --> > single computational pass. > --> > --> Ah no ... there are several constraints for which > --> constraint can be relaxed and closest match can be > --> found in on-go. > --> > --> That said, even if it were not the case, the solution > --> would still be valuable to cut-down the communication > --> overhead and amount of processing signaling be the > --> PCE's scheduler. > --> > --> > In fact, the question "where did my computation fail" > --> > is notoriously impossible to answer except with the > --> > response "in the network". > --> > > --> > Thus we should give full control to the PCC, and let > --> > the PCE choose to supply less information if it thinks > --> > that the PCC is asking too much. This control includes: > --> > > --> > a. The ability to say "this or nothing" > --> > b. The ability to say "tell me what constraints I > --> > might relax to get a path" > --> > c. The ability to say "give me n alternate paths with > --> > with your choice of relaxed constraints" (c. is > --> > like b but with the paths supplied, and it is > --> > important to control the number) > --> > d. A way to state which constraints may be relaxed > --> > absolutely (this is easy) > --> > e. A way to replace one constraint supplied by the > --> > PCC with another also supplied by the PCC > --> > f. A way to specify an ordering for relaxation in > --> > recomputation attempts. > --> > > --> > My feeling is that e might be satisfied in the protocol > --> > simply by listing the same object multiple times. But f > --> > is very messy. As soon as I have a few constraints and > --> > I am willing to relax each of them by degrees I have a > --> > very complex relaxation problem to express. > --> > --> Well not so sure ... Let's wait for the meeting in Paris to > --> have an open discussion. I'd be happy to provide some ideas. > --> Actually one could point out that such constraint relaxation > --> are used TODAY in operational networks (with CSPF). > > One could point that out, if one wants to show that having > a PCC make separate requests is the right way to go. I was > under the impression you were arguing the opposition point > of view. > > In the CSPF case you identify, the Traffic Engineer is both > a PCC and a PCE and - with respect to the relaxation mode, > it is much more likely to act like a PCC than a PCE. In other > words, given a requirement for TE tunnel routing, it will > most likely complete a computation based on a single set of > constraints and - if that fails - it may elect to relax the > path requirements and try again with different constraints. > But this is the whole point. When the PCE is co-located this can be done without introducing substantial delays ... Conversely, think of a PCE receiving a burst of requests from tens of PCCs after a network failure ... this is precisely one of the aspects that I want to optimize. > This is essentially PCC behavior. Pushing this behavior into > the PCE saves on external messaging overhead, but at a huge > cost in complexity. Now, instead of having a self-contained > entity (the PCC) deciding how next to proceed in getting a > Path (should any attempt fail), it must communicate a decision > making process to a delegate (the PCE) for every Path request > - irrespective of whether or not that Path Request would fail. > > Unless the decision making options are very limited, this must > impose a higher level of processing on the PCE just to decode, > store and - eventually - act on the decision making process. > > I doubt that the communication overhead is the bottle-neck for > PCE-PCC transactions, or the network over which they transpire. > I also strongly suspect that deployments will tend toward more > PCCs than PCEs, so - assuming that (for example) there are ten > times as many PCCs as PCEs - what is the advantage gained by > pushing the work of 1,000 PCCs onto 100 PCEs, no no ... we do not push the work of 1,000 PCCs onto 100 PCEs ... by supporting such constraint relaxation approach you drastically reduce the processing load on PCEs. Jumping to the end of this email (considering the text provided above). > especially if you > assume that most path requests will be satisfied prior to a PCC > traversal of the decision tree. > > --> > --> > > --> > This is a problem that it is very easy for the PCC to > --> > handle by issuing successive requests, but very hard for > --> > the PCC to communicate to the PCE in a single request. > --> > --> I do not think that it is hard for the PCC to communicate > --> to the PCE in a single request. > > You miss the point. > > If "communication" was easy, you wouldn't have started this > discussion, and I wouldn't be continuing it. :-) > > Let's say that PCC X follows this scheme for one subset of its > requests: > > scheme (a) > Request a path with constraints A, B and C. > On failure for A, request a path with constraint A1 that > still satisfies B and C. > On failure for A1, B or C, fail. > > To cut down on communication overhead, we could communicate > this decision making policy to the PCE and make a single > request that either succeeds or fails according to this policy. > > But this PCC (or another) also has a decision making schemes as > follows for other types of services: > > scheme (b) > Request a path with constraint A, C and D. > On failure for C, request a path with constraints A and D > only > On failure for A or D, fail. > > scheme (c) > Request a path with constraints B, C and D. > On failure (for B, C or D) request an unconstrained shortest > path. > > ... and so on ... > > Hence, given any arbitrary number of potential constraints, the > number of possible decision making policies we need to define > is clearly combinatorial (i.e. - NP) in the number of possible > constraints (and possible relaxations of each). > > However, if we do not cover all of the possibilities, then we > constrain the services that our customers can sell, their ability > to differentiate themselves from their competitors and even the > service pricing structures that are available to their customers > in turn. > > To eliminate this concern, all we need to do is define a language > for describing a decision making process. Done much work in the > area of defining languages like this? :-) > > --> > --> > > --> > So, I'd like to see some text from SPs on this subject > --> > before we add anything to the requirements I-D. > --> > > --> > --> I think that the DT is working on it. > > So, this is confusing. Are you saying that it's out of the hands > of the WG because the authors are taking this work on anyway? > /Chair Hat/ I just meant that the DT was working on the new revision of draft- ietf-pce-comm-protocol-gen-reqs with the intention to cover that aspect for WG input (this new rev has now been published). As you know, by definition, a Working Group document is owned by the Working Group. Your comments are of course more than welcome. /Chair hat removed/ We may just want to sit down in Paris and discuss more on this if you will. JP. > --> > --> Cheers, > --> > --> JP. > --> > --> > Cheers, > --> > Adrian > --> > > --> > --- [SNIP] --- > --Apple-Mail-38--407758996 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Eric,

On = Jul 18, 2005, at 3:57 PM, Gray, Eric wrote:

JP,

=A0 = =A0 =46rom your earlier response, I see that you're = aiming=A0
at the "greater of two evil" solutions.=A0 Tch, tch, tch!!

=A0 = =A0 Please see below...

--> = -----Original Message-----
--> From: = JP Vasseur [mailto:jvasseur@cisco.com]
--> Sent: Thursday, July 14, 2005 9:19 = PM
--> To: Adrian Farrel
--> Cc: Gray, Eric; pce@ietf.org
--> Subject: Re: [Pce] Requirement for = less-constrained path
--> = indraft-ietf-pce-comm-protocol-gen-reqs-00.txt
-->=A0
=A0
-->=A0
--> = On Jul 14, 2005, at 12:26 PM, Adrian Farrel wrote:
-->=A0
--> = > I want to pitch in on this thread because I think (I) see=A0
--> = > where both JP and Eric are coming from. JP's proposals = have
--> > the potential to = significantly reduce the PCE processing=A0
--> = > and cut down number of PCC-PCE transactions, but they = also
--> > have the ability to = massively increase the processing and =A0
--> = > the size of the PCC-PCE transactions.
--> = >
-->=A0
--> = that said, it it pretty straightforward to see that the benefits =A0
--> = undoubtedly outweigh the drawbacks. The request processing is =A0
--> = definitely negligible compared to the communication overhead.

This is = the point of obvious disagreement.


Good so at least we agree = on the disagreement ;-)

--> = Actually, it could be shown that the non support of such capability = =A0
--> would have a drastic scalability impact on = the solution especially =A0
--> = upon resource contention.

Only if you assume that = communication is the bottleneck.

Just try to decompose the = various steps=A0occurring during a path computation (request/reply) = especially when the constraints cannot be fully satisfied:
1) = Path computation request sent to the PCE
2) PCE processing = which includes:
=A0=A0=A0 - queueing delay (PCE = scheduler)
=A0=A0=A0 - service time (PCE = scheduler)
3) Path computation reply sent to the = PCE.

Then= repeat such cycle until a path is=A0successfully = computed.

Now = consider the two cases where:
A- The PCC has to send multiple = requests trying to guess the set of constraints that could lead to a = successful path computation.
B- The PCC specifies a set of = rules and the PCE tries to find a path by means of a single = request

A few = important facts:

- In case of A, when the = constraint is not a boolean (e.g. bandwidth), it is really a guess and = even an approach based on=A0dichotomy=A0would unavoidably lead to a non = negligible number of cycles.=A0
- Some path computation = algorithms have the capability to relax constraints "on the fly" thus = saving CPU cycles compared to serialized path computations.=A0
-= Without entering into some gory details about network analysis, = queueing systems and implementation-specific algorithms, try to = decompose the steps 1), 2) and 3), and you'll easily identify where the = bottlenecks are when comparing the two approaches (especially = 2).
- The set of rules does = not have to be complex (see an example below) and more importantly = does not have to be used when inappropriate

Reality is that messaging only becomes a bottleneck = if
message processing is excessively complex = and/or it is=A0
done in a poorly thought out way. If the = communication
issue is not with messaging, = then what is it?
I'm of course not = suggesting to design poorly thought out and excessively complex = messaging ;-)

-->=A0
--> = > Thus we need to be quite careful in the specification of = the
--> > protocol = requirements and the protocol itself. It is not OK
--> > for us to say that if an individual PCC = is irresponsible or=A0
--> = > stupid that is its problem, because such an = implementation
--> > would break the = accessibility to the PCE for other 'normal'=A0
--> = > PCCs.
--> >
-->=A0
--> = On this aspect, I do agree !
-->=A0
--> = > Unless there are "standard" constraint back-off functions=A0
--> = > it is hard to conceive of a PCE guessing the correct = back-
--> > off for the PCC that = issued the request. Note that the more=A0
--> = > "speculative paths" the PCE computes the more CPU it = uses.
-->=A0
--> = Speculative paths is definitely not an option considering the=A0
--> = number of permutations ... we would unavoidably quickly fall
--> into some NP-Complete issues ;-) ... This is = why the suggestion=A0
--> is made to start some discussion on the = hierarchical relaxation=A0
--> = policy. Note that it does not have to be awfully complex ...

Here we = have many things said in few words. I know, because I can
identify numerous points for both agreement and = disagreement.=A0 = :-)

The issue with permutations (and NP-complete issues) = is one part
on which I think we = agree.

The notion that a hierarchical relaxation approach = avoids this is
one part on which I think we = disagree.

Finally, the "wish" that it does not have to be = complex is quite
interesting.=A0 The only way that it will not = be complex, is if the
actual decision making = process is very simple in every case. The
point of = contention is the fact that - while it probably can be=A0
very = simple in most cases - it will almost certainly not be 1) the
same in every case and 2) good enough in every = case.
Ah here I fully agree with = you (last paragraph ;-)). The goal may not be to design a solution that = will address *all* cases and that will be good in *all* cases.=A0
As = a system designer, I'd be very happy if the proposed solution solves = the vast majority of the issues in an simple way. When not = appropriate, just do not use it. Vendor implementations should be able = to be flexible enough so that the operator could choose when to use such = approach. See other similar examples with hierarchical BGP policy rules, = ACLs, ...=A0

If a = different hierarchical relaxation policy might apply under
different circumstances, then the complexity of the = protocol is
going to be greater than the = combination of all "simple cases".

If the approach is not "good = enough", then a PCC is forced to
fall back on = the multiple messages approach.=A0 = Net gain: ~zero.


Indeed, we agree on the = fact that we could make it=A0awfully complex and=A0consequently not = practically usable. I could also come up with many such examples ... = Conversely, one could easily come up with *real*life*use*of*TE*scenario = where such approach would be quite useful. *Again*, think of how Service = Providers use TE today ... Let me give you a simple example here (which = by the way would cover a good % of current needs):

Packet LSPs,
Two = constraints:=A0affinity=3DRED and bandwidth=3D10
The set of = constraints cannot be fully satisfied because of resource = contention.

Case A: The PCC sends = multiple requests until a path can be found.
Case B: The PCC = sends one request (affinity=3DRED, bandwidth=3D10) and specifies to = first relax the affinity, then find the closest=A0bandwidth match. Note = that a different policy may be adopted different LSP = types.

With=A0such a simple = example, you can easily see the benefit of B-
-> Reduced = PCE processing (delay and service time)
-> Cut-down the = number of transactions
-> Simple constraint relaxation = rule

=3D>=A0consequently = reduced path computation delay

Again, I'm not claiming = that all problems could be solved this way and that an operator = should/could always use such=A0hierarchical constraints approach but = there are many circumstances whereby such approach would be IMO highly = valuable.

Of = course, I'll wait for service providers to confirm that = statement.

-->=A0
--> = > So we must keep good control on this. It is a
--> > computational myth that it is possible = to relax different =A0
--> = > constraints on a
--> > single = computational pass.
-->=A0
--> = Ah no ... there are several constraints for which=A0
--> = constraint can be relaxed and closest match can be=A0
--> = found in on-go.
-->=A0
--> = That said, even if it were not the case, the solution=A0
--> = would still be valuable to cut-down the communication=A0
--> = overhead and amount of processing signaling be the=A0
--> = PCE's scheduler.
-->=A0
--> = > In fact, the question "where did my computation fail"
--> > is notoriously impossible to answer = except with the=A0 = =A0
--> > response "in the = network".
--> >
--> > Thus we should give full control to the = PCC, and let=A0
--> > the PCE choose to supply less = information if it thinks=A0 = =A0
--> > that the PCC is = asking too much. This control includes:
--> = >
--> > a. The ability to = say "this or nothing"
--> > b. The ability = to say "tell me what constraints I
--> = >=A0 =A0 might relax to = get a path"
--> > c. The ability to = say "give me n alternate paths with=A0
--> = >=A0 =A0 with your = choice of relaxed constraints" (c. is=A0
--> = >=A0 =A0 like b but with = the paths supplied, and it is=A0
--> = >=A0 =A0 important to = control the number)
--> > d. A way to = state which constraints may be relaxed=A0
--> = >=A0 =A0 absolutely = (this is easy)
--> > e. A way to replace = one constraint supplied by the =A0
--> = >=A0 =A0 PCC with = another also supplied by the PCC
--> > = f. A way to specify an ordering for relaxation in=A0
--> = >=A0 =A0 recomputation = attempts.
--> >
--> > My feeling is that e might be satisfied = in the protocol =A0
--> > simply by listing the same object = multiple times. But f
--> > is very messy. = As soon as I have a few constraints and=A0
--> = > I am willing to relax each of them by degrees I have a
--> > very complex relaxation problem to = express.
-->=A0
--> = Well not so sure ... Let's wait for the meeting in Paris to=A0
--> = have an open discussion. I'd be happy to provide some ideas.
--> Actually one could point out that such = constraint relaxation=A0
--> = are used TODAY in operational networks (with CSPF).

One = could point that out, if one wants to show that having=A0
a PCC = make separate requests is the right way to go. I was
under the impression you were arguing the opposition = point
of view.

In the = CSPF case you identify, the Traffic Engineer is both
a PCC and a PCE and - with respect to the relaxation = mode,
it is much more likely to act = like a PCC than a PCE. In other
words, given = a requirement for TE tunnel routing, it will=A0
most = likely complete a computation based on a single set of
constraints and - if that fails - it may elect to = relax the
path requirements and try again = with different constraints.


But this is the whole = point. When the PCE is co-located this can be done without introducing = substantial delays ... Conversely, think of a PCE receiving a burst of = requests from tens of PCCs after a network failure ... this is precisely = one of the aspects that I want to optimize.

This is essentially PCC behavior. Pushing this = behavior into
the PCE saves on external = messaging overhead, but at a huge
cost in = complexity.=A0 Now, instead = of having a self-contained
entity (the = PCC) deciding how next to proceed in getting a=A0
Path = (should any attempt fail), it must communicate a decision=A0
making = process to a delegate (the PCE) for every Path request
- irrespective of whether or not that Path Request = would fail.

Unless the decision making options are very limited, = this must
impose a higher level of = processing on the PCE just to decode,
store = and - eventually - act on the decision making process.

I doubt = that the communication overhead is the bottle-neck for
PCE-PCC transactions, or the network over which they = transpire.
I also strongly suspect that = deployments will tend toward more
PCCs than = PCEs, so - assuming that (for example) there are ten
times as many PCCs as PCEs - what is the advantage = gained by
pushing the work of 1,000 PCCs = onto 100 PCEs,

no no ... we do not push = the work of 1,000 PCCs onto 100 PCEs ... by supporting such constraint = relaxation approach you drastically reduce the processing load on = PCEs.

Jumping = to the end of this email (considering the text provided = above).

=A0
assume = that most path requests will be satisfied prior to a PCC=A0

-->=A0
--> = >
--> > This is a problem = that it is very easy for the PCC to =A0
--> = > handle by issuing successive requests, but very hard for=A0
--> = > the PCC to communicate to the PCE in a single request.
-->=A0
--> I = do not think that it is hard for the PCC to communicate=A0
--> = to the PCE in a single request.

You miss the point.

If = "communication" was easy, you wouldn't have started this
discussion, and I wouldn't be continuing it.=A0 :-)

Let's = say that PCC X follows this scheme for one subset of its
requests:

scheme (a)
=A0 =A0 Request a path with = constraints A, B and C.
=A0 = =A0 On failure for A, request a path with constraint A1 = that
=A0 = =A0 =A0 =A0 still satisfies B and C.
=A0 =A0 On failure for A1, B = or C, fail.

To cut down on communication overhead, we could = communicate
this decision making policy to = the PCE and make a single
request that = either succeeds or fails according to this policy.

But this = PCC (or another) also has a decision making schemes as
follows for other types of services:

scheme = (b)
=A0 = =A0 Request a path with constraint A, C and D.
=A0 =A0 On failure for C, = request a path with constraints A and D
=A0 = =A0 =A0 =A0 only
=A0 = =A0 On failure for A or D, fail.

scheme = (c)
=A0 = =A0 Request a path with constraints B, C and D.
=A0 =A0 On failure (for B, C = or D) request an unconstrained shortest
=A0 = =A0 =A0 =A0 path.

... and so on ...

Hence, = given any arbitrary number of potential constraints, the
number of possible decision making policies we need = to define
is clearly combinatorial (i.e. - = NP) in the number of possible
constraints = (and possible relaxations of each).

However, if we do not cover all = of the possibilities, then we
constrain the = services that our customers can sell, their ability
to differentiate themselves from their competitors = and even the
service pricing structures that = are available to their customers
in = turn.

To eliminate this concern, all we need to do is = define a language
for describing a decision making = process.=A0 Done much work = in the
area of defining languages like = this?=A0 :-)

=A0
--> >
--> > = So, I'd like to see some text from SPs on this subject=A0
--> = > before we add anything to the requirements I-D.
--> >
-->=A0
--> I = think that the DT is working on it.

So, this is confusing. Are you = saying that it's out of the hands
of the WG = because the authors are taking this work on anyway?


/Chair Hat/

I just meant that the DT = was working on the new revision of draft-ietf-pce-comm-protocol-gen-reqs = with the intention to cover that aspect for WG input (this new rev has = now been published). As you know, by definition, a Working Group = document is owned by the Working Group.=A0

Your comments are of course = more than welcome.=A0

/Chair hat = removed/

We = may just want to sit down in Paris and discuss more on this if you = will.

JP.

-->=A0
--> = Cheers,
-->=A0
--> = JP.
-->=A0
--> = > Cheers,
--> > Adrian
--> >
--> > = --- [SNIP] ---


= --Apple-Mail-38--407758996-- --===============0928901708== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============0928901708==-- From pce-bounces@lists.ietf.org Tue Jul 19 11:44:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuuGH-0003zI-DO; Tue, 19 Jul 2005 11:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuuDv-0002Cn-92 for pce@megatron.ietf.org; Tue, 19 Jul 2005 11:41:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07905 for ; Tue, 19 Jul 2005 11:41:32 -0400 (EDT) Received: from webmail.movaz.com ([65.205.166.188] helo=jera.movaz.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DuuhX-0000MY-0F for pce@ietf.org; Tue, 19 Jul 2005 12:12:14 -0400 Received: from ib (unknown [172.16.24.122]) by jera.movaz.com (Postfix) with SMTP id 00D8E56D7; Tue, 19 Jul 2005 11:41:21 -0400 (EDT) Message-ID: <003401c58c78$4f9583d0$7a1810ac@movaz.com> From: "Igor Bryskin" To: "JP Vasseur" , "Gray, Eric" References: <313680C9A886D511A06000204840E1CF0C885D02@whq-msgusr-02.pit.comms.marconi.com> <3915FA68-6E86-4858-8118-84B2FAF7B76D@cisco.com> Subject: Re: [Pce] Requirement for less-constrained path indraft-ietf-pce-comm-protocol-gen-reqs-00.txt Date: Tue, 19 Jul 2005 11:41:20 -0400 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 2.8 (++) X-Scan-Signature: 16c0baa8a8bdaaf551d782158807dcb1 X-Mailman-Approved-At: Tue, 19 Jul 2005 11:44:00 -0400 Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0011241390==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0011241390== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0031_01C58C56.C855F600" This is a multi-part message in MIME format. ------=_NextPart_000_0031_01C58C56.C855F600 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable JP. As I have indicated earlier I don't believe that the complexity = associated with signaling of constraint relaxation strategy justifies = the results. Most of the constraints are non-boolean, and it is = difficult IMO to provide a simple yet flexible way for a PCC to = articulate the desired way of relaxation wrt each of the constraints. = And what if the constraints are not independent? For instance, what if a = PCC wants to get best tradeoff of several constraints ?=20 My suggestion is to start with allowing for PCC to specify in a single = request a set of mandatory constraints and an ordered list of sets of = relaxable constraints: first, use the first set in the list (+ = mandatory, of course), if path computation fails - use the second one = and so forth. This is a much simpler way of doing the constraint = relaxation and could be just good enough, although it makes the size of = requests and response larger. By the way, do you remember that sometime ago I suggested to design the = PCC-PCE protocol in a such a way where each request/response is a BASIC = style program that could be interpreted by both PCC and PCE? The = intention was to provide a very flexible way for a PCE to describe its = capabilities and introduce new ones, and for PCC to take the most of the = PCE and specify what exactly it wants from the requested path = computation (what constraints and optimization criterias to be used and = how)=20 It would be very easy to support the constraint relaxation strategies no = matter how complex they are :=3D) Cheers, Igor ----- Original Message -----=20 From: JP Vasseur=20 To: Gray, Eric=20 Cc: pce@ietf.org=20 Sent: Tuesday, July 19, 2005 9:47 AM Subject: Re: [Pce] Requirement for less-constrained path = indraft-ietf-pce-comm-protocol-gen-reqs-00.txt Hi Eric, On Jul 18, 2005, at 3:57 PM, Gray, Eric wrote: JP, From your earlier response, I see that you're aiming=20 at the "greater of two evil" solutions. Tch, tch, tch!! Please see below... --> -----Original Message----- --> From: JP Vasseur [mailto:jvasseur@cisco.com] --> Sent: Thursday, July 14, 2005 9:19 PM --> To: Adrian Farrel --> Cc: Gray, Eric; pce@ietf.org --> Subject: Re: [Pce] Requirement for less-constrained path --> indraft-ietf-pce-comm-protocol-gen-reqs-00.txt -->=20 -->=20 -->=20 --> On Jul 14, 2005, at 12:26 PM, Adrian Farrel wrote: -->=20 --> > I want to pitch in on this thread because I think (I) see=20 --> > where both JP and Eric are coming from. JP's proposals have --> > the potential to significantly reduce the PCE processing=20 --> > and cut down number of PCC-PCE transactions, but they also --> > have the ability to massively increase the processing and =20 --> > the size of the PCC-PCE transactions. --> > -->=20 --> that said, it it pretty straightforward to see that the benefits = =20 --> undoubtedly outweigh the drawbacks. The request processing is =20 --> definitely negligible compared to the communication overhead. This is the point of obvious disagreement. Good so at least we agree on the disagreement ;-) --> Actually, it could be shown that the non support of such = capability =20 --> would have a drastic scalability impact on the solution = especially =20 --> upon resource contention. Only if you assume that communication is the bottleneck. Just try to decompose the various steps occurring during a path = computation (request/reply) especially when the constraints cannot be = fully satisfied: 1) Path computation request sent to the PCE 2) PCE processing which includes: - queueing delay (PCE scheduler) - service time (PCE scheduler) 3) Path computation reply sent to the PCE. Then repeat such cycle until a path is successfully computed. Now consider the two cases where: A- The PCC has to send multiple requests trying to guess the set of = constraints that could lead to a successful path computation. B- The PCC specifies a set of rules and the PCE tries to find a path = by means of a single request A few important facts: - In case of A, when the constraint is not a boolean (e.g. bandwidth), = it is really a guess and even an approach based on dichotomy would = unavoidably lead to a non negligible number of cycles.=20 - Some path computation algorithms have the capability to relax = constraints "on the fly" thus saving CPU cycles compared to serialized = path computations.=20 - Without entering into some gory details about network analysis, = queueing systems and implementation-specific algorithms, try to = decompose the steps 1), 2) and 3), and you'll easily identify where the = bottlenecks are when comparing the two approaches (especially 2). - The set of rules does not have to be complex (see an example below) = and more importantly does not have to be used when inappropriate Reality is that messaging only becomes a bottleneck if message processing is excessively complex and/or it is=20 done in a poorly thought out way. If the communication issue is not with messaging, then what is it? I'm of course not suggesting to design poorly thought out and = excessively complex messaging ;-) -->=20 --> > Thus we need to be quite careful in the specification of the --> > protocol requirements and the protocol itself. It is not OK --> > for us to say that if an individual PCC is irresponsible or=20 --> > stupid that is its problem, because such an implementation --> > would break the accessibility to the PCE for other 'normal'=20 --> > PCCs. --> > -->=20 --> On this aspect, I do agree ! -->=20 --> > Unless there are "standard" constraint back-off functions=20 --> > it is hard to conceive of a PCE guessing the correct back- --> > off for the PCC that issued the request. Note that the more=20 --> > "speculative paths" the PCE computes the more CPU it uses. -->=20 --> Speculative paths is definitely not an option considering the=20 --> number of permutations ... we would unavoidably quickly fall --> into some NP-Complete issues ;-) ... This is why the suggestion=20 --> is made to start some discussion on the hierarchical relaxation=20 --> policy. Note that it does not have to be awfully complex ... Here we have many things said in few words. I know, because I can identify numerous points for both agreement and disagreement. :-) The issue with permutations (and NP-complete issues) is one part on which I think we agree. The notion that a hierarchical relaxation approach avoids this is one part on which I think we disagree. Finally, the "wish" that it does not have to be complex is quite interesting. The only way that it will not be complex, is if the actual decision making process is very simple in every case. The point of contention is the fact that - while it probably can be=20 very simple in most cases - it will almost certainly not be 1) the same in every case and 2) good enough in every case. Ah here I fully agree with you (last paragraph ;-)). The goal may not = be to design a solution that will address *all* cases and that will be = good in *all* cases.=20 As a system designer, I'd be very happy if the proposed solution = solves the vast majority of the issues in an simple way. When not = appropriate, just do not use it. Vendor implementations should be able = to be flexible enough so that the operator could choose when to use such = approach. See other similar examples with hierarchical BGP policy rules, = ACLs, ...=20 If a different hierarchical relaxation policy might apply under different circumstances, then the complexity of the protocol is going to be greater than the combination of all "simple cases". If the approach is not "good enough", then a PCC is forced to fall back on the multiple messages approach. Net gain: ~zero. Indeed, we agree on the fact that we could make it awfully complex and = consequently not practically usable. I could also come up with many such = examples ... Conversely, one could easily come up with = *real*life*use*of*TE*scenario where such approach would be quite useful. = *Again*, think of how Service Providers use TE today ... Let me give you = a simple example here (which by the way would cover a good % of current = needs): Packet LSPs, Two constraints: affinity=3DRED and bandwidth=3D10 The set of constraints cannot be fully satisfied because of resource = contention. Case A: The PCC sends multiple requests until a path can be found. Case B: The PCC sends one request (affinity=3DRED, bandwidth=3D10) and = specifies to first relax the affinity, then find the closest bandwidth = match. Note that a different policy may be adopted different LSP types. With such a simple example, you can easily see the benefit of B- -> Reduced PCE processing (delay and service time) -> Cut-down the number of transactions -> Simple constraint relaxation rule =3D> consequently reduced path computation delay Again, I'm not claiming that all problems could be solved this way and = that an operator should/could always use such hierarchical constraints = approach but there are many circumstances whereby such approach would be = IMO highly valuable. Of course, I'll wait for service providers to confirm that statement. -->=20 --> > So we must keep good control on this. It is a --> > computational myth that it is possible to relax different =20 --> > constraints on a --> > single computational pass. -->=20 --> Ah no ... there are several constraints for which=20 --> constraint can be relaxed and closest match can be=20 --> found in on-go. -->=20 --> That said, even if it were not the case, the solution=20 --> would still be valuable to cut-down the communication=20 --> overhead and amount of processing signaling be the=20 --> PCE's scheduler. -->=20 --> > In fact, the question "where did my computation fail" --> > is notoriously impossible to answer except with the =20 --> > response "in the network". --> > --> > Thus we should give full control to the PCC, and let=20 --> > the PCE choose to supply less information if it thinks =20 --> > that the PCC is asking too much. This control includes: --> > --> > a. The ability to say "this or nothing" --> > b. The ability to say "tell me what constraints I --> > might relax to get a path" --> > c. The ability to say "give me n alternate paths with=20 --> > with your choice of relaxed constraints" (c. is=20 --> > like b but with the paths supplied, and it is=20 --> > important to control the number) --> > d. A way to state which constraints may be relaxed=20 --> > absolutely (this is easy) --> > e. A way to replace one constraint supplied by the =20 --> > PCC with another also supplied by the PCC --> > f. A way to specify an ordering for relaxation in=20 --> > recomputation attempts. --> > --> > My feeling is that e might be satisfied in the protocol =20 --> > simply by listing the same object multiple times. But f --> > is very messy. As soon as I have a few constraints and=20 --> > I am willing to relax each of them by degrees I have a --> > very complex relaxation problem to express. -->=20 --> Well not so sure ... Let's wait for the meeting in Paris to=20 --> have an open discussion. I'd be happy to provide some ideas. --> Actually one could point out that such constraint relaxation=20 --> are used TODAY in operational networks (with CSPF). One could point that out, if one wants to show that having=20 a PCC make separate requests is the right way to go. I was under the impression you were arguing the opposition point of view. In the CSPF case you identify, the Traffic Engineer is both a PCC and a PCE and - with respect to the relaxation mode, it is much more likely to act like a PCC than a PCE. In other words, given a requirement for TE tunnel routing, it will=20 most likely complete a computation based on a single set of constraints and - if that fails - it may elect to relax the path requirements and try again with different constraints. But this is the whole point. When the PCE is co-located this can be = done without introducing substantial delays ... Conversely, think of a = PCE receiving a burst of requests from tens of PCCs after a network = failure ... this is precisely one of the aspects that I want to = optimize. This is essentially PCC behavior. Pushing this behavior into the PCE saves on external messaging overhead, but at a huge cost in complexity. Now, instead of having a self-contained entity (the PCC) deciding how next to proceed in getting a=20 Path (should any attempt fail), it must communicate a decision=20 making process to a delegate (the PCE) for every Path request - irrespective of whether or not that Path Request would fail. Unless the decision making options are very limited, this must impose a higher level of processing on the PCE just to decode, store and - eventually - act on the decision making process. I doubt that the communication overhead is the bottle-neck for PCE-PCC transactions, or the network over which they transpire. I also strongly suspect that deployments will tend toward more PCCs than PCEs, so - assuming that (for example) there are ten times as many PCCs as PCEs - what is the advantage gained by pushing the work of 1,000 PCCs onto 100 PCEs,=20 no no ... we do not push the work of 1,000 PCCs onto 100 PCEs ... by = supporting such constraint relaxation approach you drastically reduce = the processing load on PCEs. Jumping to the end of this email (considering the text provided = above). especially if you=20 assume that most path requests will be satisfied prior to a PCC=20 traversal of the decision tree. -->=20 --> > --> > This is a problem that it is very easy for the PCC to =20 --> > handle by issuing successive requests, but very hard for=20 --> > the PCC to communicate to the PCE in a single request. -->=20 --> I do not think that it is hard for the PCC to communicate=20 --> to the PCE in a single request. You miss the point. If "communication" was easy, you wouldn't have started this discussion, and I wouldn't be continuing it. :-) Let's say that PCC X follows this scheme for one subset of its requests: scheme (a) Request a path with constraints A, B and C. On failure for A, request a path with constraint A1 that still satisfies B and C. On failure for A1, B or C, fail. To cut down on communication overhead, we could communicate this decision making policy to the PCE and make a single request that either succeeds or fails according to this policy. But this PCC (or another) also has a decision making schemes as follows for other types of services: scheme (b) Request a path with constraint A, C and D. On failure for C, request a path with constraints A and D only On failure for A or D, fail. scheme (c) Request a path with constraints B, C and D. On failure (for B, C or D) request an unconstrained shortest path. ... and so on ... Hence, given any arbitrary number of potential constraints, the number of possible decision making policies we need to define is clearly combinatorial (i.e. - NP) in the number of possible constraints (and possible relaxations of each). However, if we do not cover all of the possibilities, then we constrain the services that our customers can sell, their ability to differentiate themselves from their competitors and even the service pricing structures that are available to their customers in turn. To eliminate this concern, all we need to do is define a language for describing a decision making process. Done much work in the area of defining languages like this? :-) -->=20 --> > --> > So, I'd like to see some text from SPs on this subject=20 --> > before we add anything to the requirements I-D. --> > -->=20 --> I think that the DT is working on it. So, this is confusing. Are you saying that it's out of the hands of the WG because the authors are taking this work on anyway? /Chair Hat/ I just meant that the DT was working on the new revision of = draft-ietf-pce-comm-protocol-gen-reqs with the intention to cover that = aspect for WG input (this new rev has now been published). As you know, = by definition, a Working Group document is owned by the Working Group.=20 Your comments are of course more than welcome.=20 /Chair hat removed/ We may just want to sit down in Paris and discuss more on this if you = will. JP. -->=20 --> Cheers, -->=20 --> JP. -->=20 --> > Cheers, --> > Adrian --> > --> > --- [SNIP] --- -------------------------------------------------------------------------= ----- _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce ------=_NextPart_000_0031_01C58C56.C855F600 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
JP.
 
As I have indicated earlier I don't = believe that=20 the complexity associated with signaling of constraint relaxation = strategy=20 justifies the results. Most of the constraints are non-boolean, and it = is=20 difficult IMO to provide a simple yet flexible way for a PCC to = articulate the=20 desired way of relaxation wrt each of the constraints. And = what if the=20 constraints are not independent? For instance, what if a PCC wants = to get=20 best tradeoff of several constraints ?
 
My suggestion is to start with allowing = for PCC to=20 specify in a single request a set of mandatory constraints and an = ordered list=20 of sets of relaxable constraints: first, use the first set in the list = (+=20 mandatory, of course), if path computation fails - use the second one = and so=20 forth. This is a much simpler way of doing the = constraint relaxation and=20 could be just good enough, although it makes the size of requests = and=20 response larger.
 
By the way, do you remember that = sometime ago I=20 suggested to design the PCC-PCE protocol in a such a way where each=20 request/response is a BASIC style program that could be interpreted =  by=20 both PCC and PCE? The intention was to provide a very flexible way for a = PCE to=20 describe its capabilities and introduce new ones, and for PCC to take = the most=20 of the PCE and specify what exactly it wants from the requested = path=20 computation (what constraints and optimization criterias to be used = and=20 how)
 
It would be very easy to support = the=20 constraint relaxation strategies no matter how complex they are = :=3D)
 
Cheers,
Igor
----- Original Message -----
From:=20 JP = Vasseur=20
Sent: Tuesday, July 19, 2005 = 9:47=20 AM
Subject: Re: [Pce] Requirement = for=20 less-constrained path = indraft-ietf-pce-comm-protocol-gen-reqs-00.txt

Hi Eric,

On Jul 18, 2005, at 3:57 PM, Gray, Eric wrote:
JP,

    From your = earlier=20 response, I see that you're aiming 
at the "greater of two evil" = solutions.  Tch, tch, tch!!

    Please see=20 below...

--> -----Original Message-----
--> From: JP Vasseur [mailto:jvasseur@cisco.com]
--> Sent: Thursday, July 14, 2005 9:19 = PM
--> To: Adrian Farrel
--> Cc: Gray, Eric; pce@ietf.org
--> Subject: Re: [Pce] Requirement for = less-constrained path
-->=20 indraft-ietf-pce-comm-protocol-gen-reqs-00.txt
--> 
--> 
--> 
--> On Jul 14, 2005, at 12:26 PM, = Adrian Farrel=20 wrote:
--> 
--> > I want to pitch in on this = thread=20 because I think (I) see 
--> > where both JP and Eric are = coming from.=20 JP's proposals have
--> > the potential to = significantly reduce=20 the PCE processing 
--> > and cut down number of = PCC-PCE=20 transactions, but they also
--> > have the ability to massively = increase=20 the processing and  
--> > the size of the PCC-PCE=20 transactions.
--> >
--> 
--> that said, it it pretty = straightforward to=20 see that the benefits  
--> undoubtedly outweigh the = drawbacks. The=20 request processing is  
--> definitely negligible compared to = the=20 communication overhead.

This is the point of obvious = disagreement.


Good so at least we agree on the disagreement ;-)

--> Actually, it could be shown that = the non=20 support of such capability  
--> would have a drastic scalability = impact on=20 the solution especially  
--> upon resource contention.

Only if you assume that communication is = the=20 bottleneck.

Just try to decompose the various steps occurring during a = path=20 computation (request/reply) especially when the constraints cannot be = fully=20 satisfied:
1) Path computation request sent to the PCE
2) PCE processing which includes:
    - queueing delay (PCE scheduler)
    - service time (PCE scheduler)
3) Path computation reply sent to the PCE.

Then repeat such cycle until a path is successfully = computed.

Now consider the two cases where:
A- The PCC has to send multiple requests trying to guess the set = of=20 constraints that could lead to a successful path computation.
B- The PCC specifies a set of rules and the PCE tries to find a = path by=20 means of a single request

A few important facts:

- In case of A, when the constraint is not a boolean (e.g. = bandwidth), it=20 is really a guess and even an approach based = on dichotomy would=20 unavoidably lead to a non negligible number of cycles. 
- Some path computation algorithms have the capability to relax=20 constraints "on the fly" thus saving CPU cycles compared to serialized = path=20 computations. 
- Without entering into some gory details about network analysis, = queueing systems and implementation-specific algorithms, try to = decompose the=20 steps 1), 2) and 3), and you'll easily identify where the bottlenecks = are when=20 comparing the two approaches (especially 2).
- The set of rules does not have = to be=20 complex (see an example below) and more importantly does not have = to be=20 used when inappropriate

Reality is that messaging only becomes a = bottleneck=20 if
message processing is excessively complex = and/or it=20 is 
done in a poorly thought out way. If the=20 communication
issue is not with messaging, then what is = it?


I'm of course not suggesting to design poorly thought out and = excessively=20 complex messaging ;-)

--> 
--> > Thus we need to be quite = careful in the=20 specification of the
--> > protocol requirements and the = protocol=20 itself. It is not OK
--> > for us to say that if an = individual PCC=20 is irresponsible or 
--> > stupid that is its problem, = because=20 such an implementation
--> > would break the accessibility = to the=20 PCE for other 'normal' 
--> > PCCs.
--> >
--> 
--> On this aspect, I do agree !
--> 
--> > Unless there are "standard" = constraint=20 back-off functions 
--> > it is hard to conceive of a = PCE=20 guessing the correct back-
--> > off for the PCC that issued = the=20 request. Note that the more 
--> > "speculative paths" the PCE = computes=20 the more CPU it uses.
--> 
--> Speculative paths is definitely = not an=20 option considering the 
--> number of permutations ... we = would=20 unavoidably quickly fall
--> into some NP-Complete issues ;-) = ... This is=20 why the suggestion 
--> is made to start some discussion = on the=20 hierarchical relaxation 
--> policy. Note that it does not have = to be=20 awfully complex ...

Here we have many things said in few = words. I know,=20 because I can
identify numerous points for both = agreement and=20 disagreement.  = :-)

The issue with permutations (and = NP-complete=20 issues) is one part
on which I think we agree.

The notion that a hierarchical relaxation = approach=20 avoids this is
one part on which I think we = disagree.

Finally, the "wish" that it does not have = to be=20 complex is quite
interesting.  The only way that it = will not be=20 complex, is if the
actual decision making process is very = simple in=20 every case. The
point of contention is the fact that - = while it=20 probably can be 
very simple in most cases - it will = almost=20 certainly not be 1) the
same in every case and 2) good enough in = every=20 case.


Ah here I fully agree with you (last paragraph ;-)). The goal may = not be=20 to design a solution that will address *all* cases and that will be = good in=20 *all* cases. 
As a system designer, I'd be very happy if = the=20 proposed solution solves the vast majority of the issues in an simple = way.=20 When not appropriate, just do not use it. Vendor implementations = should be=20 able to be flexible enough so that the operator could choose when to = use such=20 approach. See other similar examples with hierarchical BGP policy = rules, ACLs,=20 ... 

If a different hierarchical relaxation = policy might=20 apply under
different circumstances, then the = complexity of the=20 protocol is
going to be greater than the combination = of all=20 "simple cases".

If the approach is not "good enough", = then a PCC is=20 forced to
fall back on the multiple messages = approach.  Net gain: ~zero.


Indeed, we agree on the fact that we could make it awfully = complex=20 and consequently not practically usable. I could also come up = with many=20 such examples ... Conversely, one could easily come up with=20 *real*life*use*of*TE*scenario where such approach would be quite = useful.=20 *Again*, think of how Service Providers use TE today ... Let me give = you a=20 simple example here (which by the way would cover a good % of current=20 needs):

Packet LSPs,
Two constraints: affinity=3DRED and bandwidth=3D10
The set of constraints cannot be fully satisfied because of = resource=20 contention.

Case A: The PCC sends multiple requests until a path can be = found.
Case B: The PCC sends one request (affinity=3DRED, = bandwidth=3D10) and=20 specifies to first relax the affinity, then find the = closest bandwidth=20 match. Note that a different policy may be adopted different LSP = types.

With such a simple example, you can easily see the benefit = of=20 B-
-> Reduced PCE processing (delay and service time)
-> Cut-down the number of transactions
-> Simple constraint relaxation rule

=3D> consequently reduced path computation delay

Again, I'm not claiming that all problems could be solved this = way and=20 that an operator should/could always use such hierarchical = constraints=20 approach but there are many circumstances whereby such approach would = be IMO=20 highly valuable.

Of course, I'll wait for service providers to confirm that=20 statement.

--> 
--> > So we must keep good control = on this.=20 It is a
--> > computational myth that it is = possible=20 to relax different  
--> > constraints on a
--> > single computational = pass.
--> 
--> Ah no ... there are several = constraints for=20 which 
--> constraint can be relaxed and = closest match=20 can be 
--> found in on-go.
--> 
--> That said, even if it were not the = case, the=20 solution 
--> would still be valuable to = cut-down the=20 communication 
--> overhead and amount of processing = signaling=20 be the 
--> PCE's scheduler.
--> 
--> > In fact, the question "where = did my=20 computation fail"
--> > is notoriously impossible to = answer=20 except with the  =  
--> > response "in the = network".
--> >
--> > Thus we should give full = control to the=20 PCC, and let 
--> > the PCE choose to supply less = information if it thinks =20  
--> > that the PCC is asking too = much. This=20 control includes:
--> >
--> > a. The ability to say "this = or=20 nothing"
--> > b. The ability to say "tell = me what=20 constraints I
--> > =20   might relax to get a path"
--> > c. The ability to say "give = me n=20 alternate paths with 
--> > =20   with your choice of relaxed constraints" (c. is 
--> > =20   like b but with the paths supplied, and it is 
--> > =20   important to control the number)
--> > d. A way to state which = constraints may=20 be relaxed 
--> > =20   absolutely (this is easy)
--> > e. A way to replace one = constraint=20 supplied by the  
--> > =20   PCC with another also supplied by the PCC
--> > f. A way to specify an = ordering for=20 relaxation in 
--> > =20   recomputation attempts.
--> >
--> > My feeling is that e might be = satisfied=20 in the protocol  
--> > simply by listing the same = object=20 multiple times. But f
--> > is very messy. As soon as I = have a few=20 constraints and 
--> > I am willing to relax each of = them by=20 degrees I have a
--> > very complex relaxation = problem to=20 express.
--> 
--> Well not so sure ... Let's wait = for the=20 meeting in Paris to 
--> have an open discussion. I'd be = happy to=20 provide some ideas.
--> Actually one could point out that = such=20 constraint relaxation 
--> are used TODAY in operational = networks (with=20 CSPF).

One could point that out, if one wants to = show that=20 having 
a PCC make separate requests is the right = way to=20 go. I was
under the impression you were arguing the = opposition point
of view.

In the CSPF case you identify, the = Traffic Engineer=20 is both
a PCC and a PCE and - with respect to the = relaxation mode,
it is much more likely to act like a PCC = than a=20 PCE. In other
words, given a requirement for TE tunnel = routing,=20 it will 
most likely complete a computation based = on a=20 single set of
constraints and - if that fails - it may = elect to=20 relax the
path requirements and try again with = different=20 constraints.


But this is the whole point. When the PCE is co-located this can = be done=20 without introducing substantial delays ... Conversely, think of a PCE=20 receiving a burst of requests from tens of PCCs after a network = failure ...=20 this is precisely one of the aspects that I want to = optimize.

This is essentially PCC behavior. Pushing = this=20 behavior into
the PCE saves on external messaging = overhead, but=20 at a huge
cost in complexity.  Now, instead of having a = self-contained
entity (the PCC) deciding how next to = proceed in=20 getting a 
Path (should any attempt fail), it must = communicate=20 a decision 
making process to a delegate (the PCE) = for every=20 Path request
- irrespective of whether or not that = Path Request=20 would fail.

Unless the decision making options are = very=20 limited, this must
impose a higher level of processing on = the PCE just=20 to decode,
store and - eventually - act on the = decision making=20 process.

I doubt that the communication overhead = is the=20 bottle-neck for
PCE-PCC transactions, or the network over = which=20 they transpire.
I also strongly suspect that deployments = will tend=20 toward more
PCCs than PCEs, so - assuming that (for = example)=20 there are ten
times as many PCCs as PCEs - what is the = advantage=20 gained by
pushing the work of 1,000 PCCs onto 100 = PCEs,=20

no no ... we do not push the work of 1,000 PCCs onto 100 PCEs ... = by=20 supporting such constraint relaxation approach you drastically reduce = the=20 processing load on PCEs.

Jumping to the end of this email (considering the text provided=20 above).

especially if you 
assume that most path requests will be = satisfied=20 prior to a PCC 
traversal of the decision tree.

--> 
--> >
--> > This is a problem that it is = very easy=20 for the PCC to  
--> > handle by issuing successive = requests,=20 but very hard for 
--> > the PCC to communicate to the = PCE in a=20 single request.
--> 
--> I do not think that it is hard for = the PCC=20 to communicate 
--> to the PCE in a single = request.

You miss the point.

If "communication" was easy, you wouldn't = have=20 started this
discussion, and I wouldn't be continuing = it.  :-)

Let's say that PCC X follows this scheme = for one=20 subset of its
requests:

scheme (a)
    Request a = path with=20 constraints A, B and C.
    On failure = for A,=20 request a path with constraint A1 that
        = still=20 satisfies B and C.
    On failure = for A1, B=20 or C, fail.

To cut down on communication overhead, we = could=20 communicate
this decision making policy to the PCE = and make a=20 single
request that either succeeds or fails = according to=20 this policy.

But this PCC (or another) also has a = decision=20 making schemes as
follows for other types of = services:

scheme (b)
    Request a = path with=20 constraint A, C and D.
    On failure = for C,=20 request a path with constraints A and D
       =20 only
    On failure = for A or D,=20 fail.

scheme (c)
    Request a = path with=20 constraints B, C and D.
    On failure = (for B, C=20 or D) request an unconstrained shortest
       =20 path.

... and so on ...

Hence, given any arbitrary number of = potential=20 constraints, the
number of possible decision making = policies we need=20 to define
is clearly combinatorial (i.e. - NP) in = the number=20 of possible
constraints (and possible relaxations of=20 each).

However, if we do not cover all of the=20 possibilities, then we
constrain the services that our customers = can sell,=20 their ability
to differentiate themselves from their = competitors=20 and even the
service pricing structures that are = available to=20 their customers
in turn.

To eliminate this concern, all we need to = do is=20 define a language
for describing a decision making = process.  Done much work in = the
area of defining languages like = this?  :-)

--> 
--> >
--> > So, I'd like to see some text = from SPs=20 on this subject 
--> > before we add anything to the = requirements I-D.
--> >
--> 
--> I think that the DT is working on = it.

So, this is confusing. Are you saying = that it's out=20 of the hands
of the WG because the authors are taking = this work=20 on anyway?


/Chair Hat/

I just meant that the DT was working on the new revision of=20 draft-ietf-pce-comm-protocol-gen-reqs with the intention to cover that = aspect=20 for WG input (this new rev has now been published). As you know, by=20 definition, a Working Group document is owned by the Working=20 Group. 

Your comments are of course more than welcome. 

/Chair hat removed/

We may just want to sit down in Paris and discuss more on this if = you=20 will.

JP.

--> 
--> Cheers,
--> 
--> JP.
--> 
--> > Cheers,
--> > Adrian
--> >
--> > --- [SNIP] ---

_______________________________________________
Pce mailing=20 = list
Pce@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce<= BR> ------=_NextPart_000_0031_01C58C56.C855F600-- --===============0011241390== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============0011241390==-- From pce-bounces@lists.ietf.org Tue Jul 19 12:00:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuuWQ-0001WC-1m; Tue, 19 Jul 2005 12:00:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuuWO-0001Vw-L6 for pce@megatron.ietf.org; Tue, 19 Jul 2005 12:00:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09253 for ; Tue, 19 Jul 2005 12:00:38 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Duuzz-000164-SS for pce@ietf.org; Tue, 19 Jul 2005 12:31:19 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 19 Jul 2005 09:00:27 -0700 X-IronPort-AV: i="3.93,300,1115017200"; d="scan'208,217"; a="649322862:sNHT42224588" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j6JG0NVX023825; Tue, 19 Jul 2005 09:00:24 -0700 (PDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 19 Jul 2005 12:00:23 -0400 Received: from [192.168.1.100] ([10.86.240.49]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 19 Jul 2005 12:00:22 -0400 In-Reply-To: <003401c58c78$4f9583d0$7a1810ac@movaz.com> References: <313680C9A886D511A06000204840E1CF0C885D02@whq-msgusr-02.pit.comms.marconi.com> <3915FA68-6E86-4858-8118-84B2FAF7B76D@cisco.com> <003401c58c78$4f9583d0$7a1810ac@movaz.com> Mime-Version: 1.0 (Apple Message framework v730) X-Priority: 3 Message-Id: From: JP Vasseur Subject: Re: [Pce] Requirement for less-constrained path indraft-ietf-pce-comm-protocol-gen-reqs-00.txt Date: Tue, 19 Jul 2005 12:00:38 -0400 To: Igor Bryskin X-Mailer: Apple Mail (2.730) X-OriginalArrivalTime: 19 Jul 2005 16:00:22.0924 (UTC) FILETIME=[F8472CC0:01C58C7A] X-Spam-Score: 0.8 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0687880895==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org --===============0687880895== Content-Type: multipart/alternative; boundary=Apple-Mail-52--399765567 --Apple-Mail-52--399765567 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Hi Igor, Removing text since the message exceeds the max message size on the SMTP server ... see all about constraints relaxation ;-)) Comment: The co-authors of the PCEP ID propose to remove it from the PCEP ID (in the next revision) since the topic deserves its own ID. The PCEP ID will deal with basic protocol operations and set of messages/objects. On Jul 19, 2005, at 11:41 AM, Igor Bryskin wrote: > JP. > > As I have indicated earlier I don't believe that the complexity > associated with signaling of constraint relaxation strategy > justifies the results. Most of the constraints are non-boolean, and > it is difficult IMO to provide a simple yet flexible way for a PCC > to articulate the desired way of relaxation wrt each of the > constraints. And what if the constraints are not independent? For > instance, what if a PCC wants to get best tradeoff of several > constraints ? > Wouldn't you have to configure it somewhere if you wanted to reach that objective ? > My suggestion is to start with allowing for PCC to specify in a > single request a set of mandatory constraints and an ordered list > of sets of relaxable constraints: first, use the first set in the > list (+ mandatory, of course), if path computation fails - use the > second one and so forth. This is a much simpler way of doing the > constraint relaxation and could be just good enough, although it > makes the size of requests and response larger. We can discuss the details of this in Paris, but this a perfectly valid way of allowing a PCC for the specification of constraint relaxation (although it does not address the "guessing" issue for non boolean constraint but we could find an easy way to deal with this). Good ! What I'm trying to avoid is a succession of serialized path computation requests without providing the ability for the PCE to come up with a closest match but no need to restart the whole thread here ... > > By the way, do you remember that sometime ago I suggested to design > the PCC-PCE protocol in a such a way where each request/response is > a BASIC style program that could be interpreted by both PCC and > PCE? The intention was to provide a very flexible way for a PCE to > describe its capabilities and introduce new ones, and for PCC to > take the most of the PCE and specify what exactly it wants from the > requested path computation (what constraints and optimization > criterias to be used and how) > Well at this point, we may want to get more feed-back from Service Providers. Cheers, JP. > It would be very easy to support the constraint relaxation > strategies no matter how complex they are :=) > > Cheers, > Igor --Apple-Mail-52--399765567 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Igor,

Removing text since the = message exceeds the max message size on the SMTP server ... see all = about constraints relaxation ;-))

Comment: The co-authors of = the PCEP ID propose to remove it from the PCEP ID (in the next revision) = since the topic=A0deserves its own ID. The PCEP ID will deal with basic = protocol operations and set of = messages/objects.=A0

On Jul 19, 2005, at 11:41 = AM, Igor Bryskin wrote:

JP.
=A0
=A0

Wouldn't you have to = configure it somewhere if you wanted to reach that objective = ?

My suggestion is to start with allowing for = PCC to specify in a single request a set of mandatory constraints and an = ordered list of sets of relaxable constraints: first, use the first set = in the list (+ mandatory, of course), if path computation fails - use = the second one and so forth. This is a much simpler way of doing the = constraint=A0relaxation and could be just good enough, although=A0it = makes the size of requests and response = larger.

We can discuss the details = of this in Paris, but this a perfectly valid way of allowing a PCC for = the specification of constraint relaxation (although it does not address = the "guessing" issue for non boolean constraint but we could find an = easy way to deal with this). Good ! What I'm trying to avoid is a = succession of serialized path computation requests without providing the = ability for the PCE to come up with a closest match but no need to = restart the=A0whole thread here ...=A0

=A0
=A0

Well at this point, we may = want to get more feed-back from Service Providers.

Cheers,

JP.

It would be very easy=A0to support the = constraint relaxation strategies no matter how complex they are = :=3D)
=A0
Date: Tue, 19 Jul 2005 15:50:02 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-architecture-01.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org --NextPart 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 : Path Computation Element (PCE) Architecture Author(s) : A. Farrel, et al. Filename : draft-ietf-pce-architecture-01.txt Pages : 29 Date : 2005-7-19 Constraint-based path computation is a fundamental building block for traffic engineering systems such as Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) networks. Path computation in large, multi-domain, multi-region or multi-layer networks is highly complex and may require special computational components and cooperation between the different network domains. This document specifies the architecture for a Path Computation Element (PCE)-based model to address this problem space. This document does not attempt to provide a detailed description of all the architectural components, but rather it describes a set of building blocks for the PCE architecture from which solutions may be constructed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-architecture-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pce-architecture-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pce-architecture-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-7-19114623.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pce-architecture-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pce-architecture-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-7-19114623.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --NextPart-- From pce-bounces@lists.ietf.org Tue Jul 19 20:55:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dv2sQ-0002rM-Lt; Tue, 19 Jul 2005 20:55:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dv2sN-0002rD-IE for pce@megatron.ietf.org; Tue, 19 Jul 2005 20:55:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22154 for ; Tue, 19 Jul 2005 20:55:53 -0400 (EDT) Received: from tama55.ecl.ntt.co.jp ([129.60.39.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dv3M6-0008Aw-Jf for pce@ietf.org; Tue, 19 Jul 2005 21:26:39 -0400 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama55.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j6K0shoI009363; Wed, 20 Jul 2005 09:54:43 +0900 (JST) Received: from vcs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j6K0shTK029277; Wed, 20 Jul 2005 09:54:43 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j6K0sg5Q029265; Wed, 20 Jul 2005 09:54:42 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j6K0sgfF019995; Wed, 20 Jul 2005 09:54:42 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j6K0sgsB019992; Wed, 20 Jul 2005 09:54:42 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j6K0sfmk006820; Wed, 20 Jul 2005 09:54:41 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j6K0sfvT022570; Wed, 20 Jul 2005 09:54:41 +0900 (JST) Received: from imb.m.ecl.ntt.co.jp (imb0.m.ecl.ntt.co.jp [129.60.5.140]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j6K0sf8g022567; Wed, 20 Jul 2005 09:54:41 +0900 (JST) Received: from [127.0.0.1] by imb.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id JAA19586; Wed, 20 Jul 2005 09:54:40 +0900 (JST) Date: Wed, 20 Jul 2005 09:54:24 +0900 From: Eiji Oki To: JP Vasseur Subject: Re: [Pce] Requirement for less-constrained path indraft-ietf-pce- comm-protocol-gen-reqs-00.txt In-Reply-To: <3915FA68-6E86-4858-8118-84B2FAF7B76D@cisco.com> References: <313680C9A886D511A06000204840E1CF0C885D02@whq-msgusr-02.pit.comms.marconi.com> <3915FA68-6E86-4858-8118-84B2FAF7B76D@cisco.com> Message-Id: <20050720094453.D4CC.OKI.EIJI@lab.ntt.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-Mailer: Becky! ver. 2.08 [ja] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: quoted-printable Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi =46rom SP point of view, the less-constraint approach is highly useful. It is beneficial for an operator to get a suggested path by PCE according to simple constraint relaxation rules with an efficient manner. Thank you. Eiji On Tue, 19 Jul 2005 09:47:25 -0400 JP Vasseur wrote: > Hi Eric, >=20 > On Jul 18, 2005, at 3:57 PM, Gray, Eric wrote: >=20 > > JP, > > [snip] >=20 > Case A: The PCC sends multiple requests until a path can be found. > Case B: The PCC sends one request (affinity=3DRED, bandwidth=3D10) and = =20 > specifies to first relax the affinity, then find the closest =20 > bandwidth match. Note that a different policy may be adopted =20 > different LSP types. >=20 > With such a simple example, you can easily see the benefit of B- > -> Reduced PCE processing (delay and service time) > -> Cut-down the number of transactions > -> Simple constraint relaxation rule >=20 > =3D> consequently reduced path computation delay >=20 > Again, I'm not claiming that all problems could be solved this way =20 > and that an operator should/could always use such hierarchical =20 > constraints approach but there are many circumstances whereby such =20 > approach would be IMO highly valuable. >=20 > Of course, I'll wait for service providers to confirm that statement. >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Jul 20 07:38:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvCub-0003Ac-I5; Wed, 20 Jul 2005 07:38:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvCua-0003AI-BK for pce@megatron.ietf.org; Wed, 20 Jul 2005 07:38:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07348 for ; Wed, 20 Jul 2005 07:38:50 -0400 (EDT) Received: from relay1.mail.uk.clara.net ([80.168.70.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvDON-0003Wh-4j for pce@ietf.org; Wed, 20 Jul 2005 08:09:41 -0400 Received: from du-069-0127.access.clara.net ([217.158.132.127] helo=Puppy) by relay1.mail.uk.clara.net with smtp (Exim 4.46) id 1DvCuR-0004Gt-I6 for pce@ietf.org; Wed, 20 Jul 2005 12:38:44 +0100 Message-ID: <153a01c58d1f$ee3f36f0$d6849ed9@Puppy> From: "Adrian Farrel" To: Date: Wed, 20 Jul 2005 11:52:13 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: 7bit Cc: Subject: [Pce] Draft schedule - PCE moved to Tuesday 2pm X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi, It would appear that PCE has been moved to Tuesday at 2pm. (I did say it was provisional!) Adrian _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Jul 20 07:38:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvCuc-0003B1-0X; Wed, 20 Jul 2005 07:38:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvCua-0003AK-Cp for pce@megatron.ietf.org; Wed, 20 Jul 2005 07:38:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07349 for ; Wed, 20 Jul 2005 07:38:50 -0400 (EDT) Received: from relay1.mail.uk.clara.net ([80.168.70.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvDON-0003Wj-4f for pce@ietf.org; Wed, 20 Jul 2005 08:09:41 -0400 Received: from du-069-0127.access.clara.net ([217.158.132.127] helo=Puppy) by relay1.mail.uk.clara.net with smtp (Exim 4.46) id 1DvCuS-0004Gt-J0 for pce@ietf.org; Wed, 20 Jul 2005 12:38:45 +0100 Message-ID: <154701c58d1f$ef014e70$d6849ed9@Puppy> From: "Adrian Farrel" To: References: Date: Wed, 20 Jul 2005 12:05:30 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 0.1 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: 7bit Cc: Subject: [Pce] Changes in the new revision of the architecture I-D X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi, We did a largely editorial pass on the Architecture I-D. That is, no new technical aspects. Changes are listed below. I am aware that the I-D would benefit from some restructuring and an editorial pass dedicated to clarity, but I would ask that we now have a really thorough technical review of the document. Thanks, Adrian === Reformatted the text so that it is correctly aligned Remove spurious blank lines Align indented paragraphs Re-draw figure 3 to fit on page Updated the boilerplate Removed the RFC2219 references Renumbered the sections Resolve and correct cross-references Remove double spaces Change single quotes to double quotes Updated references Use "reoptimize" throughout. Fix references to VNT since it was discussed before it was referenced Add Manageability Considerations Section (section 8) Add penultimate paragraph to section 6.6 to cover comments from Takao Shimizu Add final paragraph to section 6.8 to cover comments from Takao Shimizu Add 2nd sentence to first paragraph of section 7 to cover comments from Takao Shimizu Add 2nd paragraph to section 6.1 to cover comments from Vivek Dubey Rewrite parts of section 6.3 which was garbled and add comments from Vivek Dubey and Richard Rewrite 2nd paragraph of section 6.5 to handle comments from Vivek Dubey Fix sundry typos found on casual reading Add section 6.11 in response to discussions in the last WG meeting Section 3 2) add 2nd sentence to clarify for Arthi. Rewrite 6.7 3) because it implied that LSP information is held in the TED and comments form Arthi Add final sentence to section 7 bullet 1 to cover our discussion of Igor's comments Section 4.5 clarify the PCC's role in the management plane in response to Richard. Section 5.4 clarify that the multiple PCE with inter-PCE communication scenario is not a case of a distributed computation algorithm. Fill out Acknowledgements section Spell-check Repaginate and index Run idnits and make fixes _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Jul 22 10:27:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvyV1-00011G-L7; Fri, 22 Jul 2005 10:27:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvyUz-000114-H8 for pce@megatron.ietf.org; Fri, 22 Jul 2005 10:27:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19972 for ; Fri, 22 Jul 2005 10:27:35 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvyzF-0007ry-9p for pce@ietf.org; Fri, 22 Jul 2005 10:58:53 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 22 Jul 2005 07:27:28 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j6MEQf7P001156 for ; Fri, 22 Jul 2005 07:27:26 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 22 Jul 2005 10:27:17 -0400 Received: from [192.168.1.100] ([10.86.241.25]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 22 Jul 2005 10:27:16 -0400 Mime-Version: 1.0 (Apple Message framework v730) References: <153a01c58d1f$ee3f36f0$d6849ed9@Puppy> X-Priority: 3 Message-Id: <05908F35-32D2-43D7-90EC-E9FADF785AE0@cisco.com> From: JP Vasseur Subject: Fwd: [Pce] Draft schedule - PCE moved to Tuesday 2pm Date: Fri, 22 Jul 2005 10:27:34 -0400 To: pce@ietf.org X-Mailer: Apple Mail (2.730) X-OriginalArrivalTime: 22 Jul 2005 14:27:16.0709 (UTC) FILETIME=[75DFA950:01C58EC9] X-Spam-Score: 0.2 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2114202830==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org --===============2114202830== Content-Type: multipart/alternative; boundary=Apple-Mail-102--146149891 --Apple-Mail-102--146149891 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Quick note to mention that we have a 2-hour slot. JP. Begin forwarded message: > From: "Adrian Farrel" > Date: July 20, 2005 6:52:13 AM EDT > To: > Subject: [Pce] Draft schedule - PCE moved to Tuesday 2pm > Reply-To: Adrian Farrel > > > Hi, > > It would appear that PCE has been moved to Tuesday at 2pm. > > (I did say it was provisional!) > > Adrian > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > --Apple-Mail-102--146149891 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Quick note to mention that we = have a 2-hour slot.

JP.

Begin = forwarded message:

From: = "Adrian Farrel" <adrian@olddog.co.uk>
Date: = July 20, 2005 6:52:13 AM EDT
Subject: = [Pce] Draft schedule - PCE moved to Tuesday = 2pm
Reply-To: Adrian Farrel <adrian@olddog.co.uk>


Hi,

It would = appear that PCE has been moved to Tuesday at 2pm.

(I did = say it was provisional!)

Adrian

Pce mailing list


= --Apple-Mail-102--146149891-- --===============2114202830== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============2114202830==-- From pce-bounces@lists.ietf.org Sat Jul 23 08:36:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwJEz-0001Wt-OE; Sat, 23 Jul 2005 08:36:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwJEx-0001Wo-Rs for pce@megatron.ietf.org; Sat, 23 Jul 2005 08:36:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22443 for ; Sat, 23 Jul 2005 08:36:26 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwJjP-0003ii-J3 for pce@ietf.org; Sat, 23 Jul 2005 09:07:55 -0400 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DwJEw-000P10-CO; Sat, 23 Jul 2005 12:36:26 +0000 Message-ID: <42E239D1.9010907@psg.com> Date: Sat, 23 Jul 2005 14:36:33 +0200 From: dimitri papadimitriou User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adrian Farrel Subject: Re: [Pce] Changes in the new revision of the architecture I-D References: <154701c58d1f$ef014e70$d6849ed9@Puppy> In-Reply-To: <154701c58d1f$ef014e70$d6849ed9@Puppy> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: 7bit Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org hi adrian > We did a largely editorial pass on the Architecture I-D. That is, no new > technical aspects. > > Changes are listed below. > > I am aware that the I-D would benefit from some restructuring and an > editorial pass dedicated to clarity, but I would ask that we now have a > really thorough technical review of the document. do you have any specific timeframe for such technical review beside charter milestone thanks, - dimitri. > Thanks, > Adrian > > === > > Reformatted the text so that it is correctly aligned > > Remove spurious blank lines > > Align indented paragraphs > > Re-draw figure 3 to fit on page > > Updated the boilerplate > > Removed the RFC2219 references > > Renumbered the sections > > Resolve and correct cross-references > > Remove double spaces > > Change single quotes to double quotes > > Updated references > > Use "reoptimize" throughout. > > Fix references to VNT since it was discussed before it was referenced > > Add Manageability Considerations Section (section 8) > > Add penultimate paragraph to section 6.6 to cover comments from Takao > Shimizu > > Add final paragraph to section 6.8 to cover comments from Takao Shimizu > > Add 2nd sentence to first paragraph of section 7 to cover comments from > Takao Shimizu > > Add 2nd paragraph to section 6.1 to cover comments from Vivek Dubey > > Rewrite parts of section 6.3 which was garbled and add comments from Vivek > Dubey and Richard > > Rewrite 2nd paragraph of section 6.5 to handle comments from Vivek Dubey > > Fix sundry typos found on casual reading > > Add section 6.11 in response to discussions in the last WG meeting > > Section 3 2) add 2nd sentence to clarify for Arthi. > > Rewrite 6.7 3) because it implied that LSP information is held in the TED > and comments form Arthi > > Add final sentence to section 7 bullet 1 to cover our discussion of Igor's > comments > > Section 4.5 clarify the PCC's role in the management plane in response to > Richard. > > Section 5.4 clarify that the multiple PCE with inter-PCE communication > scenario is not a case of a distributed computation algorithm. > > Fill out Acknowledgements section > > Spell-check > > Repaginate and index > > Run idnits and make fixes > > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > > . > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Sat Jul 23 09:25:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwK0q-0000MF-KI; Sat, 23 Jul 2005 09:25:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwK0o-0000LT-Er for pce@megatron.ietf.org; Sat, 23 Jul 2005 09:25:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24669 for ; Sat, 23 Jul 2005 09:25:52 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwKVG-000511-IQ for pce@ietf.org; Sat, 23 Jul 2005 09:57:22 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 23 Jul 2005 06:24:46 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.95,137,1120460400"; d="scan'208"; a="3082047:sNHT22755208" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j6NDOik6005845; Sat, 23 Jul 2005 09:24:44 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 23 Jul 2005 09:24:43 -0400 Received: from [192.168.1.100] ([10.86.241.6]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 23 Jul 2005 09:24:43 -0400 In-Reply-To: <42E239D1.9010907@psg.com> References: <154701c58d1f$ef014e70$d6849ed9@Puppy> <42E239D1.9010907@psg.com> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <84945647-6729-4394-A308-17C1D3C79589@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: [Pce] Changes in the new revision of the architecture I-D Date: Sat, 23 Jul 2005 09:24:54 -0400 To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be X-Mailer: Apple Mail (2.730) X-OriginalArrivalTime: 23 Jul 2005 13:24:43.0907 (UTC) FILETIME=[E3714530:01C58F89] X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: 7bit Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi Dimitri, On Jul 23, 2005, at 8:36 AM, dimitri papadimitriou wrote: > hi adrian > > >> We did a largely editorial pass on the Architecture I-D. That is, >> no new >> technical aspects. >> Changes are listed below. >> I am aware that the I-D would benefit from some restructuring and an >> editorial pass dedicated to clarity, but I would ask that we now >> have a >> really thorough technical review of the document. >> > > do you have any specific timeframe for such technical review beside > charter milestone > We think that the ID is pretty stable in term of technical content. As Adrian pointed out, there might be some editorial work to be done before WG last call. So the short answer is "as soon as possible". Thanks. JP. > thanks, > - dimitri. > > > >> Thanks, >> Adrian >> === >> Reformatted the text so that it is correctly aligned >> Remove spurious blank lines >> Align indented paragraphs >> Re-draw figure 3 to fit on page >> Updated the boilerplate >> Removed the RFC2219 references >> Renumbered the sections >> Resolve and correct cross-references >> Remove double spaces >> Change single quotes to double quotes >> Updated references >> Use "reoptimize" throughout. >> Fix references to VNT since it was discussed before it was referenced >> Add Manageability Considerations Section (section 8) >> Add penultimate paragraph to section 6.6 to cover comments from Takao >> Shimizu >> Add final paragraph to section 6.8 to cover comments from Takao >> Shimizu >> Add 2nd sentence to first paragraph of section 7 to cover comments >> from >> Takao Shimizu >> Add 2nd paragraph to section 6.1 to cover comments from Vivek Dubey >> Rewrite parts of section 6.3 which was garbled and add comments >> from Vivek >> Dubey and Richard >> Rewrite 2nd paragraph of section 6.5 to handle comments from Vivek >> Dubey >> Fix sundry typos found on casual reading >> Add section 6.11 in response to discussions in the last WG meeting >> Section 3 2) add 2nd sentence to clarify for Arthi. >> Rewrite 6.7 3) because it implied that LSP information is held in >> the TED >> and comments form Arthi >> Add final sentence to section 7 bullet 1 to cover our discussion >> of Igor's >> comments >> Section 4.5 clarify the PCC's role in the management plane in >> response to >> Richard. >> Section 5.4 clarify that the multiple PCE with inter-PCE >> communication >> scenario is not a case of a distributed computation algorithm. >> Fill out Acknowledgements section >> Spell-check >> Repaginate and index >> Run idnits and make fixes >> _______________________________________________ >> Pce mailing list >> Pce@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/pce >> . >> > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Sat Jul 23 12:45:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwN7h-0008RA-QS; Sat, 23 Jul 2005 12:45:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwN7g-0008Ql-5V for pce@megatron.ietf.org; Sat, 23 Jul 2005 12:45:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07486 for ; Sat, 23 Jul 2005 12:45:08 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwNcA-0002ip-01 for pce@ietf.org; Sat, 23 Jul 2005 13:16:42 -0400 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DwN7W-000H0f-Ot; Sat, 23 Jul 2005 16:45:03 +0000 Message-ID: <42E27415.2030104@psg.com> Date: Sat, 23 Jul 2005 18:45:09 +0200 From: dimitri papadimitriou User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: JP Vasseur Subject: Re: [Pce] Changes in the new revision of the architecture I-D References: <154701c58d1f$ef014e70$d6849ed9@Puppy> <42E239D1.9010907@psg.com> <84945647-6729-4394-A308-17C1D3C79589@cisco.com> In-Reply-To: <84945647-6729-4394-A308-17C1D3C79589@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: 7bit Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org hi, >>> We did a largely editorial pass on the Architecture I-D. That is, no >>> new >>> technical aspects. >>> Changes are listed below. >>> I am aware that the I-D would benefit from some restructuring and an >>> editorial pass dedicated to clarity, but I would ask that we now have a >>> really thorough technical review of the document. >> >> do you have any specific timeframe for such technical review beside >> charter milestone > > We think that the ID is pretty stable in term of technical content. As > Adrian pointed out, there might be some editorial work to be done > before WG last call. So the short answer is "as soon as possible". ok thanks - this said i asked the question because adrian's e-mail speaks about a thorough *technical* review and wanted to know whether you wanted to have a specific review before last call ? > Thanks. > > JP. > >> thanks, >> - dimitri. >> >> >> >>> Thanks, >>> Adrian >>> === >>> Reformatted the text so that it is correctly aligned >>> Remove spurious blank lines >>> Align indented paragraphs >>> Re-draw figure 3 to fit on page >>> Updated the boilerplate >>> Removed the RFC2219 references >>> Renumbered the sections >>> Resolve and correct cross-references >>> Remove double spaces >>> Change single quotes to double quotes >>> Updated references >>> Use "reoptimize" throughout. >>> Fix references to VNT since it was discussed before it was referenced >>> Add Manageability Considerations Section (section 8) >>> Add penultimate paragraph to section 6.6 to cover comments from Takao >>> Shimizu >>> Add final paragraph to section 6.8 to cover comments from Takao Shimizu >>> Add 2nd sentence to first paragraph of section 7 to cover comments from >>> Takao Shimizu >>> Add 2nd paragraph to section 6.1 to cover comments from Vivek Dubey >>> Rewrite parts of section 6.3 which was garbled and add comments from >>> Vivek >>> Dubey and Richard >>> Rewrite 2nd paragraph of section 6.5 to handle comments from Vivek >>> Dubey >>> Fix sundry typos found on casual reading >>> Add section 6.11 in response to discussions in the last WG meeting >>> Section 3 2) add 2nd sentence to clarify for Arthi. >>> Rewrite 6.7 3) because it implied that LSP information is held in >>> the TED >>> and comments form Arthi >>> Add final sentence to section 7 bullet 1 to cover our discussion of >>> Igor's >>> comments >>> Section 4.5 clarify the PCC's role in the management plane in >>> response to >>> Richard. >>> Section 5.4 clarify that the multiple PCE with inter-PCE communication >>> scenario is not a case of a distributed computation algorithm. >>> Fill out Acknowledgements section >>> Spell-check >>> Repaginate and index >>> Run idnits and make fixes >>> _______________________________________________ >>> Pce mailing list >>> Pce@lists.ietf.org >>> https://www1.ietf.org/mailman/listinfo/pce >>> . >>> >> >> _______________________________________________ >> Pce mailing list >> Pce@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/pce >> > > . > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Sat Jul 23 13:05:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwNRZ-0006KF-NV; Sat, 23 Jul 2005 13:05:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwNRY-0006KA-41 for pce@megatron.ietf.org; Sat, 23 Jul 2005 13:05:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08563 for ; Sat, 23 Jul 2005 13:05:40 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwNvz-0003Gy-36 for pce@ietf.org; Sat, 23 Jul 2005 13:37:14 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 23 Jul 2005 10:05:31 -0700 X-IronPort-AV: i="3.95,137,1120460400"; d="scan'208"; a="322407324:sNHT31609708" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j6NH5Pul024157; Sat, 23 Jul 2005 10:05:26 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 23 Jul 2005 13:05:25 -0400 Received: from [192.168.1.100] ([10.86.241.6]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 23 Jul 2005 13:05:29 -0400 In-Reply-To: <42E27415.2030104@psg.com> References: <154701c58d1f$ef014e70$d6849ed9@Puppy> <42E239D1.9010907@psg.com> <84945647-6729-4394-A308-17C1D3C79589@cisco.com> <42E27415.2030104@psg.com> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: [Pce] Changes in the new revision of the architecture I-D Date: Sat, 23 Jul 2005 13:05:47 -0400 To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be X-Mailer: Apple Mail (2.730) X-OriginalArrivalTime: 23 Jul 2005 17:05:29.0838 (UTC) FILETIME=[BAA1F0E0:01C58FA8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Content-Transfer-Encoding: 7bit Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi, On Jul 23, 2005, at 12:45 PM, dimitri papadimitriou wrote: > hi, > > >>>> We did a largely editorial pass on the Architecture I-D. That >>>> is, no new >>>> technical aspects. >>>> Changes are listed below. >>>> I am aware that the I-D would benefit from some restructuring >>>> and an >>>> editorial pass dedicated to clarity, but I would ask that we >>>> now have a >>>> really thorough technical review of the document. >>>> >>> >>> do you have any specific timeframe for such technical review >>> beside charter milestone >>> >> We think that the ID is pretty stable in term of technical >> content. As Adrian pointed out, there might be some editorial >> work to be done before WG last call. So the short answer is "as >> soon as possible". >> > > ok thanks - > > this said i asked the question because adrian's e-mail speaks about > a thorough *technical* review and wanted to know whether you wanted > to have a specific review before last call ? > It would indeed be nice to do it prior to last call. Thanks. JP. > >> Thanks. >> JP. >> >>> thanks, >>> - dimitri. >>> >>> >>> >>> >>>> Thanks, >>>> Adrian >>>> === >>>> Reformatted the text so that it is correctly aligned >>>> Remove spurious blank lines >>>> Align indented paragraphs >>>> Re-draw figure 3 to fit on page >>>> Updated the boilerplate >>>> Removed the RFC2219 references >>>> Renumbered the sections >>>> Resolve and correct cross-references >>>> Remove double spaces >>>> Change single quotes to double quotes >>>> Updated references >>>> Use "reoptimize" throughout. >>>> Fix references to VNT since it was discussed before it was >>>> referenced >>>> Add Manageability Considerations Section (section 8) >>>> Add penultimate paragraph to section 6.6 to cover comments from >>>> Takao >>>> Shimizu >>>> Add final paragraph to section 6.8 to cover comments from Takao >>>> Shimizu >>>> Add 2nd sentence to first paragraph of section 7 to cover >>>> comments from >>>> Takao Shimizu >>>> Add 2nd paragraph to section 6.1 to cover comments from Vivek Dubey >>>> Rewrite parts of section 6.3 which was garbled and add comments >>>> from Vivek >>>> Dubey and Richard >>>> Rewrite 2nd paragraph of section 6.5 to handle comments from >>>> Vivek Dubey >>>> Fix sundry typos found on casual reading >>>> Add section 6.11 in response to discussions in the last WG meeting >>>> Section 3 2) add 2nd sentence to clarify for Arthi. >>>> Rewrite 6.7 3) because it implied that LSP information is held >>>> in the TED >>>> and comments form Arthi >>>> Add final sentence to section 7 bullet 1 to cover our >>>> discussion of Igor's >>>> comments >>>> Section 4.5 clarify the PCC's role in the management plane in >>>> response to >>>> Richard. >>>> Section 5.4 clarify that the multiple PCE with inter-PCE >>>> communication >>>> scenario is not a case of a distributed computation algorithm. >>>> Fill out Acknowledgements section >>>> Spell-check >>>> Repaginate and index >>>> Run idnits and make fixes >>>> _______________________________________________ >>>> Pce mailing list >>>> Pce@lists.ietf.org >>>> https://www1.ietf.org/mailman/listinfo/pce >>>> . >>>> >>>> >>> >>> _______________________________________________ >>> Pce mailing list >>> Pce@lists.ietf.org >>> https://www1.ietf.org/mailman/listinfo/pce >>> >>> >> . > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Jul 25 06:38:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx0La-0005AC-W4; Mon, 25 Jul 2005 06:38:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwycO-0002t2-SD for pce@megatron.ietf.org; Mon, 25 Jul 2005 04:47:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28457 for ; Mon, 25 Jul 2005 04:47:23 -0400 (EDT) Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dwz7B-0000z8-7x for pce@ietf.org; Mon, 25 Jul 2005 05:19:16 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Mon, 25 Jul 2005 10:45:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Pce] Requirement for less-constrained pathindraft-ietf-pce-comm-protocol-gen-reqs-00.txt Date: Mon, 25 Jul 2005 10:45:09 +0200 Message-ID: Thread-Topic: [Pce] Requirement for less-constrained pathindraft-ietf-pce-comm-protocol-gen-reqs-00.txt Thread-Index: AcWMeRRAgGjOron5Q9Wfg+uU4zf22gEcC53w From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "Igor Bryskin" , "JP Vasseur" , "Gray, Eric" X-OriginalArrivalTime: 25 Jul 2005 08:45:10.0803 (UTC) FILETIME=[2AB83630:01C590F5] X-Spam-Score: 2.9 (++) X-Scan-Signature: a6fbc3f72733b992651b7383a5b2fed7 X-Mailman-Approved-At: Mon, 25 Jul 2005 06:38:09 -0400 Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1089100328==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1089100328== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C590F5.2A8478DD" This is a multi-part message in MIME format. ------_=_NextPart_001_01C590F5.2A8478DD Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Igor, all =20 Please see inline for some comments, ________________________________ De : pce-bounces@lists.ietf.org [mailto:pce-bounces@lists.ietf.org] De = la part de Igor Bryskin Envoy=E9 : mardi 19 juillet 2005 17:41 =C0 : JP Vasseur; Gray, Eric Cc : pce@ietf.org Objet : Re: [Pce] Requirement for less-constrained = pathindraft-ietf-pce-comm-protocol-gen-reqs-00.txt JP. =20 As I have indicated earlier I don't believe that the complexity = associated with signaling of constraint relaxation strategy justifies = the results.=20 [JLLR] Please don't make things more complex than they are in practical = operational cases... =20 A practical case, that is deployed btw, is SRLG exclusion in FRR bypass = tunnel path computation: The operator wants a path that excludes a set of SRLGs, and if this path = cannot be found he wants a path that excludes the maximum number of = SRLGs in this set. Unfortunately the PCC cannot guess this best relaxed = set and for instance if #SRLG =3D 4 this may lead to 16 requests :-( Conversely the PCE can run an algorithm that will return a path = maximizing the number of excluded SRLGs. This is a simple case where less constrained paths are highly valuable. =20 Another simple case is "bounded delay bandwidth constrained" path = computation: If the path cannot be found, I want the PCE to provide me a bandwidth = constrained path with a relaxed delay bound or a delay bounded path with a relaxed bandwidth constraint. = Unfortunately I cannot guess these relaxed values, and it sound really valuable, and not so complex (there are highly efficient heuristics) for = the PCE to perform such relaxation.... =20 Most of the constraints are non-boolean, and it is difficult IMO to = provide a simple yet flexible way for a PCC to articulate the desired = way of relaxation wrt each of the constraints. [JLLR] In practical operational cases you won't have a lot of = constraints, so this sounds quite simple to articulate such relaxation = (one could use a set of bits vectors). =20 And what if the constraints are not independent? For instance, what if = a PCC wants to get best tradeoff of several constraints ?=20 [JLLR] We could also find a simple way to express these cases (again = with a vector encoding dependent constraints to be relaxed...) My suggestion is to start with allowing for PCC to specify in a single = request a set of mandatory constraints and an ordered list of sets of = relaxable constraints: first, use the first set in the list (+ = mandatory, of course), if path computation fails - use the second one = and so forth.=20 [JLLR] Do you include constraint values or just identify constraints to = be relaxed?=20 If the latter, then we fully agree. =20 This is a much simpler way of doing the constraint relaxation and could = be just good enough, although it makes the size of requests and response = larger. [JLLR] Simpler than which way??=20 =20 By the way, do you remember that sometime ago I suggested to design the = PCC-PCE protocol in a such a way where each request/response is a BASIC = style program that could be interpreted by both PCC and PCE? The intention was to = provide a very flexible way for a PCE to describe its capabilities and = introduce new ones, and for PCC to take the most of the PCE and specify = what exactly it wants from the requested path computation (what = constraints and optimization criterias to be used and how) =20 [JLLR]=20 Note that this has already been proposed by Kireeti two years ago to = pass constraints in RSVP (see = http://www.watersprings.org/pub/id/draft-kompella-mpls-rsvp-constraints-0= 1.txt = ) I have major concerns regarding the complexity of this approach. Please = note that the PCE may run quite complex algorithms (e.g. = multi-constraint heuristic algorithms, or, yet to be added in the = charter, steiner tree heuristics, requiring CPU intensive = computation...). Do you also assume passing the code for such complex = algorithms??? This would drastically complexify PCC operations.... =20 It would be very easy to support the constraint relaxation strategies no = matter how complex they are :=3D) [JLLR] Ah yes of course if you put a lot of complexity on the PCC :-( =20 I agree with you that this would provide a huge flexibility in the way = to express constraints, but think about the standardization effort that this would imply (unless = you want to rely on Java applets :-)) =20 Best Regards, =20 JL =20 Cheers, Igor ----- Original Message -----=20 From: JP Vasseur =20 To: Gray, Eric =20 Cc: pce@ietf.org=20 Sent: Tuesday, July 19, 2005 9:47 AM Subject: Re: [Pce] Requirement for less-constrained path = indraft-ietf-pce-comm-protocol-gen-reqs-00.txt Hi Eric,=20 On Jul 18, 2005, at 3:57 PM, Gray, Eric wrote: JP, From your earlier response, I see that you're aiming=20 at the "greater of two evil" solutions. Tch, tch, tch!! Please see below... --> -----Original Message----- --> From: JP Vasseur [mailto:jvasseur@cisco.com] --> Sent: Thursday, July 14, 2005 9:19 PM --> To: Adrian Farrel --> Cc: Gray, Eric; pce@ietf.org --> Subject: Re: [Pce] Requirement for less-constrained path --> indraft-ietf-pce-comm-protocol-gen-reqs-00.txt -->=20 -->=20 -->=20 --> On Jul 14, 2005, at 12:26 PM, Adrian Farrel wrote: -->=20 --> > I want to pitch in on this thread because I think (I) see=20 --> > where both JP and Eric are coming from. JP's proposals have --> > the potential to significantly reduce the PCE processing=20 --> > and cut down number of PCC-PCE transactions, but they also --> > have the ability to massively increase the processing and =20 --> > the size of the PCC-PCE transactions. --> > -->=20 --> that said, it it pretty straightforward to see that the benefits =20 --> undoubtedly outweigh the drawbacks. The request processing is =20 --> definitely negligible compared to the communication overhead. This is the point of obvious disagreement. Good so at least we agree on the disagreement ;-) --> Actually, it could be shown that the non support of such = capability =20 --> would have a drastic scalability impact on the solution especially = =20 --> upon resource contention. Only if you assume that communication is the bottleneck. Just try to decompose the various steps occurring during a path = computation (request/reply) especially when the constraints cannot be = fully satisfied: 1) Path computation request sent to the PCE 2) PCE processing which includes: - queueing delay (PCE scheduler) - service time (PCE scheduler) 3) Path computation reply sent to the PCE. Then repeat such cycle until a path is successfully computed. Now consider the two cases where: A- The PCC has to send multiple requests trying to guess the set of = constraints that could lead to a successful path computation. B- The PCC specifies a set of rules and the PCE tries to find a path by = means of a single request A few important facts: - In case of A, when the constraint is not a boolean (e.g. bandwidth), = it is really a guess and even an approach based on dichotomy would = unavoidably lead to a non negligible number of cycles.=20 - Some path computation algorithms have the capability to relax = constraints "on the fly" thus saving CPU cycles compared to serialized = path computations.=20 - Without entering into some gory details about network analysis, = queueing systems and implementation-specific algorithms, try to = decompose the steps 1), 2) and 3), and you'll easily identify where the = bottlenecks are when comparing the two approaches (especially 2). - The set of rules does not have to be complex (see an example below) = and more importantly does not have to be used when inappropriate =09 Reality is that messaging only becomes a bottleneck if message processing is excessively complex and/or it is=20 done in a poorly thought out way. If the communication issue is not with messaging, then what is it? I'm of course not suggesting to design poorly thought out and = excessively complex messaging ;-) -->=20 --> > Thus we need to be quite careful in the specification of the --> > protocol requirements and the protocol itself. It is not OK --> > for us to say that if an individual PCC is irresponsible or=20 --> > stupid that is its problem, because such an implementation --> > would break the accessibility to the PCE for other 'normal'=20 --> > PCCs. --> > -->=20 --> On this aspect, I do agree ! -->=20 --> > Unless there are "standard" constraint back-off functions=20 --> > it is hard to conceive of a PCE guessing the correct back- --> > off for the PCC that issued the request. Note that the more=20 --> > "speculative paths" the PCE computes the more CPU it uses. -->=20 --> Speculative paths is definitely not an option considering the=20 --> number of permutations ... we would unavoidably quickly fall --> into some NP-Complete issues ;-) ... This is why the suggestion=20 --> is made to start some discussion on the hierarchical relaxation=20 --> policy. Note that it does not have to be awfully complex ... Here we have many things said in few words. I know, because I can identify numerous points for both agreement and disagreement. :-) The issue with permutations (and NP-complete issues) is one part on which I think we agree. The notion that a hierarchical relaxation approach avoids this is one part on which I think we disagree. Finally, the "wish" that it does not have to be complex is quite interesting. The only way that it will not be complex, is if the actual decision making process is very simple in every case. The point of contention is the fact that - while it probably can be=20 very simple in most cases - it will almost certainly not be 1) the same in every case and 2) good enough in every case. Ah here I fully agree with you (last paragraph ;-)). The goal may not = be to design a solution that will address *all* cases and that will be = good in *all* cases.=20 As a system designer, I'd be very happy if the proposed solution solves = the vast majority of the issues in an simple way. When not appropriate, = just do not use it. Vendor implementations should be able to be flexible = enough so that the operator could choose when to use such approach. See = other similar examples with hierarchical BGP policy rules, ACLs, ...=20 =09 =09 If a different hierarchical relaxation policy might apply under different circumstances, then the complexity of the protocol is going to be greater than the combination of all "simple cases". If the approach is not "good enough", then a PCC is forced to fall back on the multiple messages approach. Net gain: ~zero. Indeed, we agree on the fact that we could make it awfully complex and = consequently not practically usable. I could also come up with many such = examples ... Conversely, one could easily come up with = *real*life*use*of*TE*scenario where such approach would be quite useful. = *Again*, think of how Service Providers use TE today ... Let me give you = a simple example here (which by the way would cover a good % of current = needs): Packet LSPs, Two constraints: affinity=3DRED and bandwidth=3D10 The set of constraints cannot be fully satisfied because of resource = contention. Case A: The PCC sends multiple requests until a path can be found. Case B: The PCC sends one request (affinity=3DRED, bandwidth=3D10) and = specifies to first relax the affinity, then find the closest bandwidth = match. Note that a different policy may be adopted different LSP types. With such a simple example, you can easily see the benefit of B- -> Reduced PCE processing (delay and service time) -> Cut-down the number of transactions -> Simple constraint relaxation rule =3D> consequently reduced path computation delay Again, I'm not claiming that all problems could be solved this way and = that an operator should/could always use such hierarchical constraints = approach but there are many circumstances whereby such approach would be = IMO highly valuable. Of course, I'll wait for service providers to confirm that statement. -->=20 --> > So we must keep good control on this. It is a --> > computational myth that it is possible to relax different =20 --> > constraints on a --> > single computational pass. -->=20 --> Ah no ... there are several constraints for which=20 --> constraint can be relaxed and closest match can be=20 --> found in on-go. -->=20 --> That said, even if it were not the case, the solution=20 --> would still be valuable to cut-down the communication=20 --> overhead and amount of processing signaling be the=20 --> PCE's scheduler. -->=20 --> > In fact, the question "where did my computation fail" --> > is notoriously impossible to answer except with the =20 --> > response "in the network". --> > --> > Thus we should give full control to the PCC, and let=20 --> > the PCE choose to supply less information if it thinks =20 --> > that the PCC is asking too much. This control includes: --> > --> > a. The ability to say "this or nothing" --> > b. The ability to say "tell me what constraints I --> > might relax to get a path" --> > c. The ability to say "give me n alternate paths with=20 --> > with your choice of relaxed constraints" (c. is=20 --> > like b but with the paths supplied, and it is=20 --> > important to control the number) --> > d. A way to state which constraints may be relaxed=20 --> > absolutely (this is easy) --> > e. A way to replace one constraint supplied by the =20 --> > PCC with another also supplied by the PCC --> > f. A way to specify an ordering for relaxation in=20 --> > recomputation attempts. --> > --> > My feeling is that e might be satisfied in the protocol =20 --> > simply by listing the same object multiple times. But f --> > is very messy. As soon as I have a few constraints and=20 --> > I am willing to relax each of them by degrees I have a --> > very complex relaxation problem to express. -->=20 --> Well not so sure ... Let's wait for the meeting in Paris to=20 --> have an open discussion. I'd be happy to provide some ideas. --> Actually one could point out that such constraint relaxation=20 --> are used TODAY in operational networks (with CSPF). One could point that out, if one wants to show that having=20 a PCC make separate requests is the right way to go. I was under the impression you were arguing the opposition point of view. In the CSPF case you identify, the Traffic Engineer is both a PCC and a PCE and - with respect to the relaxation mode, it is much more likely to act like a PCC than a PCE. In other words, given a requirement for TE tunnel routing, it will=20 most likely complete a computation based on a single set of constraints and - if that fails - it may elect to relax the path requirements and try again with different constraints. But this is the whole point. When the PCE is co-located this can be = done without introducing substantial delays ... Conversely, think of a = PCE receiving a burst of requests from tens of PCCs after a network = failure ... this is precisely one of the aspects that I want to = optimize. This is essentially PCC behavior. Pushing this behavior into the PCE saves on external messaging overhead, but at a huge cost in complexity. Now, instead of having a self-contained entity (the PCC) deciding how next to proceed in getting a=20 Path (should any attempt fail), it must communicate a decision=20 making process to a delegate (the PCE) for every Path request - irrespective of whether or not that Path Request would fail. Unless the decision making options are very limited, this must impose a higher level of processing on the PCE just to decode, store and - eventually - act on the decision making process. I doubt that the communication overhead is the bottle-neck for PCE-PCC transactions, or the network over which they transpire. I also strongly suspect that deployments will tend toward more PCCs than PCEs, so - assuming that (for example) there are ten times as many PCCs as PCEs - what is the advantage gained by pushing the work of 1,000 PCCs onto 100 PCEs,=20 =09 no no ... we do not push the work of 1,000 PCCs onto 100 PCEs ... by = supporting such constraint relaxation approach you drastically reduce = the processing load on PCEs. Jumping to the end of this email (considering the text provided above). especially if you=20 assume that most path requests will be satisfied prior to a PCC=20 traversal of the decision tree. -->=20 --> > --> > This is a problem that it is very easy for the PCC to =20 --> > handle by issuing successive requests, but very hard for=20 --> > the PCC to communicate to the PCE in a single request. -->=20 --> I do not think that it is hard for the PCC to communicate=20 --> to the PCE in a single request. You miss the point. If "communication" was easy, you wouldn't have started this discussion, and I wouldn't be continuing it. :-) Let's say that PCC X follows this scheme for one subset of its requests: scheme (a) Request a path with constraints A, B and C. On failure for A, request a path with constraint A1 that still satisfies B and C. On failure for A1, B or C, fail. To cut down on communication overhead, we could communicate this decision making policy to the PCE and make a single request that either succeeds or fails according to this policy. But this PCC (or another) also has a decision making schemes as follows for other types of services: scheme (b) Request a path with constraint A, C and D. On failure for C, request a path with constraints A and D only On failure for A or D, fail. scheme (c) Request a path with constraints B, C and D. On failure (for B, C or D) request an unconstrained shortest path. ... and so on ... Hence, given any arbitrary number of potential constraints, the number of possible decision making policies we need to define is clearly combinatorial (i.e. - NP) in the number of possible constraints (and possible relaxations of each). However, if we do not cover all of the possibilities, then we constrain the services that our customers can sell, their ability to differentiate themselves from their competitors and even the service pricing structures that are available to their customers in turn. To eliminate this concern, all we need to do is define a language for describing a decision making process. Done much work in the area of defining languages like this? :-) -->=20 --> > --> > So, I'd like to see some text from SPs on this subject=20 --> > before we add anything to the requirements I-D. --> > -->=20 --> I think that the DT is working on it. So, this is confusing. Are you saying that it's out of the hands of the WG because the authors are taking this work on anyway? /Chair Hat/ I just meant that the DT was working on the new revision of = draft-ietf-pce-comm-protocol-gen-reqs with the intention to cover that = aspect for WG input (this new rev has now been published). As you know, = by definition, a Working Group document is owned by the Working Group.=20 Your comments are of course more than welcome.=20 /Chair hat removed/ We may just want to sit down in Paris and discuss more on this if you = will. JP. -->=20 --> Cheers, -->=20 --> JP. -->=20 --> > Cheers, --> > Adrian --> > --> > --- [SNIP] --- =09 ________________________________ =09 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce =09 ------_=_NextPart_001_01C590F5.2A8478DD Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Igor, all
 
Please see inline for some=20 comments,

De : pce-bounces@lists.ietf.org = [mailto:pce-bounces@lists.ietf.org] De la part de Igor=20 Bryskin
Envoy=E9 : mardi 19 juillet 2005 = 17:41
=C0 :=20 JP Vasseur; Gray, Eric
Cc : = pce@ietf.org
Objet :=20 Re: [Pce] Requirement for less-constrained=20 pathindraft-ietf-pce-comm-protocol-gen-reqs-00.txt

JP.
 
As I have indicated earlier I don't = believe that=20 the complexity associated with signaling of constraint relaxation = strategy=20 justifies the results.
[JLLR] Please don't make things more complex than = they are in=20 practical operational cases...
 
A=20 practical case, that is deployed btw, is SRLG exclusion in FRR = bypass=20 tunnel path computation:
The=20 operator wants a path that excludes a set of SRLGs, and if this path = cannot be=20 found he wants a path that excludes the maximum number of = SRLGs in=20 this set. Unfortunately the PCC cannot guess this best relaxed set=20 and for instance if #SRLG =3D 4 this may lead  to 16 = requests=20 :-(
Conversely the PCE can run an algorithm that = will=20 return a path maximizing the number of excluded = SRLGs.
This=20 is a simple case where less constrained paths are highly=20 valuable.
 
Another simple case is "bounded delay = bandwidth=20 constrained" path computation:
If the=20 path cannot be found, I want the PCE to provide me a bandwidth = constrained path=20 with a relaxed delay bound
or a=20 delay bounded path with a relaxed bandwidth = constraint. Unfortunately I=20 cannot guess these relaxed values, and it sound = really
valuable, and not so complex (there are = highly=20 efficient heuristics) for the PCE to perform such=20 relaxation....
 
 Most of the constraints are = non-boolean,=20 and it is difficult IMO to provide a simple yet flexible way for a PCC = to=20 articulate the desired way of relaxation wrt each of the=20 constraints.
[JLLR] In practical operational cases = you won't have a=20 lot of constraints, so this sounds quite simple to articulate such=20 relaxation (one could use a set of bits=20 vectors).
 
  And what if the constraints are = not=20 independent? For instance, what if a PCC wants to get best tradeoff = of=20 several constraints ?
[JLLR] We could also find a simple way to = express these=20 cases (again with a vector encoding dependent constraints to be=20 relaxed...)
My suggestion is to start with allowing = for PCC to=20 specify in a single request a set of mandatory constraints and an = ordered list=20 of sets of relaxable constraints: first, use the first set in the list = (+=20 mandatory, of course), if path computation fails - use the second one = and so=20 forth.
[JLLR] Do you=20 include constraint values or just identify constraints to be relaxed?=20
If the=20 latter, then we fully agree.
 
 This is a much simpler way of = doing the=20 constraint relaxation and could be just good enough, = although it makes=20 the size of requests and response larger.
[JLLR] Simpler = than which=20 way?? 
 
By the way, do you remember that = sometime ago=20 I suggested to design the PCC-PCE protocol in a such a way where each=20 request/response is a BASIC style program
  that could be interpreted =  by both=20 PCC and PCE? The intention was to provide a very flexible way for a PCE = to=20 describe its capabilities and introduce new ones, and for PCC to take = the most=20 of the PCE and specify what exactly it wants from the requested = path=20 computation (what constraints and optimization criterias to be used = and=20 how)
 
[JLLR] 
Note that this has already been proposed by = Kireeti two=20 years ago to pass constraints in = RSVP
(see=20 http://www.watersprings.org/pub/id/draft-kompella-mpls-rsvp-cons= traints-01.txt)
I have major concerns regarding the = complexity of=20 this approach. Please note = that the=20 PCE may run quite complex algorithms (e.g. multi-constraint heuristic=20 algorithms, or, yet to be added in the charter, steiner tree heuristics, = requiring CPU intensive computation...). Do you also assume passing the = code for=20 such complex algorithms??? This = would=20 drastically complexify PCC = operations....
 
It would be very easy to = support the=20 constraint relaxation strategies no matter how complex they are = :=3D)
[JLLR] Ah yes of = course if you=20 put a lot of complexity on the PCC=20 :-(
 
I agree with you that this would provide = a huge=20 flexibility in the way to express = constraints,
but think about the standardization = effort that=20 this would imply (unless you want to rely on Java applets=20 :-))
 
Best Regards,
 
JL
 
Cheers,
Igor
----- Original Message -----
From:=20 JP = Vasseur=20
Sent: Tuesday, July 19, 2005 = 9:47=20 AM
Subject: Re: [Pce] Requirement = for=20 less-constrained path = indraft-ietf-pce-comm-protocol-gen-reqs-00.txt

Hi Eric,=20

On Jul 18, 2005, at 3:57 PM, Gray, Eric wrote:
JP,

    From your = earlier=20 response, I see that you're aiming 
at the "greater of two evil" = solutions.  Tch, tch, tch!!

    Please see=20 below...

--> -----Original Message-----
--> From: JP Vasseur [mailto:jvasseur@cisco.com]
--> Sent: Thursday, July 14, 2005 9:19 = PM
--> To: Adrian Farrel
--> Cc: Gray, Eric; pce@ietf.org
--> Subject: Re: [Pce] Requirement for = less-constrained path
-->=20 indraft-ietf-pce-comm-protocol-gen-reqs-00.txt
--> 
--> 
--> 
--> On Jul 14, 2005, at 12:26 PM, = Adrian Farrel=20 wrote:
--> 
--> > I want to pitch in on this = thread=20 because I think (I) see 
--> > where both JP and Eric are = coming from.=20 JP's proposals have
--> > the potential to = significantly reduce=20 the PCE processing 
--> > and cut down number of = PCC-PCE=20 transactions, but they also
--> > have the ability to massively = increase=20 the processing and  
--> > the size of the PCC-PCE=20 transactions.
--> >
--> 
--> that said, it it pretty = straightforward to=20 see that the benefits  
--> undoubtedly outweigh the = drawbacks. The=20 request processing is  
--> definitely negligible compared to = the=20 communication overhead.

This is the point of obvious = disagreement.


Good so at least we agree on the disagreement ;-)

--> Actually, it could be shown that = the non=20 support of such capability  
--> would have a drastic scalability = impact on=20 the solution especially  
--> upon resource contention.

Only if you assume that communication is = the=20 bottleneck.

Just try to decompose the various steps occurring during a = path=20 computation (request/reply) especially when the constraints cannot be = fully=20 satisfied:
1) Path computation request sent to the PCE
2) PCE processing which includes:
    - queueing delay (PCE scheduler)
    - service time (PCE scheduler)
3) Path computation reply sent to the PCE.

Then repeat such cycle until a path is successfully = computed.

Now consider the two cases where:
A- The PCC has to send multiple requests trying to guess the set = of=20 constraints that could lead to a successful path computation.
B- The PCC specifies a set of rules and the PCE tries to find a = path by=20 means of a single request

A few important facts:

- In case of A, when the constraint is not a boolean (e.g. = bandwidth), it=20 is really a guess and even an approach based = on dichotomy would=20 unavoidably lead to a non negligible number of cycles. 
- Some path computation algorithms have the capability to relax=20 constraints "on the fly" thus saving CPU cycles compared to serialized = path=20 computations. 
- Without entering into some gory details about network analysis, = queueing systems and implementation-specific algorithms, try to = decompose the=20 steps 1), 2) and 3), and you'll easily identify where the bottlenecks = are when=20 comparing the two approaches (especially 2).
- The set of rules does not have = to be=20 complex (see an example below) and more importantly does not have = to be=20 used when inappropriate

Reality is that messaging only becomes a = bottleneck=20 if
message processing is excessively complex = and/or it=20 is 
done in a poorly thought out way. If the=20 communication
issue is not with messaging, then what is = it?


I'm of course not suggesting to design poorly thought out and = excessively=20 complex messaging ;-)

--> 
--> > Thus we need to be quite = careful in the=20 specification of the
--> > protocol requirements and the = protocol=20 itself. It is not OK
--> > for us to say that if an = individual PCC=20 is irresponsible or 
--> > stupid that is its problem, = because=20 such an implementation
--> > would break the accessibility = to the=20 PCE for other 'normal' 
--> > PCCs.
--> >
--> 
--> On this aspect, I do agree !
--> 
--> > Unless there are "standard" = constraint=20 back-off functions 
--> > it is hard to conceive of a = PCE=20 guessing the correct back-
--> > off for the PCC that issued = the=20 request. Note that the more 
--> > "speculative paths" the PCE = computes=20 the more CPU it uses.
--> 
--> Speculative paths is definitely = not an=20 option considering the 
--> number of permutations ... we = would=20 unavoidably quickly fall
--> into some NP-Complete issues ;-) = ... This is=20 why the suggestion 
--> is made to start some discussion = on the=20 hierarchical relaxation 
--> policy. Note that it does not have = to be=20 awfully complex ...

Here we have many things said in few = words. I know,=20 because I can
identify numerous points for both = agreement and=20 disagreement.  = :-)

The issue with permutations (and = NP-complete=20 issues) is one part
on which I think we agree.

The notion that a hierarchical relaxation = approach=20 avoids this is
one part on which I think we = disagree.

Finally, the "wish" that it does not have = to be=20 complex is quite
interesting.  The only way that it = will not be=20 complex, is if the
actual decision making process is very = simple in=20 every case. The
point of contention is the fact that - = while it=20 probably can be 
very simple in most cases - it will = almost=20 certainly not be 1) the
same in every case and 2) good enough in = every=20 case.


Ah here I fully agree with you (last paragraph ;-)). The goal may = not be=20 to design a solution that will address *all* cases and that will be = good in=20 *all* cases. 
As a system designer, I'd be very happy if = the=20 proposed solution solves the vast majority of the issues in an simple = way.=20 When not appropriate, just do not use it. Vendor implementations = should be=20 able to be flexible enough so that the operator could choose when to = use such=20 approach. See other similar examples with hierarchical BGP policy = rules, ACLs,=20 ... 

If a different hierarchical relaxation = policy might=20 apply under
different circumstances, then the = complexity of the=20 protocol is
going to be greater than the combination = of all=20 "simple cases".

If the approach is not "good enough", = then a PCC is=20 forced to
fall back on the multiple messages = approach.  Net gain: ~zero.


Indeed, we agree on the fact that we could make it awfully = complex=20 and consequently not practically usable. I could also come up = with many=20 such examples ... Conversely, one could easily come up with=20 *real*life*use*of*TE*scenario where such approach would be quite = useful.=20 *Again*, think of how Service Providers use TE today ... Let me give = you a=20 simple example here (which by the way would cover a good % of current=20 needs):

Packet LSPs,
Two constraints: affinity=3DRED and bandwidth=3D10
The set of constraints cannot be fully satisfied because of = resource=20 contention.

Case A: The PCC sends multiple requests until a path can be = found.
Case B: The PCC sends one request (affinity=3DRED, = bandwidth=3D10) and=20 specifies to first relax the affinity, then find the = closest bandwidth=20 match. Note that a different policy may be adopted different LSP = types.

With such a simple example, you can easily see the benefit = of=20 B-
-> Reduced PCE processing (delay and service time)
-> Cut-down the number of transactions
-> Simple constraint relaxation rule

=3D> consequently reduced path computation delay

Again, I'm not claiming that all problems could be solved this = way and=20 that an operator should/could always use such hierarchical = constraints=20 approach but there are many circumstances whereby such approach would = be IMO=20 highly valuable.

Of course, I'll wait for service providers to confirm that=20 statement.

--> 
--> > So we must keep good control = on this.=20 It is a
--> > computational myth that it is = possible=20 to relax different  
--> > constraints on a
--> > single computational = pass.
--> 
--> Ah no ... there are several = constraints for=20 which 
--> constraint can be relaxed and = closest match=20 can be 
--> found in on-go.
--> 
--> That said, even if it were not the = case, the=20 solution 
--> would still be valuable to = cut-down the=20 communication 
--> overhead and amount of processing = signaling=20 be the 
--> PCE's scheduler.
--> 
--> > In fact, the question "where = did my=20 computation fail"
--> > is notoriously impossible to = answer=20 except with the  =  
--> > response "in the = network".
--> >
--> > Thus we should give full = control to the=20 PCC, and let 
--> > the PCE choose to supply less = information if it thinks =20  
--> > that the PCC is asking too = much. This=20 control includes:
--> >
--> > a. The ability to say "this = or=20 nothing"
--> > b. The ability to say "tell = me what=20 constraints I
--> > =20   might relax to get a path"
--> > c. The ability to say "give = me n=20 alternate paths with 
--> > =20   with your choice of relaxed constraints" (c. is 
--> > =20   like b but with the paths supplied, and it is 
--> > =20   important to control the number)
--> > d. A way to state which = constraints may=20 be relaxed 
--> > =20   absolutely (this is easy)
--> > e. A way to replace one = constraint=20 supplied by the  
--> > =20   PCC with another also supplied by the PCC
--> > f. A way to specify an = ordering for=20 relaxation in 
--> > =20   recomputation attempts.
--> >
--> > My feeling is that e might be = satisfied=20 in the protocol  
--> > simply by listing the same = object=20 multiple times. But f
--> > is very messy. As soon as I = have a few=20 constraints and 
--> > I am willing to relax each of = them by=20 degrees I have a
--> > very complex relaxation = problem to=20 express.
--> 
--> Well not so sure ... Let's wait = for the=20 meeting in Paris to 
--> have an open discussion. I'd be = happy to=20 provide some ideas.
--> Actually one could point out that = such=20 constraint relaxation 
--> are used TODAY in operational = networks (with=20 CSPF).

One could point that out, if one wants to = show that=20 having 
a PCC make separate requests is the right = way to=20 go. I was
under the impression you were arguing the = opposition point
of view.

In the CSPF case you identify, the = Traffic Engineer=20 is both
a PCC and a PCE and - with respect to the = relaxation mode,
it is much more likely to act like a PCC = than a=20 PCE. In other
words, given a requirement for TE tunnel = routing,=20 it will 
most likely complete a computation based = on a=20 single set of
constraints and - if that fails - it may = elect to=20 relax the
path requirements and try again with = different=20 constraints.


But this is the whole point. When the PCE is co-located this can = be done=20 without introducing substantial delays ... Conversely, think of a PCE=20 receiving a burst of requests from tens of PCCs after a network = failure ...=20 this is precisely one of the aspects that I want to = optimize.

This is essentially PCC behavior. Pushing = this=20 behavior into
the PCE saves on external messaging = overhead, but=20 at a huge
cost in complexity.  Now, instead of having a = self-contained
entity (the PCC) deciding how next to = proceed in=20 getting a 
Path (should any attempt fail), it must = communicate=20 a decision 
making process to a delegate (the PCE) = for every=20 Path request
- irrespective of whether or not that = Path Request=20 would fail.

Unless the decision making options are = very=20 limited, this must
impose a higher level of processing on = the PCE just=20 to decode,
store and - eventually - act on the = decision making=20 process.

I doubt that the communication overhead = is the=20 bottle-neck for
PCE-PCC transactions, or the network over = which=20 they transpire.
I also strongly suspect that deployments = will tend=20 toward more
PCCs than PCEs, so - assuming that (for = example)=20 there are ten
times as many PCCs as PCEs - what is the = advantage=20 gained by
pushing the work of 1,000 PCCs onto 100 = PCEs,=20

no no ... we do not push the work of 1,000 PCCs onto 100 PCEs ... = by=20 supporting such constraint relaxation approach you drastically reduce = the=20 processing load on PCEs.

Jumping to the end of this email (considering the text provided=20 above).

especially if you 
assume that most path requests will be = satisfied=20 prior to a PCC 
traversal of the decision tree.

--> 
--> >
--> > This is a problem that it is = very easy=20 for the PCC to  
--> > handle by issuing successive = requests,=20 but very hard for 
--> > the PCC to communicate to the = PCE in a=20 single request.
--> 
--> I do not think that it is hard for = the PCC=20 to communicate 
--> to the PCE in a single = request.

You miss the point.

If "communication" was easy, you wouldn't = have=20 started this
discussion, and I wouldn't be continuing = it.  :-)

Let's say that PCC X follows this scheme = for one=20 subset of its
requests:

scheme (a)
    Request a = path with=20 constraints A, B and C.
    On failure = for A,=20 request a path with constraint A1 that
        = still=20 satisfies B and C.
    On failure = for A1, B=20 or C, fail.

To cut down on communication overhead, we = could=20 communicate
this decision making policy to the PCE = and make a=20 single
request that either succeeds or fails = according to=20 this policy.

But this PCC (or another) also has a = decision=20 making schemes as
follows for other types of = services:

scheme (b)
    Request a = path with=20 constraint A, C and D.
    On failure = for C,=20 request a path with constraints A and D
       =20 only
    On failure = for A or D,=20 fail.

scheme (c)
    Request a = path with=20 constraints B, C and D.
    On failure = (for B, C=20 or D) request an unconstrained shortest
       =20 path.

... and so on ...

Hence, given any arbitrary number of = potential=20 constraints, the
number of possible decision making = policies we need=20 to define
is clearly combinatorial (i.e. - NP) in = the number=20 of possible
constraints (and possible relaxations of=20 each).

However, if we do not cover all of the=20 possibilities, then we
constrain the services that our customers = can sell,=20 their ability
to differentiate themselves from their = competitors=20 and even the
service pricing structures that are = available to=20 their customers
in turn.

To eliminate this concern, all we need to = do is=20 define a language
for describing a decision making = process.  Done much work in = the
area of defining languages like = this?  :-)

--> 
--> >
--> > So, I'd like to see some text = from SPs=20 on this subject 
--> > before we add anything to the = requirements I-D.
--> >
--> 
--> I think that the DT is working on = it.

So, this is confusing. Are you saying = that it's out=20 of the hands
of the WG because the authors are taking = this work=20 on anyway?


/Chair Hat/

I just meant that the DT was working on the new revision of=20 draft-ietf-pce-comm-protocol-gen-reqs with the intention to cover that = aspect=20 for WG input (this new rev has now been published). As you know, by=20 definition, a Working Group document is owned by the Working=20 Group. 

Your comments are of course more than welcome. 

/Chair hat removed/

We may just want to sit down in Paris and discuss more on this if = you=20 will.

JP.

--> 
--> Cheers,
--> 
--> JP.
--> 
--> > Cheers,
--> > Adrian
--> >
--> > --- [SNIP] ---

_______________________________________________
Pce mailing=20 = list
Pce@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce<= BR>
------_=_NextPart_001_01C590F5.2A8478DD-- --===============1089100328== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============1089100328==-- From pce-bounces@lists.ietf.org Mon Jul 25 07:41:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx1LI-0001WI-Ga; Mon, 25 Jul 2005 07:41:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx18j-0007bu-Pd for pce@megatron.ietf.org; Mon, 25 Jul 2005 07:28:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09025 for ; Mon, 25 Jul 2005 07:28:56 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dx1dX-0006Es-NE for pce@ietf.org; Mon, 25 Jul 2005 08:00:50 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id j6PBSgYH025806; Mon, 25 Jul 2005 07:28:42 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA29474; Mon, 25 Jul 2005 07:28:42 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id ; Mon, 25 Jul 2005 07:28:41 -0400 Message-ID: <313680C9A886D511A06000204840E1CF0C885D44@whq-msgusr-02.pit.comms.marconi.com> From: "Gray, Eric" To: "'LE ROUX Jean-Louis RD-CORE-LAN'" , Igor Bryskin , JP Vasseur , "Gray, Eric" Subject: RE: [Pce] Requirement for less-constrained pathindraft-ietf-pce-c omm-protocol-gen-reqs-00.txt Date: Mon, 25 Jul 2005 07:28:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 2.9 (++) X-Scan-Signature: 62b5971f410f8a9411789cf7221d7b70 X-Mailman-Approved-At: Mon, 25 Jul 2005 07:41:55 -0400 Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0632900818==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0632900818== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5910B.FF79537A" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C5910B.FF79537A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I think the point here is that there was absolutely no consensus to = include this in the PCE protocol requirements. =20 One of the WG chairs - JP - asked if this should be included. A highly polar discussion followed in which several people weighed in against doing so. =20 The fact that it may seem like a good idea to the author(s) is = insufficient reason to put it in the draft, once the draft has become a working group document. =20 Therefore, lacking overwhelming indications that a consensus does exist = to put it in the working group's draft, the author(s) should remove it. =20 -- Eric -----Original Message----- From: LE ROUX Jean-Louis RD-CORE-LAN [mailto:jeanlouis.leroux@francetelecom.com] Sent: Monday, July 25, 2005 4:45 AM To: Igor Bryskin; JP Vasseur; Gray, Eric Cc: pce@ietf.org Subject: RE: [Pce] Requirement for less-constrained pathindraft-ietf-pce-comm-protocol-gen-reqs-00.txt Hi Igor, all =20 Please see inline for some comments, _____ =20 De : pce-bounces@lists.ietf.org [mailto:pce-bounces@lists.ietf.org] De = la part de Igor Bryskin Envoy=E9 : mardi 19 juillet 2005 17:41 =C0 : JP Vasseur; Gray, Eric Cc : pce@ietf.org Objet : Re: [Pce] Requirement for less-constrained pathindraft-ietf-pce-comm-protocol-gen-reqs-00.txt JP. =20 As I have indicated earlier I don't believe that the complexity = associated with signaling of constraint relaxation strategy justifies the results. = [JLLR] Please don't make things more complex than they are in practical operational cases... =20 A practical case, that is deployed btw, is SRLG exclusion in FRR bypass tunnel path computation: The operator wants a path that excludes a set of SRLGs, and if this = path cannot be found he wants a path that excludes the maximum number of = SRLGs in this set. Unfortunately the PCC cannot guess this best relaxed set and = for instance if #SRLG =3D 4 this may lead to 16 requests :-( Conversely the PCE can run an algorithm that will return a path = maximizing the number of excluded SRLGs. This is a simple case where less constrained paths are highly valuable. =20 Another simple case is "bounded delay bandwidth constrained" path computation: If the path cannot be found, I want the PCE to provide me a bandwidth constrained path with a relaxed delay bound or a delay bounded path with a relaxed bandwidth constraint. = Unfortunately I cannot guess these relaxed values, and it sound really valuable, and not so complex (there are highly efficient heuristics) = for the PCE to perform such relaxation.... =20 Most of the constraints are non-boolean, and it is difficult IMO to = provide a simple yet flexible way for a PCC to articulate the desired way of relaxation wrt each of the constraints. [JLLR] In practical operational cases you won't have a lot of = constraints, so this sounds quite simple to articulate such relaxation (one could = use a set of bits vectors). =20 And what if the constraints are not independent? For instance, what = if a PCC wants to get best tradeoff of several constraints ?=20 [JLLR] We could also find a simple way to express these cases (again = with a vector encoding dependent constraints to be relaxed...) My suggestion is to start with allowing for PCC to specify in a single request a set of mandatory constraints and an ordered list of sets of relaxable constraints: first, use the first set in the list (+ = mandatory, of course), if path computation fails - use the second one and so forth.=20 [JLLR] Do you include constraint values or just identify constraints to = be relaxed?=20 If the latter, then we fully agree. =20 This is a much simpler way of doing the constraint relaxation and = could be just good enough, although it makes the size of requests and response larger. [JLLR] Simpler than which way??=20 =20 By the way, do you remember that sometime ago I suggested to design the PCC-PCE protocol in a such a way where each request/response is a BASIC style program that could be interpreted by both PCC and PCE? The intention was to provide a very flexible way for a PCE to describe its capabilities and introduce new ones, and for PCC to take the most of the PCE and specify = what exactly it wants from the requested path computation (what constraints = and optimization criterias to be used and how) =20 [JLLR]=20 Note that this has already been proposed by Kireeti two years ago to = pass constraints in RSVP (see http://www.watersprings.org/pub/id/draft-kompella-mpls-rsvp-constraints-= 01.t xt) I have major concerns regarding the complexity of this approach. Please = note that the PCE may run quite complex algorithms (e.g. multi-constraint heuristic algorithms, or, yet to be added in the charter, steiner tree heuristics, requiring CPU intensive computation...). Do you also assume passing the code for such complex algorithms??? This would drastically complexify PCC operations.... =20 It would be very easy to support the constraint relaxation strategies = no matter how complex they are :=3D) [JLLR] Ah yes of course if you put a lot of complexity on the PCC :-( =20 I agree with you that this would provide a huge flexibility in the way = to express constraints, but think about the standardization effort that this would imply = (unless you want to rely on Java applets :-)) =20 Best Regards, =20 JL =20 Cheers, Igor ----- Original Message -----=20 From: JP Vasseur =20 To: Gray, Eric =20 Cc: pce@ietf.org =20 Sent: Tuesday, July 19, 2005 9:47 AM Subject: Re: [Pce] Requirement for less-constrained path indraft-ietf-pce-comm-protocol-gen-reqs-00.txt Hi Eric,=20 On Jul 18, 2005, at 3:57 PM, Gray, Eric wrote: JP, From your earlier response, I see that you're aiming=20 at the "greater of two evil" solutions. Tch, tch, tch!! Please see below... --> -----Original Message----- --> From: JP Vasseur [ mailto:jvasseur@cisco.com = ] --> Sent: Thursday, July 14, 2005 9:19 PM --> To: Adrian Farrel --> Cc: Gray, Eric; pce@ietf.org =20 --> Subject: Re: [Pce] Requirement for less-constrained path --> indraft-ietf-pce-comm-protocol-gen-reqs-00.txt -->=20 -->=20 -->=20 --> On Jul 14, 2005, at 12:26 PM, Adrian Farrel wrote: -->=20 --> > I want to pitch in on this thread because I think (I) see=20 --> > where both JP and Eric are coming from. JP's proposals have --> > the potential to significantly reduce the PCE processing=20 --> > and cut down number of PCC-PCE transactions, but they also --> > have the ability to massively increase the processing and =20 --> > the size of the PCC-PCE transactions. --> > -->=20 --> that said, it it pretty straightforward to see that the benefits =20 --> undoubtedly outweigh the drawbacks. The request processing is =20 --> definitely negligible compared to the communication overhead. This is the point of obvious disagreement. Good so at least we agree on the disagreement ;-) --> Actually, it could be shown that the non support of such capability = =20 --> would have a drastic scalability impact on the solution especially = --> upon resource contention. Only if you assume that communication is the bottleneck. Just try to decompose the various steps occurring during a path = computation (request/reply) especially when the constraints cannot be fully = satisfied: 1) Path computation request sent to the PCE 2) PCE processing which includes: - queueing delay (PCE scheduler) - service time (PCE scheduler) 3) Path computation reply sent to the PCE. Then repeat such cycle until a path is successfully computed. Now consider the two cases where: A- The PCC has to send multiple requests trying to guess the set of constraints that could lead to a successful path computation. B- The PCC specifies a set of rules and the PCE tries to find a path by means of a single request A few important facts: - In case of A, when the constraint is not a boolean (e.g. bandwidth), = it is really a guess and even an approach based on dichotomy would = unavoidably lead to a non negligible number of cycles.=20 - Some path computation algorithms have the capability to relax = constraints "on the fly" thus saving CPU cycles compared to serialized path computations.=20 - Without entering into some gory details about network analysis, = queueing systems and implementation-specific algorithms, try to decompose the = steps 1), 2) and 3), and you'll easily identify where the bottlenecks are = when comparing the two approaches (especially 2). - The set of rules does not have to be complex (see an example below) = and more importantly does not have to be used when inappropriate Reality is that messaging only becomes a bottleneck if message processing is excessively complex and/or it is=20 done in a poorly thought out way. If the communication issue is not with messaging, then what is it? I'm of course not suggesting to design poorly thought out and = excessively complex messaging ;-) -->=20 --> > Thus we need to be quite careful in the specification of the --> > protocol requirements and the protocol itself. It is not OK --> > for us to say that if an individual PCC is irresponsible or=20 --> > stupid that is its problem, because such an implementation --> > would break the accessibility to the PCE for other 'normal'=20 --> > PCCs. --> > -->=20 --> On this aspect, I do agree ! -->=20 --> > Unless there are "standard" constraint back-off functions=20 --> > it is hard to conceive of a PCE guessing the correct back- --> > off for the PCC that issued the request. Note that the more=20 --> > "speculative paths" the PCE computes the more CPU it uses. -->=20 --> Speculative paths is definitely not an option considering the=20 --> number of permutations ... we would unavoidably quickly fall --> into some NP-Complete issues ;-) ... This is why the suggestion=20 --> is made to start some discussion on the hierarchical relaxation=20 --> policy. Note that it does not have to be awfully complex ... Here we have many things said in few words. I know, because I can identify numerous points for both agreement and disagreement. :-) The issue with permutations (and NP-complete issues) is one part on which I think we agree. The notion that a hierarchical relaxation approach avoids this is one part on which I think we disagree. Finally, the "wish" that it does not have to be complex is quite interesting. The only way that it will not be complex, is if the actual decision making process is very simple in every case. The point of contention is the fact that - while it probably can be=20 very simple in most cases - it will almost certainly not be 1) the same in every case and 2) good enough in every case. Ah here I fully agree with you (last paragraph ;-)). The goal may not = be to design a solution that will address *all* cases and that will be good = in *all* cases.=20 As a system designer, I'd be very happy if the proposed solution solves = the vast majority of the issues in an simple way. When not appropriate, = just do not use it. Vendor implementations should be able to be flexible enough = so that the operator could choose when to use such approach. See other = similar examples with hierarchical BGP policy rules, ACLs, ...=20 If a different hierarchical relaxation policy might apply under different circumstances, then the complexity of the protocol is going to be greater than the combination of all "simple cases". If the approach is not "good enough", then a PCC is forced to fall back on the multiple messages approach. Net gain: ~zero. Indeed, we agree on the fact that we could make it awfully complex and consequently not practically usable. I could also come up with many = such examples ... Conversely, one could easily come up with *real*life*use*of*TE*scenario where such approach would be quite = useful. *Again*, think of how Service Providers use TE today ... Let me give = you a simple example here (which by the way would cover a good % of current needs): Packet LSPs, Two constraints: affinity=3DRED and bandwidth=3D10 The set of constraints cannot be fully satisfied because of resource contention. Case A: The PCC sends multiple requests until a path can be found. Case B: The PCC sends one request (affinity=3DRED, bandwidth=3D10) and = specifies to first relax the affinity, then find the closest bandwidth match. = Note that a different policy may be adopted different LSP types. With such a simple example, you can easily see the benefit of B- -> Reduced PCE processing (delay and service time) -> Cut-down the number of transactions -> Simple constraint relaxation rule =3D> consequently reduced path computation delay Again, I'm not claiming that all problems could be solved this way and = that an operator should/could always use such hierarchical constraints = approach but there are many circumstances whereby such approach would be IMO = highly valuable. Of course, I'll wait for service providers to confirm that statement. -->=20 --> > So we must keep good control on this. It is a --> > computational myth that it is possible to relax different =20 --> > constraints on a --> > single computational pass. -->=20 --> Ah no ... there are several constraints for which=20 --> constraint can be relaxed and closest match can be=20 --> found in on-go. -->=20 --> That said, even if it were not the case, the solution=20 --> would still be valuable to cut-down the communication=20 --> overhead and amount of processing signaling be the=20 --> PCE's scheduler. -->=20 --> > In fact, the question "where did my computation fail" --> > is notoriously impossible to answer except with the =20 --> > response "in the network". --> > --> > Thus we should give full control to the PCC, and let=20 --> > the PCE choose to supply less information if it thinks =20 --> > that the PCC is asking too much. This control includes: --> > --> > a. The ability to say "this or nothing" --> > b. The ability to say "tell me what constraints I --> > might relax to get a path" --> > c. The ability to say "give me n alternate paths with=20 --> > with your choice of relaxed constraints" (c. is=20 --> > like b but with the paths supplied, and it is=20 --> > important to control the number) --> > d. A way to state which constraints may be relaxed=20 --> > absolutely (this is easy) --> > e. A way to replace one constraint supplied by the =20 --> > PCC with another also supplied by the PCC --> > f. A way to specify an ordering for relaxation in=20 --> > recomputation attempts. --> > --> > My feeling is that e might be satisfied in the protocol =20 --> > simply by listing the same object multiple times. But f --> > is very messy. As soon as I have a few constraints and=20 --> > I am willing to relax each of them by degrees I have a --> > very complex relaxation problem to express. -->=20 --> Well not so sure ... Let's wait for the meeting in Paris to=20 --> have an open discussion. I'd be happy to provide some ideas. --> Actually one could point out that such constraint relaxation=20 --> are used TODAY in operational networks (with CSPF). One could point that out, if one wants to show that having=20 a PCC make separate requests is the right way to go. I was under the impression you were arguing the opposition point of view. In the CSPF case you identify, the Traffic Engineer is both a PCC and a PCE and - with respect to the relaxation mode, it is much more likely to act like a PCC than a PCE. In other words, given a requirement for TE tunnel routing, it will=20 most likely complete a computation based on a single set of constraints and - if that fails - it may elect to relax the path requirements and try again with different constraints. But this is the whole point. When the PCE is co-located this can be = done without introducing substantial delays ... Conversely, think of a PCE receiving a burst of requests from tens of PCCs after a network failure = ... this is precisely one of the aspects that I want to optimize. This is essentially PCC behavior. Pushing this behavior into the PCE saves on external messaging overhead, but at a huge cost in complexity. Now, instead of having a self-contained entity (the PCC) deciding how next to proceed in getting a=20 Path (should any attempt fail), it must communicate a decision=20 making process to a delegate (the PCE) for every Path request - irrespective of whether or not that Path Request would fail. Unless the decision making options are very limited, this must impose a higher level of processing on the PCE just to decode, store and - eventually - act on the decision making process. I doubt that the communication overhead is the bottle-neck for PCE-PCC transactions, or the network over which they transpire. I also strongly suspect that deployments will tend toward more PCCs than PCEs, so - assuming that (for example) there are ten times as many PCCs as PCEs - what is the advantage gained by pushing the work of 1,000 PCCs onto 100 PCEs,=20 no no ... we do not push the work of 1,000 PCCs onto 100 PCEs ... by supporting such constraint relaxation approach you drastically reduce = the processing load on PCEs. Jumping to the end of this email (considering the text provided above). especially if you=20 assume that most path requests will be satisfied prior to a PCC=20 traversal of the decision tree. -->=20 --> > --> > This is a problem that it is very easy for the PCC to =20 --> > handle by issuing successive requests, but very hard for=20 --> > the PCC to communicate to the PCE in a single request. -->=20 --> I do not think that it is hard for the PCC to communicate=20 --> to the PCE in a single request. You miss the point. If "communication" was easy, you wouldn't have started this discussion, and I wouldn't be continuing it. :-) Let's say that PCC X follows this scheme for one subset of its requests: scheme (a) Request a path with constraints A, B and C. On failure for A, request a path with constraint A1 that still satisfies B and C. On failure for A1, B or C, fail. To cut down on communication overhead, we could communicate this decision making policy to the PCE and make a single request that either succeeds or fails according to this policy. But this PCC (or another) also has a decision making schemes as follows for other types of services: scheme (b) Request a path with constraint A, C and D. On failure for C, request a path with constraints A and D only On failure for A or D, fail. scheme (c) Request a path with constraints B, C and D. On failure (for B, C or D) request an unconstrained shortest path. ... and so on ... Hence, given any arbitrary number of potential constraints, the number of possible decision making policies we need to define is clearly combinatorial (i.e. - NP) in the number of possible constraints (and possible relaxations of each). However, if we do not cover all of the possibilities, then we constrain the services that our customers can sell, their ability to differentiate themselves from their competitors and even the service pricing structures that are available to their customers in turn. To eliminate this concern, all we need to do is define a language for describing a decision making process. Done much work in the area of defining languages like this? :-) -->=20 --> > --> > So, I'd like to see some text from SPs on this subject=20 --> > before we add anything to the requirements I-D. --> > -->=20 --> I think that the DT is working on it. So, this is confusing. Are you saying that it's out of the hands of the WG because the authors are taking this work on anyway? /Chair Hat/ I just meant that the DT was working on the new revision of draft-ietf-pce-comm-protocol-gen-reqs with the intention to cover that aspect for WG input (this new rev has now been published). As you know, = by definition, a Working Group document is owned by the Working Group.=20 Your comments are of course more than welcome.=20 /Chair hat removed/ We may just want to sit down in Paris and discuss more on this if you = will. JP. -->=20 --> Cheers, -->=20 --> JP. -->=20 --> > Cheers, --> > Adrian --> > --> > --- [SNIP] --- _____ =20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce ------_=_NextPart_001_01C5910B.FF79537A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I=20 think the point here is that there was absolutely no consensus to = include this=20 in the
PCE=20 protocol requirements.
 
One of=20 the WG chairs - JP - asked if this should be included.  A highly = polar=20 discussion
followed in which several people weighed in against doing=20 so.
 
The=20 fact that it may seem like a good idea to the author(s) is insufficient = reason=20 to put
it in=20 the draft, once the draft has become a working group=20 document.
 
Therefore, lacking overwhelming indications that a consensus = does exist=20 to put it in the
working group's draft, the author(s) should remove=20 it.
 
--
Eric
-----Original Message-----
From: LE ROUX = Jean-Louis=20 RD-CORE-LAN = [mailto:jeanlouis.leroux@francetelecom.com]
Sent:=20 Monday, July 25, 2005 4:45 AM
To: Igor Bryskin; JP Vasseur; = Gray,=20 Eric
Cc: pce@ietf.org
Subject: RE: [Pce] = Requirement for=20 less-constrained=20 = pathindraft-ietf-pce-comm-protocol-gen-reqs-00.txt

Hi Igor, all
 
Please see inline for some=20 comments,

De : = pce-bounces@lists.ietf.org=20 [mailto:pce-bounces@lists.ietf.org] De la part de Igor=20 Bryskin
Envoy=E9 : mardi 19 juillet 2005 = 17:41
=C0 :=20 JP Vasseur; Gray, Eric
Cc : = pce@ietf.org
Objet :=20 Re: [Pce] Requirement for less-constrained=20 pathindraft-ietf-pce-comm-protocol-gen-reqs-00.txt

JP.
 
As I have indicated earlier I don't = believe that=20 the complexity associated with signaling of constraint relaxation = strategy=20 justifies the results.
[JLLR] Please don't make things more complex = than they are=20 in practical operational cases...
 
A=20 practical case, that is deployed btw, is SRLG exclusion in = FRR=20 bypass tunnel path computation:
The=20 operator wants a path that excludes a set of SRLGs, and if this path = cannot be=20 found he wants a path that excludes the maximum number of = SRLGs in=20 this set. Unfortunately the PCC cannot guess this best relaxed = set=20 and for instance if #SRLG =3D 4 this may lead =  to 16=20 requests :-(
Conversely the PCE can run an algorithm = that will=20 return a path maximizing the number of excluded = SRLGs.
This=20 is a simple case where less constrained paths are highly=20 valuable.
 
Another simple case is "bounded delay = bandwidth=20 constrained" path computation:
If=20 the path cannot be found, I want the PCE to provide me a bandwidth = constrained=20 path with a relaxed delay bound
or a=20 delay bounded path with a relaxed bandwidth = constraint. Unfortunately I=20 cannot guess these relaxed values, and it sound = really
valuable, and not so complex (there are = highly=20 efficient heuristics) for the PCE to perform such=20 relaxation....
 
 Most of the constraints are = non-boolean,=20 and it is difficult IMO to provide a simple yet flexible way for a = PCC to=20 articulate the desired way of relaxation wrt each of the=20 constraints.
[JLLR] In practical operational cases = you won't have a=20 lot of constraints, so this sounds quite simple to articulate = such=20 relaxation (one could use a set of bits=20 vectors).
 
  And what if the constraints = are not=20 independent? For instance, what if a PCC wants to get best = tradeoff of=20 several constraints ?
[JLLR] We could also find a simple way to = express these=20 cases (again with a vector encoding dependent constraints to be=20 relaxed...)
My suggestion is to start with = allowing for PCC=20 to specify in a single request a set of mandatory constraints and an = ordered=20 list of sets of relaxable constraints: first, use the first set in = the list (+=20 mandatory, of course), if path computation fails - use the second one = and so=20 forth.
[JLLR] Do=20 you include constraint values or just identify constraints to be = relaxed?=20
If=20 the latter, then we fully agree.
 
 This is a much simpler way of = doing the=20 constraint relaxation and could be just good enough, = although it=20 makes the size of requests and response larger.
[JLLR] Simpler = than which=20 way?? 
 
By the way, do you remember = that sometime=20 ago I suggested to design the PCC-PCE protocol in a such a way where = each=20 request/response is a BASIC style program
  that could be interpreted =  by both=20 PCC and PCE? The intention was to provide a very flexible way for a = PCE to=20 describe its capabilities and introduce new ones, and for PCC to take = the most=20 of the PCE and specify what exactly it wants from the requested = path=20 computation (what constraints and optimization criterias to be = used and=20 how)
 
[JLLR] 
Note that this has = already been=20 proposed by Kireeti two years ago to pass constraints in=20 RSVP
(see=20 http://www.watersprings.org/pub/id/draft-kompella-mpls-rsvp-con= straints-01.txt)
I have major concerns regarding the = complexity=20 of this approach. Please = note that=20 the PCE may run quite complex algorithms (e.g. multi-constraint = heuristic=20 algorithms, or, yet to be added in the charter, steiner tree = heuristics,=20 requiring CPU intensive computation...). Do you also assume passing = the code=20 for such complex algorithms??? This=20 would drastically complexify PCC=20 operations....
 
It would be very easy to = support the=20 constraint relaxation strategies no matter how complex they are = :=3D)
[JLLR] Ah yes = of course if=20 you put a lot of complexity on the PCC=20 :-(
 
I agree with you that this would provide = a huge=20 flexibility in the way to express = constraints,
but think about the standardization = effort that=20 this would imply (unless you want to rely on Java applets=20 :-))
 
Best Regards,
 
JL
 
Cheers,
Igor
----- Original Message -----
From:=20 JP = Vasseur=20
Sent: Tuesday, July 19, 2005 = 9:47=20 AM
Subject: Re: [Pce] = Requirement for=20 less-constrained path = indraft-ietf-pce-comm-protocol-gen-reqs-00.txt

Hi Eric,=20

On Jul 18, 2005, at 3:57 PM, Gray, Eric wrote:
JP,

    From your = earlier=20 response, I see that you're aiming 
at the "greater of two evil" = solutions.  Tch, tch, tch!!

    Please = see=20 below...

--> -----Original = Message-----
--> From: JP Vasseur [mailto:jvasseur@cisco.com]
--> Sent: Thursday, July 14, 2005 = 9:19=20 PM
--> To: Adrian Farrel
--> Cc: Gray, Eric; pce@ietf.org
--> Subject: Re: [Pce] Requirement = for=20 less-constrained path
-->=20 indraft-ietf-pce-comm-protocol-gen-reqs-00.txt
--> 
--> 
--> 
--> On Jul 14, 2005, at 12:26 PM, = Adrian=20 Farrel wrote:
--> 
--> > I want to pitch in on this = thread=20 because I think (I) see 
--> > where both JP and Eric are = coming=20 from. JP's proposals have
--> > the potential to = significantly reduce=20 the PCE processing 
--> > and cut down number of = PCC-PCE=20 transactions, but they also
--> > have the ability to = massively=20 increase the processing and  
--> > the size of the PCC-PCE=20 transactions.
--> >
--> 
--> that said, it it pretty = straightforward to=20 see that the benefits  
--> undoubtedly outweigh the = drawbacks. The=20 request processing is  
--> definitely negligible compared = to the=20 communication overhead.

This is the point of obvious = disagreement.


Good so at least we agree on the disagreement ;-)

--> Actually, it could be shown = that the non=20 support of such capability  
--> would have a drastic = scalability impact on=20 the solution especially  
--> upon resource contention.

Only if you assume that communication = is the=20 bottleneck.

Just try to decompose the various steps occurring during = a path=20 computation (request/reply) especially when the constraints cannot = be fully=20 satisfied:
1) Path computation request sent to the PCE
2) PCE processing which includes:
    - queueing delay (PCE scheduler)
    - service time (PCE scheduler)
3) Path computation reply sent to the PCE.

Then repeat such cycle until a path is successfully=20 computed.

Now consider the two cases where:
A- The PCC has to send multiple requests trying to guess the = set of=20 constraints that could lead to a successful path computation.
B- The PCC specifies a set of rules and the PCE tries to find = a path by=20 means of a single request

A few important facts:

- In case of A, when the constraint is not a boolean (e.g. = bandwidth),=20 it is really a guess and even an approach based = on dichotomy would=20 unavoidably lead to a non negligible number of cycles. 
- Some path computation algorithms have the capability to = relax=20 constraints "on the fly" thus saving CPU cycles compared to = serialized path=20 computations. 
- Without entering into some gory details about network = analysis,=20 queueing systems and implementation-specific algorithms, try to = decompose=20 the steps 1), 2) and 3), and you'll easily identify where the = bottlenecks=20 are when comparing the two approaches (especially 2).
- The set of rules does not = have to be=20 complex (see an example below) and more importantly does not = have to be=20 used when inappropriate

Reality is that messaging only becomes = a=20 bottleneck if
message processing is excessively = complex and/or=20 it is 
done in a poorly thought out way. If = the=20 communication
issue is not with messaging, then what = is=20 it?


I'm of course not suggesting to design poorly thought out and=20 excessively complex messaging ;-)

--> 
--> > Thus we need to be quite = careful in=20 the specification of the
--> > protocol requirements and = the=20 protocol itself. It is not OK
--> > for us to say that if an = individual=20 PCC is irresponsible or 
--> > stupid that is its = problem, because=20 such an implementation
--> > would break the = accessibility to the=20 PCE for other 'normal' 
--> > PCCs.
--> >
--> 
--> On this aspect, I do agree = !
--> 
--> > Unless there are = "standard"=20 constraint back-off functions 
--> > it is hard to conceive of = a PCE=20 guessing the correct back-
--> > off for the PCC that = issued the=20 request. Note that the more 
--> > "speculative paths" the = PCE computes=20 the more CPU it uses.
--> 
--> Speculative paths is definitely = not an=20 option considering the 
--> number of permutations ... we = would=20 unavoidably quickly fall
--> into some NP-Complete issues = ;-) ... This=20 is why the suggestion 
--> is made to start some = discussion on the=20 hierarchical relaxation 
--> policy. Note that it does not = have to be=20 awfully complex ...

Here we have many things said in few = words. I=20 know, because I can
identify numerous points for both = agreement and=20 disagreement.  = :-)

The issue with permutations (and = NP-complete=20 issues) is one part
on which I think we agree.

The notion that a hierarchical = relaxation=20 approach avoids this is
one part on which I think we = disagree.

Finally, the "wish" that it does not = have to be=20 complex is quite
interesting.  The only way that it = will not be=20 complex, is if the
actual decision making process is very = simple in=20 every case. The
point of contention is the fact that - = while it=20 probably can be 
very simple in most cases - it will = almost=20 certainly not be 1) the
same in every case and 2) good enough = in every=20 case.


Ah here I fully agree with you (last paragraph ;-)). The goal = may not=20 be to design a solution that will address *all* cases and that will = be good=20 in *all* cases. 
As a system designer, I'd be very happy = if the=20 proposed solution solves the vast majority of the issues in an = simple way.=20 When not appropriate, just do not use it. Vendor = implementations should=20 be able to be flexible enough so that the operator could choose = when to use=20 such approach. See other similar examples with hierarchical BGP = policy=20 rules, ACLs, ... 

If a different hierarchical relaxation = policy=20 might apply under
different circumstances, then the = complexity of=20 the protocol is
going to be greater than the = combination of all=20 "simple cases".

If the approach is not "good enough", = then a PCC=20 is forced to
fall back on the multiple messages = approach.  Net gain: = ~zero.


Indeed, we agree on the fact that we could make = it awfully complex=20 and consequently not practically usable. I could also come up = with many=20 such examples ... Conversely, one could easily come up with=20 *real*life*use*of*TE*scenario where such approach would be quite = useful.=20 *Again*, think of how Service Providers use TE today ... Let me = give you a=20 simple example here (which by the way would cover a good % of = current=20 needs):

Packet LSPs,
Two constraints: affinity=3DRED and bandwidth=3D10
The set of constraints cannot be fully satisfied because of = resource=20 contention.

Case A: The PCC sends multiple requests until a path can be=20 found.
Case B: The PCC sends one request (affinity=3DRED, = bandwidth=3D10) and=20 specifies to first relax the affinity, then find the = closest bandwidth=20 match. Note that a different policy may be adopted different LSP=20 types.

With such a simple example, you can easily see the = benefit of=20 B-
-> Reduced PCE processing (delay and service time)
-> Cut-down the number of transactions
-> Simple constraint relaxation rule

=3D> consequently reduced path computation delay

Again, I'm not claiming that all problems could be solved this = way and=20 that an operator should/could always use such hierarchical = constraints=20 approach but there are many circumstances whereby such approach = would be IMO=20 highly valuable.

Of course, I'll wait for service providers to confirm that=20 statement.

--> 
--> > So we must keep good = control on this.=20 It is a
--> > computational myth that it = is=20 possible to relax different  
--> > constraints on a
--> > single computational = pass.
--> 
--> Ah no ... there are several = constraints=20 for which 
--> constraint can be relaxed and = closest=20 match can be 
--> found in on-go.
--> 
--> That said, even if it were not = the case,=20 the solution 
--> would still be valuable to = cut-down the=20 communication 
--> overhead and amount of = processing=20 signaling be the 
--> PCE's scheduler.
--> 
--> > In fact, the question = "where did my=20 computation fail"
--> > is notoriously impossible = to answer=20 except with the =20  
--> > response "in the = network".
--> >
--> > Thus we should give full = control to=20 the PCC, and let 
--> > the PCE choose to supply = less=20 information if it thinks =20  
--> > that the PCC is asking too = much. This=20 control includes:
--> >
--> > a. The ability to say = "this or=20 nothing"
--> > b. The ability to say = "tell me what=20 constraints I
--> >    might relax to = get a=20 path"
--> > c. The ability to say = "give me n=20 alternate paths with 
--> >    with your = choice of=20 relaxed constraints" (c. is 
--> >    like b but = with the paths=20 supplied, and it is 
--> >    important to = control the=20 number)
--> > d. A way to state which = constraints=20 may be relaxed 
--> >    absolutely = (this is=20 easy)
--> > e. A way to replace one = constraint=20 supplied by the  
--> >    PCC with = another also=20 supplied by the PCC
--> > f. A way to specify an = ordering for=20 relaxation in 
--> >    recomputation=20 attempts.
--> >
--> > My feeling is that e might = be=20 satisfied in the protocol  
--> > simply by listing the same = object=20 multiple times. But f
--> > is very messy. As soon as = I have a=20 few constraints and 
--> > I am willing to relax each = of them by=20 degrees I have a
--> > very complex relaxation = problem to=20 express.
--> 
--> Well not so sure ... Let's wait = for the=20 meeting in Paris to 
--> have an open discussion. I'd be = happy to=20 provide some ideas.
--> Actually one could point out = that such=20 constraint relaxation 
--> are used TODAY in operational = networks=20 (with CSPF).

One could point that out, if one wants = to show=20 that having 
a PCC make separate requests is the = right way to=20 go. I was
under the impression you were arguing = the=20 opposition point
of view.

In the CSPF case you identify, the = Traffic=20 Engineer is both
a PCC and a PCE and - with respect to = the=20 relaxation mode,
it is much more likely to act like a = PCC than a=20 PCE. In other
words, given a requirement for TE = tunnel routing,=20 it will 
most likely complete a computation = based on a=20 single set of
constraints and - if that fails - it = may elect to=20 relax the
path requirements and try again with = different=20 constraints.


But this is the whole point. When the PCE is co-located this = can be=20 done without introducing substantial delays ... Conversely, think = of a PCE=20 receiving a burst of requests from tens of PCCs after a network = failure ...=20 this is precisely one of the aspects that I want to = optimize.

This is essentially PCC behavior. = Pushing this=20 behavior into
the PCE saves on external messaging = overhead, but=20 at a huge
cost in complexity.  Now, instead of = having a=20 self-contained
entity (the PCC) deciding how next to = proceed in=20 getting a 
Path (should any attempt fail), it = must=20 communicate a decision 
making process to a delegate (the PCE) = for every=20 Path request
- irrespective of whether or not that = Path=20 Request would fail.

Unless the decision making options are = very=20 limited, this must
impose a higher level of processing on = the PCE=20 just to decode,
store and - eventually - act on the = decision=20 making process.

I doubt that the communication = overhead is the=20 bottle-neck for
PCE-PCC transactions, or the network = over which=20 they transpire.
I also strongly suspect that = deployments will=20 tend toward more
PCCs than PCEs, so - assuming that = (for example)=20 there are ten
times as many PCCs as PCEs - what is = the=20 advantage gained by
pushing the work of 1,000 PCCs onto = 100 PCEs,=20

no no ... we do not push the work of 1,000 PCCs onto 100 PCEs = ... by=20 supporting such constraint relaxation approach you drastically = reduce the=20 processing load on PCEs.

Jumping to the end of this email (considering the text = provided=20 above).

especially if you 
assume that most path requests will be = satisfied=20 prior to a PCC 
traversal of the decision tree.

--> 
--> >
--> > This is a problem that it = is very=20 easy for the PCC to  
--> > handle by issuing = successive=20 requests, but very hard for 
--> > the PCC to communicate to = the PCE in=20 a single request.
--> 
--> I do not think that it is hard = for the PCC=20 to communicate 
--> to the PCE in a single = request.

You miss the point.

If "communication" was easy, you = wouldn't have=20 started this
discussion, and I wouldn't be = continuing it.  :-)

Let's say that PCC X follows this = scheme for one=20 subset of its
requests:

scheme (a)
    Request a = path with=20 constraints A, B and C.
    On = failure for A,=20 request a path with constraint A1 that
        = still=20 satisfies B and C.
    On = failure for A1, B=20 or C, fail.

To cut down on communication overhead, = we could=20 communicate
this decision making policy to the PCE = and make a=20 single
request that either succeeds or fails = according=20 to this policy.

But this PCC (or another) also has a = decision=20 making schemes as
follows for other types of = services:

scheme (b)
    Request a = path with=20 constraint A, C and D.
    On = failure for C,=20 request a path with constraints A and D
       =20 only
    On = failure for A or=20 D, fail.

scheme (c)
    Request a = path with=20 constraints B, C and D.
    On = failure (for B, C=20 or D) request an unconstrained shortest
       =20 path.

... and so on ...

Hence, given any arbitrary number of = potential=20 constraints, the
number of possible decision making = policies we=20 need to define
is clearly combinatorial (i.e. - NP) = in the=20 number of possible
constraints (and possible relaxations = of=20 each).

However, if we do not cover all of the = possibilities, then we
constrain the services that our = customers can=20 sell, their ability
to differentiate themselves from their = competitors and even the
service pricing structures that are = available to=20 their customers
in turn.

To eliminate this concern, all we need = to do is=20 define a language
for describing a decision making = process.  Done much work in = the
area of defining languages like = this?  :-)

--> 
--> >
--> > So, I'd like to see some = text from=20 SPs on this subject 
--> > before we add anything to = the=20 requirements I-D.
--> >
--> 
--> I think that the DT is working = on=20 it.

So, this is confusing. Are you saying = that it's=20 out of the hands
of the WG because the authors are = taking this=20 work on anyway?


/Chair Hat/

I just meant that the DT was working on the new revision of=20 draft-ietf-pce-comm-protocol-gen-reqs with the intention to cover = that=20 aspect for WG input (this new rev has now been published). As you = know, by=20 definition, a Working Group document is owned by the Working=20 Group. 

Your comments are of course more than welcome. 

/Chair hat removed/

We may just want to sit down in Paris and discuss more on this = if you=20 will.

JP.

--> 
--> Cheers,
--> 
--> JP.
--> 
--> > Cheers,
--> > Adrian
--> >
--> > --- [SNIP] ---

_______________________________________________
Pce = mailing=20 = list
Pce@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce=
------_=_NextPart_001_01C5910B.FF79537A-- --===============0632900818== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============0632900818==-- From pce-bounces@lists.ietf.org Mon Jul 25 07:46:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx1Q6-0002Om-Qi; Mon, 25 Jul 2005 07:46:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx1Q5-0002Oh-JY for pce@megatron.ietf.org; Mon, 25 Jul 2005 07:46:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10020 for ; Mon, 25 Jul 2005 07:46:52 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dx1uu-0006u0-Ia for pce@ietf.org; Mon, 25 Jul 2005 08:18:46 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 25 Jul 2005 04:46:43 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j6PBkeJN010905; Mon, 25 Jul 2005 04:46:41 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 25 Jul 2005 07:46:40 -0400 Received: from [192.168.1.100] ([10.86.240.220]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 25 Jul 2005 07:46:39 -0400 In-Reply-To: <313680C9A886D511A06000204840E1CF0C885D44@whq-msgusr-02.pit.comms.marconi.com> References: <313680C9A886D511A06000204840E1CF0C885D44@whq-msgusr-02.pit.comms.marconi.com> Mime-Version: 1.0 (Apple Message framework v730) Message-Id: <21A07AD3-F2CC-4337-AB5E-70541E95A26D@cisco.com> From: JP Vasseur Subject: Re: [Pce] Requirement for less-constrained pathindraft-ietf-pce-c omm-protocol-gen-reqs-00.txt Date: Mon, 25 Jul 2005 07:46:49 -0400 To: "Gray, Eric" X-Mailer: Apple Mail (2.730) X-OriginalArrivalTime: 25 Jul 2005 11:46:39.0946 (UTC) FILETIME=[852792A0:01C5910E] X-Spam-Score: 0.2 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0931634224==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org --===============0931634224== Content-Type: multipart/alternative; boundary=Apple-Mail-13-103404882 --Apple-Mail-13-103404882 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Hi Eric, / Chair Hat / On Jul 25, 2005, at 7:28 AM, Gray, Eric wrote: > I think the point here is that there was absolutely no consensus to > include this in the > PCE protocol requirements. > > One of the WG chairs - JP - asked if this should be included. A > highly polar discussion > followed in which several people weighed in against doing so. > Indeed, I asked to the WG whether there was a need for such capability. > The fact that it may seem like a good idea to the author(s) is > insufficient reason to put > it in the draft, once the draft has become a working group document. > Correct, no WG consensus has been reached on this issue as of now. Several ones were opposed to it, several other ones were in favor. > Therefore, lacking overwhelming indications that a consensus does > exist to put it in the > working group's draft, the author(s) should remove it. > Here is the plan: (1) Ask for a vote within the WG on this issue. I would suggest some discussion in Paris followed by discussion on the mailing list. The next revision of the protocol requirement will reflect the WG consensus on this particular aspect. (2) For the next revision, the authors of the PCEP spec mentioned that they would remove the "less-constrained path computation" from the PCEP specification. "Less-constrained path computation" aspects will potentially be discussed in another ID, should there be a WG consensus. Note that I would like us to make progress of the basic functionalities first (such as the PCE requirement ID, architecture, PCE communication protocol, ...) so as to meet our Milestones. More advanced features could be discussed in a second step. Thanks. JP. --Apple-Mail-13-103404882 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi = Eric,

/ Chair = Hat /

On Jul 25, 2005, at 7:28 AM, Gray, Eric = wrote:

I think the point here is that there was = absolutely no consensus to include this in = the
PCE protocol = requirements.
=A0
One of the WG chairs - JP - asked if this = should be included.=A0 A highly polar = discussion
followed in which several people weighed in = against doing so.
=A0

Indeed, I = asked to the WG whether there was a need for such = capability.

The fact that it may seem like a good idea to = the author(s) is insufficient reason to = put
it in the draft, once the draft has become a = working group document.
=A0

Correct, no WG consensus = has been reached on this issue as of now. Several ones were opposed to = it, several other ones were in favor.

Therefore, lacking overwhelming indications = that a consensus does exist to put it in = the
working group's draft, the author(s) should = remove it.
=A0

Here is the = plan:
(1) Ask for a vote within the WG = on this issue. I would suggest some discussion in Paris followed by = discussion on the mailing list. The next revision of the protocol = requirement will reflect the WG consensus on this particular = aspect.
(2) For the next revision, the = authors of the PCEP spec mentioned that they would remove the = "less-constrained path computation" from the PCEP specification. = "Less-constrained path computation" aspects will potentially be = discussed in another ID, should there be a WG = consensus.

Note that I = would like us to make progress of the basic functionalities first (such = as the PCE requirement ID, architecture, PCE communication protocol, = ...) so as to meet our Milestones. More advanced features could be = discussed in a second step.



= --Apple-Mail-13-103404882-- --===============0931634224== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============0931634224==-- From pce-bounces@lists.ietf.org Mon Jul 25 08:38:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx2E4-0004iU-PY; Mon, 25 Jul 2005 08:38:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx1yW-0001tI-UT for pce@megatron.ietf.org; Mon, 25 Jul 2005 08:22:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13705 for ; Mon, 25 Jul 2005 08:22:27 -0400 (EDT) Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dx2TJ-0008SP-Id for pce@ietf.org; Mon, 25 Jul 2005 08:54:21 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Mon, 25 Jul 2005 14:22:13 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Pce] Requirement for less-constrained pathindraft-ietf-pce-comm-protocol-gen-reqs-00.txt Date: Mon, 25 Jul 2005 14:22:12 +0200 Message-ID: Thread-Topic: [Pce] Requirement for less-constrained pathindraft-ietf-pce-comm-protocol-gen-reqs-00.txt Thread-Index: AcWRDAYOd/Jns+PLRdKwkEIPo2zKyQABBfrA From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "Gray, Eric" , "Igor Bryskin" , "JP Vasseur" X-OriginalArrivalTime: 25 Jul 2005 12:22:13.0509 (UTC) FILETIME=[7CDB7350:01C59113] X-Spam-Score: 2.9 (++) X-Scan-Signature: 5b30a0db5a1d87f6e723894075eb608f X-Mailman-Approved-At: Mon, 25 Jul 2005 08:38:31 -0400 Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0809387711==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0809387711== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C59113.7CB72CA4" This is a multi-part message in MIME format. ------_=_NextPart_001_01C59113.7CB72CA4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Eric, =20 Please note that I was not discussing here whether there is a consensus = or not and was just trying to explain a bit more the strong motivations = for such requirement... =20 Anyway let's discuss this point deeper in Paris =20 Thanks, =20 JL =20 =20 ________________________________ De : Gray, Eric [mailto:Eric.Gray@marconi.com]=20 Envoy=E9 : lundi 25 juillet 2005 13:29 =C0 : LE ROUX Jean-Louis RD-CORE-LAN; Igor Bryskin; JP Vasseur; Gray, = Eric Cc : pce@ietf.org Objet : RE: [Pce] Requirement for less-constrained = pathindraft-ietf-pce-comm-protocol-gen-reqs-00.txt I think the point here is that there was absolutely no consensus to = include this in the PCE protocol requirements. =20 One of the WG chairs - JP - asked if this should be included. A highly = polar discussion followed in which several people weighed in against doing so. =20 The fact that it may seem like a good idea to the author(s) is = insufficient reason to put it in the draft, once the draft has become a working group document. =20 Therefore, lacking overwhelming indications that a consensus does exist = to put it in the working group's draft, the author(s) should remove it. =20 -- Eric -----Original Message----- From: LE ROUX Jean-Louis RD-CORE-LAN = [mailto:jeanlouis.leroux@francetelecom.com] Sent: Monday, July 25, 2005 4:45 AM To: Igor Bryskin; JP Vasseur; Gray, Eric Cc: pce@ietf.org Subject: RE: [Pce] Requirement for less-constrained = pathindraft-ietf-pce-comm-protocol-gen-reqs-00.txt =09 =09 Hi Igor, all =20 Please see inline for some comments, ________________________________ De : pce-bounces@lists.ietf.org [mailto:pce-bounces@lists.ietf.org] De = la part de Igor Bryskin Envoy=E9 : mardi 19 juillet 2005 17:41 =C0 : JP Vasseur; Gray, Eric Cc : pce@ietf.org Objet : Re: [Pce] Requirement for less-constrained = pathindraft-ietf-pce-comm-protocol-gen-reqs-00.txt =09 =09 JP. =20 As I have indicated earlier I don't believe that the complexity = associated with signaling of constraint relaxation strategy justifies = the results.=20 [JLLR] Please don't make things more complex than they are in practical = operational cases... =20 =09 A practical case, that is deployed btw, is SRLG exclusion in FRR bypass = tunnel path computation: The operator wants a path that excludes a set of SRLGs, and if this = path cannot be found he wants a path that excludes the maximum number of = SRLGs in this set. Unfortunately the PCC cannot guess this best relaxed = set and for instance if #SRLG =3D 4 this may lead to 16 requests :-( Conversely the PCE can run an algorithm that will return a path = maximizing the number of excluded SRLGs. This is a simple case where less constrained paths are highly valuable. =20 Another simple case is "bounded delay bandwidth constrained" path = computation: If the path cannot be found, I want the PCE to provide me a bandwidth = constrained path with a relaxed delay bound or a delay bounded path with a relaxed bandwidth constraint. = Unfortunately I cannot guess these relaxed values, and it sound really valuable, and not so complex (there are highly efficient heuristics) = for the PCE to perform such relaxation.... =20 Most of the constraints are non-boolean, and it is difficult IMO to = provide a simple yet flexible way for a PCC to articulate the desired = way of relaxation wrt each of the constraints. [JLLR] In practical operational cases you won't have a lot of = constraints, so this sounds quite simple to articulate such relaxation = (one could use a set of bits vectors). =20 And what if the constraints are not independent? For instance, what = if a PCC wants to get best tradeoff of several constraints ?=20 [JLLR] We could also find a simple way to express these cases (again = with a vector encoding dependent constraints to be relaxed...) My suggestion is to start with allowing for PCC to specify in a single = request a set of mandatory constraints and an ordered list of sets of = relaxable constraints: first, use the first set in the list (+ = mandatory, of course), if path computation fails - use the second one = and so forth.=20 [JLLR] Do you include constraint values or just identify constraints to = be relaxed?=20 If the latter, then we fully agree. =20 This is a much simpler way of doing the constraint relaxation and = could be just good enough, although it makes the size of requests and = response larger. [JLLR] Simpler than which way??=20 =20 By the way, do you remember that sometime ago I suggested to design the = PCC-PCE protocol in a such a way where each request/response is a BASIC = style program that could be interpreted by both PCC and PCE? The intention was to = provide a very flexible way for a PCE to describe its capabilities and = introduce new ones, and for PCC to take the most of the PCE and specify = what exactly it wants from the requested path computation (what = constraints and optimization criterias to be used and how) =20 [JLLR]=20 Note that this has already been proposed by Kireeti two years ago to = pass constraints in RSVP (see = http://www.watersprings.org/pub/id/draft-kompella-mpls-rsvp-constraints-0= 1.txt = ) I have major concerns regarding the complexity of this approach. Please = note that the PCE may run quite complex algorithms (e.g. = multi-constraint heuristic algorithms, or, yet to be added in the = charter, steiner tree heuristics, requiring CPU intensive = computation...). Do you also assume passing the code for such complex = algorithms??? This would drastically complexify PCC operations.... =20 It would be very easy to support the constraint relaxation strategies = no matter how complex they are :=3D) [JLLR] Ah yes of course if you put a lot of complexity on the PCC :-( =20 I agree with you that this would provide a huge flexibility in the way = to express constraints, but think about the standardization effort that this would imply = (unless you want to rely on Java applets :-)) =20 Best Regards, =20 JL =20 Cheers, Igor ----- Original Message -----=20 From: JP Vasseur =20 To: Gray, Eric =20 Cc: pce@ietf.org=20 Sent: Tuesday, July 19, 2005 9:47 AM Subject: Re: [Pce] Requirement for less-constrained path = indraft-ietf-pce-comm-protocol-gen-reqs-00.txt Hi Eric,=20 On Jul 18, 2005, at 3:57 PM, Gray, Eric wrote: JP, From your earlier response, I see that you're aiming=20 at the "greater of two evil" solutions. Tch, tch, tch!! Please see below... --> -----Original Message----- --> From: JP Vasseur [mailto:jvasseur@cisco.com] --> Sent: Thursday, July 14, 2005 9:19 PM --> To: Adrian Farrel --> Cc: Gray, Eric; pce@ietf.org --> Subject: Re: [Pce] Requirement for less-constrained path --> indraft-ietf-pce-comm-protocol-gen-reqs-00.txt -->=20 -->=20 -->=20 --> On Jul 14, 2005, at 12:26 PM, Adrian Farrel wrote: -->=20 --> > I want to pitch in on this thread because I think (I) see=20 --> > where both JP and Eric are coming from. JP's proposals have --> > the potential to significantly reduce the PCE processing=20 --> > and cut down number of PCC-PCE transactions, but they also --> > have the ability to massively increase the processing and =20 --> > the size of the PCC-PCE transactions. --> > -->=20 --> that said, it it pretty straightforward to see that the benefits = --> undoubtedly outweigh the drawbacks. The request processing is =20 --> definitely negligible compared to the communication overhead. This is the point of obvious disagreement. Good so at least we agree on the disagreement ;-) --> Actually, it could be shown that the non support of such = capability =20 --> would have a drastic scalability impact on the solution = especially =20 --> upon resource contention. Only if you assume that communication is the bottleneck. Just try to decompose the various steps occurring during a path = computation (request/reply) especially when the constraints cannot be = fully satisfied: 1) Path computation request sent to the PCE 2) PCE processing which includes: - queueing delay (PCE scheduler) - service time (PCE scheduler) 3) Path computation reply sent to the PCE. Then repeat such cycle until a path is successfully computed. Now consider the two cases where: A- The PCC has to send multiple requests trying to guess the set of = constraints that could lead to a successful path computation. B- The PCC specifies a set of rules and the PCE tries to find a path = by means of a single request A few important facts: - In case of A, when the constraint is not a boolean (e.g. bandwidth), = it is really a guess and even an approach based on dichotomy would = unavoidably lead to a non negligible number of cycles.=20 - Some path computation algorithms have the capability to relax = constraints "on the fly" thus saving CPU cycles compared to serialized = path computations.=20 - Without entering into some gory details about network analysis, = queueing systems and implementation-specific algorithms, try to = decompose the steps 1), 2) and 3), and you'll easily identify where the = bottlenecks are when comparing the two approaches (especially 2). - The set of rules does not have to be complex (see an example below) = and more importantly does not have to be used when inappropriate =09 Reality is that messaging only becomes a bottleneck if message processing is excessively complex and/or it is=20 done in a poorly thought out way. If the communication issue is not with messaging, then what is it? I'm of course not suggesting to design poorly thought out and = excessively complex messaging ;-) -->=20 --> > Thus we need to be quite careful in the specification of the --> > protocol requirements and the protocol itself. It is not OK --> > for us to say that if an individual PCC is irresponsible or=20 --> > stupid that is its problem, because such an implementation --> > would break the accessibility to the PCE for other 'normal'=20 --> > PCCs. --> > -->=20 --> On this aspect, I do agree ! -->=20 --> > Unless there are "standard" constraint back-off functions=20 --> > it is hard to conceive of a PCE guessing the correct back- --> > off for the PCC that issued the request. Note that the more=20 --> > "speculative paths" the PCE computes the more CPU it uses. -->=20 --> Speculative paths is definitely not an option considering the=20 --> number of permutations ... we would unavoidably quickly fall --> into some NP-Complete issues ;-) ... This is why the suggestion=20 --> is made to start some discussion on the hierarchical relaxation=20 --> policy. Note that it does not have to be awfully complex ... Here we have many things said in few words. I know, because I can identify numerous points for both agreement and disagreement. :-) The issue with permutations (and NP-complete issues) is one part on which I think we agree. The notion that a hierarchical relaxation approach avoids this is one part on which I think we disagree. Finally, the "wish" that it does not have to be complex is quite interesting. The only way that it will not be complex, is if the actual decision making process is very simple in every case. The point of contention is the fact that - while it probably can be=20 very simple in most cases - it will almost certainly not be 1) the same in every case and 2) good enough in every case. Ah here I fully agree with you (last paragraph ;-)). The goal may not = be to design a solution that will address *all* cases and that will be = good in *all* cases.=20 As a system designer, I'd be very happy if the proposed solution = solves the vast majority of the issues in an simple way. When not = appropriate, just do not use it. Vendor implementations should be able = to be flexible enough so that the operator could choose when to use such = approach. See other similar examples with hierarchical BGP policy rules, = ACLs, ...=20 =09 =09 If a different hierarchical relaxation policy might apply under different circumstances, then the complexity of the protocol is going to be greater than the combination of all "simple cases". If the approach is not "good enough", then a PCC is forced to fall back on the multiple messages approach. Net gain: ~zero. Indeed, we agree on the fact that we could make it awfully complex and = consequently not practically usable. I could also come up with many such = examples ... Conversely, one could easily come up with = *real*life*use*of*TE*scenario where such approach would be quite useful. = *Again*, think of how Service Providers use TE today ... Let me give you = a simple example here (which by the way would cover a good % of current = needs): Packet LSPs, Two constraints: affinity=3DRED and bandwidth=3D10 The set of constraints cannot be fully satisfied because of resource = contention. Case A: The PCC sends multiple requests until a path can be found. Case B: The PCC sends one request (affinity=3DRED, bandwidth=3D10) and = specifies to first relax the affinity, then find the closest bandwidth = match. Note that a different policy may be adopted different LSP types. With such a simple example, you can easily see the benefit of B- -> Reduced PCE processing (delay and service time) -> Cut-down the number of transactions -> Simple constraint relaxation rule =3D> consequently reduced path computation delay Again, I'm not claiming that all problems could be solved this way and = that an operator should/could always use such hierarchical constraints = approach but there are many circumstances whereby such approach would be = IMO highly valuable. Of course, I'll wait for service providers to confirm that statement. -->=20 --> > So we must keep good control on this. It is a --> > computational myth that it is possible to relax different =20 --> > constraints on a --> > single computational pass. -->=20 --> Ah no ... there are several constraints for which=20 --> constraint can be relaxed and closest match can be=20 --> found in on-go. -->=20 --> That said, even if it were not the case, the solution=20 --> would still be valuable to cut-down the communication=20 --> overhead and amount of processing signaling be the=20 --> PCE's scheduler. -->=20 --> > In fact, the question "where did my computation fail" --> > is notoriously impossible to answer except with the =20 --> > response "in the network". --> > --> > Thus we should give full control to the PCC, and let=20 --> > the PCE choose to supply less information if it thinks =20 --> > that the PCC is asking too much. This control includes: --> > --> > a. The ability to say "this or nothing" --> > b. The ability to say "tell me what constraints I --> > might relax to get a path" --> > c. The ability to say "give me n alternate paths with=20 --> > with your choice of relaxed constraints" (c. is=20 --> > like b but with the paths supplied, and it is=20 --> > important to control the number) --> > d. A way to state which constraints may be relaxed=20 --> > absolutely (this is easy) --> > e. A way to replace one constraint supplied by the =20 --> > PCC with another also supplied by the PCC --> > f. A way to specify an ordering for relaxation in=20 --> > recomputation attempts. --> > --> > My feeling is that e might be satisfied in the protocol =20 --> > simply by listing the same object multiple times. But f --> > is very messy. As soon as I have a few constraints and=20 --> > I am willing to relax each of them by degrees I have a --> > very complex relaxation problem to express. -->=20 --> Well not so sure ... Let's wait for the meeting in Paris to=20 --> have an open discussion. I'd be happy to provide some ideas. --> Actually one could point out that such constraint relaxation=20 --> are used TODAY in operational networks (with CSPF). One could point that out, if one wants to show that having=20 a PCC make separate requests is the right way to go. I was under the impression you were arguing the opposition point of view. In the CSPF case you identify, the Traffic Engineer is both a PCC and a PCE and - with respect to the relaxation mode, it is much more likely to act like a PCC than a PCE. In other words, given a requirement for TE tunnel routing, it will=20 most likely complete a computation based on a single set of constraints and - if that fails - it may elect to relax the path requirements and try again with different constraints. But this is the whole point. When the PCE is co-located this can be = done without introducing substantial delays ... Conversely, think of a = PCE receiving a burst of requests from tens of PCCs after a network = failure ... this is precisely one of the aspects that I want to = optimize. This is essentially PCC behavior. Pushing this behavior into the PCE saves on external messaging overhead, but at a huge cost in complexity. Now, instead of having a self-contained entity (the PCC) deciding how next to proceed in getting a=20 Path (should any attempt fail), it must communicate a decision=20 making process to a delegate (the PCE) for every Path request - irrespective of whether or not that Path Request would fail. Unless the decision making options are very limited, this must impose a higher level of processing on the PCE just to decode, store and - eventually - act on the decision making process. I doubt that the communication overhead is the bottle-neck for PCE-PCC transactions, or the network over which they transpire. I also strongly suspect that deployments will tend toward more PCCs than PCEs, so - assuming that (for example) there are ten times as many PCCs as PCEs - what is the advantage gained by pushing the work of 1,000 PCCs onto 100 PCEs,=20 =09 no no ... we do not push the work of 1,000 PCCs onto 100 PCEs ... by = supporting such constraint relaxation approach you drastically reduce = the processing load on PCEs. Jumping to the end of this email (considering the text provided = above). especially if you=20 assume that most path requests will be satisfied prior to a PCC=20 traversal of the decision tree. -->=20 --> > --> > This is a problem that it is very easy for the PCC to =20 --> > handle by issuing successive requests, but very hard for=20 --> > the PCC to communicate to the PCE in a single request. -->=20 --> I do not think that it is hard for the PCC to communicate=20 --> to the PCE in a single request. You miss the point. If "communication" was easy, you wouldn't have started this discussion, and I wouldn't be continuing it. :-) Let's say that PCC X follows this scheme for one subset of its requests: scheme (a) Request a path with constraints A, B and C. On failure for A, request a path with constraint A1 that still satisfies B and C. On failure for A1, B or C, fail. To cut down on communication overhead, we could communicate this decision making policy to the PCE and make a single request that either succeeds or fails according to this policy. But this PCC (or another) also has a decision making schemes as follows for other types of services: scheme (b) Request a path with constraint A, C and D. On failure for C, request a path with constraints A and D only On failure for A or D, fail. scheme (c) Request a path with constraints B, C and D. On failure (for B, C or D) request an unconstrained shortest path. ... and so on ... Hence, given any arbitrary number of potential constraints, the number of possible decision making policies we need to define is clearly combinatorial (i.e. - NP) in the number of possible constraints (and possible relaxations of each). However, if we do not cover all of the possibilities, then we constrain the services that our customers can sell, their ability to differentiate themselves from their competitors and even the service pricing structures that are available to their customers in turn. To eliminate this concern, all we need to do is define a language for describing a decision making process. Done much work in the area of defining languages like this? :-) -->=20 --> > --> > So, I'd like to see some text from SPs on this subject=20 --> > before we add anything to the requirements I-D. --> > -->=20 --> I think that the DT is working on it. So, this is confusing. Are you saying that it's out of the hands of the WG because the authors are taking this work on anyway? /Chair Hat/ I just meant that the DT was working on the new revision of = draft-ietf-pce-comm-protocol-gen-reqs with the intention to cover that = aspect for WG input (this new rev has now been published). As you know, = by definition, a Working Group document is owned by the Working Group.=20 Your comments are of course more than welcome.=20 /Chair hat removed/ We may just want to sit down in Paris and discuss more on this if you = will. JP. -->=20 --> Cheers, -->=20 --> JP. -->=20 --> > Cheers, --> > Adrian --> > --> > --- [SNIP] --- =09 ________________________________ =09 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce =09 ------_=_NextPart_001_01C59113.7CB72CA4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Eric,
 
Please note that I was not discussing here = whether there is=20 a consensus or not and was just trying to explain a = bit more=20 the strong motivations for such requirement...
 
Anyway let's discuss this point deeper in=20 Paris
 
Thanks,
 
JL
 
 

De : Gray, Eric=20 [mailto:Eric.Gray@marconi.com]
Envoy=E9 : lundi 25 = juillet 2005=20 13:29
=C0 : LE ROUX Jean-Louis RD-CORE-LAN; Igor Bryskin; = JP=20 Vasseur; Gray, Eric
Cc : = pce@ietf.org
Objet : RE:=20 [Pce] Requirement for less-constrained=20 pathindraft-ietf-pce-comm-protocol-gen-reqs-00.txt

I=20 think the point here is that there was absolutely no consensus to = include this=20 in the
PCE=20 protocol requirements.
 
One of=20 the WG chairs - JP - asked if this should be included.  A highly = polar=20 discussion
followed in which several people weighed in against doing=20 so.
 
The=20 fact that it may seem like a good idea to the author(s) is insufficient = reason=20 to put
it in=20 the draft, once the draft has become a working group=20 document.
 
Therefore, lacking overwhelming indications that a consensus = does exist=20 to put it in the
working group's draft, the author(s) should remove=20 it.
 
--
Eric
-----Original Message-----
From: LE ROUX Jean-Louis = RD-CORE-LAN = [mailto:jeanlouis.leroux@francetelecom.com]
Sent:=20 Monday, July 25, 2005 4:45 AM
To: Igor Bryskin; JP Vasseur; = Gray,=20 Eric
Cc: pce@ietf.org
Subject: RE: [Pce] = Requirement for=20 less-constrained=20 = pathindraft-ietf-pce-comm-protocol-gen-reqs-00.txt

Hi Igor, all
 
Please see inline for some=20 comments,

De : = pce-bounces@lists.ietf.org=20 [mailto:pce-bounces@lists.ietf.org] De la part de Igor=20 Bryskin
Envoy=E9 : mardi 19 juillet 2005 = 17:41
=C0 :=20 JP Vasseur; Gray, Eric
Cc : = pce@ietf.org
Objet :=20 Re: [Pce] Requirement for less-constrained=20 = pathindraft-ietf-pce-comm-protocol-gen-reqs-00.txt

JP.
 
As I have indicated earlier I don't = believe that=20 the complexity associated with signaling of constraint relaxation = strategy=20 justifies the results.
[JLLR] Please don't make things more complex than = they are=20 in practical operational cases...
 
A=20 practical case, that is deployed btw, is SRLG exclusion in = FRR=20 bypass tunnel path computation:
The=20 operator wants a path that excludes a set of SRLGs, and if this path = cannot be=20 found he wants a path that excludes the maximum number of = SRLGs in=20 this set. Unfortunately the PCC cannot guess this best relaxed = set=20 and for instance if #SRLG =3D 4 this may lead =  to 16=20 requests :-(
Conversely the PCE can run an algorithm = that will=20 return a path maximizing the number of excluded = SRLGs.
This=20 is a simple case where less constrained paths are highly=20 valuable.
 
Another simple case is "bounded delay = bandwidth=20 constrained" path computation:
If=20 the path cannot be found, I want the PCE to provide me a bandwidth = constrained=20 path with a relaxed delay bound
or a=20 delay bounded path with a relaxed bandwidth = constraint. Unfortunately I=20 cannot guess these relaxed values, and it sound = really
valuable, and not so complex (there are = highly=20 efficient heuristics) for the PCE to perform such=20 relaxation....
 
 Most of the constraints are = non-boolean,=20 and it is difficult IMO to provide a simple yet flexible way for a PCC = to=20 articulate the desired way of relaxation wrt each of the=20 constraints.
[JLLR] In practical operational cases = you won't have a=20 lot of constraints, so this sounds quite simple to articulate = such=20 relaxation (one could use a set of bits=20 vectors).
 
  And what if the constraints = are not=20 independent? For instance, what if a PCC wants to get best = tradeoff of=20 several constraints ?
[JLLR] We could also find a simple way to = express these=20 cases (again with a vector encoding dependent constraints to be=20 relaxed...)
My suggestion is to start with = allowing for PCC=20 to specify in a single request a set of mandatory constraints and an = ordered=20 list of sets of relaxable constraints: first, use the first set in the = list (+=20 mandatory, of course), if path computation fails - use the second one = and so=20 forth.
[JLLR] Do=20 you include constraint values or just identify constraints to be = relaxed?=20
If=20 the latter, then we fully agree.
 
 This is a much simpler way of = doing the=20 constraint relaxation and could be just good enough, = although it=20 makes the size of requests and response larger.
[JLLR] Simpler = than which=20 way?? 
 
By the way, do you remember = that sometime=20 ago I suggested to design the PCC-PCE protocol in a such a way where = each=20 request/response is a BASIC style program
  that could be interpreted =  by both=20 PCC and PCE? The intention was to provide a very flexible way for a = PCE to=20 describe its capabilities and introduce new ones, and for PCC to take = the most=20 of the PCE and specify what exactly it wants from the requested = path=20 computation (what constraints and optimization criterias to be = used and=20 how)
 
[JLLR] 
Note that this has = already been=20 proposed by Kireeti two years ago to pass constraints in=20 RSVP
(see=20 http://www.watersprings.org/pub/id/draft-kompella-mpls-rsvp-cons= traints-01.txt)
I have major concerns regarding the = complexity=20 of this approach. Please = note that=20 the PCE may run quite complex algorithms (e.g. multi-constraint = heuristic=20 algorithms, or, yet to be added in the charter, steiner tree = heuristics,=20 requiring CPU intensive computation...). Do you also assume passing = the code=20 for such complex algorithms??? This=20 would drastically complexify PCC=20 operations....
 
It would be very easy to = support the=20 constraint relaxation strategies no matter how complex they are = :=3D)
[JLLR] Ah yes of = course if=20 you put a lot of complexity on the PCC=20 :-(
 
I agree with you that this would provide = a huge=20 flexibility in the way to express = constraints,
but think about the standardization = effort that=20 this would imply (unless you want to rely on Java applets=20 :-))
 
Best Regards,
 
JL
 
Cheers,
Igor
----- Original Message -----
From:=20 JP = Vasseur=20
Sent: Tuesday, July 19, 2005 = 9:47=20 AM
Subject: Re: [Pce] = Requirement for=20 less-constrained path = indraft-ietf-pce-comm-protocol-gen-reqs-00.txt

Hi Eric,=20

On Jul 18, 2005, at 3:57 PM, Gray, Eric wrote:
JP,

    From your = earlier=20 response, I see that you're aiming 
at the "greater of two evil" = solutions.  Tch, tch, tch!!

    Please see = below...

--> -----Original Message-----
--> From: JP Vasseur [mailto:jvasseur@cisco.com]
--> Sent: Thursday, July 14, 2005 = 9:19=20 PM
--> To: Adrian Farrel
--> Cc: Gray, Eric; pce@ietf.org
--> Subject: Re: [Pce] Requirement = for=20 less-constrained path
-->=20 indraft-ietf-pce-comm-protocol-gen-reqs-00.txt
--> 
--> 
--> 
--> On Jul 14, 2005, at 12:26 PM, = Adrian=20 Farrel wrote:
--> 
--> > I want to pitch in on this = thread=20 because I think (I) see 
--> > where both JP and Eric are = coming=20 from. JP's proposals have
--> > the potential to = significantly reduce=20 the PCE processing 
--> > and cut down number of = PCC-PCE=20 transactions, but they also
--> > have the ability to = massively=20 increase the processing and  
--> > the size of the PCC-PCE=20 transactions.
--> >
--> 
--> that said, it it pretty = straightforward to=20 see that the benefits  
--> undoubtedly outweigh the = drawbacks. The=20 request processing is  
--> definitely negligible compared = to the=20 communication overhead.

This is the point of obvious = disagreement.


Good so at least we agree on the disagreement ;-)

--> Actually, it could be shown that = the non=20 support of such capability  
--> would have a drastic scalability = impact on=20 the solution especially  
--> upon resource contention.

Only if you assume that communication = is the=20 bottleneck.

Just try to decompose the various steps occurring during a = path=20 computation (request/reply) especially when the constraints cannot = be fully=20 satisfied:
1) Path computation request sent to the PCE
2) PCE processing which includes:
    - queueing delay (PCE scheduler)
    - service time (PCE scheduler)
3) Path computation reply sent to the PCE.

Then repeat such cycle until a path is successfully=20 computed.

Now consider the two cases where:
A- The PCC has to send multiple requests trying to guess the = set of=20 constraints that could lead to a successful path computation.
B- The PCC specifies a set of rules and the PCE tries to find a = path by=20 means of a single request

A few important facts:

- In case of A, when the constraint is not a boolean (e.g. = bandwidth),=20 it is really a guess and even an approach based = on dichotomy would=20 unavoidably lead to a non negligible number of cycles. 
- Some path computation algorithms have the capability to relax = constraints "on the fly" thus saving CPU cycles compared to = serialized path=20 computations. 
- Without entering into some gory details about network = analysis,=20 queueing systems and implementation-specific algorithms, try to = decompose=20 the steps 1), 2) and 3), and you'll easily identify where the = bottlenecks=20 are when comparing the two approaches (especially 2).
- The set of rules does not have = to be=20 complex (see an example below) and more importantly does not have = to be=20 used when inappropriate

Reality is that messaging only becomes = a=20 bottleneck if
message processing is excessively = complex and/or=20 it is 
done in a poorly thought out way. If = the=20 communication
issue is not with messaging, then what = is=20 it?


I'm of course not suggesting to design poorly thought out and=20 excessively complex messaging ;-)

--> 
--> > Thus we need to be quite = careful in=20 the specification of the
--> > protocol requirements and = the=20 protocol itself. It is not OK
--> > for us to say that if an = individual=20 PCC is irresponsible or 
--> > stupid that is its problem, = because=20 such an implementation
--> > would break the = accessibility to the=20 PCE for other 'normal' 
--> > PCCs.
--> >
--> 
--> On this aspect, I do agree = !
--> 
--> > Unless there are "standard" = constraint back-off functions 
--> > it is hard to conceive of a = PCE=20 guessing the correct back-
--> > off for the PCC that issued = the=20 request. Note that the more 
--> > "speculative paths" the PCE = computes=20 the more CPU it uses.
--> 
--> Speculative paths is definitely = not an=20 option considering the 
--> number of permutations ... we = would=20 unavoidably quickly fall
--> into some NP-Complete issues ;-) = ... This=20 is why the suggestion 
--> is made to start some discussion = on the=20 hierarchical relaxation 
--> policy. Note that it does not = have to be=20 awfully complex ...

Here we have many things said in few = words. I=20 know, because I can
identify numerous points for both = agreement and=20 disagreement.  = :-)

The issue with permutations (and = NP-complete=20 issues) is one part
on which I think we agree.

The notion that a hierarchical = relaxation=20 approach avoids this is
one part on which I think we = disagree.

Finally, the "wish" that it does not = have to be=20 complex is quite
interesting.  The only way that it = will not be=20 complex, is if the
actual decision making process is very = simple in=20 every case. The
point of contention is the fact that - = while it=20 probably can be 
very simple in most cases - it will = almost=20 certainly not be 1) the
same in every case and 2) good enough = in every=20 case.


Ah here I fully agree with you (last paragraph ;-)). The goal = may not=20 be to design a solution that will address *all* cases and that will = be good=20 in *all* cases. 
As a system designer, I'd be very happy = if the=20 proposed solution solves the vast majority of the issues in an = simple way.=20 When not appropriate, just do not use it. Vendor implementations = should=20 be able to be flexible enough so that the operator could choose when = to use=20 such approach. See other similar examples with hierarchical BGP = policy=20 rules, ACLs, ... 

If a different hierarchical relaxation = policy=20 might apply under
different circumstances, then the = complexity of=20 the protocol is
going to be greater than the = combination of all=20 "simple cases".

If the approach is not "good enough", = then a PCC=20 is forced to
fall back on the multiple messages = approach.  Net gain: ~zero.


Indeed, we agree on the fact that we could make it awfully = complex=20 and consequently not practically usable. I could also come up = with many=20 such examples ... Conversely, one could easily come up with=20 *real*life*use*of*TE*scenario where such approach would be quite = useful.=20 *Again*, think of how Service Providers use TE today ... Let me give = you a=20 simple example here (which by the way would cover a good % of = current=20 needs):

Packet LSPs,
Two constraints: affinity=3DRED and bandwidth=3D10
The set of constraints cannot be fully satisfied because of = resource=20 contention.

Case A: The PCC sends multiple requests until a path can be=20 found.
Case B: The PCC sends one request (affinity=3DRED, = bandwidth=3D10) and=20 specifies to first relax the affinity, then find the = closest bandwidth=20 match. Note that a different policy may be adopted different LSP=20 types.

With such a simple example, you can easily see the benefit = of=20 B-
-> Reduced PCE processing (delay and service time)
-> Cut-down the number of transactions
-> Simple constraint relaxation rule

=3D> consequently reduced path computation delay

Again, I'm not claiming that all problems could be solved this = way and=20 that an operator should/could always use such hierarchical = constraints=20 approach but there are many circumstances whereby such approach = would be IMO=20 highly valuable.

Of course, I'll wait for service providers to confirm that=20 statement.

--> 
--> > So we must keep good = control on this.=20 It is a
--> > computational myth that it = is=20 possible to relax different  
--> > constraints on a
--> > single computational = pass.
--> 
--> Ah no ... there are several = constraints=20 for which 
--> constraint can be relaxed and = closest=20 match can be 
--> found in on-go.
--> 
--> That said, even if it were not = the case,=20 the solution 
--> would still be valuable to = cut-down the=20 communication 
--> overhead and amount of = processing=20 signaling be the 
--> PCE's scheduler.
--> 
--> > In fact, the question = "where did my=20 computation fail"
--> > is notoriously impossible = to answer=20 except with the =20  
--> > response "in the = network".
--> >
--> > Thus we should give full = control to=20 the PCC, and let 
--> > the PCE choose to supply = less=20 information if it thinks  =  
--> > that the PCC is asking too = much. This=20 control includes:
--> >
--> > a. The ability to say "this = or=20 nothing"
--> > b. The ability to say "tell = me what=20 constraints I
--> >    might relax to = get a=20 path"
--> > c. The ability to say "give = me n=20 alternate paths with 
--> >    with your = choice of=20 relaxed constraints" (c. is 
--> >    like b but with = the paths=20 supplied, and it is 
--> >    important to = control the=20 number)
--> > d. A way to state which = constraints=20 may be relaxed 
--> >    absolutely = (this is=20 easy)
--> > e. A way to replace one = constraint=20 supplied by the  
--> >    PCC with = another also=20 supplied by the PCC
--> > f. A way to specify an = ordering for=20 relaxation in 
--> >    recomputation=20 attempts.
--> >
--> > My feeling is that e might = be=20 satisfied in the protocol  
--> > simply by listing the same = object=20 multiple times. But f
--> > is very messy. As soon as I = have a=20 few constraints and 
--> > I am willing to relax each = of them by=20 degrees I have a
--> > very complex relaxation = problem to=20 express.
--> 
--> Well not so sure ... Let's wait = for the=20 meeting in Paris to 
--> have an open discussion. I'd be = happy to=20 provide some ideas.
--> Actually one could point out = that such=20 constraint relaxation 
--> are used TODAY in operational = networks=20 (with CSPF).

One could point that out, if one wants = to show=20 that having 
a PCC make separate requests is the = right way to=20 go. I was
under the impression you were arguing = the=20 opposition point
of view.

In the CSPF case you identify, the = Traffic=20 Engineer is both
a PCC and a PCE and - with respect to = the=20 relaxation mode,
it is much more likely to act like a = PCC than a=20 PCE. In other
words, given a requirement for TE = tunnel routing,=20 it will 
most likely complete a computation = based on a=20 single set of
constraints and - if that fails - it = may elect to=20 relax the
path requirements and try again with = different=20 constraints.


But this is the whole point. When the PCE is co-located this = can be=20 done without introducing substantial delays ... Conversely, think of = a PCE=20 receiving a burst of requests from tens of PCCs after a network = failure ...=20 this is precisely one of the aspects that I want to = optimize.

This is essentially PCC behavior. = Pushing this=20 behavior into
the PCE saves on external messaging = overhead, but=20 at a huge
cost in complexity.  Now, instead of having = a=20 self-contained
entity (the PCC) deciding how next to = proceed in=20 getting a 
Path (should any attempt fail), it must = communicate a decision 
making process to a delegate (the PCE) = for every=20 Path request
- irrespective of whether or not that = Path=20 Request would fail.

Unless the decision making options are = very=20 limited, this must
impose a higher level of processing on = the PCE=20 just to decode,
store and - eventually - act on the = decision=20 making process.

I doubt that the communication overhead = is the=20 bottle-neck for
PCE-PCC transactions, or the network = over which=20 they transpire.
I also strongly suspect that = deployments will=20 tend toward more
PCCs than PCEs, so - assuming that (for = example)=20 there are ten
times as many PCCs as PCEs - what is = the=20 advantage gained by
pushing the work of 1,000 PCCs onto 100 = PCEs,=20

no no ... we do not push the work of 1,000 PCCs onto 100 PCEs = ... by=20 supporting such constraint relaxation approach you drastically = reduce the=20 processing load on PCEs.

Jumping to the end of this email (considering the text provided = above).

especially if you 
assume that most path requests will be = satisfied=20 prior to a PCC 
traversal of the decision tree.

--> 
--> >
--> > This is a problem that it = is very=20 easy for the PCC to  
--> > handle by issuing = successive=20 requests, but very hard for 
--> > the PCC to communicate to = the PCE in=20 a single request.
--> 
--> I do not think that it is hard = for the PCC=20 to communicate 
--> to the PCE in a single = request.

You miss the point.

If "communication" was easy, you = wouldn't have=20 started this
discussion, and I wouldn't be = continuing it.  :-)

Let's say that PCC X follows this = scheme for one=20 subset of its
requests:

scheme (a)
    Request a = path with=20 constraints A, B and C.
    On failure = for A,=20 request a path with constraint A1 that
        = still=20 satisfies B and C.
    On failure = for A1, B=20 or C, fail.

To cut down on communication overhead, = we could=20 communicate
this decision making policy to the PCE = and make a=20 single
request that either succeeds or fails = according=20 to this policy.

But this PCC (or another) also has a = decision=20 making schemes as
follows for other types of = services:

scheme (b)
    Request a = path with=20 constraint A, C and D.
    On failure = for C,=20 request a path with constraints A and D
       =20 only
    On failure = for A or=20 D, fail.

scheme (c)
    Request a = path with=20 constraints B, C and D.
    On failure = (for B, C=20 or D) request an unconstrained shortest
       =20 path.

... and so on ...

Hence, given any arbitrary number of = potential=20 constraints, the
number of possible decision making = policies we=20 need to define
is clearly combinatorial (i.e. - NP) in = the=20 number of possible
constraints (and possible relaxations = of=20 each).

However, if we do not cover all of the=20 possibilities, then we
constrain the services that our = customers can=20 sell, their ability
to differentiate themselves from their=20 competitors and even the
service pricing structures that are = available to=20 their customers
in turn.

To eliminate this concern, all we need = to do is=20 define a language
for describing a decision making = process.  Done much work in = the
area of defining languages like = this?  :-)

--> 
--> >
--> > So, I'd like to see some = text from=20 SPs on this subject 
--> > before we add anything to = the=20 requirements I-D.
--> >
--> 
--> I think that the DT is working = on=20 it.

So, this is confusing. Are you saying = that it's=20 out of the hands
of the WG because the authors are = taking this=20 work on anyway?


/Chair Hat/

I just meant that the DT was working on the new revision of=20 draft-ietf-pce-comm-protocol-gen-reqs with the intention to cover = that=20 aspect for WG input (this new rev has now been published). As you = know, by=20 definition, a Working Group document is owned by the Working=20 Group. 

Your comments are of course more than welcome. 

/Chair hat removed/

We may just want to sit down in Paris and discuss more on this = if you=20 will.

JP.

--> 
--> Cheers,
--> 
--> JP.
--> 
--> > Cheers,
--> > Adrian
--> >
--> > --- [SNIP] ---

_______________________________________________
Pce = mailing=20 = list
Pce@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce<= BR> ------_=_NextPart_001_01C59113.7CB72CA4-- --===============0809387711== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============0809387711==-- From pce-bounces@lists.ietf.org Mon Jul 25 11:09:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx4Zt-00028o-JV; Mon, 25 Jul 2005 11:09:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx4Zp-0001l9-AT for pce@megatron.ietf.org; Mon, 25 Jul 2005 11:09:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28472 for ; Mon, 25 Jul 2005 11:09:07 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dx54h-0005w5-5t for pce@ietf.org; Mon, 25 Jul 2005 11:41:03 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id j6PF8vYH001295; Mon, 25 Jul 2005 11:08:57 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA26233; Mon, 25 Jul 2005 11:08:53 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id ; Mon, 25 Jul 2005 11:08:52 -0400 Message-ID: <313680C9A886D511A06000204840E1CF0C885D46@whq-msgusr-02.pit.comms.marconi.com> From: "Gray, Eric" To: "'JP Vasseur'" Subject: RE: [Pce] Requirement for less-constrained pathindraft-ietf-pce-c omm-protocol-gen-reqs-00.txt Date: Mon, 25 Jul 2005 11:08:49 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.3 (/) X-Scan-Signature: e5bfa71b340354e384155def5e70b13b Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2027086081==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============2027086081== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5912A.B402BF20" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C5912A.B402BF20 Content-Type: text/plain; charset="iso-8859-1" JP, Thanks for clarifying this. -- Eric -----Original Message----- From: JP Vasseur [mailto:jvasseur@cisco.com] Sent: Monday, July 25, 2005 7:47 AM To: Gray, Eric Cc: 'LE ROUX Jean-Louis RD-CORE-LAN'; Igor Bryskin; pce@ietf.org Subject: Re: [Pce] Requirement for less-constrained pathindraft-ietf-pce-c omm-protocol-gen-reqs-00.txt Hi Eric, / Chair Hat / On Jul 25, 2005, at 7:28 AM, Gray, Eric wrote: I think the point here is that there was absolutely no consensus to include this in the PCE protocol requirements. One of the WG chairs - JP - asked if this should be included. A highly polar discussion followed in which several people weighed in against doing so. Indeed, I asked to the WG whether there was a need for such capability. The fact that it may seem like a good idea to the author(s) is insufficient reason to put it in the draft, once the draft has become a working group document. Correct, no WG consensus has been reached on this issue as of now. Several ones were opposed to it, several other ones were in favor. Therefore, lacking overwhelming indications that a consensus does exist to put it in the working group's draft, the author(s) should remove it. Here is the plan: (1) Ask for a vote within the WG on this issue. I would suggest some discussion in Paris followed by discussion on the mailing list. The next revision of the protocol requirement will reflect the WG consensus on this particular aspect. (2) For the next revision, the authors of the PCEP spec mentioned that they would remove the "less-constrained path computation" from the PCEP specification. "Less-constrained path computation" aspects will potentially be discussed in another ID, should there be a WG consensus. Note that I would like us to make progress of the basic functionalities first (such as the PCE requirement ID, architecture, PCE communication protocol, ...) so as to meet our Milestones. More advanced features could be discussed in a second step. Thanks. JP. ------_=_NextPart_001_01C5912A.B402BF20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
JP,
 
    Thanks for clarifying=20 this.
 
--
Eric
-----Original Message-----
From: JP Vasseur=20 [mailto:jvasseur@cisco.com]
Sent: Monday, July 25, 2005 = 7:47=20 AM
To: Gray, Eric
Cc: 'LE ROUX Jean-Louis = RD-CORE-LAN';=20 Igor Bryskin; pce@ietf.org
Subject: Re: [Pce] Requirement = for=20 less-constrained pathindraft-ietf-pce-c=20 omm-protocol-gen-reqs-00.txt

Hi Eric,

/ Chair Hat /

On Jul 25, 2005, at 7:28 AM, Gray, Eric wrote:
I think the point = here is that=20 there was absolutely no consensus to include this in=20 the
PCE protocol=20 requirements.
 
One of the WG chairs = - JP -=20 asked if this should be included.  A highly polar=20 discussion
followed in which = several=20 people weighed in against doing so.
 

Indeed, I asked to the WG whether there = was a need=20 for such capability.

The fact that it may = seem like=20 a good idea to the author(s) is insufficient reason to=20 put
it in the draft, = once the draft=20 has become a working group document.
 

Correct, no WG consensus has been reached on this issue as of = now.=20 Several ones were opposed to it, several other ones were in = favor.

Therefore, lacking = overwhelming=20 indications that a consensus does exist to put it in=20 the
working group's = draft, the=20 author(s) should remove it.
 

Here is the plan:
(1) Ask for a vote within the WG on this = issue. I=20 would suggest some discussion in Paris followed by discussion on the = mailing=20 list. The next revision of the protocol requirement will reflect = the WG=20 consensus on this particular aspect.
(2) For the next revision, the authors of = the PCEP=20 spec mentioned that they would remove the "less-constrained path = computation"=20 from the PCEP specification. "Less-constrained path computation" = aspects will=20 potentially be discussed in another ID, should there be a WG=20 consensus.

Note = that I would=20 like us to make progress of the basic functionalities first (such as = the PCE=20 requirement ID, architecture, PCE communication protocol, ...) so as = to meet=20 our Milestones. More advanced features could be discussed in a second = step.
Thanks.

JP.

------_=_NextPart_001_01C5912A.B402BF20-- --===============2027086081== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============2027086081==-- From pce-bounces@lists.ietf.org Tue Jul 26 04:27:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxKmT-00037B-V3; Tue, 26 Jul 2005 04:27:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxKmS-00035v-0j for pce@megatron.ietf.org; Tue, 26 Jul 2005 04:27:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27532 for ; Tue, 26 Jul 2005 04:27:14 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxLHS-0002l8-70 for pce@ietf.org; Tue, 26 Jul 2005 04:59:19 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id j6Q8aWUB021365 for ; Tue, 26 Jul 2005 01:36:32 -0700 (MST) Received: from zin24exm03.corp.mot.com (zin24exm03.corp.mot.com [10.232.0.10]) by il06exr01.mot.com (8.13.1/8.13.0) with ESMTP id j6Q8XOLk017253 for ; Tue, 26 Jul 2005 03:33:26 -0500 (CDT) Received: by zin24exm03.corp.mot.com with Internet Mail Service (5.5.2657.72) id <34B801QC>; Tue, 26 Jul 2005 13:56:59 +0530 Message-ID: <45AAAAED8B10F547878F52FE15C57C5D01C4E57B@zin24exm03.corp.mot.com> From: Vivek Dubey-G20041 To: pce@ietf.org Date: Tue, 26 Jul 2005 13:56:58 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: Subject: [Pce] draft-ietf-pce-architecture-01 X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi, In case of "External PCE" model, should there be a provision provided at the PCE to protect it against flood of path computation requests from a particular PCC(in case of malfunctioning). Thanks Vivek _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue Jul 26 05:53:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxM80-0004tt-Q4; Tue, 26 Jul 2005 05:53:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxM80-0004to-71 for pce@megatron.ietf.org; Tue, 26 Jul 2005 05:53:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02624 for ; Tue, 26 Jul 2005 05:53:33 -0400 (EDT) Received: from mail120.messagelabs.com ([216.82.255.211]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1DxMcy-0005O7-77 for pce@ietf.org; Tue, 26 Jul 2005 06:25:39 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-11.tower-120.messagelabs.com!1122371601!4427011!1 X-StarScan-Version: 5.4.15; banners=-,-,- X-Originating-IP: [192.128.133.132] Received: (qmail 22245 invoked from network); 26 Jul 2005 09:53:21 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (192.128.133.132) by server-11.tower-120.messagelabs.com with SMTP; 26 Jul 2005 09:53:21 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.88) by attrh3i.attrh.att.com (7.2.052) id 42E3BC2B00036B32; Tue, 26 Jul 2005 05:53:20 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] draft-ietf-pce-architecture-01 Date: Tue, 26 Jul 2005 04:53:20 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA09FA914D@KCCLUST06EVS1.ugd.att.com> Thread-Topic: [Pce] draft-ietf-pce-architecture-01 Thread-Index: AcWRvA/Rx92cu662R8yeYkFC+aq9zAAC0m1g From: "Ash, Gerald R \(Jerry\), ALABS" To: "Vivek Dubey-G20041" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Vivek, > In case of "External PCE" model, should there be a provision=20 > provided at the PCE to protect it against flood of path > computation requests from a particular PCC (in case of > malfunctioning). See Section 6.1.8 of the PCE communication protocol (PCEP) generic requirements http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protocol-gen-req s-01.txt: " In some cases (e.g. after link failure), a large number of PCCs may simultaneously send requests to a PCE, leading to a potential saturation of the PCEs. The PCEP or the transport protocol it uses MUST properly handle such overload situations without a significant decrease in performance, such as through throttling of such requests." Thanks, Jerry _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue Jul 26 19:14:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxYdD-0004HQ-7u; Tue, 26 Jul 2005 19:14:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxYdB-0004EY-BI for pce@megatron.ietf.org; Tue, 26 Jul 2005 19:14:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03130 for ; Tue, 26 Jul 2005 19:14:34 -0400 (EDT) Received: from webmail.movaz.com ([65.205.166.188] helo=jera.movaz.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxZ8J-0005iv-7x for pce@ietf.org; Tue, 26 Jul 2005 19:46:48 -0400 Received: from movaz-hw.movaz.com (movaz-hw.atlanta.movaz.com [172.16.8.183]) by jera.movaz.com (Postfix) with ESMTP id 932FA1733; Tue, 26 Jul 2005 19:14:14 -0400 (EDT) Received: from lb.movaz.com (localhost [127.0.0.1]) by movaz-hw.movaz.com (Postfix) with ESMTP id 07CF8AF6F; Tue, 26 Jul 2005 19:14:11 -0400 (EDT) Message-Id: <6.2.3.4.2.20050726191150.03f4f040@mo-ex1> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Tue, 26 Jul 2005 19:14:09 -0400 To: "JP Vasseur" , "Adrian Farrel" , "Ash, Gerald R (Jerry), ALABS" From: Lou Berger Subject: Re: [Pce] Changes in the new revision of the architecture I-D In-Reply-To: <84945647-6729-4394-A308-17C1D3C79589@cisco.com> References: <154701c58d1f$ef014e70$d6849ed9@Puppy> <42E239D1.9010907@psg.com> <84945647-6729-4394-A308-17C1D3C79589@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org At 09:24 AM 7/23/2005, JP Vasseur wrote: >We think that the ID is pretty stable in term of technical content. >As Adrian pointed out, there might be some editorial work to be done >before WG last call. So the short answer is "as soon as possible". > >Thanks. > >JP. JP/Adrian/Jerry, As you say, the draft has come together very nicely. The primary comment I have on the document is related to how policy is presented in the draft: The draft does mention policy in multiple places, but these mentions are more "in-passing" than as major component. It seems to me that Policy and the ability to support path computation based on, or influenced by policies, must be a major part of the PCE architecture. I do agree with draft in that "policy between domains and between PCEs, and is achieved through configuration not through protocol communications." That said, the PCC-PCE and PCE-PCE communication protocols must support the communication of all information needed to support the installed policies, as well as support any policy triggered transactions that may result due to a policy (or change in policy). Also, in order to deliver viable policy to PCE, policy must not be an after thought. (Consider how successful original RSVP was with bringing in policy after the core work was complete.) In short, I think policy should be more prominent in the draft and in the PCE architecture. I suggest to: - add policy related motivations in section 4, - add a policy component to the PCE architecture(s) presented in section 5, - add a full fledged Policy sub-section to section 6 that is separate from confidentiality. - and add a policy related evaluation metric to section 7. Please let me know what you think. I'll put together some specific text for fodder.... Lou _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Jul 27 09:20:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxlpf-0006IT-Bo; Wed, 27 Jul 2005 09:20:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxlpd-0006IA-IR for pce@megatron.ietf.org; Wed, 27 Jul 2005 09:20:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26802 for ; Wed, 27 Jul 2005 09:20:19 -0400 (EDT) Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxmKt-0004uK-36 for pce@ietf.org; Wed, 27 Jul 2005 09:52:40 -0400 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate5.mot.com (8.12.11/Motgate5) with ESMTP id j6RDQiok019062 for ; Wed, 27 Jul 2005 06:26:44 -0700 (MST) Received: from zin24exm03.corp.mot.com (zin24exm03.corp.mot.com [10.232.0.10]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id j6RDPonc010305 for ; Wed, 27 Jul 2005 08:25:51 -0500 (CDT) Received: by zin24exm03.corp.mot.com with Internet Mail Service (5.5.2657.72) id <34B80Y32>; Wed, 27 Jul 2005 18:50:14 +0530 Message-ID: <45AAAAED8B10F547878F52FE15C57C5D01D074EE@zin24exm03.corp.mot.com> From: Vivek Dubey-G20041 To: pce@ietf.org Subject: RE: [Pce] draft-ietf-pce-architecture-01 Date: Wed, 27 Jul 2005 18:50:08 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Jerry, Thanks for the information. Further "throttling of such requests" takes care of "saturation of PCE" in terms of total path computation requests. Malfunctioning of one/more PCC (resulting in overloading condition) should not result in throttling of requests from other PCCs (as PCE is a shared resource among multiple PCCs). Morever PCE should serve multiple PCCs according to some fairness policy avoiding one PCC to congest PCE as a resource. Thanks Vivek -----Original Message----- From: Ash, Gerald R \(Jerry\), ALABS [mailto:gash@att.com] Sent: Tuesday, July 26, 2005 3:23 PM To: Vivek Dubey-G20041; pce@ietf.org Cc: Ash, Gerald R \(Jerry\), ALABS Subject: RE: [Pce] draft-ietf-pce-architecture-01 Vivek, > In case of "External PCE" model, should there be a provision > provided at the PCE to protect it against flood of path > computation requests from a particular PCC (in case of > malfunctioning). See Section 6.1.8 of the PCE communication protocol (PCEP) generic requirements http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protocol-gen-req s-01.txt: " In some cases (e.g. after link failure), a large number of PCCs may simultaneously send requests to a PCE, leading to a potential saturation of the PCEs. The PCEP or the transport protocol it uses MUST properly handle such overload situations without a significant decrease in performance, such as through throttling of such requests." Thanks, Jerry _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Jul 27 10:00:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxmSv-0000rp-QY; Wed, 27 Jul 2005 10:00:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxmSv-0000rh-2k for pce@megatron.ietf.org; Wed, 27 Jul 2005 10:00:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29584 for ; Wed, 27 Jul 2005 10:00:54 -0400 (EDT) Received: from webmail.movaz.com ([65.205.166.188] helo=jera.movaz.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxmyB-0006BM-AD for pce@ietf.org; Wed, 27 Jul 2005 10:33:16 -0400 Received: from ib (unknown [172.16.24.122]) by jera.movaz.com (Postfix) with SMTP id 5DBF61797; Wed, 27 Jul 2005 10:00:42 -0400 (EDT) Message-ID: <009701c592b3$94409970$7a1810ac@movaz.com> From: "Igor Bryskin" To: "JP Vasseur" , "Adrian Farrel" , "Ash, Gerald R (Jerry), ALABS" , "Lou Berger" References: <154701c58d1f$ef014e70$d6849ed9@Puppy> <42E239D1.9010907@psg.com><84945647-6729-4394-A308-17C1D3C79589@cisco.com> <6.2.3.4.2.20050726191150.03f4f040@mo-ex1> Subject: Re: [Pce] Changes in the new revision of the architecture I-D Date: Wed, 27 Jul 2005 10:00:42 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: 7bit Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi, I think Lou has just brought up a very important discussion. A PCE can apply a policy for a particular path computation request only IFF it can identify original requestor. Consider the situation when a single request involves 2 PCEs: PCC<=>PCE1<=>PCE2. PCE1 can identify the PCC and apply the polices for this PCC or this class of PCCs. However, PCE2 will not be capable to identify PCC ( we seem to agree already that PCC-PCE and PCE-PCE is the same protocol, hence PCE2 will see PCE1 as PCC), and will apply a wrong policy. For instance, it may invoke a computationally expensive algorithm, which it won't do if the PCC requested computation directly from PCC2. So, in the architecture document the reasons should be described why the identity of the original requestor should be available for all PCEs involved in particular path computation request. Secondly, the same point should be reflected in the path computation communication protocol requirements. Igor ----- Original Message ----- From: "Lou Berger" To: "JP Vasseur" ; "Adrian Farrel" ; "Ash, Gerald R (Jerry), ALABS" Cc: Sent: Tuesday, July 26, 2005 7:14 PM Subject: Re: [Pce] Changes in the new revision of the architecture I-D > At 09:24 AM 7/23/2005, JP Vasseur wrote: > >We think that the ID is pretty stable in term of technical content. > >As Adrian pointed out, there might be some editorial work to be done > >before WG last call. So the short answer is "as soon as possible". > > > >Thanks. > > > >JP. > > JP/Adrian/Jerry, > As you say, the draft has come together very nicely. The > primary comment I have on the document is related to how policy is > presented in the draft: > > The draft does mention policy in multiple places, but these mentions > are more "in-passing" than as major component. It seems to me that > Policy and the ability to support path computation based on, or > influenced by policies, must be a major part of the PCE > architecture. I do agree with draft in that "policy between domains > and between PCEs, and is achieved through configuration not through > protocol communications." That said, the PCC-PCE and PCE-PCE > communication protocols must support the communication of all > information needed to support the installed policies, as well as > support any policy triggered transactions that may result due to a > policy (or change in policy). Also, in order to deliver viable > policy to PCE, policy must not be an after thought. (Consider how > successful original RSVP was with bringing in policy after the core > work was complete.) > > In short, I think policy should be more prominent in the draft and in > the PCE architecture. > > I suggest to: > - add policy related motivations in section 4, > - add a policy component to the PCE architecture(s) presented in section 5, > - add a full fledged Policy sub-section to section 6 that is separate > from confidentiality. > - and add a policy related evaluation metric to section 7. > > Please let me know what you think. > > I'll put together some specific text for fodder.... > > Lou > > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Jul 27 10:17:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxmhR-0004sF-UT; Wed, 27 Jul 2005 10:15:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxmhQ-0004rX-3n for pce@megatron.ietf.org; Wed, 27 Jul 2005 10:15:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01270 for ; Wed, 27 Jul 2005 10:15:53 -0400 (EDT) Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxnCd-0006eY-IW for pce@ietf.org; Wed, 27 Jul 2005 10:48:15 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Wed, 27 Jul 2005 16:14:43 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Pce] Changes in the new revision of the architecture I-D Date: Wed, 27 Jul 2005 16:14:42 +0200 Message-ID: Thread-Topic: [Pce] Changes in the new revision of the architecture I-D Thread-Index: AcWSs63GXL69h5PpRnKAsVQHib7zVgAAGX7w From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "Igor Bryskin" , "JP Vasseur" , , "Ash, Gerald R \(Jerry\), ALABS" , "Lou Berger" X-OriginalArrivalTime: 27 Jul 2005 14:14:43.0941 (UTC) FILETIME=[89412150:01C592B5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Content-Transfer-Encoding: quoted-printable Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi Igor Please see inline=20 > -----Message d'origine----- > De : pce-bounces@lists.ietf.org=20 > [mailto:pce-bounces@lists.ietf.org] De la part de Igor Bryskin > Envoy=E9 : mercredi 27 juillet 2005 16:01 > =C0 : JP Vasseur; zzx-adrian@olddog.co.uk; Ash, Gerald R=20 > (Jerry), ALABS; Lou Berger > Cc : pce@ietf.org > Objet : Re: [Pce] Changes in the new revision of the architecture I-D >=20 > Hi, >=20 > I think Lou has just brought up a very important discussion. >=20 > A PCE can apply a policy for a particular path computation=20 > request only IFF it can identify original requestor. Consider=20 > the situation when a single request involves 2 PCEs:=20 > PCC<=3D>PCE1<=3D>PCE2. >=20 > PCE1 can identify the PCC and apply the polices for this PCC=20 > or this class of PCCs. However, PCE2 will not be capable to=20 > identify PCC ( we seem to agree already that PCC-PCE and=20 > PCE-PCE is the same protocol, hence PCE2 will see PCE1 as=20 > PCC) And where is the problem? Policy have a local PCC-PCE meaning PCE1 that sends a request to PCE2 is considered as a PCC, and PCE2 = applies the policy to PCE1 PCE1 offers a service to PCC, PCE2 offers a service to PCE1, To my mind policies must have a local client-server scope. Path requests have a local PCC-PCE scope. PCE2 doesn't care whether PCE1 request has been triggered by PCC request = to PCE1 or not. It serves a request from PCE1 and that's all... >, and will apply a wrong policy. For instance, it may=20 > invoke a computationally expensive algorithm, which it won't=20 > do if the PCC requested computation directly from PCC2. And what is the problem?, this is up to PCE1 to apply correct policies >=20 > So, in the architecture document the reasons should be=20 > described why the identity of the original requestor should=20 > be available for all PCEs involved in particular path=20 > computation request. A path computation request should IMHO have a local scope Multiple-PCE path computation should be considered as a cascade of=20 requests rather than the propagation of the same request, and local = PCC-PCE policies should be applied for each request... Regards, JL > Secondly, the same point should be=20 > reflected in the path computation communication protocol requirements. >=20 > Igor >=20 > ----- Original Message ----- > From: "Lou Berger" > To: "JP Vasseur" ; "Adrian Farrel" > ; "Ash, Gerald R (Jerry), ALABS" > Cc: > Sent: Tuesday, July 26, 2005 7:14 PM > Subject: Re: [Pce] Changes in the new revision of the architecture I-D >=20 >=20 > > At 09:24 AM 7/23/2005, JP Vasseur wrote: > > >We think that the ID is pretty stable in term of technical content. > > >As Adrian pointed out, there might be some editorial work=20 > to be done > > >before WG last call. So the short answer is "as soon as possible". > > > > > >Thanks. > > > > > >JP. > > > > JP/Adrian/Jerry, > > As you say, the draft has come together very nicely. The > > primary comment I have on the document is related to how policy is > > presented in the draft: > > > > The draft does mention policy in multiple places, but these mentions > > are more "in-passing" than as major component. It seems to me that > > Policy and the ability to support path computation based on, or > > influenced by policies, must be a major part of the PCE > > architecture. I do agree with draft in that "policy between domains > > and between PCEs, and is achieved through configuration not through > > protocol communications." That said, the PCC-PCE and PCE-PCE > > communication protocols must support the communication of all > > information needed to support the installed policies, as well as > > support any policy triggered transactions that may result due to a > > policy (or change in policy). Also, in order to deliver viable > > policy to PCE, policy must not be an after thought. (Consider how > > successful original RSVP was with bringing in policy after the core > > work was complete.) > > > > In short, I think policy should be more prominent in the=20 > draft and in > > the PCE architecture. > > > > I suggest to: > > - add policy related motivations in section 4, > > - add a policy component to the PCE architecture(s)=20 > presented in section > 5, > > - add a full fledged Policy sub-section to section 6 that=20 > is separate > > from confidentiality. > > - and add a policy related evaluation metric to section 7. > > > > Please let me know what you think. > > > > I'll put together some specific text for fodder.... > > > > Lou > > > > > > _______________________________________________ > > Pce mailing list > > Pce@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/pce > > >=20 >=20 > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Jul 27 10:33:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxmyP-0001GX-9V; Wed, 27 Jul 2005 10:33:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxmyM-0001Ev-JL for pce@megatron.ietf.org; Wed, 27 Jul 2005 10:33:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02770 for ; Wed, 27 Jul 2005 10:33:23 -0400 (EDT) Received: from webmail.movaz.com ([65.205.166.188] helo=jera.movaz.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxnTc-0007AK-A7 for pce@ietf.org; Wed, 27 Jul 2005 11:05:46 -0400 Received: from movaz-hw.movaz.com (movaz-hw.atlanta.movaz.com [172.16.8.183]) by jera.movaz.com (Postfix) with ESMTP id 1DB9FB085; Wed, 27 Jul 2005 10:33:14 -0400 (EDT) Received: from lb.movaz.com (localhost [127.0.0.1]) by movaz-hw.movaz.com (Postfix) with ESMTP id 1A060AF9B; Wed, 27 Jul 2005 10:33:06 -0400 (EDT) Message-Id: <6.2.3.4.2.20050727102145.04065fc0@mo-ex1> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Wed, 27 Jul 2005 10:33:05 -0400 To: "Bryskin, Igor" From: Lou Berger Subject: Re: [Pce] Changes in the new revision of the architecture I-D In-Reply-To: <009701c592b3$94409970$7a1810ac@movaz.com> References: <154701c58d1f$ef014e70$d6849ed9@Puppy> <42E239D1.9010907@psg.com> <84945647-6729-4394-A308-17C1D3C79589@cisco.com> <6.2.3.4.2.20050726191150.03f4f040@mo-ex1> <009701c592b3$94409970$7a1810ac@movaz.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Igor, My primary point was that we need to ensure that we fully consider policy in the architecture (and the resulting instantiation of the architecture). The point you raise is a reasonable one up due to such consideration. Although rather than make a statement on the requirement, I would ask the question, does policy being applied at PCE2 need to know the identity of PCC? (I'm not sure...) Much thanks, Lou At 10:00 AM 7/27/2005, Bryskin, Igor wrote: >Hi, > >I think Lou has just brought up a very important discussion. > >A PCE can apply a policy for a particular path computation request only IFF >it can identify original requestor. Consider the situation when a single >request involves 2 PCEs: PCC<=>PCE1<=>PCE2. > >PCE1 can identify the PCC and apply the polices for this PCC or this class >of PCCs. However, PCE2 will not be capable to identify PCC ( we seem to >agree already that PCC-PCE and PCE-PCE is the same protocol, hence PCE2 will >see PCE1 as PCC), and will apply a wrong policy. For instance, it may invoke >a computationally expensive algorithm, which it won't do if the PCC >requested computation directly from PCC2. > >So, in the architecture document the reasons should be described why the >identity of the original requestor should be available for all PCEs involved >in particular path computation request. Secondly, the same point should be >reflected in the path computation communication protocol requirements. > >Igor > >----- Original Message ----- >From: "Lou Berger" >To: "JP Vasseur" ; "Adrian Farrel" >; "Ash, Gerald R (Jerry), ALABS" >Cc: >Sent: Tuesday, July 26, 2005 7:14 PM >Subject: Re: [Pce] Changes in the new revision of the architecture I-D > > > At 09:24 AM 7/23/2005, JP Vasseur wrote: > > >We think that the ID is pretty stable in term of technical content. > > >As Adrian pointed out, there might be some editorial work to be done > > >before WG last call. So the short answer is "as soon as possible". > > > > > >Thanks. > > > > > >JP. > > > > JP/Adrian/Jerry, > > As you say, the draft has come together very nicely. The > > primary comment I have on the document is related to how policy is > > presented in the draft: > > > > The draft does mention policy in multiple places, but these mentions > > are more "in-passing" than as major component. It seems to me that > > Policy and the ability to support path computation based on, or > > influenced by policies, must be a major part of the PCE > > architecture. I do agree with draft in that "policy between domains > > and between PCEs, and is achieved through configuration not through > > protocol communications." That said, the PCC-PCE and PCE-PCE > > communication protocols must support the communication of all > > information needed to support the installed policies, as well as > > support any policy triggered transactions that may result due to a > > policy (or change in policy). Also, in order to deliver viable > > policy to PCE, policy must not be an after thought. (Consider how > > successful original RSVP was with bringing in policy after the core > > work was complete.) > > > > In short, I think policy should be more prominent in the draft and in > > the PCE architecture. > > > > I suggest to: > > - add policy related motivations in section 4, > > - add a policy component to the PCE architecture(s) presented in section >5, > > - add a full fledged Policy sub-section to section 6 that is separate > > from confidentiality. > > - and add a policy related evaluation metric to section 7. > > > > Please let me know what you think. > > > > I'll put together some specific text for fodder.... > > > > Lou > > > > > > _______________________________________________ > > Pce mailing list > > Pce@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/pce > > > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Jul 27 10:44:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxn9O-0003T5-3U; Wed, 27 Jul 2005 10:44:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxn9L-0003OS-Ra for pce@megatron.ietf.org; Wed, 27 Jul 2005 10:44:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03553 for ; Wed, 27 Jul 2005 10:44:45 -0400 (EDT) Received: from webmail.movaz.com ([65.205.166.188] helo=jera.movaz.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dxnec-0007WV-2a for pce@ietf.org; Wed, 27 Jul 2005 11:17:07 -0400 Received: from movaz-hw.movaz.com (movaz-hw.atlanta.movaz.com [172.16.8.183]) by jera.movaz.com (Postfix) with ESMTP id 32E2AB085; Wed, 27 Jul 2005 10:44:37 -0400 (EDT) Received: from lb.movaz.com (localhost [127.0.0.1]) by movaz-hw.movaz.com (Postfix) with ESMTP id 6672BAF9B; Wed, 27 Jul 2005 10:44:32 -0400 (EDT) Message-Id: <6.2.3.4.2.20050727103858.044bdc80@mo-ex1> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Wed, 27 Jul 2005 10:44:31 -0400 To: "LE ROUX Jean-Louis RD-CORE-LAN" From: Lou Berger Subject: RE: [Pce] Changes in the new revision of the architecture I-D In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Content-Transfer-Encoding: quoted-printable Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org >To my mind policies must have a local client-server scope. >Path requests have a local PCC-PCE scope. >PCE2 doesn't care whether PCE1 request has been=20 >triggered by PCC request to PCE1 or not. It=20 >serves a request from PCE1 and that's all... Jean-Louis, I think this discussion, and the fact=20 that you and Igor are disagreeing, highlights the=20 need to clearly state the supported policy models=20 and the corresponding requirements/implications=20 in the PCE requirements documents... Lou At 10:14 AM 7/27/2005, LE ROUX Jean-Louis RD-CORE-LAN wrote: >Hi Igor > >Please see inline > > > -----Message d'origine----- > > De : pce-bounces@lists.ietf.org > > [mailto:pce-bounces@lists.ietf.org] De la part de Igor Bryskin > > Envoy=E9 : mercredi 27 juillet 2005 16:01 > > =C0 : JP Vasseur; zzx-adrian@olddog.co.uk; Ash, Gerald R > > (Jerry), ALABS; Lou Berger > > Cc : pce@ietf.org > > Objet : Re: [Pce] Changes in the new revision of the architecture I-D > > > > Hi, > > > > I think Lou has just brought up a very important discussion. > > > > A PCE can apply a policy for a particular path computation > > request only IFF it can identify original requestor. Consider > > the situation when a single request involves 2 PCEs: > > PCC<=3D>PCE1<=3D>PCE2. > > > > PCE1 can identify the PCC and apply the polices for this PCC > > or this class of PCCs. However, PCE2 will not be capable to > > identify PCC ( we seem to agree already that PCC-PCE and > > PCE-PCE is the same protocol, hence PCE2 will see PCE1 as > > PCC) > >And where is the problem? Policy have a local PCC-PCE meaning >PCE1 that sends a request to PCE2 is considered=20 >as a PCC, and PCE2 applies the policy to PCE1 >PCE1 offers a service to PCC, PCE2 offers a service to PCE1, >To my mind policies must have a local client-server scope. >Path requests have a local PCC-PCE scope. >PCE2 doesn't care whether PCE1 request has been=20 >triggered by PCC request to PCE1 or not. It=20 >serves a request from PCE1 and that's all... > > >, and will apply a wrong policy. For instance, it may > > invoke a computationally expensive algorithm, which it won't > > do if the PCC requested computation directly from PCC2. > >And what is the problem?, this is up to PCE1 to apply correct policies > > > > > So, in the architecture document the reasons should be > > described why the identity of the original requestor should > > be available for all PCEs involved in particular path > > computation request. > >A path computation request should IMHO have a local scope >Multiple-PCE path computation should be considered as a cascade of >requests rather than the propagation of the same=20 >request, and local PCC-PCE policies should be applied for each request... > > >Regards, > >JL > > > Secondly, the same point should be > > reflected in the path computation communication protocol requirements. > > > > Igor > > > > ----- Original Message ----- > > From: "Lou Berger" > > To: "JP Vasseur" ; "Adrian Farrel" > > ; "Ash, Gerald R (Jerry), ALABS" > > Cc: > > Sent: Tuesday, July 26, 2005 7:14 PM > > Subject: Re: [Pce] Changes in the new revision of the architecture I-D > > > > > > > At 09:24 AM 7/23/2005, JP Vasseur wrote: > > > >We think that the ID is pretty stable in term of technical content. > > > >As Adrian pointed out, there might be some editorial work > > to be done > > > >before WG last call. So the short answer is "as soon as possible". > > > > > > > >Thanks. > > > > > > > >JP. > > > > > > JP/Adrian/Jerry, > > > As you say, the draft has come together very nicely. The > > > primary comment I have on the document is related to how policy is > > > presented in the draft: > > > > > > The draft does mention policy in multiple places, but these mentions > > > are more "in-passing" than as major component. It seems to me that > > > Policy and the ability to support path computation based on, or > > > influenced by policies, must be a major part of the PCE > > > architecture. I do agree with draft in that "policy between domains > > > and between PCEs, and is achieved through configuration not through > > > protocol communications." That said, the PCC-PCE and PCE-PCE > > > communication protocols must support the communication of all > > > information needed to support the installed policies, as well as > > > support any policy triggered transactions that may result due to a > > > policy (or change in policy). Also, in order to deliver viable > > > policy to PCE, policy must not be an after thought. (Consider how > > > successful original RSVP was with bringing in policy after the core > > > work was complete.) > > > > > > In short, I think policy should be more prominent in the > > draft and in > > > the PCE architecture. > > > > > > I suggest to: > > > - add policy related motivations in section 4, > > > - add a policy component to the PCE architecture(s) > > presented in section > > 5, > > > - add a full fledged Policy sub-section to section 6 that > > is separate > > > from confidentiality. > > > - and add a policy related evaluation metric to section 7. > > > > > > Please let me know what you think. > > > > > > I'll put together some specific text for fodder.... > > > > > > Lou > > > > > > > > > _______________________________________________ > > > Pce mailing list > > > Pce@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/pce > > > > > > > > > _______________________________________________ > > Pce mailing list > > Pce@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/pce > > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Jul 27 10:44:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxn9O-0003TU-Fz; Wed, 27 Jul 2005 10:44:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxn9M-0003Ob-5W for pce@megatron.ietf.org; Wed, 27 Jul 2005 10:44:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03557 for ; Wed, 27 Jul 2005 10:44:45 -0400 (EDT) Received: from webmail.movaz.com ([65.205.166.188] helo=jera.movaz.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dxned-0007WY-59 for pce@ietf.org; Wed, 27 Jul 2005 11:17:07 -0400 Received: from ib (unknown [172.16.24.122]) by jera.movaz.com (Postfix) with SMTP id 15F0E127E4; Wed, 27 Jul 2005 10:44:38 -0400 (EDT) Message-ID: <00ad01c592b9$b6cb77c0$7a1810ac@movaz.com> From: "Igor Bryskin" To: "LE ROUX Jean-Louis RD-CORE-LAN" , "JP Vasseur" , , "Ash, Gerald R (Jerry), ALABS" , "Lou Berger" References: Subject: Re: [Pce] Changes in the new revision of the architecture I-D Date: Wed, 27 Jul 2005 10:44:37 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id KAA03557 Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org JL, See in-line. Igor ----- Original Message -----=20 From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "Igor Bryskin" ; "JP Vasseur" ; ; "Ash, Gerald R (Jerry), ALABS" ; "Lo= u Berger" Cc: Sent: Wednesday, July 27, 2005 10:14 AM Subject: RE: [Pce] Changes in the new revision of the architecture I-D Hi Igor Please see inline > -----Message d'origine----- > De : pce-bounces@lists.ietf.org > [mailto:pce-bounces@lists.ietf.org] De la part de Igor Bryskin > Envoy=E9 : mercredi 27 juillet 2005 16:01 > =C0 : JP Vasseur; zzx-adrian@olddog.co.uk; Ash, Gerald R > (Jerry), ALABS; Lou Berger > Cc : pce@ietf.org > Objet : Re: [Pce] Changes in the new revision of the architecture I-D > > Hi, > > I think Lou has just brought up a very important discussion. > > A PCE can apply a policy for a particular path computation > request only IFF it can identify original requestor. Consider > the situation when a single request involves 2 PCEs: > PCC<=3D>PCE1<=3D>PCE2. > > PCE1 can identify the PCC and apply the polices for this PCC > or this class of PCCs. However, PCE2 will not be capable to > identify PCC ( we seem to agree already that PCC-PCE and > PCE-PCE is the same protocol, hence PCE2 will see PCE1 as > PCC) And where is the problem? Policy have a local PCC-PCE meaning PCE1 that sends a request to PCE2 is considered as a PCC, and PCE2 applie= s the policy to PCE1 PCE1 offers a service to PCC, PCE2 offers a service to PCE1, To my mind policies must have a local client-server scope. Path requests have a local PCC-PCE scope. PCE2 doesn't care whether PCE1 request has been triggered by PCC request = to PCE1 or not. It serves a request from PCE1 and that's all... IB>> The problem is in my opinion quite obvious. A PCC sends a request to PCE1 with a lot of constraints and optimization objectives. PCE1 recogniz= es the PCC as "unimportant" and is about to perform some "cheap" heuristic. However, it does not have visibility to the destination, hence it relays = the request to PCE2. PCE2 recognizes the PCE1 as a "very important" client an= d tries to satisfy the request as best as it can, which may take 25% of its CPU capacity. Now, if you have several more such "unimportant" PCCs, you = get your PCE2 saturated very quickly. Igor >, and will apply a wrong policy. For instance, it may > invoke a computationally expensive algorithm, which it won't > do if the PCC requested computation directly from PCC2. And what is the problem?, this is up to PCE1 to apply correct policies > > So, in the architecture document the reasons should be > described why the identity of the original requestor should > be available for all PCEs involved in particular path > computation request. A path computation request should IMHO have a local scope Multiple-PCE path computation should be considered as a cascade of requests rather than the propagation of the same request, and local PCC-P= CE policies should be applied for each request... Regards, JL > Secondly, the same point should be > reflected in the path computation communication protocol requirements. > > Igor > > ----- Original Message ----- > From: "Lou Berger" > To: "JP Vasseur" ; "Adrian Farrel" > ; "Ash, Gerald R (Jerry), ALABS" > Cc: > Sent: Tuesday, July 26, 2005 7:14 PM > Subject: Re: [Pce] Changes in the new revision of the architecture I-D > > > > At 09:24 AM 7/23/2005, JP Vasseur wrote: > > >We think that the ID is pretty stable in term of technical content. > > >As Adrian pointed out, there might be some editorial work > to be done > > >before WG last call. So the short answer is "as soon as possible". > > > > > >Thanks. > > > > > >JP. > > > > JP/Adrian/Jerry, > > As you say, the draft has come together very nicely. The > > primary comment I have on the document is related to how policy is > > presented in the draft: > > > > The draft does mention policy in multiple places, but these mentions > > are more "in-passing" than as major component. It seems to me that > > Policy and the ability to support path computation based on, or > > influenced by policies, must be a major part of the PCE > > architecture. I do agree with draft in that "policy between domains > > and between PCEs, and is achieved through configuration not through > > protocol communications." That said, the PCC-PCE and PCE-PCE > > communication protocols must support the communication of all > > information needed to support the installed policies, as well as > > support any policy triggered transactions that may result due to a > > policy (or change in policy). Also, in order to deliver viable > > policy to PCE, policy must not be an after thought. (Consider how > > successful original RSVP was with bringing in policy after the core > > work was complete.) > > > > In short, I think policy should be more prominent in the > draft and in > > the PCE architecture. > > > > I suggest to: > > - add policy related motivations in section 4, > > - add a policy component to the PCE architecture(s) > presented in section > 5, > > - add a full fledged Policy sub-section to section 6 that > is separate > > from confidentiality. > > - and add a policy related evaluation metric to section 7. > > > > Please let me know what you think. > > > > I'll put together some specific text for fodder.... > > > > Lou > > > > > > _______________________________________________ > > Pce mailing list > > Pce@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/pce > > > > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Jul 27 10:54:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxnIr-0008Hr-1Y; Wed, 27 Jul 2005 10:54:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxnIp-0008Hm-F8 for pce@megatron.ietf.org; Wed, 27 Jul 2005 10:54:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04582 for ; Wed, 27 Jul 2005 10:54:32 -0400 (EDT) Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dxno6-0007wq-IP for pce@ietf.org; Wed, 27 Jul 2005 11:26:55 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Wed, 27 Jul 2005 16:54:27 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Pce] Changes in the new revision of the architecture I-D Date: Wed, 27 Jul 2005 16:54:26 +0200 Message-ID: Thread-Topic: [Pce] Changes in the new revision of the architecture I-D Thread-Index: AcWSubh6T+ZOqK0sRpCqXZROcTCMLAAAQN4w From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "Lou Berger" X-OriginalArrivalTime: 27 Jul 2005 14:54:27.0112 (UTC) FILETIME=[15BC2A80:01C592BB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb Content-Transfer-Encoding: quoted-printable Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi Lou > Jean-Louis, > I think this discussion, and the fact that you and=20 > Igor are disagreeing, highlights the need to clearly state=20 > the supported policy models and the corresponding=20 > requirements/implications in the PCE requirements documents... >=20 You are right, and thanks for highlighting this point JL =20 > -----Message d'origine----- > De : Lou Berger [mailto:lberger@movaz.com]=20 > Envoy=E9 : mercredi 27 juillet 2005 16:45 > =C0 : LE ROUX Jean-Louis RD-CORE-LAN > Cc : Igor Bryskin; JP Vasseur; zzx-adrian@olddog.co.uk; Ash,=20 > Gerald R (Jerry), ALABS; Lou Berger; pce@ietf.org > Objet : RE: [Pce] Changes in the new revision of the architecture I-D >=20 >=20 > >To my mind policies must have a local client-server scope. > >Path requests have a local PCC-PCE scope. > >PCE2 doesn't care whether PCE1 request has been triggered by PCC=20 > >request to PCE1 or not. It serves a request from PCE1 and=20 > that's all... >=20 > Jean-Louis, > I think this discussion, and the fact that you and=20 > Igor are disagreeing, highlights the need to clearly state=20 > the supported policy models and the corresponding=20 > requirements/implications in the PCE requirements documents... >=20 > Lou >=20 > At 10:14 AM 7/27/2005, LE ROUX Jean-Louis RD-CORE-LAN wrote: > >Hi Igor > > > >Please see inline > > > > > -----Message d'origine----- > > > De : pce-bounces@lists.ietf.org > > > [mailto:pce-bounces@lists.ietf.org] De la part de Igor Bryskin > > > Envoy=E9 : mercredi 27 juillet 2005 16:01 > > > =C0 : JP Vasseur; zzx-adrian@olddog.co.uk; Ash, Gerald R > > > (Jerry), ALABS; Lou Berger > > > Cc : pce@ietf.org > > > Objet : Re: [Pce] Changes in the new revision of the=20 > architecture I-D > > > > > > Hi, > > > > > > I think Lou has just brought up a very important discussion. > > > > > > A PCE can apply a policy for a particular path computation > > > request only IFF it can identify original requestor. Consider > > > the situation when a single request involves 2 PCEs: > > > PCC<=3D>PCE1<=3D>PCE2. > > > > > > PCE1 can identify the PCC and apply the polices for this PCC > > > or this class of PCCs. However, PCE2 will not be capable to > > > identify PCC ( we seem to agree already that PCC-PCE and > > > PCE-PCE is the same protocol, hence PCE2 will see PCE1 as > > > PCC) > > > >And where is the problem? Policy have a local PCC-PCE meaning > >PCE1 that sends a request to PCE2 is considered=20 > >as a PCC, and PCE2 applies the policy to PCE1 > >PCE1 offers a service to PCC, PCE2 offers a service to PCE1, > >To my mind policies must have a local client-server scope. > >Path requests have a local PCC-PCE scope. > >PCE2 doesn't care whether PCE1 request has been=20 > >triggered by PCC request to PCE1 or not. It=20 > >serves a request from PCE1 and that's all... > > > > >, and will apply a wrong policy. For instance, it may > > > invoke a computationally expensive algorithm, which it won't > > > do if the PCC requested computation directly from PCC2. > > > >And what is the problem?, this is up to PCE1 to apply=20 > correct policies > > > > > > > > So, in the architecture document the reasons should be > > > described why the identity of the original requestor should > > > be available for all PCEs involved in particular path > > > computation request. > > > >A path computation request should IMHO have a local scope > >Multiple-PCE path computation should be considered as a cascade of > >requests rather than the propagation of the same=20 > >request, and local PCC-PCE policies should be applied for=20 > each request... > > > > > >Regards, > > > >JL > > > > > Secondly, the same point should be > > > reflected in the path computation communication protocol=20 > requirements. > > > > > > Igor > > > > > > ----- Original Message ----- > > > From: "Lou Berger" > > > To: "JP Vasseur" ; "Adrian Farrel" > > > ; "Ash, Gerald R (Jerry), ALABS"=20 > > > > Cc: > > > Sent: Tuesday, July 26, 2005 7:14 PM > > > Subject: Re: [Pce] Changes in the new revision of the=20 > architecture I-D > > > > > > > > > > At 09:24 AM 7/23/2005, JP Vasseur wrote: > > > > >We think that the ID is pretty stable in term of=20 > technical content. > > > > >As Adrian pointed out, there might be some editorial work > > > to be done > > > > >before WG last call. So the short answer is "as soon=20 > as possible". > > > > > > > > > >Thanks. > > > > > > > > > >JP. > > > > > > > > JP/Adrian/Jerry, > > > > As you say, the draft has come together very=20 > nicely. The > > > > primary comment I have on the document is related to=20 > how policy is > > > > presented in the draft: > > > > > > > > The draft does mention policy in multiple places, but=20 > these mentions > > > > are more "in-passing" than as major component. It=20 > seems to me that > > > > Policy and the ability to support path computation based on, or > > > > influenced by policies, must be a major part of the PCE > > > > architecture. I do agree with draft in that "policy=20 > between domains > > > > and between PCEs, and is achieved through configuration=20 > not through > > > > protocol communications." That said, the PCC-PCE and PCE-PCE > > > > communication protocols must support the communication of all > > > > information needed to support the installed policies, as well as > > > > support any policy triggered transactions that may=20 > result due to a > > > > policy (or change in policy). Also, in order to deliver viable > > > > policy to PCE, policy must not be an after thought. =20 > (Consider how > > > > successful original RSVP was with bringing in policy=20 > after the core > > > > work was complete.) > > > > > > > > In short, I think policy should be more prominent in the > > > draft and in > > > > the PCE architecture. > > > > > > > > I suggest to: > > > > - add policy related motivations in section 4, > > > > - add a policy component to the PCE architecture(s) > > > presented in section > > > 5, > > > > - add a full fledged Policy sub-section to section 6 that > > > is separate > > > > from confidentiality. > > > > - and add a policy related evaluation metric to section 7. > > > > > > > > Please let me know what you think. > > > > > > > > I'll put together some specific text for fodder.... > > > > > > > > Lou > > > > > > > > > > > > _______________________________________________ > > > > Pce mailing list > > > > Pce@lists.ietf.org > > > > https://www1.ietf.org/mailman/listinfo/pce > > > > > > > > > > > > > _______________________________________________ > > > Pce mailing list > > > Pce@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/pce > > > >=20 >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Jul 27 10:55:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxnJK-0008Mu-Rz; Wed, 27 Jul 2005 10:55:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxnJJ-0008Mm-IK for pce@megatron.ietf.org; Wed, 27 Jul 2005 10:55:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04603 for ; Wed, 27 Jul 2005 10:55:02 -0400 (EDT) Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxnoY-0007xi-Ob for pce@ietf.org; Wed, 27 Jul 2005 11:27:25 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Wed, 27 Jul 2005 16:51:54 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Pce] Changes in the new revision of the architecture I-D Date: Wed, 27 Jul 2005 16:51:53 +0200 Message-ID: Thread-Topic: [Pce] Changes in the new revision of the architecture I-D Thread-Index: AcWSubrdtG3zfNm3TuCp1Zv/A5/jmAAAGd7Q From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "Igor Bryskin" , "JP Vasseur" , , "Ash, Gerald R \(Jerry\), ALABS" , "Lou Berger" X-OriginalArrivalTime: 27 Jul 2005 14:51:54.0113 (UTC) FILETIME=[BA8A5F10:01C592BA] X-Spam-Score: 0.0 (/) X-Scan-Signature: df9edf1223802dd4cf213867a3af6121 Content-Transfer-Encoding: quoted-printable Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi Igor, PCE1 could reflect "low importance" in the request sent to PCE2, by mean of specific objective function selection, request priority or = potentially using a dedicated parameter (yet not defined). Please not that in inter-AS/SP environment there may be cases where PCE2 = MUST not have knowledge of PCC... Regards, JL=20 > -----Message d'origine----- > De : Igor Bryskin [mailto:ibryskin@movaz.com]=20 > Envoy=E9 : mercredi 27 juillet 2005 16:45 > =C0 : LE ROUX Jean-Louis RD-CORE-LAN; JP Vasseur;=20 > zzx-adrian@olddog.co.uk; Ash, Gerald R (Jerry), ALABS; Lou Berger > Cc : pce@ietf.org > Objet : Re: [Pce] Changes in the new revision of the architecture I-D >=20 > JL, >=20 > See in-line. >=20 > Igor >=20 > ----- Original Message ----- > From: "LE ROUX Jean-Louis RD-CORE-LAN"=20 > > To: "Igor Bryskin" ; "JP Vasseur"=20 > ; ; "Ash, Gerald R=20 > (Jerry), ALABS" ; "Lou Berger" > Cc: > Sent: Wednesday, July 27, 2005 10:14 AM > Subject: RE: [Pce] Changes in the new revision of the architecture I-D >=20 >=20 > Hi Igor >=20 > Please see inline >=20 > > -----Message d'origine----- > > De : pce-bounces@lists.ietf.org > > [mailto:pce-bounces@lists.ietf.org] De la part de Igor Bryskin > > Envoy=E9 : mercredi 27 juillet 2005 16:01 > > =C0 : JP Vasseur; zzx-adrian@olddog.co.uk; Ash, Gerald R > > (Jerry), ALABS; Lou Berger > > Cc : pce@ietf.org > > Objet : Re: [Pce] Changes in the new revision of the=20 > architecture I-D > > > > Hi, > > > > I think Lou has just brought up a very important discussion. > > > > A PCE can apply a policy for a particular path computation > > request only IFF it can identify original requestor. Consider > > the situation when a single request involves 2 PCEs: > > PCC<=3D>PCE1<=3D>PCE2. > > > > PCE1 can identify the PCC and apply the polices for this PCC > > or this class of PCCs. However, PCE2 will not be capable to > > identify PCC ( we seem to agree already that PCC-PCE and > > PCE-PCE is the same protocol, hence PCE2 will see PCE1 as > > PCC) >=20 > And where is the problem? Policy have a local PCC-PCE meaning > PCE1 that sends a request to PCE2 is considered as a PCC, and=20 > PCE2 applies > the policy to PCE1 > PCE1 offers a service to PCC, PCE2 offers a service to PCE1, > To my mind policies must have a local client-server scope. > Path requests have a local PCC-PCE scope. > PCE2 doesn't care whether PCE1 request has been triggered by=20 > PCC request to > PCE1 or not. It serves a request from PCE1 and that's all... >=20 > IB>> The problem is in my opinion quite obvious. A PCC sends=20 > a request to > PCE1 with a lot of constraints and optimization objectives.=20 > PCE1 recognizes > the PCC as "unimportant" and is about to perform some "cheap"=20 > heuristic. > However, it does not have visibility to the destination,=20 > hence it relays the > request to PCE2. PCE2 recognizes the PCE1 as a "very=20 > important" client and > tries to satisfy the request as best as it can, which may=20 > take 25% of its > CPU capacity. Now, if you have several more such=20 > "unimportant" PCCs, you get > your PCE2 saturated very quickly. >=20 > Igor >=20 > >, and will apply a wrong policy. For instance, it may > > invoke a computationally expensive algorithm, which it won't > > do if the PCC requested computation directly from PCC2. >=20 > And what is the problem?, this is up to PCE1 to apply correct policies >=20 > > > > So, in the architecture document the reasons should be > > described why the identity of the original requestor should > > be available for all PCEs involved in particular path > > computation request. >=20 > A path computation request should IMHO have a local scope > Multiple-PCE path computation should be considered as a cascade of > requests rather than the propagation of the same request, and=20 > local PCC-PCE > policies should be applied for each request... >=20 >=20 > Regards, >=20 > JL >=20 > > Secondly, the same point should be > > reflected in the path computation communication protocol=20 > requirements. > > > > Igor > > > > ----- Original Message ----- > > From: "Lou Berger" > > To: "JP Vasseur" ; "Adrian Farrel" > > ; "Ash, Gerald R (Jerry), ALABS" > > Cc: > > Sent: Tuesday, July 26, 2005 7:14 PM > > Subject: Re: [Pce] Changes in the new revision of the=20 > architecture I-D > > > > > > > At 09:24 AM 7/23/2005, JP Vasseur wrote: > > > >We think that the ID is pretty stable in term of=20 > technical content. > > > >As Adrian pointed out, there might be some editorial work > > to be done > > > >before WG last call. So the short answer is "as soon as=20 > possible". > > > > > > > >Thanks. > > > > > > > >JP. > > > > > > JP/Adrian/Jerry, > > > As you say, the draft has come together very nicely. The > > > primary comment I have on the document is related to how policy is > > > presented in the draft: > > > > > > The draft does mention policy in multiple places, but=20 > these mentions > > > are more "in-passing" than as major component. It seems=20 > to me that > > > Policy and the ability to support path computation based on, or > > > influenced by policies, must be a major part of the PCE > > > architecture. I do agree with draft in that "policy=20 > between domains > > > and between PCEs, and is achieved through configuration=20 > not through > > > protocol communications." That said, the PCC-PCE and PCE-PCE > > > communication protocols must support the communication of all > > > information needed to support the installed policies, as well as > > > support any policy triggered transactions that may result due to a > > > policy (or change in policy). Also, in order to deliver viable > > > policy to PCE, policy must not be an after thought. (Consider how > > > successful original RSVP was with bringing in policy=20 > after the core > > > work was complete.) > > > > > > In short, I think policy should be more prominent in the > > draft and in > > > the PCE architecture. > > > > > > I suggest to: > > > - add policy related motivations in section 4, > > > - add a policy component to the PCE architecture(s) > > presented in section > > 5, > > > - add a full fledged Policy sub-section to section 6 that > > is separate > > > from confidentiality. > > > - and add a policy related evaluation metric to section 7. > > > > > > Please let me know what you think. > > > > > > I'll put together some specific text for fodder.... > > > > > > Lou > > > > > > > > > _______________________________________________ > > > Pce mailing list > > > Pce@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/pce > > > > > > > > > _______________________________________________ > > Pce mailing list > > Pce@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/pce > > >=20 >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Jul 27 11:13:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxnai-0004x7-1k; Wed, 27 Jul 2005 11:13:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxnag-0004x2-HX for pce@megatron.ietf.org; Wed, 27 Jul 2005 11:13:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06132 for ; Wed, 27 Jul 2005 11:12:59 -0400 (EDT) Received: from webmail.movaz.com ([65.205.166.188] helo=jera.movaz.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dxo5u-00008V-JY for pce@ietf.org; Wed, 27 Jul 2005 11:45:22 -0400 Received: from ib (unknown [172.16.24.122]) by jera.movaz.com (Postfix) with SMTP id 28AD11733; Wed, 27 Jul 2005 11:12:43 -0400 (EDT) Message-ID: <00ce01c592bd$a343a200$7a1810ac@movaz.com> From: "Igor Bryskin" To: "LE ROUX Jean-Louis RD-CORE-LAN" , "JP Vasseur" , , "Ash, Gerald R (Jerry), ALABS" , "Lou Berger" References: Subject: Re: [Pce] Changes in the new revision of the architecture I-D Date: Wed, 27 Jul 2005 11:12:42 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: a069a8e8835d39ce36e425c148267a7b Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id LAA06132 Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org JL, PCE1 could reflect "low importance" in the request sent to PCE2, by mean of specific objective function selection (IB>> which? how?), request priority (IB>> won't help, PCE2 will just move request into lower priority task) or potentially using a dedicated parameter (yet not defined). IB>> And the point is why not to use the original requestor ID as the dedicated parameter you mentioned, so that PCE2 could apply the policy of its own? Please not that in inter-AS/SP environment there may be cases where PCE2 MUST not have knowledge of PCC... IB>> No problem here, original requestor ID will be "unknown", and PCE2 might have a policy for such clients as well Igor Regards, JL > -----Message d'origine----- > De : Igor Bryskin [mailto:ibryskin@movaz.com] > Envoy=E9 : mercredi 27 juillet 2005 16:45 > =C0 : LE ROUX Jean-Louis RD-CORE-LAN; JP Vasseur; > zzx-adrian@olddog.co.uk; Ash, Gerald R (Jerry), ALABS; Lou Berger > Cc : pce@ietf.org > Objet : Re: [Pce] Changes in the new revision of the architecture I-D > > JL, > > See in-line. > > Igor > > ----- Original Message ----- > From: "LE ROUX Jean-Louis RD-CORE-LAN" > > To: "Igor Bryskin" ; "JP Vasseur" > ; ; "Ash, Gerald R > (Jerry), ALABS" ; "Lou Berger" > Cc: > Sent: Wednesday, July 27, 2005 10:14 AM > Subject: RE: [Pce] Changes in the new revision of the architecture I-D > > > Hi Igor > > Please see inline > > > -----Message d'origine----- > > De : pce-bounces@lists.ietf.org > > [mailto:pce-bounces@lists.ietf.org] De la part de Igor Bryskin > > Envoy=E9 : mercredi 27 juillet 2005 16:01 > > =C0 : JP Vasseur; zzx-adrian@olddog.co.uk; Ash, Gerald R > > (Jerry), ALABS; Lou Berger > > Cc : pce@ietf.org > > Objet : Re: [Pce] Changes in the new revision of the > architecture I-D > > > > Hi, > > > > I think Lou has just brought up a very important discussion. > > > > A PCE can apply a policy for a particular path computation > > request only IFF it can identify original requestor. Consider > > the situation when a single request involves 2 PCEs: > > PCC<=3D>PCE1<=3D>PCE2. > > > > PCE1 can identify the PCC and apply the polices for this PCC > > or this class of PCCs. However, PCE2 will not be capable to > > identify PCC ( we seem to agree already that PCC-PCE and > > PCE-PCE is the same protocol, hence PCE2 will see PCE1 as > > PCC) > > And where is the problem? Policy have a local PCC-PCE meaning > PCE1 that sends a request to PCE2 is considered as a PCC, and > PCE2 applies > the policy to PCE1 > PCE1 offers a service to PCC, PCE2 offers a service to PCE1, > To my mind policies must have a local client-server scope. > Path requests have a local PCC-PCE scope. > PCE2 doesn't care whether PCE1 request has been triggered by > PCC request to > PCE1 or not. It serves a request from PCE1 and that's all... > > IB>> The problem is in my opinion quite obvious. A PCC sends > a request to > PCE1 with a lot of constraints and optimization objectives. > PCE1 recognizes > the PCC as "unimportant" and is about to perform some "cheap" > heuristic. > However, it does not have visibility to the destination, > hence it relays the > request to PCE2. PCE2 recognizes the PCE1 as a "very > important" client and > tries to satisfy the request as best as it can, which may > take 25% of its > CPU capacity. Now, if you have several more such > "unimportant" PCCs, you get > your PCE2 saturated very quickly. > > Igor > > >, and will apply a wrong policy. For instance, it may > > invoke a computationally expensive algorithm, which it won't > > do if the PCC requested computation directly from PCC2. > > And what is the problem?, this is up to PCE1 to apply correct policies > > > > > So, in the architecture document the reasons should be > > described why the identity of the original requestor should > > be available for all PCEs involved in particular path > > computation request. > > A path computation request should IMHO have a local scope > Multiple-PCE path computation should be considered as a cascade of > requests rather than the propagation of the same request, and > local PCC-PCE > policies should be applied for each request... > > > Regards, > > JL > > > Secondly, the same point should be > > reflected in the path computation communication protocol > requirements. > > > > Igor > > > > ----- Original Message ----- > > From: "Lou Berger" > > To: "JP Vasseur" ; "Adrian Farrel" > > ; "Ash, Gerald R (Jerry), ALABS" > > Cc: > > Sent: Tuesday, July 26, 2005 7:14 PM > > Subject: Re: [Pce] Changes in the new revision of the > architecture I-D > > > > > > > At 09:24 AM 7/23/2005, JP Vasseur wrote: > > > >We think that the ID is pretty stable in term of > technical content. > > > >As Adrian pointed out, there might be some editorial work > > to be done > > > >before WG last call. So the short answer is "as soon as > possible". > > > > > > > >Thanks. > > > > > > > >JP. > > > > > > JP/Adrian/Jerry, > > > As you say, the draft has come together very nicely. The > > > primary comment I have on the document is related to how policy is > > > presented in the draft: > > > > > > The draft does mention policy in multiple places, but > these mentions > > > are more "in-passing" than as major component. It seems > to me that > > > Policy and the ability to support path computation based on, or > > > influenced by policies, must be a major part of the PCE > > > architecture. I do agree with draft in that "policy > between domains > > > and between PCEs, and is achieved through configuration > not through > > > protocol communications." That said, the PCC-PCE and PCE-PCE > > > communication protocols must support the communication of all > > > information needed to support the installed policies, as well as > > > support any policy triggered transactions that may result due to a > > > policy (or change in policy). Also, in order to deliver viable > > > policy to PCE, policy must not be an after thought. (Consider how > > > successful original RSVP was with bringing in policy > after the core > > > work was complete.) > > > > > > In short, I think policy should be more prominent in the > > draft and in > > > the PCE architecture. > > > > > > I suggest to: > > > - add policy related motivations in section 4, > > > - add a policy component to the PCE architecture(s) > > presented in section > > 5, > > > - add a full fledged Policy sub-section to section 6 that > > is separate > > > from confidentiality. > > > - and add a policy related evaluation metric to section 7. > > > > > > Please let me know what you think. > > > > > > I'll put together some specific text for fodder.... > > > > > > Lou > > > > > > > > > _______________________________________________ > > > Pce mailing list > > > Pce@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/pce > > > > > > > > > _______________________________________________ > > Pce mailing list > > Pce@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/pce > > > > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Jul 27 11:39:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxo0b-0005h8-MD; Wed, 27 Jul 2005 11:39:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxo0Z-0005fK-Pa for pce@megatron.ietf.org; Wed, 27 Jul 2005 11:39:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08224 for ; Wed, 27 Jul 2005 11:39:44 -0400 (EDT) Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxoVo-00015L-0m for pce@ietf.org; Wed, 27 Jul 2005 12:12:07 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Wed, 27 Jul 2005 17:39:33 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Pce] Changes in the new revision of the architecture I-D Date: Wed, 27 Jul 2005 17:39:32 +0200 Message-ID: Thread-Topic: [Pce] Changes in the new revision of the architecture I-D Thread-Index: AcWSvaRiFaI5J0udQFmiCP3+4Lbu8wAAGGSQ From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "Igor Bryskin" , "JP Vasseur" , , "Ash, Gerald R \(Jerry\), ALABS" , "Lou Berger" X-OriginalArrivalTime: 27 Jul 2005 15:39:33.0710 (UTC) FILETIME=[62FE3EE0:01C592C1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d2fdecab7a7fa796e06e001d026c91 Content-Transfer-Encoding: quoted-printable Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi Igor=20 > -----Message d'origine----- > De : Igor Bryskin [mailto:ibryskin@movaz.com]=20 > Envoy=E9 : mercredi 27 juillet 2005 17:13 > =C0 : LE ROUX Jean-Louis RD-CORE-LAN; JP Vasseur;=20 > zzx-adrian@olddog.co.uk; Ash, Gerald R (Jerry), ALABS; Lou Berger > Cc : pce@ietf.org > Objet : Re: [Pce] Changes in the new revision of the architecture I-D >=20 > JL, >=20 > PCE1 could reflect "low importance" in the request sent to=20 > PCE2, by mean of specific objective function selection (IB>>=20 > which? how?), Solution to encode objective function are not yet specified, btw this = should be addressed in future PCEP revisions. But have a look at the text related to objective function and = parameterization of these functions in the communication protocol = generic requirements.=20 This may allow to request for what you call "cheap" or "expansive" = heuristics... >=20 > request priority (IB>> won't help, PCE2 will just move=20 > request into lower priority task) Right >=20 > or potentially using a dedicated parameter (yet not defined). > IB>> And the point is why not to use the original requestor ID as the > dedicated parameter you mentioned, so that PCE2 could apply=20 > the policy of its own? Hence PCE2 would have to be aware of all PCCs in other domains... Think about scalability, confidentiality, and policy configurations... This is up to PCE1 to notify the importance of the request to PCE2. In the PCC->PCE1->PCE2 cascade, PCC IS NOT a client of PCE2, PCC is a = client of PCE1, so if PCE1 considers that the request is not so = "important" it should reflect that in the request sent to PCE2 (control = of objective function, or maybe using a specific "importance" = parameter).=20 We should consider that PCEs may not be aware of PCCs in other domains >=20 > Please not that in inter-AS/SP environment there may be cases=20 > where PCE2 MUST not have knowledge of PCC... > IB>> No problem here, original requestor ID will be=20 > "unknown", and PCE2 > might have a policy for such clients as well So, if I follow you, the same policies would be applied for all unknow = clients...This does not sound really acceptable. Regards, JL >=20 > Igor >=20 > Regards, >=20 > JL >=20 > > -----Message d'origine----- > > De : Igor Bryskin [mailto:ibryskin@movaz.com] Envoy=E9 : mercredi 27 = > > juillet 2005 16:45 =C0 : LE ROUX Jean-Louis RD-CORE-LAN; JP Vasseur; = > > zzx-adrian@olddog.co.uk; Ash, Gerald R (Jerry), ALABS; Lou=20 > Berger Cc :=20 > > pce@ietf.org Objet : Re: [Pce] Changes in the new revision of the=20 > > architecture I-D > > > > JL, > > > > See in-line. > > > > Igor > > > > ----- Original Message ----- > > From: "LE ROUX Jean-Louis RD-CORE-LAN" > > > > To: "Igor Bryskin" ; "JP Vasseur" > > ; ; "Ash, Gerald R=20 > (Jerry),=20 > > ALABS" ; "Lou Berger" > > Cc: > > Sent: Wednesday, July 27, 2005 10:14 AM > > Subject: RE: [Pce] Changes in the new revision of the=20 > architecture I-D > > > > > > Hi Igor > > > > Please see inline > > > > > -----Message d'origine----- > > > De : pce-bounces@lists.ietf.org > > > [mailto:pce-bounces@lists.ietf.org] De la part de Igor Bryskin=20 > > > Envoy=E9 : mercredi 27 juillet 2005 16:01 =C0 : JP Vasseur;=20 > > > zzx-adrian@olddog.co.uk; Ash, Gerald R (Jerry), ALABS;=20 > Lou Berger Cc=20 > > > : pce@ietf.org Objet : Re: [Pce] Changes in the new=20 > revision of the > > architecture I-D > > > > > > Hi, > > > > > > I think Lou has just brought up a very important discussion. > > > > > > A PCE can apply a policy for a particular path=20 > computation request=20 > > > only IFF it can identify original requestor. Consider the=20 > situation=20 > > > when a single request involves 2 PCEs: > > > PCC<=3D>PCE1<=3D>PCE2. > > > > > > PCE1 can identify the PCC and apply the polices for this=20 > PCC or this=20 > > > class of PCCs. However, PCE2 will not be capable to=20 > identify PCC (=20 > > > we seem to agree already that PCC-PCE and PCE-PCE is the same=20 > > > protocol, hence PCE2 will see PCE1 as > > > PCC) > > > > And where is the problem? Policy have a local PCC-PCE meaning > > PCE1 that sends a request to PCE2 is considered as a PCC, and > > PCE2 applies > > the policy to PCE1 > > PCE1 offers a service to PCC, PCE2 offers a service to PCE1, To my=20 > > mind policies must have a local client-server scope. > > Path requests have a local PCC-PCE scope. > > PCE2 doesn't care whether PCE1 request has been triggered by PCC=20 > > request to > > PCE1 or not. It serves a request from PCE1 and that's all... > > > > IB>> The problem is in my opinion quite obvious. A PCC sends > > a request to > > PCE1 with a lot of constraints and optimization objectives. > > PCE1 recognizes > > the PCC as "unimportant" and is about to perform some "cheap" > > heuristic. > > However, it does not have visibility to the destination, hence it=20 > > relays the request to PCE2. PCE2 recognizes the PCE1 as a "very=20 > > important" client and tries to satisfy the request as best=20 > as it can,=20 > > which may take 25% of its CPU capacity. Now, if you have=20 > several more=20 > > such "unimportant" PCCs, you get your PCE2 saturated very quickly. > > > > Igor > > > > >, and will apply a wrong policy. For instance, it may invoke a=20 > > >computationally expensive algorithm, which it won't do if the PCC=20 > > >requested computation directly from PCC2. > > > > And what is the problem?, this is up to PCE1 to apply=20 > correct policies > > > > > > > > So, in the architecture document the reasons should be=20 > described why=20 > > > the identity of the original requestor should be=20 > available for all=20 > > > PCEs involved in particular path computation request. > > > > A path computation request should IMHO have a local scope=20 > Multiple-PCE=20 > > path computation should be considered as a cascade of=20 > requests rather=20 > > than the propagation of the same request, and local PCC-PCE=20 > policies=20 > > should be applied for each request... > > > > > > Regards, > > > > JL > > > > > Secondly, the same point should be > > > reflected in the path computation communication protocol > > requirements. > > > > > > Igor > > > > > > ----- Original Message ----- > > > From: "Lou Berger" > > > To: "JP Vasseur" ; "Adrian Farrel" > > > ; "Ash, Gerald R (Jerry), ALABS"=20 > > > > Cc: > > > Sent: Tuesday, July 26, 2005 7:14 PM > > > Subject: Re: [Pce] Changes in the new revision of the > > architecture I-D > > > > > > > > > > At 09:24 AM 7/23/2005, JP Vasseur wrote: > > > > >We think that the ID is pretty stable in term of > > technical content. > > > > >As Adrian pointed out, there might be some editorial work > > > to be done > > > > >before WG last call. So the short answer is "as soon as > > possible". > > > > > > > > > >Thanks. > > > > > > > > > >JP. > > > > > > > > JP/Adrian/Jerry, > > > > As you say, the draft has come together very=20 > nicely. The=20 > > > > primary comment I have on the document is related to=20 > how policy is=20 > > > > presented in the draft: > > > > > > > > The draft does mention policy in multiple places, but > > these mentions > > > > are more "in-passing" than as major component. It seems > > to me that > > > > Policy and the ability to support path computation based on, or=20 > > > > influenced by policies, must be a major part of the PCE=20 > > > > architecture. I do agree with draft in that "policy > > between domains > > > > and between PCEs, and is achieved through configuration > > not through > > > > protocol communications." That said, the PCC-PCE and PCE-PCE=20 > > > > communication protocols must support the communication of all=20 > > > > information needed to support the installed policies,=20 > as well as=20 > > > > support any policy triggered transactions that may=20 > result due to a=20 > > > > policy (or change in policy). Also, in order to deliver viable=20 > > > > policy to PCE, policy must not be an after thought. =20 > (Consider how=20 > > > > successful original RSVP was with bringing in policy > > after the core > > > > work was complete.) > > > > > > > > In short, I think policy should be more prominent in the > > > draft and in > > > > the PCE architecture. > > > > > > > > I suggest to: > > > > - add policy related motivations in section 4, > > > > - add a policy component to the PCE architecture(s) > > > presented in section > > > 5, > > > > - add a full fledged Policy sub-section to section 6 that > > > is separate > > > > from confidentiality. > > > > - and add a policy related evaluation metric to section 7. > > > > > > > > Please let me know what you think. > > > > > > > > I'll put together some specific text for fodder.... > > > > > > > > Lou > > > > > > > > > > > > _______________________________________________ > > > > Pce mailing list > > > > Pce@lists.ietf.org > > > > https://www1.ietf.org/mailman/listinfo/pce > > > > > > > > > > > > > _______________________________________________ > > > Pce mailing list > > > Pce@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/pce > > > > > > > >=20 >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Jul 27 13:05:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxpLY-0000Tt-1G; Wed, 27 Jul 2005 13:05:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxpLT-0000Tk-89 for pce@megatron.ietf.org; Wed, 27 Jul 2005 13:05:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14481 for ; Wed, 27 Jul 2005 13:05:23 -0400 (EDT) Received: from webmail.movaz.com ([65.205.166.188] helo=jera.movaz.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dxpqk-0003wa-SO for pce@ietf.org; Wed, 27 Jul 2005 13:37:48 -0400 Received: from ib (unknown [172.16.24.122]) by jera.movaz.com (Postfix) with SMTP id 6989A1828; Wed, 27 Jul 2005 13:05:14 -0400 (EDT) Message-ID: <00fc01c592cd$5b3d6b70$7a1810ac@movaz.com> From: "Igor Bryskin" To: "LE ROUX Jean-Louis RD-CORE-LAN" , "JP Vasseur" , , "Ash, Gerald R (Jerry), ALABS" , "Lou Berger" References: Subject: Re: [Pce] Changes in the new revision of the architecture I-D Date: Wed, 27 Jul 2005 13:05:14 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9f79b8e383fd3af2b1b5b1d0910f6094 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id NAA14481 Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Jl, 1. PCE2 publishes its presence, hence it must be prepared to receive requests from many clients and may have policies for some of them. In our example the PCE2 could get a request directly from the PCC, may have a policy for the PCC (not necessarily identical to the policy that the PCE1 has). 2. PCE1 in our example can always put its own ID as request originator ID= in the request to PCE2 and modify the request to reflect its importance as f= ar as it sees it (exactly your model). Alternatively. PCE1 may choose not to modify the request (changing neither request originator ID nor constraint= s) and let PCE2 treat the request according to its own policies. In the latt= er case: PCC->PCE1->PCE2->PCE1->PCC and PCC->PCE1->PCC->PCE2->PCC sequences will likely to produce the same resulting paths. In any case enabling all PCEs involved in the request to be aware of the "real" originator seems to me a more flexible approach. On more general note it is obvious that articulating policies between PCE wrt specific request has never been discussed and we should IMO, starting with the architecture. See you in Paris, Igor ----- Original Message -----=20 From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "Igor Bryskin" ; "JP Vasseur" ; ; "Ash, Gerald R (Jerry), ALABS" ; "Lo= u Berger" Cc: Sent: Wednesday, July 27, 2005 11:39 AM Subject: RE: [Pce] Changes in the new revision of the architecture I-D Hi Igor > -----Message d'origine----- > De : Igor Bryskin [mailto:ibryskin@movaz.com] > Envoy=E9 : mercredi 27 juillet 2005 17:13 > =C0 : LE ROUX Jean-Louis RD-CORE-LAN; JP Vasseur; > zzx-adrian@olddog.co.uk; Ash, Gerald R (Jerry), ALABS; Lou Berger > Cc : pce@ietf.org > Objet : Re: [Pce] Changes in the new revision of the architecture I-D > > JL, > > PCE1 could reflect "low importance" in the request sent to > PCE2, by mean of specific objective function selection (IB>> > which? how?), Solution to encode objective function are not yet specified, btw this sho= uld be addressed in future PCEP revisions. But have a look at the text related to objective function and parameterization of these functions in the communication protocol generic requirements. This may allow to request for what you call "cheap" or "expansive" heuristics... > > request priority (IB>> won't help, PCE2 will just move > request into lower priority task) Right > > or potentially using a dedicated parameter (yet not defined). > IB>> And the point is why not to use the original requestor ID as the > dedicated parameter you mentioned, so that PCE2 could apply > the policy of its own? Hence PCE2 would have to be aware of all PCCs in other domains... Think about scalability, confidentiality, and policy configurations... This is up to PCE1 to notify the importance of the request to PCE2. In the PCC->PCE1->PCE2 cascade, PCC IS NOT a client of PCE2, PCC is a cli= ent of PCE1, so if PCE1 considers that the request is not so "important" it should reflect that in the request sent to PCE2 (control of objective function, or maybe using a specific "importance" parameter). We should consider that PCEs may not be aware of PCCs in other domains > > Please not that in inter-AS/SP environment there may be cases > where PCE2 MUST not have knowledge of PCC... > IB>> No problem here, original requestor ID will be > "unknown", and PCE2 > might have a policy for such clients as well So, if I follow you, the same policies would be applied for all unknow clients...This does not sound really acceptable. Regards, JL > > Igor > > Regards, > > JL > > > -----Message d'origine----- > > De : Igor Bryskin [mailto:ibryskin@movaz.com] Envoy=E9 : mercredi 27 > > juillet 2005 16:45 =C0 : LE ROUX Jean-Louis RD-CORE-LAN; JP Vasseur; > > zzx-adrian@olddog.co.uk; Ash, Gerald R (Jerry), ALABS; Lou > Berger Cc : > > pce@ietf.org Objet : Re: [Pce] Changes in the new revision of the > > architecture I-D > > > > JL, > > > > See in-line. > > > > Igor > > > > ----- Original Message ----- > > From: "LE ROUX Jean-Louis RD-CORE-LAN" > > > > To: "Igor Bryskin" ; "JP Vasseur" > > ; ; "Ash, Gerald R > (Jerry), > > ALABS" ; "Lou Berger" > > Cc: > > Sent: Wednesday, July 27, 2005 10:14 AM > > Subject: RE: [Pce] Changes in the new revision of the > architecture I-D > > > > > > Hi Igor > > > > Please see inline > > > > > -----Message d'origine----- > > > De : pce-bounces@lists.ietf.org > > > [mailto:pce-bounces@lists.ietf.org] De la part de Igor Bryskin > > > Envoy=E9 : mercredi 27 juillet 2005 16:01 =C0 : JP Vasseur; > > > zzx-adrian@olddog.co.uk; Ash, Gerald R (Jerry), ALABS; > Lou Berger Cc > > > : pce@ietf.org Objet : Re: [Pce] Changes in the new > revision of the > > architecture I-D > > > > > > Hi, > > > > > > I think Lou has just brought up a very important discussion. > > > > > > A PCE can apply a policy for a particular path > computation request > > > only IFF it can identify original requestor. Consider the > situation > > > when a single request involves 2 PCEs: > > > PCC<=3D>PCE1<=3D>PCE2. > > > > > > PCE1 can identify the PCC and apply the polices for this > PCC or this > > > class of PCCs. However, PCE2 will not be capable to > identify PCC ( > > > we seem to agree already that PCC-PCE and PCE-PCE is the same > > > protocol, hence PCE2 will see PCE1 as > > > PCC) > > > > And where is the problem? Policy have a local PCC-PCE meaning > > PCE1 that sends a request to PCE2 is considered as a PCC, and > > PCE2 applies > > the policy to PCE1 > > PCE1 offers a service to PCC, PCE2 offers a service to PCE1, To my > > mind policies must have a local client-server scope. > > Path requests have a local PCC-PCE scope. > > PCE2 doesn't care whether PCE1 request has been triggered by PCC > > request to > > PCE1 or not. It serves a request from PCE1 and that's all... > > > > IB>> The problem is in my opinion quite obvious. A PCC sends > > a request to > > PCE1 with a lot of constraints and optimization objectives. > > PCE1 recognizes > > the PCC as "unimportant" and is about to perform some "cheap" > > heuristic. > > However, it does not have visibility to the destination, hence it > > relays the request to PCE2. PCE2 recognizes the PCE1 as a "very > > important" client and tries to satisfy the request as best > as it can, > > which may take 25% of its CPU capacity. Now, if you have > several more > > such "unimportant" PCCs, you get your PCE2 saturated very quickly. > > > > Igor > > > > >, and will apply a wrong policy. For instance, it may invoke a > > >computationally expensive algorithm, which it won't do if the PCC > > >requested computation directly from PCC2. > > > > And what is the problem?, this is up to PCE1 to apply > correct policies > > > > > > > > So, in the architecture document the reasons should be > described why > > > the identity of the original requestor should be > available for all > > > PCEs involved in particular path computation request. > > > > A path computation request should IMHO have a local scope > Multiple-PCE > > path computation should be considered as a cascade of > requests rather > > than the propagation of the same request, and local PCC-PCE > policies > > should be applied for each request... > > > > > > Regards, > > > > JL > > > > > Secondly, the same point should be > > > reflected in the path computation communication protocol > > requirements. > > > > > > Igor > > > > > > ----- Original Message ----- > > > From: "Lou Berger" > > > To: "JP Vasseur" ; "Adrian Farrel" > > > ; "Ash, Gerald R (Jerry), ALABS" > > > > Cc: > > > Sent: Tuesday, July 26, 2005 7:14 PM > > > Subject: Re: [Pce] Changes in the new revision of the > > architecture I-D > > > > > > > > > > At 09:24 AM 7/23/2005, JP Vasseur wrote: > > > > >We think that the ID is pretty stable in term of > > technical content. > > > > >As Adrian pointed out, there might be some editorial work > > > to be done > > > > >before WG last call. So the short answer is "as soon as > > possible". > > > > > > > > > >Thanks. > > > > > > > > > >JP. > > > > > > > > JP/Adrian/Jerry, > > > > As you say, the draft has come together very > nicely. The > > > > primary comment I have on the document is related to > how policy is > > > > presented in the draft: > > > > > > > > The draft does mention policy in multiple places, but > > these mentions > > > > are more "in-passing" than as major component. It seems > > to me that > > > > Policy and the ability to support path computation based on, or > > > > influenced by policies, must be a major part of the PCE > > > > architecture. I do agree with draft in that "policy > > between domains > > > > and between PCEs, and is achieved through configuration > > not through > > > > protocol communications." That said, the PCC-PCE and PCE-PCE > > > > communication protocols must support the communication of all > > > > information needed to support the installed policies, > as well as > > > > support any policy triggered transactions that may > result due to a > > > > policy (or change in policy). Also, in order to deliver viable > > > > policy to PCE, policy must not be an after thought. > (Consider how > > > > successful original RSVP was with bringing in policy > > after the core > > > > work was complete.) > > > > > > > > In short, I think policy should be more prominent in the > > > draft and in > > > > the PCE architecture. > > > > > > > > I suggest to: > > > > - add policy related motivations in section 4, > > > > - add a policy component to the PCE architecture(s) > > > presented in section > > > 5, > > > > - add a full fledged Policy sub-section to section 6 that > > > is separate > > > > from confidentiality. > > > > - and add a policy related evaluation metric to section 7. > > > > > > > > Please let me know what you think. > > > > > > > > I'll put together some specific text for fodder.... > > > > > > > > Lou > > > > > > > > > > > > _______________________________________________ > > > > Pce mailing list > > > > Pce@lists.ietf.org > > > > https://www1.ietf.org/mailman/listinfo/pce > > > > > > > > > > > > > _______________________________________________ > > > Pce mailing list > > > Pce@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/pce > > > > > > > > > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Jul 27 13:37:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxpqs-00039T-7X; Wed, 27 Jul 2005 13:37:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxpqq-00039C-He for pce@megatron.ietf.org; Wed, 27 Jul 2005 13:37:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16462 for ; Wed, 27 Jul 2005 13:37:48 -0400 (EDT) Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxqM8-0004v4-TI for pce@ietf.org; Wed, 27 Jul 2005 14:10:13 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Wed, 27 Jul 2005 19:36:45 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Pce] Changes in the new revision of the architecture I-D Date: Wed, 27 Jul 2005 19:36:44 +0200 Message-ID: Thread-Topic: [Pce] Changes in the new revision of the architecture I-D Thread-Index: AcWSzV4bUzGCXbAGTdqlsFIwLY/4lwAAD6cQ From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "Igor Bryskin" , "JP Vasseur" , , "Ash, Gerald R \(Jerry\), ALABS" , "Lou Berger" X-OriginalArrivalTime: 27 Jul 2005 17:36:45.0378 (UTC) FILETIME=[C231A220:01C592D1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 89ebdf268eceaeaf784b3acb625dc20e Content-Transfer-Encoding: quoted-printable Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi Igor See inline=20 > -----Message d'origine----- > De : Igor Bryskin [mailto:ibryskin@movaz.com]=20 > Envoy=E9 : mercredi 27 juillet 2005 19:05 > =C0 : LE ROUX Jean-Louis RD-CORE-LAN; JP Vasseur;=20 > zzx-adrian@olddog.co.uk; Ash, Gerald R (Jerry), ALABS; Lou Berger > Cc : pce@ietf.org > Objet : Re: [Pce] Changes in the new revision of the architecture I-D >=20 > Jl, >=20 > 1. PCE2 publishes its presence, hence it must be prepared to=20 > receive requests from many clients and may have policies for=20 > some of them.=20 This is a strong assumption... PCE2 does not necessarily publish its presence accross domains, please see section 6.2 of [PCE-DISC]. E.g. let's assume that PCE1 and PCE2 belong to distinct service = providers (let say SP1 and SP2)... A possible ( and valuable :-) approach is that PCE1 statically discover = PCE2. PCCs in SP1 are not aware of PCE2. There is a policy on PCE2 so = that all requests coming from SP1 are rejected except those from PCE1. Hence all the trust rely on PCE1-PCE2 communication. In that case advertising orignator id so as to apply a specific policy on PCE2 does = not really make sense as PCE2 is not aware of PCCs in SP1... >In our example the PCE2 could get a request=20 > directly from the PCC, may have a policy for the PCC (not=20 > necessarily identical to the policy that the PCE1 has). >=20 > 2. PCE1 in our example can always put its own ID as request=20 > originator ID in the request to PCE2 and modify the request=20 > to reflect its importance as far as it sees it (exactly your=20 > model). Alternatively. PCE1 may choose not to modify the=20 > request (changing neither request originator ID nor=20 > constraints) and let PCE2 treat the request according to its=20 > own policies. > In the latter > case: PCC->PCE1->PCE2->PCE1->PCC and=20 > PCC->PCE1->PCC->PCE2->PCC sequences will likely to produce=20 > the same resulting paths. OK in this case PCE1 is simply acting as a proxy, but again this = requires that PCE2 be aware of PCCs in domain 1 which is IMHO a strong = assumption not always (and not often when domain =3D SP) valid... Again think about confidentiality, scalability accross AS/SPs... It seems that it is time to start working on application specific = requirements... >=20 > In any case enabling all PCEs involved in the request to be=20 > aware of the "real" originator seems to me a more flexible approach. I disagree, in various cases policing based on the orignator does not = make sense and cannot work >=20 > On more general note it is obvious that articulating policies=20 > between PCE wrt specific request has never been discussed and=20 > we should IMO, starting with the architecture. Fully agree >=20 > See you in Paris, OK let's discuss this point in Paris Best Regards, JL > Igor >=20 > ----- Original Message ----- > From: "LE ROUX Jean-Louis RD-CORE-LAN"=20 > > To: "Igor Bryskin" ; "JP Vasseur"=20 > ; ; "Ash, Gerald R=20 > (Jerry), ALABS" ; "Lou Berger" > Cc: > Sent: Wednesday, July 27, 2005 11:39 AM > Subject: RE: [Pce] Changes in the new revision of the architecture I-D >=20 >=20 > Hi Igor >=20 > > -----Message d'origine----- > > De : Igor Bryskin [mailto:ibryskin@movaz.com] > > Envoy=E9 : mercredi 27 juillet 2005 17:13 > > =C0 : LE ROUX Jean-Louis RD-CORE-LAN; JP Vasseur; > > zzx-adrian@olddog.co.uk; Ash, Gerald R (Jerry), ALABS; Lou Berger > > Cc : pce@ietf.org > > Objet : Re: [Pce] Changes in the new revision of the=20 > architecture I-D > > > > JL, > > > > PCE1 could reflect "low importance" in the request sent to > > PCE2, by mean of specific objective function selection (IB>> > > which? how?), >=20 > Solution to encode objective function are not yet specified,=20 > btw this should > be addressed in future PCEP revisions. > But have a look at the text related to objective function and > parameterization of these functions in the communication=20 > protocol generic > requirements. > This may allow to request for what you call "cheap" or "expansive" > heuristics... >=20 >=20 >=20 > > > > request priority (IB>> won't help, PCE2 will just move > > request into lower priority task) >=20 > Right >=20 > > > > or potentially using a dedicated parameter (yet not defined). > > IB>> And the point is why not to use the original requestor=20 > ID as the > > dedicated parameter you mentioned, so that PCE2 could apply > > the policy of its own? >=20 > Hence PCE2 would have to be aware of all PCCs in other domains... > Think about scalability, confidentiality, and policy configurations... > This is up to PCE1 to notify the importance of the request to PCE2. > In the PCC->PCE1->PCE2 cascade, PCC IS NOT a client of PCE2,=20 > PCC is a client > of PCE1, so if PCE1 considers that the request is not so=20 > "important" it > should reflect that in the request sent to PCE2 (control of objective > function, or maybe using a specific "importance" parameter). > We should consider that PCEs may not be aware of PCCs in other domains >=20 > > > > Please not that in inter-AS/SP environment there may be cases > > where PCE2 MUST not have knowledge of PCC... > > IB>> No problem here, original requestor ID will be > > "unknown", and PCE2 > > might have a policy for such clients as well >=20 > So, if I follow you, the same policies would be applied for all unknow > clients...This does not sound really acceptable. >=20 > Regards, >=20 > JL >=20 > > > > Igor > > > > Regards, > > > > JL > > > > > -----Message d'origine----- > > > De : Igor Bryskin [mailto:ibryskin@movaz.com] Envoy=E9 : mercredi = 27 > > > juillet 2005 16:45 =C0 : LE ROUX Jean-Louis RD-CORE-LAN; JP = Vasseur; > > > zzx-adrian@olddog.co.uk; Ash, Gerald R (Jerry), ALABS; Lou > > Berger Cc : > > > pce@ietf.org Objet : Re: [Pce] Changes in the new revision of the > > > architecture I-D > > > > > > JL, > > > > > > See in-line. > > > > > > Igor > > > > > > ----- Original Message ----- > > > From: "LE ROUX Jean-Louis RD-CORE-LAN" > > > > > > To: "Igor Bryskin" ; "JP Vasseur" > > > ; ; "Ash, Gerald R > > (Jerry), > > > ALABS" ; "Lou Berger" > > > Cc: > > > Sent: Wednesday, July 27, 2005 10:14 AM > > > Subject: RE: [Pce] Changes in the new revision of the > > architecture I-D > > > > > > > > > Hi Igor > > > > > > Please see inline > > > > > > > -----Message d'origine----- > > > > De : pce-bounces@lists.ietf.org > > > > [mailto:pce-bounces@lists.ietf.org] De la part de Igor Bryskin > > > > Envoy=E9 : mercredi 27 juillet 2005 16:01 =C0 : JP Vasseur; > > > > zzx-adrian@olddog.co.uk; Ash, Gerald R (Jerry), ALABS; > > Lou Berger Cc > > > > : pce@ietf.org Objet : Re: [Pce] Changes in the new > > revision of the > > > architecture I-D > > > > > > > > Hi, > > > > > > > > I think Lou has just brought up a very important discussion. > > > > > > > > A PCE can apply a policy for a particular path > > computation request > > > > only IFF it can identify original requestor. Consider the > > situation > > > > when a single request involves 2 PCEs: > > > > PCC<=3D>PCE1<=3D>PCE2. > > > > > > > > PCE1 can identify the PCC and apply the polices for this > > PCC or this > > > > class of PCCs. However, PCE2 will not be capable to > > identify PCC ( > > > > we seem to agree already that PCC-PCE and PCE-PCE is the same > > > > protocol, hence PCE2 will see PCE1 as > > > > PCC) > > > > > > And where is the problem? Policy have a local PCC-PCE meaning > > > PCE1 that sends a request to PCE2 is considered as a PCC, and > > > PCE2 applies > > > the policy to PCE1 > > > PCE1 offers a service to PCC, PCE2 offers a service to PCE1, To my > > > mind policies must have a local client-server scope. > > > Path requests have a local PCC-PCE scope. > > > PCE2 doesn't care whether PCE1 request has been triggered by PCC > > > request to > > > PCE1 or not. It serves a request from PCE1 and that's all... > > > > > > IB>> The problem is in my opinion quite obvious. A PCC sends > > > a request to > > > PCE1 with a lot of constraints and optimization objectives. > > > PCE1 recognizes > > > the PCC as "unimportant" and is about to perform some "cheap" > > > heuristic. > > > However, it does not have visibility to the destination, hence it > > > relays the request to PCE2. PCE2 recognizes the PCE1 as a "very > > > important" client and tries to satisfy the request as best > > as it can, > > > which may take 25% of its CPU capacity. Now, if you have > > several more > > > such "unimportant" PCCs, you get your PCE2 saturated very quickly. > > > > > > Igor > > > > > > >, and will apply a wrong policy. For instance, it may invoke a > > > >computationally expensive algorithm, which it won't do=20 > if the PCC > > > >requested computation directly from PCC2. > > > > > > And what is the problem?, this is up to PCE1 to apply > > correct policies > > > > > > > > > > > So, in the architecture document the reasons should be > > described why > > > > the identity of the original requestor should be > > available for all > > > > PCEs involved in particular path computation request. > > > > > > A path computation request should IMHO have a local scope > > Multiple-PCE > > > path computation should be considered as a cascade of > > requests rather > > > than the propagation of the same request, and local PCC-PCE > > policies > > > should be applied for each request... > > > > > > > > > Regards, > > > > > > JL > > > > > > > Secondly, the same point should be > > > > reflected in the path computation communication protocol > > > requirements. > > > > > > > > Igor > > > > > > > > ----- Original Message ----- > > > > From: "Lou Berger" > > > > To: "JP Vasseur" ; "Adrian Farrel" > > > > ; "Ash, Gerald R (Jerry), ALABS" > > > > > > Cc: > > > > Sent: Tuesday, July 26, 2005 7:14 PM > > > > Subject: Re: [Pce] Changes in the new revision of the > > > architecture I-D > > > > > > > > > > > > > At 09:24 AM 7/23/2005, JP Vasseur wrote: > > > > > >We think that the ID is pretty stable in term of > > > technical content. > > > > > >As Adrian pointed out, there might be some editorial work > > > > to be done > > > > > >before WG last call. So the short answer is "as soon as > > > possible". > > > > > > > > > > > >Thanks. > > > > > > > > > > > >JP. > > > > > > > > > > JP/Adrian/Jerry, > > > > > As you say, the draft has come together very > > nicely. The > > > > > primary comment I have on the document is related to > > how policy is > > > > > presented in the draft: > > > > > > > > > > The draft does mention policy in multiple places, but > > > these mentions > > > > > are more "in-passing" than as major component. It seems > > > to me that > > > > > Policy and the ability to support path computation=20 > based on, or > > > > > influenced by policies, must be a major part of the PCE > > > > > architecture. I do agree with draft in that "policy > > > between domains > > > > > and between PCEs, and is achieved through configuration > > > not through > > > > > protocol communications." That said, the PCC-PCE and PCE-PCE > > > > > communication protocols must support the communication of all > > > > > information needed to support the installed policies, > > as well as > > > > > support any policy triggered transactions that may > > result due to a > > > > > policy (or change in policy). Also, in order to=20 > deliver viable > > > > > policy to PCE, policy must not be an after thought. > > (Consider how > > > > > successful original RSVP was with bringing in policy > > > after the core > > > > > work was complete.) > > > > > > > > > > In short, I think policy should be more prominent in the > > > > draft and in > > > > > the PCE architecture. > > > > > > > > > > I suggest to: > > > > > - add policy related motivations in section 4, > > > > > - add a policy component to the PCE architecture(s) > > > > presented in section > > > > 5, > > > > > - add a full fledged Policy sub-section to section 6 that > > > > is separate > > > > > from confidentiality. > > > > > - and add a policy related evaluation metric to section 7. > > > > > > > > > > Please let me know what you think. > > > > > > > > > > I'll put together some specific text for fodder.... > > > > > > > > > > Lou > > > > > > > > > > > > > > > _______________________________________________ > > > > > Pce mailing list > > > > > Pce@lists.ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/pce > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Pce mailing list > > > > Pce@lists.ietf.org > > > > https://www1.ietf.org/mailman/listinfo/pce > > > > > > > > > > > > > > >=20 >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Jul 27 14:43:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxqru-0001SA-OG; Wed, 27 Jul 2005 14:43:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxqrt-0001Rc-CZ for pce@megatron.ietf.org; Wed, 27 Jul 2005 14:43:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22381 for ; Wed, 27 Jul 2005 14:42:59 -0400 (EDT) Received: from webmail.movaz.com ([65.205.166.188] helo=jera.movaz.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxrNC-0007UY-DK for pce@ietf.org; Wed, 27 Jul 2005 15:15:23 -0400 Received: from ib (unknown [172.16.24.122]) by jera.movaz.com (Postfix) with SMTP id 19E2480F5; Wed, 27 Jul 2005 14:42:51 -0400 (EDT) Message-ID: <011601c592da$fe204260$7a1810ac@movaz.com> From: "Igor Bryskin" To: "LE ROUX Jean-Louis RD-CORE-LAN" , "JP Vasseur" , , "Ash, Gerald R (Jerry), ALABS" , "Lou Berger" References: Subject: Re: [Pce] Changes in the new revision of the architecture I-D Date: Wed, 27 Jul 2005 14:42:50 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: 563af5038a5e1dade28c8affc0fff375 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id OAA22381 Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org JL, Ok, one last attempt. Nobody says that a PCE must have policies about every PCC, but it might h= ave about some and might want to apply them whether the request comes directl= y or via some other PCE(s). Your example when PCE1 and PCE2 belong to different providers and PCE2's address is configured locally presents NO problem - PCE1 knows about this fact and ALWAYS replaces the originator ID with its own before sending th= e request to the PCE2. But how about the case when multiple PCEs work withi= n a single provider, where all of them publish their presence and the PCE2 ma= y get a relayed request from the PCE1 OR direct from the PCC? Why is it not wiser to let PCE2 apply its own policy wrt the PCC? Just to state "I disagree, in various cases policing based on the originator does not make sense and cannot work" is not good enough. Besides, I'd also like to hear what the architecture authors think about this. Let's discuss more in Paris. I have some other issues with the architectu= re anyway. Regards, Igor ----- Original Message -----=20 From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "Igor Bryskin" ; "JP Vasseur" ; ; "Ash, Gerald R (Jerry), ALABS" ; "Lo= u Berger" Cc: Sent: Wednesday, July 27, 2005 1:36 PM Subject: RE: [Pce] Changes in the new revision of the architecture I-D Hi Igor See inline > -----Message d'origine----- > De : Igor Bryskin [mailto:ibryskin@movaz.com] > Envoy=E9 : mercredi 27 juillet 2005 19:05 > =C0 : LE ROUX Jean-Louis RD-CORE-LAN; JP Vasseur; > zzx-adrian@olddog.co.uk; Ash, Gerald R (Jerry), ALABS; Lou Berger > Cc : pce@ietf.org > Objet : Re: [Pce] Changes in the new revision of the architecture I-D > > Jl, > > 1. PCE2 publishes its presence, hence it must be prepared to > receive requests from many clients and may have policies for > some of them. This is a strong assumption... PCE2 does not necessarily publish its presence accross domains, please see section 6.2 of [PCE-DISC]. E.g. let's assume that PCE1 and PCE2 belong to distinct service providers (let say SP1 and SP2)... A possible ( and valuable :-) approach is that PCE1 statically discover PCE2. PCCs in SP1 are not aware of PCE2. There is a policy on PCE2 so tha= t all requests coming from SP1 are rejected except those from PCE1. Hence all the trust rely on PCE1-PCE2 communication. In that case advertising orignator id so as to apply a specific policy on PCE2 does no= t really make sense as PCE2 is not aware of PCCs in SP1... >In our example the PCE2 could get a request > directly from the PCC, may have a policy for the PCC (not > necessarily identical to the policy that the PCE1 has). > > 2. PCE1 in our example can always put its own ID as request > originator ID in the request to PCE2 and modify the request > to reflect its importance as far as it sees it (exactly your > model). Alternatively. PCE1 may choose not to modify the > request (changing neither request originator ID nor > constraints) and let PCE2 treat the request according to its > own policies. > In the latter > case: PCC->PCE1->PCE2->PCE1->PCC and > PCC->PCE1->PCC->PCE2->PCC sequences will likely to produce > the same resulting paths. OK in this case PCE1 is simply acting as a proxy, but again this requires that PCE2 be aware of PCCs in domain 1 which is IMHO a strong assumption not always (and not often when domain =3D SP) valid... Again think about confidentiality, scalability accross AS/SPs... It seems that it is time to start working on application specific requirements... > > In any case enabling all PCEs involved in the request to be > aware of the "real" originator seems to me a more flexible approach. I disagree, in various cases policing based on the orignator does not mak= e sense and cannot work > > On more general note it is obvious that articulating policies > between PCE wrt specific request has never been discussed and > we should IMO, starting with the architecture. Fully agree > > See you in Paris, OK let's discuss this point in Paris Best Regards, JL > Igor > > ----- Original Message ----- > From: "LE ROUX Jean-Louis RD-CORE-LAN" > > To: "Igor Bryskin" ; "JP Vasseur" > ; ; "Ash, Gerald R > (Jerry), ALABS" ; "Lou Berger" > Cc: > Sent: Wednesday, July 27, 2005 11:39 AM > Subject: RE: [Pce] Changes in the new revision of the architecture I-D > > > Hi Igor > > > -----Message d'origine----- > > De : Igor Bryskin [mailto:ibryskin@movaz.com] > > Envoy=E9 : mercredi 27 juillet 2005 17:13 > > =C0 : LE ROUX Jean-Louis RD-CORE-LAN; JP Vasseur; > > zzx-adrian@olddog.co.uk; Ash, Gerald R (Jerry), ALABS; Lou Berger > > Cc : pce@ietf.org > > Objet : Re: [Pce] Changes in the new revision of the > architecture I-D > > > > JL, > > > > PCE1 could reflect "low importance" in the request sent to > > PCE2, by mean of specific objective function selection (IB>> > > which? how?), > > Solution to encode objective function are not yet specified, > btw this should > be addressed in future PCEP revisions. > But have a look at the text related to objective function and > parameterization of these functions in the communication > protocol generic > requirements. > This may allow to request for what you call "cheap" or "expansive" > heuristics... > > > > > > > request priority (IB>> won't help, PCE2 will just move > > request into lower priority task) > > Right > > > > > or potentially using a dedicated parameter (yet not defined). > > IB>> And the point is why not to use the original requestor > ID as the > > dedicated parameter you mentioned, so that PCE2 could apply > > the policy of its own? > > Hence PCE2 would have to be aware of all PCCs in other domains... > Think about scalability, confidentiality, and policy configurations... > This is up to PCE1 to notify the importance of the request to PCE2. > In the PCC->PCE1->PCE2 cascade, PCC IS NOT a client of PCE2, > PCC is a client > of PCE1, so if PCE1 considers that the request is not so > "important" it > should reflect that in the request sent to PCE2 (control of objective > function, or maybe using a specific "importance" parameter). > We should consider that PCEs may not be aware of PCCs in other domains > > > > > Please not that in inter-AS/SP environment there may be cases > > where PCE2 MUST not have knowledge of PCC... > > IB>> No problem here, original requestor ID will be > > "unknown", and PCE2 > > might have a policy for such clients as well > > So, if I follow you, the same policies would be applied for all unknow > clients...This does not sound really acceptable. > > Regards, > > JL > > > > > Igor > > > > Regards, > > > > JL > > > > > -----Message d'origine----- > > > De : Igor Bryskin [mailto:ibryskin@movaz.com] Envoy=E9 : mercredi 2= 7 > > > juillet 2005 16:45 =C0 : LE ROUX Jean-Louis RD-CORE-LAN; JP Vasseur= ; > > > zzx-adrian@olddog.co.uk; Ash, Gerald R (Jerry), ALABS; Lou > > Berger Cc : > > > pce@ietf.org Objet : Re: [Pce] Changes in the new revision of the > > > architecture I-D > > > > > > JL, > > > > > > See in-line. > > > > > > Igor > > > > > > ----- Original Message ----- > > > From: "LE ROUX Jean-Louis RD-CORE-LAN" > > > > > > To: "Igor Bryskin" ; "JP Vasseur" > > > ; ; "Ash, Gerald R > > (Jerry), > > > ALABS" ; "Lou Berger" > > > Cc: > > > Sent: Wednesday, July 27, 2005 10:14 AM > > > Subject: RE: [Pce] Changes in the new revision of the > > architecture I-D > > > > > > > > > Hi Igor > > > > > > Please see inline > > > > > > > -----Message d'origine----- > > > > De : pce-bounces@lists.ietf.org > > > > [mailto:pce-bounces@lists.ietf.org] De la part de Igor Bryskin > > > > Envoy=E9 : mercredi 27 juillet 2005 16:01 =C0 : JP Vasseur; > > > > zzx-adrian@olddog.co.uk; Ash, Gerald R (Jerry), ALABS; > > Lou Berger Cc > > > > : pce@ietf.org Objet : Re: [Pce] Changes in the new > > revision of the > > > architecture I-D > > > > > > > > Hi, > > > > > > > > I think Lou has just brought up a very important discussion. > > > > > > > > A PCE can apply a policy for a particular path > > computation request > > > > only IFF it can identify original requestor. Consider the > > situation > > > > when a single request involves 2 PCEs: > > > > PCC<=3D>PCE1<=3D>PCE2. > > > > > > > > PCE1 can identify the PCC and apply the polices for this > > PCC or this > > > > class of PCCs. However, PCE2 will not be capable to > > identify PCC ( > > > > we seem to agree already that PCC-PCE and PCE-PCE is the same > > > > protocol, hence PCE2 will see PCE1 as > > > > PCC) > > > > > > And where is the problem? Policy have a local PCC-PCE meaning > > > PCE1 that sends a request to PCE2 is considered as a PCC, and > > > PCE2 applies > > > the policy to PCE1 > > > PCE1 offers a service to PCC, PCE2 offers a service to PCE1, To my > > > mind policies must have a local client-server scope. > > > Path requests have a local PCC-PCE scope. > > > PCE2 doesn't care whether PCE1 request has been triggered by PCC > > > request to > > > PCE1 or not. It serves a request from PCE1 and that's all... > > > > > > IB>> The problem is in my opinion quite obvious. A PCC sends > > > a request to > > > PCE1 with a lot of constraints and optimization objectives. > > > PCE1 recognizes > > > the PCC as "unimportant" and is about to perform some "cheap" > > > heuristic. > > > However, it does not have visibility to the destination, hence it > > > relays the request to PCE2. PCE2 recognizes the PCE1 as a "very > > > important" client and tries to satisfy the request as best > > as it can, > > > which may take 25% of its CPU capacity. Now, if you have > > several more > > > such "unimportant" PCCs, you get your PCE2 saturated very quickly. > > > > > > Igor > > > > > > >, and will apply a wrong policy. For instance, it may invoke a > > > >computationally expensive algorithm, which it won't do > if the PCC > > > >requested computation directly from PCC2. > > > > > > And what is the problem?, this is up to PCE1 to apply > > correct policies > > > > > > > > > > > So, in the architecture document the reasons should be > > described why > > > > the identity of the original requestor should be > > available for all > > > > PCEs involved in particular path computation request. > > > > > > A path computation request should IMHO have a local scope > > Multiple-PCE > > > path computation should be considered as a cascade of > > requests rather > > > than the propagation of the same request, and local PCC-PCE > > policies > > > should be applied for each request... > > > > > > > > > Regards, > > > > > > JL > > > > > > > Secondly, the same point should be > > > > reflected in the path computation communication protocol > > > requirements. > > > > > > > > Igor > > > > > > > > ----- Original Message ----- > > > > From: "Lou Berger" > > > > To: "JP Vasseur" ; "Adrian Farrel" > > > > ; "Ash, Gerald R (Jerry), ALABS" > > > > > > Cc: > > > > Sent: Tuesday, July 26, 2005 7:14 PM > > > > Subject: Re: [Pce] Changes in the new revision of the > > > architecture I-D > > > > > > > > > > > > > At 09:24 AM 7/23/2005, JP Vasseur wrote: > > > > > >We think that the ID is pretty stable in term of > > > technical content. > > > > > >As Adrian pointed out, there might be some editorial work > > > > to be done > > > > > >before WG last call. So the short answer is "as soon as > > > possible". > > > > > > > > > > > >Thanks. > > > > > > > > > > > >JP. > > > > > > > > > > JP/Adrian/Jerry, > > > > > As you say, the draft has come together very > > nicely. The > > > > > primary comment I have on the document is related to > > how policy is > > > > > presented in the draft: > > > > > > > > > > The draft does mention policy in multiple places, but > > > these mentions > > > > > are more "in-passing" than as major component. It seems > > > to me that > > > > > Policy and the ability to support path computation > based on, or > > > > > influenced by policies, must be a major part of the PCE > > > > > architecture. I do agree with draft in that "policy > > > between domains > > > > > and between PCEs, and is achieved through configuration > > > not through > > > > > protocol communications." That said, the PCC-PCE and PCE-PCE > > > > > communication protocols must support the communication of all > > > > > information needed to support the installed policies, > > as well as > > > > > support any policy triggered transactions that may > > result due to a > > > > > policy (or change in policy). Also, in order to > deliver viable > > > > > policy to PCE, policy must not be an after thought. > > (Consider how > > > > > successful original RSVP was with bringing in policy > > > after the core > > > > > work was complete.) > > > > > > > > > > In short, I think policy should be more prominent in the > > > > draft and in > > > > > the PCE architecture. > > > > > > > > > > I suggest to: > > > > > - add policy related motivations in section 4, > > > > > - add a policy component to the PCE architecture(s) > > > > presented in section > > > > 5, > > > > > - add a full fledged Policy sub-section to section 6 that > > > > is separate > > > > > from confidentiality. > > > > > - and add a policy related evaluation metric to section 7. > > > > > > > > > > Please let me know what you think. > > > > > > > > > > I'll put together some specific text for fodder.... > > > > > > > > > > Lou > > > > > > > > > > > > > > > _______________________________________________ > > > > > Pce mailing list > > > > > Pce@lists.ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/pce > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Pce mailing list > > > > Pce@lists.ietf.org > > > > https://www1.ietf.org/mailman/listinfo/pce > > > > > > > > > > > > > > > > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Jul 27 15:45:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxrqe-0002lQ-5y; Wed, 27 Jul 2005 15:45:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxrqc-0002lL-AO for pce@megatron.ietf.org; Wed, 27 Jul 2005 15:45:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27638 for ; Wed, 27 Jul 2005 15:45:43 -0400 (EDT) Received: from webmail.movaz.com ([65.205.166.188] helo=jera.movaz.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxsLs-0000x9-Vg for pce@ietf.org; Wed, 27 Jul 2005 16:18:08 -0400 Received: from ib (unknown [172.16.24.122]) by jera.movaz.com (Postfix) with SMTP id 282B580F5; Wed, 27 Jul 2005 15:45:33 -0400 (EDT) Message-ID: <014e01c592e3$c075bc20$7a1810ac@movaz.com> From: "Igor Bryskin" To: "Alia Atlas" References: <011601c592da$fe204260$7a1810ac@movaz.com> <6280db5205072712375902fd6f@mail.gmail.com> Subject: Re: [Pce] Changes in the new revision of the architecture I-D Date: Wed, 27 Jul 2005 15:45:32 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Alia, Sounds like one good way to address the problem. But this is just one problem related to policies. The higher level discussion is necessary. See you in Paris, Igor ----- Original Message ----- From: "Alia Atlas" To: "Igor Bryskin" Cc: "LE ROUX Jean-Louis RD-CORE-LAN" ; "JP Vasseur" ; ; "Ash, Gerald R (Jerry), ALABS" ; "Lou Berger" ; Sent: Wednesday, July 27, 2005 3:37 PM Subject: Re: [Pce] Changes in the new revision of the architecture I-D On 7/27/05, Igor Bryskin wrote: > Nobody says that a PCE must have policies about every PCC, but it might have > about some and might want to apply them whether the request comes directly > or via some other PCE(s). > > Your example when PCE1 and PCE2 belong to different providers and PCE2's > address is configured locally presents NO problem - PCE1 knows about this > fact and ALWAYS replaces the originator ID with its own before sending the > request to the PCE2. But how about the case when multiple PCEs work within a > single provider, where all of them publish their presence and the PCE2 may > get a relayed request from the PCE1 OR direct from the PCC? Why is it not > wiser to let PCE2 apply its own policy wrt the PCC? Just to state "I > disagree, in various cases policing based on the originator does not make > sense and cannot work" is not good enough. Does it help to change the assumption that PCE1 can only have one sourcing identity? I.e., let PCE1 apply policy to the originator PCC & derive an proxy originator to pass on to PCE2. Then PCE2 just needs to know about and have policy on the set of proxy originators that it agrees to support from PCE1. Basically, PCE1 decides how to set the originator based on where PCE2 is and what agreements may be in force with PCE2. In the first case, where PCE1 and PCE2 belong to the same service provider (or possibly are just in the same area, depending on distributed knowledge), PCE1 can decide not to proxy the originator and just specify an orginator = PCC. In the second case, where PCE1 and PCE2 belong to different service providers, PCE1 can decide to proxy the originator so that originator = proxy(PCC, policy(PCE1, PCE2)). Alia _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Jul 27 16:01:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxs5l-0007lv-VX; Wed, 27 Jul 2005 16:01:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxs5k-0007ll-S4 for pce@megatron.ietf.org; Wed, 27 Jul 2005 16:01:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28599 for ; Wed, 27 Jul 2005 16:01:22 -0400 (EDT) Received: from astro.systems.pipex.net ([62.241.163.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dxsb2-0001Ne-HD for pce@ietf.org; Wed, 27 Jul 2005 16:33:47 -0400 Received: from Puppy (81-178-114-56.dsl.pipex.com [81.178.114.56]) by astro.systems.pipex.net (Postfix) with SMTP id 657FFE0000DA; Wed, 27 Jul 2005 21:00:57 +0100 (BST) Message-ID: <009701c592e6$4352cb40$0601a8c0@Puppy> From: "Adrian Farrel" To: "JP Vasseur" , "Ash, Gerald R \(Jerry\), ALABS" , "Lou Berger" References: <154701c58d1f$ef014e70$d6849ed9@Puppy> <42E239D1.9010907@psg.com> <84945647-6729-4394-A308-17C1D3C79589@cisco.com> <6.2.3.4.2.20050726191150.03f4f040@mo-ex1> Subject: Re: [Pce] Changes in the new revision of the architecture I-D Date: Wed, 27 Jul 2005 19:25:39 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 0.1 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Thanks Lou, You raise an important point. Looking forward to seeing your text. Cheers, Adrian ----- Original Message ----- From: "Lou Berger" To: "JP Vasseur" ; "Adrian Farrel" ; "Ash, Gerald R (Jerry), ALABS" Cc: Sent: Wednesday, July 27, 2005 12:14 AM Subject: Re: [Pce] Changes in the new revision of the architecture I-D > At 09:24 AM 7/23/2005, JP Vasseur wrote: > >We think that the ID is pretty stable in term of technical content. > >As Adrian pointed out, there might be some editorial work to be done > >before WG last call. So the short answer is "as soon as possible". > > > >Thanks. > > > >JP. > > JP/Adrian/Jerry, > As you say, the draft has come together very nicely. The > primary comment I have on the document is related to how policy is > presented in the draft: > > The draft does mention policy in multiple places, but these mentions > are more "in-passing" than as major component. It seems to me that > Policy and the ability to support path computation based on, or > influenced by policies, must be a major part of the PCE > architecture. I do agree with draft in that "policy between domains > and between PCEs, and is achieved through configuration not through > protocol communications." That said, the PCC-PCE and PCE-PCE > communication protocols must support the communication of all > information needed to support the installed policies, as well as > support any policy triggered transactions that may result due to a > policy (or change in policy). Also, in order to deliver viable > policy to PCE, policy must not be an after thought. (Consider how > successful original RSVP was with bringing in policy after the core > work was complete.) > > In short, I think policy should be more prominent in the draft and in > the PCE architecture. > > I suggest to: > - add policy related motivations in section 4, > - add a policy component to the PCE architecture(s) presented in section 5, > - add a full fledged Policy sub-section to section 6 that is separate > from confidentiality. > - and add a policy related evaluation metric to section 7. > > Please let me know what you think. > > I'll put together some specific text for fodder.... > > Lou > > > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Jul 27 16:01:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxs5m-0007mK-9E; Wed, 27 Jul 2005 16:01:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxs5l-0007ln-4y for pce@megatron.ietf.org; Wed, 27 Jul 2005 16:01:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28602 for ; Wed, 27 Jul 2005 16:01:22 -0400 (EDT) Received: from astro.systems.pipex.net ([62.241.163.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dxsb4-0001Nh-6O for pce@ietf.org; Wed, 27 Jul 2005 16:33:47 -0400 Received: from Puppy (81-178-114-56.dsl.pipex.com [81.178.114.56]) by astro.systems.pipex.net (Postfix) with SMTP id 6D1FCE00008D; Wed, 27 Jul 2005 21:01:01 +0100 (BST) Message-ID: <009801c592e6$4383c650$0601a8c0@Puppy> From: "Adrian Farrel" To: "Ash, Gerald R \(Jerry\), ALABS" , "Vivek Dubey-G20041" , References: <9473683187ADC049A855ED2DA739ABCA09FA914D@KCCLUST06EVS1.ugd.att.com> Subject: Re: [Pce] draft-ietf-pce-architecture-01 Date: Wed, 27 Jul 2005 19:29:13 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org I think Vivek is raising a slightly different point. That is, allowing the PCE to handle a PCC that is misbehaving. Presumably a naughty PCC could ignore whatever throttling mechanisms are applied by the PCE. As Jerry says, this is an issue for the PCE-PCC generic communication requirements. Thanks, Adrian ----- Original Message ----- From: "Ash, Gerald R (Jerry), ALABS" To: "Vivek Dubey-G20041" ; Sent: Tuesday, July 26, 2005 10:53 AM Subject: RE: [Pce] draft-ietf-pce-architecture-01 Vivek, > In case of "External PCE" model, should there be a provision > provided at the PCE to protect it against flood of path > computation requests from a particular PCC (in case of > malfunctioning). See Section 6.1.8 of the PCE communication protocol (PCEP) generic requirements http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protocol-gen-req s-01.txt: " In some cases (e.g. after link failure), a large number of PCCs may simultaneously send requests to a PCE, leading to a potential saturation of the PCEs. The PCEP or the transport protocol it uses MUST properly handle such overload situations without a significant decrease in performance, such as through throttling of such requests." Thanks, Jerry _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Jul 27 16:06:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxsAI-0000Ga-BI; Wed, 27 Jul 2005 16:06:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxsAH-0000GV-OW for pce@megatron.ietf.org; Wed, 27 Jul 2005 16:06:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28862 for ; Wed, 27 Jul 2005 16:06:03 -0400 (EDT) Received: from webmail.movaz.com ([65.205.166.188] helo=jera.movaz.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dxsfa-0001Ud-U9 for pce@ietf.org; Wed, 27 Jul 2005 16:38:28 -0400 Received: from movaz-hw.movaz.com (movaz-hw.atlanta.movaz.com [172.16.8.183]) by jera.movaz.com (Postfix) with ESMTP id 6C154F90; Wed, 27 Jul 2005 16:05:55 -0400 (EDT) Received: from lb.movaz.com (localhost [127.0.0.1]) by movaz-hw.movaz.com (Postfix) with ESMTP id 6C7B8B00F; Wed, 27 Jul 2005 16:05:54 -0400 (EDT) Message-Id: <6.2.3.4.2.20050727160443.03fa2d78@mo-ex1> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Wed, 27 Jul 2005 16:05:50 -0400 To: "Adrian Farrel" From: Lou Berger Subject: Re: [Pce] Changes in the new revision of the architecture I-D In-Reply-To: <009701c592e6$4352cb40$0601a8c0@Puppy> References: <154701c58d1f$ef014e70$d6849ed9@Puppy> <42E239D1.9010907@psg.com> <84945647-6729-4394-A308-17C1D3C79589@cisco.com> <6.2.3.4.2.20050726191150.03f4f040@mo-ex1> <009701c592e6$4352cb40$0601a8c0@Puppy> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Typing some text up at the moment. Based on the immediate (and unforeseen) specific discussion my bet is that the text will hit just the tip of the iceberg! Lou At 02:25 PM 7/27/2005, Adrian Farrel wrote: >Thanks Lou, > >You raise an important point. >Looking forward to seeing your text. > > Cheers, >Adrian >----- Original Message ----- >From: "Lou Berger" >To: "JP Vasseur" ; "Adrian Farrel" >; "Ash, Gerald R (Jerry), ALABS" >Cc: >Sent: Wednesday, July 27, 2005 12:14 AM >Subject: Re: [Pce] Changes in the new revision of the architecture I-D > > > At 09:24 AM 7/23/2005, JP Vasseur wrote: > > >We think that the ID is pretty stable in term of technical content. > > >As Adrian pointed out, there might be some editorial work to be done > > >before WG last call. So the short answer is "as soon as possible". > > > > > >Thanks. > > > > > >JP. > > > > JP/Adrian/Jerry, > > As you say, the draft has come together very nicely. The > > primary comment I have on the document is related to how policy is > > presented in the draft: > > > > The draft does mention policy in multiple places, but these mentions > > are more "in-passing" than as major component. It seems to me that > > Policy and the ability to support path computation based on, or > > influenced by policies, must be a major part of the PCE > > architecture. I do agree with draft in that "policy between domains > > and between PCEs, and is achieved through configuration not through > > protocol communications." That said, the PCC-PCE and PCE-PCE > > communication protocols must support the communication of all > > information needed to support the installed policies, as well as > > support any policy triggered transactions that may result due to a > > policy (or change in policy). Also, in order to deliver viable > > policy to PCE, policy must not be an after thought. (Consider how > > successful original RSVP was with bringing in policy after the core > > work was complete.) > > > > In short, I think policy should be more prominent in the draft and in > > the PCE architecture. > > > > I suggest to: > > - add policy related motivations in section 4, > > - add a policy component to the PCE architecture(s) presented in section >5, > > - add a full fledged Policy sub-section to section 6 that is separate > > from confidentiality. > > - and add a policy related evaluation metric to section 7. > > > > Please let me know what you think. > > > > I'll put together some specific text for fodder.... > > > > Lou > > > > > > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Jul 27 16:06:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxsAY-0000OC-Ka; Wed, 27 Jul 2005 16:06:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxsAX-0000O7-H9 for pce@megatron.ietf.org; Wed, 27 Jul 2005 16:06:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28871 for ; Wed, 27 Jul 2005 16:06:19 -0400 (EDT) Received: from webmail.movaz.com ([65.205.166.188] helo=jera.movaz.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dxsfr-0001V8-Fb for pce@ietf.org; Wed, 27 Jul 2005 16:38:43 -0400 Received: from movaz-hw.movaz.com (movaz-hw.atlanta.movaz.com [172.16.8.183]) by jera.movaz.com (Postfix) with ESMTP id B60B4D2D; Wed, 27 Jul 2005 16:06:11 -0400 (EDT) Received: from lb.movaz.com (localhost [127.0.0.1]) by movaz-hw.movaz.com (Postfix) with ESMTP id F3A7DB00F; Wed, 27 Jul 2005 16:06:10 -0400 (EDT) Message-Id: <6.2.3.4.2.20050727160554.03e6def0@mo-ex1> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Wed, 27 Jul 2005 16:06:07 -0400 To: Alia Atlas From: Lou Berger Subject: Re: [Pce] Changes in the new revision of the architecture I-D In-Reply-To: <6280db5205072712375902fd6f@mail.gmail.com> References: <011601c592da$fe204260$7a1810ac@movaz.com> <6280db5205072712375902fd6f@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org This sounds just right to me... At 03:37 PM 7/27/2005, Alia Atlas wrote: >On 7/27/05, Igor Bryskin wrote: > > Nobody says that a PCE must have policies about every PCC, but it > might have > > about some and might want to apply them whether the request comes directly > > or via some other PCE(s). > > > > Your example when PCE1 and PCE2 belong to different providers and PCE2's > > address is configured locally presents NO problem - PCE1 knows about this > > fact and ALWAYS replaces the originator ID with its own before sending the > > request to the PCE2. But how about the case when multiple PCEs > work within a > > single provider, where all of them publish their presence and the PCE2 may > > get a relayed request from the PCE1 OR direct from the PCC? Why is it not > > wiser to let PCE2 apply its own policy wrt the PCC? Just to state "I > > disagree, in various cases policing based on the originator does not make > > sense and cannot work" is not good enough. > >Does it help to change the assumption that PCE1 can only have one >sourcing identity? I.e., let PCE1 apply policy to the originator PCC >& derive an proxy originator to pass on to PCE2. Then PCE2 just >needs to know about and have policy on the set of proxy originators >that it agrees to support from PCE1. > >Basically, PCE1 decides how to set the originator based on where PCE2 >is and what agreements may be in force with PCE2. > >In the first case, where PCE1 and PCE2 belong to the same service >provider (or possibly are just in the same area, depending on >distributed knowledge), PCE1 can decide not to proxy the originator >and just specify an orginator = PCC. > >In the second case, where PCE1 and PCE2 belong to different service >providers, PCE1 can decide to proxy the originator so that originator >= proxy(PCC, policy(PCE1, PCE2)). > >Alia _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Jul 27 16:40:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxsho-0002y7-Dw; Wed, 27 Jul 2005 16:40:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxriR-0000Y3-Nl for pce@megatron.ietf.org; Wed, 27 Jul 2005 15:37:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27307 for ; Wed, 27 Jul 2005 15:37:17 -0400 (EDT) Received: from wproxy.gmail.com ([64.233.184.192]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxsDi-0000ja-HV for pce@ietf.org; Wed, 27 Jul 2005 16:09:41 -0400 Received: by wproxy.gmail.com with SMTP id 55so263071wri for ; Wed, 27 Jul 2005 12:37:07 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=lUq5vBT3BvElvKnOq7mFUfLqZQH8MN5tUqkejRxin65q4bpsw4ypxZHFvE6lUWANi7iPcZt0RBeAzmvg8SCQIEZ8pM0lgMpNSJyabwEkyfupU4T8iP9nQTt+XsDqYVL4KcST2qnwPmkvmdpXN2NflS9Gj8VEcPkM2Xf/t/GQIWM= Received: by 10.54.27.50 with SMTP id a50mr466208wra; Wed, 27 Jul 2005 12:37:07 -0700 (PDT) Received: by 10.54.139.10 with HTTP; Wed, 27 Jul 2005 12:37:07 -0700 (PDT) Message-ID: <6280db5205072712375902fd6f@mail.gmail.com> Date: Wed, 27 Jul 2005 12:37:07 -0700 From: Alia Atlas To: Igor Bryskin Subject: Re: [Pce] Changes in the new revision of the architecture I-D In-Reply-To: <011601c592da$fe204260$7a1810ac@movaz.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <011601c592da$fe204260$7a1810ac@movaz.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 27 Jul 2005 16:40:42 -0400 Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alia Atlas List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org On 7/27/05, Igor Bryskin wrote: > Nobody says that a PCE must have policies about every PCC, but it might h= ave > about some and might want to apply them whether the request comes directl= y > or via some other PCE(s). >=20 > Your example when PCE1 and PCE2 belong to different providers and PCE2's > address is configured locally presents NO problem - PCE1 knows about this > fact and ALWAYS replaces the originator ID with its own before sending th= e > request to the PCE2. But how about the case when multiple PCEs work withi= n a > single provider, where all of them publish their presence and the PCE2 ma= y > get a relayed request from the PCE1 OR direct from the PCC? Why is it not > wiser to let PCE2 apply its own policy wrt the PCC? Just to state "I > disagree, in various cases policing based on the originator does not make > sense and cannot work" is not good enough. Does it help to change the assumption that PCE1 can only have one sourcing identity? I.e., let PCE1 apply policy to the originator PCC & derive an proxy originator to pass on to PCE2. Then PCE2 just needs to know about and have policy on the set of proxy originators that it agrees to support from PCE1. Basically, PCE1 decides how to set the originator based on where PCE2 is and what agreements may be in force with PCE2. In the first case, where PCE1 and PCE2 belong to the same service provider (or possibly are just in the same area, depending on distributed knowledge), PCE1 can decide not to proxy the originator and just specify an orginator =3D PCC. In the second case, where PCE1 and PCE2 belong to different service providers, PCE1 can decide to proxy the originator so that originator =3D proxy(PCC, policy(PCE1, PCE2)). Alia _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Jul 27 16:48:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxsp7-000596-I8; Wed, 27 Jul 2005 16:48:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxsp5-000579-Ky for pce@megatron.ietf.org; Wed, 27 Jul 2005 16:48:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01920 for ; Wed, 27 Jul 2005 16:48:12 -0400 (EDT) Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxtKP-0002nO-FE for pce@ietf.org; Wed, 27 Jul 2005 17:20:38 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Wed, 27 Jul 2005 22:48:00 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Pce] Changes in the new revision of the architecture I-D Date: Wed, 27 Jul 2005 22:47:57 +0200 Message-ID: Thread-Topic: [Pce] Changes in the new revision of the architecture I-D Thread-Index: AcWS2v+GlooCCCTsRjiqitZx6gxfsgADQmIQ From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "Igor Bryskin" , "JP Vasseur" , , "Ash, Gerald R \(Jerry\), ALABS" , "Lou Berger" X-OriginalArrivalTime: 27 Jul 2005 20:48:00.0334 (UTC) FILETIME=[79CCF6E0:01C592EC] X-Spam-Score: 0.0 (/) X-Scan-Signature: e52c6009a9b39871b75233310d7f3490 Content-Transfer-Encoding: quoted-printable Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi Igor, Your were saying in previous email: >IN ANY CASE enabling all PCEs involved in the request to be >aware of the "REAL" originator seems to me a more flexible approach. And I maintain that this is a wrong assertion. For me the inclusion of what you call the "REAL" originator ID is = irrelevant in VARIOUS CASES... See also inline, Regards, JL > -----Message d'origine----- > De : Igor Bryskin [mailto:ibryskin@movaz.com]=20 > Envoy=E9 : mercredi 27 juillet 2005 20:43 > =C0 : LE ROUX Jean-Louis RD-CORE-LAN; JP Vasseur;=20 > zzx-adrian@olddog.co.uk; Ash, Gerald R (Jerry), ALABS; Lou Berger > Cc : pce@ietf.org > Objet : Re: [Pce] Changes in the new revision of the architecture I-D >=20 > JL, >=20 > Ok, one last attempt. Please :-) >=20 > Nobody says that a PCE must have policies about every PCC,=20 > but it might have about some and might want to apply them=20 > whether the request comes directly or via some other PCE(s). Fair enough >=20 > Your example when PCE1 and PCE2 belong to different providers=20 > and PCE2's address is configured locally presents NO problem=20 > - PCE1 knows about this fact and ALWAYS replaces the=20 > originator ID with its own before sending the request to the=20 > PCE2. OK, so this is no longer the so called "REAL" orignator ID :-) But how about the case when multiple PCEs work within a=20 > single provider, where all of them publish their presence and=20 > the PCE2 may get a relayed request from the PCE1 OR direct=20 > from the PCC? Why is it not wiser to let PCE2 apply its own=20 > policy wrt the PCC? I recall that intially we were addresing multiple PCE path = computation... Here your exemple is related to PCE proxying, which is actually quite = different from multiple-PCE path computation. And I agree that in the = particular case of proxying, the inclusion of the originator ID could be = useful > Just to state "I disagree, in various=20 > cases policing based on the originator does not make sense=20 > and cannot work" is not good enough. :-))))) OK, you were saying "IN ANY CASE being aware of the REAL originator ID = is useful". I replied and I strongly maintain that this is wrong, there are VARIOUS = CASES (I never said in all cases) where this is not useful and cannot = work... and now you just list cases where this is useful. We will never = conclude like that... >=20 > Besides, I'd also like to hear what the architecture authors=20 > think about this. Sure, this would be helpful >=20 > Let's discuss more in Paris. I have some other issues with=20 > the architecture anyway. OK, Best Regards JL >=20 > Regards, > Igor >=20 >=20 > ----- Original Message ----- > From: "LE ROUX Jean-Louis RD-CORE-LAN"=20 > > To: "Igor Bryskin" ; "JP Vasseur"=20 > ; ; "Ash, Gerald R=20 > (Jerry), ALABS" ; "Lou Berger" > Cc: > Sent: Wednesday, July 27, 2005 1:36 PM > Subject: RE: [Pce] Changes in the new revision of the architecture I-D >=20 >=20 > Hi Igor >=20 > See inline >=20 > > -----Message d'origine----- > > De : Igor Bryskin [mailto:ibryskin@movaz.com] > > Envoy=E9 : mercredi 27 juillet 2005 19:05 > > =C0 : LE ROUX Jean-Louis RD-CORE-LAN; JP Vasseur; > > zzx-adrian@olddog.co.uk; Ash, Gerald R (Jerry), ALABS; Lou Berger > > Cc : pce@ietf.org > > Objet : Re: [Pce] Changes in the new revision of the=20 > architecture I-D > > > > Jl, > > > > 1. PCE2 publishes its presence, hence it must be prepared to > > receive requests from many clients and may have policies for > > some of them. >=20 > This is a strong assumption... > PCE2 does not necessarily publish its presence accross domains, > please see section 6.2 of [PCE-DISC]. >=20 > E.g. let's assume that PCE1 and PCE2 belong to distinct=20 > service providers > (let say SP1 and SP2)... > A possible ( and valuable :-) approach is that PCE1=20 > statically discover > PCE2. PCCs in SP1 are not aware of PCE2. There is a policy on=20 > PCE2 so that > all requests coming from SP1 are rejected except those from PCE1. > Hence all the trust rely on PCE1-PCE2 communication. In that case > advertising orignator id so as to apply a specific policy on=20 > PCE2 does not > really make sense as PCE2 is not aware of PCCs in SP1... >=20 > >In our example the PCE2 could get a request > > directly from the PCC, may have a policy for the PCC (not > > necessarily identical to the policy that the PCE1 has). > > > > 2. PCE1 in our example can always put its own ID as request > > originator ID in the request to PCE2 and modify the request > > to reflect its importance as far as it sees it (exactly your > > model). Alternatively. PCE1 may choose not to modify the > > request (changing neither request originator ID nor > > constraints) and let PCE2 treat the request according to its > > own policies. > > In the latter > > case: PCC->PCE1->PCE2->PCE1->PCC and > > PCC->PCE1->PCC->PCE2->PCC sequences will likely to produce > > the same resulting paths. >=20 > OK in this case PCE1 is simply acting as a proxy, but again=20 > this requires > that PCE2 be aware of PCCs in domain 1 which is IMHO a=20 > strong assumption > not always (and not often when domain =3D SP) valid... > Again think about confidentiality, scalability accross AS/SPs... >=20 > It seems that it is time to start working on application specific > requirements... >=20 > > > > In any case enabling all PCEs involved in the request to be > > aware of the "real" originator seems to me a more flexible approach. >=20 > I disagree, in various cases policing based on the orignator=20 > does not make > sense and cannot work >=20 >=20 > > > > On more general note it is obvious that articulating policies > > between PCE wrt specific request has never been discussed and > > we should IMO, starting with the architecture. >=20 > Fully agree >=20 > > > > See you in Paris, >=20 > OK let's discuss this point in Paris >=20 > Best Regards, >=20 > JL >=20 > > Igor > > > > ----- Original Message ----- > > From: "LE ROUX Jean-Louis RD-CORE-LAN" > > > > To: "Igor Bryskin" ; "JP Vasseur" > > ; ; "Ash, Gerald R > > (Jerry), ALABS" ; "Lou Berger" > > Cc: > > Sent: Wednesday, July 27, 2005 11:39 AM > > Subject: RE: [Pce] Changes in the new revision of the=20 > architecture I-D > > > > > > Hi Igor > > > > > -----Message d'origine----- > > > De : Igor Bryskin [mailto:ibryskin@movaz.com] > > > Envoy=E9 : mercredi 27 juillet 2005 17:13 > > > =C0 : LE ROUX Jean-Louis RD-CORE-LAN; JP Vasseur; > > > zzx-adrian@olddog.co.uk; Ash, Gerald R (Jerry), ALABS; Lou Berger > > > Cc : pce@ietf.org > > > Objet : Re: [Pce] Changes in the new revision of the > > architecture I-D > > > > > > JL, > > > > > > PCE1 could reflect "low importance" in the request sent to > > > PCE2, by mean of specific objective function selection (IB>> > > > which? how?), > > > > Solution to encode objective function are not yet specified, > > btw this should > > be addressed in future PCEP revisions. > > But have a look at the text related to objective function and > > parameterization of these functions in the communication > > protocol generic > > requirements. > > This may allow to request for what you call "cheap" or "expansive" > > heuristics... > > > > > > > > > > > > request priority (IB>> won't help, PCE2 will just move > > > request into lower priority task) > > > > Right > > > > > > > > or potentially using a dedicated parameter (yet not defined). > > > IB>> And the point is why not to use the original requestor > > ID as the > > > dedicated parameter you mentioned, so that PCE2 could apply > > > the policy of its own? > > > > Hence PCE2 would have to be aware of all PCCs in other domains... > > Think about scalability, confidentiality, and policy=20 > configurations... > > This is up to PCE1 to notify the importance of the request to PCE2. > > In the PCC->PCE1->PCE2 cascade, PCC IS NOT a client of PCE2, > > PCC is a client > > of PCE1, so if PCE1 considers that the request is not so > > "important" it > > should reflect that in the request sent to PCE2 (control of=20 > objective > > function, or maybe using a specific "importance" parameter). > > We should consider that PCEs may not be aware of PCCs in=20 > other domains > > > > > > > > Please not that in inter-AS/SP environment there may be cases > > > where PCE2 MUST not have knowledge of PCC... > > > IB>> No problem here, original requestor ID will be > > > "unknown", and PCE2 > > > might have a policy for such clients as well > > > > So, if I follow you, the same policies would be applied for=20 > all unknow > > clients...This does not sound really acceptable. > > > > Regards, > > > > JL > > > > > > > > Igor > > > > > > Regards, > > > > > > JL > > > > > > > -----Message d'origine----- > > > > De : Igor Bryskin [mailto:ibryskin@movaz.com] Envoy=E9 :=20 > mercredi 27 > > > > juillet 2005 16:45 =C0 : LE ROUX Jean-Louis RD-CORE-LAN;=20 > JP Vasseur; > > > > zzx-adrian@olddog.co.uk; Ash, Gerald R (Jerry), ALABS; Lou > > > Berger Cc : > > > > pce@ietf.org Objet : Re: [Pce] Changes in the new=20 > revision of the > > > > architecture I-D > > > > > > > > JL, > > > > > > > > See in-line. > > > > > > > > Igor > > > > > > > > ----- Original Message ----- > > > > From: "LE ROUX Jean-Louis RD-CORE-LAN" > > > > > > > > To: "Igor Bryskin" ; "JP Vasseur" > > > > ; ; "Ash, Gerald R > > > (Jerry), > > > > ALABS" ; "Lou Berger" > > > > Cc: > > > > Sent: Wednesday, July 27, 2005 10:14 AM > > > > Subject: RE: [Pce] Changes in the new revision of the > > > architecture I-D > > > > > > > > > > > > Hi Igor > > > > > > > > Please see inline > > > > > > > > > -----Message d'origine----- > > > > > De : pce-bounces@lists.ietf.org > > > > > [mailto:pce-bounces@lists.ietf.org] De la part de Igor Bryskin > > > > > Envoy=E9 : mercredi 27 juillet 2005 16:01 =C0 : JP Vasseur; > > > > > zzx-adrian@olddog.co.uk; Ash, Gerald R (Jerry), ALABS; > > > Lou Berger Cc > > > > > : pce@ietf.org Objet : Re: [Pce] Changes in the new > > > revision of the > > > > architecture I-D > > > > > > > > > > Hi, > > > > > > > > > > I think Lou has just brought up a very important discussion. > > > > > > > > > > A PCE can apply a policy for a particular path > > > computation request > > > > > only IFF it can identify original requestor. Consider the > > > situation > > > > > when a single request involves 2 PCEs: > > > > > PCC<=3D>PCE1<=3D>PCE2. > > > > > > > > > > PCE1 can identify the PCC and apply the polices for this > > > PCC or this > > > > > class of PCCs. However, PCE2 will not be capable to > > > identify PCC ( > > > > > we seem to agree already that PCC-PCE and PCE-PCE is the same > > > > > protocol, hence PCE2 will see PCE1 as > > > > > PCC) > > > > > > > > And where is the problem? Policy have a local PCC-PCE meaning > > > > PCE1 that sends a request to PCE2 is considered as a PCC, and > > > > PCE2 applies > > > > the policy to PCE1 > > > > PCE1 offers a service to PCC, PCE2 offers a service to=20 > PCE1, To my > > > > mind policies must have a local client-server scope. > > > > Path requests have a local PCC-PCE scope. > > > > PCE2 doesn't care whether PCE1 request has been triggered by PCC > > > > request to > > > > PCE1 or not. It serves a request from PCE1 and that's all... > > > > > > > > IB>> The problem is in my opinion quite obvious. A PCC sends > > > > a request to > > > > PCE1 with a lot of constraints and optimization objectives. > > > > PCE1 recognizes > > > > the PCC as "unimportant" and is about to perform some "cheap" > > > > heuristic. > > > > However, it does not have visibility to the=20 > destination, hence it > > > > relays the request to PCE2. PCE2 recognizes the PCE1 as a "very > > > > important" client and tries to satisfy the request as best > > > as it can, > > > > which may take 25% of its CPU capacity. Now, if you have > > > several more > > > > such "unimportant" PCCs, you get your PCE2 saturated=20 > very quickly. > > > > > > > > Igor > > > > > > > > >, and will apply a wrong policy. For instance, it may invoke a > > > > >computationally expensive algorithm, which it won't do > > if the PCC > > > > >requested computation directly from PCC2. > > > > > > > > And what is the problem?, this is up to PCE1 to apply > > > correct policies > > > > > > > > > > > > > > So, in the architecture document the reasons should be > > > described why > > > > > the identity of the original requestor should be > > > available for all > > > > > PCEs involved in particular path computation request. > > > > > > > > A path computation request should IMHO have a local scope > > > Multiple-PCE > > > > path computation should be considered as a cascade of > > > requests rather > > > > than the propagation of the same request, and local PCC-PCE > > > policies > > > > should be applied for each request... > > > > > > > > > > > > Regards, > > > > > > > > JL > > > > > > > > > Secondly, the same point should be > > > > > reflected in the path computation communication protocol > > > > requirements. > > > > > > > > > > Igor > > > > > > > > > > ----- Original Message ----- > > > > > From: "Lou Berger" > > > > > To: "JP Vasseur" ; "Adrian Farrel" > > > > > ; "Ash, Gerald R (Jerry), ALABS" > > > > > > > > Cc: > > > > > Sent: Tuesday, July 26, 2005 7:14 PM > > > > > Subject: Re: [Pce] Changes in the new revision of the > > > > architecture I-D > > > > > > > > > > > > > > > > At 09:24 AM 7/23/2005, JP Vasseur wrote: > > > > > > >We think that the ID is pretty stable in term of > > > > technical content. > > > > > > >As Adrian pointed out, there might be some editorial work > > > > > to be done > > > > > > >before WG last call. So the short answer is "as soon as > > > > possible". > > > > > > > > > > > > > >Thanks. > > > > > > > > > > > > > >JP. > > > > > > > > > > > > JP/Adrian/Jerry, > > > > > > As you say, the draft has come together very > > > nicely. The > > > > > > primary comment I have on the document is related to > > > how policy is > > > > > > presented in the draft: > > > > > > > > > > > > The draft does mention policy in multiple places, but > > > > these mentions > > > > > > are more "in-passing" than as major component. It seems > > > > to me that > > > > > > Policy and the ability to support path computation > > based on, or > > > > > > influenced by policies, must be a major part of the PCE > > > > > > architecture. I do agree with draft in that "policy > > > > between domains > > > > > > and between PCEs, and is achieved through configuration > > > > not through > > > > > > protocol communications." That said, the PCC-PCE=20 > and PCE-PCE > > > > > > communication protocols must support the=20 > communication of all > > > > > > information needed to support the installed policies, > > > as well as > > > > > > support any policy triggered transactions that may > > > result due to a > > > > > > policy (or change in policy). Also, in order to > > deliver viable > > > > > > policy to PCE, policy must not be an after thought. > > > (Consider how > > > > > > successful original RSVP was with bringing in policy > > > > after the core > > > > > > work was complete.) > > > > > > > > > > > > In short, I think policy should be more prominent in the > > > > > draft and in > > > > > > the PCE architecture. > > > > > > > > > > > > I suggest to: > > > > > > - add policy related motivations in section 4, > > > > > > - add a policy component to the PCE architecture(s) > > > > > presented in section > > > > > 5, > > > > > > - add a full fledged Policy sub-section to section 6 that > > > > > is separate > > > > > > from confidentiality. > > > > > > - and add a policy related evaluation metric to section 7. > > > > > > > > > > > > Please let me know what you think. > > > > > > > > > > > > I'll put together some specific text for fodder.... > > > > > > > > > > > > Lou > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Pce mailing list > > > > > > Pce@lists.ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/pce > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Pce mailing list > > > > > Pce@lists.ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/pce > > > > > > > > > > > > > > > > > > > > > > > >=20 >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Jul 27 17:10:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxtAF-0003Fn-9m; Wed, 27 Jul 2005 17:10:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxtAB-0003Dy-DR for pce@megatron.ietf.org; Wed, 27 Jul 2005 17:10:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03423 for ; Wed, 27 Jul 2005 17:10:00 -0400 (EDT) Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxtfV-0003TU-Sy for pce@ietf.org; Wed, 27 Jul 2005 17:42:26 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Wed, 27 Jul 2005 23:09:56 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Pce] Changes in the new revision of the architecture I-D Date: Wed, 27 Jul 2005 23:09:54 +0200 Message-ID: Thread-Topic: [Pce] Changes in the new revision of the architecture I-D Thread-Index: AcWS4s6QbMJ+g82+SciAZ1Qnne9MUwACfOHw From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "Alia Atlas" , "Igor Bryskin" X-OriginalArrivalTime: 27 Jul 2005 21:09:56.0042 (UTC) FILETIME=[8A0612A0:01C592EF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: quoted-printable Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi Alia What you propose sounds valuable in case of PCE proxying. But we definitely need to make the distinction between PCE proxying, and multiple-PCE path computation which are actually quite different = functions IMO. In case of multiple-PCE path computation, cascaded requests are = independant and a PCE should not care whether the cascade was initially = triggered by X, Y, or Z, and should only apply policies based on the = "direct" requestor and not based on any "proxied originator"... Best Regards, JL =20 > -----Message d'origine----- > De : Alia Atlas [mailto:akatlas@gmail.com]=20 > Envoy=E9 : mercredi 27 juillet 2005 21:37 > =C0 : Igor Bryskin > Cc : LE ROUX Jean-Louis RD-CORE-LAN; JP Vasseur;=20 > zzx-adrian@olddog.co.uk; Ash, Gerald R (Jerry), ALABS; Lou=20 > Berger; pce@ietf.org > Objet : Re: [Pce] Changes in the new revision of the architecture I-D >=20 > On 7/27/05, Igor Bryskin wrote: > > Nobody says that a PCE must have policies about every PCC, but it=20 > > might have about some and might want to apply them whether=20 > the request=20 > > comes directly or via some other PCE(s). > >=20 > > Your example when PCE1 and PCE2 belong to different providers and=20 > > PCE2's address is configured locally presents NO problem -=20 > PCE1 knows=20 > > about this fact and ALWAYS replaces the originator ID with its own=20 > > before sending the request to the PCE2. But how about the case when=20 > > multiple PCEs work within a single provider, where all of=20 > them publish=20 > > their presence and the PCE2 may get a relayed request from=20 > the PCE1 OR=20 > > direct from the PCC? Why is it not wiser to let PCE2 apply its own=20 > > policy wrt the PCC? Just to state "I disagree, in various cases=20 > > policing based on the originator does not make sense and=20 > cannot work" is not good enough. >=20 > Does it help to change the assumption that PCE1 can only have=20 > one sourcing identity? I.e., let PCE1 apply policy to the=20 > originator PCC > & derive an proxy originator to pass on to PCE2. Then PCE2 just > needs to know about and have policy on the set of proxy=20 > originators that it agrees to support from PCE1. >=20 > Basically, PCE1 decides how to set the originator based on=20 > where PCE2 is and what agreements may be in force with PCE2. >=20 > In the first case, where PCE1 and PCE2 belong to the same=20 > service provider (or possibly are just in the same area,=20 > depending on distributed knowledge), PCE1 can decide not to=20 > proxy the originator and just specify an orginator =3D PCC. >=20 > In the second case, where PCE1 and PCE2 belong to different=20 > service providers, PCE1 can decide to proxy the originator so=20 > that originator =3D proxy(PCC, policy(PCE1, PCE2)). >=20 > Alia >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Jul 28 18:09:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyGZ1-0006Eg-Cc; Thu, 28 Jul 2005 18:09:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyGYz-0006Eb-5s for pce@megatron.ietf.org; Thu, 28 Jul 2005 18:09:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02045 for ; Thu, 28 Jul 2005 18:09:10 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyH4W-0003Jx-Mr for pce@ietf.org; Thu, 28 Jul 2005 18:41:49 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 28 Jul 2005 15:09:03 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j6SM92JL028071; Thu, 28 Jul 2005 15:09:03 -0700 (PDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 28 Jul 2005 18:09:02 -0400 Received: from [192.168.1.101] ([10.86.242.54]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 28 Jul 2005 18:09:02 -0400 In-Reply-To: <6.2.3.4.2.20050727102145.04065fc0@mo-ex1> References: <154701c58d1f$ef014e70$d6849ed9@Puppy> <42E239D1.9010907@psg.com> <84945647-6729-4394-A308-17C1D3C79589@cisco.com> <6.2.3.4.2.20050726191150.03f4f040@mo-ex1> <009701c592b3$94409970$7a1810ac@movaz.com> <6.2.3.4.2.20050727102145.04065fc0@mo-ex1> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: [Pce] Changes in the new revision of the architecture I-D Date: Wed, 27 Jul 2005 15:46:17 -0400 To: Lou Berger , Igor Bryskin X-Mailer: Apple Mail (2.730) X-OriginalArrivalTime: 28 Jul 2005 22:09:02.0352 (UTC) FILETIME=[F633C900:01C593C0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Content-Transfer-Encoding: 7bit Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi Lou, On Jul 27, 2005, at 10:33 AM, Lou Berger wrote: > Igor, > My primary point was that we need to ensure that we fully > consider policy in the architecture (and the resulting > instantiation of the architecture). > > The point you raise is a reasonable one up due to such > consideration. Although rather than make a statement on the > requirement, I would ask the question, does policy being applied at > PCE2 need to know the identity of PCC? > (I'm not sure...) > This is exactly what I was also about to reply. Indeed, I think that we all welcome your useful suggestion to devote more text to Policy in the architecture ID since it deserves more focus. On the other hand, this does require more discussion on the mailing list to determine what the requirements are. Furthermore, requirements should not be discussed in the architecture ID and it is pretty likely that new requirements related to policy will arise when discussing the application-specific requirements IDs. Thanks. JP. > Much thanks, > Lou > > At 10:00 AM 7/27/2005, Bryskin, Igor wrote: > > >> Hi, >> >> I think Lou has just brought up a very important discussion. >> >> A PCE can apply a policy for a particular path computation request >> only IFF >> it can identify original requestor. Consider the situation when a >> single >> request involves 2 PCEs: PCC<=>PCE1<=>PCE2. >> >> PCE1 can identify the PCC and apply the polices for this PCC or >> this class >> of PCCs. However, PCE2 will not be capable to identify PCC ( we >> seem to >> agree already that PCC-PCE and PCE-PCE is the same protocol, hence >> PCE2 will >> see PCE1 as PCC), and will apply a wrong policy. For instance, it >> may invoke >> a computationally expensive algorithm, which it won't do if the PCC >> requested computation directly from PCC2. >> >> So, in the architecture document the reasons should be described >> why the >> identity of the original requestor should be available for all >> PCEs involved >> in particular path computation request. Secondly, the same point >> should be >> reflected in the path computation communication protocol >> requirements. >> >> Igor >> >> ----- Original Message ----- >> From: "Lou Berger" >> To: "JP Vasseur" ; "Adrian Farrel" >> ; "Ash, Gerald R (Jerry), ALABS" >> Cc: >> Sent: Tuesday, July 26, 2005 7:14 PM >> Subject: Re: [Pce] Changes in the new revision of the architecture >> I-D >> >> > At 09:24 AM 7/23/2005, JP Vasseur wrote: >> > >We think that the ID is pretty stable in term of technical >> content. >> > >As Adrian pointed out, there might be some editorial work to be >> done >> > >before WG last call. So the short answer is "as soon as possible". >> > > >> > >Thanks. >> > > >> > >JP. >> > >> > JP/Adrian/Jerry, >> > As you say, the draft has come together very nicely. The >> > primary comment I have on the document is related to how policy is >> > presented in the draft: >> > >> > The draft does mention policy in multiple places, but these >> mentions >> > are more "in-passing" than as major component. It seems to me that >> > Policy and the ability to support path computation based on, or >> > influenced by policies, must be a major part of the PCE >> > architecture. I do agree with draft in that "policy between >> domains >> > and between PCEs, and is achieved through configuration not through >> > protocol communications." That said, the PCC-PCE and PCE-PCE >> > communication protocols must support the communication of all >> > information needed to support the installed policies, as well as >> > support any policy triggered transactions that may result due to a >> > policy (or change in policy). Also, in order to deliver viable >> > policy to PCE, policy must not be an after thought. (Consider how >> > successful original RSVP was with bringing in policy after the core >> > work was complete.) >> > >> > In short, I think policy should be more prominent in the draft >> and in >> > the PCE architecture. >> > >> > I suggest to: >> > - add policy related motivations in section 4, >> > - add a policy component to the PCE architecture(s) presented in >> section >> 5, >> > - add a full fledged Policy sub-section to section 6 that is >> separate >> > from confidentiality. >> > - and add a policy related evaluation metric to section 7. >> > >> > Please let me know what you think. >> > >> > I'll put together some specific text for fodder.... >> > >> > Lou >> > >> > >> > _______________________________________________ >> > Pce mailing list >> > Pce@lists.ietf.org >> > https:// >> www1.ietf.org/mailman/listinfo/pce >> > > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Jul 29 08:23:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyTtM-0005K4-Ep; Fri, 29 Jul 2005 08:23:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyTtL-0005JU-Oc for pce@megatron.ietf.org; Fri, 29 Jul 2005 08:23:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02929 for ; Fri, 29 Jul 2005 08:23:05 -0400 (EDT) Received: from webmail.movaz.com ([65.205.166.188] helo=jera.movaz.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyUP0-0007GO-Sx for pce@ietf.org; Fri, 29 Jul 2005 08:55:51 -0400 Received: from movaz-hw.movaz.com (movaz-hw.atlanta.movaz.com [172.16.8.183]) by jera.movaz.com (Postfix) with ESMTP id 83EFD13C0; Fri, 29 Jul 2005 08:22:53 -0400 (EDT) Received: from lb.movaz.com (localhost [127.0.0.1]) by movaz-hw.movaz.com (Postfix) with ESMTP id C16D3B006; Fri, 29 Jul 2005 08:22:47 -0400 (EDT) Message-Id: <6.2.3.4.2.20050729081831.044896c8@mo-ex1> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Fri, 29 Jul 2005 08:22:47 -0400 To: "JP Vasseur" From: Lou Berger Subject: Re: [Pce] Changes in the new revision of the architecture I-D In-Reply-To: References: <154701c58d1f$ef014e70$d6849ed9@Puppy> <42E239D1.9010907@psg.com> <84945647-6729-4394-A308-17C1D3C79589@cisco.com> <6.2.3.4.2.20050726191150.03f4f040@mo-ex1> <009701c592b3$94409970$7a1810ac@movaz.com> <6.2.3.4.2.20050727102145.04065fc0@mo-ex1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org JP, See below. At 03:46 PM 7/27/2005, JP Vasseur wrote: >Hi Lou, > >On Jul 27, 2005, at 10:33 AM, Lou Berger wrote: > > > Igor, > > My primary point was that we need to ensure that we fully > > consider policy in the architecture (and the resulting > > instantiation of the architecture). > > > > The point you raise is a reasonable one up due to such > > consideration. Although rather than make a statement on the > > requirement, I would ask the question, does policy being applied at > > PCE2 need to know the identity of PCC? > > (I'm not sure...) > > > >This is exactly what I was also about to reply. Indeed, I think that >we all welcome your useful suggestion to devote more text to Policy >in the architecture ID since it deserves more focus. On the other >hand, this does require more discussion on the mailing list to >determine what the requirements are. 100% agree. Input from the community is need. >Furthermore, requirements should >not be discussed in the architecture ID and it is pretty likely that >new requirements related to policy will arise when discussing the >application-specific requirements IDs. I think limiting the policy discussion in the arch document to ensuring it is include and excluding the definition of specific policies is reasonable. I also agree that policy will come up in the definition of other WG documents. Furthermore, it probably makes to have a standalone document devoted to the types/models of policy supported by PCE and to provide a framework for this. I think we can discuss this further next week. Lou >Thanks. > >JP. > > > Much thanks, > > Lou > > > > At 10:00 AM 7/27/2005, Bryskin, Igor wrote: > > > > > >> Hi, > >> > >> I think Lou has just brought up a very important discussion. > >> > >> A PCE can apply a policy for a particular path computation request > >> only IFF > >> it can identify original requestor. Consider the situation when a > >> single > >> request involves 2 PCEs: PCC<=>PCE1<=>PCE2. > >> > >> PCE1 can identify the PCC and apply the polices for this PCC or > >> this class > >> of PCCs. However, PCE2 will not be capable to identify PCC ( we > >> seem to > >> agree already that PCC-PCE and PCE-PCE is the same protocol, hence > >> PCE2 will > >> see PCE1 as PCC), and will apply a wrong policy. For instance, it > >> may invoke > >> a computationally expensive algorithm, which it won't do if the PCC > >> requested computation directly from PCC2. > >> > >> So, in the architecture document the reasons should be described > >> why the > >> identity of the original requestor should be available for all > >> PCEs involved > >> in particular path computation request. Secondly, the same point > >> should be > >> reflected in the path computation communication protocol > >> requirements. > >> > >> Igor > >> > >> ----- Original Message ----- > >> From: "Lou Berger" > >> To: "JP Vasseur" ; "Adrian Farrel" > >> ; "Ash, Gerald R (Jerry), ALABS" > >> Cc: > >> Sent: Tuesday, July 26, 2005 7:14 PM > >> Subject: Re: [Pce] Changes in the new revision of the architecture > >> I-D > >> > >> > At 09:24 AM 7/23/2005, JP Vasseur wrote: > >> > >We think that the ID is pretty stable in term of technical > >> content. > >> > >As Adrian pointed out, there might be some editorial work to be > >> done > >> > >before WG last call. So the short answer is "as soon as possible". > >> > > > >> > >Thanks. > >> > > > >> > >JP. > >> > > >> > JP/Adrian/Jerry, > >> > As you say, the draft has come together very nicely. The > >> > primary comment I have on the document is related to how policy is > >> > presented in the draft: > >> > > >> > The draft does mention policy in multiple places, but these > >> mentions > >> > are more "in-passing" than as major component. It seems to me that > >> > Policy and the ability to support path computation based on, or > >> > influenced by policies, must be a major part of the PCE > >> > architecture. I do agree with draft in that "policy between > >> domains > >> > and between PCEs, and is achieved through configuration not through > >> > protocol communications." That said, the PCC-PCE and PCE-PCE > >> > communication protocols must support the communication of all > >> > information needed to support the installed policies, as well as > >> > support any policy triggered transactions that may result due to a > >> > policy (or change in policy). Also, in order to deliver viable > >> > policy to PCE, policy must not be an after thought. (Consider how > >> > successful original RSVP was with bringing in policy after the core > >> > work was complete.) > >> > > >> > In short, I think policy should be more prominent in the draft > >> and in > >> > the PCE architecture. > >> > > >> > I suggest to: > >> > - add policy related motivations in section 4, > >> > - add a policy component to the PCE architecture(s) presented in > >> section > >> 5, > >> > - add a full fledged Policy sub-section to section 6 that is > >> separate > >> > from confidentiality. > >> > - and add a policy related evaluation metric to section 7. > >> > > >> > Please let me know what you think. > >> > > >> > I'll put together some specific text for fodder.... > >> > > >> > Lou > >> > > >> > > >> > _______________________________________________ > >> > Pce mailing list > >> > Pce@lists.ietf.org > >> > > <https://www1.ietf.org/mailman/listinfo/pce>https:// > > >> www1.ietf.org/mailman/listinfo/pce > >> > > > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Jul 29 08:45:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyUEi-0004aW-8m; Fri, 29 Jul 2005 08:45:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyUEh-0004ZN-6B for pce@megatron.ietf.org; Fri, 29 Jul 2005 08:45:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05393 for ; Fri, 29 Jul 2005 08:45:09 -0400 (EDT) Received: from webmail.movaz.com ([65.205.166.188] helo=jera.movaz.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyUkM-0008In-JF for pce@ietf.org; Fri, 29 Jul 2005 09:17:54 -0400 Received: from ib (vpn15.atlanta.movaz.com [172.18.0.15]) by jera.movaz.com (Postfix) with SMTP id 7666513C0; Fri, 29 Jul 2005 08:45:00 -0400 (EDT) Message-ID: <006601c5943b$551b21f0$6501a8c0@movaz.com> From: "Igor Bryskin" To: "JP Vasseur" , "Lou Berger" References: <154701c58d1f$ef014e70$d6849ed9@Puppy> <42E239D1.9010907@psg.com> <84945647-6729-4394-A308-17C1D3C79589@cisco.com> <6.2.3.4.2.20050726191150.03f4f040@mo-ex1> <009701c592b3$94409970$7a1810ac@movaz.com> <6.2.3.4.2.20050727102145.04065fc0@mo-ex1> Subject: Re: [Pce] Changes in the new revision of the architecture I-D Date: Fri, 29 Jul 2005 08:44:58 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Content-Transfer-Encoding: 7bit Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi JP, I think that the architectureID is exactly the right context. It seems to me a hole in the arhcitecture, what other context do you have in mind? Igor ----- Original Message ----- From: "JP Vasseur" To: "Lou Berger" ; "Igor Bryskin" Cc: "Adrian Farrel" ; "Ash, Gerald R (Jerry), ALABS" ; Sent: Wednesday, July 27, 2005 3:46 PM Subject: Re: [Pce] Changes in the new revision of the architecture I-D > Hi Lou, > > On Jul 27, 2005, at 10:33 AM, Lou Berger wrote: > > > Igor, > > My primary point was that we need to ensure that we fully > > consider policy in the architecture (and the resulting > > instantiation of the architecture). > > > > The point you raise is a reasonable one up due to such > > consideration. Although rather than make a statement on the > > requirement, I would ask the question, does policy being applied at > > PCE2 need to know the identity of PCC? > > (I'm not sure...) > > > > This is exactly what I was also about to reply. Indeed, I think that > we all welcome your useful suggestion to devote more text to Policy > in the architecture ID since it deserves more focus. On the other > hand, this does require more discussion on the mailing list to > determine what the requirements are. Furthermore, requirements should > not be discussed in the architecture ID and it is pretty likely that > new requirements related to policy will arise when discussing the > application-specific requirements IDs. > > Thanks. > > JP. > > > Much thanks, > > Lou > > > > At 10:00 AM 7/27/2005, Bryskin, Igor wrote: > > > > > >> Hi, > >> > >> I think Lou has just brought up a very important discussion. > >> > >> A PCE can apply a policy for a particular path computation request > >> only IFF > >> it can identify original requestor. Consider the situation when a > >> single > >> request involves 2 PCEs: PCC<=>PCE1<=>PCE2. > >> > >> PCE1 can identify the PCC and apply the polices for this PCC or > >> this class > >> of PCCs. However, PCE2 will not be capable to identify PCC ( we > >> seem to > >> agree already that PCC-PCE and PCE-PCE is the same protocol, hence > >> PCE2 will > >> see PCE1 as PCC), and will apply a wrong policy. For instance, it > >> may invoke > >> a computationally expensive algorithm, which it won't do if the PCC > >> requested computation directly from PCC2. > >> > >> So, in the architecture document the reasons should be described > >> why the > >> identity of the original requestor should be available for all > >> PCEs involved > >> in particular path computation request. Secondly, the same point > >> should be > >> reflected in the path computation communication protocol > >> requirements. > >> > >> Igor > >> > >> ----- Original Message ----- > >> From: "Lou Berger" > >> To: "JP Vasseur" ; "Adrian Farrel" > >> ; "Ash, Gerald R (Jerry), ALABS" > >> Cc: > >> Sent: Tuesday, July 26, 2005 7:14 PM > >> Subject: Re: [Pce] Changes in the new revision of the architecture > >> I-D > >> > >> > At 09:24 AM 7/23/2005, JP Vasseur wrote: > >> > >We think that the ID is pretty stable in term of technical > >> content. > >> > >As Adrian pointed out, there might be some editorial work to be > >> done > >> > >before WG last call. So the short answer is "as soon as possible". > >> > > > >> > >Thanks. > >> > > > >> > >JP. > >> > > >> > JP/Adrian/Jerry, > >> > As you say, the draft has come together very nicely. The > >> > primary comment I have on the document is related to how policy is > >> > presented in the draft: > >> > > >> > The draft does mention policy in multiple places, but these > >> mentions > >> > are more "in-passing" than as major component. It seems to me that > >> > Policy and the ability to support path computation based on, or > >> > influenced by policies, must be a major part of the PCE > >> > architecture. I do agree with draft in that "policy between > >> domains > >> > and between PCEs, and is achieved through configuration not through > >> > protocol communications." That said, the PCC-PCE and PCE-PCE > >> > communication protocols must support the communication of all > >> > information needed to support the installed policies, as well as > >> > support any policy triggered transactions that may result due to a > >> > policy (or change in policy). Also, in order to deliver viable > >> > policy to PCE, policy must not be an after thought. (Consider how > >> > successful original RSVP was with bringing in policy after the core > >> > work was complete.) > >> > > >> > In short, I think policy should be more prominent in the draft > >> and in > >> > the PCE architecture. > >> > > >> > I suggest to: > >> > - add policy related motivations in section 4, > >> > - add a policy component to the PCE architecture(s) presented in > >> section > >> 5, > >> > - add a full fledged Policy sub-section to section 6 that is > >> separate > >> > from confidentiality. > >> > - and add a policy related evaluation metric to section 7. > >> > > >> > Please let me know what you think. > >> > > >> > I'll put together some specific text for fodder.... > >> > > >> > Lou > >> > > >> > > >> > _______________________________________________ > >> > Pce mailing list > >> > Pce@lists.ietf.org > >> > https:// > >> www1.ietf.org/mailman/listinfo/pce > >> > > > > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Jul 29 09:36:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyV23-0001ka-7X; Fri, 29 Jul 2005 09:36:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyV21-0001kN-Kt for pce@megatron.ietf.org; Fri, 29 Jul 2005 09:36:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08182 for ; Fri, 29 Jul 2005 09:36:07 -0400 (EDT) Received: from webmail.movaz.com ([65.205.166.188] helo=jera.movaz.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyVXg-0001Ki-5r for pce@ietf.org; Fri, 29 Jul 2005 10:08:53 -0400 Received: from ib (vpn18.atlanta.movaz.com [172.18.0.18]) by jera.movaz.com (Postfix) with SMTP id E3095C4CC; Fri, 29 Jul 2005 09:35:56 -0400 (EDT) Message-ID: <007101c59442$7381b580$6501a8c0@movaz.com> From: "Igor Bryskin" To: "JP Vasseur" References: <154701c58d1f$ef014e70$d6849ed9@Puppy> <42E239D1.9010907@psg.com> <84945647-6729-4394-A308-17C1D3C79589@cisco.com> <6.2.3.4.2.20050726191150.03f4f040@mo-ex1> <009701c592b3$94409970$7a1810ac@movaz.com> <6.2.3.4.2.20050727102145.04065fc0@mo-ex1> Subject: Re: [Pce] Changes in the new revision of the architecture I-D Date: Fri, 29 Jul 2005 09:35:18 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi, This is from the architectureID: 2) a. In "single PCE path computation," a single PCE is used to compute a given path in a domain. There may be multiple PCEs in a domain, but only one PCE per domain is involved in any single path computation. b. In "multiple PCE path computation," multiple PCEs are used to compute a given path in a domain. 3) a. "Centralized computation model" refers to a model whereby all paths in a domain are computed by a single, centralized PCE. b. Conversely, "Distributed computation model" refers to the computation of paths in a domain being shared among multiple PCEs. I believe (as I once have indicated to the authors of the draft) that the definition of Centralized/distributed path computation is too simplistic. A PCC co-located with an LSP ingress LSR views centralized/distributed path computation quite differently. When the PCC requests one or more paths from a PCE, it is concerned about how many other path computation requests will have to be *issued* from the same or different PCCs in order to determine all segments of the LSP path.Ideally, the ingress PCC would like to get 100% explicit paths in the very first path computation response, because these would be conceptually the best paths (best degree of satisfaction of specified constraints, optimizations and diversities, which is virtually impossible to achieve in subsequent requests). That's how PCC views the Centralized path computation (it does not care whether the paths are computed by a single PCE or a federation of PCEs). On the other hand, additional path computations could be satisfied by the *same* (possibly single in the domain) PCE, and it would still be adistributed path computation as far as the PCC is concerned.On more general note, what IMO ID lacks is the angle from the PCC's point of view. After all this is the guy who ultimately pays for the service.Igor _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Jul 29 11:33:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyWrY-0004YG-Gy; Fri, 29 Jul 2005 11:33:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyWrX-0004YB-CB for pce@megatron.ietf.org; Fri, 29 Jul 2005 11:33:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17342 for ; Fri, 29 Jul 2005 11:33:24 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyXND-00057E-S9 for pce@ietf.org; Fri, 29 Jul 2005 12:06:12 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 29 Jul 2005 11:33:18 -0400 X-IronPort-AV: i="3.95,153,1120449600"; d="scan'208"; a="64482424:sNHT34343644" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j6TFX7WG020350; Fri, 29 Jul 2005 11:33:17 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 29 Jul 2005 11:33:16 -0400 Received: from [192.168.1.102] ([10.86.241.19]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 29 Jul 2005 11:33:16 -0400 In-Reply-To: <6.2.3.4.2.20050729081831.044896c8@mo-ex1> References: <154701c58d1f$ef014e70$d6849ed9@Puppy> <42E239D1.9010907@psg.com> <84945647-6729-4394-A308-17C1D3C79589@cisco.com> <6.2.3.4.2.20050726191150.03f4f040@mo-ex1> <009701c592b3$94409970$7a1810ac@movaz.com> <6.2.3.4.2.20050727102145.04065fc0@mo-ex1> <6.2.3.4.2.20050729081831.044896c8@mo-ex1> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <476E3EFF-8AE9-4AFA-A096-DB9316317D1D@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: [Pce] Changes in the new revision of the architecture I-D Date: Fri, 29 Jul 2005 17:33:36 +0200 To: Lou Berger X-Mailer: Apple Mail (2.730) X-OriginalArrivalTime: 29 Jul 2005 15:33:16.0372 (UTC) FILETIME=[D6E88940:01C59452] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c Content-Transfer-Encoding: 7bit Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi Lou, On Jul 29, 2005, at 2:22 PM, Lou Berger wrote: > JP, > See below. > At 03:46 PM 7/27/2005, JP Vasseur wrote: > > >> Hi Lou, >> >> On Jul 27, 2005, at 10:33 AM, Lou Berger wrote: >> >> > Igor, >> > My primary point was that we need to ensure that we fully >> > consider policy in the architecture (and the resulting >> > instantiation of the architecture). >> > >> > The point you raise is a reasonable one up due to such >> > consideration. Although rather than make a statement on the >> > requirement, I would ask the question, does policy being applied at >> > PCE2 need to know the identity of PCC? >> > (I'm not sure...) >> > >> >> This is exactly what I was also about to reply. Indeed, I think that >> we all welcome your useful suggestion to devote more text to Policy >> in the architecture ID since it deserves more focus. On the other >> hand, this does require more discussion on the mailing list to >> determine what the requirements are. >> > > 100% agree. Input from the community is need. > > >> Furthermore, requirements should >> not be discussed in the architecture ID and it is pretty likely that >> new requirements related to policy will arise when discussing the >> application-specific requirements IDs. >> > > I think limiting the policy discussion in the arch document to > ensuring it is include and excluding the definition of specific > policies is reasonable. I also agree that policy will come up in > the definition of other WG documents. Furthermore, it probably > makes to have a standalone document devoted to the types/models of > policy supported by PCE and to provide a framework for this. I > think we can discuss this further next week. > Sure, we're in sync. cheers JP. > Lou > > >> Thanks. >> >> JP. >> >> > Much thanks, >> > Lou >> > >> > At 10:00 AM 7/27/2005, Bryskin, Igor wrote: >> > >> > >> >> Hi, >> >> >> >> I think Lou has just brought up a very important discussion. >> >> >> >> A PCE can apply a policy for a particular path computation request >> >> only IFF >> >> it can identify original requestor. Consider the situation when a >> >> single >> >> request involves 2 PCEs: PCC<=>PCE1<=>PCE2. >> >> >> >> PCE1 can identify the PCC and apply the polices for this PCC or >> >> this class >> >> of PCCs. However, PCE2 will not be capable to identify PCC ( we >> >> seem to >> >> agree already that PCC-PCE and PCE-PCE is the same protocol, hence >> >> PCE2 will >> >> see PCE1 as PCC), and will apply a wrong policy. For instance, it >> >> may invoke >> >> a computationally expensive algorithm, which it won't do if the >> PCC >> >> requested computation directly from PCC2. >> >> >> >> So, in the architecture document the reasons should be described >> >> why the >> >> identity of the original requestor should be available for all >> >> PCEs involved >> >> in particular path computation request. Secondly, the same point >> >> should be >> >> reflected in the path computation communication protocol >> >> requirements. >> >> >> >> Igor >> >> >> >> ----- Original Message ----- >> >> From: "Lou Berger" >> >> To: "JP Vasseur" ; "Adrian Farrel" >> >> ; "Ash, Gerald R (Jerry), ALABS" >> >> >> Cc: >> >> Sent: Tuesday, July 26, 2005 7:14 PM >> >> Subject: Re: [Pce] Changes in the new revision of the architecture >> >> I-D >> >> >> >> > At 09:24 AM 7/23/2005, JP Vasseur wrote: >> >> > >We think that the ID is pretty stable in term of technical >> >> content. >> >> > >As Adrian pointed out, there might be some editorial work to be >> >> done >> >> > >before WG last call. So the short answer is "as soon as >> possible". >> >> > > >> >> > >Thanks. >> >> > > >> >> > >JP. >> >> > >> >> > JP/Adrian/Jerry, >> >> > As you say, the draft has come together very >> nicely. The >> >> > primary comment I have on the document is related to how >> policy is >> >> > presented in the draft: >> >> > >> >> > The draft does mention policy in multiple places, but these >> >> mentions >> >> > are more "in-passing" than as major component. It seems to >> me that >> >> > Policy and the ability to support path computation based on, or >> >> > influenced by policies, must be a major part of the PCE >> >> > architecture. I do agree with draft in that "policy between >> >> domains >> >> > and between PCEs, and is achieved through configuration not >> through >> >> > protocol communications." That said, the PCC-PCE and PCE-PCE >> >> > communication protocols must support the communication of all >> >> > information needed to support the installed policies, as well as >> >> > support any policy triggered transactions that may result due >> to a >> >> > policy (or change in policy). Also, in order to deliver viable >> >> > policy to PCE, policy must not be an after thought. >> (Consider how >> >> > successful original RSVP was with bringing in policy after >> the core >> >> > work was complete.) >> >> > >> >> > In short, I think policy should be more prominent in the draft >> >> and in >> >> > the PCE architecture. >> >> > >> >> > I suggest to: >> >> > - add policy related motivations in section 4, >> >> > - add a policy component to the PCE architecture(s) presented in >> >> section >> >> 5, >> >> > - add a full fledged Policy sub-section to section 6 that is >> >> separate >> >> > from confidentiality. >> >> > - and add a policy related evaluation metric to section 7. >> >> > >> >> > Please let me know what you think. >> >> > >> >> > I'll put together some specific text for fodder.... >> >> > >> >> > Lou >> >> > >> >> > >> >> > _______________________________________________ >> >> > Pce mailing list >> >> > Pce@lists.ietf.org >> >> > <https:// >> www1.ietf.org/mailman/listinfo/pce>https:// >> >> www1.ietf.org/mailman/listinfo/pce >> >> > >> > > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce