Skip to main content

Requirements for GMPLS Applications of PCE
draft-ietf-pce-gmpls-aps-req-09

Yes

(Adrian Farrel)

No Objection

(Barry Leiba)
(Gonzalo Camarillo)
(Jari Arkko)
(Martin Stiemerling)
(Richard Barnes)
(Sean Turner)
(Spencer Dawkins)
(Stewart Bryant)

Note: This ballot was opened for revision 08 and is now closed.

Adrian Farrel Former IESG member
Yes
Yes (for -08) Unknown

                            
Barry Leiba Former IESG member
No Objection
No Objection (for -08) Unknown

                            
Benoît Claise Former IESG member
(was Discuss) No Objection
No Objection (2013-07-23) Unknown
For the record only. No action on the draft is needed.

There were actually two issues in my initial discussion:
1. this specific draft
2. a generic issue of PCE management

During the IESG telechat, I overreacted on the issue 2. while looking at 1.

1. The draft-ietf-pce-gmpls-aps-req-09.txt draft addresses my concern with the new "GMPLS PCE Management" section

2. A generic issue of PCE management
http://tools.ietf.org/html/rfc4655#section-9 "manageability considerations" is very good. It covers a lot.
But 7 years after, I would be appropriate to have a PCE manageability draft, covering the different manageability pieces (MIB, OAM, you-name-it) and basically express how to manage a PCE network (with extensions)  today.
Just one example for this RFC: "it must be possible to control the application of policy at the PCE through configuration." How is it done today?

Regards, Benoit
Gonzalo Camarillo Former IESG member
No Objection
No Objection (for -08) Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection (for -08) Unknown

                            
Joel Jaeggli Former IESG member
(was Discuss) No Objection
No Objection (2013-08-16) Unknown
09 addresses my major concerns.

former discuss:

Abstract

  The initial effort of the PCE (Path computation element) WG is
  specifically focused on MPLS.  As a next step, this draft describes
   functional requirements for GMPLS application of PCE.

Was specifically focused on mpls

Is replicated in section 1

also I'm not sure it was 

https://datatracker.ietf.org/doc/rfc4655/

is the very first document out the door for pce and it already states it's applicability to GMPLS. likewise GMPLS is included in the the charter.


3.3 

Mibs are not the sole manageability consideration associated with the application of PCE to GMPLS networks

     reliance on other protocols and functions are considerations (e.g. in or out of band signaling) are a considers

     impact on network operations are a consideration.

4. 

imho the security considerations section is inadequate.  at a minimum it should cite supporting PCE security considerations secretion of RFC 4655
former comment:

Some of the items here are nits I don't feel strongly about those but they are inline and I can shift them to a comment.

also in section 1

   This document provides the investigated results of GMPLS applications
  of PCE for the support of GMPLS path computation.  This document also
  provides requirements for GMPLS applications of PCE in GMPLS intra-
  domain and inter-domain environments.

awkward

  This document provides requirements for GMPLS application 
  of PCE in support of GMPLS path computation, included are
  requirements for both intra-domain and inter-domain environments.

2.1.  Path computation in GMPLS network

  Figure 1 depicts a typical GMPLS network, consisting of an ingress
  link, a transit link as well as an egress link, to investigate a
   consistent guideline for GMPLS path computation.

awkward

  Figure 1 depicts a model GMPLS network, consisting of an ingress
  link, a transit link as well as an egress link. We will use this model to investigate
   consistent guidelines for GMPLS path computation.

fig 2. 

  The
   client Ethernet service could be provided by a VC4 connection

Virtual Concatenation is not a connection it's a mapping.


3.1.  Requirements on Path Computation Request

  As for path computation in GMPLS-controlled networks as discussed in
  section 2, the PCE should consider the GMPLS TE attributes
  appropriately once a PCC or another PCE requests a path computation.
  Indeed, the path calculation request message from the PCC or the PCE
  must contain the information specifying appropriate attributes.
  According to [RFC5440], [PCE-WSON-REQ] and to RSVP procedures like
  explicit label control(ELC),the additional attributes introduced are
  as follows:


Starting an entirely new section with a subordinating conjunction is super painful it implies this is part of section 2

 If this is just a subsection of section 2 then great it should be reorganized.

Otherwise, consider:

The PCE should consider the GMPLS TE attributes appropriately once a PCC or another PCE requests a Path computation in GMPLS-controlled networks as discussed in section 2.

Appropriately really needs to be qualified as the the numbered elements below.

remove Indeed

3.1 (4)  if we are referring to the network  technology in it's entirety is not G.709 OTUk not G.709 ODUk since the later is the wrapper for other client signals?
Martin Stiemerling Former IESG member
No Objection
No Objection (for -08) Unknown

                            
Richard Barnes Former IESG member
No Objection
No Objection (for -08) Unknown

                            
Sean Turner Former IESG member
No Objection
No Objection (for -08) Unknown

                            
Spencer Dawkins Former IESG member
No Objection
No Objection (for -08) Unknown

                            
Stephen Farrell Former IESG member
No Objection
No Objection (2013-06-25 for -08) Unknown
The secdir review [1] ended up with the authors and
AD suggesting this addition to the security 
considerations, which I think would be good:

PCEP extensions to support GMPLS should be considered
under the same security as current PCE work and this
extension will not change the underlying security issues.
Sec. 10 of [RFC5440] describes the list of security
considerations in PCEP. At the time [RFC5440] was
published, TCP Authentication Option (TCP-AO) had not
been fully specified for securing the TCP connections
that underlie PCEP sessions. TCP-AO [RFC5925] has now
been published and PCEP implementations should fully
support TCP-AO according to [RFC6952].

   [1] http://www.ietf.org/mail-archive/web/secdir/current/msg04026.html
Stewart Bryant Former IESG member
No Objection
No Objection (for -08) Unknown