From routing-discussion-bounces@ietf.org Thu Jun 3 21:55:12 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19043 for ; Thu, 3 Jun 2004 21:55:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BW3sf-0002It-TB; Thu, 03 Jun 2004 21:52:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BW3o4-0001FK-Qh for routing-discussion@megatron.ietf.org; Thu, 03 Jun 2004 21:47:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18582 for ; Thu, 3 Jun 2004 21:47:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BW3o3-0001v1-45 for routing-discussion@ietf.org; Thu, 03 Jun 2004 21:47:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BW3n5-0001Yh-00 for routing-discussion@ietf.org; Thu, 03 Jun 2004 21:46:40 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BW3m6-0001CL-00 for routing-discussion@ietf.org; Thu, 03 Jun 2004 21:45:38 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BW3m6-0006t5-A2 for routing-discussion@ietf.org; Fri, 04 Jun 2004 01:45:38 +0000 Date: Thu, 3 Jun 2004 18:45:37 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1353393576.20040603184537@psg.com> To: routing-discussion@ietf.org In-Reply-To: <200406021954.PAA15253@ietf.org> References: <200406021954.PAA15253@ietf.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: Fwd: WG Action: Bidirectional Forwarding Detection (bfd) X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area General mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org Content-Transfer-Encoding: 7bit FYI. -- Alex http://www.psg.com/~zinin This is a forwarded message From: The IESG To: IETF-Announce: ; Cc: rtg-bfd@ietf.org, Jeffrey Haas , David Ward Date: Wednesday, June 2, 2004, 12:54:36 PM Subject: WG Action: Bidirectional Forwarding Detection (bfd) ===8<==============Original message text=============== A new IETF working group has been formed in the Routing Area. For additional information, please contact the Area Directors or the WG Chairs. Bidirectional Forwarding Detection (bfd) ========================================= Current Status: Active Working Group Chair(s): David Ward Jeffrey Haas Routing Area Director(s): Bill Fenner Alex Zinin Routing Area Advisor: Alex Zinin Technical Advisor(s): Dave Katz Mailing Lists: General Discussion: rtg-bfd@ietf.org To Subscribe: rtg-bfd-request@ietf.org In Body: With a subject line: subscribe Archive: ftp://ftp.ietf.org/ietf-mail-archive/rtg-bfd-wg Description of Working Group: The BFD Working Group is chartered to specify a protocol for bidirectional forwarding detection (BFD), as well as extensions to be used within the scope of BFD and IP routing, or protocols such as MPLS that are based on IP routing, in a way that will encourage multiple, inter-operable vendor implementations. BFD is a protocol intended to detect faults in the bidirectional path between two forwarding engines, including physical interfaces, subinterfaces, data link(s), and to the extent possible the forwarding engines themselves, with potentially very low latency. It operates independently of media, data protocols, and routing protocols. An additional goal is to provide a single mechanism that can be used for liveness detection over any media, at any protocol layer, with a wide range of detection times and overhead, to avoid a proliferation of different methods. Important characteristics of BFD include: - Simple, fixed-field encoding to facilitate implementations in hardware - Independence of the data protocol being forwarded between two systems. BFD packets are carried as the payload of whatever encapsulating protocol is appropriate for the medium and network. - Path independence: BFD can provide failure detection on any kind of path between systems, including direct physical links, virtual circuits, tunnels, MPLS LSPs, multihop routed paths, and unidirectional links (so long as there is some return path, of course.) - Ability to be bootstrapped by any other protocol that automatically forms peer, neighbor or adjacency relationships to seed BFD endpoint discovery. At this time the WG is chartered to complete the following work items (additional items will require rechartering): 1. Develop the base BFD protocol specification and submit it to the IESG for publication as a Proposed Standard 2. Document BFD encapsulation and usage profile for single-hop IPv4 and IPv6 adjacencies (e.g, physical links and IP/GRE tunnels for static routes, IS-IS, OSPFv2, OSPFv3, single-hop BGP) and submit the specification to the IESG for publication as a Proposed Standard. 3. Document BFD encapsulation and usage profile for MPLS LSPs and submit the specification to the IESG for publication as a Proposed Standard. 4. Develop the MIB module for BFD and submit it to the IESG for publication as a Proposed Standard. 5. Document BFD encapsulation and usage profile for multi-hop IPv4 and IPv6 adjacencies (e.g. OSPF virtual links and iBGP sessions) and submit the specification to the IESG for publication as a Proposed Standard. Topics for Possible Future Work: 1. Document BFD directly over 802.3 in close collaboration and synchronization with the IEEE. Goals and Milestones: Aug 04 Submit the base protocol specification to the IESG to be considered as a Proposed Standard. Aug 04 Submit BFD encapsulation and usage profile for single-hop IPv4 and IPv6 adjacencies to the IESG to be considered as a Proposed Standard Aug 04 Submit BFD encapsulation and usage profile for MPLS LSPs to the IESG to be considered as a Proposed Standard Nov 04 Submit BFD MIB to the IESG to be considered as Proposed Standard. Feb 05 Submit BFD encapsulation and usage profile for multi-hop IPv4 and IPv6 adjacencies to the IESG to be considered as a Proposed Standard ===8<===========End of original message text=========== _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Wed Jun 16 13:42:37 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24155 for ; Wed, 16 Jun 2004 13:42:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Badz3-0007hv-Mw; Wed, 16 Jun 2004 13:13:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Badnj-0000xg-Bn for routing-discussion@megatron.ietf.org; Wed, 16 Jun 2004 13:02:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21389 for ; Wed, 16 Jun 2004 13:02:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Badnf-0001wM-KB for routing-discussion@ietf.org; Wed, 16 Jun 2004 13:02:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BadUJ-0006J8-00 for routing-discussion@ietf.org; Wed, 16 Jun 2004 12:42:12 -0400 Received: from relay3.mail.uk.clara.net ([80.168.70.143]) by ietf-mx with esmtp (Exim 4.12) id 1BadAL-0002qZ-00; Wed, 16 Jun 2004 12:21:33 -0400 Received: from du-069-0656.access.clara.net ([217.158.156.147] helo=Puppy) by relay3.mail.uk.clara.net with smtp (Exim 4.22) id 1BadAI-0004uP-Dt; Wed, 16 Jun 2004 17:21:30 +0100 Message-ID: <009e01c453bd$fb5d3310$d4849ed9@Puppy> From: "Adrian Farrel" To: Date: Wed, 16 Jun 2004 17:21:21 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: l2vpn@ietf.org, L1VPN List , l3vpn@ietf.org, routing-discussion@ietf.org, rtgwg@ietf.org Subject: Layer One VPNs X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Routing Area General mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi, This is just to let you know that a new mail list has been set up for the discussion of Layer One VPNs. Subscription can be managed through https://www1.ietf.org/mailman/listinfo/l1vpn. You are all very welcome to join. This list is currently "under the care" of the CCAMP co-chairs while we evaluate the interest and relevance to the IETF. Much of the initial work for developing service level requirements and an architecture has come from the ITU-T SG13 and we will advance the discussions in a cooperative relationship. At the moment there are three drafts that are of particular interest. http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-framework-00.txt This provides a good background to what L1VPNs are trying to achieve and summarizes the architectures that may be used. http://www.ietf.org/internet-drafts/draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-05.txt Describes a BGP-based solution to "Generalized VPNs". This fits into one of the architectural models for L1VPNs. http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-overlay-04.txt Satisfies another of the L1VPN architectural models. We hope that the next work will be: - review and refinement of the framework draft - tightening and further detail for functional requirements - applicability of the existing GMPLS protocols to the architectures in the framework - identification of any protocol extensions that may be needed. All of this is done under the following provisos: - there continues to be interest within the IETF - it continues to be judged appropriate for the IETF - no better place for the discussions is identified. Comments on these points as well as the drafts and the work itself are welcomed on the list. Please note that at the moment the automatic archiving of the list is broken, but that this will be fixed very soon. Thanks, Adrian _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Thu Jun 17 17:45:37 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18048 for ; Thu, 17 Jun 2004 17:45:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bb4QO-00051X-9e; Thu, 17 Jun 2004 17:27:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bb48g-0008IX-HL for routing-discussion@megatron.ietf.org; Thu, 17 Jun 2004 17:09:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15896 for ; Thu, 17 Jun 2004 17:09:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bb48f-0004WC-1p for routing-discussion@ietf.org; Thu, 17 Jun 2004 17:09:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bb46j-00043L-00 for routing-discussion@ietf.org; Thu, 17 Jun 2004 17:07:39 -0400 Received: from relay1.mail.uk.clara.net ([80.168.70.141]) by ietf-mx with esmtp (Exim 4.12) id 1Bb45j-0003jF-00; Thu, 17 Jun 2004 17:06:35 -0400 Received: from du-069-0092.access.clara.net ([217.158.132.92] helo=Puppy) by relay1.mail.uk.clara.net with smtp (Exim 4.34) id 1Bb45f-000BDD-5J; Thu, 17 Jun 2004 22:06:34 +0100 Message-ID: <01e201c454ae$f7966d90$d4849ed9@Puppy> From: "Adrian Farrel" To: , "'mpls@uu.net'" , , , "TEWG" Date: Thu, 17 Jun 2004 22:01:25 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 Cc: "'Jean Philippe Vasseur'" Subject: Path Computation Element (PCE) BOF X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Routing Area General mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1223726028==" Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org This is a multi-part message in MIME format. --===============1223726028== Content-Type: multipart/alternative; boundary="----=_NextPart_000_01D7_01C454B6.A251D6F0" This is a multi-part message in MIME format. ------=_NextPart_000_01D7_01C454B6.A251D6F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, We will be holding a BOF in San Diego under the care of the Routing = Area. Please see the description, a draft agenda, and proposed charter below. We'd welcome any thoughts for additions to the agenda, and any pointers = to existing drafts that you consider already fit within this scope. If you have views for or against, please bring them to the BOF where we = will hopefully have time to air them fully. Thanks, Adrian and JP =3D=3D=3D=3D Path Computation Element BOF (PCE BOF) Agenda 60th IETF, San Diego, August 2004 =20 Routing Area Ads: Alex Zinin (zinin@psg.com), Bill Fenner (fenner@research.att.com) BOF Chairs: JP Vasseur (jvasseur@cisco.com), Adrian Farrel (adrian@olddog.co.uk) Description: In certain MPLS TE networks it may be beneficial or desirable to have = path=20 computation performed by a distinct node (termed the Path Computation=20 Element PCE) that is not the LSR that needs to know the path. This BOF=20 examines the scope of such function, what extensions to existing = protocols=20 might required, what additional protocols may need to be developed, and=20 whether there is cuase and support for this work within the IETF. --- =20 Proposed BOF agenda 1) Introduction, admin, statement of objectives of the BOF (10 minutes) 2) Overview of PCE-based LSP Path computation (10 minutes) - terminology - dichotomy (centralized versus distributed, statefull versus=20 stateless, ...) 3) Requirements for PCE-based path computation (5 minutes) - for intra-area TE LSP (packet and non packet LSP, multiple=20 criteria optimization techniques, online/offline) - for inter-area and inter-AS TE (shared information or=20 collaborative computation) 4) Functional requirements of a PCE-based path computation system (10 = minutes) - Framework, - Path computation model - discovery of PCEs within a network - distribution of TE information to PCEs - LSR-PCE communication - Monitoring and Management (MIBs) - Policy/Security/Confidentiality in the context of = inter-providers 5) Current status of drafts and early implementations (10 minutes) 6) Why should this be IETF work? (5 minutes) - CCAMP or new Working Group? - Is this work limited to MPLS-TE? What about BGP route = servers? 7) Proposed charter (see below) (10 minutes) 8) Open discussion (50 minutes) 9) Summary and conclusions (10 minutes) --- =20 Proposed WG Charter =20 Organizational Overview The PCE working group coordinates the work within the IETF of defining = the=20 operation of path computation elements within the Internet. Path=20 computation elements are responsible for computing paths through IP=20 networks for uses such as traffic engineering so that a prime consumer = of=20 such paths might be an MPLS-TE LSR. Areas of responsibility will include = the collection of attributes relevant to the computation of paths, the=20 discovery by LSRs of available path computation elements, the = communication=20 with LSRs for the request of path computation, the collaboration between = path computation elements within the network, and analysis of path=20 computation algorithms with a view to ensuring consistency between = computed=20 paths. The working group will work closely with many working groups in = the=20 Routing Area including the OSPF, IS-IS, IDR, MPLS and CCAMP working = groups. Working Group Scope The PCE working group scope includes: - Definition of Generalized Traffic Engineered LSP paths computation=20 techniques involving Path Computation Element(s). This includes the = intra=20 IGP area, inter IGP area, inter-AS and inter-provider TE LSPs path=20 computation for Point-to-Point, Point-to-Multipoint and=20 Multipoint-to-Multipoint TE LSPs. - Definition of protocol-independent metrics and constraints defining = path=20 quality measurement criteria, algorithm complexity and scalability = criteria=20 related to path computation techniques. - Definition of requirements for communication between LSRs and PCEs=20 including routing extensions in support of PCE discovery techniques = within=20 an IGP area and across multiple IGP areas, ASes and Provider networks, = and=20 including the development of new protocols or protocol extensions for=20 requesting path computation and supplying responses. Any protocol=20 extensions will developed in conjunction with the working groups in = charge=20 of the specific protocols. - Specification of routing (OSPF, ISIS, BGP) and signalling extensions=20 (RSVP-TE) required by PCE-based path computation techniques. The = extensions=20 will developed in conjunction with the working groups in charge of the = specific protocols. - Specification of requirements and protocol extensions related to the=20 policy, security and confidentiality aspects of PCE-based path = computation=20 techniques involving PCEs of multiple Providers. - Definition of MIBs, management procedures related to the protocol=20 extensions defined by the WG In doing this work, the WG will closely work with at least the following = other WGs: CCAMP, MPLS, ISIS, OSPF, IDR. The WG will also cooperate with = the ITU-T and OIF. Goals and Milestones Dates for milestones to be decided later. Post strawman WG goals and charter. Submit WG document defining the framework and applicability of the=20 PCE model. Select a single candidate protocol from communication between LSRs=20 and PCEs. Submit document(s) that define various path computation models =20 Submit an analysis document examining the requirements for coherent computation techniques and the implication of cooperation between=20 PCEs. Submit a document defining the protocol for communication between=20 LSRs and PCEs. Submit document(s) defining extensions to routing and signalling=20 protocols necessary to support the use of a PCE model within MPLS networks. =20 Submit a document defining MIB modules for modeling and management=20 of PCE systems. ------=_NextPart_000_01D7_01C454B6.A251D6F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
We will be holding a BOF in San Diego = under the=20 care of the Routing Area.
 
Please see the description, a draft = agenda, and=20 proposed charter below.
 
We'd welcome any thoughts for = additions to the=20 agenda, and any pointers to existing drafts that you consider already = fit within=20 this scope.
 
If you have views for or against, = please bring=20 them to the BOF where we will hopefully have time to air them=20 fully.
 
Thanks,
Adrian and JP
 
=3D=3D=3D=3D
Path Computation Element BOF (PCE = BOF)=20 Agenda
60th IETF, San Diego, August 2004
 
Routing Area = Ads: Alex=20 Zinin (zinin@psg.com),
          &nbs= p;     =20  Bill Fenner (fenner@research.att.com)

BOF Chairs: JP Vasseur (jvasseur@cisco.com),
           =  Adrian=20 Farrel (adrian@olddog.co.uk)

Description:
In certain MPLS TE networks it may be = beneficial=20 or desirable to have path 
computation performed by a distinct = node=20 (termed the Path Computation 
Element  PCE) that is not the = LSR=20 that needs to know the path. This BOF 
examines the scope of = such=20 function, what extensions to existing protocols 
might required, = what=20 additional protocols may need to be developed, and 
whether = there is=20 cuase and support for this work within the IETF.
---
 
Proposed BOF agenda
1) = Introduction,=20 admin, statement of objectives of the BOF (10 minutes)
2) Overview of = PCE-based LSP Path computation (10=20 minutes)
         -=20 terminology
         - = dichotomy=20 (centralized versus distributed, statefull=20 versus 
         &nb= sp; stateless,=20 ...)
3) Requirements for PCE-based path computation (5=20 minutes)
         - for = intra-area TE=20 LSP (packet and non packet LSP,=20 multiple 
         &= nbsp; criteria=20 optimization techniques,=20 online/offline)
         - = for=20 inter-area and inter-AS TE (shared information=20 or 
         =20  collaborative computation)
4) Functional requirements of a = PCE-based=20 path computation system  (10=20 minutes)
         -=20 Framework,
         - Path=20 computation model
         -=20 discovery of PCEs within a=20 network
         - = distribution of TE=20 information to PCEs
         = -=20 LSR-PCE = communication
         -=20 Monitoring and Management=20 (MIBs)
         -=20 Policy/Security/Confidentiality in the context of inter-providers
5) = Current=20 status of drafts and early implementations (10 minutes)
6) Why should = this be=20 IETF work? (5 = minutes)
         -=20 CCAMP or new Working = Group?
        =20 - Is this work limited to MPLS-TE? What about BGP route servers?
7) = Proposed=20 charter (see below) (10 minutes)
8) Open discussion (50 = minutes)
9)=20 Summary and conclusions (10 minutes)
---
 
Proposed WG=20 Charter
 
Organizational Overview
The PCE working group=20 coordinates the work within the IETF of defining the 
operation = of path=20 computation elements within the Internet. Path 
computation = elements are=20 responsible for computing paths through IP 
networks for uses = such as=20 traffic engineering so that a prime consumer of 
such paths = might be an=20 MPLS-TE LSR. Areas of responsibility will include 
the = collection of=20 attributes relevant to the computation of paths, the 
discovery = by LSRs=20 of available path computation elements, the communication 
with = LSRs for=20 the request of path computation, the collaboration between 
path = computation elements within the network, and analysis of=20 path 
computation algorithms with a view to ensuring consistency = between=20 computed 
paths. The working group will work closely with many = working=20 groups in the 
Routing Area including the OSPF, IS-IS, IDR, MPLS = and=20 CCAMP working groups.

Working Group Scope
The PCE working = group scope=20 includes:
- Definition  of Generalized Traffic Engineered LSP = paths=20 computation 
  techniques involving Path Computation = Element(s).=20 This includes the intra 
  IGP area, inter IGP area, = inter-AS and=20 inter-provider TE LSPs path 
  computation for = Point-to-Point,=20 Point-to-Multipoint and 
  Multipoint-to-Multipoint TE = LSPs.
-=20 Definition of protocol-independent metrics and constraints defining=20 path 
  quality measurement criteria, algorithm complexity = and=20 scalability criteria 
  related to path computation=20 techniques.
- Definition of requirements for communication between = LSRs and=20 PCEs 
  including routing extensions in support of PCE = discovery=20 techniques within 
  an IGP area and across multiple IGP = areas,=20 ASes and Provider networks, and 
  including the = development of new=20 protocols or protocol extensions for 
  requesting path = computation=20 and supplying responses. Any protocol 
  extensions will = developed=20 in conjunction with the working groups in charge
  of the = specific=20 protocols.
- Specification of routing (OSPF, ISIS, BGP) and = signalling=20 extensions 
  (RSVP-TE) required by PCE-based path = computation=20 techniques. The extensions
  will developed in conjunction with = the=20 working groups in charge of the
  specific protocols.
-=20 Specification of requirements and protocol extensions related to=20 the 
  policy, security and confidentiality aspects of = PCE-based=20 path computation
  techniques involving PCEs of multiple=20 Providers.
- Definition of MIBs, management procedures related to the = protocol 
  extensions defined by the WG

In doing = this work,=20 the WG will closely work with at least the following 
other WGs: = CCAMP,=20 MPLS, ISIS, OSPF, IDR. The WG will also cooperate with 
the=20 ITU-T and OIF.

Goals and Milestones

Dates for = milestones to=20 be decided later.

  Post strawman WG goals and=20 charter.

  Submit WG document defining the framework and=20 applicability of the 
  PCE model.

  = Select a=20 single candidate protocol from communication between = LSRs 
  and=20 PCEs.

  Submit document(s) that define various path = computation=20 models
 
  Submit an analysis document examining the=20 requirements for coherent
  computation techniques and the = implication=20 of cooperation between 
  PCEs.

  Submit a = document=20 defining the protocol for communication between 
  LSRs=20 and PCEs.

  Submit document(s) defining extensions to = routing=20 and signalling 
  protocols necessary to support the = use of a=20 PCE model within MPLS
  networks.
 
  Submit=20 a document defining MIB modules for modeling and = management 
  of=20 PCE systems.
------=_NextPart_000_01D7_01C454B6.A251D6F0-- --===============1223726028== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion --===============1223726028==-- From routing-discussion-bounces@ietf.org Thu Jun 17 20:05:47 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28021 for ; Thu, 17 Jun 2004 20:05:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bb6lU-0007SE-H0; Thu, 17 Jun 2004 19:57:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bb6eD-0004mt-Dz for routing-discussion@megatron.ietf.org; Thu, 17 Jun 2004 19:50:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27007 for ; Thu, 17 Jun 2004 19:50:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bb6eB-0003pY-SQ for routing-discussion@ietf.org; Thu, 17 Jun 2004 19:50:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bb6dH-0003Vt-00 for routing-discussion@ietf.org; Thu, 17 Jun 2004 19:49:24 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1Bb6ce-0003CF-00 for routing-discussion@ietf.org; Thu, 17 Jun 2004 19:48:44 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bb6ce-0000Eq-7L for routing-discussion@ietf.org; Thu, 17 Jun 2004 23:48:44 +0000 Date: Thu, 17 Jun 2004 16:48:41 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1884056252.20040617164841@psg.com> To: routing-discussion@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: Open Routing Area meeting in San Diego X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area General mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org Content-Transfer-Encoding: 7bit Folks- As usual, we will hold an open RTG area meeting in San Diego. At this time, we have the following topic for discussion: IP Traffic Engineering RM: draft-shen-ip-te-rsp-00.txt If you would like to request a slot, please send an e-mail to Bill and me. -- Alex http://www.psg.com/~zinin _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Thu Jun 17 20:17:53 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28771 for ; Thu, 17 Jun 2004 20:17:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bb6yp-0003Ux-5l; Thu, 17 Jun 2004 20:11:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bb6pt-0000qW-1L for routing-discussion@megatron.ietf.org; Thu, 17 Jun 2004 20:02:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27591 for ; Thu, 17 Jun 2004 20:02:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bb6pr-0007VU-Hv for routing-discussion@ietf.org; Thu, 17 Jun 2004 20:02:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bb6oq-00076C-00 for routing-discussion@ietf.org; Thu, 17 Jun 2004 20:01:21 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1Bb6n0-0006VV-00 for routing-discussion@ietf.org; Thu, 17 Jun 2004 19:59:26 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bb6n0-0001Tn-PL; Thu, 17 Jun 2004 23:59:26 +0000 Date: Thu, 17 Jun 2004 16:59:23 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1938974374.20040617165923@psg.com> To: Pekka Savola In-Reply-To: References: <19150967.20040503182939@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: routing-discussion@ietf.org Subject: Re: Updated version posted: draft-kompella-zinin-early-allocation-01.txt X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area General mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org Content-Transfer-Encoding: 7bit Pekka, Catching up on old things... Wednesday, May 19, 2004, 5:11:19 AM, Pekka Savola wrote: > On Mon, 3 May 2004, Alex Zinin wrote: >> Kireeti and I updated the draft based on the comments we got via e-mail and at >> the meeting in Seoul. Please check the new rev. We will be asking Bill to Last >> Call the document within a few weeks. Send comments to routing-discussion@ietf.org, >> please. > Seems like good stuff. First time I read this -- a few rather minor > comments below. > semi-substantial > ---------------- > If conditions (a) or (b) are not met, then the processes in this memo > do not apply. ==>> why do not conditions (c) and (d) be considered as blocking? What's the > difference with these processed? > Or do you mean that (a) or (b) are the "show-stopper" issues which MUST have > been fulfilled before even considering this approach, and c)-d) must be > filled in any case, but that's then up to the WG (and chairs) whether > they consider these filled or not? Exactly. > The similar comment applies to: > 2) The WG chairs determine whether the conditions for early > allocations described in section 2 are met, particularly > conditions (c) and (d). > .... > [3692] Narten, T., "Assigning Experimental and Testing Numbers > Considered Useful", BCP 82, RFC 3692, January 2004 ==>> this wasn't used in the body; remove or add reference? removed > editorial > --------- > performs allocation. However, in situations where codepoints are a > scarce resource and/or the IETF community is willing to retain tight > control of the protocol, policies such as IESG Approval, IETF ==>> s/is willing/wants/ (there's a nuance difference but I think the latter > is closer) ok > 2. IANA allocates codepoints silently used for other extensions. > Different extensions will collide. ==>> please reword, I didn't quite understand the "silently used" parts. > Prefix with "that someone has illegitimately" ? Frankly, I don't find your suggested text much clearer either :) What the text means is someone just grabbing a codepoint and using it without registration. > 1) The authors (editors) of the document submit a request for early > allocation the Working Group chairs, specifying which code points ==>> s/allocation/allocation to/ ok > immediately obvious: depletion of code space by early allocations; > and process overburden of IANA itself. The processes described here ==>> I find "process overburden" a bit difficult to parse. changed to "process overloading". Will resubmit shortly. Thanks! Alex _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Thu Jun 17 20:42:13 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00045 for ; Thu, 17 Jun 2004 20:42:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bb7JK-0000IA-UZ; Thu, 17 Jun 2004 20:32:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bb71M-00046d-Ce for routing-discussion@megatron.ietf.org; Thu, 17 Jun 2004 20:14:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28648 for ; Thu, 17 Jun 2004 20:14:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bb71K-00045a-Og for routing-discussion@ietf.org; Thu, 17 Jun 2004 20:14:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bb70L-0003kc-00 for routing-discussion@ietf.org; Thu, 17 Jun 2004 20:13:13 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1Bb6zP-0003QP-00 for routing-discussion@ietf.org; Thu, 17 Jun 2004 20:12:16 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bb6zQ-0003EW-GA; Fri, 18 Jun 2004 00:12:16 +0000 Date: Thu, 17 Jun 2004 17:12:15 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1961160596.20040617171215@psg.com> To: Mukesh.Gupta@nokia.com In-Reply-To: <8D260779A766FB4A9C1739A476F84FA401F79A37@daebe009.americas.nokia.com> References: <8D260779A766FB4A9C1739A476F84FA401F79A37@daebe009.americas.nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: routing-discussion@ietf.org Subject: Re: Updated version posted: draft-kompella-zinin-early-allocation-01.txt X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area General mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org Content-Transfer-Encoding: 7bit Thanks Mukesh! I'll certainly address those in the next rev. -- Alex http://www.psg.com/~zinin Monday, May 17, 2004, 12:14:29 AM, Mukesh.Gupta@nokia.com wrote: > Alex, > The changes look good to me. Minor points.. > - The draft needs to update the internet draft template. > "This document is an Internet-Draft and is in full > conformance with all provisions of Section 10 of > RFC2026." should be replaced with "By submitting > this Internet-Draft, I certify that any applicable > patent or other IPR claims of which I am aware have > been disclosed, and any of which I become aware will > be disclosed, in accordance with RFC 3668." > - Also it should include the Intellectual Property Statement > at the end. > Regards > Mukesh >> -----Original Message----- >> From: routing-discussion-admin@ietf.org >> [mailto:routing-discussion-admin@ietf.org]On Behalf Of ext Alex Zinin >> Sent: Monday, May 03, 2004 6:30 PM >> To: routing-discussion@ietf.org >> Subject: Updated version posted: >> draft-kompella-zinin-early-allocation-01.txt >> >> >> Folks- >> >> Kireeti and I updated the draft based on the comments we got >> via e-mail and at >> the meeting in Seoul. Please check the new rev. We will be >> asking Bill to Last >> Call the document within a few weeks. Send comments to >> routing-discussion@ietf.org, >> please. >> >> The draft is available at: >> >> >> http://www.ietf.org/internet-drafts/draft-kompella-zinin-early >> -allocation-01.txt >> >> For your convenience, the htmldiff is available at: >> >> >> http://www.psg.com/~zinin/ietf/draft-kompella-zinin-early-allo >> cation-00-01-diff.html >> >> Abstract from the draft: >> >> This memo discusses earlier allocation of code points by IANA as a >> remedy to the problem created by the "Standards Action" IANA policy >> for protocols where, by the IETF process, implementation and >> deployment experience is desired or required prior to publication. >> >> -- >> Alex >> http://www.psg.com/~zinin/ >> >> >> _______________________________________________ >> routing-discussion mailing list >> routing-discussion@ietf.org >> https://www1.ietf.org/mailman/listinfo/routing-discussion >> _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Fri Jun 18 01:35:49 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14359 for ; Fri, 18 Jun 2004 01:35:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BbBxL-0004jX-Lf; Fri, 18 Jun 2004 01:30:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BbBsZ-0003vy-EF for routing-discussion@megatron.ietf.org; Fri, 18 Jun 2004 01:25:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13860 for ; Fri, 18 Jun 2004 01:25:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BbBsX-0001ab-9T for routing-discussion@ietf.org; Fri, 18 Jun 2004 01:25:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BbBrb-0001D4-00 for routing-discussion@ietf.org; Fri, 18 Jun 2004 01:24:32 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1BbBpX-0000EV-00 for routing-discussion@ietf.org; Fri, 18 Jun 2004 01:22:23 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i5I5Lp202618; Fri, 18 Jun 2004 08:21:52 +0300 Date: Fri, 18 Jun 2004 08:21:51 +0300 (EEST) From: Pekka Savola To: Alex Zinin In-Reply-To: <1938974374.20040617165923@psg.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Cc: routing-discussion@ietf.org Subject: Re: Updated version posted: draft-kompella-zinin-early-allocation-01.txt X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org On Thu, 17 Jun 2004, Alex Zinin wrote: > Wednesday, May 19, 2004, 5:11:19 AM, Pekka Savola wrote: > > On Mon, 3 May 2004, Alex Zinin wrote: > >> Kireeti and I updated the draft based on the comments we got via e-mail and at > >> the meeting in Seoul. Please check the new rev. We will be asking Bill to Last > >> Call the document within a few weeks. Send comments to routing-discussion@ietf.org, > >> please. > > > Seems like good stuff. First time I read this -- a few rather minor > > comments below. > > > semi-substantial > > ---------------- > > > If conditions (a) or (b) are not met, then the processes in this memo > > do not apply. > > ==>> why do not conditions (c) and (d) be considered as blocking? What's the > > difference with these processed? > > > Or do you mean that (a) or (b) are the "show-stopper" issues which MUST have > > been fulfilled before even considering this approach, and c)-d) must be > > filled in any case, but that's then up to the WG (and chairs) whether > > they consider these filled or not? > > Exactly. But isn't b) at least also a judgment call? It might not be clear whether a random I-D has "adequate description" -- this check must be done by someone, and someone else might disagree. I agree that a) is a more binary choice. > > 2. IANA allocates codepoints silently used for other extensions. > > Different extensions will collide. > > ==>> please reword, I didn't quite understand the "silently used" parts. > > Prefix with "that someone has illegitimately" ? > > Frankly, I don't find your suggested text much clearer either :) > What the text means is someone just grabbing a codepoint and using > it without registration. Well, this is not a hot issue for me, though IMHO "silently used" is not obvious enough (it could be read many different ways). -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Mon Jun 21 18:33:12 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10524 for ; Mon, 21 Jun 2004 18:33:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcX9b-00006M-Sj; Mon, 21 Jun 2004 18:20:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcWzL-00025P-Om for routing-discussion@megatron.ietf.org; Mon, 21 Jun 2004 18:10:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07649 for ; Mon, 21 Jun 2004 18:10:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BcWzK-0005ly-6j for routing-discussion@ietf.org; Mon, 21 Jun 2004 18:10:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BcWyW-0005VT-00 for routing-discussion@ietf.org; Mon, 21 Jun 2004 18:09:13 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BcWxv-0005ER-00 for routing-discussion@ietf.org; Mon, 21 Jun 2004 18:08:35 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BcWxv-000DEp-Sv; Mon, 21 Jun 2004 22:08:35 +0000 Date: Mon, 21 Jun 2004 15:08:34 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <944770795.20040621150834@psg.com> To: Pekka Savola In-Reply-To: References: <1938974374.20040617165923@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: routing-discussion@ietf.org Subject: Re: Updated version posted: draft-kompella-zinin-early-allocation-01.txt X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area General mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org Content-Transfer-Encoding: 7bit Pekka, > But isn't b) at least also a judgment call? In some situations. If there's no documentation at all, then it's a clear cut. > It might not be clear > whether a random I-D has "adequate description" -- this check must be > done by someone, and someone else might disagree. I agree that a) is > a more binary choice. Any wording suggestions? >> > 2. IANA allocates codepoints silently used for other extensions. >> > Different extensions will collide. >> >> ==>> please reword, I didn't quite understand the "silently used" parts. >> > Prefix with "that someone has illegitimately" ? >> >> Frankly, I don't find your suggested text much clearer either :) >> What the text means is someone just grabbing a codepoint and using >> it without registration. > Well, this is not a hot issue for me, though IMHO "silently used" is > not obvious enough (it could be read many different ways). If the text is good enough, let's leave it as is. If you're afraid it may be misinterpreted, I'd like to know what you have in mind. Thanks. Alex _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Fri Jun 25 15:26:17 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05210 for ; Fri, 25 Jun 2004 15:26:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bdw5I-0005kX-1l; Fri, 25 Jun 2004 15:10:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bdvz0-0008JT-8d for routing-discussion@megatron.ietf.org; Fri, 25 Jun 2004 15:03:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02999 for ; Fri, 25 Jun 2004 15:03:28 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bdvyy-0003V6-Vp for routing-discussion@ietf.org; Fri, 25 Jun 2004 15:03:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bdvy7-0003Ej-00 for routing-discussion@ietf.org; Fri, 25 Jun 2004 15:02:36 -0400 Received: from [209.219.209.75] (helo=ckmso2.proxy.att.com) by ietf-mx with esmtp (Exim 4.12) id 1BdvxW-0002vq-00; Fri, 25 Jun 2004 15:01:59 -0400 Received: from attrh5i.attrh.att.com ([135.38.62.12]) by ckmso2.proxy.att.com (AT&T IPNS/MSO-5.5) with ESMTP id i5PJ1Q3d014620; Fri, 25 Jun 2004 15:01:26 -0400 Received: from kcclust06evs1.ugd.att.com (135.38.164.88) by attrh5i.attrh.att.com (7.1.006) id 40D5B5A600151601; Fri, 25 Jun 2004 15:01:14 -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, 25 Jun 2004 14:01:23 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA060CE177@KCCLUST06EVS1.ugd.att.com> Thread-Topic: Path Computation Element (PCE) BOF Thread-Index: AcRUr0dzmSxeTiQ0RZy92QvHx5wFMwGNiQng From: "Ash, Gerald R \(Jerry\), ALABS" To: , "mpls@uu.net" , , , "TEWG" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Cc: "Ash, Gerald R \(Jerry\), ALABS" , Adrian Farrel , Jean Philippe Vasseur Subject: RE: Path Computation Element (PCE) BOF X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org Content-Transfer-Encoding: quoted-printable All, Please review and comment on "Path Computation Element (PCE) Problem Statement" http://www.ietf.org/internet-drafts/draft-ash-pce-problem-statement-00.t xt. The PCE is an approach to MPLS traffic engineering that is applicable to inter-area and inter-AS path computation. A problem statement and overview of solution alternatives is provided. This will be discussed during the PCE BOF outlined below. Thanks, Jerry=20 ________________________________ From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel Sent: Thursday, June 17, 2004 5:01 PM To: ccamp@ops.ietf.org; 'mpls@uu.net'; routing-discussion@ietf.org; rtgwg@ietf.org; TEWG Cc: 'Jean Philippe Vasseur' Subject: Path Computation Element (PCE) BOF Hi, =20 We will be holding a BOF in San Diego under the care of the Routing Area. =20 Please see the description, a draft agenda, and proposed charter below. =20 We'd welcome any thoughts for additions to the agenda, and any pointers to existing drafts that you consider already fit within this scope. =20 If you have views for or against, please bring them to the BOF where we will hopefully have time to air them fully. =20 Thanks, Adrian and JP =20 =3D=3D=3D=3D Path Computation Element BOF (PCE BOF) Agenda 60th IETF, San Diego, August 2004 =20 Routing Area Ads: Alex Zinin (zinin@psg.com ), Bill Fenner (fenner@research.att.com ) BOF Chairs: JP Vasseur (jvasseur@cisco.com ), Adrian Farrel (adrian@olddog.co.uk ) Description: In certain MPLS TE networks it may be beneficial or desirable to have path=20 computation performed by a distinct node (termed the Path Computation=20 Element PCE) that is not the LSR that needs to know the path. This BOF=20 examines the scope of such function, what extensions to existing protocols=20 might required, what additional protocols may need to be developed, and=20 whether there is cuase and support for this work within the IETF. --- Proposed BOF agenda 1) Introduction, admin, statement of objectives of the BOF (10 minutes) 2) Overview of PCE-based LSP Path computation (10 minutes) - terminology - dichotomy (centralized versus distributed, statefull versus=20 stateless, ...) 3) Requirements for PCE-based path computation (5 minutes) - for intra-area TE LSP (packet and non packet LSP, multiple=20 criteria optimization techniques, online/offline) - for inter-area and inter-AS TE (shared information or=20 collaborative computation) 4) Functional requirements of a PCE-based path computation system (10 minutes) - Framework, - Path computation model - discovery of PCEs within a network - distribution of TE information to PCEs - LSR-PCE communication - Monitoring and Management (MIBs) - Policy/Security/Confidentiality in the context of inter-providers 5) Current status of drafts and early implementations (10 minutes) 6) Why should this be IETF work? (5 minutes) - CCAMP or new Working Group? - Is this work limited to MPLS-TE? What about BGP route servers? 7) Proposed charter (see below) (10 minutes) 8) Open discussion (50 minutes) 9) Summary and conclusions (10 minutes) --- Proposed WG Charter =20 Organizational Overview The PCE working group coordinates the work within the IETF of defining the=20 operation of path computation elements within the Internet. Path=20 computation elements are responsible for computing paths through IP=20 networks for uses such as traffic engineering so that a prime consumer of=20 such paths might be an MPLS-TE LSR. Areas of responsibility will include the collection of attributes relevant to the computation of paths, the=20 discovery by LSRs of available path computation elements, the communication=20 with LSRs for the request of path computation, the collaboration between path computation elements within the network, and analysis of path=20 computation algorithms with a view to ensuring consistency between computed=20 paths. The working group will work closely with many working groups in the=20 Routing Area including the OSPF, IS-IS, IDR, MPLS and CCAMP working groups. Working Group Scope The PCE working group scope includes: - Definition of Generalized Traffic Engineered LSP paths computation=20 techniques involving Path Computation Element(s). This includes the intra=20 IGP area, inter IGP area, inter-AS and inter-provider TE LSPs path=20 computation for Point-to-Point, Point-to-Multipoint and=20 Multipoint-to-Multipoint TE LSPs. - Definition of protocol-independent metrics and constraints defining path=20 quality measurement criteria, algorithm complexity and scalability criteria=20 related to path computation techniques. - Definition of requirements for communication between LSRs and PCEs=20 including routing extensions in support of PCE discovery techniques within=20 an IGP area and across multiple IGP areas, ASes and Provider networks, and=20 including the development of new protocols or protocol extensions for=20 requesting path computation and supplying responses. Any protocol=20 extensions will developed in conjunction with the working groups in charge=20 of the specific protocols. - Specification of routing (OSPF, ISIS, BGP) and signalling extensions=20 (RSVP-TE) required by PCE-based path computation techniques. The extensions=20 will developed in conjunction with the working groups in charge of the specific protocols. - Specification of requirements and protocol extensions related to the=20 policy, security and confidentiality aspects of PCE-based path computation=20 techniques involving PCEs of multiple Providers. - Definition of MIBs, management procedures related to the protocol=20 extensions defined by the WG In doing this work, the WG will closely work with at least the following other WGs: CCAMP, MPLS, ISIS, OSPF, IDR. The WG will also cooperate with the ITU-T and OIF. Goals and Milestones Dates for milestones to be decided later. Post strawman WG goals and charter. Submit WG document defining the framework and applicability of the=20 PCE model. Select a single candidate protocol from communication between LSRs=20 and PCEs. Submit document(s) that define various path computation models =20 Submit an analysis document examining the requirements for coherent computation techniques and the implication of cooperation between=20 PCEs. Submit a document defining the protocol for communication between=20 LSRs and PCEs. Submit document(s) defining extensions to routing and signalling=20 protocols necessary to support the use of a PCE model within MPLS networks. =20 Submit a document defining MIB modules for modeling and management=20 of PCE systems. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion