Skip to main content

A Path Computation Element (PCE)-Based Architecture
draft-ietf-pce-architecture-05

Revision differences

Document history

Date Rev. By Action
2012-08-22
05 (System) post-migration administrative database adjustment to the No Objection position for Dan Romascanu
2012-08-22
05 (System) post-migration administrative database adjustment to the No Objection position for Russ Housley
2006-07-24
05 Bill Fenner State Change Notice email list have been change to pce-chairs@tools.ietf.org from adrian@olddog.co.uk, jpv@cisco.com
2006-05-02
05 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2006-05-01
05 Amy Vezza IESG state changed to Approved-announcement sent
2006-05-01
05 Amy Vezza IESG has approved the document
2006-05-01
05 Amy Vezza Closed "Approve" ballot
2006-04-28
05 Ross Callon State Changes to Approved-announcement to be sent from Approved-announcement to be sent::Point Raised - writeup needed by Ross Callon
2006-04-28
05 Amy Vezza State Changes to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation::AD Followup by Amy Vezza
2006-04-28
05 (System) Removed from agenda for telechat - 2006-04-27
2006-04-24
05 Dan Romascanu
[Ballot comment]
I cleared my DISCUSS as most of the issues I raised were addressed. There is one editorial issue left that is not worth …
[Ballot comment]
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?
2006-04-24
05 Dan Romascanu [Ballot Position Update] Position for Dan Romascanu has been changed to No Objection from Undefined by Dan Romascanu
2006-04-24
05 Dan Romascanu [Ballot Position Update] Position for Dan Romascanu has been changed to Undefined from Discuss by Dan Romascanu
2006-04-21
05 Russ Housley [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley
2006-04-20
05 Russ Housley
[Ballot discuss]
Section 6.10 says:
>
> This requirement is not a security issue, but relates to Service
>  Provider policy. Confidentiality, integrity, and authentication …
[Ballot discuss]
Section 6.10 says:
>
> This requirement is not a security issue, but relates to Service
>  Provider policy. Confidentiality, integrity, and authentication of
>  PCC-PCE and PCE-PCE messages must also be ensured and is described in
>  Section 10.
>
This is good.  I have no problem with the point that is being made about
confidentiality.  However, Section 10 does not provide the expected
discussion.

The closest text in Section 10 is:
>
> It is expected that PCE solutions will address these issues in detail
> using authentication and security techniques.
>
I would be much happier with a statement like that requires the
implementation of mechanisms that will ensure the integrity and
authentication of PCC-PCE and PCE-PCE messages.  An optional
mechanism can also be specified to ensure the confidentiality of
these messages.
2006-04-19
05 Ross Callon Placed on agenda for telechat - 2006-04-27 by Ross Callon
2006-04-19
05 Ross Callon [Ballot Position Update] New position, Yes, has been recorded for Ross Callon by Ross Callon
2006-04-14
05 (System) Sub state has been changed to AD Follow up from New Id Needed
2006-04-14
05 (System) New version available: draft-ietf-pce-architecture-05.txt
2006-04-12
05 Ross Callon State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation::AD Followup by Ross Callon
2006-04-12
05 Ross Callon The author (JP Vasseur) has indicated that a minor editorial update is needed.
2006-03-30
05 Amy Vezza State Changes to IESG Evaluation::AD Followup from IESG Evaluation - Defer by Amy Vezza
2006-03-30
05 Lisa Dusseault [Ballot Position Update] New position, No Objection, has been recorded for Lisa Dusseault by Lisa Dusseault
2006-03-30
05 Jari Arkko State Changes to IESG Evaluation - Defer from IESG Evaluation by Jari Arkko
2006-03-29
05 Bill Fenner Shepherding AD has been changed to Ross Callon from Alex Zinin
2006-03-29
05 Jari Arkko [Ballot comment]
Typo in Section 5.6: s/extening/extending/
2006-03-29
05 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko by Jari Arkko
2006-03-29
05 Dan Romascanu
[Ballot discuss]
Several observations concerning manageability aspects, that would deserve a more careful consideration:

- Section 5.5 includes the following text:
'The NMS uses a …
[Ballot discuss]
Several observations concerning manageability aspects, that would deserve a more careful consideration:

- Section 5.5 includes the following text:
'The NMS uses a management plane mechanism to send this request such as the TE MIB module [RFC3812].'
A MIB module is not a 'management plane mechanism' but a data model. A better text would be:
'The NMS uses a aonfiguration protocol as a management plane mechanism associated with a data model, such as the one defined in SMIv2 for the TE MIB module [RFC3812]

- last bullet in section 5.6 includes a list of items for which MIB modules (actually data models) are needed. I would add here PCE monitoring information, so that the last bullet would be:

OLD:
MIB modules related to communication protocols, routing and signaling extensions and metrics.

NEW:
MIB modules related to communication protocols, routing and signaling extensions and metrics, and PCE monitoring information

- Section 9.2 includes the following:

OLD:
The new MIB modules should also be used to provide notifications (formerly known as traps) when key thresholds are crossed or when important events occur. Great care must be exercised to ensure that the network is not flooded with SNMP notifications. Thus it might be inappropriate to issue a notification every time that a PCE receives a request to compute a path. In any case, full control must be provided through the MIB modules to allow notifications to be disabled.

Two problems here:
- saying that notifications are formally known as traps is a well-known buggy expression in the SNMP world. Actually notifications include both traps and informs
- if SNMP is being used, there is a standard interface (MIB module) to control notification targets and enabling, which should be mentioned

so, I suggest the following:

The new MIB modules should also be used to provide notifications when key thresholds are crossed or when important events occur. Great care must be exercised to ensure that the network is not flooded with SNMP notifications. Thus it might be inappropriate to issue a notification every time that a PCE receives a request to compute a path. In any case, full control must be provided to allow notifications to be disabled using for example the mechanisms defined in the SNMP-NOTIFICATION MIB in [RFC3413].

[RFC3413] should be added to the references.

- It is not clear to me what is the role of Section 9.7. Looks to me that it can be taken out.

- I believe that the security considerations section should mention the fact that a control plane protocol performing configuration operations must be appropriately secured in order to prevent un-desired or even malicious operations that may affect the network operational state, for example by diabling PCE function as described in Section 9.1
2006-03-29
05 Dan Romascanu [Ballot Position Update] Position for Dan Romascanu has been changed to Discuss from Undefined by Dan Romascanu
2006-03-29
05 Dan Romascanu [Ballot Position Update] New position, Undefined, has been recorded for Dan Romascanu by Dan Romascanu
2006-03-29
05 Lars Eggert [Ballot Position Update] New position, No Objection, has been recorded for Lars Eggert by Lars Eggert
2006-03-29
05 (System) State Changes to IESG Evaluation from IESG Evaluation - Defer by system
2006-03-28
05 Cullen Jennings [Ballot Position Update] New position, No Objection, has been recorded for Cullen Jennings by Cullen Jennings
2006-03-26
05 Magnus Westerlund [Ballot comment]
Please spell out all usage of acronyms in their first usage. Some example of this is ASON, NMS and IGP.
2006-03-26
05 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded for Magnus Westerlund by Magnus Westerlund
2006-03-16
05 Sam Hartman State Changes to IESG Evaluation - Defer from IESG Evaluation by Sam Hartman
2006-03-16
05 Mark Townsley [Ballot Position Update] New position, No Objection, has been recorded for Mark Townsley by Mark Townsley
2006-03-16
05 Margaret Cullen [Ballot Position Update] New position, No Objection, has been recorded for Margaret Wasserman by Margaret Wasserman
2006-03-16
05 Russ Housley
[Ballot discuss]
Section 6.10 covers confidentiality requirements.  Authentication
  and integrity are even more important.  Please expand this section
  to cover all three topics.  …
[Ballot discuss]
Section 6.10 covers confidentiality requirements.  Authentication
  and integrity are even more important.  Please expand this section
  to cover all three topics.  The Security Considerations section
  touches on some of these points, but the document structure leads
  the reader to the conclusion that confidentiality is more important
  than authentication and integrity, which is false in this protocol
  environment.

  COMMENT

  Section 1: Please spell out the first use of PCC, TED, and LSR.

  Section 9.7: Why is this here?  Please delete it.
2006-03-16
05 Russ Housley [Ballot Position Update] New position, Discuss, has been recorded for Russ Housley by Russ Housley
2006-03-16
05 Brian Carpenter [Ballot Position Update] Position for Brian Carpenter has been changed to No Objection from Undefined by Brian Carpenter
2006-03-16
05 Allison Mankin [Ballot Position Update] New position, No Objection, has been recorded for Allison Mankin by Allison Mankin
2006-03-16
05 Bill Fenner [Ballot Position Update] New position, No Objection, has been recorded for Bill Fenner by Bill Fenner
2006-03-16
05 David Kessens
[Ballot comment]
I received the following comments by Pekka Savola from the OPS directorate that
you might want to consider:

(Note: we don't run MPLS …
[Ballot comment]
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." ? :-)
2006-03-16
05 David Kessens [Ballot Position Update] New position, No Objection, has been recorded for David Kessens by David Kessens
2006-03-15
05 Brian Carpenter
[Ballot comment]
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. …
[Ballot comment]
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.
2006-03-15
05 Brian Carpenter
[Ballot comment]
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. …
[Ballot comment]
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.
2006-03-15
05 Brian Carpenter
[Ballot comment]
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. …
[Ballot comment]
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 the QoS enters into path computation seems very casual given
the history of QoS-based routing.
2006-03-15
05 Brian Carpenter [Ballot Position Update] New position, Undefined, has been recorded for Brian Carpenter by Brian Carpenter
2006-03-15
05 Michelle Cotton IANA Comments:
As described in the IANA Consideration section, we understand this document to have NO IANA Actions.
2006-03-13
05 Alex Zinin [Ballot Position Update] New position, Yes, has been recorded for Alex Zinin
2006-03-13
05 Alex Zinin Ballot has been issued by Alex Zinin
2006-03-13
05 Alex Zinin Created "Approve" ballot
2006-03-13
05 (System) Ballot writeup text was added
2006-03-13
05 (System) Last call text was added
2006-03-13
05 (System) Ballot approval text was added
2006-02-26
05 Alex Zinin Placed on agenda for telechat - 2006-03-16 by Alex Zinin
2006-02-26
05 Alex Zinin State Changes to IESG Evaluation from AD Evaluation by Alex Zinin
2006-01-19
05 Alex Zinin State Changes to AD Evaluation from Publication Requested by Alex Zinin
2006-01-19
05 Dinara Suleymanova Draft Added by Dinara Suleymanova in state Publication Requested
2006-01-17
04 (System) New version available: draft-ietf-pce-architecture-04.txt
2005-12-09
03 (System) New version available: draft-ietf-pce-architecture-03.txt
2005-09-21
02 (System) New version available: draft-ietf-pce-architecture-02.txt
2005-07-19
01 (System) New version available: draft-ietf-pce-architecture-01.txt
2005-03-21
00 (System) New version available: draft-ietf-pce-architecture-00.txt