From pce-bounces@ietf.org Thu Sep 2 19:03:26 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21034; Thu, 2 Sep 2004 19:03:25 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C30eW-0000up-KW; Thu, 02 Sep 2004 19:06:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C30aT-0000EE-8r; Thu, 02 Sep 2004 19:01:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C30Rg-0002yg-BJ for pce@megatron.ietf.org; Thu, 02 Sep 2004 18:52:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20462 for ; Thu, 2 Sep 2004 18:52:43 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C30U9-0008QW-62 for pce@ietf.org; Thu, 02 Sep 2004 18:55:18 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 02 Sep 2004 15:53:51 -0700 X-BrightmailFiltered: true Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i82Mq2RL021755; Thu, 2 Sep 2004 15:52:02 -0700 (PDT) Received: from jvasseur-w2k01.cisco.com (dhcp-10-86-162-120.cisco.com [10.86.162.120]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id PAA06613; Thu, 2 Sep 2004 15:52:04 -0700 (PDT) Message-Id: <4.3.2.7.2.20040902185100.0384dc90@wells.cisco.com> X-Sender: jvasseur@wells.cisco.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 02 Sep 2004 18:51:28 -0400 To: pce@ietf.org From: Jean Philippe Vasseur Mime-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 562e86ae4313685a38b49114a0f69210 Subject: [Pce] Fwd: PCE BOF minutes - IETF-60 - San Diego 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="===============0455761401==" Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1069eb5b3f212f2b9b575eaf2aff5119 --===============0455761401== Content-Type: multipart/alternative; boundary="=====================_206422399==_.ALT" --=====================_206422399==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi, Please forward any correction/addition you may want to make on the minutes. JP. >Date: Thu, 02 Sep 2004 10:30:40 -0400 >To: proceedings@ietf.org >From: Jean Philippe Vasseur >Subject: PCE BOF minutes - IETF-60 - San Diego >Cc: adrian@olddog.co.uk, zinin@psg.com, bill Fenner > >Minutes of the Path Computation Element BOF (pce) IETF-60 San Diego >############################################################# > >Chairs: JP Vasseur, Adrian Farrel >ADs: Alex Zinin, Bill Fenner > >*thanks to Dave Ward and Don Fedyk for their help taking notes* > >1) Agenda bashing, Admin and objectives - Adrian >********************************************************** > >2) Overview of PCE-based path computation - JP >********************************************************* >What is the BoF about ? What do we mean by PCE ? >PCE is an entity capable of compositing a path. Mainly we mean MPLS TE for >now but could expand to other (IP paths). >If you are computing a path for a loose hop you are a PCE. PCE examples: >Router, LSR, Server. >PCE is just an entity capable of doing some computation >Does not require centralized path computation. PCE can do distributed >computation. >One View: Each router is a PCE for it neighbors. >Could have a PCE where global optimization is required >Could be completely stateless or stateful >PCE approach is not necessarily the only approach but one approach >PCE suits a number of problem spaces. >Highlighting that PCE can be centralized or distributed model and need both > >3) Requirements for PCE-based path computation (30 minutes) Raymond >(Infonet), Kenji (KDDI), Jean-Louis (France Telecom), Seisho (NTT), Jerry >(ATT), Javier (Telefonica), Venkata (MCI) > >Raymond Zhang, Infonet >Case customer wants a guaranteed path that is delay sensitive. Problem is >there is high interconnect multi domain. Want to select paths with a high >degree of control. > >Kenji Kumaki, KDDI >Multi AS inter SP, Shortest end to end, Re-optimization, Multi IGP areas, >Re-optimization. These are difficult problems to solve. Scalability issues >with Routing and Signaling. > >Jean Louis Le Roux, France Telecom >Head end is sufficient for most., Complex routing conditions for P2 MP. >Multi constraint Backup Path. Inter domain path computation. Diverse path >computation. Could benefit from path computation element. Dedicated tool, >Centralized, Collaborative Useful for backup. > >High level requirements: Reliable signaling protocol, Automatic discovery, >Scalability, Balance the computational load, Distribute PCE function, High >Availability, Robustness. > >Question Dimitri Papadimitriou: is list detailing the PCE to PCE signaling? >JP: Yes >Dimitri: So 1st bullet is client to server signaling relationship? >JP: Yes good point load share requests but also need case where paths are >dependent on one another. > >Jerry Ash, AT&T >Requirements: Migrating to converged Network. >IP MPLS and all TDM to VoIP. These are the architecture plans, not >committed and being implemented. PCE is part of the plan. Inter area, very >large network need a solution that scales. Intra and inter AS. Need >shortest path across Network >Need standards based solution > >Seisho Yakukawa, NTT >Requirements: P2MP, IP-TV, Video, CPU intensive, P2MP, Inter-domain, Need >wider community, PCE approach is good. > >Arthi: PCE to PCE or LSR to PCE based on same protocols? >Adrian: Yet to be decided. Good Point. >Arthi :When we talk about signaling, is it query-reply or MPLS TE signaling? >JP: query-reply, no change to TE LSP signalling >Igor: Two types of signaling: are they the same ? >Adrian: This is what we are deciding. Please wait for this. >Dimitri: The issue I see is there need for synchronization. There is a >need for coordination. >Adrian: Yes that is what we are discussing >?? You are going to have a discussion part a the end >JP:Yes. >Bijan Jabbari : Are you asking in the context of MPLS? >JP: Yes. >Bijan: This is related to some specific application. >JP:Yes > >Venkata Josyula, MCI >Requirements: Multiple AS, Hierarchical AS and be able to build AS, Inter >area PCE.. >Inter AS: Need a simple solution. Not saying you can use BGP next hops. >Do need TE Policy. Like the flexibility to coexist with other approaches. >JP: Interesting question. PCE could be used for inter areas and BGP for >inter AS (AS path selection). This is an Interesting point. > >4) Functional requirements of a PCE-based path computation system - JP >*************************************************************************************** >Functional requirements: >Multiple Models Picture: >Centralized, >Cooperative model PCE for one [or more] parts of the path. >Distributed : Each node is a fully distributed PCE (example: Backup Tunnel >path comp). > >Discovery of the PCE in a network: >Static Provisioning >Dynamic discovery computing resource (load sharing between multiple PCEs) > >PCE may have routing adjacency with other nodes or may use some [other] >protocols) > >LSR-PCE Signaling: Interaction between the router and the PCE: RSVP, or >new protocol. Need to specify request and reply. > >Arthi: On slide are PCE red circles. Are these the only PCEs? >JP: No of course not. > From this figure each LSR is a PCE or does it talk to other PCEs? >Adrian: If you have an Abstract node or a loose path you are using a PCE. >Arthi: This picture is not necessary the only view. It is not mandatory. >JP: It can be a server or a router itself. >Bijan: It can be [LSR]{missed it} or higher level than that? >?? It would be useful to have distinction between PCEs. Implement a LSR >as a distributed machinery with PCE and share the network with the data >network. >JP: We can discuss this. >?? Many, many approaches. Distributed path computation. Information is not >synchronized. If you do it on several path computation elements. >Adrian: Yes that is a problem. Clearly diverse path. Clearly not produce >loops. >?? Signaling protocol soft state?. RSVP-TE sounds like a funny approach. >Will there be others? >Adrian: Yes 5 proposals already ... >Alex. Clarification on slides please. >Ina: Do you have model ? Does the PCE have to run routing or not? Type of >discovery mechanism are a direct result of the model. >JP :Yes it is dependent. >Ping Pan: Inter domain. Great one [requirement]. What is the best >algorithm? That is independent. How you communicate. COPS, RADIUS >DIAMETER. Cisco scripts overnight. >JP: Not sure what you are trying to clarify. >Ping: You are limited to data path signaling. >Alex: Is it local to the box or cooperative [across boxes]? >JP: Inter domain must be standardized to some extent to compute an >inter-domain shortest path and avoid loops. Intra not necessary. >Ping: Preventing loop is one thing. >Alex: Cut line hold to discussion. > >JP: Policy, Security, Confidentiality. > >Adrian: Not here to discuss drafts good bad or WG drafts. Just want to >expose the drafts. If you have questions please go to authors not to >microphone. > >????: Does the LSR have to be the PCE? >JP: No, it can be another box. >????: Can PCEs be out of band? >JP: At end of meeting >????: Can we use this to find diverse paths? Can we use this for >cooperative model? Are there loops formed? >JP: Yes for diverse paths, no to loops, yes to cooperative >Sue Hares: Does the PCE have to participate in routing? >JP - It can > >5) Current status of drafts (20 minutes) - Several >******************************************************** >Background and framework drafts 4 >Requirements draft 1 >PCE Discovery (see IDs in CCAMP, ISIS and OSPF WGs) >PCE signaling 3 drafts >Modified TE Flooding >Applications 2 drafts > >Quick walk through the drafts - Minor clarifications and comments > >JP: No time to discuss the draft in detail by the way, not the objective >of this BOF. > >draft-leroux-pce-backup-comp-frwk-00.txt Jean-Louis >Nurit Sprecher: What is what the assumption for failure? A single failure? >JL: Yes this is reasonable. All networks are done this way. >Nurit: For multiple failures? >JL: This is to present one model for example. > >draft-oki-pce-gmpls-req-00.txt, Eiji Oki >Two kinds of requirements >PCE requirement: GMPLS and MPLS >Functionally separated from MPLS NODE >Provider can choose appropriate implementation. >Centralized and distributed. >Multi region TE in GMPLS >Interworking between MPLS and GMPLS. > >Hierarchical LSP setup. >Trigger by higher level LSP setup. PCE helps GMPLS node to setup >hierarchical LSP. >PCE Triggered LSP should be supported. Treat as single region network from >higher level. Standard Opaque TE information. Nodal requirement >PCE two request modes: Mandatory mode, Normal request node can ask own >node or PCE. > >Solution drafts >****************** > >draft-oki-ccamp-gtep-00.txt, Eiji Oki >Generalized TE protocol GTEP. >Features: >Support trigger hierarchical LSP setup >Support TEDB synchronization >Reliable transfer of larger data based on TCP >GTEP running code > >draft-vasseur-mpls-computation-rsvp-05.txt, Alia Atlas: >Extensions to RSVP-TE >Extend RSVP-TE a bit between the head end and the PCE. >Most of the stuff is there. >Request and reply message. >Some additional objects. >Drafts consider a number of different scenarios. > >draft-choi-pce-e2e-centralized-restoration-srlg-00.txt, Jun Kyun >Centralized control from optical network and GMPLS 50 Ms constraint. >Logical Ring configuration based on SRLG and PCE >Compatible with ASON architecture SG-15 >Simplifies and reduces management. > >Bijan Jabbari: 50 msec requirement is driving control not feasible. >Jun: Where is the location of the central controller. The requirement is >there. > >IDs related to P2MP >LSR PCE signaling required could be part of a general PCE > >IDs under construction - JP > Requirements for signaling necessary > Quick overview of inter-domain QoS ID, Mohamed Boucadair >6) Discussion points, WG formation, possible goals and milestones? Adrian, JP >********************************************************************************************* >JP: We need to discuss where can we do the work, what the scope is: MPLS >or IP as well? > >Adrian: Multiple components: Do we need a protocol at all ? Resolving how? >Alex: Do we have a good understanding ? > >Bijan Jabbari: Note that there are requirements from research networks as >well as SPs for Path Computation and routing > >Alex: PCE computations? >Bijan: Yes. >????: LSR or something like that? >Bijan: In optical network very complex. Loops are a problem and problems >are usually N-P complete. Complex. Requires a PCE. > >JP: Let's discuss whether we need new protocols? > >Zafar Ali: There is evidence for PCE needs/desires. Yes we should be >working on this in the IETF. > >Mark Hanley: Is spectrum too big? New routing architecture is evident and >watch how far you want to go. > >Alex: Lots of requirements however, from an architecture point of view >there is confusion. Are we separating out some non-forwarding pieces. > >Someone from Korea: Is scope limited to MPLS TE? > >JP: It includes GMPLS > >Arthi: Clear that SPs require this. Server SPs already have some >mechanisms. People may already have some form of this functionality. How >are people are going to cooperate? Who will change? How much will existing >mechanism affect what we do? > >Adrian: You are saying even if this a good idea we are too late? We may be >too late - Service provider can say. If we come up with a different >protocol will this have impact? Do you have strong opinion? > >Arthi: Yes should be done, but where? Don't know. Cannot standardize >computation algorithms. Don't think so. Differentiates on PCE from [vendor >to vendor] > >Mohamed Boucadair, France Telecom: the PCE control plane and forwarding >plane. If you have one element for this PCE it and element that manages >your inter domain resources. Inter-provider not arguing for this. What we >need the protocol in two different domains. > >Dimitri: Does it cover co-located PCE. Should the PCE talk to elements of >different vendors? What are changes expected to communicate LSR<->PCE? How >far do we change RSVP? Please add requirements doc. Must have >interoperability cleared up - don't get this. What about scalability >problems of PCE once all TEDB are combined. > >Zafar: Offline tools already present but, SP doesn't like them or not. > >Dima: We know there is a need. IETF should take it on. There should be a >new WG. There needs to be clarity on PCE being w/in the LSR or if the PCE >should be a router to participate. > >Francois LeFechaur: Clear requirements. We should do it. > >Bora A: How you communicate to the router. Only Standardized. Co-located >PCE on the router no different than what you do today. Comp SNMP TCL >scripts and we need another algorithm. I think RSVP-TE approach may be the >way to go. > >Igor: I agree [with Bora]. Protocol only. Formidable task. Standardizing >constraints is tough. I do believe we need to review the architecture. >SNMP like protocol is a better choice. > >Bjian: Need some form of centralization? >Adrian: Support centralization but not mandated >JP Yes. First slide. >Bijan: Distributed as well? Need multiple computation algorithms in the >PCE. However that does not need to be standard. >Alex: We have some experience documenting algorithms. Kireeti did document >an algorithm but this went [no where]. This could be done as Informational > >Bijan - Is there centralization or not? There has to be both distributed >and centralized. > >Ina: Several people requirements and tools. Clear sign yes. Need for new >working group. Should PCE be part of an LSR or and independent element? > >Bora: Only thing that can be standardize is the communication, not >algorithms. Ok creating another WG but, there isn't a lot of work here. > >Igor: Only can standardize the communication between LSR and PCE. We need >the work, the WG and the architecture. Perhaps we should have a >configuration server like ATM. > >Richard Rabbat: Clearly requirements, take this on. Scope don't >standardize algorithm. Where. Stay in CCAMP. > >JP: Note that in some cases such as collaborative path computation, you >need to standardize algorithm to guarantee optimality (shortest path) and >prevent looping problems. > >Alia: We need signalling, we need architecture, we need resolve this, it >should not be CCAMP as that WG is swamped > >Hani: We should take on [new] WG > >Bruce Davie: Let's not standardize the algorithms but make sure we specify >it enough to make sure we don't have loops. Kireeti says that we should >use BGP. It should be a WG and w/in the IETF. > >Dimitri: The distributed model is difficult. Access of LSR to PCE. Next >hop path resolution protocol. Important aspect should determine what are >the based computation assumptions. Don't want one PCE then another PCE etc. > >Ping Pan: What is a domain? >Adrian: Have some input areas computation domain and protection >domains. Broad computation visibility. > >Summary >************ >Alex takes the mic: >Clearly there is a need >Clearly there is support for a solution >Confusion on what needs to be specified: communication, etc >Many requirements but quite diverse. Requirements good but so large. >What need to be standardized ? How this will affect the existing work ? >Tread very carefully and do architectural work so not to screw the internet >Heard strong opinion that we shouldn't standardize algorithms > >Steps >******** >Create mailing list - everyone will join >Need framework/arch doc(s) >Need to reduce requirements and present what will be covered >If we have something more complete by the next meting we will need another >BOF. --=====================_206422399==_.ALT Content-Type: text/html; charset="us-ascii" X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id SAA20462 Content-Transfer-Encoding: quoted-printable Hi,

Please forward any correction/addition you may want to make on the minutes.

JP.

Date: Thu, 02 Sep 2004 10:30:40 -0400
To: proceedings@ietf.org
From: Jean Philippe Vasseur <jvasseur@cisco.com>
Subject: PCE BOF minutes - IETF-60 - San Diego
Cc: adrian@olddog.co.uk, zinin@psg.com, bill Fenner <fenner@research.att.com>

Minutes of the Path Computation Element BOF (pce)  IETF-60  San Diego
#############################################################

Chairs: JP Vasseur, Adrian Farrel
ADs: Alex Zinin, Bill Fenner

*thanks to Dave Ward and Don Fedyk for their help taking notes*

1) Agenda bashing, Admin and objectives - Adrian
**********************************************************

2) Overview of PCE-based path computation - JP
*********************************************************
What is the BoF about ? What do we mean by PCE ?
PCE is an entity capable of compositing a path. Mainly we mean MPLS TE for now but could expand to other (IP paths).
If you are computing a path for a loose hop you are a PCE. PCE examples: Router, LSR, Server.
PCE is just an entity capable of doing some computation
Does not require centralized path computation. PCE can do distributed computation.
One View: Each router is a PCE for it neighbors.
Could have a PCE where global optimization is required
Could be completely stateless or stateful
PCE approach is not necessarily the only approach but one approach
PCE suits a number of problem spaces.
Highlighting that PCE can be centralized or distributed model and need both

3) Requirements for PCE-based path computation (30 minutes) Raymond (Infonet), Kenji (KDDI), Jean-Louis (France Telecom), Seisho (NTT), Jerry (ATT), Javier (Telefonica), Venkata (MCI)

Raymond Zhang, Infonet
Case customer wants a guaranteed path that is delay sensitive. Problem is there is high interconnect multi domain. Want to select paths with a high degree of control.

Kenji Kumaki, KDDI
Multi AS inter SP, Shortest end to end, Re-optimization, Multi IGP areas, Re-optimization. These are difficult problems to solve. Scalability issues with Routing and Signaling.

Jean Louis Le Roux, France Telecom
Head end is sufficient for most., Complex routing conditions for P2 MP. Multi constraint Backup Path.  Inter domain path computation. Diverse path computation. Could benefit from path computation element. Dedicated tool, Centralized, Collaborative Useful for backup.

High level requirements: Reliable signaling protocol, Automatic discovery, Scalability, Balance the computational load, Distribute PCE function, High Availability, Robustness.

Question Dimitri Papadimitriou: is list detailing the PCE to PCE signaling?
JP: Yes
Dimitri: So 1st bullet is client to server signaling relationship?
JP: Yes good point load share requests but also need case where paths are dependent on one another.

Jerry Ash, AT&T
Requirements:  Migrating to converged Network.
IP MPLS and all TDM to VoIP. These are the architecture plans, not committed and being implemented. PCE is part of the plan. Inter area, very large network need a solution that scales. Intra and inter AS.  Need shortest path across Network
Need standards based solution

Seisho  Yakukawa, NTT
Requirements: P2MP, IP-TV, Video, CPU intensive, P2MP, Inter-domain, Need wider community, PCE approach is good.

Arthi:  PCE to PCE or LSR to PCE based on same protocols?
Adrian: Yet to be decided. Good Point.
Arthi :When we talk about signaling, is it query-reply or  MPLS TE signaling?
JP: query-reply, no change to TE LSP signalling
Igor: Two types of signaling: are they the same ?
Adrian: This is what we are deciding. Please wait for this.
Dimitri: The issue I see is there need for synchronization. There is a need for coordination.
Adrian: Yes that is what we are discussing
?? You are going to have a discussion part a the end
JP:Yes.
Bijan Jabbari : Are you asking in the context of MPLS?
JP: Yes.
Bijan:  This is related to some specific application.
JP:Yes

Venkata Josyula, MCI
Requirements: Multiple AS, Hierarchical AS and be able to build AS, Inter area PCE..
Inter AS: Need a simple solution. Not saying you can use BGP next hops.
Do need TE Policy. Like the flexibility to coexist with other approaches.
JP: Interesting question. PCE could be used for inter areas and BGP for inter AS (AS path selection). This is an Interesting point.

4) Functional requirements of a PCE-based path computation system  - JP
*************************************************************************= **************
Functional requirements:
Multiple Models Picture:
Centralized,
Cooperative model PCE for one [or more] parts of the path.=20
Distributed : Each node is a fully distributed PCE (example: Backup Tunnel path comp).=20

Discovery of the PCE in a network:
Static Provisioning=20
Dynamic discovery computing resource (load sharing between multiple PCEs)=20

PCE may have routing adjacency with other nodes or may use some [other] protocols)

LSR-PCE Signaling: Interaction between the router and the PCE: RSVP, or new protocol. Need to specify request and reply. 

Arthi: On slide are PCE red circles. Are these the only PCEs? =20
JP: No of course not.
From this figure each LSR is a PCE or does it talk to other PCEs?
Adrian: If you have an Abstract node or a loose path you are using a PCE.
Arthi: This picture is not necessary the only view. It is not mandatory.
JP: It can be a server or a router itself.
Bijan: It can be [LSR]{missed it} or higher level than that?
??  It would be useful to have distinction between PCEs. Implement a LSR as a distributed machinery with PCE and share the network with the data network.
JP: We can discuss this.
?? Many, many approaches. Distributed path computation. Information is not synchronized.  If you do it on several path computation elements.
Adrian: Yes that is a problem. Clearly diverse path.  Clearly not produce loops.
?? Signaling protocol soft state?. RSVP-TE sounds like a funny approach. Will there be others?
Adrian: Yes 5 proposals already ...
Alex. Clarification on slides please.
Ina: Do you have model ? Does the PCE have to run routing or not? Type of discovery mechanism are a direct result of the model.
JP :Yes it is dependent.
Ping Pan: Inter domain. Great one [requirement]. What is the best algorithm? That is independent. How you communicate. COPS, RADIUS DIAMETER. Cisco scripts overnight.
JP: Not sure what you are trying to clarify.
Ping: You are limited to data path signaling.
Alex: Is it local to the box or cooperative [across boxes]?
JP: Inter domain must be standardized to some extent to compute an inter-domain shortest path and avoid loops. Intra not necessary.
Ping: Preventing loop is one thing.
Alex: Cut line hold to discussion.

JP: Policy, Security, Confidentiality.

Adrian: Not here to discuss drafts good bad or WG drafts. Just want to expose the drafts. If you have questions please go to authors not to microphone.

????: Does the LSR have to be the PCE?
JP: No, it can be another box.
????: Can PCEs be out of band?
JP: At end of meeting
????: Can we use this to find diverse paths? Can we use this for cooperative model? Are there loops formed?
JP: Yes for diverse paths, no to loops, yes to cooperative
Sue Hares: Does the PCE have to participate in routing?
JP - It can

5) Current status of drafts (20 minutes) - Several
********************************************************
Background and framework drafts 4
Requirements draft 1
PCE Discovery (see IDs in CCAMP, ISIS and OSPF WGs)
PCE signaling 3 drafts
Modified TE Flooding
Applications 2 drafts

Quick walk through the drafts -  Minor clarifications and comments

JP: No time to discuss the draft in detail  by the way, not the objective of this BOF.

draft-leroux-pce-backup-comp-frwk-00.txt  Jean-Louis
Nurit Sprecher: What is what the assumption for failure? A single failure?
JL: Yes this is reasonable. All networks are done this way.
Nurit: For multiple failures?
JL: This is to present one model for example.

draft-oki-pce-gmpls-req-00.txt, Eiji Oki
Two kinds of requirements
PCE requirement: GMPLS and MPLS
Functionally separated from MPLS NODE
Provider can choose appropriate implementation.
Centralized and distributed.
Multi region TE in GMPLS
Interworking between MPLS and GMPLS.

Hierarchical LSP setup.
Trigger by higher level LSP setup. PCE helps GMPLS node to setup hierarchical LSP.
PCE Triggered LSP should be supported. Treat as single region network from higher level. Standard Opaque TE information. Nodal=20 requirement
PCE two request modes: Mandatory mode, Normal request node can ask own node or PCE.

Solution drafts
******************

draft-oki-ccamp-gtep-00.txt, Eiji Oki
Generalized TE protocol GTEP.
Features:
Support trigger hierarchical LSP setup
Support TEDB synchronization
Reliable transfer of larger data based on TCP
GTEP running code

draft-vasseur-mpls-computation-rsvp-05.txt, Alia Atlas:
Extensions to RSVP-TE
Extend RSVP-TE a bit between the head end and the PCE.
Most of the stuff is there.
Request and reply message.
Some additional objects.
Drafts consider a number of different scenarios.

draft-choi-pce-e2e-centralized-restoration-srlg-00.txt, Jun Kyun
Centralized control from optical network and GMPLS 50 Ms=20 constraint.
Logical Ring configuration  based on SRLG and PCE
Compatible with ASON architecture SG-15
Simplifies and reduces management.

Bijan Jabbari: 50 msec requirement is driving control not feasible.
Jun: Where is the location of the central controller. The requirement is there.

IDs related to P2MP
LSR PCE signaling required could be part of a general PCE

IDs under construction - JP
 Requirements for signaling necessary=20
 Quick overview of inter-domain QoS ID, Mohamed Boucadair
6) Discussion points, WG formation, possible goals and milestones? Adrian, JP
*************************************************************************= ********************
JP: We need to discuss where can we do the work, what the scope is: MPLS or IP as well?

Adrian: Multiple components: Do we need a protocol at all ? Resolving how?
Alex: Do we have a good understanding ?

Bijan Jabbari: Note that there are requirements from research networks as well as SPs for Path Computation and routing

Alex: PCE computations?
Bijan: Yes.
????: LSR or something like that?
Bijan: In optical network very complex. Loops are a problem and problems are usually N-P complete. Complex. Requires a PCE.

JP: Let=92s discuss whether we need new protocols?

Zafar Ali: There is evidence for PCE needs/desires. Yes we should be working on this in the IETF.

Mark Hanley: Is spectrum too big? New routing architecture is evident and watch how far you want to go.

Alex: Lots of requirements however, from an architecture point of view there is confusion. Are we separating out some non-forwarding pieces.

Someone from Korea: Is scope limited to MPLS TE?

JP: It includes GMPLS

Arthi: Clear that SPs require this. Server SPs already have some mechanisms. People may already have some form of this functionality.  How are people are going to cooperate? Who will change? How much will existing mechanism affect what we do?

Adrian: You are saying even if this a good idea we are too late? We may be too late - Service provider can say. If we come up with a different protocol will this have impact? Do you have strong opinion?

Arthi: Yes should be done, but where? Don't know. Cannot standardize computation algorithms. Don't think so. Differentiates on PCE from [vendor to vendor]

Mohamed Boucadair, France Telecom: the PCE control plane and forwarding plane. If you have one element for this PCE it and element that manages your inter domain resources. Inter-provider not arguing for this. What we need the protocol in two different domains.

Dimitri: Does it cover co-located PCE. Should the PCE talk to elements of different vendors? What are changes expected to communicate LSR<->PCE? How far do we change RSVP? Please add requirements doc. Must have interoperability cleared up - don't get this. What about scalability problems of PCE once all TEDB are combined.

Zafar: Offline tools already present but, SP doesn't like them or not.

Dima: We know there is a need. IETF should take it on. There should be a new WG. There needs to be clarity on PCE being w/in the LSR or if the PCE should be a router to participate.

Francois LeFechaur: Clear requirements. We should do it.

Bora A: How you communicate to the router. Only Standardized. Co-located PCE on the router no different than what you do today. Comp SNMP TCL scripts and we need another algorithm. I think RSVP-TE approach may be the way to go.

Igor: I agree [with Bora]. Protocol only. Formidable task. Standardizing constraints is tough. I do believe we need to review the architecture. SNMP like protocol is a better choice.

Bjian: Need some form of centralization?
Adrian: Support centralization but not mandated
JP Yes. First slide.
Bijan: Distributed as well? Need multiple computation algorithms in the PCE. However that does not need to be standard.
Alex: We have some experience documenting algorithms. Kireeti did document an algorithm but this went [no where]. This could be done as Informational

Bijan - Is there centralization or not? There has to be both distributed and centralized.

Ina: Several people requirements and tools. Clear sign yes. Need for new working group. Should PCE be part of an LSR or and independent element?

Bora: Only thing that can be standardize is the communication, not algorithms. Ok creating another WG but, there isn't a lot of work here.

Igor: Only can standardize the communication between LSR and PCE. We need the work, the WG and the architecture. Perhaps we should have a configuration server like ATM.

Richard Rabbat: Clearly requirements, take this on. Scope don't standardize algorithm. Where. Stay in CCAMP.

JP: Note that in some cases such as collaborative path computation, you need to standardize algorithm to guarantee optimality (shortest path) and prevent looping problems.

Alia: We need signalling, we need architecture, we need resolve this, it should not be CCAMP as that WG is swamped

Hani: We should take on [new] WG

Bruce Davie: Let's not standardize the algorithms but make sure we specify it enough to make sure we don't have loops. Kireeti says that we should use BGP. It should be a WG and w/in the IETF.

Dimitri: The distributed model is difficult. Access of LSR to PCE. Next hop path resolution protocol. Important aspect should determine what are the based computation assumptions. Don't want one PCE then another PCE etc. 

Ping Pan: What is a domain?
Adrian: Have some input areas computation domain and protection domains.  Broad computation visibility.

Summary
************
Alex takes the mic:
Clearly there is a need
Clearly there is support for a solution
Confusion on what needs to be specified: communication, etc
Many requirements but quite diverse. Requirements good but so large.
What need to be standardized ? How this will affect the existing work ?
Tread very carefully and do architectural work so not to screw the internet
Heard strong opinion that we shouldn't standardize algorithms

Steps
********
Create mailing list - everyone will join
Need framework/arch doc(s)
Need to reduce requirements and present what will be covered
If we have something more complete by the next meting we will need another BOF.
--=====================_206422399==_.ALT-- --===============0455761401== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============0455761401==-- From pce-bounces@ietf.org Fri Sep 3 09:02:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26364; Fri, 3 Sep 2004 09:02:13 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C3DkK-0005nN-Te; Fri, 03 Sep 2004 09:04:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C3Dbi-00073w-Fd; Fri, 03 Sep 2004 08:55:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2r8o-0004Fi-K3; Thu, 02 Sep 2004 08:56:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29953; Thu, 2 Sep 2004 08:56:37 -0400 (EDT) Received: from prue.eim.surrey.ac.uk ([131.227.76.5] ident=exim) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2rBC-0000we-BL; Thu, 02 Sep 2004 08:59:07 -0400 Received: from argos.ee.surrey.ac.uk ([131.227.89.15] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.33 #4) id 1C2r8a-0006Bk-00; Thu, 02 Sep 2004 13:56:24 +0100 Date: Thu, 2 Sep 2004 13:56:22 +0100 (BST) From: Lloyd Wood X-X-Sender: eep1lw@argos.ee.surrey.ac.uk To: Adrian Farrel In-Reply-To: <045b01c490e4$ccd8f3d0$b6849ed9@Puppy> Message-ID: References: <045b01c490e4$ccd8f3d0$b6849ed9@Puppy> Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-102.5 required=5.5 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_PINE,USER_IN_WHITELIST autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Scanner: exiscan *1C2r8a-0006Bk-00*CaOB0zq/G9.* (SECM, UniS) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 X-Mailman-Approved-At: Fri, 03 Sep 2004 08:55:56 -0400 Cc: ccamp@ops.ietf.org, mpls@ietf.org, pce@ietf.org, routing-discussion@ietf.org, rtgwg@ietf.org Subject: [Pce] Re: Mailing List for Path Computation Element (PCE) 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@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 If, like me, you're too busy to attend BOFs and wondering what on earth PCE is, see: Path Computation Element Problem Statement http://www.ietf.org/internet-drafts/draft-ash-pce-problem-statement-00.txt for an intro. And there's a bunch of other drafts. cheers, L. don't we have enough approaches to traffic engineering already? On Thu, 2 Sep 2004, Adrian Farrel wrote: > Date: Thu, 2 Sep 2004 13:02:55 +0100 > From: Adrian Farrel > To: routing-discussion@ietf.org, rtgwg@ietf.org > Cc: ccamp@ops.ietf.org, mpls@ietf.org, pce@ietf.org > Subject: Mailing List for Path Computation Element (PCE) > > Hi, > > We have set up a mailing list to continue the discussions started in San Diego at the PCE > BOF. > > To subscribe https://www1.ietf.org/mailman/listinfo/pce > You are strongly advised to use a password as a random password > will be assigned for you otherwise! > > To post pce@lists.ietf.org OR pce@ietf.org (you must be subscribed) > All received mail appears to have been sent to pce@ietf.org regardless of which address > you actually use. > > Archive at https://www1.ietf.org/mail-archive/working-groups/pce/current/maillist.html > > To start the ball rolling, we will post the minutes from the BOF. > We are also well-progressed through the first cut of an architecture draft and will post > that soon and solicit comments. > > Thanks, > Adrian > > > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www1.ietf.org/mailman/listinfo/routing-discussion > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Fri Sep 3 09:02:59 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26392; Fri, 3 Sep 2004 09:02:59 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C3Dl7-0005yW-TE; Fri, 03 Sep 2004 09:05:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C3Dbr-00077n-P9; Fri, 03 Sep 2004 08:56:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2sg3-0007YW-SC for pce@megatron.ietf.org; Thu, 02 Sep 2004 10:35:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08144 for ; Thu, 2 Sep 2004 10:35:02 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2siS-0000Zv-B4 for pce@ietf.org; Thu, 02 Sep 2004 10:37:33 -0400 X-BrightmailFiltered: true Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i82EYPmT014532; Thu, 2 Sep 2004 07:34:25 -0700 (PDT) Received: from jvasseur-w2k01.cisco.com (dhcp-10-86-162-120.cisco.com [10.86.162.120]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id HAA25649; Thu, 2 Sep 2004 07:34:24 -0700 (PDT) Message-Id: <4.3.2.7.2.20040902103242.05b15a50@wells.cisco.com> X-Sender: jvasseur@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 02 Sep 2004 10:33:46 -0400 To: pce@ietf.org From: Jean Philippe Vasseur Mime-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 562e86ae4313685a38b49114a0f69210 X-Mailman-Approved-At: Fri, 03 Sep 2004 08:56:05 -0400 Subject: [Pce] Fwd: PCE BOF minutes - IETF-60 - San Diego 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="===============0267011430==" Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1069eb5b3f212f2b9b575eaf2aff5119 --===============0267011430== Content-Type: multipart/alternative; boundary="=====================_176566178==_.ALT" --=====================_176566178==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi, Please forward any correction/addition you may want to make on the minutes. JP. >Date: Thu, 02 Sep 2004 10:30:40 -0400 >To: proceedings@ietf.org >From: Jean Philippe Vasseur >Subject: PCE BOF minutes - IETF-60 - San Diego >Cc: adrian@olddog.co.uk, zinin@psg.com, bill Fenner > >Minutes of the Path Computation Element BOF (pce) IETF-60 San Diego >############################################################# > >Chairs: JP Vasseur, Adrian Farrel >ADs: Alex Zinin, Bill Fenner > >*thanks to Dave Ward and Don Fedyk for their help taking notes* > >1) Agenda bashing, Admin and objectives - Adrian >********************************************************** > >2) Overview of PCE-based path computation - JP >********************************************************* >What is the BoF about ? What do we mean by PCE ? >PCE is an entity capable of compositing a path. Mainly we mean MPLS TE for >now but could expand to other (IP paths). >If you are computing a path for a loose hop you are a PCE. PCE examples: >Router, LSR, Server. >PCE is just an entity capable of doing some computation >Does not require centralized path computation. PCE can do distributed >computation. >One View: Each router is a PCE for it neighbors. >Could have a PCE where global optimization is required >Could be completely stateless or stateful >PCE approach is not necessarily the only approach but one approach >PCE suits a number of problem spaces. >Highlighting that PCE can be centralized or distributed model and need both > >3) Requirements for PCE-based path computation (30 minutes) Raymond >(Infonet), Kenji (KDDI), Jean-Louis (France Telecom), Seisho (NTT), Jerry >(ATT), Javier (Telefonica), Venkata (MCI) > >Raymond Zhang, Infonet >Case customer wants a guaranteed path that is delay sensitive. Problem is >there is high interconnect multi domain. Want to select paths with a high >degree of control. > >Kenji Kumaki, KDDI >Multi AS inter SP, Shortest end to end, Re-optimization, Multi IGP areas, >Re-optimization. These are difficult problems to solve. Scalability issues >with Routing and Signaling. > >Jean Louis Le Roux, France Telecom >Head end is sufficient for most., Complex routing conditions for P2 MP. >Multi constraint Backup Path. Inter domain path computation. Diverse path >computation. Could benefit from path computation element. Dedicated tool, >Centralized, Collaborative Useful for backup. > >High level requirements: Reliable signaling protocol, Automatic discovery, >Scalability, Balance the computational load, Distribute PCE function, High >Availability, Robustness. > >Question Dimitri Papadimitriou: is list detailing the PCE to PCE signaling? >JP: Yes >Dimitri: So 1st bullet is client to server signaling relationship? >JP: Yes good point load share requests but also need case where paths are >dependent on one another. > >Jerry Ash, AT&T >Requirements: Migrating to converged Network. >IP MPLS and all TDM to VoIP. These are the architecture plans, not >committed and being implemented. PCE is part of the plan. Inter area, very >large network need a solution that scales. Intra and inter AS. Need >shortest path across Network >Need standards based solution > >Seisho Yakukawa, NTT >Requirements: P2MP, IP-TV, Video, CPU intensive, P2MP, Inter-domain, Need >wider community, PCE approach is good. > >Arthi: PCE to PCE or LSR to PCE based on same protocols? >Adrian: Yet to be decided. Good Point. >Arthi :When we talk about signaling, is it query-reply or MPLS TE signaling? >JP: query-reply, no change to TE LSP signalling >Igor: Two types of signaling: are they the same ? >Adrian: This is what we are deciding. Please wait for this. >Dimitri: The issue I see is there need for synchronization. There is a >need for coordination. >Adrian: Yes that is what we are discussing >?? You are going to have a discussion part a the end >JP:Yes. >Bijan Jabbari : Are you asking in the context of MPLS? >JP: Yes. >Bijan: This is related to some specific application. >JP:Yes > >Venkata Josyula, MCI >Requirements: Multiple AS, Hierarchical AS and be able to build AS, Inter >area PCE.. >Inter AS: Need a simple solution. Not saying you can use BGP next hops. >Do need TE Policy. Like the flexibility to coexist with other approaches. >JP: Interesting question. PCE could be used for inter areas and BGP for >inter AS (AS path selection). This is an Interesting point. > >4) Functional requirements of a PCE-based path computation system - JP >*************************************************************************************** >Functional requirements: >Multiple Models Picture: >Centralized, >Cooperative model PCE for one [or more] parts of the path. >Distributed : Each node is a fully distributed PCE (example: Backup Tunnel >path comp). > >Discovery of the PCE in a network: >Static Provisioning >Dynamic discovery computing resource (load sharing between multiple PCEs) > >PCE may have routing adjacency with other nodes or may use some [other] >protocols) > >LSR-PCE Signaling: Interaction between the router and the PCE: RSVP, or >new protocol. Need to specify request and reply. > >Arthi: On slide are PCE red circles. Are these the only PCEs? >JP: No of course not. > From this figure each LSR is a PCE or does it talk to other PCEs? >Adrian: If you have an Abstract node or a loose path you are using a PCE. >Arthi: This picture is not necessary the only view. It is not mandatory. >JP: It can be a server or a router itself. >Bijan: It can be [LSR]{missed it} or higher level than that? >?? It would be useful to have distinction between PCEs. Implement a LSR >as a distributed machinery with PCE and share the network with the data >network. >JP: We can discuss this. >?? Many, many approaches. Distributed path computation. Information is not >synchronized. If you do it on several path computation elements. >Adrian: Yes that is a problem. Clearly diverse path. Clearly not produce >loops. >?? Signaling protocol soft state?. RSVP-TE sounds like a funny approach. >Will there be others? >Adrian: Yes 5 proposals already ... >Alex. Clarification on slides please. >Ina: Do you have model ? Does the PCE have to run routing or not? Type of >discovery mechanism are a direct result of the model. >JP :Yes it is dependent. >Ping Pan: Inter domain. Great one [requirement]. What is the best >algorithm? That is independent. How you communicate. COPS, RADIUS >DIAMETER. Cisco scripts overnight. >JP: Not sure what you are trying to clarify. >Ping: You are limited to data path signaling. >Alex: Is it local to the box or cooperative [across boxes]? >JP: Inter domain must be standardized to some extent to compute an >inter-domain shortest path and avoid loops. Intra not necessary. >Ping: Preventing loop is one thing. >Alex: Cut line hold to discussion. > >JP: Policy, Security, Confidentiality. > >Adrian: Not here to discuss drafts good bad or WG drafts. Just want to >expose the drafts. If you have questions please go to authors not to >microphone. > >????: Does the LSR have to be the PCE? >JP: No, it can be another box. >????: Can PCEs be out of band? >JP: At end of meeting >????: Can we use this to find diverse paths? Can we use this for >cooperative model? Are there loops formed? >JP: Yes for diverse paths, no to loops, yes to cooperative >Sue Hares: Does the PCE have to participate in routing? >JP - It can > >5) Current status of drafts (20 minutes) - Several >******************************************************** >Background and framework drafts 4 >Requirements draft 1 >PCE Discovery (see IDs in CCAMP, ISIS and OSPF WGs) >PCE signaling 3 drafts >Modified TE Flooding >Applications 2 drafts > >Quick walk through the drafts - Minor clarifications and comments > >JP: No time to discuss the draft in detail by the way, not the objective >of this BOF. > >draft-leroux-pce-backup-comp-frwk-00.txt Jean-Louis >Nurit Sprecher: What is what the assumption for failure? A single failure? >JL: Yes this is reasonable. All networks are done this way. >Nurit: For multiple failures? >JL: This is to present one model for example. > >draft-oki-pce-gmpls-req-00.txt, Eiji Oki >Two kinds of requirements >PCE requirement: GMPLS and MPLS >Functionally separated from MPLS NODE >Provider can choose appropriate implementation. >Centralized and distributed. >Multi region TE in GMPLS >Interworking between MPLS and GMPLS. > >Hierarchical LSP setup. >Trigger by higher level LSP setup. PCE helps GMPLS node to setup >hierarchical LSP. >PCE Triggered LSP should be supported. Treat as single region network from >higher level. Standard Opaque TE information. Nodal requirement >PCE two request modes: Mandatory mode, Normal request node can ask own >node or PCE. > >Solution drafts >****************** > >draft-oki-ccamp-gtep-00.txt, Eiji Oki >Generalized TE protocol GTEP. >Features: >Support trigger hierarchical LSP setup >Support TEDB synchronization >Reliable transfer of larger data based on TCP >GTEP running code > >draft-vasseur-mpls-computation-rsvp-05.txt, Alia Atlas: >Extensions to RSVP-TE >Extend RSVP-TE a bit between the head end and the PCE. >Most of the stuff is there. >Request and reply message. >Some additional objects. >Drafts consider a number of different scenarios. > >draft-choi-pce-e2e-centralized-restoration-srlg-00.txt, Jun Kyun >Centralized control from optical network and GMPLS 50 Ms constraint. >Logical Ring configuration based on SRLG and PCE >Compatible with ASON architecture SG-15 >Simplifies and reduces management. > >Bijan Jabbari: 50 msec requirement is driving control not feasible. >Jun: Where is the location of the central controller. The requirement is >there. > >IDs related to P2MP >LSR PCE signaling required could be part of a general PCE > >IDs under construction - JP > Requirements for signaling necessary > Quick overview of inter-domain QoS ID, Mohamed Boucadair >6) Discussion points, WG formation, possible goals and milestones? Adrian, JP >********************************************************************************************* >JP: We need to discuss where can we do the work, what the scope is: MPLS >or IP as well? > >Adrian: Multiple components: Do we need a protocol at all ? Resolving how? >Alex: Do we have a good understanding ? > >Bijan Jabbari: Note that there are requirements from research networks as >well as SPs for Path Computation and routing > >Alex: PCE computations? >Bijan: Yes. >????: LSR or something like that? >Bijan: In optical network very complex. Loops are a problem and problems >are usually N-P complete. Complex. Requires a PCE. > >JP: Let's discuss whether we need new protocols? > >Zafar Ali: There is evidence for PCE needs/desires. Yes we should be >working on this in the IETF. > >Mark Hanley: Is spectrum too big? New routing architecture is evident and >watch how far you want to go. > >Alex: Lots of requirements however, from an architecture point of view >there is confusion. Are we separating out some non-forwarding pieces. > >Someone from Korea: Is scope limited to MPLS TE? > >JP: It includes GMPLS > >Arthi: Clear that SPs require this. Server SPs already have some >mechanisms. People may already have some form of this functionality. How >are people are going to cooperate? Who will change? How much will existing >mechanism affect what we do? > >Adrian: You are saying even if this a good idea we are too late? We may be >too late - Service provider can say. If we come up with a different >protocol will this have impact? Do you have strong opinion? > >Arthi: Yes should be done, but where? Don't know. Cannot standardize >computation algorithms. Don't think so. Differentiates on PCE from [vendor >to vendor] > >Mohamed Boucadair, France Telecom: the PCE control plane and forwarding >plane. If you have one element for this PCE it and element that manages >your inter domain resources. Inter-provider not arguing for this. What we >need the protocol in two different domains. > >Dimitri: Does it cover co-located PCE. Should the PCE talk to elements of >different vendors? What are changes expected to communicate LSR<->PCE? How >far do we change RSVP? Please add requirements doc. Must have >interoperability cleared up - don't get this. What about scalability >problems of PCE once all TEDB are combined. > >Zafar: Offline tools already present but, SP doesn't like them or not. > >Dima: We know there is a need. IETF should take it on. There should be a >new WG. There needs to be clarity on PCE being w/in the LSR or if the PCE >should be a router to participate. > >Francois LeFechaur: Clear requirements. We should do it. > >Bora A: How you communicate to the router. Only Standardized. Co-located >PCE on the router no different than what you do today. Comp SNMP TCL >scripts and we need another algorithm. I think RSVP-TE approach may be the >way to go. > >Igor: I agree [with Bora]. Protocol only. Formidable task. Standardizing >constraints is tough. I do believe we need to review the architecture. >SNMP like protocol is a better choice. > >Bjian: Need some form of centralization? >Adrian: Support centralization but not mandated >JP Yes. First slide. >Bijan: Distributed as well? Need multiple computation algorithms in the >PCE. However that does not need to be standard. >Alex: We have some experience documenting algorithms. Kireeti did document >an algorithm but this went [no where]. This could be done as Informational > >Bijan - Is there centralization or not? There has to be both distributed >and centralized. > >Ina: Several people requirements and tools. Clear sign yes. Need for new >working group. Should PCE be part of an LSR or and independent element? > >Bora: Only thing that can be standardize is the communication, not >algorithms. Ok creating another WG but, there isn't a lot of work here. > >Igor: Only can standardize the communication between LSR and PCE. We need >the work, the WG and the architecture. Perhaps we should have a >configuration server like ATM. > >Richard Rabbat: Clearly requirements, take this on. Scope don't >standardize algorithm. Where. Stay in CCAMP. > >JP: Note that in some cases such as collaborative path computation, you >need to standardize algorithm to guarantee optimality (shortest path) and >prevent looping problems. > >Alia: We need signalling, we need architecture, we need resolve this, it >should not be CCAMP as that WG is swamped > >Hani: We should take on [new] WG > >Bruce Davie: Let's not standardize the algorithms but make sure we specify >it enough to make sure we don't have loops. Kireeti says that we should >use BGP. It should be a WG and w/in the IETF. > >Dimitri: The distributed model is difficult. Access of LSR to PCE. Next >hop path resolution protocol. Important aspect should determine what are >the based computation assumptions. Don't want one PCE then another PCE etc. > >Ping Pan: What is a domain? >Adrian: Have some input areas computation domain and protection >domains. Broad computation visibility. > >Summary >************ >Alex takes the mic: >Clearly there is a need >Clearly there is support for a solution >Confusion on what needs to be specified: communication, etc >Many requirements but quite diverse. Requirements good but so large. >What need to be standardized ? How this will affect the existing work ? >Tread very carefully and do architectural work so not to screw the internet >Heard strong opinion that we shouldn't standardize algorithms > >Steps >******** >Create mailing list - everyone will join >Need framework/arch doc(s) >Need to reduce requirements and present what will be covered >If we have something more complete by the next meting we will need another >BOF. --=====================_176566178==_.ALT Content-Type: text/html; charset="us-ascii" X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id KAA08144 Content-Transfer-Encoding: quoted-printable Hi,

Please forward any correction/addition you may want to make on the minutes.

JP.

Date: Thu, 02 Sep 2004 10:30:40 -0400
To: proceedings@ietf.org
From: Jean Philippe Vasseur <jvasseur@cisco.com>
Subject: PCE BOF minutes - IETF-60 - San Diego
Cc: adrian@olddog.co.uk, zinin@psg.com, bill Fenner <fenner@research.att.com>

Minutes of the Path Computation Element BOF (pce)  IETF-60  San Diego
#############################################################

Chairs: JP Vasseur, Adrian Farrel
ADs: Alex Zinin, Bill Fenner

*thanks to Dave Ward and Don Fedyk for their help taking notes*

1) Agenda bashing, Admin and objectives - Adrian
**********************************************************

2) Overview of PCE-based path computation - JP
*********************************************************
What is the BoF about ? What do we mean by PCE ?
PCE is an entity capable of compositing a path. Mainly we mean MPLS TE for now but could expand to other (IP paths).
If you are computing a path for a loose hop you are a PCE. PCE examples: Router, LSR, Server.
PCE is just an entity capable of doing some computation
Does not require centralized path computation. PCE can do distributed computation.
One View: Each router is a PCE for it neighbors.
Could have a PCE where global optimization is required
Could be completely stateless or stateful
PCE approach is not necessarily the only approach but one approach
PCE suits a number of problem spaces.
Highlighting that PCE can be centralized or distributed model and need both

3) Requirements for PCE-based path computation (30 minutes) Raymond (Infonet), Kenji (KDDI), Jean-Louis (France Telecom), Seisho (NTT), Jerry (ATT), Javier (Telefonica), Venkata (MCI)

Raymond Zhang, Infonet
Case customer wants a guaranteed path that is delay sensitive. Problem is there is high interconnect multi domain. Want to select paths with a high degree of control.

Kenji Kumaki, KDDI
Multi AS inter SP, Shortest end to end, Re-optimization, Multi IGP areas, Re-optimization. These are difficult problems to solve. Scalability issues with Routing and Signaling.

Jean Louis Le Roux, France Telecom
Head end is sufficient for most., Complex routing conditions for P2 MP. Multi constraint Backup Path.  Inter domain path computation. Diverse path computation. Could benefit from path computation element. Dedicated tool, Centralized, Collaborative Useful for backup.

High level requirements: Reliable signaling protocol, Automatic discovery, Scalability, Balance the computational load, Distribute PCE function, High Availability, Robustness.

Question Dimitri Papadimitriou: is list detailing the PCE to PCE signaling?
JP: Yes
Dimitri: So 1st bullet is client to server signaling relationship?
JP: Yes good point load share requests but also need case where paths are dependent on one another.

Jerry Ash, AT&T
Requirements:  Migrating to converged Network.
IP MPLS and all TDM to VoIP. These are the architecture plans, not committed and being implemented. PCE is part of the plan. Inter area, very large network need a solution that scales. Intra and inter AS.  Need shortest path across Network
Need standards based solution

Seisho  Yakukawa, NTT
Requirements: P2MP, IP-TV, Video, CPU intensive, P2MP, Inter-domain, Need wider community, PCE approach is good.

Arthi:  PCE to PCE or LSR to PCE based on same protocols?
Adrian: Yet to be decided. Good Point.
Arthi :When we talk about signaling, is it query-reply or  MPLS TE signaling?
JP: query-reply, no change to TE LSP signalling
Igor: Two types of signaling: are they the same ?
Adrian: This is what we are deciding. Please wait for this.
Dimitri: The issue I see is there need for synchronization. There is a need for coordination.
Adrian: Yes that is what we are discussing
?? You are going to have a discussion part a the end
JP:Yes.
Bijan Jabbari : Are you asking in the context of MPLS?
JP: Yes.
Bijan:  This is related to some specific application.
JP:Yes

Venkata Josyula, MCI
Requirements: Multiple AS, Hierarchical AS and be able to build AS, Inter area PCE..
Inter AS: Need a simple solution. Not saying you can use BGP next hops.
Do need TE Policy. Like the flexibility to coexist with other approaches.
JP: Interesting question. PCE could be used for inter areas and BGP for inter AS (AS path selection). This is an Interesting point.

4) Functional requirements of a PCE-based path computation system  - JP
*************************************************************************= **************
Functional requirements:
Multiple Models Picture:
Centralized,
Cooperative model PCE for one [or more] parts of the path.=20
Distributed : Each node is a fully distributed PCE (example: Backup Tunnel path comp).=20

Discovery of the PCE in a network:
Static Provisioning=20
Dynamic discovery computing resource (load sharing between multiple PCEs)=20

PCE may have routing adjacency with other nodes or may use some [other] protocols)

LSR-PCE Signaling: Interaction between the router and the PCE: RSVP, or new protocol. Need to specify request and reply. 

Arthi: On slide are PCE red circles. Are these the only PCEs? =20
JP: No of course not.
From this figure each LSR is a PCE or does it talk to other PCEs?
Adrian: If you have an Abstract node or a loose path you are using a PCE.
Arthi: This picture is not necessary the only view. It is not mandatory.
JP: It can be a server or a router itself.
Bijan: It can be [LSR]{missed it} or higher level than that?
??  It would be useful to have distinction between PCEs. Implement a LSR as a distributed machinery with PCE and share the network with the data network.
JP: We can discuss this.
?? Many, many approaches. Distributed path computation. Information is not synchronized.  If you do it on several path computation elements.
Adrian: Yes that is a problem. Clearly diverse path.  Clearly not produce loops.
?? Signaling protocol soft state?. RSVP-TE sounds like a funny approach. Will there be others?
Adrian: Yes 5 proposals already ...
Alex. Clarification on slides please.
Ina: Do you have model ? Does the PCE have to run routing or not? Type of discovery mechanism are a direct result of the model.
JP :Yes it is dependent.
Ping Pan: Inter domain. Great one [requirement]. What is the best algorithm? That is independent. How you communicate. COPS, RADIUS DIAMETER. Cisco scripts overnight.
JP: Not sure what you are trying to clarify.
Ping: You are limited to data path signaling.
Alex: Is it local to the box or cooperative [across boxes]?
JP: Inter domain must be standardized to some extent to compute an inter-domain shortest path and avoid loops. Intra not necessary.
Ping: Preventing loop is one thing.
Alex: Cut line hold to discussion.

JP: Policy, Security, Confidentiality.

Adrian: Not here to discuss drafts good bad or WG drafts. Just want to expose the drafts. If you have questions please go to authors not to microphone.

????: Does the LSR have to be the PCE?
JP: No, it can be another box.
????: Can PCEs be out of band?
JP: At end of meeting
????: Can we use this to find diverse paths? Can we use this for cooperative model? Are there loops formed?
JP: Yes for diverse paths, no to loops, yes to cooperative
Sue Hares: Does the PCE have to participate in routing?
JP - It can

5) Current status of drafts (20 minutes) - Several
********************************************************
Background and framework drafts 4
Requirements draft 1
PCE Discovery (see IDs in CCAMP, ISIS and OSPF WGs)
PCE signaling 3 drafts
Modified TE Flooding
Applications 2 drafts

Quick walk through the drafts -  Minor clarifications and comments

JP: No time to discuss the draft in detail  by the way, not the objective of this BOF.

draft-leroux-pce-backup-comp-frwk-00.txt  Jean-Louis
Nurit Sprecher: What is what the assumption for failure? A single failure?
JL: Yes this is reasonable. All networks are done this way.
Nurit: For multiple failures?
JL: This is to present one model for example.

draft-oki-pce-gmpls-req-00.txt, Eiji Oki
Two kinds of requirements
PCE requirement: GMPLS and MPLS
Functionally separated from MPLS NODE
Provider can choose appropriate implementation.
Centralized and distributed.
Multi region TE in GMPLS
Interworking between MPLS and GMPLS.

Hierarchical LSP setup.
Trigger by higher level LSP setup. PCE helps GMPLS node to setup hierarchical LSP.
PCE Triggered LSP should be supported. Treat as single region network from higher level. Standard Opaque TE information. Nodal=20 requirement
PCE two request modes: Mandatory mode, Normal request node can ask own node or PCE.

Solution drafts
******************

draft-oki-ccamp-gtep-00.txt, Eiji Oki
Generalized TE protocol GTEP.
Features:
Support trigger hierarchical LSP setup
Support TEDB synchronization
Reliable transfer of larger data based on TCP
GTEP running code

draft-vasseur-mpls-computation-rsvp-05.txt, Alia Atlas:
Extensions to RSVP-TE
Extend RSVP-TE a bit between the head end and the PCE.
Most of the stuff is there.
Request and reply message.
Some additional objects.
Drafts consider a number of different scenarios.

draft-choi-pce-e2e-centralized-restoration-srlg-00.txt, Jun Kyun
Centralized control from optical network and GMPLS 50 Ms=20 constraint.
Logical Ring configuration  based on SRLG and PCE
Compatible with ASON architecture SG-15
Simplifies and reduces management.

Bijan Jabbari: 50 msec requirement is driving control not feasible.
Jun: Where is the location of the central controller. The requirement is there.

IDs related to P2MP
LSR PCE signaling required could be part of a general PCE

IDs under construction - JP
 Requirements for signaling necessary=20
 Quick overview of inter-domain QoS ID, Mohamed Boucadair
6) Discussion points, WG formation, possible goals and milestones? Adrian, JP
*************************************************************************= ********************
JP: We need to discuss where can we do the work, what the scope is: MPLS or IP as well?

Adrian: Multiple components: Do we need a protocol at all ? Resolving how?
Alex: Do we have a good understanding ?

Bijan Jabbari: Note that there are requirements from research networks as well as SPs for Path Computation and routing

Alex: PCE computations?
Bijan: Yes.
????: LSR or something like that?
Bijan: In optical network very complex. Loops are a problem and problems are usually N-P complete. Complex. Requires a PCE.

JP: Let=92s discuss whether we need new protocols?

Zafar Ali: There is evidence for PCE needs/desires. Yes we should be working on this in the IETF.

Mark Hanley: Is spectrum too big? New routing architecture is evident and watch how far you want to go.

Alex: Lots of requirements however, from an architecture point of view there is confusion. Are we separating out some non-forwarding pieces.

Someone from Korea: Is scope limited to MPLS TE?

JP: It includes GMPLS

Arthi: Clear that SPs require this. Server SPs already have some mechanisms. People may already have some form of this functionality.  How are people are going to cooperate? Who will change? How much will existing mechanism affect what we do?

Adrian: You are saying even if this a good idea we are too late? We may be too late - Service provider can say. If we come up with a different protocol will this have impact? Do you have strong opinion?

Arthi: Yes should be done, but where? Don't know. Cannot standardize computation algorithms. Don't think so. Differentiates on PCE from [vendor to vendor]

Mohamed Boucadair, France Telecom: the PCE control plane and forwarding plane. If you have one element for this PCE it and element that manages your inter domain resources. Inter-provider not arguing for this. What we need the protocol in two different domains.

Dimitri: Does it cover co-located PCE. Should the PCE talk to elements of different vendors? What are changes expected to communicate LSR<->PCE? How far do we change RSVP? Please add requirements doc. Must have interoperability cleared up - don't get this. What about scalability problems of PCE once all TEDB are combined.

Zafar: Offline tools already present but, SP doesn't like them or not.

Dima: We know there is a need. IETF should take it on. There should be a new WG. There needs to be clarity on PCE being w/in the LSR or if the PCE should be a router to participate.

Francois LeFechaur: Clear requirements. We should do it.

Bora A: How you communicate to the router. Only Standardized. Co-located PCE on the router no different than what you do today. Comp SNMP TCL scripts and we need another algorithm. I think RSVP-TE approach may be the way to go.

Igor: I agree [with Bora]. Protocol only. Formidable task. Standardizing constraints is tough. I do believe we need to review the architecture. SNMP like protocol is a better choice.

Bjian: Need some form of centralization?
Adrian: Support centralization but not mandated
JP Yes. First slide.
Bijan: Distributed as well? Need multiple computation algorithms in the PCE. However that does not need to be standard.
Alex: We have some experience documenting algorithms. Kireeti did document an algorithm but this went [no where]. This could be done as Informational

Bijan - Is there centralization or not? There has to be both distributed and centralized.

Ina: Several people requirements and tools. Clear sign yes. Need for new working group. Should PCE be part of an LSR or and independent element?

Bora: Only thing that can be standardize is the communication, not algorithms. Ok creating another WG but, there isn't a lot of work here.

Igor: Only can standardize the communication between LSR and PCE. We need the work, the WG and the architecture. Perhaps we should have a configuration server like ATM.

Richard Rabbat: Clearly requirements, take this on. Scope don't standardize algorithm. Where. Stay in CCAMP.

JP: Note that in some cases such as collaborative path computation, you need to standardize algorithm to guarantee optimality (shortest path) and prevent looping problems.

Alia: We need signalling, we need architecture, we need resolve this, it should not be CCAMP as that WG is swamped

Hani: We should take on [new] WG

Bruce Davie: Let's not standardize the algorithms but make sure we specify it enough to make sure we don't have loops. Kireeti says that we should use BGP. It should be a WG and w/in the IETF.

Dimitri: The distributed model is difficult. Access of LSR to PCE. Next hop path resolution protocol. Important aspect should determine what are the based computation assumptions. Don't want one PCE then another PCE etc. 

Ping Pan: What is a domain?
Adrian: Have some input areas computation domain and protection domains.  Broad computation visibility.

Summary
************
Alex takes the mic:
Clearly there is a need
Clearly there is support for a solution
Confusion on what needs to be specified: communication, etc
Many requirements but quite diverse. Requirements good but so large.
What need to be standardized ? How this will affect the existing work ?
Tread very carefully and do architectural work so not to screw the internet
Heard strong opinion that we shouldn't standardize algorithms

Steps
********
Create mailing list - everyone will join
Need framework/arch doc(s)
Need to reduce requirements and present what will be covered
If we have something more complete by the next meting we will need another BOF.
--=====================_176566178==_.ALT-- --===============0267011430== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============0267011430==-- From pce-bounces@ietf.org Sat Sep 4 04:42:03 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03054; Sat, 4 Sep 2004 04:42:03 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C3WAL-0004dA-EK; Sat, 04 Sep 2004 04:44:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C3W4g-0005P0-LG; Sat, 04 Sep 2004 04:39:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C3W3O-0005F1-H0 for pce@megatron.ietf.org; Sat, 04 Sep 2004 04:37:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02813 for ; Sat, 4 Sep 2004 04:37:44 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C3W6A-0004Yi-BQ for pce@ietf.org; Sat, 04 Sep 2004 04:40:39 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C3W3L-0001tc-3O; Sat, 04 Sep 2004 08:37:44 +0000 Message-ID: <41397EF8.305@psg.com> Date: Sat, 04 Sep 2004 10:38:16 +0200 From: dimitri papadimitriou User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jean Philippe Vasseur Subject: Re: [Pce] Fwd: PCE BOF minutes - IETF-60 - San Diego References: <4.3.2.7.2.20040902185100.0384dc90@wells.cisco.com> In-Reply-To: <4.3.2.7.2.20040902185100.0384dc90@wells.cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: dfc64cf6e4c6efdbf6b8f4c995df04df Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id EAA02813 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@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c375f2012a4f820b0c0fd6fb14a28357 Content-Transfer-Encoding: quoted-printable jp - see in-line: Jean Philippe Vasseur wrote: > Hi, >=20 > Please forward any correction/addition you may want to make on the minu= tes. >=20 > JP. >=20 >> Date: Thu, 02 Sep 2004 10:30:40 -0400 >> To: proceedings@ietf.org >> From: Jean Philippe Vasseur >> Subject: PCE BOF minutes - IETF-60 - San Diego >> Cc: adrian@olddog.co.uk, zinin@psg.com, bill Fenner=20 >> >> >> Minutes of the Path Computation Element BOF (pce) IETF-60 San Diego >> ############################################################# >> >> Chairs: JP Vasseur, Adrian Farrel >> ADs: Alex Zinin, Bill Fenner >> >> *thanks to Dave Ward and Don Fedyk for their help taking notes* >> >> 1) Agenda bashing, Admin and objectives - Adrian >> ********************************************************** >> >> 2) Overview of PCE-based path computation - JP >> ********************************************************* >> What is the BoF about ? What do we mean by PCE ? >> PCE is an entity capable of compositing a path. Mainly we mean MPLS TE= =20 >> for now but could expand to other (IP paths). >> If you are computing a path for a loose hop you are a PCE. PCE=20 >> examples: Router, LSR, Server. >> PCE is just an entity capable of doing some computation >> Does not require centralized path computation. PCE can do distributed=20 >> computation. >> One View: Each router is a PCE for it neighbors. >> Could have a PCE where global optimization is required >> Could be completely stateless or stateful >> PCE approach is not necessarily the only approach but one approach >> PCE suits a number of problem spaces. >> Highlighting that PCE can be centralized or distributed model and need= =20 >> both >> >> 3) Requirements for PCE-based path computation (_30 minutes_) Raymond=20 >> (Infonet), Kenji (KDDI), Jean-Louis (France Telecom), Seisho (NTT),=20 >> Jerry (ATT), Javier (Telefonica), Venkata (MCI) >> >> Raymond Zhang, Infonet >> Case customer wants a guaranteed path that is delay sensitive. Problem= =20 >> is there is high interconnect multi domain. Want to select paths with=20 >> a high degree of control. >> >> Kenji Kumaki, KDDI >> Multi AS inter SP, Shortest end to end, Re-optimization, Multi IGP=20 >> areas, Re-optimization. These are difficult problems to solve.=20 >> Scalability issues with Routing and Signaling. >> >> Jean Louis Le Roux, France Telecom >> Head end is sufficient for most., Complex routing conditions for P2=20 >> MP. Multi constraint Backup Path. Inter domain path computation.=20 >> Diverse path computation. Could benefit from path computation element.= =20 >> Dedicated tool, Centralized, Collaborative Useful for backup. >> >> High level requirements: Reliable signaling protocol, Automatic=20 >> discovery, Scalability, Balance the computational load, Distribute PCE= =20 >> function, High Availability, Robustness. >> >> Question Dimitri Papadimitriou: is list detailing the PCE to PCE=20 >> signaling? >> JP: Yes >> Dimitri: So 1st bullet is client to server signaling relationship? >> JP: Yes good point load share requests but also need case where paths=20 >> are dependent on one another. >> >> Jerry Ash, AT&T >> Requirements: Migrating to converged Network. >> IP MPLS and all TDM to VoIP. These are the architecture plans, not=20 >> committed and being implemented. PCE is part of the plan. Inter area,=20 >> very large network need a solution that scales. Intra and inter AS. =20 >> Need shortest path across Network >> Need standards based solution >> >> Seisho Yakukawa, NTT >> Requirements: P2MP, IP-TV, Video, CPU intensive, P2MP, Inter-domain,=20 >> Need wider community, PCE approach is good. >> >> Arthi: PCE to PCE or LSR to PCE based on same protocols? >> Adrian: Yet to be decided. Good Point. >> Arthi :When we talk about signaling, is it query-reply or MPLS TE=20 >> signaling? >> JP: query-reply, no change to TE LSP signalling >> Igor: Two types of signaling: are they the same ? >> Adrian: This is what we are deciding. Please wait for this. >> Dimitri: The issue I see is there need for synchronization. There is a= =20 >> need for coordination. >> Adrian: Yes that is what we are discussing >> ?? You are going to have a discussion part a the end >> JP:Yes. >> Bijan Jabbari : Are you asking in the context of MPLS? >> JP: Yes. >> Bijan: This is related to some specific application. >> JP:Yes >> >> Venkata Josyula, MCI >> Requirements: Multiple AS, Hierarchical AS and be able to build AS,=20 >> Inter area PCE.. >> Inter AS: Need a simple solution. Not saying you can use BGP next hops. >> Do need TE Policy. Like the flexibility to coexist with other approach= es. >> JP: Interesting question. PCE could be used for inter areas and BGP=20 >> for inter AS (AS path selection). This is an Interesting point. >> >> 4) Functional requirements of a PCE-based path computation system - J= P >> **********************************************************************= ***************** >> Functional requirements: >> Multiple Models Picture: >> Centralized, >> Cooperative model PCE for one [or more] parts of the path. >> >> Distributed : Each node is a fully distributed PCE (example: >> Backup Tunnel path comp).=20 >> >> >> Discovery of the PCE in a network: >> Static Provisioning >> >> Dynamic discovery computing resource (load sharing between >> multiple PCEs)=20 >> >> >> PCE may have routing adjacency with other nodes or may use some=20 >> [other] protocols) >> >> LSR-PCE Signaling: Interaction between the router and the PCE: RSVP,=20 >> or new protocol. Need to specify request and reply.=20 >> >> Arthi: On slide are PCE red circles. Are these the only PCEs?=20 >> JP: No of course not. >> From this figure each LSR is a PCE or does it talk to other PCEs? >> Adrian: If you have an Abstract node or a loose path you are using a P= CE. >> Arthi: This picture is not necessary the only view. It is not mandator= y. >> JP: It can be a server or a router itself. >> Bijan: It can be [LSR]{missed it} or higher level than that? >> ?? It would be useful to have distinction between PCEs. Implement a=20 >> LSR as a distributed machinery with PCE and share the network with the= =20 >> data network. >> JP: We can discuss this. >> ?? Many, many approaches. Distributed path computation. Information is= =20 >> not synchronized. If you do it on several path computation elements. >> Adrian: Yes that is a problem. Clearly diverse path. Clearly not=20 >> produce loops. >> ?? Signaling protocol soft state?. RSVP-TE sounds like a funny=20 >> approach. Will there be others? >> Adrian: Yes 5 proposals already ... >> Alex. Clarification on slides please. >> Ina: Do you have model ? Does the PCE have to run routing or not? Type= =20 >> of discovery mechanism are a direct result of the model. >> JP :Yes it is dependent. >> Ping Pan: Inter domain. Great one [requirement]. What is the best=20 >> algorithm? That is independent. How you communicate. COPS, RADIUS=20 >> DIAMETER. Cisco scripts overnight. >> JP: Not sure what you are trying to clarify. >> Ping: You are limited to data path signaling. >> Alex: Is it local to the box or cooperative [across boxes]? >> JP: Inter domain must be standardized to some extent to compute an=20 >> inter-domain shortest path and avoid loops. Intra not necessary. >> Ping: Preventing loop is one thing. >> Alex: Cut line hold to discussion. >> >> JP: Policy, Security, Confidentiality. >> >> Adrian: Not here to discuss drafts good bad or WG drafts. Just want to= =20 >> expose the drafts. If you have questions please go to authors not to=20 >> microphone. >> >> ????: Does the LSR have to be the PCE? >> JP: No, it can be another box. >> ????: Can PCEs be out of band? >> JP: At end of meeting >> ????: Can we use this to find diverse paths? Can we use this for=20 >> cooperative model? Are there loops formed? >> JP: Yes for diverse paths, no to loops, yes to cooperative >> Sue Hares: Does the PCE have to participate in routing? >> JP - It can >> >> 5) Current status of drafts (_20 minutes_) - Several >> ******************************************************** >> Background and framework drafts 4 >> Requirements draft 1 >> PCE Discovery (see IDs in CCAMP, ISIS and OSPF WGs) >> PCE signaling 3 drafts >> Modified TE Flooding >> Applications 2 drafts >> >> Quick walk through the drafts - Minor clarifications and comments >> >> JP: No time to discuss the draft in detail by the way, not the=20 >> objective of this BOF. >> >> draft-leroux-pce-backup-comp-frwk-00.txt Jean-Louis >> Nurit Sprecher: What is what the assumption for failure? A single=20 >> failure? >> JL: Yes this is reasonable. All networks are done this way. >> Nurit: For multiple failures? >> JL: This is to present one model for example. >> >> draft-oki-pce-gmpls-req-00.txt, Eiji Oki >> Two kinds of requirements >> PCE requirement: GMPLS and MPLS >> Functionally separated from MPLS NODE >> Provider can choose appropriate implementation. >> Centralized and distributed. >> Multi region TE in GMPLS >> Interworking between MPLS and GMPLS. >> >> Hierarchical LSP setup. >> Trigger by higher level LSP setup. PCE helps GMPLS node to setup=20 >> hierarchical LSP. >> PCE Triggered LSP should be supported. Treat as single region network=20 >> from higher level. Standard Opaque TE information. Nodal requirement >> PCE two request modes: Mandatory mode, Normal request node can ask own= =20 >> node or PCE. >> >> Solution drafts >> ****************** >> >> draft-oki-ccamp-gtep-00.txt, Eiji Oki >> Generalized TE protocol GTEP. >> Features: >> Support trigger hierarchical LSP setup >> Support TEDB synchronization >> Reliable transfer of larger data based on TCP >> GTEP running code >> >> draft-vasseur-mpls-computation-rsvp-05.txt, Alia Atlas: >> Extensions to RSVP-TE >> Extend RSVP-TE a bit between the head end and the PCE. >> Most of the stuff is there. >> Request and reply message. >> Some additional objects. >> Drafts consider a number of different scenarios. >> >> draft-choi-pce-e2e-centralized-restoration-srlg-00.txt, Jun Kyun >> Centralized control from optical network and GMPLS 50 Ms constraint. >> Logical Ring configuration based on SRLG and PCE >> Compatible with ASON architecture SG-15 >> Simplifies and reduces management. >> >> Bijan Jabbari: 50 msec requirement is driving control not feasible. >> Jun: Where is the location of the central controller. The requirement=20 >> is there. >> >> IDs related to P2MP >> LSR PCE signaling required could be part of a general PCE >> >> IDs under construction - JP >> >> Requirements for signaling necessary=20 >> Quick overview of inter-domain QoS ID, Mohamed Boucadair=20 >> >> 6) Discussion points, WG formation, possible goals and milestones?=20 >> Adrian, JP >> **********************************************************************= *********************** >> JP: We need to discuss where can we do the work, what the scope is:=20 >> MPLS or IP as well? >> >> Adrian: Multiple components: Do we need a protocol at all ? Resolving = how? >> Alex: Do we have a good understanding ? >> >> Bijan Jabbari: Note that there are requirements from research networks= =20 >> as well as SPs for Path Computation and routing >> >> Alex: PCE computations? >> Bijan: Yes. >> ????: LSR or something like that? >> Bijan: In optical network very complex. Loops are a problem and=20 >> problems are usually N-P complete. Complex. Requires a PCE. >> >> JP: Let=92s discuss whether we need new protocols? >> >> Zafar Ali: There is evidence for PCE needs/desires. Yes we should be=20 >> working on this in the IETF. >> >> Mark Hanley: Is spectrum too big? New routing architecture is evident=20 >> and watch how far you want to go. >> >> Alex: Lots of requirements however, from an architecture point of view= =20 >> there is confusion. Are we separating out some non-forwarding pieces. >> >> Someone from Korea: Is scope limited to MPLS TE? >> >> JP: It includes GMPLS >> >> Arthi: Clear that SPs require this. Server SPs already have some=20 >> mechanisms. People may already have some form of this functionality. =20 >> How are people are going to cooperate? Who will change? How much will=20 >> existing mechanism affect what we do? >> >> Adrian: You are saying even if this a good idea we are too late? We=20 >> may be too late - Service provider can say. If we come up with a=20 >> different protocol will this have impact? Do you have strong opinion? >> >> Arthi: Yes should be done, but where? Don't know. Cannot standardize=20 >> computation algorithms. Don't think so. Differentiates on PCE from=20 >> [vendor to vendor] >> >> Mohamed Boucadair, France Telecom: the PCE control plane and=20 >> forwarding plane. If you have one element for this PCE it and element=20 >> that manages your inter domain resources. Inter-provider not arguing=20 >> for this. What we need the protocol in two different domains. >> >> Dimitri: Does it cover co-located PCE. Should the PCE talk to elements= =20 >> of different vendors? What are changes expected to communicate=20 >> LSR<->PCE? How far do we change RSVP? Please add requirements doc.=20 >> Must have interoperability cleared up - don't get this. What about=20 >> scalability problems of PCE once all TEDB are combined. to complete the last item the question is also related to "PCE-PCE" communication: does it require any information exchange a-priori or would it only imply exchanges upon incoming request from LSR ? >> Zafar: Offline tools already present but, SP doesn't like them or not. >> >> Dima: We know there is a need. IETF should take it on. There should be= =20 >> a new WG. There needs to be clarity on PCE being w/in the LSR or if=20 >> the PCE should be a router to participate. >> >> Francois LeFechaur: Clear requirements. We should do it. >> >> Bora A: How you communicate to the router. Only Standardized.=20 >> Co-located PCE on the router no different than what you do today. Comp= =20 >> SNMP TCL scripts and we need another algorithm. I think RSVP-TE=20 >> approach may be the way to go. >> >> Igor: I agree [with Bora]. Protocol only. Formidable task.=20 >> Standardizing constraints is tough. I do believe we need to review the= =20 >> architecture. SNMP like protocol is a better choice. >> >> Bjian: Need some form of centralization? >> Adrian: Support centralization but not mandated >> JP Yes. First slide. >> Bijan: Distributed as well? Need multiple computation algorithms in=20 >> the PCE. However that does not need to be standard. >> Alex: We have some experience documenting algorithms. Kireeti did=20 >> document an algorithm but this went [no where]. This could be done as=20 >> Informational >> >> Bijan - Is there centralization or not? There has to be both=20 >> distributed and centralized. >> >> Ina: Several people requirements and tools. Clear sign yes. Need for=20 >> new working group. Should PCE be part of an LSR or and independent=20 >> element? >> >> Bora: Only thing that can be standardize is the communication, not=20 >> algorithms. Ok creating another WG but, there isn't a lot of work here. >> >> Igor: Only can standardize the communication between LSR and PCE. We=20 >> need the work, the WG and the architecture. Perhaps we should have a=20 >> configuration server like ATM. >> >> Richard Rabbat: Clearly requirements, take this on. Scope don't=20 >> standardize algorithm. Where. Stay in CCAMP. >> >> JP: Note that in some cases such as collaborative path computation,=20 >> you need to standardize algorithm to guarantee optimality (shortest=20 >> path) and prevent looping problems. >> >> Alia: We need signalling, we need architecture, we need resolve this,=20 >> it should not be CCAMP as that WG is swamped >> >> Hani: We should take on [new] WG >> >> Bruce Davie: Let's not standardize the algorithms but make sure we=20 >> specify it enough to make sure we don't have loops. Kireeti says that=20 >> we should use BGP. It should be a WG and w/in the IETF. >> >> Dimitri: The distributed model is difficult. Access of LSR to PCE.=20 >> Next hop path resolution protocol. Important aspect should determine=20 >> what are the based computation assumptions. Don't want one PCE then=20 >> another PCE etc.=20 please complete with: "concerning the "distributed PCE model" difficult to assess whether=20 referring to: - distributed access to a single PCE (multiple entry points) - when accessed PCE requires exchanges with other PCEs to deliver the final result (computation for instance performed in sequence before delivering the final result) -> "kind of" next hop path resolution protocol - computation itself can be distributed among several PCE (parallel)" so an important aspect should also determine what are the base computation assumptions ?." >> Ping Pan: What is a domain? >> Adrian: Have some input areas computation domain and protection=20 >> domains. Broad computation visibility. >> >> Summary >> ************ >> Alex takes the mic: >> Clearly there is a need >> Clearly there is support for a solution >> Confusion on what needs to be specified: communication, etc >> Many requirements but quite diverse. Requirements good but so large. >> What need to be standardized ? How this will affect the existing work = ? >> Tread very carefully and do architectural work so not to screw the=20 >> internet >> Heard strong opinion that we shouldn't standardize algorithms >> >> Steps >> ******** >> Create mailing list - everyone will join >> Need framework/arch doc(s) >> Need to reduce requirements and present what will be covered >> If we have something more complete by the next meting we will need=20 >> another BOF. >=20 >=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@ietf.org Sat Sep 4 14:16:04 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28991; Sat, 4 Sep 2004 14:16:04 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C3f7v-0005rO-Hi; Sat, 04 Sep 2004 14:19:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C3f45-0002j2-R1; Sat, 04 Sep 2004 14:15:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C3f1H-0002Ur-5v for pce@megatron.ietf.org; Sat, 04 Sep 2004 14:12:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28821 for ; Sat, 4 Sep 2004 14:12:09 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C3f48-0005nT-3j for pce@ietf.org; Sat, 04 Sep 2004 14:15:09 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 04 Sep 2004 11:20:17 +0000 X-BrightmailFiltered: true Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i84IBY8J027764; Sat, 4 Sep 2004 11:11:34 -0700 (PDT) Received: from jvasseur-w2k01.cisco.com (che-vpn-cluster-1-95.cisco.com [10.86.240.95]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA19307; Sat, 4 Sep 2004 11:11:33 -0700 (PDT) Message-Id: <4.3.2.7.2.20040904140840.04652db8@wells.cisco.com> X-Sender: jvasseur@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 04 Sep 2004 14:11:30 -0400 To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be, dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be From: Jean Philippe Vasseur Subject: Re: [Pce] Fwd: PCE BOF minutes - IETF-60 - San Diego In-Reply-To: <41397EF8.305@psg.com> References: <4.3.2.7.2.20040902185100.0384dc90@wells.cisco.com> <4.3.2.7.2.20040902185100.0384dc90@wells.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 82b297dca242a35ee50ccecf5bf2e37f 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@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8aa7cbc518894eb04182283f0682f662 Hi Dimitri, At 10:38 AM 9/4/2004 +0200, dimitri papadimitriou wrote: >jp - see in-line: > >Jean Philippe Vasseur wrote: >>Hi, >>Please forward any correction/addition you may want to make on the minutes. >>JP. >> >>>Date: Thu, 02 Sep 2004 10:30:40 -0400 >>>To: proceedings@ietf.org >>>From: Jean Philippe Vasseur >>>Subject: PCE BOF minutes - IETF-60 - San Diego >>>Cc: adrian@olddog.co.uk, zinin@psg.com, bill Fenner >>> >>> >>>Minutes of the Path Computation Element BOF (pce) IETF-60 San Diego >>>############################################################# >>> >>>Chairs: JP Vasseur, Adrian Farrel >>>ADs: Alex Zinin, Bill Fenner >>> >>>*thanks to Dave Ward and Don Fedyk for their help taking notes* >>> >>>1) Agenda bashing, Admin and objectives - Adrian >>>********************************************************** >>> >>>2) Overview of PCE-based path computation - JP >>>********************************************************* >>>What is the BoF about ? What do we mean by PCE ? >>>PCE is an entity capable of compositing a path. Mainly we mean MPLS TE >>>for now but could expand to other (IP paths). >>>If you are computing a path for a loose hop you are a PCE. PCE examples: >>>Router, LSR, Server. >>>PCE is just an entity capable of doing some computation >>>Does not require centralized path computation. PCE can do distributed >>>computation. >>>One View: Each router is a PCE for it neighbors. >>>Could have a PCE where global optimization is required >>>Could be completely stateless or stateful >>>PCE approach is not necessarily the only approach but one approach >>>PCE suits a number of problem spaces. >>>Highlighting that PCE can be centralized or distributed model and need both >>> >>>3) Requirements for PCE-based path computation (_30 minutes_) Raymond >>>(Infonet), Kenji (KDDI), Jean-Louis (France Telecom), Seisho (NTT), >>>Jerry (ATT), Javier (Telefonica), Venkata (MCI) >>> >>>Raymond Zhang, Infonet >>>Case customer wants a guaranteed path that is delay sensitive. Problem >>>is there is high interconnect multi domain. Want to select paths with a >>>high degree of control. >>> >>>Kenji Kumaki, KDDI >>>Multi AS inter SP, Shortest end to end, Re-optimization, Multi IGP >>>areas, Re-optimization. These are difficult problems to solve. >>>Scalability issues with Routing and Signaling. >>> >>>Jean Louis Le Roux, France Telecom >>>Head end is sufficient for most., Complex routing conditions for P2 MP. >>>Multi constraint Backup Path. Inter domain path computation. Diverse >>>path computation. Could benefit from path computation element. Dedicated >>>tool, Centralized, Collaborative Useful for backup. >>> >>>High level requirements: Reliable signaling protocol, Automatic >>>discovery, Scalability, Balance the computational load, Distribute PCE >>>function, High Availability, Robustness. >>> >>>Question Dimitri Papadimitriou: is list detailing the PCE to PCE signaling? >>>JP: Yes >>>Dimitri: So 1st bullet is client to server signaling relationship? >>>JP: Yes good point load share requests but also need case where paths >>>are dependent on one another. >>> >>>Jerry Ash, AT&T >>>Requirements: Migrating to converged Network. >>>IP MPLS and all TDM to VoIP. These are the architecture plans, not >>>committed and being implemented. PCE is part of the plan. Inter area, >>>very large network need a solution that scales. Intra and inter AS. >>>Need shortest path across Network >>>Need standards based solution >>> >>>Seisho Yakukawa, NTT >>>Requirements: P2MP, IP-TV, Video, CPU intensive, P2MP, Inter-domain, >>>Need wider community, PCE approach is good. >>> >>>Arthi: PCE to PCE or LSR to PCE based on same protocols? >>>Adrian: Yet to be decided. Good Point. >>>Arthi :When we talk about signaling, is it query-reply or MPLS TE >>>signaling? >>>JP: query-reply, no change to TE LSP signalling >>>Igor: Two types of signaling: are they the same ? >>>Adrian: This is what we are deciding. Please wait for this. >>>Dimitri: The issue I see is there need for synchronization. There is a >>>need for coordination. >>>Adrian: Yes that is what we are discussing >>>?? You are going to have a discussion part a the end >>>JP:Yes. >>>Bijan Jabbari : Are you asking in the context of MPLS? >>>JP: Yes. >>>Bijan: This is related to some specific application. >>>JP:Yes >>> >>>Venkata Josyula, MCI >>>Requirements: Multiple AS, Hierarchical AS and be able to build AS, >>>Inter area PCE.. >>>Inter AS: Need a simple solution. Not saying you can use BGP next hops. >>>Do need TE Policy. Like the flexibility to coexist with other approaches. >>>JP: Interesting question. PCE could be used for inter areas and BGP for >>>inter AS (AS path selection). This is an Interesting point. >>> >>>4) Functional requirements of a PCE-based path computation system - JP >>>*************************************************************************************** >>>Functional requirements: >>>Multiple Models Picture: >>>Centralized, >>>Cooperative model PCE for one [or more] parts of the path. >>> >>> Distributed : Each node is a fully distributed PCE (example: >>> Backup Tunnel path comp). >>> >>>Discovery of the PCE in a network: >>>Static Provisioning >>> >>> Dynamic discovery computing resource (load sharing between >>> multiple PCEs) >>> >>>PCE may have routing adjacency with other nodes or may use some [other] >>>protocols) >>> >>>LSR-PCE Signaling: Interaction between the router and the PCE: RSVP, or >>>new protocol. Need to specify request and reply. >>>Arthi: On slide are PCE red circles. Are these the only PCEs? JP: No of >>>course not. >>> From this figure each LSR is a PCE or does it talk to other PCEs? >>>Adrian: If you have an Abstract node or a loose path you are using a PCE. >>>Arthi: This picture is not necessary the only view. It is not mandatory. >>>JP: It can be a server or a router itself. >>>Bijan: It can be [LSR]{missed it} or higher level than that? >>>?? It would be useful to have distinction between PCEs. Implement a LSR >>>as a distributed machinery with PCE and share the network with the data >>>network. >>>JP: We can discuss this. >>>?? Many, many approaches. Distributed path computation. Information is >>>not synchronized. If you do it on several path computation elements. >>>Adrian: Yes that is a problem. Clearly diverse path. Clearly not >>>produce loops. >>>?? Signaling protocol soft state?. RSVP-TE sounds like a funny approach. >>>Will there be others? >>>Adrian: Yes 5 proposals already ... >>>Alex. Clarification on slides please. >>>Ina: Do you have model ? Does the PCE have to run routing or not? Type >>>of discovery mechanism are a direct result of the model. >>>JP :Yes it is dependent. >>>Ping Pan: Inter domain. Great one [requirement]. What is the best >>>algorithm? That is independent. How you communicate. COPS, RADIUS >>>DIAMETER. Cisco scripts overnight. >>>JP: Not sure what you are trying to clarify. >>>Ping: You are limited to data path signaling. >>>Alex: Is it local to the box or cooperative [across boxes]? >>>JP: Inter domain must be standardized to some extent to compute an >>>inter-domain shortest path and avoid loops. Intra not necessary. >>>Ping: Preventing loop is one thing. >>>Alex: Cut line hold to discussion. >>> >>>JP: Policy, Security, Confidentiality. >>> >>>Adrian: Not here to discuss drafts good bad or WG drafts. Just want to >>>expose the drafts. If you have questions please go to authors not to >>>microphone. >>> >>>????: Does the LSR have to be the PCE? >>>JP: No, it can be another box. >>>????: Can PCEs be out of band? >>>JP: At end of meeting >>>????: Can we use this to find diverse paths? Can we use this for >>>cooperative model? Are there loops formed? >>>JP: Yes for diverse paths, no to loops, yes to cooperative >>>Sue Hares: Does the PCE have to participate in routing? >>>JP - It can >>> >>>5) Current status of drafts (_20 minutes_) - Several >>>******************************************************** >>>Background and framework drafts 4 >>>Requirements draft 1 >>>PCE Discovery (see IDs in CCAMP, ISIS and OSPF WGs) >>>PCE signaling 3 drafts >>>Modified TE Flooding >>>Applications 2 drafts >>> >>>Quick walk through the drafts - Minor clarifications and comments >>> >>>JP: No time to discuss the draft in detail by the way, not the >>>objective of this BOF. >>> >>>draft-leroux-pce-backup-comp-frwk-00.txt Jean-Louis >>>Nurit Sprecher: What is what the assumption for failure? A single failure? >>>JL: Yes this is reasonable. All networks are done this way. >>>Nurit: For multiple failures? >>>JL: This is to present one model for example. >>> >>>draft-oki-pce-gmpls-req-00.txt, Eiji Oki >>>Two kinds of requirements >>>PCE requirement: GMPLS and MPLS >>>Functionally separated from MPLS NODE >>>Provider can choose appropriate implementation. >>>Centralized and distributed. >>>Multi region TE in GMPLS >>>Interworking between MPLS and GMPLS. >>> >>>Hierarchical LSP setup. >>>Trigger by higher level LSP setup. PCE helps GMPLS node to setup >>>hierarchical LSP. >>>PCE Triggered LSP should be supported. Treat as single region network >>>from higher level. Standard Opaque TE information. Nodal requirement >>>PCE two request modes: Mandatory mode, Normal request node can ask own >>>node or PCE. >>> >>>Solution drafts >>>****************** >>> >>>draft-oki-ccamp-gtep-00.txt, Eiji Oki >>>Generalized TE protocol GTEP. >>>Features: >>>Support trigger hierarchical LSP setup >>>Support TEDB synchronization >>>Reliable transfer of larger data based on TCP >>>GTEP running code >>> >>>draft-vasseur-mpls-computation-rsvp-05.txt, Alia Atlas: >>>Extensions to RSVP-TE >>>Extend RSVP-TE a bit between the head end and the PCE. >>>Most of the stuff is there. >>>Request and reply message. >>>Some additional objects. >>>Drafts consider a number of different scenarios. >>> >>>draft-choi-pce-e2e-centralized-restoration-srlg-00.txt, Jun Kyun >>>Centralized control from optical network and GMPLS 50 Ms constraint. >>>Logical Ring configuration based on SRLG and PCE >>>Compatible with ASON architecture SG-15 >>>Simplifies and reduces management. >>> >>>Bijan Jabbari: 50 msec requirement is driving control not feasible. >>>Jun: Where is the location of the central controller. The requirement is >>>there. >>> >>>IDs related to P2MP >>>LSR PCE signaling required could be part of a general PCE >>> >>>IDs under construction - JP >>> >>> Requirements for signaling necessary Quick overview of >>> inter-domain QoS ID, Mohamed Boucadair >>>6) Discussion points, WG formation, possible goals and milestones? >>>Adrian, JP >>>********************************************************************************************* >>>JP: We need to discuss where can we do the work, what the scope is: MPLS >>>or IP as well? >>> >>>Adrian: Multiple components: Do we need a protocol at all ? Resolving how? >>>Alex: Do we have a good understanding ? >>> >>>Bijan Jabbari: Note that there are requirements from research networks >>>as well as SPs for Path Computation and routing >>> >>>Alex: PCE computations? >>>Bijan: Yes. >>>????: LSR or something like that? >>>Bijan: In optical network very complex. Loops are a problem and problems >>>are usually N-P complete. Complex. Requires a PCE. >>> >>>JP: Let's discuss whether we need new protocols? >>> >>>Zafar Ali: There is evidence for PCE needs/desires. Yes we should be >>>working on this in the IETF. >>> >>>Mark Hanley: Is spectrum too big? New routing architecture is evident >>>and watch how far you want to go. >>> >>>Alex: Lots of requirements however, from an architecture point of view >>>there is confusion. Are we separating out some non-forwarding pieces. >>> >>>Someone from Korea: Is scope limited to MPLS TE? >>> >>>JP: It includes GMPLS >>> >>>Arthi: Clear that SPs require this. Server SPs already have some >>>mechanisms. People may already have some form of this functionality. >>>How are people are going to cooperate? Who will change? How much will >>>existing mechanism affect what we do? >>> >>>Adrian: You are saying even if this a good idea we are too late? We may >>>be too late - Service provider can say. If we come up with a different >>>protocol will this have impact? Do you have strong opinion? >>> >>>Arthi: Yes should be done, but where? Don't know. Cannot standardize >>>computation algorithms. Don't think so. Differentiates on PCE from >>>[vendor to vendor] >>> >>>Mohamed Boucadair, France Telecom: the PCE control plane and forwarding >>>plane. If you have one element for this PCE it and element that manages >>>your inter domain resources. Inter-provider not arguing for this. What >>>we need the protocol in two different domains. >>> >>>Dimitri: Does it cover co-located PCE. Should the PCE talk to elements >>>of different vendors? What are changes expected to communicate >>>LSR<->PCE? How far do we change RSVP? Please add requirements doc. Must >>>have interoperability cleared up - don't get this. What about >>>scalability problems of PCE once all TEDB are combined. > >to complete the last item the question is also related to "PCE-PCE" >communication: does it require any information exchange a-priori or >would it only imply exchanges upon incoming request from LSR ? comment will be added to the minutes. >>>Zafar: Offline tools already present but, SP doesn't like them or not. >>> >>>Dima: We know there is a need. IETF should take it on. There should be a >>>new WG. There needs to be clarity on PCE being w/in the LSR or if the >>>PCE should be a router to participate. >>> >>>Francois LeFechaur: Clear requirements. We should do it. >>> >>>Bora A: How you communicate to the router. Only Standardized. Co-located >>>PCE on the router no different than what you do today. Comp SNMP TCL >>>scripts and we need another algorithm. I think RSVP-TE approach may be >>>the way to go. >>> >>>Igor: I agree [with Bora]. Protocol only. Formidable task. Standardizing >>>constraints is tough. I do believe we need to review the architecture. >>>SNMP like protocol is a better choice. >>> >>>Bjian: Need some form of centralization? >>>Adrian: Support centralization but not mandated >>>JP Yes. First slide. >>>Bijan: Distributed as well? Need multiple computation algorithms in the >>>PCE. However that does not need to be standard. >>>Alex: We have some experience documenting algorithms. Kireeti did >>>document an algorithm but this went [no where]. This could be done as >>>Informational >>> >>>Bijan - Is there centralization or not? There has to be both distributed >>>and centralized. >>> >>>Ina: Several people requirements and tools. Clear sign yes. Need for new >>>working group. Should PCE be part of an LSR or and independent element? >>> >>>Bora: Only thing that can be standardize is the communication, not >>>algorithms. Ok creating another WG but, there isn't a lot of work here. >>> >>>Igor: Only can standardize the communication between LSR and PCE. We >>>need the work, the WG and the architecture. Perhaps we should have a >>>configuration server like ATM. >>> >>>Richard Rabbat: Clearly requirements, take this on. Scope don't >>>standardize algorithm. Where. Stay in CCAMP. >>> >>>JP: Note that in some cases such as collaborative path computation, you >>>need to standardize algorithm to guarantee optimality (shortest path) >>>and prevent looping problems. >>> >>>Alia: We need signalling, we need architecture, we need resolve this, it >>>should not be CCAMP as that WG is swamped >>> >>>Hani: We should take on [new] WG >>> >>>Bruce Davie: Let's not standardize the algorithms but make sure we >>>specify it enough to make sure we don't have loops. Kireeti says that we >>>should use BGP. It should be a WG and w/in the IETF. >>> >>>Dimitri: The distributed model is difficult. Access of LSR to PCE. Next >>>hop path resolution protocol. Important aspect should determine what are >>>the based computation assumptions. Don't want one PCE then another PCE etc. > >please complete with: > >"concerning the "distributed PCE model" difficult to assess whether >referring to: >- distributed access to a single PCE (multiple entry points) >- when accessed PCE requires exchanges with other PCEs to deliver the > final result (computation for instance performed in sequence before > delivering the final result) -> "kind of" next hop path resolution > protocol >- computation itself can be distributed among several PCE (parallel)" > so an important aspect should also determine what are the base > computation assumptions ?." will also be added to the minutes. As you will see, the architecture ID should clearly address that point. As suggested by Alex, next step is to come up with a PCE architecture ID for which I would warmly encourage the members of this list to provide comments. A first cut of the ID is on its way and should be sent to the list in 2-3 weeks. JP. >>>Ping Pan: What is a domain? >>>Adrian: Have some input areas computation domain and protection >>>domains. Broad computation visibility. >>> >>>Summary >>>************ >>>Alex takes the mic: >>>Clearly there is a need >>>Clearly there is support for a solution >>>Confusion on what needs to be specified: communication, etc >>>Many requirements but quite diverse. Requirements good but so large. >>>What need to be standardized ? How this will affect the existing work ? >>>Tread very carefully and do architectural work so not to screw the internet >>>Heard strong opinion that we shouldn't standardize algorithms >>> >>>Steps >>>******** >>>Create mailing list - everyone will join >>>Need framework/arch doc(s) >>>Need to reduce requirements and present what will be covered >>>If we have something more complete by the next meting we will need >>>another BOF. >> >>------------------------------------------------------------------------ >>_______________________________________________ >>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@ietf.org Fri Sep 24 12:23:05 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21779; Fri, 24 Sep 2004 12:23:05 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAsxg-0004q0-K6; Fri, 24 Sep 2004 12:30:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAshQ-0005Br-In; Fri, 24 Sep 2004 12:13:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAsTg-0002Ay-69 for pce@megatron.ietf.org; Fri, 24 Sep 2004 11:59:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20302 for ; Fri, 24 Sep 2004 11:59:17 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAsah-0004Mv-EE for pce@ietf.org; Fri, 24 Sep 2004 12:06:35 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 24 Sep 2004 08:59:07 -0700 X-BrightmailFiltered: true Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i8OFwj3c018680; Fri, 24 Sep 2004 08:58:46 -0700 (PDT) Received: from [66.189.47.89] (rtp-vpn3-41.cisco.com [10.82.216.41]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id IAA23786; Fri, 24 Sep 2004 08:58:44 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v619) To: pce@ietf.org Message-Id: <9CF1708C-0E42-11D9-BF82-000D93330B14@cisco.com> From: JP Vasseur Date: Fri, 24 Sep 2004 11:58:44 -0400 X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Cc: "Jerry " Subject: [Pce] Fwd: Internet Draft for Publication 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="===============1051587751==" Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e --===============1051587751== Content-Type: multipart/alternative; boundary=Apple-Mail-8--377275800 --Apple-Mail-8--377275800 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Hi, One of the main action point required by Alex after the PCE BOF held in San Diego was to produce a PCE architecture document whose aim was to describe various possible PCE architectures and their components, provides application examples, and clarify the scope of the applicability of such path computation techniques. In particular, PCE-based path computation would not replace existing methods but could be used in some environments and for specific applications. In order to move forward, comments to this draft are very welcome. Adrian and I also received various emails mentioning that other PCE related IDs were on their way, so please authors, try to publish them prior to the next IETF so as to have enough time for comments and discussion. JP. Begin forwarded message: > From: grash@hello.mt.att.com > Date: September 24, 2004 11:28:43 AM EDT > To: internet-drafts@ietf.org > Cc: adrian@olddog.co.uk, gash@att.com, grash@hello.mt.att.com, > jpv@cisco.com > Subject: Internet Draft for Publication > > > To: Internet Drafts Editor > > Please publish the attached Internet Draft: > > draft-ash-pce-architecture-00.txt> > > Please announce the draft to the CCAMP working group. > > The attached file is in ASCII text. > > Thank you very much, > Jerry Ash > ----------------------------------------------------------------------- > ----- > Gerald R. (Jerry) Ash > AT&T Labs > Room MT D5-2A01 > 200 Laurel Avenue > Middletown, NJ 07748-4801 > U.S.A. > Telephone 732-420-4578 > Fax 732-368-8659 > E-mail gash@att.com > ----------------------------------------------------------------------- > ----- --Apple-Mail-8--377275800 Content-Type: text/enriched; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi, One of the main action point required by Alex after the PCE BOF held in San Diego was to produce a PCE architecture document whose aim was to describe various possible PCE architectures and their components, provides application examples, and clarify the scope of the applicability of such path computation techniques. In particular, PCE-based path computation would not replace existing methods but could be used in some environments and for specific applications. In order to move forward, comments to this draft are very welcome. Adrian and I also received various emails mentioning that other PCE related IDs were on their way, so please authors, try to publish them prior to the next IETF so as to have enough time for comments and discussion. JP. Begin forwarded message: Helvetica0000,0000,0000From: Helveticagrash@hello.mt.att.com 0000,0000,0000Date: September 24, 2004 11:28:43 AM EDT 0000,0000,0000To: internet-drafts@ietf.org 0000,0000,0000Cc: adrian@olddog.co.uk, gash@att.com, grash@hello.mt.att.com, jpv@cisco.com 0000,0000,0000Subject: Internet Draft for Publication < To: Internet Drafts Editor Please publish the attached Internet Draft: draft-ash-pce-architecture-00.txt> Please announce the draft to the CCAMP working group. The attached file is in ASCII text. Thank you very much, Jerry Ash ---------------------------------------------------------------------------- Gerald R. (Jerry) Ash AT&T Labs Room MT D5-2A01 200 Laurel Avenue Middletown, NJ 07748-4801 U.S.A. Telephone 732-420-4578 Fax 732-368-8659 E-mail gash@att.com ---------------------------------------------------------------------------- --Apple-Mail-8--377275800-- --===============1051587751== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============1051587751==-- From pce-bounces@ietf.org Fri Sep 24 17:15:39 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21270; Fri, 24 Sep 2004 17:15:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAxWu-00055v-2r; Fri, 24 Sep 2004 17:23:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAxCR-0005jO-CY; Fri, 24 Sep 2004 17:01:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAx1y-0002ip-IN for pce@megatron.ietf.org; Fri, 24 Sep 2004 16:51:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18981 for ; Fri, 24 Sep 2004 16:51:00 -0400 (EDT) Received: from almso2.att.com ([192.128.166.71] helo=almso2.proxy.att.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAx91-0004P6-KM for pce@ietf.org; Fri, 24 Sep 2004 16:58:20 -0400 Received: from attrh5i.attrh.att.com ([135.38.62.12]) by almso2.proxy.att.com (AT&T IPNS/MSO-5.5) with ESMTP id i8OKnZpJ008596 for ; Fri, 24 Sep 2004 16:50:26 -0400 Received: from kcclust06evs1.ugd.att.com (135.38.164.88) by attrh5i.attrh.att.com (7.1.006) id 414DAE590014AD71; Fri, 24 Sep 2004 16:50:26 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6561.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 24 Sep 2004 15:50:25 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA060C800F@KCCLUST06EVS1.ugd.att.com> Thread-Topic: Internet Draft Thread-Index: AcSiT2U1CVJLSdMwQTaPO+LEh3sLYAAKCO7A From: "Ash, Gerald R \(Jerry\), ALABS" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: quoted-printable Subject: [Pce] RE: Internet Draft 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@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: quoted-printable All, The I-D is now available at http://www.ietf.org/internet-drafts/draft-ash-pce-architecture-00.txt. Please read and comment. Thanks, Jerry ________________________________ From: JP Vasseur [mailto:jvasseur@cisco.com]=20 Sent: Friday, September 24, 2004 11:59 AM To: pce@ietf.org Cc: Adrian Farrel; Ash, Gerald R (Jerry), ALABS Subject: Fwd: Internet Draft for Publication Hi,=20 One of the main action point required by Alex after the PCE BOF held in San Diego was to produce a PCE architecture document whose aim was to describe various possible PCE architectures and their components, provide application examples, and clarify the scope of the applicability of such path computation techniques.=20 In particular, PCE-based path computation would not replace existing methods but could be used in some environments and for specific applications.=20 In order to move forward, comments to this draft are very welcome.=20 Adrian and I also received various emails mentioning that other PCE related IDs were on their way, so please authors, try to publish them prior to the next IETF so as to have enough time for comments and discussion.=20 JP=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Tue Sep 28 10:55:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27657; Tue, 28 Sep 2004 10:55:55 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCJWO-0002uB-1A; Tue, 28 Sep 2004 11:04:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCJMx-0004dY-S2; Tue, 28 Sep 2004 10:54:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCJKc-000435-Fo for pce@megatron.ietf.org; Tue, 28 Sep 2004 10:51:54 -0400 Received: from ilsmtp01.ecitele.com (ilsmtp01.ecitele.com [147.234.1.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27284 for ; Tue, 28 Sep 2004 10:51:51 -0400 (EDT) From: Lionel.Silman@ecitele.com To: pce@ietf.org X-Mailer: Lotus Notes Release 5.0.2b (Intl) 16 December 1999 Message-ID: Date: Tue, 28 Sep 2004 16:51:52 +0300 X-MIMETrack: Serialize by Router on ILSMTP01/ECI Telecom(Release 6.5.1|January 21, 2004) at 09/28/2004 16:55:31 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: [Pce] PCE-generated FRR Tunnel Interaction with Scheduling 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@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 This question / comment refers to the excellent document draft-leroux-pce-backup-comp-frwk-00. We want to use a Centralized PCE (namely an NMS) to calculate FRR bypass paths for MPLS-TE tunnels carefully taking into account bandwidth sharing. At the same time, we want to perform Dynamic Adjustment ( as per RFC 3564, Section 3.6) of Diff-Serv PHB Parameters (and other Traffic Management Parameters) in order to obtain required NE performance over full range of load per CoS. For this, Dynamic adjustment of Traffic Management parameters for each CoS should take into account the total (primary plus shared protection) load per CoS on each interface. The primary load is available to the the NE but it does not know the shared protection load. How should the NE dynamically adjust traffic parameters to take into account shared protection load per COS? I see it as desirable that:- * the bandwidth of the bypass tunnels be signaled or configured into each NE through which the bypass tunnel passes * there be an indication this tunnel is a bypass tunnel for which regular CAC is not performed But this does not allow it to calculate the shared protection load per CoS which is known only to the PCE. Section 10 (Interaction with Scheduling) does not seem to refer to the issue of NE derivation of shared protection load per CoS required for Dynamic Traffic Parameter adjustment. Does it assume no dynamic adjustment? ---------------------------------------------------------------------------------------------------- Lionel Silman, System, Optical Networks Division, ECI Telecom Tel Work: +972 (3) 9266007; Home: +972 (3) 6417464 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Tue Sep 28 13:59:40 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08196; Tue, 28 Sep 2004 13:59:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCMOD-0006Ly-OV; Tue, 28 Sep 2004 14:07:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCM0v-0002um-Ib; Tue, 28 Sep 2004 13:43:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCLuy-0001oT-VQ for pce@megatron.ietf.org; Tue, 28 Sep 2004 13:37:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06952 for ; Tue, 28 Sep 2004 13:37:33 -0400 (EDT) Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCM2n-0005vH-Pc for pce@ietf.org; Tue, 28 Sep 2004 13:45:45 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 28 Sep 2004 19:37:27 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE : [Pce] PCE-generated FRR Tunnel Interaction with Scheduling Date: Tue, 28 Sep 2004 19:37:26 +0200 Message-ID: Thread-Topic: [Pce] PCE-generated FRR Tunnel Interaction with Scheduling Thread-Index: AcSla0XKiWGGjEEeSxW/fdq1FLlh3wAAnr+A From: "LE ROUX Jean-Louis RD-CORE-LAN" To: , X-OriginalArrivalTime: 28 Sep 2004 17:37:27.0292 (UTC) FILETIME=[D26CB3C0:01C4A581] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: quoted-printable 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@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Content-Transfer-Encoding: quoted-printable Hi Lionel, Thanks a lot for these highly relevant remarks, you raised a good point. There are actually two options to achieve bandwith sharing at the = signaling level -Option 1: Signal backup LSPs with zero bandwidth. This allows no = extension to RSVP CAC, but requires a coordinated computation of the set = of bypass protecting a given facility, to avoid any bandwidth violation -Option 2: Signal backup LSPs with non zero bandwith. This requires = extensions to RSVP CAC (an object to identify backup tunnels, an object to indicate the = protected elements) In this first version we focused on option 1, as this requires no = extension to current LSP signaling, but note that the PCE-based backup = path computation framework applies equally to option 2. As you mention, using option 1, LSR have no idea of the amount of shared = bandwidth, and this precludes dynamic adjustement of PHB parameters. Such dynamic = adjustement can only be achieved with option 2. Actually, we could reuse RSVP extensions defined in CCAMP P&R documents, = to achieve option 2. You can signal bypass tunnels using the PROTECTION object, to indicate = that the LSP is a Bypass, and the PRIMARY_PATH_ROUTE object to indicate = the protected facility, and thus to allow computing the amount of shared = bandwidth. With such extension each LSR would known the shared protection load and = could adjust PHB parameters dynamically. Regards, JL >-----Message d'origine----- >De : pce-bounces@lists.ietf.org=20 >[mailto:pce-bounces@lists.ietf.org] De la part de=20 >Lionel.Silman@ecitele.com >Envoy=E9 : mardi 28 septembre 2004 15:52 >=C0 : pce@ietf.org >Objet : [Pce] PCE-generated FRR Tunnel Interaction with Scheduling > > > > > > >This question / comment refers to the excellent document=20 >draft-leroux-pce-backup-comp-frwk-00. > >We want to use a Centralized PCE (namely an NMS) to calculate=20 >FRR bypass paths for MPLS-TE tunnels carefully taking into=20 >account bandwidth sharing. > >At the same time, we want to perform Dynamic Adjustment ( as=20 >per RFC 3564, Section 3.6) of Diff-Serv PHB Parameters (and=20 >other Traffic Management >Parameters) in order to obtain required NE performance over=20 >full range of load per CoS. > >For this, Dynamic adjustment of Traffic Management parameters=20 >for each CoS should take into account the total (primary plus=20 >shared protection) load per CoS on each interface. The primary=20 >load is available to the the NE but it does not know the=20 >shared protection load. > >How should the NE dynamically adjust traffic parameters to=20 >take into account shared protection load per COS? > >I see it as desirable that:- >* the bandwidth of the bypass tunnels be signaled or=20 >configured into each NE through which the bypass tunnel passes >* there be an indication this tunnel is a bypass tunnel for=20 >which regular CAC is not performed > >But this does not allow it to calculate the shared protection=20 >load per CoS which is known only to the PCE. > >Section 10 (Interaction with Scheduling) does not seem to=20 >refer to the issue of NE derivation of shared protection load=20 >per CoS required for Dynamic Traffic Parameter adjustment.=20 >Does it assume no dynamic adjustment? >--------------------------------------------------------------- >------------------------------------- > >Lionel Silman, System, Optical Networks Division, ECI Telecom >Tel Work: +972 (3) 9266007; Home: +972 (3) 6417464 > > >_______________________________________________ >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@ietf.org Thu Sep 30 22:49:10 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26167; Thu, 30 Sep 2004 22:49:10 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDDcF-0002Cg-Td; Thu, 30 Sep 2004 22:57:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDDIo-00047O-Lh; Thu, 30 Sep 2004 22:37:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDDIP-0003lM-B7 for pce@megatron.ietf.org; Thu, 30 Sep 2004 22:37:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25265 for ; Thu, 30 Sep 2004 22:37:18 -0400 (EDT) Received: from mandala.kddilabs.jp ([192.26.91.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDDQl-0001y3-UC for pce@ietf.org; Thu, 30 Sep 2004 22:46:00 -0400 Received: from localhost (localhost [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id D668BECEC6 for ; Fri, 1 Oct 2004 11:36:39 +0900 (JST) Received: from platinum.onw.kddilabs.jp (platinum.onw.kddilabs.jp [2001:200:601:1300:172:19:83:254]) by mandala.kddilabs.jp (Postfix) with ESMTP id A244BECEB4 for ; Fri, 1 Oct 2004 11:36:39 +0900 (JST) Received: from OGINO-PC.kddilabs.jp (unknown [172.19.83.33]) by platinum.onw.kddilabs.jp (Postfix) with ESMTP id 5AD99578103 for ; Fri, 1 Oct 2004 11:33:31 +0900 (JST) Message-Id: <6.1.0.6.2.20041001105611.04525848@172.19.83.254> X-Sender: ogino@172.19.83.254 X-Mailer: QUALCOMM Windows Eudora Version 6J Jr4 Date: Fri, 01 Oct 2004 11:36:33 +0900 To: pce@ietf.org From: ogino Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Subject: [Pce] Submission of PCE draft 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@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Dear PCE BOF members, I submitted the attached short draft titled "Path Computation Model for Recovery LSPs Using External PCE". This draft describes a path computation model, where an external PCE exclusively preserving necessary TE information can compute efficient recovery LSP routes that promote bandwidth sharing between other recovery LSPs. Recovery schemes considered in this draft are the bandwidth protection for packet-LSPs and the shared-mesh restoration for all the types of TE-LSPs controlled by the GMPLS protocol suite. The abstract of the draft is as follows. "This document proposes a PC model, where the recovery LSP route in a domain is computed using an external PCE. Recovery LSP computation that promotes bandwidth sharing between other recovery LSPs requires unreserved bandwidth information that corresponds to each failure position or SRLG. However, the present IGP-TE can only advertise unreserved bandwidth information corresponding to eight priority classes to each LSR involved in an IGP area. An external PCE in a domain can compute efficient recovery LSP routes by exclusively preserving such unreserved bandwidth information without any extension of the present IGP-TE." I will be happy if you review this draft. Your comments and suggestions are very welcome. Best regards, Nagao Ogino ****************************** Nagao Ogino, Dr. Eng. KDDI R&D Laboratories Inc. 2-1-15 Ohara, Kamifukuoka-shi, Saitama 356-8502 Japan TEL +81 49 278 7860 FAX +81 49 278 7811 E-mail ogino@kddilabs.jp ****************************** _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Thu Sep 30 22:52:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26466; Thu, 30 Sep 2004 22:52:52 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDDfp-0002I8-Bf; Thu, 30 Sep 2004 23:01:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDDVM-0006wY-SM; Thu, 30 Sep 2004 22:50:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDDPO-0005BF-C1 for pce@megatron.ietf.org; Thu, 30 Sep 2004 22:44:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25839 for ; Thu, 30 Sep 2004 22:44:31 -0400 (EDT) Received: from mandala.kddilabs.jp ([192.26.91.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDDXk-00026w-6A for pce@ietf.org; Thu, 30 Sep 2004 22:53:13 -0400 Received: from localhost (localhost [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id D093FECF39 for ; Fri, 1 Oct 2004 11:44:01 +0900 (JST) Received: from platinum.onw.kddilabs.jp (platinum.onw.kddilabs.jp [2001:200:601:1300:172:19:83:254]) by mandala.kddilabs.jp (Postfix) with ESMTP id 8E23EECF37 for ; Fri, 1 Oct 2004 11:44:01 +0900 (JST) Received: from OGINO-PC.kddilabs.jp (unknown [172.19.83.33]) by platinum.onw.kddilabs.jp (Postfix) with ESMTP id 3EECF578103 for ; Fri, 1 Oct 2004 11:40:53 +0900 (JST) Message-Id: <6.1.0.6.2.20041001113746.0458fd28@172.19.83.254> X-Sender: ogino@172.19.83.254 X-Mailer: QUALCOMM Windows Eudora Version 6J Jr4 Date: Fri, 01 Oct 2004 11:43:58 +0900 To: pce@ietf.org From: ogino Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_8806687==_" X-Virus-Scanned: by amavisd-new X-Spam-Score: 0.0 (/) X-Scan-Signature: 210770d71723b650f9c8e3db4e95b596 Subject: [Pce] [Re] Submission of PCE draft 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@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 10e6cb90de4fe268e7150fb24857273b --=====================_8806687==_ Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit I am sorry. I have forgotten attaching the draft to the previous e-mail. I send this e-mail again. ****************************** Dear PCE BOF members, I submitted the attached short draft titled "Path Computation Model for Recovery LSPs Using External PCE". This draft describes a path computation model, where an external PCE exclusively preserving necessary TE information can compute efficient recovery LSP routes that promote bandwidth sharing between other recovery LSPs. Recovery schemes considered in this draft are the bandwidth protection for packet-LSPs and the shared-mesh restoration for all the types of TE-LSPs controlled by the GMPLS protocol suite. The abstract of the draft is as follows. "This document proposes a PC model, where the recovery LSP route in a domain is computed using an external PCE. Recovery LSP computation that promotes bandwidth sharing between other recovery LSPs requires unreserved bandwidth information that corresponds to each failure position or SRLG. However, the present IGP-TE can only advertise unreserved bandwidth information corresponding to eight priority classes to each LSR involved in an IGP area. An external PCE in a domain can compute efficient recovery LSP routes by exclusively preserving such unreserved bandwidth information without any extension of the present IGP-TE." I will be happy if you review this draft. Your comments and suggestions are very welcome. Best regards, Nagao Ogino ****************************** Nagao Ogino, Dr. Eng. KDDI R&D Laboratories Inc. 2-1-15 Ohara, Kamifukuoka-shi, Saitama 356-8502 Japan TEL +81 49 278 7860 FAX +81 49 278 7811 E-mail ogino@kddilabs.jp ****************************** --=====================_8806687==_ Content-Type: application/octet-stream; name="draft-ogino-pce-recovery-pc-model-00.txt"; x-mac-type="54455854"; x-mac-creator="74747874" Content-Disposition: attachment; filename="draft-ogino-pce-recovery-pc-model-00.txt" Content-Transfer-Encoding: base64 DQoNCiAgIFBDRSBCT0YgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIA0KICAgSW50ZXJuZXQgRHJhZnQgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgTmFnYW8gT2dpbm8gDQogICBQcm9wb3NlZCBTdGF0dXM6 IEluZm9ybWF0aW9uYWwgICAgICAgICAgICAgICAgICAgICAgICBLRERJIFImRCBMYWJzLiANCiAg IEV4cGlyZXM6IE1hcmNoIDIwMDUgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFNl cHRlbWJlciAyMDA0IA0KICAgIA0KICAgIA0KICAgICAgICBQYXRoIENvbXB1dGF0aW9uIE1vZGVs IGZvciBSZWNvdmVyeSBMU1BzIFVzaW5nIEV4dGVybmFsIFBDRSANCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgIGRyYWZ0LW9naW5vLXBjZS1y ZWNvdmVyeS1wYy1tb2RlbC0wMC50eHQgDQogICAgDQogICAgDQpTdGF0dXMgb2YgdGhpcyBNZW1v IA0KICAgIA0KICAgVGhpcyBkb2N1bWVudCBpcyBhbiBJbnRlcm5ldC1EcmFmdCBhbmQgaXMgc3Vi amVjdCB0byBhbGwgcHJvdmlzaW9ucyANCiAgIG9mIHNlY3Rpb24gMyBvZiBSRkMgMzY2Ny4gQnkg c3VibWl0dGluZyB0aGlzIEludGVybmV0LURyYWZ0LCBlYWNoIA0KICAgYXV0aG9yIHJlcHJlc2Vu dHMgdGhhdCBhbnkgYXBwbGljYWJsZSBwYXRlbnQgb3Igb3RoZXIgSVBSIGNsYWltcyBvZiANCiAg IHdoaWNoIGhlIG9yIHNoZSBpcyBhd2FyZSBoYXZlIGJlZW4gb3Igd2lsbCBiZSBkaXNjbG9zZWQs IGFuZCBhbnkgb2YgDQogICB3aGljaCBoZSBvciBzaGUgYmVjb21lIGF3YXJlIHdpbGwgYmUgZGlz Y2xvc2VkLCBpbiBhY2NvcmRhbmNlIHdpdGggDQogICBSRkMgMzY2OC4gDQogICAgDQogICBJbnRl cm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVl cmluZyANCiAgIFRhc2sgRm9yY2UgKElFVEYpLCBpdHMgYXJlYXMsIGFuZCBpdHMgd29ya2luZyBn cm91cHMuIE5vdGUgdGhhdCBvdGhlciANCiAgIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmlidXRlIHdv cmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LURyYWZ0cy4gDQogICAgDQogICBJbnRlcm5ldC1E cmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBtb250 aHMgDQogICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3Ro ZXIgZG9jdW1lbnRzIGF0IGFueSANCiAgIHRpbWUuIEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNl IEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2UgDQogICBtYXRlcmlhbCBvciB0byBjaXRlIHRo ZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iIA0KICAgIA0KICAgVGhlIGxpc3Qg b2YgY3VycmVudCBJbnRlcm5ldC1EcmFmdHMgY2FuIGJlIGFjY2Vzc2VkIGF0IA0KICAgICAgICBo dHRwOi8vd3d3LmlldGYub3JnL2lldGYvMWlkLWFic3RyYWN0cy50eHQuIA0KICAgIA0KICAgVGhl IGxpc3Qgb2YgSW50ZXJuZXQtRHJhZnQgU2hhZG93IERpcmVjdG9yaWVzIGNhbiBiZSBhY2Nlc3Nl ZCBhdCANCiAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbC4gDQogICAgDQog ICBUaGlzIEludGVybmV0LURyYWZ0IHdpbGwgZXhwaXJlIG9uIE1hcmNoIDIwMDUuIA0KICAgIA0K ICAgQ29weXJpZ2h0IE5vdGljZSANCiAgICANCiAgIENvcHlyaWdodCAoQykgVGhlIEludGVybmV0 IFNvY2lldHkgKDIwMDQpLiANCiAgICANCiAgICANCkFic3RyYWN0IA0KICAgIA0KICAgVGhpcyBk b2N1bWVudCBwcm9wb3NlcyBhIFBDIG1vZGVsLCB3aGVyZSB0aGUgcmVjb3ZlcnkgTFNQIHJvdXRl IGluIGEgDQogICBkb21haW4gaXMgY29tcHV0ZWQgdXNpbmcgYW4gZXh0ZXJuYWwgUENFLiBSZWNv dmVyeSBMU1AgY29tcHV0YXRpb24gDQogICB0aGF0IHByb21vdGVzIGJhbmR3aWR0aCBzaGFyaW5n IGJldHdlZW4gb3RoZXIgcmVjb3ZlcnkgTFNQcyByZXF1aXJlcyANCiAgIHVucmVzZXJ2ZWQgYmFu ZHdpZHRoIGluZm9ybWF0aW9uIHRoYXQgY29ycmVzcG9uZHMgdG8gZWFjaCBmYWlsdXJlIA0KICAg cG9zaXRpb24gb3IgU1JMRy4gSG93ZXZlciwgdGhlIHByZXNlbnQgSUdQLVRFIGNhbiBvbmx5IGFk dmVydGlzZSANCiAgIHVucmVzZXJ2ZWQgYmFuZHdpZHRoIGluZm9ybWF0aW9uIGNvcnJlc3BvbmRp bmcgdG8gZWlnaHQgcHJpb3JpdHkgDQogDQogDQpPZ2lubyAgICAgICAgICAgICAgICAgICAgRXhw aXJlcyAtIE1hcmNoIDIwMDUgICAgICAgICAgICAgICAgIFtQYWdlIDFdIA0KDEludGVybmV0IERy YWZ0PGRyYWZ0LW9naW5vLXBjZS1yZWNvdmVyeS1wYy1tb2RlbC0wMC50eHQ+IFNlcHRlbWJlciAy MDA0IA0KIA0KIA0KICAgY2xhc3NlcyB0byBlYWNoIExTUiBpbnZvbHZlZCBpbiBhbiBJR1AgYXJl YS4gQW4gZXh0ZXJuYWwgUENFIGluIGEgDQogICBkb21haW4gY2FuIGNvbXB1dGUgZWZmaWNpZW50 IHJlY292ZXJ5IExTUCByb3V0ZXMgYnkgZXhjbHVzaXZlbHkgDQogICBwcmVzZXJ2aW5nIHN1Y2gg dW5yZXNlcnZlZCBiYW5kd2lkdGggaW5mb3JtYXRpb24gd2l0aG91dCBhbnkgDQogICBleHRlbnNp b24gb2YgdGhlIHByZXNlbnQgSUdQLVRFLiANCiAgICANCiAgICANCkNvbnZlbnRpb25zIHVzZWQg aW4gdGhpcyBkb2N1bWVudCANCiAgICANCiAgIFRoZSBrZXkgd29yZHMgIk1VU1QiLCAiTVVTVCBO T1QiLCAiUkVRVUlSRUQiLCAiU0hBTEwiLCAiU0hBTEwgTk9UIiwgDQogICAiU0hPVUxEIiwgIlNI T1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAiTUFZIiwgYW5kICJPUFRJT05BTCIgaW4gdGhpcyAN CiAgIGRvY3VtZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQgaW4gUkZDIDIx MTkgW1JGQzIxMTldLiANCiAgICANCiAgICANClRhYmxlIG9mIENvbnRlbnRzIA0KICAgIA0KICAg MS4gSW50cm9kdWN0aW9uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uMiANCiAgIDIuIFByaW5jaXBsZSBvZiBSZWNvdmVyeSBQYXRoIENvbXB1dGF0aW9u IE1vZGVsLi4uLi4uLi4uLi4uLi4uLi4uLjMgDQogICAzLiBSZWNvdmVyeSBQYXRoIENvbXB1dGF0 aW9uIFByb2NlZHVyZS4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi40IA0KICAgNC4gUmVjb3Zl cnkgUGF0aCBDb21wdXRhdGlvbiBFeGFtcGxlLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u NSANCiAgIDUuIFNjYWxhYmlsaXR5IENvbnNpZGVyYXRpb25zLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLjggDQogICA2LiBTZWN1cml0eSBDb25zaWRlcmF0aW9ucy4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi44IA0KICAgNy4gSUFOQSBDb25zaWRlcmF0 aW9ucy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uOCANCiAgIDgu IEFja25vd2xlZGdlbWVudHMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLjggDQogICA5LiBSZWZlcmVuY2VzLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi44IA0KICAgICAgOS4xIE5vcm1hdGl2ZSBSZWZlcmVuY2Vz Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uOCANCiAgICAgIDkuMiBJbmZv cm1hdGlvbmFsIFJlZmVyZW5jZXMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjkg DQogICAxMC4gQXV0aG9ycycgQWRkcmVzc2VzLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi45IA0KICAgMTEuIEludGVsbGVjdHVhbCBQcm9wZXJ0eSBTdGF0ZW1lbnQu Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uOSANCiAgICAgIDExLjEgSVBSIERpc2Nsb3N1 cmUgQWNrbm93bGVkZ2VtZW50Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTAgDQogICAxMi4g RnVsbCBDb3B5cmlnaHQgU3RhdGVtZW50Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLjEwIA0KICAgIA0KICAgIA0KMS4gSW50cm9kdWN0aW9uIA0KICAgIA0KICAgUGF0aCBDb21w dXRhdGlvbiBFbGVtZW50IChQQ0UpIFtQQ0UtQVJDSElURUNUVVJFLCBQQ0UtUFJPQkxFTV0gaXMg DQogICBpbmRpc3BlbnNhYmxlIHdoZW4gcGF0aCBjb21wdXRhdGlvbiByZXF1aXJlcyBUcmFmZmlj IEVuZ2luZWVyaW5nIChURSkgDQogICBpbmZvcm1hdGlvbiB0aGF0IGNhbm5vdCBiZSBhZHZlcnRp c2VkIGJ5IHJvdXRpbmcgcHJvdG9jb2xzLiBGb3IgYW4gDQogICBleGFtcGxlLCBwYXRoIGNvbXB1 dGF0aW9uIGluIGEgZG9tYWluIG1heSByZXF1aXJlIFRFIGluZm9ybWF0aW9uIHRoYXQgDQogICBj YW5ub3QgYmUgYWR2ZXJ0aXNlZCB0byBvdGhlciBkb21haW5zIGJ5IHRoZSBwcmVzZW50IGludGVy LWRvbWFpbiANCiAgIHJvdXRpbmcgcHJvdG9jb2xzIFtCR1AtNF0uIEluIHRoaXMgY2FzZSwgb25s eSBQQ0UgaW52b2x2ZWQgaW4gdGhhdCANCiAgIGRvbWFpbiBjYW4gY29tcHV0ZSBhbiBvcHRpbWFs IExhYmVsLVN3aXRjaGVkIFBhdGggKExTUCkgcm91dGUgaW4gdGhlIA0KICAgZG9tYWluIHdpdGhv dXQgYW55IGV4dGVuc2lvbiBvZiB0aGUgaW50ZXItZG9tYWluIHJvdXRpbmcgcHJvdG9jb2xzIA0K ICAgW0lOVEVSLURPTUFJTi1GUkFNRVdPUkssIElOVEVSLURPTUFJTi1QQVRILUNPTVBdLiBMaWtl d2lzZSwgcGF0aCANCiAgIGNvbXB1dGF0aW9uIGluIGEgZG9tYWluIG1heSByZXF1aXJlIFRFIGlu Zm9ybWF0aW9uIHRoYXQgY2Fubm90IGJlIA0KICAgYWR2ZXJ0aXNlZCB0byBlYWNoIExhYmVsIFN3 aXRjaGluZyBSb3V0ZXIgKExTUikgaW4gdGhlIGRvbWFpbiBieSB0aGUgDQogICBwcmVzZW50IGlu dHJhLWRvbWFpbiByb3V0aW5nIHByb3RvY29scy4gSW4gdGhpcyBjYXNlLCBhbiBleHRlcm5hbCBQ Q0UgDQogICBpbiB0aGUgZG9tYWluIGNhbiBjb21wdXRlIGFuIGVmZmljaWVudCBMU1Agcm91dGUg YnkgZXhjbHVzaXZlbHkgDQogICBwcmVzZXJ2aW5nIHN1Y2ggcmVxdWlyZWQgVEUgaW5mb3JtYXRp b24gd2l0aG91dCBhbnkgZXh0ZW5zaW9uIG9mIHRoZSANCiAgIGludHJhLWRvbWFpbiByb3V0aW5n IHByb3RvY29scy4gDQogDQogDQpPZ2lubyAgICAgICAgICAgICAgICAgICAgRXhwaXJlcyAtIE1h cmNoIDIwMDUgICAgICAgICAgICAgICAgIFtQYWdlIDJdIA0KDEludGVybmV0IERyYWZ0PGRyYWZ0 LW9naW5vLXBjZS1yZWNvdmVyeS1wYy1tb2RlbC0wMC50eHQ+IFNlcHRlbWJlciAyMDA0IA0KIA0K IA0KICAgIA0KICAgVGhpcyBkb2N1bWVudCBwcm9wb3NlcyBhIFBDIG1vZGVsLCB3aGVyZSByZWNv dmVyeSBMU1Agcm91dGUgaW4gYSANCiAgIGRvbWFpbiBpcyBjb21wdXRlZCB1c2luZyBhbiBleHRl cm5hbCBQQ0UuIFJlY292ZXJ5IExTUCBjb21wdXRhdGlvbiANCiAgIHRoYXQgcHJvbW90ZXMgYmFu ZHdpZHRoIHNoYXJpbmcgYmV0d2VlbiBvdGhlciByZWNvdmVyeSBMU1BzIHJlcXVpcmVzIA0KICAg dW5yZXNlcnZlZCBiYW5kd2lkdGggaW5mb3JtYXRpb24gdGhhdCBjb3JyZXNwb25kcyB0byBlYWNo IGZhaWx1cmUgDQogICBwb3NpdGlvbiBvciBTUkxHLiBIb3dldmVyLCB0aGUgcHJlc2VudCBJR1At VEUgY2FuIG9ubHkgYWR2ZXJ0aXNlIA0KICAgdW5yZXNlcnZlZCBiYW5kd2lkdGggaW5mb3JtYXRp b24gY29ycmVzcG9uZGluZyB0byBlaWdodCBwcmlvcml0eSANCiAgIGNsYXNzZXMgdG8gZWFjaCBM U1IgaW52b2x2ZWQgaW4gYW4gSUdQIGFyZWEgW09TUEYtVEUsIElTLUlTLVRFXS4gQW4gDQogICBl eHRlcm5hbCBQQ0UgaW4gYSBkb21haW4gY2FuIGNvbXB1dGUgZWZmaWNpZW50IHJlY292ZXJ5IExT UCByb3V0ZXMgYnkgDQogICBleGNsdXNpdmVseSBwcmVzZXJ2aW5nIHN1Y2ggdW5yZXNlcnZlZCBi YW5kd2lkdGggaW5mb3JtYXRpb24gd2l0aG91dCANCiAgIGFueSBleHRlbnNpb24gb2YgdGhlIHBy ZXNlbnQgSUdQLVRFLiBIZXJlLCBhIGRvbWFpbiBpcyBjb25zaWRlcmVkIHRvIA0KICAgaW5jbHVk ZSBhIHdvcmtpbmcgTFNQIHNlZ21lbnQgdGhhdCBjYW4gYmUgcHJvdGVjdGVkIGJ5IGEgcmVjb3Zl cnkgTFNQLiANCiAgICANCiAgICANCjIuIFByaW5jaXBsZSBvZiBSZWNvdmVyeSBQYXRoIENvbXB1 dGF0aW9uIE1vZGVsIA0KICAgIA0KICAgSW4gdGhpcyBkb2N1bWVudCwgdGhlIGJhbmR3aWR0aCBw cm90ZWN0aW9uIGZvciBwYWNrZXQtTFNQcyBhbmQgDQogICBzaGFyZWQtbWVzaCByZXN0b3JhdGlv biBmb3IgYWxsIG9mIHRoZSBURS1MU1BzIGFyZSBjb25zaWRlcmVkIHRvIGJlIA0KICAgcmVjb3Zl cnkgc2NoZW1lcyBbUkVDT1ZFUlktVEVSTUlOT0xPR1ldLiBJbiB0aG9zZSByZWNvdmVyeSBzY2hl bWVzLCANCiAgIHJlY292ZXJ5IExTUHMgY2FuIHNoYXJlIHRoZSBsaW5rIGJhbmR3aWR0aCBpZiB0 aGUgcHJvdGVjdGVkIHNlZ21lbnRzIA0KICAgb2Ygd29ya2luZyBMU1BzIGFyZSBuZXZlciBleHBv c2VkIHRvIGRhbWFnZSBhdCB0aGUgc2FtZSB0aW1lIA0KICAgW1JFQ09WRVJZLUFOQUxZU0lTXS4g QSBQQ0UgY2FuIGNvbXB1dGUgZWZmaWNpZW50IGJhY2t1cCBMU1Agcm91dGVzIA0KICAgdGhhdCBl bnN1cmUgc3VjaCBsaW5rIGJhbmR3aWR0aCBzaGFyaW5nIGluIHRoZSBjb250ZXh0IG9mIGZhc3Qg DQogICByZXJvdXRlIGJhbmR3aWR0aCBwcm90ZWN0aW9uIG9mIHBhY2tldC1MU1BzIFtQQ0UtQkFD S1VQLUNPTVAtRlJXS10uIA0KICAgQW4gZXh0ZXJuYWwgUENFIGluIGEgZG9tYWluIGNhbiBjb21w dXRlIGVmZmljaWVudCByZWNvdmVyeSBMU1Agcm91dGVzIA0KICAgdGhhdCBwcm9tb3RlIHN1Y2gg bGluayBiYW5kd2lkdGggc2hhcmluZyB3aXRob3V0IGFueSBleHRlbnNpb24gb2YgdGhlIA0KICAg cHJlc2VudCBJR1AtVEUuIEEgd29ya2luZyBMU1AgaXMgY29tcG9zZWQgb2Ygc2V2ZXJhbCBzZWdt ZW50cyBhbmQgDQogICBlYWNoIHNlZ21lbnQgaXMgcHJvdGVjdGVkIGJ5IGEgcmVjb3ZlcnkgTFNQ LiAgVGhvdWdoIGEgc2luZ2xlIHNlZ21lbnQgDQogICBpcyBuZXZlciBpbnZvbHZlZCBpbiB0d28g ZG9tYWlucywgbXVsdGlwbGUgc2VnbWVudHMgbWF5IGJlIGluY2x1ZGVkIA0KICAgaW4gYSBzaW5n bGUgZG9tYWluLiANCiAgICANCiAgIEEgd29ya2luZyBMU1AgYWx3YXlzIG9jY3VwaWVzIHRoZSBs aW5rIGJhbmR3aWR0aC4gSG93ZXZlciwgYSByZWNvdmVyeSANCiAgIExTUCBvY2N1cGllcyB0aGUg bGluayBiYW5kd2lkdGggb25seSB3aGVuIHRoZSBjb3JyZXNwb25kaW5nIHdvcmtpbmcgDQogICBM U1Agc2VnbWVudCBpbmN1cnMgZGFtYWdlLiBUaHVzLCB0aGUgbGluayBiYW5kd2lkdGggYWN0dWFs bHkgdXRpbGl6ZWQgDQogICBjaGFuZ2VzIGFjY29yZGluZyB0byB3aGV0aGVyIHRoZSBhY2NvbW1v ZGF0ZWQgcmVjb3ZlcnkgTFNQcyBhcmUgDQogICBjb252ZXlpbmcgdGhlIHByb3RlY3RlZCB0cmFm ZmljIG9yIG5vdC4gRGVzaWduYXRpbmcgdGhlIHVub2NjdXBpZWQgDQogICBsaW5rIGJhbmR3aWR0 aCBieSAidW5yZXNlcnZlZCBiYW5kd2lkdGgiLCBpdHMgZXh0ZW50IHdpdGhpbiBhIGxpbmsgDQog ICBkZXBlbmRzIG9uIHRoZSBvY2N1cnJlbmNlIG9mIGFueSBmYWlsdXJlIGFuZCB0aGUgcG9zaXRp b24gb2YgdGhhdCANCiAgIGZhaWx1cmUsIGV2ZW4gaWYgdGhlIGFjY29tbW9kYXRlZCBMU1BzIGlu IHRoYXQgbGluayByZW1haW4gdW5jaGFuZ2VkLiANCiAgIExpbmsgYmFuZHdpZHRoIGF2YWlsYWJs ZSBmb3IgYSByZWNvdmVyeSBMU1AgaXMgYSBmYWN0b3Igb2YgbGluayANCiAgIGZhaWx1cmVzIHRo YXQgdGhlIGNvcnJlc3BvbmRpbmcgd29ya2luZyBMU1AgbWF5IGluY3VyIGluIHRoZSBjYXNlIG9m IA0KICAgbGluayBwcm90ZWN0aW9uLiBUaGVzZSwgaW4gdHVybiwgYXJlIHRyaWdnZXJlZCBieSBu b2RlIGZhaWx1cmVzIHRoYXQgDQogICBtYXkgb2NjdXIgd2l0aGluIHRoZSBjb3JyZXNwb25kaW5n IHdvcmtpbmcgTFNQIGluIHRoZSBjYXNlIG9mIG5vZGUgDQogICBwcm90ZWN0aW9uLCBhbmQgZGVj aWRlZCBieSBTaGFyZWQgUmlzayBMaW5rIEdyb3VwcyAoU1JMR3MpIHRoYXQgdGhlIA0KICAgY29y cmVzcG9uZGluZyB3b3JraW5nIExTUCBiZWxvbmdzIHRvIGluIHRoZSBjYXNlIG9mIHRoZSBTUkxH IA0KICAgcHJvdGVjdGlvbi4gSGVyZSwgdGhlIFNSTEdzIHRoYXQgYW4gTFNQIGJlbG9uZ3MgdG8g YXJlIGRlZmluZWQgYXMgYW4gDQogICBTUkxHIGFnZ3JlZ2F0aW9uIHRoYXQgdGhlIGxpbmtzIGFj Y29tbW9kYXRpbmcgdGhlIExTUCBiZWxvbmcgdG8uIA0KICAgIA0KDQogDQogDQpPZ2lubyAgICAg ICAgICAgICAgICAgICAgRXhwaXJlcyAtIE1hcmNoIDIwMDUgICAgICAgICAgICAgICAgIFtQYWdl IDNdIA0KDEludGVybmV0IERyYWZ0PGRyYWZ0LW9naW5vLXBjZS1yZWNvdmVyeS1wYy1tb2RlbC0w MC50eHQ+IFNlcHRlbWJlciAyMDA0IA0KIA0KIA0KICAgTW9yZW92ZXIsIHJlY292ZXJ5IExTUHMg Y2FuIHNoYXJlIHRoZSBsaW5rIGJhbmR3aWR0aCBpZiB0aGUgcHJvdGVjdGVkIA0KICAgc2VnbWVu dHMgb2Ygd29ya2luZyBMU1BzIGFyZSBuZXZlciBzaW11bHRhbmVvdXNseSBleHBvc2VkIHRvIGRh bWFnZS4gDQogICBXaGVuIGxpbmsgYmFuZHdpZHRoIGF2YWlsYWJsZSBmb3IgYSByZWNvdmVyeSBM U1AgZXhjZWVkcyB0aGUgbWluaW11bSANCiAgIHVucmVzZXJ2ZWQgYmFuZHdpZHRoIGluIHRoYXQg bGluaywgdGhlIHJlY292ZXJ5IExTUCBjYW4gc2hhcmUgdGhlIA0KICAgbGluayBiYW5kd2lkdGgg d2l0aCBvdGhlciByZWNvdmVyeSBMU1BzIGFjY29tbW9kYXRlZCBpbiB0aGUgc2FtZSBsaW5rLiAN CiAgIElmIHRoZSB2b2x1bWUgb2YgdGhlIG1pbmltdW0gdW5yZXNlcnZlZCBiYW5kd2lkdGggYW5k IHRoYXQgYXZhaWxhYmxlIA0KICAgZm9yIGEgbmV3bHkgcmVxdWVzdGVkIHJlY292ZXJ5IExTUCBj YW4gYmUga25vd24sIHRoZSBiYW5kd2lkdGggcmF0ZSANCiAgIGF0IHdoaWNoIHRoZSBuZXdseSBy ZXF1ZXN0ZWQgcmVjb3ZlcnkgTFNQIGNhbiBzaGFyZSB0aGUgbGluayANCiAgIGJhbmR3aWR0aCB3 aXRoIG90aGVyIGFjY29tbW9kYXRlZCByZWNvdmVyeSBMU1BzIGNhbiBiZSBjYWxjdWxhdGVkLiAN CiAgIEJhbmR3aWR0aCBzaGFyaW5nIGNhbiBiZSBwcm9tb3RlZCBieSByZWR1Y2luZyB0aGUgbGlu ayB3ZWlnaHQgYXMgdGhlIA0KICAgYmFuZHdpZHRoIHNoYXJpbmcgcmF0ZSBiZWNvbWVzIGxhcmdl ci4gDQogICAgDQogICBBcyBkZXNjcmliZWQgYWJvdmUsIHJlY292ZXJ5IExTUCBjb21wdXRhdGlv biB0aGF0IHByb21vdGVzIGJhbmR3aWR0aCANCiAgIHNoYXJpbmcgYmV0d2VlbiByZWNvdmVyeSBM U1BzIHJlcXVpcmVzIHVucmVzZXJ2ZWQgYmFuZHdpZHRoIA0KICAgaW5mb3JtYXRpb24gY29ycmVz cG9uZGluZyB0byBlYWNoIGxpbmsgZmFpbHVyZSwgZWFjaCBub2RlIGZhaWx1cmUsIA0KICAgYW5k IGVhY2ggU1JMRy4gSG93ZXZlciwgdGhlIHByZXNlbnQgSUdQLVRFIGNhbiBvbmx5IGFkdmVydGlz ZSANCiAgIHVucmVzZXJ2ZWQgYmFuZHdpZHRoIGluZm9ybWF0aW9uIGNvcnJlc3BvbmRpbmcgdG8g ZWlnaHQgcHJpb3JpdHkgDQogICBjbGFzc2VzIHRvIGVhY2ggTFNSIGludm9sdmVkIGluIGFuIElH UCBhcmVhIFtPU1BGLVRFLCBJUy1JUy1URV0uIEFuIA0KICAgZXh0ZXJuYWwgZG9tYWluLWJhc2Vk IFBDRSBjYW4gYWNoaWV2ZSB0aGUgYWZvcmVtZW50aW9uZWQgZWZmaWNpZW50IA0KICAgcmVjb3Zl cnkgTFNQIGNvbXB1dGF0aW9uIHRocm91Z2ggZXhjbHVzaXZlIHByZXNlcnZhdGlvbiBvZiB1bnJl c2VydmVkIA0KICAgYmFuZHdpZHRoIGluZm9ybWF0aW9uIHdpdGhvdXQgYW55IGV4dGVuc2lvbiBv ZiB0aGUgcHJlc2VudCBJR1AtVEUuIA0KICAgIA0KICAgIA0KMy4gUmVjb3ZlcnkgUGF0aCBDb21w dXRhdGlvbiBQcm9jZWR1cmUgDQogICAgDQogICBUaGUgaGVhZC1lbmQgTFNSIG9mIHJlY292ZXJh YmxlIFRFLUxTUCwgaW5ncmVzcyBMU1IgaW50byB0aGUgZG9tYWluLCANCiAgIGFuZCBQQ0VzIGlu IG90aGVyIGRvbWFpbnMgbWF5IHJlcXVlc3QgcGF0aCBjb21wdXRhdGlvbiB0byBhbiBleHRlcm5h bCANCiAgIFBDRSBbSU5URVItRE9NQUlOLVJTVlAtVEVdLiBUaGUgZXh0ZXJuYWwgUENFIGNvbXB1 dGVzIGEgcm91dGUgZm9yIGEgDQogICB3b3JraW5nIExTUCBzZWdtZW50IGFuZCB0aGUgY29ycmVz cG9uZGluZyByZWNvdmVyeSBMU1AgcmVzcGVjdGl2ZWx5LiANCiAgIEZpcnN0bHksIHRoZSBleHRl cm5hbCBQQ0UgY29tcHV0ZXMgYSByb3V0ZSBmb3IgdGhlIHdvcmtpbmcgTFNQIA0KICAgc2VnbWVu dCBiYXNlZCBvbiB0aGUgb3JpZ2luYXRpbmcgYW5kIHRlcm1pbmF0aW5nIExTUnMgb2YgdGhlIExT UCANCiAgIHNlZ21lbnQgZGVzaWduYXRlZCBieSB0aGUgcmVxdWVzdGVyLiBCZWNhdXNlIHRoZSBh dmFpbGFibGUgYmFuZHdpZHRoIA0KICAgZm9yIGEgd29ya2luZyBMU1AgaXMgdGhlIG1pbmltdW0g dW5yZXNlcnZlZCBiYW5kd2lkdGgsIGxpbmtzIHdpdGggDQogICBtaW5pbXVtIHVucmVzZXJ2ZWQg YmFuZHdpZHRoIGFtb3VudGluZyB0byBsZXNzIHRoYW4gdGhlIHdvcmtpbmcgTFNQIA0KICAgYmFu ZHdpZHRoIGFyZSByZW1vdmVkLiBUaGVuLCB0aGUgc2hvcnRlc3QgcGF0aCBpcyBzZWxlY3RlZCBh cyB0aGUgDQogICByb3V0ZSBmb3IgYSB3b3JraW5nIExTUCBzZWdtZW50LiBUaGUgZXh0ZXJuYWwg UENFIGRlY3JlYXNlcyBhbGwgb2YgDQogICB0aGUgdW5yZXNlcnZlZCBiYW5kd2lkdGggdm9sdW1l cyBpbiB0aGUgbGlua3MgbmV3bHkgYWNjb21tb2RhdGluZyB0aGUgDQogICB3b3JraW5nIExTUCBz ZWdtZW50LiBBbGwgb2YgdGhlIHVucmVzZXJ2ZWQgYmFuZHdpZHRocyBjb3JyZXNwb25kaW5nIA0K ICAgdG8gYWxsIGxpbmsgYW5kIG5vZGUgZmFpbHVyZXMgYW5kIGFsbCB0aGUgU1JMR3MgYXJlIHJl ZHVjZWQgYnkgdGhlIA0KICAgd29ya2luZyBMU1AgYmFuZHdpZHRoLiANCiAgICANCiAgIE5leHQs IHRoZSBleHRlcm5hbCBQQ0UgY29tcHV0ZXMgYSByb3V0ZSBmb3IgdGhlIGNvcnJlc3BvbmRpbmcg DQogICByZWNvdmVyeSBMU1AuIFRoZSBleHRlcm5hbCBQQ0UgZXhjbHVkZXMgdGhlIGxpbmtzIHRy YXZlcnNlZCBieSB0aGUgDQogICB3b3JraW5nIExTUCBzZWdtZW50IGluIHRoZSBjYXNlIG9mIGxp bmsgcHJvdGVjdGlvbiwgdGhlIHRyYW5zaXQgbm9kZXMgDQogICBmb3IgdGhlIHdvcmtpbmcgTFNQ IHNlZ21lbnQgaW4gdGhlIGNhc2Ugb2Ygbm9kZSBwcm90ZWN0aW9uLCBhbmQgdGhlIA0KICAgU1JM R3MgdGhhdCB0aGUgd29ya2luZyBMU1Agc2VnbWVudCBiZWxvbmdzIHRvIGluIHRoZSBjYXNlIG9m IFNSTEcgDQogICBwcm90ZWN0aW9uLiANCiAgICANCg0KIA0KIA0KT2dpbm8gICAgICAgICAgICAg ICAgICAgIEV4cGlyZXMgLSBNYXJjaCAyMDA1ICAgICAgICAgICAgICAgICBbUGFnZSA0XSANCgxJ bnRlcm5ldCBEcmFmdDxkcmFmdC1vZ2luby1wY2UtcmVjb3ZlcnktcGMtbW9kZWwtMDAudHh0PiBT ZXB0ZW1iZXIgMjAwNCANCiANCiANCiAgIEF2YWlsYWJsZSBiYW5kd2lkdGggZm9yIHRoZSByZWNv dmVyeSBMU1AgaW4gZWFjaCBsaW5rIGNhbiBiZSBrbm93biANCiAgIGZyb20gdGhlIHJvdXRlIHNl bGVjdGVkIGZvciB0aGUgY29ycmVzcG9uZGluZyB3b3JraW5nIExTUCBzZWdtZW50LiBJbiANCiAg IG90aGVyIHdvcmRzLCB0aGUgcm91dGUgZm9yIHRoZSB3b3JraW5nIExTUCBzZWdtZW50IGRldGFp bHMgdGhlIGxpbmsgDQogICBhbmQgbm9kZSBmYWlsdXJlcyB0aGF0IHRoZSB3b3JraW5nIExTUCBz ZWdtZW50IG1heSBpbmN1ciBhbmQgdGhlIA0KICAgU1JMR3MgdG8gd2hpY2ggdGhlIHdvcmtpbmcg TFNQIHNlZ21lbnQgYmVsb25ncy4gVGhlIGF2YWlsYWJsZSANCiAgIGJhbmR3aWR0aCBmb3IgdGhl IHJlY292ZXJ5IExTUCBpbiBlYWNoIGxpbmsgaXMgaWRlbnRpY2FsIHRvIHRoZSBsZWFzdCANCiAg IHVucmVzZXJ2ZWQgYmFuZHdpZHRoIGFtb25nIHRob3NlIGNvcnJlc3BvbmRpbmcgdG8gc3VjaCBs aW5rIGFuZCBub2RlIA0KICAgZmFpbHVyZXMgYW5kIFNSTEdzLiBUaGUgZXh0ZXJuYWwgUENFIHJl bW92ZXMgYWxsIGxpbmtzIHdpdGggYXZhaWxhYmxlIA0KICAgYmFuZHdpZHRoIGxlc3MgdGhhbiB0 aGUgcmVjb3ZlcnkgTFNQLiANCiAgICANCiAgIFRoZSBleHRlcm5hbCBQQ0UgdGhlbiBjYWxjdWxh dGVzIHRoZSBiYW5kd2lkdGggc2hhcmluZyByYXRlIGluIGVhY2ggDQogICByZW1haW5pbmcgbGlu aywgdXNpbmcgZmlndXJlcyBmb3IgdGhlIGF2YWlsYWJsZSBhbmQgbWluaW11bSANCiAgIHVucmVz ZXJ2ZWQgYmFuZHdpZHRocyByZXNwZWN0aXZlbHksIGFuZCB0aGVuIGFkanVzdGluZyB0aGUgbGlu ayANCiAgIHdlaWdodCBhY2NvcmRpbmcgdG8gdGhlIGJhbmR3aWR0aCBzaGFyaW5nIHJhdGUgY2Fs Y3VsYXRlZCBmb3IgdGhlIA0KICAgbGluay4gSW4gb3RoZXIgd29yZHMsIHRoZSBsaW5rIHdlaWdo dCBpcyByZWR1Y2VkIGFzIHRoZSBiYW5kd2lkdGggDQogICBzaGFyaW5nIHJhdGUgaW5jcmVhc2Vz LCBhbmQgdGhlIHNlbGVjdGlvbiBvZiBzdWNoIGEgbGluayBpcyBwcm9tb3RlZC4gDQogICBGaW5h bGx5LCB0aGUgc2hvcnRlc3QgcGF0aCBiZXR3ZWVuIHRoZSBvcmlnaW5hdGluZyBhbmQgdGVybWlu YXRpbmcgDQogICBMU1JzIGZvciB0aGUgd29ya2luZyBMU1Agc2VnbWVudCBpcyBzZWxlY3RlZCBh cyB0aGUgcm91dGUgZm9yIHRoZSANCiAgIHJlY292ZXJ5IExTUC4gVGhlIGV4dGVybmFsIFBDRSBy ZWR1Y2VzIHRoZSB1bnJlc2VydmVkIGJhbmR3aWR0aHMgaW4gDQogICB0aGUgbGlua3MgbmV3bHkg YWNjb21tb2RhdGluZyB0aGUgcmVjb3ZlcnkgTFNQLiBUaGUgdW5yZXNlcnZlZCANCiAgIGJhbmR3 aWR0aHMgY29ycmVzcG9uZGluZyB0byB0aGUgbGluayBhbmQgbm9kZSBmYWlsdXJlcyB0aGF0IHRo ZSANCiAgIHdvcmtpbmcgTFNQIHNlZ21lbnQgbWF5IGluY3VyIGFyZSByZWR1Y2VkIGJ5IHRoZSBy ZWNvdmVyeSBMU1AgDQogICBiYW5kd2lkdGguIFRoZSB1bnJlc2VydmVkIGJhbmR3aWR0aHMgY29y cmVzcG9uZGluZyB0byB0aGUgU1JMR3MgdG8gDQogICB3aGljaCB0aGUgd29ya2luZyBMU1Agc2Vn bWVudCBiZWxvbmdzIGFyZSBhbHNvIHJlZHVjZWQgYnkgdGhlIA0KICAgcmVjb3ZlcnkgTFNQIGJh bmR3aWR0aC4gDQogICAgDQogICBTaW5jZSB0aGUgZXh0ZXJuYWwgUENFIGlzIHJlcXVpcmVkIHRv IGJlIHN0YXRlZnVsLCB0aGUgZXh0ZXJuYWwgUENFIA0KICAgbXVzdCBiZSBub3RpZmllZCB3aGVu IHRoZSByZWNvdmVyYWJsZSBURS1MU1AgaXMgcmVsZWFzZWQuIE1vcmVvdmVyLCANCiAgIHVucmVz ZXJ2ZWQgYmFuZHdpZHRoIGluZm9ybWF0aW9uIHByZXNlcnZlZCBleGNsdXNpdmVseSBieSB0aGUg DQogICBleHRlcm5hbCBQQ0UgcmVxdWlyZXMgdXBkYXRpbmcuIFRoZSBleHRlcm5hbCBQQ0UgaW5j cmVhc2VzIGFsbCBvZiB0aGUgDQogICB1bnJlc2VydmVkIGJhbmR3aWR0aHMgd2l0aGluIGxpbmtz IHRoYXQgaGF2ZSBhY2NvbW1vZGF0ZWQgdGhlIHNlZ21lbnQgDQogICBvZiB0aGUgcmVsZWFzZWQg d29ya2luZyBMU1AuIEFsbCB1bnJlc2VydmVkIGJhbmR3aWR0aHMgY29ycmVzcG9uZGluZyANCiAg IHRvIGFsbCBsaW5rIGFuZCBub2RlIGZhaWx1cmVzIGFuZCBhbGwgU1JMR3MgYXJlIGluY3JlYXNl ZCBieSB0aGUgDQogICBiYW5kd2lkdGggb2YgdGhlIHJlbGVhc2VkIHdvcmtpbmcgTFNQLiBUaGUg ZXh0ZXJuYWwgUENFIGluY3JlYXNlcyB0aGUgDQogICB1bnJlc2VydmVkIGJhbmR3aWR0aHMgaW4g dGhlIGxpbmtzIHRoYXQgaGF2ZSBhY2NvbW1vZGF0ZWQgdGhlIA0KICAgcmVjb3ZlcnkgTFNQLiBU aGUgdW5yZXNlcnZlZCBiYW5kd2lkdGhzIGNvcnJlc3BvbmRpbmcgdG8gdGhlIGxpbmsgYW5kIA0K ICAgbm9kZSBmYWlsdXJlcyB0aGF0IHRoZSBzZWdtZW50IG9mIHJlbGVhc2VkIHdvcmtpbmcgTFNQ IG1heSBpbmN1ciBhcmUgDQogICBpbmNyZWFzZWQgYnkgdGhlIGJhbmR3aWR0aCBvZiB0aGUgcmVs ZWFzZWQgcmVjb3ZlcnkgTFNQLiBUaGUgDQogICB1bnJlc2VydmVkIGJhbmR3aWR0aHMgY29ycmVz cG9uZGluZyB0byB0aGUgU1JMR3MgdG8gd2hpY2ggdGhlIHNlZ21lbnQgDQogICBvZiByZWxlYXNl ZCB3b3JraW5nIExTUCBiZWxvbmdzIGFyZSBhbHNvIGluY3JlYXNlZCBieSB0aGUgYmFuZHdpZHRo IA0KICAgb2YgdGhlIHJlbGVhc2VkIHJlY292ZXJ5IExTUC4gVGhlIGV4dGVybmFsIFBDRSBtdXN0 IHByZXNlcnZlIHRoZSBwYXRoIA0KICAgcm91dGUgaW5mb3JtYXRpb24gY2FsY3VsYXRlZCBmb3Ig YSBzZWdtZW50IG9mIHJlY292ZXJhYmxlIFRFLUxTUCBpZiANCiAgIHRoZSBub3RpZmljYXRpb24g bWVzc2FnZSBmb3IgcmVsZWFzZSBvZiB0aGlzIHNlZ21lbnQgb2YgcmVjb3ZlcmFibGUgDQogICBU RS1MU1AgaW5jbHVkZXMgbm8gc3VjaCBwYXRoIHJvdXRlIGluZm9ybWF0aW9uIGZvciB0aGlzIHNl Z21lbnQgb2YgDQogICByZWNvdmVyYWJsZSBURS1MU1AuIA0KICAgIA0KICAgIA0KNC4gUmVjb3Zl cnkgUGF0aCBDb21wdXRhdGlvbiBFeGFtcGxlIA0KICAgIA0KIA0KIA0KT2dpbm8gICAgICAgICAg ICAgICAgICAgIEV4cGlyZXMgLSBNYXJjaCAyMDA1ICAgICAgICAgICAgICAgICBbUGFnZSA1XSAN CgxJbnRlcm5ldCBEcmFmdDxkcmFmdC1vZ2luby1wY2UtcmVjb3ZlcnktcGMtbW9kZWwtMDAudHh0 PiBTZXB0ZW1iZXIgMjAwNCANCiANCiANCiAgIFRoZSByZWNvdmVyeSBwYXRoIGNvbXB1dGF0aW9u IG1vZGVsIGlzIGV4cGxhaW5lZCB1c2luZyB0aGUgZm9sbG93aW5nIA0KICAgZXhhbXBsZSBvZiBk b21haW4gdG9wb2xvZ3kuIEhlcmUsIG9ubHkgbGluayBwcm90ZWN0aW9uIGlzIGNvbnNpZGVyZWQu IA0KICAgIA0KICAgTFNSMSoqKioqKioqKioqKioqKioqKioqKioqKkxTUjQgDQogICAgKyAgIFwg ICAgICAgICAgICAgICAgICAgIC8gICAqIA0KICAgICsgICAgIFwgICAgICAgICAgICAgICAgLyAg ICAgKiANCiAgICArICAgICAgIFwgICAgICAgICAgICAvICAgICAgICogDQogICAgKyAgICAgICAg IFwgICAgICAgIC8gICAgICAgICAqIA0KICAgICsgICAgICAgICAgIFwgICAgLyAgICAgICAgICAg KiANCiAgICArICAgICAgICAgICAgTFNSNSAgICAgICAgICAgICogDQogICAgKyAgICAgICAgICAg KiAgICAqICAgICAgICAgICAqIA0KICAgICsgICAgICAgICAqICAgICAgICAqICAgICAgICAgKiAN CiAgICArICAgICAgICogICAgICAgICAgICAqICAgICAgICogDQogICAgKyAgICAgKiAgICAgICAg ICAgICAgICAqICAgICAqIA0KICAgICsgICAqICAgICAgICAgICAgICAgICAgICAqICAgKiANCiAg IExTUjIrKysrKysrKysrKysrKysrKysrKysrKytMU1IzIA0KICAgIA0KICAgSW4gdGhlIGFib3Zl IGV4YW1wbGUsIHRoZSBiYW5kd2lkdGggb2YgZWFjaCBsaW5rIGlzIGFzc3VtZWQgdG8gYmUgNS4w LiANCiAgIEEgc2VnbWVudCBvZiByZWNvdmVyYWJsZSBURS1MU1Agd2l0aCBhIGJhbmR3aWR0aCBv ZiAzLjAgaXMgDQogICBlc3RhYmxpc2hlZCBiZXR3ZWVuIExTUjEgYW5kIExTUjMuIFRoZSB3b3Jr aW5nIExTUCBzZWdtZW50IGJldHdlZW4gDQogICBMU1IxIGFuZCBMU1IzIGlzIGVzdGFibGlzaGVk IHRocm91Z2ggTFNSNCB3aGlsZSB0aGUgcmVjb3ZlcnkgTFNQIA0KICAgYmV0d2VlbiBMU1IxIGFu ZCBMU1IzIGlzIGVzdGFibGlzaGVkIHRocm91Z2ggTFNSMi4gQSBzZWdtZW50IG9mIA0KICAgcmVj b3ZlcmFibGUgVEUtTFNQIHdpdGggYSBiYW5kd2lkdGggb2YgMS4wIGlzIGFsc28gZXN0YWJsaXNo ZWQgDQogICBiZXR3ZWVuIExTUjIgYW5kIExTUjMuIFRoZSB3b3JraW5nIExTUCBzZWdtZW50IGJl dHdlZW4gTFNSMiBhbmQgTFNSMyANCiAgIGlzIGVzdGFibGlzaGVkIHRocm91Z2ggTFNSNSB3aGls ZSB0aGUgcmVjb3ZlcnkgTFNQIGNvbm5lY3RzIExTUjEgYW5kIA0KICAgTFNSMyBkaXJlY3RseS4g VHdvIHJlY292ZXJ5IExTUHMgY2FuIHNoYXJlIHRoZSBiYW5kd2lkdGggb2YgbGluayANCiAgIExT UjItTFNSMyBiZWNhdXNlIHRoZSBjb3JyZXNwb25kaW5nIHNlZ21lbnRzIG9mIHdvcmtpbmcgTFNQ cyBuZXZlciANCiAgIGluY3VyIGRhbWFnZSBzaW11bHRhbmVvdXNseS4gDQogICAgDQogICBBdCB0 aGlzIHRpbWUsIHRoZSB1bnJlc2VydmVkIGJhbmR3aWR0aCBpbmZvcm1hdGlvbiBmb3IgbGluayBM U1IyLUxTUjMgDQogICBpcyBhcyBmb2xsb3dzLiBUaGlzIGluZm9ybWF0aW9uIGlzIHByZXNlcnZl ZCBleGNsdXNpdmVseSBpbiBhbiANCiAgIGV4dGVybmFsIFBDRS4gDQogICAgDQogICArLS0tLS0t LS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tKyANCiAgIHwgICAgIExpbmsg ZmFpbHVyZSAgICAgfCBVbnJlc2VydmVkIGJhbmR3aWR0aCB8IA0KICAgKy0tLS0tLS0tLS0tLS0t LS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsgDQogICB8ICAgICAgTFNSMS1MU1I0ICAg ICAgICsgICAgICAgICAyLjAgICAgICAgICAgfCANCiAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0t Ky0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rIA0KICAgfCAgICAgIExTUjQtTFNSMyAgICAgICArICAg ICAgICAgMi4wICAgICAgICAgIHwgDQogICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0t LS0tLS0tLS0tLS0tLS0tKyANCiAgIHwgICAgICBMU1IyLUxTUjUgICAgICAgKyAgICAgICAgIDQu MCAgICAgICAgICB8IA0KICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0t LS0tLS0tLSsgDQogICB8ICAgICAgTFNSNS1MU1IzICAgICAgICsgICAgICAgICA0LjAgICAgICAg ICAgfCANCiAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0r IA0KICAgfCAgICAgICAgT3RoZXJzICAgICAgICArICAgICAgICAgNS4wICAgICAgICAgIHwgDQog ICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tKyANCiAgICAN CiAgIFRoaXMgaW5mb3JtYXRpb24gY2xlYXJseSBpbmRpY2F0ZXMgdGhhdCB0aGUgYXZhaWxhYmxl IGJhbmR3aWR0aCBmb3IgYSANCiAgIHdvcmtpbmcgTFNQIGlzIDIuMCBpbiBsaW5rIExTUjItTFNS My4gSXQgYWxzbyBpbmRpY2F0ZXMgdGhlIGF2YWlsYWJsZSANCiANCiANCk9naW5vICAgICAgICAg ICAgICAgICAgICBFeHBpcmVzIC0gTWFyY2ggMjAwNSAgICAgICAgICAgICAgICAgW1BhZ2UgNl0g DQoMSW50ZXJuZXQgRHJhZnQ8ZHJhZnQtb2dpbm8tcGNlLXJlY292ZXJ5LXBjLW1vZGVsLTAwLnR4 dD4gU2VwdGVtYmVyIDIwMDQgDQogDQogDQogICBiYW5kd2lkdGggZm9yIGEgcmVjb3ZlcnkgTFNQ IHRvIGJlIDIuMCB3aGVuIHRoZSBjb3JyZXNwb25kaW5nIHdvcmtpbmcgDQogICBMU1Agc2VnbWVu dCB0cmF2ZXJzZXMgZWl0aGVyIG9mIHRoZSBsaW5rcyBMU1IxLUxTUjQgb3IgTFNSNC1MU1IzLiAN CiAgIEZ1cnRoZXIsIGRhdGEgc2hvd3MgdGhlIGF2YWlsYWJsZSBiYW5kd2lkdGggZm9yIGEgcmVj b3ZlcnkgTFNQIHRvIGJlIA0KICAgNC4wIGFuZCB0aGUgYWJpbGl0eSBvZiBhIHJlY292ZXJ5IExT UCB0byBzaGFyZSBsaW5rIGJhbmR3aWR0aCBvZiAyLjAgDQogICB3aXRoIG90aGVyIHJlY292ZXJ5 IExTUHMgd2hlbiB0aGUgY29ycmVzcG9uZGluZyB3b3JraW5nIExTUCBzZWdtZW50IA0KICAgdHJh dmVyc2VzIG5laXRoZXIgb2YgdGhlIGxpbmtzIExTUjEtTFNSNCBub3IgTFNSNC1MU1IzIGJ1dCBl aXRoZXIgb2YgDQogICBsaW5rcyBMU1IyLUxTUjUgb3IgTFNSNS1MU1IzLiBGaW5hbGx5LCB3ZSBs ZWFybiB0aGF0IHRoZSBhdmFpbGFibGUgDQogICBiYW5kd2lkdGggZm9yIGEgcmVjb3ZlcnkgTFNQ IGlzIDUuMCBhbmQgYSByZWNvdmVyeSBMU1AgY2FuIHNoYXJlIHRoZSANCiAgIGxpbmsgYmFuZHdp ZHRoIG9mIDMuMCB3aXRoIG90aGVyIHJlY292ZXJ5IExTUHMgd2hlbiB0aGUgY29ycmVzcG9uZGlu ZyANCiAgIHdvcmtpbmcgTFNQIHNlZ21lbnQgdHJhdmVyc2VzIG5vbmUgb2YgdGhlIGxpbmtzIExT UjEtTFNSNCwgTFNSNC1MU1IzLCANCiAgIExTUjItTFNSNSBhbmQgTFNSNS1MU1IzLiANCiAgICAN CiAgIEhlcmUsIGFuIGV4dGVybmFsIFBDRSByZWNlaXZlcyBhIHJlcXVlc3QgdG8gZXN0YWJsaXNo IGEgc2VnbWVudCBvZiANCiAgIHJlY292ZXJhYmxlIFRFLUxTUCB3aXRoIGEgYmFuZHdpZHRoIG9m IDMuMCBiZXR3ZWVuIExTUjIgYW5kIExTUjMuIFRoZSANCiAgIGV4dGVybmFsIFBDRSBzZWxlY3Rz IHRoZSBzaG9ydGVzdCBwYXRoIExTUjItTFNSNS1MU1IzIGZvciB0aGUgd29ya2luZyANCiAgIExT UCBzZWdtZW50IGJlY2F1c2UgbGluayBMU1IyLUxTUjMgY2Fubm90IGFjY29tbW9kYXRlIHRoaXMg d29ya2luZyANCiAgIExTUCBzZWdtZW50LiBUaGUgZXh0ZXJuYWwgUENFIGV4Y2x1ZGVzIGxpbmtz IExTUjItTFNSNSBhbmQgTFNSNS1MU1IzIA0KICAgYmVjYXVzZSB0aGUgd29ya2luZyBMU1Agc2Vn bWVudCBhbHJlYWR5IHRyYXZlcnNlcyB0aG9zZSBsaW5rcy4gVGhlIA0KICAgZXh0ZXJuYWwgUENF IHJlbW92ZXMgbGlua3MgTFNSMS1MU1I0IGFuZCBMU1I0LUxTUjMgYmVjYXVzZSB0aG9zZSANCiAg IGxpbmtzIGNhbm5vdCBhY2NvbW1vZGF0ZSB0aGUgcmVjb3ZlcnkgTFNQLiBUaGVuLCB0aGUgZXh0 ZXJuYWwgUENFIA0KICAgc2VsZWN0cyB0aGUgc2hvcnRlc3QgcGF0aCBMU1IyLUxTUjMgZm9yIHRo ZSByZWNvdmVyeSBMU1AuIEF0IHRoaXMgDQogICB0aW1lLCB0aGUgcmVjb3ZlcnkgTFNQIGNhbiBz aGFyZSBiYW5kd2lkdGggb2YgMi4wIHdpdGggb3RoZXIgcmVjb3ZlcnkgDQogICBMU1BzIGluIGxp bmsgTFNSMi1MU1IzLiBUaGUgYmFuZHdpZHRoIHNoYXJpbmcgcmF0ZSBiZWNvbWVzIDY3JSANCiAg IGJlY2F1c2UgYmFuZHdpZHRoIG9mIHRoZSByZWNvdmVyeSBMU1AgaXMgMy4wLiBUaGVyZWZvcmUs IHRoZSBleHRlcm5hbCANCiAgIFBDRSBtYXkgcmVkdWNlIHRoZSB3ZWlnaHQgb2YgbGluayBMU1Iy LUxTUjMgZnJvbSAxLjAgdG8gMC4zMyB0byANCiAgIHByb21vdGUgc2VsZWN0aW9uIG9mIGxpbmsg TFNSMi1MU1IzLiANCiAgICANCiAgIEFzIGEgcmVzdWx0LCB0aGUgZXh0ZXJuYWwgUENFIHVwZGF0 ZXMgdGhlIHVucmVzZXJ2ZWQgYmFuZHdpZHRoIA0KICAgaW5mb3JtYXRpb24gZm9yIGxpbmsgTFNS Mi1MU1IzIGFzIGZvbGxvd3MuIA0KICAgIA0KICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0t LS0tLS0tLS0tLS0tLS0tLS0tLSsgDQogICB8ICAgICBMaW5rIGZhaWx1cmUgICAgIHwgVW5yZXNl cnZlZCBiYW5kd2lkdGggfCANCiAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0t LS0tLS0tLS0tLS0rIA0KICAgfCAgICAgIExTUjEtTFNSNCAgICAgICArICAgICAgICAgMi4wICAg ICAgICAgIHwgDQogICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0t LS0tKyANCiAgIHwgICAgICBMU1I0LUxTUjMgICAgICAgKyAgICAgICAgIDIuMCAgICAgICAgICB8 IA0KICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsgDQog ICB8ICAgICAgTFNSMi1MU1I1ICAgICAgICsgICAgICAgICAxLjAgICAgICAgICAgfCANCiAgICst LS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rIA0KICAgfCAgICAg IExTUjUtTFNSMyAgICAgICArICAgICAgICAgMS4wICAgICAgICAgIHwgDQogICArLS0tLS0tLS0t LS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tKyANCiAgIHwgICAgICAgIE90aGVy cyAgICAgICAgKyAgICAgICAgIDUuMCAgICAgICAgICB8IA0KICAgKy0tLS0tLS0tLS0tLS0tLS0t LS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsgDQogICAgDQogICBJZiB0aGUgcmVsZWFzZSBv ZiB0aGlzIGVzdGFibGlzaGVkIHNlZ21lbnQgb2YgcmVjb3ZlcmFibGUgVEUtTFNQLCANCiAgIHdp dGggYmFuZHdpZHRoIG9mIDMuMCBiZXR3ZWVuIExTUjIgYW5kIExTUjMsIGlzIG5vdGlmaWVkLCB0 aGUgDQogICBleHRlcm5hbCBQQ0UgbXVzdCB1cGRhdGUgdGhpcyB1bnJlc2VydmVkIGJhbmR3aWR0 aCBpbmZvcm1hdGlvbiBmb3IgDQogICBsaW5rIExTUjItTFNSMyB0byBpdHMgcHJldmlvdXMgc3Rh dGUuIA0KICAgIA0KIA0KIA0KT2dpbm8gICAgICAgICAgICAgICAgICAgIEV4cGlyZXMgLSBNYXJj aCAyMDA1ICAgICAgICAgICAgICAgICBbUGFnZSA3XSANCgxJbnRlcm5ldCBEcmFmdDxkcmFmdC1v Z2luby1wY2UtcmVjb3ZlcnktcGMtbW9kZWwtMDAudHh0PiBTZXB0ZW1iZXIgMjAwNCANCiANCiAN CiAgICANCjUuIFNjYWxhYmlsaXR5IENvbnNpZGVyYXRpb25zIA0KICAgIA0KICAgV2hlbiBhIGNl bnRyYWxpemVkIGV4dGVybmFsIFBDRSBleGNsdXNpdmVseSBwcmVzZXJ2aW5nIHRoZSByZXF1aXJl ZCANCiAgIFRFIGluZm9ybWF0aW9uIGlzIHByZXBhcmVkIGluIGEgZG9tYWluLCBib3RoIHRoZSBw cm9jZXNzaW5nIGFuZCANCiAgIG1lbW9yeSBsb2FkcyBvZiB0aGUgcGF0aCBjb21wdXRhdGlvbiBj b25jZW50cmF0ZSBvbiB0aGlzIFBDRS4gVGhlIA0KICAgc2l6ZSBvZiBhIGRvbWFpbiBuZWVkcyB0 byBiZSBkZWNpZGVkIG9uLCBiYXNlZCBvbiB0aGUgYXZhaWxhYmxlIA0KICAgcHJvY2Vzc2luZyBh bmQgbWVtb3J5IGNhcGFjaXRpZXMgb2YgdGhlIGNlbnRyYWxpemVkIFBDRS4gQWx0aG91Z2ggDQog ICBsb2FkIHNoYXJpbmcgYnkgZGlzdHJpYnV0ZWQgUENFcyBpcyBwb3NzaWJsZSB3aXRoaW4gYSBk b21haW4sIHRoaXMgDQogICBzY2VuYXJpbyByZXF1aXJlcyBmYXN0IHN5bmNocm9uaXphdGlvbiBv ZiBURSBpbmZvcm1hdGlvbiBiZXR3ZWVuIHRoZSANCiAgIGRpc3RyaWJ1dGVkIFBDRXMuIA0KICAg IA0KICAgIA0KNi4gU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgDQogICAgDQogICBUaGlzIGRvY3Vt ZW50IGRvZXMgbm90IHJhaXNlIGFueSBuZXcgc2VjdXJpdHkgaXNzdWVzLCBiZXlvbmQgdGhvc2Ug b2YgDQogICB0aGUgUENFIGFyY2hpdGVjdHVyZSBbUENFLUFSQ0hJVEVDVFVSRV0uIA0KICAgIA0K ICAgIA0KNy4gSUFOQSBDb25zaWRlcmF0aW9ucyANCiAgICANCiAgIFRoaXMgZG9jdW1lbnQgbWFr ZXMgbm8gcmVxdWVzdCBmb3IgSUFOQSBhY3Rpb24uIA0KICAgIA0KICAgIA0KOC4gQWNrbm93bGVk Z2VtZW50cyANCiAgICANCiAgIFRoZSBhdXRob3JzIHdvdWxkIGxpa2UgdG8gdGhhbmsgdG8gSmVh biBQaGlsaXBwZSBWYXNzZXVyIGFuZCBBZHJpYW4gDQogICBGYXJyZWwgZm9yIHRoZWlyIGVuY291 cmFnZW1lbnQgaW4gdGhlIHN1Ym1pc3Npb24gb2YgdGhpcyBkb2N1bWVudC4gDQogICAgDQogICAg DQo5LiBSZWZlcmVuY2VzIA0KIA0KOS4xIE5vcm1hdGl2ZSBSZWZlcmVuY2VzIA0KICAgIA0KICAg W1BDRS1BUkNISVRFQ1RVUkVdIEZhcnJlbCwgQS4sIFZhc3NldXIsIEouIFAuLCBhbmQgQXNoLCBK LiwgIlBhdGggDQogICBDb21wdXRhdGlvbiBFbGVtZW50IChQQ0UpIEFyY2hpdGVjdHVyZSIsIGRy YWZ0LWFzaC1wY2UtYXJjaGl0ZWN0dXJlLQ0KICAgMDAudHh0LCBTZXB0ZW1iZXIgMjAwNCAod29y ayBpbiBwcm9ncmVzcykuIA0KICAgIA0KICAgW1BDRS1QUk9CTEVNXSBBc2gsIEouIGFuZCBGYXJy ZWwsIEEuLCAiUGF0aCBDb21wdXRhdGlvbiBFbGVtZW50IA0KICAgUHJvYmxlbSBTdGF0ZW1lbnQi LCBkcmFmdC1hc2gtcGNlLXByb2JsZW0tc3RhdGVtZW50LTAwLnR4dCwgSnVuZSAyMDA0IA0KICAg KHdvcmsgaW4gcHJvZ3Jlc3MpLiANCiAgICANCiAgIFtQQ0UtQkFDS1VQLUNPTVAtRlJXS10gVmFz c2V1ciwgSi4gUC4sIENoYXJueSwgQS4sIEZhdWNoZXVyLCBGLiBMLiwgDQogICBBY2hpcmljYSwg Si4gYW5kIFJvdXgsIEouIEwuLCAiRnJhbWV3b3JrIGZvciBQQ0UtYmFzZWQgTVBMUy1URSBGYXN0 IA0KICAgUmVyb3V0ZSBCYWNrdXAgUGF0aCBDb21wdXRhdGlvbiIsIGRyYWZ0LWxlcm91eC1wY2Ut YmFja3VwLWNvbXAtZnJ3ay0NCiAgIDAwLnR4dCwgSnVseSAyMDA0ICh3b3JrIGluIHByb2dyZXNz KS4gDQogICAgDQoNCg0KIA0KDCANCk9naW5vICAgICAgICAgICAgICAgICAgICBFeHBpcmVzIC0g TWFyY2ggMjAwNSAgICAgICAgICAgICAgICAgW1BhZ2UgOF0gDQoMSW50ZXJuZXQgRHJhZnQ8ZHJh ZnQtb2dpbm8tcGNlLXJlY292ZXJ5LXBjLW1vZGVsLTAwLnR4dD4gU2VwdGVtYmVyIDIwMDQgDQog DQogDQo5LjIgSW5mb3JtYXRpb25hbCBSZWZlcmVuY2VzIA0KICAgIA0KICAgW0JHUC00XSBSZWto dGVyLCBZLiBhbmQgTGksIFQuLCAiQSBCb3JkZXIgR2F0ZXdheSBQcm90b2NvbCA0IChCR1AtNCki LCANCiAgIFJGQyAxNzcxLCBNYXJjaCAxOTk1LiANCiAgICANCiAgIFtPU1BGLVRFXSBLYXR6LCBE LiwgWWV1bmcsIEQuIGFuZCBLb21wZWxsYSwgSy4sICJUcmFmZmljIEVuZ2luZWVyaW5nIA0KICAg RXh0ZW5zaW9ucyB0byBPU1BGIFZlcnNpb24gMiIsIFJGQyAzNjMwLCBTZXB0ZW1iZXIgMjAwMy4g IA0KICAgICANCiAgIFtJUy1JUy1URV0gTGksIFQuIGFuZCBTbWl0LCBILiwgIklTLUlTIGV4dGVu c2lvbnMgZm9yIFRyYWZmaWMgDQogICBFbmdpbmVlcmluZyIsIFJGQyAzNzg0LCBKdW5lIDIwMDQu IA0KICAgIA0KICAgW0lOVEVSLURPTUFJTi1GUkFNRVdPUktdIEZhcnJlbCwgQS4sIFZhc3NldXIs IEouIFAuLCBhbmQgQXl5YW5nYXIsIEEuLCANCiAgICJBIEZyYW1ld29yayBmb3IgSW50ZXItRG9t YWluIE1QTFMgVHJhZmZpYyBFbmdpbmVlcmluZyIsIGRyYWZ0LQ0KICAgZmFycmVsLWNjYW1wLWlu dGVyLWRvbWFpbi0gDQogICBmcmFtZXdvcmstMDEudHh0LCBKdWx5IDIwMDQgKHdvcmsgaW4gcHJv Z3Jlc3MpLiANCiAgICANCiAgIFtJTlRFUi1ET01BSU4tUlNWUC1URV0gQXl5YW5nYXIsIEEuIGFu ZCBWYXNzZXVyLCBKLiBQLiwgIkludGVyLWRvbWFpbiANCiAgIE1QTFMgVHJhZmZpYyBFbmdpbmVl cmluZy0gUlNWUC1URSBleHRlbnNpb25zIiwgZHJhZnQtYXl5YW5nYXItY2NhbXAtDQogICBpbnRl ci1kb21haW4tcnN2cC10ZS0wMC4gDQogICB0eHQsIEp1bHkgMjAwNCAod29yayBpbiBwcm9ncmVz cykuIA0KICAgIA0KICAgW0lOVEVSLURPTUFJTi1QQVRILUNPTVBdIFZhc3NldXIsIEouIFAuLCBB eXlhbmdhciwgQS4sIGFuZCBaaGFuZywgUi4sIA0KICAgIkludGVyLWRvbWFpbiBUcmFmZmljIEVu Z2luZWVyaW5nIExTUCBwYXRoIGNvbXB1dGF0aW9uIG1ldGhvZHMiLCANCiAgIGRyYWZ0LXZhc3Nl dXItY2NhbXAtaW50ZXItIA0KICAgZG9tYWluLXBhdGgtY29tcC0wMC50eHQsIEp1bHkgMjAwNCAo d29yayBpbiBwcm9ncmVzcykuIA0KICAgIA0KICAgW1JFQ09WRVJZLVRFUk1JTk9MT0dZXSBNYW5u aWUsIEUuIGFuZCBQYXBhZGltaXRyaW91LCBELiwgIlJlY292ZXJ5IA0KICAgKFByb3RlY3Rpb24g YW5kIFJlc3RvcmF0aW9uKSBUZXJtaW5vbG9neSBmb3IgR2VuZXJhbGl6ZWQgTXVsdGktDQogICBQ cm90b2NvbCBMYWJlbCBTd2l0Y2hpbmcgKEdNUExTKSIsIGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMt cmVjb3ZlcnktDQogICB0ZXJtaW5vbG9neS0wNC50eHQsIEFwcmlsIDIwMDQgKHdvcmsgaW4gcHJv Z3Jlc3MpLiANCiAgICANCiAgIFtSRUNPVkVSWS1BTkFMWVNJU10gUGFwYWRpbWl0cmlvdSwgRC4g YW5kIE1hbm5pZSwgRS4sICJBbmFseXNpcyBvZiANCiAgIEdlbmVyYWxpemVkIE11bHRpLVByb3Rv Y29sIExhYmVsIFN3aXRjaGluZyAoR01QTFMpLWJhc2VkIFJlY292ZXJ5IA0KICAgTWVjaGFuaXNt cyAoaW5jbHVkaW5nIFByb3RlY3Rpb24gYW5kIFJlc3RvcmF0aW9uKSIsIGRyYWZ0LWlldGYtY2Nh bXAtDQogICBnbXBscy1yZWNvdmVyeS1hbmFseXNpcy0wMy50eHQsIEFwcmlsIDIwMDQgKHdvcmsg aW4gcHJvZ3Jlc3MpLiANCiAgICANCiAgICANCjEwLiBBdXRob3JzJyBBZGRyZXNzZXMgDQogICAg DQogICBOYWdhbyBPZ2lubyANCiAgIEtEREkgUiZEIExhYm9yYXRvcmllcyBJbmMuIA0KICAgMi0x LTE1IE9oYXJhLCBLYW1pZnVrdW9rYS1zaGkgDQogICBTYWl0YW1hIDM1Ni04NTAyIEpBUEFOIA0K ICAgRW1haWw6ICBvZ2lub0BrZGRpbGFicy5qcCANCiAgICANCiAgICANCjExLiBJbnRlbGxlY3R1 YWwgUHJvcGVydHkgU3RhdGVtZW50IA0KICAgIA0KDQogDQogDQpPZ2lubyAgICAgICAgICAgICAg ICAgICAgRXhwaXJlcyAtIE1hcmNoIDIwMDUgICAgICAgICAgICAgICAgIFtQYWdlIDldIA0KDElu dGVybmV0IERyYWZ0PGRyYWZ0LW9naW5vLXBjZS1yZWNvdmVyeS1wYy1tb2RlbC0wMC50eHQ+IFNl cHRlbWJlciAyMDA0IA0KIA0KIA0KICAgVGhlIElFVEYgdGFrZXMgbm8gcG9zaXRpb24gcmVnYXJk aW5nIHRoZSB2YWxpZGl0eSBvciBzY29wZSBvZiBhbnkgDQogICBJbnRlbGxlY3R1YWwgUHJvcGVy dHkgUmlnaHRzIG9yIG90aGVyIHJpZ2h0cyB0aGF0IG1pZ2h0IGJlIGNsYWltZWQgdG8gDQogICBw ZXJ0YWluIHRvIHRoZSBpbXBsZW1lbnRhdGlvbiBvciB1c2Ugb2YgdGhlIHRlY2hub2xvZ3kgZGVz Y3JpYmVkIGluIA0KICAgdGhpcyBkb2N1bWVudCBvciB0aGUgZXh0ZW50IHRvIHdoaWNoIGFueSBs aWNlbnNlIHVuZGVyIHN1Y2ggcmlnaHRzIA0KICAgbWlnaHQgb3IgbWlnaHQgbm90IGJlIGF2YWls YWJsZTsgbm9yIGRvZXMgaXQgcmVwcmVzZW50IHRoYXQgaXQgaGFzIA0KICAgbWFkZSBhbnkgaW5k ZXBlbmRlbnQgZWZmb3J0IHRvIGlkZW50aWZ5IGFueSBzdWNoIHJpZ2h0cy4gSW5mb3JtYXRpb24g DQogICBvbiB0aGUgcHJvY2VkdXJlcyB3aXRoIHJlc3BlY3QgdG8gcmlnaHRzIGluIFJGQyBkb2N1 bWVudHMgY2FuIGJlIA0KICAgZm91bmQgaW4gQkNQIDc4IGFuZCBCQ1AgNzkuIA0KICAgIA0KICAg Q29waWVzIG9mIElQUiBkaXNjbG9zdXJlcyBtYWRlIHRvIHRoZSBJRVRGIFNlY3JldGFyaWF0IGFu ZCBhbnkgDQogICBhc3N1cmFuY2VzIG9mIGxpY2Vuc2VzIHRvIGJlIG1hZGUgYXZhaWxhYmxlLCBv ciB0aGUgcmVzdWx0IG9mIGFuIA0KICAgYXR0ZW1wdCBtYWRlIHRvIG9idGFpbiBhIGdlbmVyYWwg bGljZW5zZSBvciBwZXJtaXNzaW9uIGZvciB0aGUgdXNlIG9mIA0KICAgc3VjaCBwcm9wcmlldGFy eSByaWdodHMgYnkgaW1wbGVtZW50ZXJzIG9yIHVzZXJzIG9mIHRoaXMgDQogICBzcGVjaWZpY2F0 aW9uIGNhbiBiZSBvYnRhaW5lZCBmcm9tIHRoZSBJRVRGIG9uLWxpbmUgSVBSIHJlcG9zaXRvcnkg YXQgDQogICBodHRwOi8vd3d3LmlldGYub3JnL2lwci4gDQogICAgDQogICBUaGUgSUVURiBpbnZp dGVzIGFueSBpbnRlcmVzdGVkIHBhcnR5IHRvIGJyaW5nIHRvIGl0cyBhdHRlbnRpb24gYW55IA0K ICAgY29weXJpZ2h0cywgcGF0ZW50cyBvciBwYXRlbnQgYXBwbGljYXRpb25zLCBvciBvdGhlciBw cm9wcmlldGFyeSANCiAgIHJpZ2h0cyB0aGF0IG1heSBjb3ZlciB0ZWNobm9sb2d5IHRoYXQgbWF5 IGJlIHJlcXVpcmVkIHRvIGltcGxlbWVudCANCiAgIHRoaXMgc3RhbmRhcmQuICBQbGVhc2UgYWRk cmVzcyB0aGUgaW5mb3JtYXRpb24gdG8gdGhlIElFVEYgYXQgaWV0Zi0NCiAgIGlwckBpZXRmLm9y Zy4gDQogICAgDQoxMS4xIElQUiBEaXNjbG9zdXJlIEFja25vd2xlZGdlbWVudCAgDQogICAgICAg ICAgIA0KICAgQnkgc3VibWl0dGluZyB0aGlzIEludGVybmV0LURyYWZ0LCBJIGNlcnRpZnkgdGhh dCBhbnkgYXBwbGljYWJsZSANCiAgIHBhdGVudCBvciBvdGhlciBJUFIgY2xhaW1zIG9mIHdoaWNo IEkgYW0gYXdhcmUgaGF2ZSBiZWVuIGRpc2Nsb3NlZCwgDQogICBvciB3aWxsIGJlIGRpc2Nsb3Nl ZCwgYW5kIGFueSBvZiB3aGljaCBJIGJlY29tZSBhd2FyZSB3aWxsIGJlIA0KICAgZGlzY2xvc2Vk LCBpbiBhY2NvcmRhbmNlIHdpdGggUkZDIDM2NjguIA0KICAgIA0KICAgIA0KMTIuIEZ1bGwgQ29w eXJpZ2h0IFN0YXRlbWVudCANCiAgICANCiAgIENvcHlyaWdodCAoQykgVGhlIEludGVybmV0IFNv Y2lldHkgKDIwMDQpLiBUaGlzIGRvY3VtZW50IGlzIHN1YmplY3QgDQogICB0byB0aGUgcmlnaHRz LCBsaWNlbnNlcyBhbmQgcmVzdHJpY3Rpb25zIGNvbnRhaW5lZCBpbiBCQ1AgNzgsIGFuZCANCiAg IGV4Y2VwdCBhcyBzZXQgZm9ydGggdGhlcmVpbiwgdGhlIGF1dGhvcnMgcmV0YWluIGFsbCB0aGVp ciByaWdodHMuIA0KICAgIA0KICAgVGhpcyBkb2N1bWVudCBhbmQgdGhlIGluZm9ybWF0aW9uIGNv bnRhaW5lZCBoZXJlaW4gYXJlIHByb3ZpZGVkIG9uIGFuIA0KICAgIkFTIElTIiBiYXNpcyBhbmQg VEhFIENPTlRSSUJVVE9SLCBUSEUgT1JHQU5JWkFUSU9OIEhFL1NIRSBSRVBSRVNFTlRTIA0KICAg T1IgSVMgU1BPTlNPUkVEIEJZIChJRiBBTlkpLCBUSEUgSU5URVJORVQgU09DSUVUWSBBTkQgVEhF IElOVEVSTkVUIA0KICAgRU5HSU5FRVJJTkcgVEFTSyBGT1JDRSBESVNDTEFJTSBBTEwgV0FSUkFO VElFUywgRVhQUkVTUyBPUiBJTVBMSUVELCANCiAgIElOQ0xVRElORyBCVVQgTk9UIExJTUlURUQg VE8gQU5ZIFdBUlJBTlRZIFRIQVQgVEhFIFVTRSBPRiBUSEUgDQogICBJTkZPUk1BVElPTiBIRVJF SU4gV0lMTCBOT1QgSU5GUklOR0UgQU5ZIFJJR0hUUyBPUiBBTlkgSU1QTElFRCANCiAgIFdBUlJB TlRJRVMgT0YgTUVSQ0hBTlRBQklMSVRZIE9SIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQ T1NFLiANCiAgICANCiAgICANCkFja25vd2xlZGdtZW50IA0KICAgIA0KICAgRnVuZGluZyBmb3Ig dGhlIFJGQyBFZGl0b3IgZnVuY3Rpb24gaXMgY3VycmVudGx5IHByb3ZpZGVkIGJ5IHRoZSANCiAg IEludGVybmV0IFNvY2lldHkuIA0KIA0KIA0KT2dpbm8gICAgICAgICAgICAgICAgICAgIEV4cGly ZXMgLSBNYXJjaCAyMDA1ICAgICAgICAgICAgICAgIFtQYWdlIDEwXSANCgw= --=====================_8806687==_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --=====================_8806687==_--