Protocol Action: 'OSPF Protocol Extensions for Path Computation Element (PCE) Discovery' to Proposed Standard

[The IESG <[e-mail]>]

The IESG has approved the following document:

- 'OSPF Protocol Extensions for Path Computation Element (PCE) 
   Discovery '
   <draft-ietf-pce-disco-proto-ospf-08.txt> as a Proposed Standard

This document is the product of the Path Computation Element Working 
Group. 

The IESG contact persons are Ross Callon and David Ward.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pce-disco-proto-ospf-08.txt

Technical Summary
 
   There are various circumstances where it is highly desirable for a
   Path Computation Client (PCC) to be able to dynamically and
   automatically discover a set of Path Computation Elements (PCE),
   along with some information that can be used for PCE selection. When
   the PCE is a Label Switching Router (LSR) participating in the
   Interior Gateway Protocol (IGP), or even a server participating
   passively in the IGP, a simple and efficient way to discover PCEs
   consists of using IGP flooding. For that purpose, this document
   defines extensions to the Open Shortest Path First (OSPF) routing
   protocol for the advertisement of PCE Discovery information within an
   OSPF area or within the entire OSPF routing domain.
 
Working Group Summary
 
   No dissent reported. The choice is relatively obvious for networks 
   running OSPF. Of course an IS-IS version is also needed for those
   networks that are running IS-IS (and will be submitted to the IESG
   soon). 
 
Protocol Quality
 
   Ross Callon has reviewed this spec for the IESG. I will check on 
   whether there are implementations. 

Note to RFC Editor
 
   Section 1:  Insert two new terms in alphabetic order in the list 
   as follows:

     PCED: PCE Discovery.

     TLV: Type-Length-Variable data encoding.

   Section 4.1

   OLD
     The PCE-ADDRESS sub-TLV is mandatory; it MUST be present within the
     PCED TLV. It MAY appear twice, when the PCE has both an IPv4 and 
     IPv6 address. It MUST NOT appear more than once for the same
     address type. If it appears more than once, only the first
     occurrence is processed and any others MUST be ignored.

   NEW
     The PCE-ADDRESS sub-TLV is mandatory; it MUST be present within the
     PCED TLV. It MAY appear twice, when the PCE has both an IPv4 and 
     IPv6 address. It MUST NOT appear more than once for the same 
     address type. If it appears more than once for the same address 
     type, only the first occurrence is processed and any others MUST be
     ignored.

   Section 5, in the fourth paragraph, remove the last two sentences. 
   Thus:

   OLD
     The PCE address (i.e., the address indicated within the PCE ADDRESS 
     sub-TLV) SHOULD be reachable via some prefixes advertised by OSPF. 
     This allows the detection of a PCE failure to be sped up. When the 
     PCE address is no longer reachable, the PCE node has failed, has 
     been torn down, or there is no longer IP connectivity to the PCE 
     node.

   NEW
     The PCE address (i.e., the address indicated within the PCE ADDRESS 
     sub-TLV) SHOULD be reachable via some prefixes advertised by OSPF. 

   Insert immediately after this paragraph: 

     The PCED TLV information regarding a specific PCE is
     only considered current and useable when the router
     advertising this information is itself reachable via 
     OSPF calculated paths in the same area of the LSA in which
     the PCED TLV appears.

     A change in the state of a PCE (activate, deactivate, 
     parameter change) MUST result in a corresponding change in
     the PCED TLV information advertised by an OSPF router
     (inserted, removed, updated) in its LSA. The way PCEs
     determine the information they advertise and how that
     information is made available to OSPF is out of the scope
     of this document. Some information may be configured (e.g.,
     address, preferences, scope) and other information may be
     automatically determined by the PCE (e.g. areas of visibility).

   Delete the last paragraph of section 5 (this paragraph begins "The 
   way PCEs determine...", and has been moved up in the text). 

   Replace all of section 9.3 with the following text:

     9.3. Liveness Detection and Monitoring

     This document specifies the use of OSPF as a PCE Discovery 
     Protocol. The requirements specified in RFC 4674 include the 
     ability to determine liveness of the PCE Discovery protocol.
     Normal operation of the OSPF protocol meets these requirements. 

   Section 10

   OLD
     We would also like to thank Dave Ward, Lars Eggert, Sam Hartman, and
     Tim Polk for their comments during the final stages of publication.

   NEW
     We would also like to thank Dave Ward, Lars Eggert, Sam Hartman, Tim
     Polk, and Lisa Dusseault for their comments during the final stages 
     of publication.


_______________________________________________
IETF-Announce mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ietf-announce