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