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

[The IESG <[e-mail]>]

The IESG has approved the following document:

- 'IS-IS Protocol Extensions for Path Computation Element (PCE) 
   Discovery '
   <draft-ietf-pce-disco-proto-isis-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-isis-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 (PCEs), 
   along with information that can be used by the PCC 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 announce PCEs 
   consists of using IGP flooding. For that purpose this document 
   defines extensions to the Intermediate System to Intermediate System 
   (IS-IS) routing protocol for the advertisement of PCE Discovery 
   information within an IS-IS area or within the entire IS-IS routing 
   domain.
 
Working Group Summary
 
   No dissent reported (see PROTO writeup by Adrian Farrel). 
 
Protocol Quality
 
   Ross Callon has reviewed the spec for the IESG. Two downref's were
   called out during the second IETF last call, and have been added to 
   the downref directory. Also, note that this document is very similar
   to the equivalent OSPF document, draft-ietf-pce-disco-proto-ospf. 
   The changes that came up during IESG review of the OSPF document 
   have also been made to this document. 

Note to RFC Editor
 
   The reference to [IS-IS-CAP] will need to be replaced by a reference
   to RFC 4971. 

   Near the bottom of page 4, eigth paragraph of section 2 the double 
   paretheses should be removed. Thus "([IS-IS-CAP])" is replaced with
   "[IS-IS-CAP]", or more precisely with "[RFC 4971]".

   Section 4.1

   OLD
     The PCE-ADDRESS sub-TLV is mandatory; it MUST be present within the
     PCED sub-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 sub-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 fifth 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 IS-IS. 
     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 IS-IS. 

   Insert immediately after this paragraph: 

     The PCED sub-TLV information regarding a specific PCE is
     only considered current and useable when the router
     advertising this information is itself reachable via 
     IS-IS calculated paths at the level of the LSP in which
     the PCED sub-TLV appears.

     A change in the state of a PCE (activate, deactivate, 
     parameter change) MUST result in a corresponding change in
     the PCED sub-TLV information advertised by an IS-IS router
     (inserted, removed, updated) in its LSP. The way PCEs
     determine the information they advertise and how that
     information is made available to IS-IS 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 IS-IS 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 IS-IS protocol meets these requirements.

   Section 10

   OLD
     We would like to thank Lucy Wong, Adrian Farrel, Les Ginsberg, Mike
     Shand, Lou Berger, and David Ward, for their useful comments and
     suggestions.

   NEW
     We would like to thank Lucy Wong, Adrian Farrel, Les Ginsberg, Mike
     Shand, Lou Berger, David Ward, Ross Callon, and Lisa Dusseault for 
     their useful comments and suggestions.


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