From pce-bounces@lists.ietf.org Tue Nov 01 10:24:41 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWy09-0002Mu-BH; Tue, 01 Nov 2005 10:24:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWy07-0002M3-3e for pce@megatron.ietf.org; Tue, 01 Nov 2005 10:24:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26352 for ; Tue, 1 Nov 2005 10:24:18 -0500 (EST) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWyEV-0005GO-UC for pce@ietf.org; Tue, 01 Nov 2005 10:39:32 -0500 Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id jA1FORe23305 for ; Tue, 1 Nov 2005 10:24:27 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: [Pce] Comments on draft-vasseur-pce-pcep-02.txt Date: Tue, 1 Nov 2005 10:24:25 -0500 Message-ID: <9671A92C3C8B5744BC97F855F7CB646506B9FC78@zcarhxm1.corp.nortel.com> Thread-Topic: [Pce] Comments on draft-vasseur-pce-pcep-02.txt Thread-Index: AcXe+Fe9e+1aNtxsQSOTHBh0TSjWYw== From: "Darek Skalecki" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba 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="===============1534067651==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1534067651== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5DEF8.58599552" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5DEF8.58599552 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Good day, I have gone over the draft and have the following comments for consideration by the authors and others on the mailing list: * In section 6.7 - In the BNF for PCErr, why is there an object>?. Looks like a typo :) * In section 6.4 - In the BNF for PCReq, would it be possible to reverse the order of [] and such that is first and then followed by [], and such order being recommended. The reasoning is related to potential efficiency in decoding. I realize it may be implementation specific but if most implementations find it easier to decode the request-list before the SVEC-list then this is the order that should be adopted. Comments from other implementers???. * In section 7.2 - There is a keepalive frequency in the OPEN object but do we need some sort of dead-interval or number-of-keepalives-that-can-be-lost-before-we-declare-session-DOWN. For example, keepalive frequency is 30 seconds and dead-interval is 3 or 90 seconds meaning that if PCC/PCE doesn't receive a keepalive from its peer in 90 seconds then the session to its peer will be deemed DOWN. * In section 7.6 - Bandwidth in bytes per second may not be sufficient for all applications of PCE. For example, in SONET networks, to compute a route through a BLSR ring where time-slot interchange is not possible, one needs to compute a route consisting of the same time-slot from an ingress to egress of that ring. Same may hold for photonic networks where a route consisting of the same lambda may need to be computed. * In section 7.8 and 7.9 - I am getting confused as to whether the route to reoptimize is specified in ERO or RRO. 7.8 seems to suggest the route of current LSP to reoptimize is carried in ERO in PCReq, while 7.9 suggests RRO in PCReq is used for the same purpose. * In section 7.10 - PCReq is used instead of PCRep in the first paragraph where "...(in this case, the PCReq message also comprises a NO-PATH object ...". * In section 7.10 - Why is Setup Prio and Holding Prio 8-bits in length. Shouldn't 3 bits be sufficient. Also, at first I was scratching my head why Holding Prio is specified for path computation where it really doesn't play any role unlike Setup Prio, but I now presume it is used by PCEs that are stateful, i.e. the ones that keep track of the routes and need their Holding Prio in order to compute routes that bump/pre-empt. Is this correct?. * In section 7.12 - There are some inefficiencies in the SVEC object. When SVEC object is used in PCReq (section 6.4) then it doesn't need not contain a set of RP objects and could simply contain a set of Request-ID-numbers from the RP objects. If the SVEC object is used in PCRep (section 6.5) then I see the need for the entire RP object albeit also Request-ID-number and Pri fields of RP are really only used. I wonder if we can come up with a better definition, unless carrying the redundant info in RP is OK.=20 Also in section 7.12, why is Pri value of 0 used to denote "no priority" or "lowest priority". It seems to be contrary to definitions of Setup and Holding Priorities where 0 implies the highest priority and 7 the lowest priority. * In section 6.6 - Why is the entire RP object used instead of just the Request-ID-number of RP. It seems the combination of Request-ID-number and PCC's source IP address are the unique keys used to identify a particular path computation request. The other 32 bits of info in RP doesn't add any value and I doubt it would be used by the recipient of PCNtf for anything. Am I missing something???. * In section 6.7 - Same comment as just above. * In section 7.12 - About the diversity specifications. We have come up with requests from our customers to provide maximum diversity in addition to absolute diversity, i.e. if you cannot find absolutely diverse set of routes then find a set of routes with as fewer nodes/links/SRLGs in common as possible. Has such concept of maximum diversity been discussed among the authors and are there any parties on the PCE mailing list interested in it also.=20 Regards, Darek Darek Skalecki Optical Networks Nortel dareks@nortel.com ------_=_NextPart_001_01C5DEF8.58599552 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [Pce] Comments on draft-vasseur-pce-pcep-02.txt

Good day,

I have gone over the draft and have the = following comments for consideration by the authors and others on the = mailing list:

  • In section 6.7 - In the BNF for PCErr, = why is there an <Open> object>?. Looks like a typo = :)
  • In section 6.4 - In the BNF for PCReq, = would it be possible to reverse the order of [<SVEC-list>] and = <request-list> such that <request-list> is first and then = followed by [<SVEC-list>], and such order being recommended. The = reasoning is related to potential efficiency in decoding. I realize it = may be implementation specific but if most implementations find it = easier to decode the request-list before the SVEC-list then this is the = order that should be adopted. Comments from other = implementers???.
  • In section 7.2 - There is a keepalive = frequency in the OPEN object but do we need some sort of dead-interval = or number-of-keepalives-that-can-be-lost-before-we-declare-session-DOWN. = For example, keepalive frequency is 30 seconds and dead-interval is 3 or = 90 seconds meaning that if PCC/PCE doesn't receive a keepalive from its = peer in 90 seconds then the session to its peer will be deemed = DOWN.
  • In section 7.6 - Bandwidth in bytes = per second may not be sufficient for all applications of PCE. For = example, in SONET networks, to compute a route through a BLSR ring where = time-slot interchange is not possible, one needs to compute a route = consisting of the same time-slot from an ingress to egress of that ring. = Same may hold for photonic networks where a route consisting of the same = lambda may need to be computed.
  • In section 7.8 and 7.9 - I am getting = confused as to whether the route to reoptimize is specified in ERO or = RRO. 7.8 seems to suggest the route of current LSP to reoptimize is = carried in ERO in PCReq, while 7.9 suggests RRO in PCReq is used for the = same purpose.
  • In section 7.10 - PCReq is used = instead of PCRep in the first paragraph where "…(in this = case, the PCReq message also comprises a NO-PATH = object …".
  • In section 7.10 - Why is Setup Prio = and Holding Prio 8-bits in length. Shouldn't 3 bits be sufficient. Also, = at first I was scratching my head why Holding Prio is specified for path = computation where it really doesn't play any role unlike Setup Prio, but = I now presume it is used by PCEs that are stateful, i.e. the ones that = keep track of the routes and need their Holding Prio in order to compute = routes that bump/pre-empt. Is this correct?.
  • In section 7.12 - There are some = inefficiencies in the SVEC object. When SVEC object is used in PCReq = (section 6.4) then it doesn't need not contain a set of RP objects and = could simply contain a set of Request-ID-numbers from the RP objects. If = the SVEC object is used in PCRep (section 6.5) then I see the need for = the entire RP object albeit also Request-ID-number and Pri fields of RP = are really only used. I wonder if we can come up with a better = definition, unless carrying the redundant info in RP is OK.
    Also in section 7.12, why is Pri value of 0 used to denote "no = priority" or "lowest priority". It seems to be contrary = to definitions of Setup and Holding Priorities where 0 implies the = highest priority and 7 the lowest priority.
  • In section 6.6 - Why is the entire RP = object used instead of just the Request-ID-number of RP. It seems the = combination of Request-ID-number and PCC's source IP address are the = unique keys used to identify a particular path computation request. The = other 32 bits of info in RP doesn't add any value and I doubt it would = be used by the recipient of PCNtf for anything. Am I missing = something???.
  • In section 6.7 - Same comment as just = above.
  • In section 7.12 - About the diversity = specifications. We have come up with requests from our customers to = provide maximum diversity in addition to absolute diversity, i.e. if you = cannot find absolutely diverse set of routes then find a set of routes = with as fewer nodes/links/SRLGs in common as possible. Has such concept = of maximum diversity been discussed among the authors and are there any = parties on the PCE mailing list interested in it also.

Regards,

Darek

Darek = Skalecki
Optical = Networks
Nortel
dareks@nortel.com


------_=_NextPart_001_01C5DEF8.58599552-- --===============1534067651== 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 --===============1534067651==-- From pce-bounces@lists.ietf.org Tue Nov 01 11:01:14 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWyZW-0000BF-2Q; Tue, 01 Nov 2005 11:01:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWyZT-00009t-Un for pce@megatron.ietf.org; Tue, 01 Nov 2005 11:01:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29021 for ; Tue, 1 Nov 2005 11:00:51 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWyns-0000Ve-KK for pce@ietf.org; Tue, 01 Nov 2005 11:16:05 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 01 Nov 2005 08:01:00 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,274,1125903600"; d="scan'208,217"; a="14310403:sNHT38080158" 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 jA1G0cF0019229; Tue, 1 Nov 2005 11:00:58 -0500 (EST) 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); Tue, 1 Nov 2005 11:00:47 -0500 Received: from [192.168.1.100] ([10.86.240.239]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 1 Nov 2005 11:00:46 -0500 In-Reply-To: <9671A92C3C8B5744BC97F855F7CB646506B9FC78@zcarhxm1.corp.nortel.com> References: <9671A92C3C8B5744BC97F855F7CB646506B9FC78@zcarhxm1.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v734) Message-Id: <59CDA355-8A33-46B4-A9F1-9F93D0DCF22C@cisco.com> From: JP Vasseur Subject: Re: [Pce] Comments on draft-vasseur-pce-pcep-02.txt Date: Tue, 1 Nov 2005 11:00:06 -0500 To: Darek Skalecki X-Mailer: Apple Mail (2.734) X-OriginalArrivalTime: 01 Nov 2005 16:00:46.0866 (UTC) FILETIME=[6BEC2F20:01C5DEFD] X-Spam-Score: 0.1 (/) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee 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="===============0757370861==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org --===============0757370861== Content-Type: multipart/alternative; boundary=Apple-Mail-41-82267075 --Apple-Mail-41-82267075 Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Content-Transfer-Encoding: quoted-printable Hi Darek, Just wanted to thank you for these useful comments ... we'll =20 certainly address them right after Vancouver Thanks. JP. On Nov 1, 2005, at 10:24 AM, Darek Skalecki wrote: > Good day, > > I have gone over the draft and have the following comments for =20 > consideration by the authors and others on the mailing list: > > In section 6.7 - In the BNF for PCErr, why is there an =20 > object>?. Looks like a typo :) > In section 6.4 - In the BNF for PCReq, would it be possible to =20 > reverse the order of [] and such that =20 > is first and then followed by [], and =20 > such order being recommended. The reasoning is related to potential =20= > efficiency in decoding. I realize it may be implementation specific =20= > but if most implementations find it easier to decode the request-=20 > list before the SVEC-list then this is the order that should be =20 > adopted. Comments from other implementers???. > In section 7.2 - There is a keepalive frequency in the OPEN object =20 > but do we need some sort of dead-interval or number-of-keepalives-=20 > that-can-be-lost-before-we-declare-session-DOWN. For example, =20 > keepalive frequency is 30 seconds and dead-interval is 3 or 90 =20 > seconds meaning that if PCC/PCE doesn't receive a keepalive from =20 > its peer in 90 seconds then the session to its peer will be deemed =20 > DOWN. > In section 7.6 - Bandwidth in bytes per second may not be =20 > sufficient for all applications of PCE. For example, in SONET =20 > networks, to compute a route through a BLSR ring where time-slot =20 > interchange is not possible, one needs to compute a route =20 > consisting of the same time-slot from an ingress to egress of that =20 > ring. Same may hold for photonic networks where a route consisting =20 > of the same lambda may need to be computed. > In section 7.8 and 7.9 - I am getting confused as to whether the =20 > route to reoptimize is specified in ERO or RRO. 7.8 seems to =20 > suggest the route of current LSP to reoptimize is carried in ERO in =20= > PCReq, while 7.9 suggests RRO in PCReq is used for the same purpose. > In section 7.10 - PCReq is used instead of PCRep in the first =20 > paragraph where "=85(in this case, the PCReq message also comprises a =20= > NO-PATH object =85". > In section 7.10 - Why is Setup Prio and Holding Prio 8-bits in =20 > length. Shouldn't 3 bits be sufficient. Also, at first I was =20 > scratching my head why Holding Prio is specified for path =20 > computation where it really doesn't play any role unlike Setup =20 > Prio, but I now presume it is used by PCEs that are stateful, i.e. =20 > the ones that keep track of the routes and need their Holding Prio =20 > in order to compute routes that bump/pre-empt. Is this correct?. > In section 7.12 - There are some inefficiencies in the SVEC object. =20= > When SVEC object is used in PCReq (section 6.4) then it doesn't =20 > need not contain a set of RP objects and could simply contain a set =20= > of Request-ID-numbers from the RP objects. If the SVEC object is =20 > used in PCRep (section 6.5) then I see the need for the entire RP =20 > object albeit also Request-ID-number and Pri fields of RP are =20 > really only used. I wonder if we can come up with a better =20 > definition, unless carrying the redundant info in RP is OK. > Also in section 7.12, why is Pri value of 0 used to denote "no =20 > priority" or "lowest priority". It seems to be contrary to =20 > definitions of Setup and Holding Priorities where 0 implies the =20 > highest priority and 7 the lowest priority. > In section 6.6 - Why is the entire RP object used instead of just =20 > the Request-ID-number of RP. It seems the combination of Request-ID-=20= > number and PCC's source IP address are the unique keys used to =20 > identify a particular path computation request. The other 32 bits =20 > of info in RP doesn't add any value and I doubt it would be used by =20= > the recipient of PCNtf for anything. Am I missing something???. > In section 6.7 - Same comment as just above. > In section 7.12 - About the diversity specifications. We have come =20 > up with requests from our customers to provide maximum diversity in =20= > addition to absolute diversity, i.e. if you cannot find absolutely =20 > diverse set of routes then find a set of routes with as fewer nodes/=20= > links/SRLGs in common as possible. Has such concept of maximum =20 > diversity been discussed among the authors and are there any =20 > parties on the PCE mailing list interested in it also. > > Regards, > > Darek > > Darek Skalecki > Optical Networks > Nortel > dareks@nortel.com > > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > --Apple-Mail-41-82267075 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Hi Darek,

Just wanted to thank you = for these useful comments ... we'll certainly address them right after = Vancouver=A0

Thanks.

JP.

O= n Nov 1, 2005, at 10:24 AM, Darek Skalecki wrote:

Good day,

I have gone over the draft and have the following = comments for consideration by the authors and others on the mailing = list:

  • In section 6.7 = - In the BNF for PCErr, why is there an <Open> object>?. Looks = like a typo :)
  • In = section 6.4 - In the BNF for PCReq, would it be possible to reverse the = order of [<SVEC-list>] and <request-list> such that = <request-list> is first and then followed by [<SVEC-list>], = and such order being recommended. The reasoning is related to potential = efficiency in decoding. I realize it may be implementation specific but = if most implementations find it easier to decode the request-list before = the SVEC-list then this is the order that should be adopted. Comments = from other implementers???.
  • In section 7.2 - There is a keepalive frequency in the = OPEN object but do we need some sort of dead-interval or = number-of-keepalives-that-can-be-lost-before-we-declare-session-DOWN. = For example, keepalive frequency is 30 seconds and dead-interval is 3 or = 90 seconds meaning that if PCC/PCE doesn't receive a keepalive from its = peer in 90 seconds then the session to its peer will be deemed = DOWN.
  • In section 7.6 - = Bandwidth in bytes per second may not be sufficient for all applications = of PCE. For example, in SONET networks, to compute a route through a = BLSR ring where time-slot interchange is not possible, one needs to = compute a route consisting of the same time-slot from an ingress to = egress of that ring. Same may hold for photonic networks where a route = consisting of the same lambda may need to be computed.
    • =
  • In section 7.8 and 7.9 - I am = getting confused as to whether the route to reoptimize is specified in = ERO or RRO. 7.8 seems to suggest the route of current LSP to reoptimize = is carried in ERO in PCReq, while 7.9 suggests RRO in PCReq is used for = the same purpose.
  • In = section 7.10 - PCReq is used instead of PCRep in the first paragraph = where "=85(in this case, the PCReq message also = comprises a NO-PATH object =85".
  • In section 7.10 - Why is Setup Prio and Holding Prio = 8-bits in length. Shouldn't 3 bits be sufficient. Also, at first I was = scratching my head why Holding Prio is specified for path computation = where it really doesn't play any role unlike Setup Prio, but I now = presume it is used by PCEs that are stateful, i.e. the ones that keep = track of the routes and need their Holding Prio in order to compute = routes that bump/pre-empt. Is this correct?.
  • In section 7.12 - There are some = inefficiencies in the SVEC object. When SVEC object is used in PCReq = (section 6.4) then it doesn't need not contain a set of RP objects and = could simply contain a set of Request-ID-numbers from the RP objects. If = the SVEC object is used in PCRep (section 6.5) then I see the need for = the entire RP object albeit also Request-ID-number and Pri fields of RP = are really only used. I wonder if we can come up with a better = definition, unless carrying the redundant info in RP is OK.
    Also in = section 7.12, why is Pri value of 0 used to denote "no priority" or = "lowest priority". It seems to be contrary to definitions of Setup and = Holding Priorities where 0 implies the highest priority and 7 the lowest = priority.
  • In section 6.6 = - Why is the entire RP object used instead of just the Request-ID-number = of RP. It seems the combination of Request-ID-number and PCC's source IP = address are the unique keys used to identify a particular path = computation request. The other 32 bits of info in RP doesn't add any = value and I doubt it would be used by the recipient of PCNtf for = anything. Am I missing something???.
  • In section 6.7 - Same comment as just above.
    • =
  • In section 7.12 - About the = diversity specifications. We have come up with requests from our = customers to provide maximum diversity in addition to absolute = diversity, i.e. if you cannot find absolutely diverse set of routes then = find a set of routes with as fewer nodes/links/SRLGs in common as = possible. Has such concept of maximum diversity been discussed among the = authors and are there any parties on the PCE mailing list interested in = it also.

Regards,

Darek

Darek Skalecki
Optical Networks
Nortel =
dareks@nortel.com

=
Pce mailing list


= --Apple-Mail-41-82267075-- --===============0757370861== 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 --===============0757370861==-- From pce-bounces@lists.ietf.org Fri Nov 11 12:19:08 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EacXu-0007Uq-Fe; Fri, 11 Nov 2005 12:18:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EacXs-0007Uh-Ph for pce@megatron.ietf.org; Fri, 11 Nov 2005 12:18:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21068 for ; Fri, 11 Nov 2005 12:18:07 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EacoL-00056W-Ey for pce@ietf.org; Fri, 11 Nov 2005 12:35:37 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 11 Nov 2005 09:18:28 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.99,119,1131350400"; d="scan'208"; a="14951566:sNHT22197468" 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 jABHIHmq005206; Fri, 11 Nov 2005 12:18:26 -0500 (EST) 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, 11 Nov 2005 12:18:22 -0500 Received: from [192.168.1.102] ([10.86.242.171]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 11 Nov 2005 12:18:22 -0500 Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <69E83372-63B6-4777-AF5E-699E763D79C6@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Date: Thu, 10 Nov 2005 11:13:08 -0500 To: pce@ietf.org X-Mailer: Apple Mail (2.734) X-OriginalArrivalTime: 11 Nov 2005 17:18:22.0232 (UTC) FILETIME=[EADE2980:01C5E6E3] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Cc: Subject: [Pce] New Working Group documents 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, There was clear consensus to adopt the two following IDs as WG document during our last meeting in Vancouver: (1) draft-oki-pce-inter-layer-req, (2) draft-leroux-pce-pcecp-inter-area-reqs Both drafts require more work and comments should be addressed in further revisions. As usual let's confirm on the list. In the absence of objection, these two documents will be accepted as WG document in two weeks from now (November 24th). JP and Adrian. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Nov 11 14:35:22 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaegE-0005zB-67; Fri, 11 Nov 2005 14:35:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaegB-0005yy-RR for pce@megatron.ietf.org; Fri, 11 Nov 2005 14:35:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00450 for ; Fri, 11 Nov 2005 14:34:49 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eaewf-0002hZ-NM for pce@ietf.org; Fri, 11 Nov 2005 14:52:21 -0500 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EaegA-000F0v-HS for pce@ietf.org; Fri, 11 Nov 2005 19:35:18 +0000 Message-ID: <4374F27F.7080500@psg.com> Date: Fri, 11 Nov 2005 20:35:27 +0100 From: dimitri papadimitriou User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 X-Accept-Language: en-us, en MIME-Version: 1.0 To: pce@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: Subject: [Pce] multiple PCE path computation 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 all - during the discussion on "PCECP Specific Requirements for Inter-Area Path Computation" i raised the issue that this document addresses the case where the path computation is completely decoupled from its signaling however, there is a case - also described in Section 5.3 of the PCE architecture document - where multiple PCE path computations may be performed along the path during LSP establishment (we could refer to this case as path coupled computation) hence, the questions are o) do we need to address this case (imho: yes) o) do we need a separate document to address this case (the question is probably yes concerning the specific RSVP-TE processing during path establishment but is there a need to describe corresponding requirements in a dedicated document or could we make use of the "generic" document suggested by Jean-Louis) ? opinions appreciated. thanks, - dimitri. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Nov 14 17:08:07 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbmUg-0001aw-TF; Mon, 14 Nov 2005 17:08:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbmUf-0001ar-8S for pce@megatron.ietf.org; Mon, 14 Nov 2005 17:08:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04841 for ; Mon, 14 Nov 2005 17:07:32 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ebmll-0000Z3-93 for pce@ietf.org; Mon, 14 Nov 2005 17:25:46 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 14 Nov 2005 14:07:55 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,328,1125903600"; d="scan'208"; a="15189451:sNHT18846316" 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 jAEM7mJP021714; Mon, 14 Nov 2005 17:07:53 -0500 (EST) 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, 14 Nov 2005 17:07:52 -0500 Received: from [192.168.1.100] ([10.86.242.214]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 14 Nov 2005 17:07:51 -0500 Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: JP Vasseur Date: Mon, 14 Nov 2005 17:07:20 -0500 To: pce@ietf.org X-Mailer: Apple Mail (2.734) X-OriginalArrivalTime: 14 Nov 2005 22:07:51.0641 (UTC) FILETIME=[DB14E490:01C5E967] X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit Cc: Subject: [Pce] PCE WG Meeting presentations - IETF-64 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, The presentations used during the last WG meeting in Vancouver can be found at: https://datatracker.ietf.org/public/meeting_materials.cgi? meeting_num=64 Thanks. JP. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue Nov 15 13:31:37 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec5ai-00027C-Vt; Tue, 15 Nov 2005 13:31:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec5ag-000259-Cw for pce@megatron.ietf.org; Tue, 15 Nov 2005 13:31:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16019 for ; Tue, 15 Nov 2005 13:31:02 -0500 (EST) Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ec5rw-0006b4-VY for pce@ietf.org; Tue, 15 Nov 2005 13:49:26 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Tue, 15 Nov 2005 19:31:31 +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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] multiple PCE path computation Date: Tue, 15 Nov 2005 19:31:30 +0100 Message-ID: Thread-Topic: [Pce] multiple PCE path computation Thread-Index: AcXm9zuHXwJI9GCJSz2lN06HAVK96QDGMdTA From: "LE ROUX Jean-Louis RD-CORE-LAN" To: , , X-OriginalArrivalTime: 15 Nov 2005 18:31:31.0234 (UTC) FILETIME=[CC91B820:01C5EA12] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 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 Dimitri, Please see inline > -----Message d'origine----- > De : pce-bounces@lists.ietf.org=20 > [mailto:pce-bounces@lists.ietf.org] De la part de dimitri=20 > papadimitriou > Envoy=E9 : vendredi 11 novembre 2005 20:35 > =C0 : pce@ietf.org > Objet : [Pce] multiple PCE path computation >=20 > all - >=20 > during the discussion on "PCECP Specific Requirements for=20 > Inter-Area Path Computation" i raised the issue that this=20 > document addresses the case where the path computation is=20 > completely decoupled from its signaling Yes, that is, the path is entirely computed and then signaled. By the way, note that this does not necessarily mean that the returned = path is a strict explicit path. This may be a loose path, and ABRs may = still have to perfom ERO expansion (either directly or using the = services of an external PCE), but this may be a useless mode in this = inter-area context, where confidentiality is not a problem... >=20 > however, there is a case - also described in Section 5.3 of=20 > the PCE architecture document - where multiple PCE path=20 > computations may be performed along the path during LSP=20 > establishment (we could refer to this case as path coupled=20 > computation) Yes, note that this is also discussed in section 5 of this draft: "Note that the per-area path computation mode relying on route=20 expansion performed directly by ABRs on the path (which function has=20 composite PCEs) , or on external PCEs contacted by the ABRs on the=20 path, consists in fact of a simple concatenation of intra area paths. = It actually only implies intra-area path computations and does not=20 allow computing inter-area optimal paths. Hence this mode is not=20 discussed in this document. " >=20 > hence, the questions are >=20 > o) do we need to address this case (imho: yes) Yes this should be address, but, as explained in the draft in this case = PCEs perform intra-area path computation, so this is not strictly = speaking an inter-area path computation application... >=20 > o) do we need a separate document to address this case (the=20 > question is probably yes concerning the specific RSVP-TE=20 > processing during path establishment but is there a need to=20 > describe corresponding requirements in a dedicated document=20 > or could we make use of the "generic" document suggested by=20 > Jean-Louis) ? To me this is an intra-area path computation issue, and this should not = be covered in this ID. By the way do you see, with this application, any specific requirement = for the PCECP, not already covered in the generic ID?? Also note that RSVP-TE procedures for such coupled computation are = described in draft-ietf-ccamp-inter-domain-pd-path-comp... Regards, JL >=20 > opinions appreciated. >=20 > thanks, > - dimitri. >=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 Nov 17 13:46:23 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecom7-00083Q-Mj; Thu, 17 Nov 2005 13:46:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecom5-00083D-G5 for pce@megatron.ietf.org; Thu, 17 Nov 2005 13:46:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13449 for ; Thu, 17 Nov 2005 13:45:46 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ecp3k-0004hQ-FT for pce@ietf.org; Thu, 17 Nov 2005 14:04:38 -0500 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1Ecom0-0007IF-Ms; Thu, 17 Nov 2005 18:46:16 +0000 Message-ID: <437CD006.8090401@psg.com> Date: Thu, 17 Nov 2005 19:46:30 +0100 From: dimitri papadimitriou User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 X-Accept-Language: en-us, en MIME-Version: 1.0 To: LE ROUX Jean-Louis RD-CORE-LAN Subject: Re: [Pce] multiple PCE path computation References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id NAA13449 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 jean-louis, LE ROUX Jean-Louis RD-CORE-LAN wrote: > Hi Dimitri, >=20 > Please see inline >=20 >=20 >> -----Message d'origine----- De : pce-bounces@lists.ietf.org=20 >> [mailto:pce-bounces@lists.ietf.org] De la part de dimitri=20 >> papadimitriou Envoy=E9 : vendredi 11 novembre 2005 20:35 =C0 : >> pce@ietf.org Objet : [Pce] multiple PCE path computation >>=20 >> all - >>=20 >> during the discussion on "PCECP Specific Requirements for=20 >> Inter-Area Path Computation" i raised the issue that this document >> addresses the case where the path computation is completely >> decoupled from its signaling > =20 > Yes, that is, the path is entirely computed and then signaled. By the > way, note that this does not necessarily mean that the returned path > is a strict explicit path. This may be a loose path, and ABRs may > still have to perfom ERO expansion (either directly or using the > services of an external PCE), but this may be a useless mode in this > inter-area context, where confidentiality is not a problem... >=20 >> however, there is a case - also described in Section 5.3 of the PCE >> architecture document - where multiple PCE path computations may be >> performed along the path during LSP establishment (we could refer >> to this case as path coupled computation) >=20 > Yes, note that this is also discussed in section 5 of this draft: >=20 > "Note that the per-area path computation mode relying on route=20 > expansion performed directly by ABRs on the path (which function has > composite PCEs) , or on external PCEs contacted by the ABRs on the=20 > path, consists in fact of a simple concatenation of intra area paths. > It actually only implies intra-area path computations and does not=20 > allow computing inter-area optimal paths. Hence this mode is not=20 > discussed in this document. " >=20 >> hence, the questions are >>=20 >> o) do we need to address this case (imho: yes) >=20 > Yes this should be address, but, as explained in the draft in this > case PCEs perform intra-area path computation, so this is not > strictly speaking an inter-area path computation application... >=20 >> o) do we need a separate document to address this case (the=20 >> question is probably yes concerning the specific RSVP-TE processing >> during path establishment but is there a need to describe >> corresponding requirements in a dedicated document or could we make >> use of the "generic" document suggested by Jean-Louis) ? >=20 > To me this is an intra-area path computation issue, and this should > not be covered in this ID. >=20 > By the way do you see, with this application, any specific > requirement for the PCECP, not already covered in the generic ID?? the specific requirement in this case would be the PCE selection along=20 the signaled path, by default the PCE is driven by the local policy=20 (that by default may perform selection of the local computation engine)=20 and optionally the ERO may include a subobject indicating which PCE may=20 be contacted for further expanding the path - the reason for this is=20 that the ingress may be in a position to perform such selection from the=20 initial request rather than leaving the intermediate LSR performing this=20 selection but as i read your e-mail it is "yes, but not in this document" hence=20 the question remains shall we bring this back to CCAMP to complete the=20 RSVP extensions ? > Also note that RSVP-TE procedures for such coupled computation are > described in draft-ietf-ccamp-inter-domain-pd-path-comp... i sent an e-mail to the list concerning this document last october and i=20 would like to see what the revision will look like before further=20 stating this document is the right place for documenting the above thanks, - dimitri. > Regards, >=20 > JL >=20 >=20 >> opinions appreciated. >>=20 >> thanks, - dimitri. >>=20 >> _______________________________________________ Pce mailing list=20 >> Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce >>=20 >=20 >=20 > . >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Nov 18 08:47:33 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed6aT-0006G6-3W; Fri, 18 Nov 2005 08:47:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed6aS-0006Dh-A6 for pce@megatron.ietf.org; Fri, 18 Nov 2005 08:47:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18601 for ; Fri, 18 Nov 2005 08:46:56 -0500 (EST) 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 1Ed6sI-0000UP-AK for pce@ietf.org; Fri, 18 Nov 2005 09:05:59 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 18 Nov 2005 05:47:21 -0800 X-IronPort-AV: i="3.97,345,1125903600"; d="scan'208"; a="367216748:sNHT22967464" 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 jAIDlFCd014135; Fri, 18 Nov 2005 05:47:21 -0800 (PST) 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); Fri, 18 Nov 2005 08:47:16 -0500 Received: from [192.168.1.100] ([10.86.240.236]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 18 Nov 2005 08:47:16 -0500 Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: JP Vasseur Date: Fri, 18 Nov 2005 08:46:45 -0500 To: pce@ietf.org X-Mailer: Apple Mail (2.734) X-OriginalArrivalTime: 18 Nov 2005 13:47:16.0673 (UTC) FILETIME=[967F7B10:01C5EC46] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Cc: Subject: [Pce] Draft PCE WG Meeting minutes - IETF-64 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, You can find the Draft of the PCE WG meeting minutes at the following location: http://www3.ietf.org/proceedings/05nov/minutes/pce.txt Thanks to Richard Rabbat anb Scott Brim for the notes. Let us know if you have comments by November 28th. Thanks. JP. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Nov 18 11:14:41 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed8sr-0000lT-Ga; Fri, 18 Nov 2005 11:14:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed8sq-0000gT-Ix for pce@megatron.ietf.org; Fri, 18 Nov 2005 11:14:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26406 for ; Fri, 18 Nov 2005 11:14:06 -0500 (EST) Received: from blaster.systems.pipex.net ([62.241.163.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ed9Ag-000560-Kb for pce@ietf.org; Fri, 18 Nov 2005 11:33:09 -0500 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by blaster.systems.pipex.net (Postfix) with ESMTP id B7CC6E00018B for ; Fri, 18 Nov 2005 16:14:22 +0000 (GMT) Received: from Puppy ([138.111.223.143] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 18 Nov 2005 16:14:20 +0000 Message-ID: <004601c5ec5b$97159400$8fdf6f8a@Puppy> From: "Adrian Farrel" To: Date: Fri, 18 Nov 2005 16:13:31 -0000 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-OriginalArrivalTime: 18 Nov 2005 16:14:21.0085 (UTC) FILETIME=[2241E4D0:01C5EC5B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: Subject: [Pce] Working group next steps for protocols 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, Following up from the Vancouver meeting (per the meeting report) I would like your opinion on the following actions. 1. Discovery solutions work. The meeting had good support for adopting draft-leroux-pce-disco-proto-igp-00.txt as a Working Group draft to provide IGP-based solutions for PCE discovery. What is your opinion on this becoming a WG draft? 2. PCE Communications Protocol The Vancouver meeting discussed both the process of selecting a PCECP and the candidate protocol (PCEP) described in draft-vasseur-pce-pcep-02.txt. The mood of the meeting was that PCEP should be worked on within the working group, and there was no objection to this becoming a WG draft. What is your opinion on this becoming a WG draft? Thanks, Adrian _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Nov 18 11:18:36 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed8we-0002Kr-9b; Fri, 18 Nov 2005 11:18:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed8wd-0002FP-4l for pce@megatron.ietf.org; Fri, 18 Nov 2005 11:18:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26654 for ; Fri, 18 Nov 2005 11:18:00 -0500 (EST) Received: from mail126.messagelabs.com ([216.82.254.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ed9EQ-0005DO-U5 for pce@ietf.org; Fri, 18 Nov 2005 11:37:03 -0500 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-11.tower-126.messagelabs.com!1132330689!8449993!4 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 27960 invoked from network); 18 Nov 2005 16:18:17 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-11.tower-126.messagelabs.com with SMTP; 18 Nov 2005 16:18:17 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by attrh3i.attrh.att.com (7.2.052) id 435BB4FA004DAD1C; Fri, 18 Nov 2005 11:18:17 -0500 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] Working group next steps for protocols Date: Fri, 18 Nov 2005 10:18:16 -0600 Message-ID: <9473683187ADC049A855ED2DA739ABCA09FA96AD@KCCLUST06EVS1.ugd.att.com> Thread-Topic: [Pce] Working group next steps for protocols Thread-Index: AcXsW0r3gM2+sxBaRJyI6udIVkVxfAAABENw From: "Ash, Gerald R \(Jerry\), ALABS" To: "Adrian Farrel" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 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 > draft-leroux-pce-disco-proto-igp-00.txt > What is your opinion on this becoming a WG draft? Yes. > draft-vasseur-pce-pcep-02.txt. > What is your opinion on this becoming a WG draft? Yes. Thanks, Jerry _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Nov 18 11:28:14 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed95y-0004zF-JR; Fri, 18 Nov 2005 11:28:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed95m-0004qK-QW for pce@megatron.ietf.org; Fri, 18 Nov 2005 11:28:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27193 for ; Fri, 18 Nov 2005 11:27:28 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ed9Ne-0005Uj-1y for pce@ietf.org; Fri, 18 Nov 2005 11:46:31 -0500 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1Ed95k-000A7Q-7D; Fri, 18 Nov 2005 16:28:00 +0000 Message-ID: <437E011B.6030003@psg.com> Date: Fri, 18 Nov 2005 17:28:11 +0100 From: dimitri papadimitriou User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 X-Accept-Language: en-us, en MIME-Version: 1.0 To: JP Vasseur Subject: Re: [Pce] Draft PCE WG Meeting minutes - IETF-64 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac 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 jp comments in-line [snip] 5) Discussion on the PCE Discovery protocol (Jean-Louis Le Roux - 15mn) draft-leroux-pce-disco-proto-igp-00.txt See slides for content JP> one of the strengths is that you use existing ISIS Router capability TLV and OSPF Router Information LSA with no change in term of elements of procedures. JP> it's fair to make the assumption that it could be easily used Dimitri> we may need another protocol for extensions? [replace by] Dimitri> We may then need another protocol when the discovery mechanism will be extended to the inter-AS case [snip] Adrian> both requirements and solution need to be restructured? Dimitri> requirement document could have been written another way but focus is solution [rephrase] Dimitri> the requirement document could have been written another way but focus is now on the solution (document) [snip] Dimitri> you're expecting that you will get the whole path, not a partial path. It has been suggested to use this or that pce if you're going to compute the path [rephrase] Dimitri> You're expecting that you will get the whole path, not a partial path; it should be possible (as previously discussed) to include as part of the signaling request an explicit indication about which PCE is suggested to be used for ERO expansion purposes ? --- JP Vasseur wrote: > Dear WG, > > You can find the Draft of the PCE WG meeting minutes at the following > location: > > http://www3.ietf.org/proceedings/05nov/minutes/pce.txt > > Thanks to Richard Rabbat anb Scott Brim for the notes. > > Let us know if you have comments by November 28th. > > Thanks. > > JP. > > _______________________________________________ > 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 Nov 18 11:52:20 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed9TI-0008MS-Iq; Fri, 18 Nov 2005 11:52:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed9TH-0008Gt-AJ for pce@megatron.ietf.org; Fri, 18 Nov 2005 11:52:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28305 for ; Fri, 18 Nov 2005 11:51:44 -0500 (EST) 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 1Ed9l8-00063s-T8 for pce@ietf.org; Fri, 18 Nov 2005 12:10:48 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 18 Nov 2005 08:52:09 -0800 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 jAIGq8CP028850; Fri, 18 Nov 2005 08:52:09 -0800 (PST) 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); Fri, 18 Nov 2005 08:52:07 -0800 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] Working group next steps for protocols Date: Fri, 18 Nov 2005 08:52:06 -0800 Message-ID: <70BC84B185C3EE448EDB7AB8956D3B0EE92DD7@xmb-sjc-234.amer.cisco.com> Thread-Topic: [Pce] Working group next steps for protocols Thread-Index: AcXsW1ReDLZoTPH2SJi/E6AXBo8i0wABPHow From: "Dean Cheng \(dcheng\)" To: "Adrian Farrel" , X-OriginalArrivalTime: 18 Nov 2005 16:52:07.0923 (UTC) FILETIME=[6965EC30:01C5EC60] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b 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 Support both as WG draft. Dean=20 -----Original Message----- From: pce-bounces@lists.ietf.org [mailto:pce-bounces@lists.ietf.org] On Behalf Of Adrian Farrel Sent: Friday, November 18, 2005 8:14 AM To: pce@ietf.org Subject: [Pce] Working group next steps for protocols Hi, Following up from the Vancouver meeting (per the meeting report) I would like your opinion on the following actions. 1. Discovery solutions work. The meeting had good support for adopting draft-leroux-pce-disco-proto-igp-00.txt as a Working Group draft to provide IGP-based solutions for PCE discovery. What is your opinion on this becoming a WG draft? 2. PCE Communications Protocol The Vancouver meeting discussed both the process of selecting a PCECP and the candidate protocol (PCEP) described in draft-vasseur-pce-pcep-02.txt. The mood of the meeting was that PCEP should be worked on within the working group, and there was no objection to this becoming a WG draft. What is your opinion on this becoming a WG draft? Thanks, Adrian _______________________________________________ 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 Nov 18 11:56:16 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed9X6-00070B-Mg; Fri, 18 Nov 2005 11:56:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed9X5-0006tQ-0l for pce@megatron.ietf.org; Fri, 18 Nov 2005 11:56:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28497 for ; Fri, 18 Nov 2005 11:55:40 -0500 (EST) Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ed9ov-00069G-Hz for pce@ietf.org; Fri, 18 Nov 2005 12:14:43 -0500 Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id jAIGtp617731; Fri, 18 Nov 2005 11:55:51 -0500 (EST) 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] Working group next steps for protocols Date: Fri, 18 Nov 2005 11:55:49 -0500 Message-ID: <9671A92C3C8B5744BC97F855F7CB6465070A8B02@zcarhxm1.corp.nortel.com> Thread-Topic: [Pce] Working group next steps for protocols Thread-Index: AcXsW01xY/7wvqvRQXa1lSLBWTLJqQABUT/A From: "Darek Skalecki" To: "Adrian Farrel" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca 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 Good day, I put my vote in support for the PCEP draft-vasseur-pce-pcep-02.txt becoming a WG draft. Darek Darek Skalecki Optical Networks Nortel dareks@nortel.com -----Original Message----- From: pce-bounces@lists.ietf.org [mailto:pce-bounces@lists.ietf.org] On Behalf Of Adrian Farrel Sent: November 18, 2005 11:14 AM To: pce@ietf.org Subject: [Pce] Working group next steps for protocols Hi, Following up from the Vancouver meeting (per the meeting report) I would like your opinion on the following actions. 1. Discovery solutions work. The meeting had good support for adopting draft-leroux-pce-disco-proto-igp-00.txt as a Working Group draft to provide IGP-based solutions for PCE discovery. What is your opinion on this becoming a WG draft? 2. PCE Communications Protocol The Vancouver meeting discussed both the process of selecting a PCECP and the candidate protocol (PCEP) described in draft-vasseur-pce-pcep-02.txt. The mood of the meeting was that PCEP should be worked on within the working group, and there was no objection to this becoming a WG draft. What is your opinion on this becoming a WG draft? Thanks, Adrian _______________________________________________ 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 Nov 18 12:05:01 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed9fZ-0006xq-Ob; Fri, 18 Nov 2005 12:05:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed9fX-0006oA-HT for pce@megatron.ietf.org; Fri, 18 Nov 2005 12:04:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29128 for ; Fri, 18 Nov 2005 12:04:25 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ed9xO-0006TI-7O for pce@ietf.org; Fri, 18 Nov 2005 12:23:28 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 18 Nov 2005 09:04:47 -0800 X-IronPort-AV: i="3.97,346,1125903600"; d="scan'208"; a="232136113:sNHT24808052" 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 jAIH4dOr009196; Fri, 18 Nov 2005 09:04:42 -0800 (PST) Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 18 Nov 2005 12:04:43 -0500 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] Working group next steps for protocols Date: Fri, 18 Nov 2005 12:04:42 -0500 Message-ID: Thread-Topic: [Pce] Working group next steps for protocols Thread-Index: AcXsW1V6jIBAtO6lSCKoWVBUKS5weAABsjsw From: "Zafar Ali \(zali\)" To: "Adrian Farrel" , X-OriginalArrivalTime: 18 Nov 2005 17:04:43.0467 (UTC) FILETIME=[2BBCC9B0:01C5EC62] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 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 Yes, to both.=20 Thanks Regards... Zafar =20 > -----Original Message----- > From: pce-bounces@lists.ietf.org=20 > [mailto:pce-bounces@lists.ietf.org] On Behalf Of Adrian Farrel > Sent: Friday, November 18, 2005 11:14 AM > To: pce@ietf.org > Subject: [Pce] Working group next steps for protocols >=20 > Hi, >=20 > Following up from the Vancouver meeting (per the meeting=20 > report) I would like your opinion on the following actions. >=20 > 1. Discovery solutions work. > The meeting had good support for adopting=20 > draft-leroux-pce-disco-proto-igp-00.txt as a Working Group=20 > draft to provide IGP-based solutions for PCE discovery. >=20 > What is your opinion on this becoming a WG draft? >=20 > 2. PCE Communications Protocol > The Vancouver meeting discussed both the process of selecting=20 > a PCECP and the candidate protocol (PCEP) described in=20 > draft-vasseur-pce-pcep-02.txt. > The mood of the meeting was that PCEP should be worked on=20 > within the working group, and there was no objection to this=20 > becoming a WG draft. >=20 > What is your opinion on this becoming a WG draft? >=20 > Thanks, > Adrian >=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 Fri Nov 18 12:21:01 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed9kX-0004ju-ME; Fri, 18 Nov 2005 12:10:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed9kU-0004as-Ug for pce@megatron.ietf.org; Fri, 18 Nov 2005 12:10:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29551 for ; Fri, 18 Nov 2005 12:09:32 -0500 (EST) Received: from usjk1003.kddi.com ([211.4.169.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EdA2E-0006dB-UY for pce@ietf.org; Fri, 18 Nov 2005 12:28:35 -0500 Received: from usjk1006.kddi.com (usjk1006 [10.96.2.3]) by usjk1003.kddi.com with ESMTP id jAIH9Sa29195; Sat, 19 Nov 2005 02:09:28 +0900 (JST) Received: from usjk1039 (localhost [127.0.0.1]) by usjk1006.kddi.com with SMTP id jAIH9S507325; Sat, 19 Nov 2005 02:09:28 +0900 (JST) Received: from [127.0.0.1] ([133.128.75.150]) by usjk1010.kddi.com (InterMail vM.5.01.02.00 201-253-116-121-20001201) with ESMTP id <20051118170925.TAKM22556.usjk1010.kddi.com@[127.0.0.1]>; Sat, 19 Nov 2005 02:09:25 +0900 Date: Sat, 19 Nov 2005 02:09:20 +0900 From: Kenji Kumaki To: Adrian Farrel Subject: Re: [Pce] Working group next steps for protocols In-Reply-To: <004601c5ec5b$97159400$8fdf6f8a@Puppy> References: <004601c5ec5b$97159400$8fdf6f8a@Puppy> Message-Id: <20051119020827.EB97.KE-KUMAKI@kddi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.21.03 [ja] X-WAuditID: 0511190209250000220551 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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, > 1. Discovery solutions work. > The meeting had good support for adopting > draft-leroux-pce-disco-proto-igp-00.txt as a Working Group draft to > provide IGP-based solutions for PCE discovery. > > What is your opinion on this becoming a WG draft? > Yes. > 2. PCE Communications Protocol > The Vancouver meeting discussed both the process of selecting a PCECP and > the candidate protocol (PCEP) described in draft-vasseur-pce-pcep-02.txt. > The mood of the meeting was that PCEP should be worked on within the > working group, and there was no objection to this becoming a WG draft. > > What is your opinion on this becoming a WG draft? > Yes. Thanks, Kenji > Thanks, > Adrian > > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce -- Kenji Kumaki _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Nov 18 13:13:54 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdAkE-0003eL-D9; Fri, 18 Nov 2005 13:13:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdAkD-0003aS-A8 for pce@megatron.ietf.org; Fri, 18 Nov 2005 13:13:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02592 for ; Fri, 18 Nov 2005 13:13:18 -0500 (EST) Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EdB25-00088s-Dh for pce@ietf.org; Fri, 18 Nov 2005 13:32:22 -0500 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 jAIIDgfK022641; Fri, 18 Nov 2005 13:13:42 -0500 (EST) 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 NAA23386; Fri, 18 Nov 2005 13:13:42 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id ; Fri, 18 Nov 2005 16:13:41 -0200 Message-ID: <313680C9A886D511A06000204840E1CF0C8860DF@whq-msgusr-02.pit.comms.marconi.com> From: "Gray, Eric" To: "'Adrian Farrel'" Subject: RE: [Pce] Working group next steps for protocols Date: Fri, 18 Nov 2005 16:13:39 -0200 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: 769a46790fb42fbb0b0cc700c82f7081 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 Adrian, et al, Please see responses in line below (short answer, yes and yes)... --> -----Original Message----- --> From: pce-bounces@lists.ietf.org --> [mailto:pce-bounces@lists.ietf.org] On Behalf Of Adrian Farrel --> Sent: Friday, November 18, 2005 11:14 AM --> To: pce@ietf.org --> Subject: [Pce] Working group next steps for protocols --> --> Hi, --> --> Following up from the Vancouver meeting (per the meeting --> report) I would like your opinion on the following actions. --> --> 1. Discovery solutions work. --> The meeting had good support for adopting --> draft-leroux-pce-disco-proto-igp-00.txt as a Working Group --> draft to provide IGP-based solutions for PCE discovery. --> --> What is your opinion on this becoming a WG draft? It should become a WG draft. --> --> 2. PCE Communications Protocol --> The Vancouver meeting discussed both the process of --> selecting a PCECP and the candidate protocol (PCEP) --> described in draft-vasseur-pce-pcep-02.txt. --> The mood of the meeting was that PCEP should be worked on --> within the working group, and there was no objection to --> this becoming a WG draft. --> --> What is your opinion on this becoming a WG draft? It should become a WG draft. --> --> Thanks, --> Adrian --> --> --> _______________________________________________ --> 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 Nov 18 14:13:35 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdBfz-00040O-46; Fri, 18 Nov 2005 14:13:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdBfy-00040J-2y for pce@megatron.ietf.org; Fri, 18 Nov 2005 14:13:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05160 for ; Fri, 18 Nov 2005 14:12:58 -0500 (EST) Received: from webmail.movaz.com ([70.158.43.219] helo=jera.movaz.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EdBxq-0000zk-U5 for pce@ietf.org; Fri, 18 Nov 2005 14:32:04 -0500 Received: from ib (vpn19.atlanta.movaz.com [172.18.0.19]) by jera.movaz.com (Postfix) with SMTP id 24AAD286A4; Fri, 18 Nov 2005 14:12:42 -0500 (EST) Message-ID: <010b01c5ec74$1e056a40$6601a8c0@movaz.com> From: "Igor Bryskin" To: "Adrian Farrel" , References: <004601c5ec5b$97159400$8fdf6f8a@Puppy> Subject: Re: [Pce] Working group next steps for protocols Date: Fri, 18 Nov 2005 14:13:10 -0500 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: 7baded97d9887f7a0c7e8a33c2e3ea1b 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, > > Following up from the Vancouver meeting (per the meeting report) I would > like your opinion on the following actions. > > 1. Discovery solutions work. > The meeting had good support for adopting > draft-leroux-pce-disco-proto-igp-00.txt as a Working Group draft to > provide IGP-based solutions for PCE discovery. > > What is your opinion on this becoming a WG draft? IB>> Should become WG draft > > 2. PCE Communications Protocol > The Vancouver meeting discussed both the process of selecting a PCECP and > the candidate protocol (PCEP) described in draft-vasseur-pce-pcep-02.txt. > The mood of the meeting was that PCEP should be worked on within the > working group, and there was no objection to this becoming a WG draft. > > What is your opinion on this becoming a WG draft? IB>> Should become WG draft on a condition that the PCEP is viewed as as a mlti-layer (at least, two layer) protocol with a clear separation between its semantics and transport. Igor > > Thanks, > Adrian > > > _______________________________________________ > 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 Nov 18 14:28:57 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdBur-0002Op-GC; Fri, 18 Nov 2005 14:28:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdBup-0002Of-On for pce@megatron.ietf.org; Fri, 18 Nov 2005 14:28:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05916 for ; Fri, 18 Nov 2005 14:28:20 -0500 (EST) 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 1EdCCi-0001NA-MQ for pce@ietf.org; Fri, 18 Nov 2005 14:47:26 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 18 Nov 2005 11:28:28 -0800 X-IronPort-AV: i="3.97,347,1125903600"; d="scan'208"; a="676639719:sNHT27265436" 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 jAIJSCec023130; Fri, 18 Nov 2005 11:28:25 -0800 (PST) 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); Fri, 18 Nov 2005 14:28:09 -0500 Received: from [192.168.1.100] ([10.86.240.41]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 18 Nov 2005 14:28:09 -0500 In-Reply-To: <437E011B.6030003@psg.com> References: <437E011B.6030003@psg.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: [Pce] Draft PCE WG Meeting minutes - IETF-64 Date: Fri, 18 Nov 2005 14:27:39 -0500 To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be X-Mailer: Apple Mail (2.734) X-OriginalArrivalTime: 18 Nov 2005 19:28:09.0516 (UTC) FILETIME=[3557A6C0:01C5EC76] X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 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, Thanks, I'll reflect your changes. JP. On Nov 18, 2005, at 11:28 AM, dimitri papadimitriou wrote: > hi jp > > comments in-line > > [snip] > > 5) Discussion on the PCE Discovery protocol (Jean-Louis Le Roux - > 15mn) > draft-leroux-pce-disco-proto-igp-00.txt > > See slides for content > > JP> one of the strengths is that you use existing ISIS Router > capability TLV and OSPF Router Information LSA with no change in > term of elements of procedures. > > JP> it's fair to make the assumption that it could be easily used > > Dimitri> we may need another protocol for extensions? > > [replace by] Dimitri> We may then need another protocol when the > discovery mechanism will be extended to the inter-AS case > > [snip] > > Adrian> both requirements and solution need to be restructured? > > Dimitri> requirement document could have been written another way > but focus is solution > > [rephrase] Dimitri> the requirement document could have been > written another way but focus is now on the solution (document) > > [snip] > > Dimitri> you're expecting that you will get the whole path, not a > partial path. It has been suggested to use this or that pce if > you're going to compute the path > > [rephrase] Dimitri> You're expecting that you will get the whole > path, not a partial path; it should be possible (as previously > discussed) to include as part of the signaling request an explicit > indication about which PCE is suggested to be used for ERO > expansion purposes ? > > --- > > > > > > > > > > JP Vasseur wrote: > > >> Dear WG, >> You can find the Draft of the PCE WG meeting minutes at the >> following location: >> http://www3.ietf.org/proceedings/05nov/minutes/pce.txt >> Thanks to Richard Rabbat anb Scott Brim for the notes. >> Let us know if you have comments by November 28th. >> Thanks. >> JP. >> _______________________________________________ >> 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 Nov 18 16:02:26 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdDNK-0000Sw-7d; Fri, 18 Nov 2005 16:02:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdDNJ-0000Sl-65 for pce@megatron.ietf.org; Fri, 18 Nov 2005 16:02:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10466 for ; Fri, 18 Nov 2005 16:01:48 -0500 (EST) Received: from wproxy.gmail.com ([64.233.184.197]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EdDfC-0003my-7n for pce@ietf.org; Fri, 18 Nov 2005 16:20:55 -0500 Received: by wproxy.gmail.com with SMTP id 58so450510wri for ; Fri, 18 Nov 2005 13:02:20 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=mAHjdAIoQTtqzW5lnNQxHW9JHHQ30k3Fhb+Z1uE27lsLyFHOCC0MCuU9zVSOvbX+Z78xRJKZxaeZeQ/1N+Z0F4LbIZaf0sQOTJ28Ey8ZLRAno7haJqaDLE1s35lPmh9/bS3QYLoE7eaws3aiatsBwzIUk3/mCpFCfc+N7gmNhaM= Received: by 10.54.91.15 with SMTP id o15mr251894wrb; Fri, 18 Nov 2005 13:02:20 -0800 (PST) Received: by 10.54.151.15 with HTTP; Fri, 18 Nov 2005 13:02:20 -0800 (PST) Message-ID: <6280db520511181302o78257f4cl62e8174059002569@mail.gmail.com> Date: Fri, 18 Nov 2005 13:02:20 -0800 From: Alia Atlas To: Adrian Farrel Subject: Re: [Pce] Working group next steps for protocols In-Reply-To: <004601c5ec5b$97159400$8fdf6f8a@Puppy> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <004601c5ec5b$97159400$8fdf6f8a@Puppy> X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 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 Yes and yes Alia On 11/18/05, Adrian Farrel wrote: > Hi, > > Following up from the Vancouver meeting (per the meeting report) I would > like your opinion on the following actions. > > 1. Discovery solutions work. > The meeting had good support for adopting > draft-leroux-pce-disco-proto-igp-00.txt as a Working Group draft to > provide IGP-based solutions for PCE discovery. > > What is your opinion on this becoming a WG draft? > > 2. PCE Communications Protocol > The Vancouver meeting discussed both the process of selecting a PCECP and > the candidate protocol (PCEP) described in draft-vasseur-pce-pcep-02.txt. > The mood of the meeting was that PCEP should be worked on within the > working group, and there was no objection to this becoming a WG draft. > > What is your opinion on this becoming a WG draft? > > Thanks, > Adrian > > > _______________________________________________ > 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 Nov 18 16:21:45 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdDg1-0005no-Cq; Fri, 18 Nov 2005 16:21:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdDg0-0005ni-Dr for pce@megatron.ietf.org; Fri, 18 Nov 2005 16:21:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11654 for ; Fri, 18 Nov 2005 16:21:08 -0500 (EST) Received: from cbis.ece.drexel.edu ([129.25.60.1] helo=coe.drexel.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EdDxt-0004LR-9h for pce@ietf.org; Fri, 18 Nov 2005 16:40:15 -0500 Received: from [129.25.14.14] (n1-14-14.dhcp.drexel.edu [129.25.14.14]) (authenticated bits=0) by coe.drexel.edu (8.13.4/8.13.4) with ESMTP id jAILLan3016846 for ; Fri, 18 Nov 2005 16:21:36 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v746.2) References: <403A0BD4-3734-404B-9F5B-42E035A0684B@ece.drexel.edu> X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <47634192-16E2-4A55-A2F9-0AC72629073C@ece.drexel.edu> Content-Transfer-Encoding: 7bit From: Jaudelice Cavalcante de Oliveira Subject: Re: [Pce] Working group next steps for protocols Date: Fri, 18 Nov 2005 16:21:35 -0500 To: pce@ietf.org X-Mailer: Apple Mail (2.746.2) X-Spam-Score: (-1.54) AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.51 on 129.25.60.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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 On Nov 18, 2005, at 11:13 AM, Adrian Farrel wrote: > 1. Discovery solutions work. > The meeting had good support for adopting > draft-leroux-pce-disco-proto-igp-00.txt as a Working Group draft to > provide IGP-based solutions for PCE discovery. > > What is your opinion on this becoming a WG draft? Agree. > 2. PCE Communications Protocol > The Vancouver meeting discussed both the process of selecting a > PCECP and > the candidate protocol (PCEP) described in draft-vasseur-pce- > pcep-02.txt. > The mood of the meeting was that PCEP should be worked on within the > working group, and there was no objection to this becoming a WG draft. > > What is your opinion on this becoming a WG draft? > Agree. Thanks, Jaudelice. Jaudelice C. de Oliveira, Assistant Professor Electrical and Computer Engineering Department Drexel University, Philadelphia, PA, USA Phone: 215.895.2248 Fax: 215.895.1695 web: http://www.ece.drexel.edu/faculty/deoliveira/ _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Nov 18 18:11:19 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdFO3-0005t5-1N; Fri, 18 Nov 2005 18:11:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdFO1-0005t0-UU for pce@megatron.ietf.org; Fri, 18 Nov 2005 18:11:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16398 for ; Fri, 18 Nov 2005 18:10:43 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EdFfw-0006mJ-T7 for pce@ietf.org; Fri, 18 Nov 2005 18:29:50 -0500 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EdFNs-000BFR-PM; Fri, 18 Nov 2005 23:11:09 +0000 Message-ID: <437E5F97.7010909@psg.com> Date: Sat, 19 Nov 2005 00:11:19 +0100 From: dimitri papadimitriou User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adrian Farrel Subject: Re: [Pce] Working group next steps for protocols References: <004601c5ec5b$97159400$8fdf6f8a@Puppy> In-Reply-To: <004601c5ec5b$97159400$8fdf6f8a@Puppy> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 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 > Following up from the Vancouver meeting (per the meeting report) I would > like your opinion on the following actions. > > 1. Discovery solutions work. > The meeting had good support for adopting > draft-leroux-pce-disco-proto-igp-00.txt as a Working Group draft to > provide IGP-based solutions for PCE discovery. > > What is your opinion on this becoming a WG draft? you mention solution*S* what does that exactly mean ? that the WG may come out with more than one solution which seems to me to be advisable as the proposed solution is only suitable when PCEs are located/ connected on LSRs in part. ABR; in that context start work on this is ok along as its content is open to discussion > 2. PCE Communications Protocol > The Vancouver meeting discussed both the process of selecting a PCECP and > the candidate protocol (PCEP) described in draft-vasseur-pce-pcep-02.txt. > The mood of the meeting was that PCEP should be worked on within the > working group, and there was no objection to this becoming a WG draft. > > What is your opinion on this becoming a WG draft? the discussion during the f2f meeting have clearly shown that there is serious work that needs to be done on this document to structure the protocol (per RFC 4101) such as to distinguish between the role of the transport, the transaction primitives and information to be carried back and forth between the client/server and the server; hence there is also (as recorded during the meeting) an effort that needs to be provided to clearly identify this information - in brief, yes, as long as these objectives are maintained > Thanks, > Adrian > > > _______________________________________________ > 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 Sun Nov 20 07:10:25 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Edo1Z-0001Hy-G2; Sun, 20 Nov 2005 07:10:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Edo1X-0001Ht-Bi for pce@megatron.ietf.org; Sun, 20 Nov 2005 07:10:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15001 for ; Sun, 20 Nov 2005 07:09:45 -0500 (EST) Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EdoJk-0007au-F9 for pce@ietf.org; Sun, 20 Nov 2005 07:29:14 -0500 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id jAKCA7BM004146; Sun, 20 Nov 2005 21:10:07 +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 jAKCA7ix024262; Sun, 20 Nov 2005 21:10:07 +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 jAKCA6GE024255; Sun, 20 Nov 2005 21:10:06 +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 jAKCA6Ex027087; Sun, 20 Nov 2005 21:10:06 +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 jAKCA6uC027084; Sun, 20 Nov 2005 21:10:06 +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 jAKCA5A9008529; Sun, 20 Nov 2005 21:10:05 +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 jAKCA5c7009093; Sun, 20 Nov 2005 21:10:05 +0900 (JST) Received: from imb.m.ecl.ntt.co.jp (imb.m.ecl.ntt.co.jp [129.60.5.226]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id jAKCA4GU009090; Sun, 20 Nov 2005 21:10:04 +0900 (JST) Received: from [192.168.1.2] ([129.60.15.201]) by imb.m.ecl.ntt.co.jp (8.13.4/8.13.4) with ESMTP id jAKCA3tY003740; Sun, 20 Nov 2005 21:10:04 +0900 (JST) Date: Sun, 20 Nov 2005 21:10:00 +0900 From: Eiji Oki To: Adrian Farrel Subject: Re: [Pce] Working group next steps for protocols In-Reply-To: <004601c5ec5b$97159400$8fdf6f8a@Puppy> References: <004601c5ec5b$97159400$8fdf6f8a@Puppy> Message-Id: <20051120210528.E869.OKI.EIJI@lab.ntt.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.21.03 [ja] X-Spam-Score: 2.2 (++) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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, Yes, to both. Thank you. Eiji On Fri, 18 Nov 2005 16:13:31 -0000 "Adrian Farrel" wrote: > Hi, > > Following up from the Vancouver meeting (per the meeting report) I would > like your opinion on the following actions. > > 1. Discovery solutions work. > The meeting had good support for adopting > draft-leroux-pce-disco-proto-igp-00.txt as a Working Group draft to > provide IGP-based solutions for PCE discovery. > > What is your opinion on this becoming a WG draft? > > 2. PCE Communications Protocol > The Vancouver meeting discussed both the process of selecting a PCECP and > the candidate protocol (PCEP) described in draft-vasseur-pce-pcep-02.txt. > The mood of the meeting was that PCEP should be worked on within the > working group, and there was no objection to this becoming a WG draft. > > What is your opinion on this becoming a WG draft? > > Thanks, > Adrian > > > _______________________________________________ > 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 Sun Nov 20 11:01:20 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Edrd2-0007SD-6L; Sun, 20 Nov 2005 11:01:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Edrd1-0007S8-32 for pce@megatron.ietf.org; Sun, 20 Nov 2005 11:01:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27428 for ; Sun, 20 Nov 2005 11:00:41 -0500 (EST) Received: from coral.ocn.ne.jp ([222.146.40.164] helo=smtp.coral.ocn.ne.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EdrvD-0005DK-Rs for pce@ietf.org; Sun, 20 Nov 2005 11:20:12 -0500 Received: from ikejiri-ibm-new (p29196-adsau17honb12-acca.tokyo.ocn.ne.jp [60.43.66.196]) by smtp.coral.ocn.ne.jp (Postfix) with ESMTP id 6FEA96BFA for ; Mon, 21 Nov 2005 01:01:06 +0900 (JST) Date: Mon, 21 Nov 2005 01:01:07 +0900 From: Yuichi Ikejiri To: Subject: Re: [Pce] Working group next steps for protocols In-Reply-To: <004601c5ec5b$97159400$8fdf6f8a@Puppy> References: <004601c5ec5b$97159400$8fdf6f8a@Puppy> Message-Id: <20051121005218.9F14.Y.IKEJIRI@ntt.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.00.03 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 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, On Fri, 18 Nov 2005 16:13:31 -0000 "Adrian Farrel" wrote: > Hi, > > Following up from the Vancouver meeting (per the meeting report) I would > like your opinion on the following actions. > > 1. Discovery solutions work. > The meeting had good support for adopting > draft-leroux-pce-disco-proto-igp-00.txt as a Working Group draft to > provide IGP-based solutions for PCE discovery. > > What is your opinion on this becoming a WG draft? Yes, I support that it is becoming a WG draft. > > 2. PCE Communications Protocol > The Vancouver meeting discussed both the process of selecting a PCECP and > the candidate protocol (PCEP) described in draft-vasseur-pce-pcep-02.txt. > The mood of the meeting was that PCEP should be worked on within the > working group, and there was no objection to this becoming a WG draft. > > What is your opinion on this becoming a WG draft? Yes, I support that it is becoming a WG draft. Thanks, Yuichi > > Thanks, > Adrian > > > _______________________________________________ > 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 Sun Nov 20 15:57:42 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdwFq-0005sk-Qm; Sun, 20 Nov 2005 15:57:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdwFp-0005sS-9K for pce@megatron.ietf.org; Sun, 20 Nov 2005 15:57:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12861 for ; Sun, 20 Nov 2005 15:57:04 -0500 (EST) Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EdwY8-0004QB-TG for pce@ietf.org; Sun, 20 Nov 2005 16:16:37 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Sun, 20 Nov 2005 21:57: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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] multiple PCE path computation Date: Sun, 20 Nov 2005 21:57:30 +0100 Message-ID: Thread-Topic: [Pce] multiple PCE path computation Thread-Index: AcXrpzJetXpo5Q9EQsSZHrEVWVFzPQAvo1OQ From: "LE ROUX Jean-Louis RD-CORE-LAN" To: , X-OriginalArrivalTime: 20 Nov 2005 20:57:33.0257 (UTC) FILETIME=[07351390:01C5EE15] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba 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, Please find inlined answers,=20 > -----Message d'origine----- > De : dimitri papadimitriou [mailto:dpapadimitriou@psg.com]=20 > Envoy=E9 : jeudi 17 novembre 2005 19:47 > =C0 : LE ROUX Jean-Louis RD-CORE-LAN > Cc : dimitri.papadimitriou@alcatel.be; pce@ietf.org > Objet : Re: [Pce] multiple PCE path computation >=20 > hi jean-louis, >=20 > LE ROUX Jean-Louis RD-CORE-LAN wrote: > > Hi Dimitri, > >=20 > > Please see inline > >=20 > >=20 > >> -----Message d'origine----- De : pce-bounces@lists.ietf.org=20 > >> [mailto:pce-bounces@lists.ietf.org] De la part de dimitri=20 > >> papadimitriou Envoy=E9 : vendredi 11 novembre 2005 20:35 =C0 : > >> pce@ietf.org Objet : [Pce] multiple PCE path computation > >>=20 > >> all - > >>=20 > >> during the discussion on "PCECP Specific Requirements for=20 > Inter-Area=20 > >> Path Computation" i raised the issue that this document=20 > addresses the=20 > >> case where the path computation is completely decoupled from its=20 > >> signaling > > =20 > > Yes, that is, the path is entirely computed and then=20 > signaled. By the=20 > > way, note that this does not necessarily mean that the=20 > returned path=20 > > is a strict explicit path. This may be a loose path, and ABRs may=20 > > still have to perfom ERO expansion (either directly or using the=20 > > services of an external PCE), but this may be a useless=20 > mode in this=20 > > inter-area context, where confidentiality is not a problem... > >=20 > >> however, there is a case - also described in Section 5.3=20 > of the PCE=20 > >> architecture document - where multiple PCE path=20 > computations may be=20 > >> performed along the path during LSP establishment (we=20 > could refer to=20 > >> this case as path coupled computation) > >=20 > > Yes, note that this is also discussed in section 5 of this draft: > >=20 > > "Note that the per-area path computation mode relying on route=20 > > expansion performed directly by ABRs on the path (which=20 > function has=20 > > composite PCEs) , or on external PCEs contacted by the ABRs on the=20 > > path, consists in fact of a simple concatenation of intra=20 > area paths. > > It actually only implies intra-area path computations and does not=20 > > allow computing inter-area optimal paths. Hence this mode is not=20 > > discussed in this document. " > >=20 > >> hence, the questions are > >>=20 > >> o) do we need to address this case (imho: yes) > >=20 > > Yes this should be address, but, as explained in the draft in this=20 > > case PCEs perform intra-area path computation, so this is=20 > not strictly=20 > > speaking an inter-area path computation application... > >=20 > >> o) do we need a separate document to address this case=20 > (the question=20 > >> is probably yes concerning the specific RSVP-TE processing during=20 > >> path establishment but is there a need to describe corresponding=20 > >> requirements in a dedicated document or could we make use of the=20 > >> "generic" document suggested by Jean-Louis) ? > >=20 > > To me this is an intra-area path computation issue, and this should=20 > > not be covered in this ID. > >=20 > > By the way do you see, with this application, any specific=20 > requirement=20 > > for the PCECP, not already covered in the generic ID?? >=20 > the specific requirement in this case would be the PCE=20 > selection along the signaled path, by default the PCE is=20 > driven by the local policy (that by default may perform=20 > selection of the local computation engine) and optionally the=20 > ERO may include a subobject indicating which PCE may be=20 > contacted for further expanding the path=20 These are interesting points but related to PCE selection, and actually = out of the scope of the PCECP...=20 Here I was asking for PCECP requirements... >- the reason for=20 > this is that the ingress may be in a position to perform such=20 > selection from the initial request rather than leaving the=20 > intermediate LSR performing this selection >=20 > but as i read your e-mail it is "yes, but not in this=20 > document" hence the question remains shall we bring this back=20 > to CCAMP to complete the RSVP extensions ? More generally some PCE applications will require RSVP-TE extensions. Here you give a potential example. Another example, could be the support = of path confidentiality in an inter-provider context. In this case the = computed path may, for instance, comprise of cookies identifying the = computed intra-provider path segments along with the IDs of the = corresponding PCEs. This would require RSVP-TE extensions to carry these = PCE ids and path cookies within the ERO, and this would also address = your point by the way. Where should these extensions be worked out in an other issue, and I = will let the chairs answer. Actually the answser seems to be in the PCE charter: "- In cooperation with protocol specific Working Group (OSPF, ISIS, IDR, MPLS, CCAMP), development of routing (OSPF, ISIS, BGP) and LSP signaling (RSVP-TE) extensions required to support PCE-based path computation models." Thanks for this discussion. Best Regards, JL >=20 > > Also note that RSVP-TE procedures for such coupled computation are=20 > > described in draft-ietf-ccamp-inter-domain-pd-path-comp... >=20 > i sent an e-mail to the list concerning this document last=20 > october and i would like to see what the revision will look=20 > like before further stating this document is the right place=20 > for documenting the above >=20 > thanks, > - dimitri. >=20 > > Regards, > >=20 > > JL > >=20 > >=20 > >> opinions appreciated. > >>=20 > >> thanks, - dimitri. > >>=20 > >> _______________________________________________ Pce mailing list=20 > >> Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce > >>=20 > >=20 > >=20 > > . > >=20 >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Nov 21 08:50:03 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeC3X-0005Jy-5R; Mon, 21 Nov 2005 08:50:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeC3V-0005Jl-6E for pce@megatron.ietf.org; Mon, 21 Nov 2005 08:50:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01230 for ; Mon, 21 Nov 2005 08:49:24 -0500 (EST) Received: from kanfw1.ottawa.alcatel.ca ([192.75.23.69] helo=tm3.ca.alcatel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeCLu-0003Tg-Rx for pce@ietf.org; Mon, 21 Nov 2005 09:09:06 -0500 Received: from CAOTTN03070 (localhost [127.0.0.1]) by tm3.ca.alcatel.com (8.13.0/8.13.0) with ESMTP id jALDnh9B019178; Mon, 21 Nov 2005 08:49:43 -0500 (EST) Message-Id: <200511211349.jALDnh9B019178@tm3.ca.alcatel.com> From: "Andrew Dolganow" To: "'Adrian Farrel'" , Subject: RE: [Pce] Working group next steps for protocols Date: Mon, 21 Nov 2005 08:49:42 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-reply-to: <004601c5ec5b$97159400$8fdf6f8a@Puppy> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: AcXsW00fvL5RYp/dTfS0V7soJc78nACRwT1w X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 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 Yes to both. Andrew > -----Original Message----- > From: pce-bounces@lists.ietf.org > [mailto:pce-bounces@lists.ietf.org] On Behalf Of Adrian Farrel > Sent: Friday, November 18, 2005 11:14 AM > To: pce@ietf.org > Subject: [Pce] Working group next steps for protocols > > Hi, > > Following up from the Vancouver meeting (per the meeting > report) I would like your opinion on the following actions. > > 1. Discovery solutions work. > The meeting had good support for adopting > draft-leroux-pce-disco-proto-igp-00.txt as a Working Group > draft to provide IGP-based solutions for PCE discovery. > > What is your opinion on this becoming a WG draft? > > 2. PCE Communications Protocol > The Vancouver meeting discussed both the process of selecting > a PCECP and the candidate protocol (PCEP) described in > draft-vasseur-pce-pcep-02.txt. > The mood of the meeting was that PCEP should be worked on > within the working group, and there was no objection to this > becoming a WG draft. > > What is your opinion on this becoming a WG draft? > > Thanks, > Adrian > > > _______________________________________________ > 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 Nov 21 13:27:19 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeGNr-00078J-8e; Mon, 21 Nov 2005 13:27:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeGNq-00078E-HJ for pce@megatron.ietf.org; Mon, 21 Nov 2005 13:27:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20533 for ; Mon, 21 Nov 2005 13:26:40 -0500 (EST) Received: from mail.infinera.com ([216.193.238.48] helo=EXCHANGE.infinera.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeGgK-0003Aj-L0 for pce@ietf.org; Mon, 21 Nov 2005 13:46:25 -0500 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] Working group next steps for protocols Date: Mon, 21 Nov 2005 10:26:51 -0800 Message-ID: Thread-Topic: [Pce] Working group next steps for protocols Thread-Index: AcXsW0hCPCo1rHFSQmC3AicFSLplYQCbY1lQ From: "George Frank" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 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 Yes to both. George > -----Original Message----- > From: pce-bounces@lists.ietf.org [mailto:pce-bounces@lists.ietf.org] On > Behalf Of Adrian Farrel > Sent: Friday, November 18, 2005 8:14 AM > To: pce@ietf.org > Subject: [Pce] Working group next steps for protocols >=20 > Hi, >=20 > Following up from the Vancouver meeting (per the meeting report) I would > like your opinion on the following actions. >=20 > 1. Discovery solutions work. > The meeting had good support for adopting > draft-leroux-pce-disco-proto-igp-00.txt as a Working Group draft to > provide IGP-based solutions for PCE discovery. >=20 > What is your opinion on this becoming a WG draft? >=20 > 2. PCE Communications Protocol > The Vancouver meeting discussed both the process of selecting a PCECP and > the candidate protocol (PCEP) described in draft-vasseur-pce-pcep-02.txt. > The mood of the meeting was that PCEP should be worked on within the > working group, and there was no objection to this becoming a WG draft. >=20 > What is your opinion on this becoming a WG draft? >=20 > Thanks, > Adrian >=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 Tue Nov 22 05:50:58 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeVjm-0003x5-FO; Tue, 22 Nov 2005 05:50:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeVjk-0003wx-94 for pce@megatron.ietf.org; Tue, 22 Nov 2005 05:50:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01465 for ; Tue, 22 Nov 2005 05:50:18 -0500 (EST) Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeW2M-0003gu-9R for pce@ietf.org; Tue, 22 Nov 2005 06:10:12 -0500 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id jAMAopG5002630 for ; Tue, 22 Nov 2005 19:50:51 +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 jAMAooLI002450 for ; Tue, 22 Nov 2005 19:50:50 +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 jAMAonmL002441 for ; Tue, 22 Nov 2005 19:50:50 +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 jAMAonqJ001092 for ; Tue, 22 Nov 2005 19:50:49 +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 jAMAonqQ001088 for ; Tue, 22 Nov 2005 19:50:49 +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 jAMAomLL021895 for ; Tue, 22 Nov 2005 19:50:48 +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 jAMAoaVx008731 for ; Tue, 22 Nov 2005 19:50:36 +0900 (JST) Received: from imc.m.ecl.ntt.co.jp (imc.m.ecl.ntt.co.jp [129.60.5.227]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id jAMAoZnN008727; Tue, 22 Nov 2005 19:50:35 +0900 (JST) Received: from win-yasukawa.lab.ntt.co.jp ([129.60.80.227]) by imc.m.ecl.ntt.co.jp (8.13.4/8.13.4) with ESMTP id jAMAoWKA011737; Tue, 22 Nov 2005 19:50:33 +0900 (JST) Message-Id: <5.0.2.5.2.20051122200640.084f9520@imc.m.ecl.ntt.co.jp> X-Sender: sy003@imc.m.ecl.ntt.co.jp X-Mailer: QUALCOMM Windows Eudora Version 5.0.2-J Date: Tue, 22 Nov 2005 20:09:39 +0900 To: pce@ietf.org From: Seisho Yasukawa Subject: Re: [Pce] Working group next steps for protocols In-Reply-To: <200511211712.jALHC7ae005823@tama3.tas.ntt.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: yasukawa.seisho@lab.ntt.co.jp 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 support both of following drafts to be WG drafts. Seisho > > -----Original Message----- > > From: pce-bounces@lists.ietf.org > > [mailto:pce-bounces@lists.ietf.org] On Behalf Of Adrian Farrel > > Sent: Friday, November 18, 2005 11:14 AM > > To: pce@ietf.org > > Subject: [Pce] Working group next steps for protocols > > > > Hi, > > > > Following up from the Vancouver meeting (per the meeting > > report) I would like your opinion on the following actions. > > > > 1. Discovery solutions work. > > The meeting had good support for adopting > > draft-leroux-pce-disco-proto-igp-00.txt as a Working Group > > draft to provide IGP-based solutions for PCE discovery. > > > > What is your opinion on this becoming a WG draft? > > > > 2. PCE Communications Protocol > > The Vancouver meeting discussed both the process of selecting > > a PCECP and the candidate protocol (PCEP) described in > > draft-vasseur-pce-pcep-02.txt. > > The mood of the meeting was that PCEP should be worked on > > within the working group, and there was no objection to this > > becoming a WG draft. > > > > What is your opinion on this becoming a WG draft? > > > > Thanks, > > Adrian > > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Nov 24 06:53:59 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfFfr-000715-6n; Thu, 24 Nov 2005 06:53:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfFfn-0006zA-4X for pce@megatron.ietf.org; Thu, 24 Nov 2005 06:53:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19676 for ; Thu, 24 Nov 2005 06:53:13 -0500 (EST) Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EfFyp-0001Ot-Jc for pce@ietf.org; Thu, 24 Nov 2005 07:13:36 -0500 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by ranger.systems.pipex.net (Postfix) with ESMTP id 3D0D2E000282; Thu, 24 Nov 2005 11:53:35 +0000 (GMT) Received: from Puppy ([217.158.132.155] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 24 Nov 2005 11:46:23 +0000 Message-ID: <004801c5f0ed$2d089620$9b849ed9@Puppy> From: "Adrian Farrel" To: References: <004601c5ec5b$97159400$8fdf6f8a@Puppy> Date: Thu, 24 Nov 2005 11:47:29 -0000 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-OriginalArrivalTime: 24 Nov 2005 11:46:26.0181 (UTC) FILETIME=[B358B350:01C5F0EC] X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: Subject: [Pce] Working group next steps for protocols 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 OK, We seem to have consensus to move ahead with these two I-Ds. Editors, please submit: draft-leroux-pce-disco-proto-igp-00.txt as draft-ietf-pce-disco-proto-igp-00.txt draft-vasseur-pce-pcep-02.txt as draft-ietf-pce-pcep-00.txt Please make no changes to the I-Ds except for the document names and the dates. As soon as these are published, I would like you to be sure to address the questions recently raised on the mailing list and in Vancouver. Thanks, Adrian _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Nov 24 11:10:46 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfJgM-000717-79; Thu, 24 Nov 2005 11:10:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfJgK-000712-NQ for pce@megatron.ietf.org; Thu, 24 Nov 2005 11:10:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21544 for ; Thu, 24 Nov 2005 11:10:03 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EfJzQ-0004he-Aa for pce@ietf.org; Thu, 24 Nov 2005 11:30:28 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 24 Nov 2005 11:10:36 -0500 X-IronPort-AV: i="3.97,373,1125892800"; d="scan'208,217"; a="76452365:sNHT38345912" 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 jAOGAXdr006826; Thu, 24 Nov 2005 11:10:33 -0500 (EST) 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, 24 Nov 2005 11:10:33 -0500 Received: from [192.168.1.101] ([10.86.240.101]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 24 Nov 2005 11:10:32 -0500 Mime-Version: 1.0 (Apple Message framework v734) References: <69E83372-63B6-4777-AF5E-699E763D79C6@cisco.com> Message-Id: <473DF480-144B-428E-A47D-3A15F1FD7B40@cisco.com> From: JP Vasseur Subject: Fwd: [Pce] New Working Group documents Date: Thu, 24 Nov 2005 11:10:02 -0500 To: pce@ietf.org X-Mailer: Apple Mail (2.734) X-OriginalArrivalTime: 24 Nov 2005 16:10:32.0750 (UTC) FILETIME=[98A33CE0:01C5F111] X-Spam-Score: 0.2 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 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="===============0862486927==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org --===============0862486927== Content-Type: multipart/alternative; boundary=Apple-Mail-7--77420299 --Apple-Mail-7--77420299 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Authors, please publish: (1) draft-oki-pce-inter-layer-req, (2) draft-leroux-pce-pcecp-inter-area-reqs as WG document with no change but the name and date. Thanks to follow up with the action points related to (2). Cheers, JP. Begin forwarded message: > From: JP Vasseur > Date: November 10, 2005 11:13:08 AM EST > To: pce@ietf.org > Subject: [Pce] New Working Group documents > > > Dear WG, > > There was clear consensus to adopt the two following IDs as WG > document during our last meeting in Vancouver: > (1) draft-oki-pce-inter-layer-req, > (2) draft-leroux-pce-pcecp-inter-area-reqs > > Both drafts require more work and comments should be addressed in > further revisions. > > As usual let's confirm on the list. > > In the absence of objection, these two documents will be accepted > as WG document in two weeks from now (November 24th). > > JP and Adrian. > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > --Apple-Mail-7--77420299 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Authors,=A0

please = publish:

=A0=A0= =A0(1) draft-oki-pce-inter-layer-req,
=A0=A0 =A0(2) = draft-leroux-pce-pcecp-inter-area-reqs

as WG document=A0with no = change but the name and date.

Thanks to follow up with = the action points related to (2).

Cheers,

JP.

B= egin forwarded message:

From: = JP Vasseur <jvasseur@cisco.com>
=
Date: = November 10, 2005 11:13:08 AM EST
Subject: = [Pce] New Working Group documents


Dear = WG,

There was clear consensus to adopt the two following = IDs as WG document during our last meeting in Vancouver:
=A0 =A0 = (1) draft-oki-pce-inter-layer-req,
=A0 =A0 (2) = draft-leroux-pce-pcecp-inter-area-reqs

Both drafts = require more work and comments should be addressed in further = revisions.

As usual let's confirm on the list.

In the = absence of objection, these two documents will be accepted as WG = document in two weeks from now (November 24th).

JP and = Adrian.

Pce mailing list


= --Apple-Mail-7--77420299-- --===============0862486927== 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 --===============0862486927==-- From pce-bounces@lists.ietf.org Fri Nov 25 10:00:42 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eff46-0005Jh-8K; Fri, 25 Nov 2005 10:00:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Efeug-0007Ni-26; Fri, 25 Nov 2005 09:50:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03524; Fri, 25 Nov 2005 09:50:17 -0500 (EST) 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 1EffDv-0000y2-9B; Fri, 25 Nov 2005 10:10:53 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 25 Nov 2005 06:50:46 -0800 X-IronPort-AV: i="3.97,377,1125903600"; d="scan'208,217"; a="678513587:sNHT38783728" 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 jAPEogs2026561; Fri, 25 Nov 2005 06:50:42 -0800 (PST) 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, 25 Nov 2005 09:50:41 -0500 Received: from [192.168.1.101] ([10.86.240.101]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 25 Nov 2005 09:50:40 -0500 Mime-Version: 1.0 (Apple Message framework v734) To: ccamp@ops.ietf.org, mpls@ietf.org, idr@ietf.org, Mailing List , isis-wg@ietf.org, pce@ietf.org Message-Id: <43CEE596-A350-4883-A85E-A889F5DC4FEC@cisco.com> From: JP Vasseur Date: Fri, 25 Nov 2005 09:50:08 -0500 X-Mailer: Apple Mail (2.734) X-OriginalArrivalTime: 25 Nov 2005 14:50:40.0769 (UTC) FILETIME=[9ACEB710:01C5F1CF] X-Spam-Score: 0.7 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac X-Mailman-Approved-At: Fri, 25 Nov 2005 10:00:40 -0500 Cc: "David Kessens \(E-mail\)" , Bill Fenner , "Bert \(Bert\) Wijnen" , "raymond.zhang" Subject: [Pce] Discussion on Multi-technology protection/restoration schemes 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="===============0752658541==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org --===============0752658541== Content-Type: multipart/alternative; boundary=Apple-Mail-17-4186124 --Apple-Mail-17-4186124 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Dear WGs, Raymond Zhang, Jean-Louis Le Roux and myself have been discussing for a while about the idea of the formation of a new Working Group at the IETF (under the OPS area) in order to discuss operational issues related to the use of multi-technologies in the context of protection/ restoration. This was motivated by a number of discussions that we had with Service Providers expressing some interest in this topic. For the sake of illustration, (1) How to use Fast IGP in conjunction with MPLS TE FRR ? (2) How to use Graceful Restart with Fast IGP or IPFRR ? (3) Multi-technology protection/restoration OAM - ... Indeed, there are many cases where such protection/restoration/HA technologies may interact thus triggering potential race conditions if not used appropriately. The aim of such potential Working Group would be to discuss these issues, document deployment models, ... and potentially come up with problem statements leading to new protocol requirements. Note that the goal of such WG would NOT be to work on protocol extensions but to analyze the problems statements, document combination strategies, ... Protocol extensions would be worked out in other WGs (likely in Routing area). We had a first informal meeting in Vancouver with: Bruno Decraene (FT), Eiji Oki (NTT), Yuichi Ikejiri (NTT), Kenji Kumaki (KDDI), Javier Achirica (Telefonica), Deborah Brungard (ATT), Jaime Miles (Level 3) and Alberto Tempia (Telecom Italia), Jean-Louis and myself. In this meeting, we got positive feed-back on the usefulness of this work. In the meantime we also received positive feed-back from a number of other Service Providers. A short ID should be posted soon proposing a problem statement. The OPS Area Directors (Bert and David) gave us the approval to create a mailing list to see whether this topic is of interest to the IETF community in which case a BOF may be approved for the next IETF. If you are interested, please join the mailing list and contribute to this work. mter@ietf.org: https://www1.ietf.org/mailman/listinfo/mter Thanks. JP, Jean-Louis and Raymond. --Apple-Mail-17-4186124 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear WGs,

Raymond = Zhang, Jean-Louis Le Roux and myself have been discussing for a while = about the idea of the formation of a new Working Group at the IETF = (under the OPS area) in order to discuss operational issues related to = the use of multi-technologies in the context of protection/restoration. = This was motivated by a number of discussions that we had with Service = Providers expressing some interest in this topic.=A0

For the sake = of illustration,
=A0 =A0 (1)=A0How to use Fast = IGP in conjunction with MPLS TE FRR ?
=A0 =A0 = (2)=A0How to use Graceful Restart with Fast IGP or IPFRR ?
=A0=A0=A0 (3)=A0Multi-technology = protection/restoration OAM=A0
=A0=A0 =A0 - = ...

Indeed, = there are many cases where such protection/restoration/HA technologies = may interact thus triggering potential race conditions if not used = appropriately.=A0

The aim of such potential Working Group would = be to discuss these issues, document deployment models, ... and = potentially come up with problem statements leading to new protocol = requirements. Note that the goal of such WG would NOT be to work on = protocol extensions but to analyze the problems statements, document = combination strategies, ... Protocol extensions would be worked out = in other WGs (likely in Routing area).

We had a = first informal meeting in Vancouver with: Bruno Decraene (FT), Eiji Oki = (NTT), Yuichi Ikejiri (NTT), Kenji Kumaki (KDDI), Javier Achirica = (Telefonica), Deborah Brungard (ATT), Jaime Miles (Level 3) and Alberto = Tempia (Telecom Italia), Jean-Louis and myself. In this meeting, we got = positive feed-back on the usefulness of this work.=A0

In the = meantime we also received positive feed-back from a number of other = Service Providers.

A short = ID should be posted soon proposing a problem statement.

The OPS Area = Directors (Bert and David) gave us the approval to create a mailing list = to see whether this topic is of interest to the IETF community in which = case a BOF may be approved for the next IETF. If you are interested, = please join the mailing list and contribute to this work.
=A0=A0=A0 mter@ietf.org:=A0<= A href=3D"https://www1.ietf.org/mailman/listinfo/mter">https://www1.ietf.org/mailman/listinfo/mter


JP, = Jean-Louis and Raymond.
= --Apple-Mail-17-4186124-- --===============0752658541== 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 --===============0752658541==-- From pce-bounces@lists.ietf.org Fri Nov 25 12:57:40 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfhpM-0008Pn-6E; Fri, 25 Nov 2005 12:57:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EffZL-0008OG-KU; Fri, 25 Nov 2005 10:32:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08125; Fri, 25 Nov 2005 10:32:18 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Effsc-0002bm-Ku; Fri, 25 Nov 2005 10:52:55 -0500 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 25 Nov 2005 16:32:49 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jAPFWhAT021375; Fri, 25 Nov 2005 16:32:44 +0100 (MET) Received: from [10.61.81.249] (ams-clip-vpn-dhcp4602.cisco.com [10.61.81.249]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id PAA04671; Fri, 25 Nov 2005 15:32:35 GMT Message-ID: <43872E92.2090600@cisco.com> Date: Fri, 25 Nov 2005 15:32:34 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: JP Vasseur Subject: Re: [Pce] Discussion on Multi-technology protection/restoration schemes References: <43CEE596-A350-4883-A85E-A889F5DC4FEC@cisco.com> In-Reply-To: <43CEE596-A350-4883-A85E-A889F5DC4FEC@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 25 Nov 2005 12:57:38 -0500 Cc: ccamp@ops.ietf.org, mpls@ietf.org, "David Kessens \(E-mail\)" , pce@ietf.org, isis-wg@ietf.org, idr@ietf.org, Bill Fenner , "Bert \(Bert\) Wijnen" , "raymond.zhang" , Mailing List 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 > Raymond Zhang, Jean-Louis Le Roux and myself have been discussing for > a while about the idea of the formation of a new Working Group at the > IETF (under the OPS area) in order to discuss operational issues > related to the use of multi-technologies in the context of > protection/restoration. This was motivated by a number of discussions > that we had with Service Providers expressing some interest in this > topic. > > For the sake of illustration, > (1) How to use Fast IGP in conjunction with MPLS TE FRR ? > (2) How to use Graceful Restart with Fast IGP or IPFRR ? > (3) Multi-technology protection/restoration OAM > - ... Would the wider application of loop-free IGP convergence as described in http://www.ietf.org/internet-drafts/draft-bryant-shand-lf-applicability-00.txt be in scope? - Stewart _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Sat Nov 26 09:24:54 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eg0z0-0007OY-JD; Sat, 26 Nov 2005 09:24:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfjSG-0003iP-PH for pce@megatron.ietf.org; Fri, 25 Nov 2005 14:41:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08192; Fri, 25 Nov 2005 14:41:14 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EfjlW-0003Fg-0V; Fri, 25 Nov 2005 15:01:55 -0500 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1EfjRz-0006rG-1X; Fri, 25 Nov 2005 14:41:39 -0500 Content-Type: text/plain Mime-Version: 1.0 To: jpv@cisco.com, adrian@olddog.co.uk From: Greg Jones(ITU-T SG 15) Message-Id: Date: Fri, 25 Nov 2005 14:41:39 -0500 X-Spam-Score: 1.9 (+) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-Mailman-Approved-At: Sat, 26 Nov 2005 09:24:52 -0500 Cc: sjtrowbridge@lucent.com, greg.jones@itu.int, maeda@ansl.ntt.co.jp, fenner@research.att.com, statements@ietf.org, hklam@lucent.com, sob@harvard.edu, pce@ietf.org, tsbsg15@itu.int, betts01@nortel.com, Subject: [Pce] Submission of New Liaison Statement, "Liaison Statement to IETF PCE WG" 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 Title: Liaison Statement to IETF PCE WG Submission Date: 2005-11-25 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=152 From: Greg Jones(ITU-T SG 15) To: IETF PCE WG(jpv@cisco.com, adrian@olddog.co.uk) Cc: sob@harvard.edu fenner@research.att.com zinin@psg.com pce@ietf.org maeda@ansl.ntt.co.jp sjtrowbridge@lucent.com hklam@lucent.com betts01@nortel.com tsbsg15@itu.int Reponse Contact: tsbsg15@itu.int greg.jones@itu.int Technical Contact: hklam@lucent.com; betts01@nortel.com; Purpose: For information Body: Thank you for your positive response to our previous liaison statement. We look forward to continued cooperation on this work. As a result of the comments in your liaison statement we have drafted text to modify G.8080 that we plan to consent at the February 2006 meeting of SG 15. We have added a second route query interface to the routing controller component. This allows a routing controller to consult other routing controllers to resolve a route. We have also indicated that a routing controller component can contain either a path computation function, a routing database or both. These constructs were already present in G.7715.1. We believe that the ASON architecture is now aligned with your work on PCE. We would appreciate being kept informed on this topic. Attachment(s): Liaison Statement to IETF PCE WG (https://datatracker.ietf.org/documents/LIAISON/file209.doc) _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Sat Nov 26 09:24:54 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eg0z0-0007Ox-QU; Sat, 26 Nov 2005 09:24:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Efjb9-0008QR-Iz for pce@megatron.ietf.org; Fri, 25 Nov 2005 14:51:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09152; Fri, 25 Nov 2005 14:50:26 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EfjuT-0003ZS-R9; Fri, 25 Nov 2005 15:11:06 -0500 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1Efjb5-00035E-QI; Fri, 25 Nov 2005 14:51:03 -0500 Content-Type: text/plain Mime-Version: 1.0 To: jpv@cisco.com, adrian@olddog.co.uk From: Greg Jones(ITU-T SG 15) Message-Id: Date: Fri, 25 Nov 2005 14:51:03 -0500 X-Spam-Score: 1.9 (+) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id OAA09152 X-Mailman-Approved-At: Sat, 26 Nov 2005 09:24:52 -0500 Cc: , greg.jones@itu.int, maeda@ansl.ntt.co.jp, sjtrowbridge@lucent.com, fenner@research.att.com, statements@ietf.org, hklam@lucent.com, sob@harvard.edu, pce@ietf.org, tsbsg15@itu.int Subject: [Pce] Submission of New Liaison Statement, "ASON-related Work" 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 Title: ASON-related Work Submission Date: 2005-11-25 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_det= ail.cgi?detail_id=3D153=20 Please reply by 2006-01-27 From: Greg Jones(ITU-T SG 15) To: ASON-related Work(jpv@cisco.com, adrian@olddog.co.uk) Cc: sob@harvard.edu; fenner@research.att.com; zinin@psg.com; pce@ietf.org= ; maeda@ansl.ntt.co.jp; sjtrowbridge@lucent.com; Reponse Contact: tsbsg15@itu.int greg.jones@itu.int Technical Contact: hklam@lucent.com Purpose: For action=20 Body: ITU Q14/15 would like to bring the following comments on IETF CCAMP= =E2=80=99s ASON-related work to the attention of IETF CCAMP WG: 1. Q14/15 has been monitoring the work on ASON routing solutions, and str= ongly supports CCAMP=E2=80=99s continued work to address ASON requirement= s in the routing protocols. We have noted the new draft (draft-dimitri-c= camp-ason-routing-sol-00.txt) and generally support its directions, altho= ugh the draft is still incomplete at this time. Q14/15 requests that fut= ure working group drafts on this topic be liaised to Q14/15 for their inf= ormation and comment. 2. Q14/15 have also noted the work on ASON signaling solutions taking pla= ce in CCAMP. We understand that this work diverges in many respects from= the solutions defined in ITU-T Recommendation G.7713.2. Q14/15 continue= s to be interested in collaboratively exploring any opportunities for con= vergence of signaling solutions, as previously stated in our Liaison of F= ebruary 2004, and to that end request that CCAMP continue liaison with Q.= 14/15 regarding any future signaling efforts that are ASON-related. In general, it is requested that CCAMP notify Q.14/15 when ASON-related d= rafts are nearing completion. While some members of Q14/15 have particip= ated in CCAMP activities such as joint design teams, their participation = does not constitute agreement of Q14/15 itself with the output. We strong= ly suggest that CCAMP liaises such documents to ITU for review prior to p= ublishing as an RFC (for example, just preceding or following WG Last Cal= l), in order to ensure continued mutual understanding of the requirements. Note: This liaison is sent with an action date of January 27, 2006 in ord= er to allow for any liaisons to be discussed at the February meeting of I= TU-T SG15. Attachment(s): ASON-related Work (https://datatracker.ietf.org/documents/LIAISON/fi= le210.doc) _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue Nov 29 18:50:16 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhFEm-0000yd-Et; Tue, 29 Nov 2005 18:50:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhFEZ-0000t8-Iz; Tue, 29 Nov 2005 18:50:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26529; Tue, 29 Nov 2005 18:49:17 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhFYj-00023b-Fb; Tue, 29 Nov 2005 19:10:53 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EhFEX-0007Nb-Si; Tue, 29 Nov 2005 18:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 29 Nov 2005 18:50:01 -0500 X-Spam-Score: 0.4 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-pcep-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 : Path Computation Element (PCE) communication Protocol (PCEP) - Version 1 - Author(s) : J. Vasseur, et al. Filename : draft-ietf-pce-pcep-00.txt Pages : 48 Date : 2005-11-29 This document specifies the Path Computation Element communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between two PCEs. Such interactions include path computation requests and path computation replies as well as notifications of specific states related to the use of a PCE in the context of MPLS and GMPLS Traffic Engineering. The PCEP protocol is designed to be flexible and extensible so as to easily allow for the addition of further messages and objects, should further requirements be expressed in the future. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-pcep-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-pcep-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-pcep-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-11-29163549.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pce-pcep-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pce-pcep-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-11-29163549.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 Nov 29 18:50:19 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhFEp-0000zp-IT; Tue, 29 Nov 2005 18:50:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhFEc-0000uo-0B; Tue, 29 Nov 2005 18:50:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26548; Tue, 29 Nov 2005 18:49:19 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhFYm-000245-FH; Tue, 29 Nov 2005 19:10:56 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EhFEY-0007Nv-0L; Tue, 29 Nov 2005 18:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 29 Nov 2005 18:50:02 -0500 X-Spam-Score: 0.4 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-inter-layer-req-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 : PCC-PCE Communication Requirements for Inter-Layer Traffic Engineering Author(s) : E. Oki Filename : draft-ietf-pce-inter-layer-req-00.txt Pages : 10 Date : 2005-11-29 The Path Computation Element (PCE) provides functions of path computation in support of traffic engineering in Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. MPLS and GMPLS networks may be constructed from layered service networks. It is advantageous for overall network efficiency to provide end-to-end traffic engineering across multiple network layers. PCE is a candidate solution for such requirements. Generic requirements for a communication protocol between Path Computation Clients (PCCs) and PCEs are presented in "PCE Communication Protocol Generic Requirements". This document complements the generic requirements and presents a detailed set of PCC-PCE communication protocol requirements for inter-layer traffic engineering. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-inter-layer-req-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-inter-layer-req-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-inter-layer-req-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-11-29164941.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pce-inter-layer-req-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pce-inter-layer-req-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-11-29164941.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 Wed Nov 30 15:50:36 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhYuS-0001YH-HV; Wed, 30 Nov 2005 15:50:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhYtw-0001Al-JO; Wed, 30 Nov 2005 15:50:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11368; Wed, 30 Nov 2005 15:49:19 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhZEG-0002eK-TP; Wed, 30 Nov 2005 16:11:05 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EhYtu-0006st-Af; Wed, 30 Nov 2005 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 30 Nov 2005 15:50:02 -0500 X-Spam-Score: 0.4 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-disco-proto-igp-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 : IGP protocol extensions for Path Computation Element (PCE) Discovery Author(s) : J. Le Roux, et al. Filename : draft-ietf-pce-disco-proto-igp-00.txt Pages : 26 Date : 2005-11-30 In various situations it would be highly useful for a Path Computation Client (PCC) to be able to dynamically and automatically discover a set of Path Computation Element(s) (PCE), along with some of information relevant for PCE selection. When the PCE is an LSR participating to the IGP, or even a server participating passively to the IGP, a simple and efficient way for PCE discovery, consists of relying on IGP flooding. For that purpose this document defines simple OSPF and ISIS extensions for the advertisement of PCE Discovery information within and across IGP areas. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-disco-proto-igp-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-disco-proto-igp-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-disco-proto-igp-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-11-30122112.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pce-disco-proto-igp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pce-disco-proto-igp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-11-30122112.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--