A Path Computation Element (PCE)-Based Architecture
RFC 4655
Yes
No Objection
Note: This ballot was opened for revision 05 and is now closed.
Lars Eggert No Objection
(Alex Zinin; former steering group member) Yes
(Ross Callon; former steering group member) Yes
(Allison Mankin; former steering group member) No Objection
(Bill Fenner; former steering group member) No Objection
(Brian Carpenter; former steering group member) No Objection
I'm slightly surprised that this has only one rather casual mention of the word "loop". I'd have expected some discussion of loop avoidance. Similarly, the assumption that QoS enters into path computation seems very casual given the history of QoS-based routing.
(Cullen Jennings; former steering group member) No Objection
(Dan Romascanu; former steering group member) (was No Record, Discuss) No Objection
I cleared my DISCUSS as most of the issues I raised were addressed. There is one editorial issue left that is not worth more than a COMMENT, yet I would be glad to see it fixed or hear an explanation. Section 9 lists Manageability Considerations in sub-sections 9.1 to 9.6, and then includes the follwoing: 9.7. Other Considerations No other management considerations have been identified. Why this?
(David Kessens; former steering group member) No Objection
I received the following comments by Pekka Savola from the OPS directorate that
you might want to consider:
(Note: we don't run MPLS or GMPLS TE networks so review from someone
who does woudln't hurt..)
I read the draft and thought it was reasonably clear and easy to read.
There seemed to be a couple of internal inconsistancies (section x
said "foo", section y said "foo and bar") but nothing major. I think
the doc could easily be wrapped up in a month with one revision.
semi-substantial
----------------
4.4. Node Outside the Routing Domain
An LER might not be part of the routing domain for administrative
reasons (for example, a customer-edge (CE) router connected to the
provider-edge (PE) router in the context of MPLS VPN [RFC2547] and
for which it is desired to provide a CE to CE TE LSP path).
This scenario suggests a solution that does not involve doing
computation on the ingress (TE LSP head-end) router, and that does
not rely on static loose hops configuration in which case optimal
shortest paths could not be achieved. A distinct PCE-based solution
can help here. Note that the PCE in this case may, itself, provide a
path that includes loose hops.
==> I'm not sure how relevant this scenario really is. If you don't
rely on external equipment (e.g., CE's, maybe under the customer
control or not) to participate in the routing domain for
administrative reasons, why could you rely on them doing TE decisions?
(which could hurt ISP's own TE decisions..) In any case, such nodes
basically just have a default route to the ISP, so I'm not sure why
they need to participate in TE at all..
Conversely, stateless PCEs do not have to remember any computed path
and each set of request(s) is processed independently of each other.
For example, stateless PCEs may compute paths based on current TED
information, which could be out of sync with actual network state
given other recent PCE-computed paths changes.
==> do you assume that if a PCE computes a path, it will actually
automatically get used? The last sentence seems to imply that. (But
text further in the draft doesn't seem to assume that.) The router
could just also very well discard it. The path computations made to
PCC's seem irrelevant, as the PCEs should use solely TED to get info
about path changes. (This might imply that you might need to wait
until TED has been updated between each PCE computation to know if it
was activated or not...)
editorial
---------
4.8 Path Selection Policy
===> it might have been useful to briefly also mention the policy
synchronization here, because if you have multiple PCE's, that's pretty
important; whether that needs to be done out-of-band or using e.g., PCE-PCE
protocols remains to be seen.
5.3. Multiple PCE Path Computation
Figure 3 illustrates how multiple PCE path computations may be
performed along the path of a signaled service. As in the previous
example, the head-end PCC makes a request to an external PCE, but the
path that is returned is such that the next network element finds it
necessary to perform further computation. This may be the case when
the path returned is a partial path that does not reach the intended
destination or when the computed path is loose. [...]
==> in section 5 or 6, you don't describe the scenario at all where PCC
sends in a request to a PCE, which fails to provide a reply or replies in
such a manner (e.g., the first hop is loose) that the PCC needs to contact
another PCE for better path information. On the other hand, the second
bullet in Section 7 seems to imply this is also possible. Is this an
intentional omission or should that scenario also be mentioned here?
(AFAICS, your the two cases addressed here are: 1) contact PCE, get enough
information to forward packets to the next hop, let that contact the same or
some other PCE, and 2) contact PCE, and assume inter-PCE communication to
sort it out.)
6.6. PCC-PCE & PCE-PCE Communication
==> you don't include any requirements on how the communication needs to be
1) secured (well, later in section 6.10 you have some but PCE-PCE or PCC-PCE
IMHO belong here; note that you'll probably want more than just
confidentiality, e.g., integrity), or
2) what kind of requirements there are for communication (e.g., how fast
should you notice if the communication doesn't form? or dies in the middle?)
[I note that some of this is under 6.5]
9.7. Other Considerations
No other management considerations arise.
==> hmm.. shouldn't you rather say, "No other management considerations have
been identified." ? :-)
(Jari Arkko; former steering group member) No Objection
Typo in Section 5.6: s/extening/extending/
(Lisa Dusseault; former steering group member) No Objection
(Magnus Westerlund; former steering group member) No Objection
Please spell out all usage of acronyms in their first usage. Some example of this is ASON, NMS and IGP.
(Margaret Cullen; former steering group member) No Objection
(Mark Townsley; former steering group member) No Objection
(Russ Housley; former steering group member) (was Discuss) No Objection