OSPF Protocol Extensions for Path Computation Element (PCE) Discovery
draft-ietf-pce-disco-proto-ospf-08

[Ballot discuss]
(This is related to Ron's and Lars's Discusses.)

I am concerned that the use of a routing protocol
to not merely do application layer service discovery
but also dynamic load tracking is not the right
long-term direction for our protocol set. From the
document I also see that cross-AS discovery may in
future be necessary, which concerns me even more than
doing so within an area.

[Ballot comment]
From the Gen-ART review by Robert Sparks...

  The introduction claims that this draft does not define any new 
  OSPF elements of procedure, but section 5 is titled "Elements of 
  Procedure" and does appear to contain some significant behavioral 
  requirements. Should the introduction be modified?

[Ballot discuss]
RFC 4674 establishes mandatory security requirements for PCE discovery in section 4.6.

  Hence, mechanisms MUST be defined to ensure authenticity, integrity,
  confidentiality, and containment of PCE discovery information:

  - There MUST be a mechanism to authenticate discovery information.
  - There MUST be a mechanism to verify discovery information
    integrity.
  - There MUST be a mechanism to encrypt discovery information.
  - There MUST be a mechanism to restrict the scope of discovery to a
    set of authorized PCCs and to filter PCE information disclosed at
    domain boundaries (as per defined in Section 4.5).

My reading of this specification, supplemented by a limited understanding of
OSPF, is that RFC 2154 specifies mechanisms for OSPF satisfying the first two
requirements and the "flooding scope" addresses requirement four.  However,
there does not appear to be any mechanism for encrypting the discovery
information in OSPF, and RFC 2154 is not mandatory to implement.

Did the WG determine that the requirements specified in 4674 do not apply
in the OSPF architecture?

[Ballot discuss]
RFC 4674 establishes mandatory security requirements for PCE discovery in section 4.6.

  Hence, mechanisms MUST be defined to ensure authenticity, integrity,
  confidentiality, and containment of PCE discovery information:

  - There MUST be a mechanism to authenticate discovery information.
  - There MUST be a mechanism to verify discovery information
    integrity.
  - There MUST be a mechanism to encrypt discovery information.
  - There MUST be a mechanism to restrict the scope of discovery to a
    set of authorized PCCs and to filter PCE information disclosed at
    domain boundaries (as per defined in Section 4.5).

My reading of this specification, supplemented by a limited understanding of
OSPF, is that RFC 2154 specifies mechanisms for OSPF satisfying the first two
requirements and the "flooding scope" addresses requirement four.  However,
there does not appear to be any mechanism for encrypting the discovery
information and  RFC 2154 is not mandatory to implement.

Did the WG determine that the requirements specified in 4674 do not apply
in the OSPF architecture?

[Ballot discuss]
Is there any precedent for using OSPF to flood information regarding which applications the router supports (other than OSPF itself)? If not, is this a direction in which we want to go? The answer may be "yes", but I don't think that we have discussed it sufficiently.

[Ballot discuss]
Hi.
This discuss raises a blocking question.
It is possible, even likely that this may be resolved with no changes to the document.

During the discussion of PCE requirements, we discussed the need for
automated key management per RFC 4107 and the role that discovery
might play in that.  I see that the discovery solution adopted has no
way to discover security properties for PCE.  That may be OK.  How do
you plan to do automated key management for PCE and how will the
necessary security information be discovered?

[Ballot comment]
The use of the term "congestion" in this document is unfortunate,
  because congestion has a well-defined meaning already, and it isn't
  about not having CPU cycles. I'd much prefer a different term
  (overload?), but it's probably too late for that.

[Ballot discuss]
I'm no PCE expert, so maybe some of this doesn't make sense, but I'm
  bothered by the lack of specifics around where congestion information
  comes from and what is to be done with it, both in Section 3.2.1 and
  Section 5.1. There are a lot of phrasings like "outside the scope of
  this document", "particular attention MUST be given" to some
  mechanisms not further described, some rate "MUST be chosen" in ways
  not further defined, etc. Is there any real experience with this
  congestion information and the mechanisms around it? Should this be
  considered Experimental?

[Ballot discuss]
This draft hasn't been presented to the OSPF WG nor were they involved  in the PCE WG last call (whoops, they were notified Feb 14th and never queried again). I believe Adrian sent OSPF/ISIS WGs an initial version  a long time ago but that is the extent of the IGPs involvement. However, it  seems the volume and dynamics of what is advertised has grown since  then. It was agreed w/ the PCE chairs and the IGP (OSPF/ISIS) chairs that since there were so many comments the first time around, the IGPs would have further opportunities for review.

In general, I would advise  to use a separate OSPFv2 opaque LSA  opaque type and OSPFv3 LSA type rather than cramming more and more  information into the capabilities LSA. The PCE application appears to  advertise enough dynamic information to warrant this. It would allow (de)prioritizing the PCE information and prioritizing routing information.

Other nits:

0) the authors misuse "composed" and "comprised." It is a common error but, a pet peeve.
1)  4.1.3 : Using "left" and "right" is confusing. I assume what they mean here is that the first two octets (preferred terminology over "bytes") are 0, and the last two octets are the 16 bit AS #???
2) they frequently switch between octet and byte. easier if consistent
3) Congestion spamming: Call me paranoid :-), but the fact that they advertise this value in seconds suggests that we would either:

a)Have to flood frequently to keep the time accurate
b)Require OSPF implementations to age this time value (much as they do LSP lifetime) so that when it is propagated to a new neighbor it is accurate.

Needless to say, I dislike both choices. Does this really need to be in seconds? Could it be in minutes? Or should we do away with the duration entirely and simply send the congestion state and require that the state changes be filtered to a "reasonable" update rate? (I prefer the last idea.)


4) Section 5 PCE addresses:  It does seem required that the PCE addresses are "reachable"- but it does NOT seem required that reachability to the PCE MUST be advertised by the IGP (specified as OSPF). Certainly that would be more common/preferable, but is it really a "must".

5) Section 5:
  " The PCED sub-TLV is OPTIONAL. When an OSPF LSA does not contain any PCED TLV, this means that the PCE information of that node is unknown."

I do not know what the above paragraph is trying to say. Since the PCE may or may not be the advertising router, "node" is ambiguous. Perhaps this paragraph can be omitted?

6) Section 5.1 "An OSPF implementation SHOULD support an appropriate dampening algorithm..." The above should be the responsibility of the application providing PCE info to OSPF - not the responsibility of the OSPF implementation.

7) I find this sentence somewhat strange:
"  In this document, we call TLV any TLV that is carried within an OSPF
  LSA. Any TLV that is itself carried within another TLV is referred to
  as either a TLV or a sub-TLV."

Why isn't a sub-TLV always a sub-TLV? Note there doesn't seem to be any discussion of what to do if, contrary to the MUNST NOT, a sub-TLV appears more than once.

8) There doesn't seem to be any discussion of what to do if, contrary to
the MUST NOT, a sub-TLV appears more than once.

9) When a PCE is deactivated, the OSPF router advertising this PCE MUST
  originate a new Router Information LSA that does no longer include

English could do with tidying up (...LSA that no longer includes...)


10) section 5.1 para 2

typo CONGESITON -> CONGESTION



11)  I'm kind of interested to know HOW you might predict how long congestion is going to last with any accuracy. Or is the idea that you just keep resetting if it hasn't gone away,  and don't really care about the incremental over estimate. Apart from wondering how a PCE might actually compute this number, it requires ageing before flooding in order for the number in
the LSA/LSP to have any validity over time.

Think of what happens if we get a congestion time of 500 seconds - and 100 seconds after generating/receiving the LSA with that info we bring up a new adjacency and want to flood that info to the neighbor.

12) section 9.5

The OSPF extensions defined in this documents do not imply any requirement on other protocols.

typo documents -> document

[Ballot discuss]
This draft hasn't been presented to the OSPF WG nor were they involved  in the PCE WG last call (whoops, they were notified Feb 14th and never queried again). I believe Adrian sent OSPF/ISIS WGs an initial version  a long time ago but that is the extent of the IGPs involvement. However, it  seems the volume and dynamics of what is advertised has grown since  then. It was agreed w/ the PCE chairs and the IGP (OSPF/ISIS) chairs that since there were so many comments the first time around, the IGPs would have further opportunities for review.

In general, I would advise  to use a separate OSPFv2 opaque LSA  opaque type and OSPFv3 LSA type rather than cramming more and more  information into the capabilities LSA. The PCE application appears to  advertise enough dynamic information to warrant this. It would allow (de)prioritizing the PCE information and prioritizing routing information.

Other nits:

0) the authors misuse "composed" and "comprised." It is a common error but, a pet peeve.
1)  4.1.3 : Using "left" and "right" is confusing. I assume what they mean here is that the first two octets (preferred terminology over "bytes") are 0, and the last two octets are the 16 bit AS #???
2) they frequently switch between octet and byte. easier if consistent
3) Congestion spamming: Call me paranoid :-), but the fact that they advertise this value in seconds suggests that we would either:

a)Have to flood frequently to keep the time accurate
b)Require OSPF implementations to age this time value (much as they do LSP lifetime) so that when it is propagated to a new neighbor it is accurate.

Needless to say, I dislike both choices. Does this really need to be in seconds? Could it be in minutes? Or should we do away with the duration entirely and simply send the congestion state and require that the state changes be filtered to a "reasonable" update rate? (I prefer the last idea.)


4) Section 5 PCE addresses:  It does seem required that the PCE addresses are "reachable"- but it does NOT seem required that reachability to the PCE MUST be advertised by the IGP (specified as OSPF). Certainly that would be more common/preferable, but is it really a "must".

5) Section 5:
  " The PCED sub-TLV is OPTIONAL. When an OSPF LSA does not contain any PCED TLV, this means that the PCE information of that node is unknown."

I do not know what the above paragraph is trying to say. Since the PCE may or may not be the advertising router, "node" is ambiguous. Perhaps this paragraph can be omitted?

6) Section 5.1 "An OSPF implementation SHOULD support an appropriate dampening algorithm..." The above should be the responsibility of the application providing PCE info to OSPF - not the responsibility of the OSPF implementation.

7) I find this sentence somewhat strange:
"  In this document, we call TLV any TLV that is carried within an OSPF
  LSA. Any TLV that is itself carried within another TLV is referred to
  as either a TLV or a sub-TLV."

Why isn't a sub-TLV always a sub-TLV? Note there doesn't seem to be any discussion of what to do if, contrary to the MUNST NOT, a sub-TLV appears more than once.

8) There doesn't seem to be any discussion of what to do if, contrary to
the MUST NOT, a sub-TLV appears more than once.

9) When a PCE is deactivated, the OSPF router advertising this PCE MUST
  originate a new Router Information LSA that does no longer include

English could do with tidying up (...LSA that no longer includes...)


10) section 5.1 para 2

typo CONGESITON -> CONGESTION



11)  I'm kind of interested to know HOW you might predict how long congestion is going to last with any accuracy. Or is the idea that you just keep resetting if it hasn't gone away,  and don't really care about the incremental over estimate

12) section 9.5

The OSPF extensions defined in this documents do not imply any requirement on other protocols.

typo documents -> document

[Ballot comment]
I would like to salute the authors of the document and the PCE WG for the Manageability Considerations section. This section could be used as a reference for the type of information that should be included in a protocol document.

[Ballot comment]
This draft hasn't been presented to the OSPF WG nor were they involved  in the PCE WG last call (whoops, they were notified Feb 14th and never queried again). I believe Adrian sent OSPF/ISIS WGs an initial version  a long time ago but that is the extent of the IGPs involvement. However, it  seems the volume and dynamics of what is advertised has grown since  then. It was agreed w/ the PCE chairs and the IGP (OSPF/ISIS) chairs that since there were so many comments the first time around, the IGPs would have further opportunities for review.

In general, I would advise  to use a separate OSPFv2 opaque LSA  opaque type and OSPFv3 LSA type rather than cramming more and more  information into the capabilities LSA. The PCE application appears to  advertise enough dynamic information to warrant this.

Other nits:

0) the authors misuse "composed" and "comprised." It is a common error but, a pet peeve.
1)  4.1.3 : Using "left" and "right" is confusing. I assume what they mean here is that the first two octets (preferred terminology over "bytes") are 0, and the last two octets are the 16 bit AS #???
2) they frequently switch between octet and byte. easier if consistent
3) Congestion spamming: Call me paranoid :-), but the fact that they advertise this value in seconds suggests that we would either:

a)Have to flood frequently to keep the time accurate
b)Require OSPF implementations to age this time value (much as they do LSP lifetime) so that when it is propagated to a new neighbor it is accurate.

Needless to say, I dislike both choices. Does this really need to be in seconds? Could it be in minutes? Or should we do away with the duration entirely and simply send the congestion state and require that the state changes be filtered to a "reasonable" update rate? (I prefer the last idea.)


4) Section 5 PCE addresses:  It does seem required that the PCE addresses are "reachable"- but it does NOT seem required that reachability to the PCE MUST be advertised by the IGP (specified as OSPF). Certainly that would be more common/preferable, but is it really a "must".

5) Section 5:
  " The PCED sub-TLV is OPTIONAL. When an OSPF LSA does not contain any PCED TLV, this means that the PCE information of that node is unknown."

I do not know what the above paragraph is trying to say. Since the PCE may or may not be the advertising router, "node" is ambiguous. Perhaps this paragraph can be omitted?

6) Section 5.1 "An OSPF implementation SHOULD support an appropriate dampening algorithm..." The above should be the responsibility of the application providing PCE info to OSPF - not the responsibility of the OSPF implementation.

[Ballot comment]
This draft hasn't been presented to the OSPF WG nor were they involved  in the PCE WG last call. I believe Adrian sent OSPF/ISIS WGs an initial version  a long time ago but that is the extent of the IGPs involvement. However, it  seems the volume and dynamics of what is advertised has grown since  then. It was agreed w/ the PCE chairs and the IGP (OSPF/ISIS) chairs that since there were so many comments the first time around, the IGPs would have further opportunities for review.

In general, I would advise  to use a separate OSPFv2 opaque LSA  opaque type and OSPFv3 LSA type rather than cramming more and more  information into the capabilities LSA. The PCE application appears to  advertise enough dynamic information to warrant this.

Other nits:

0) the authors misuse "composed" and "comprised." It is a common error but, a pet peeve.
1)  4.1.3 : Using "left" and "right" is confusing. I assume what they mean here is that the first two octets (preferred terminology over "bytes") are 0, and the last two octets are the 16 bit AS #???
2) they frequently switch between octet and byte. easier if consistent
3) Congestion spamming: Call me paranoid :-), but the fact that they advertise this value in seconds suggests that we would either:

a)Have to flood frequently to keep the time accurate
b)Require OSPF implementations to age this time value (much as they do LSP lifetime) so that when it is propagated to a new neighbor it is accurate.

Needless to say, I dislike both choices. Does this really need to be in seconds? Could it be in minutes? Or should we do away with the duration entirely and simply send the congestion state and require that the state changes be filtered to a "reasonable" update rate? (I prefer the last idea.)


4) Section 5 PCE addresses:  It does seem required that the PCE addresses are "reachable"- but it does NOT seem required that reachability to the PCE MUST be advertised by the IGP (specified as OSPF). Certainly that would be more common/preferable, but is it really a "must".

5) Section 5:
  " The PCED sub-TLV is OPTIONAL. When an OSPF LSA does not contain any PCED TLV, this means that the PCE information of that node is unknown."

I do not know what the above paragraph is trying to say. Since the PCE may or may not be the advertising router, "node" is ambiguous. Perhaps this paragraph can be omitted?

6) Section 5.1 "An OSPF implementation SHOULD support an appropriate dampening algorithm..." The above should be the responsibility of the application providing PCE info to OSPF - not the responsibility of the OSPF implementation.

IANA Last Call Comments:

Action #1
Upon approval of this document, the IANA will
make the following assignments in the "OSPFv3
Parameters" registry located at

http://www.iana.org/assignments/ospfv3-parameters

sub-registry "OSPFv3 Router Information (RI) LSA"

5 PCED [RFC-pce-disco-proto-ospf-05]


Action #2:
Upon approval of this document, the IANA will create
following sub-registry in the "OSPFv3 Parameters"
registry located at

http://www.iana.org/assignments/ospfv3-parameters

sub-registry "PCED Sub-TLV Registry"

Allocation policy is: IETF Consensus action.

Initial contents of the registry:

Sub-TLV Sub-TLV
Type Name References
----- -------- ----------
0 Reserved
1 PCE-ADDRESS [RFC-pce-disco-proto-ospf-05]
2 PATH-SCOPE [RFC-pce-disco-proto-ospf-05]
3 PCE-DOMAIN [RFC-pce-disco-proto-ospf-05]
4 NEIG-PCE-DOMAIN [RFC-pce-disco-proto-ospf-05]
5 PCE-CAP-FLAGS [RFC-pce-disco-proto-ospf-05]
6 CONGESTION [RFC-pce-disco-proto-ospf-05]
7-65536 Available for assignment [RFC-pce-disco-proto-ospf-05]



Action 3:
Upon approval of this document, the IANA will
create following sub-registry in the "OSPFv3
Parameters" registry located at

http://www.iana.org/assignments/ospfv3-parameters

sub-registry "PCE Capability Flags Registry"

Allocation policy: IETF consensus

Initial Contents:

Bit Capability Description

0 Path computation with GMPLS link constraints
[RFC-pce-disco-proto-ospf-05]
1 Bidirectional path computation [RFC-pce-disco-proto-ospf-05]
2 Diverse path computation [RFC-pce-disco-proto-ospf-05]
3 Load-balanced path computation [RFC-pce-disco-proto-ospf-05]
4 Synchronized paths computation [RFC-pce-disco-proto-ospf-05]
5 Support for multiple objective functions
[RFC-pce-disco-proto-ospf-05]
6 Support for additive path constraints
(max hop count, etc.) [RFC-pce-disco-proto-ospf-05]
7 Support for request prioritization
[RFC-pce-disco-proto-ospf-05]
8 Support for multiple requests per message
[RFC-pce-disco-proto-ospf-05]
9-31 Available for assignment




We understand this to be the only IANA Actions
for this document.

PROTO Write-up

>(1.a) Who is the Document Shepherd for this document?

Adrian Farrel

> Has the Document Shepherd personally reviewed this version
> of the document and, in particular, does he or she believe
> this version is ready for forwarding to the IESG for
> publication?

Yes

>(1.b) Has the document had adequate review both from key WG
> members and from key non-WG members?

Yes. Cross-review to OSPF WG held.

> Does the Document Shepherd have any concerns about the
> depth or breadth of the reviews that have been performed?

No concerns.

>(1.c) Does the Document Shepherd have concerns that the document
> needs more review from a particular or broader perspective,
> e.g., security, operational complexity, someone familiar
> with AAA, internationalization or XML?

No concerns.

>(1.d) Does the Document Shepherd have any specific concerns or
> issues with this document that the Responsible Area
> Director and/or the IESG should be aware of? For example,
> perhaps he or she is uncomfortable with certain parts of
> the document, or has concerns whether there really is a
> need for it. In any event, if the WG has discussed those
> issues and has indicated that it still wishes to advance
> the document, detail those concerns here.

No concerns.

> Has an IPR disclosure related to this document
> been filed? If so, please include a reference to the
> disclosure and summarize the WG discussion and conclusion
> on this issue.

None has been filed.

>(1.e) How solid is the WG consensus behind this document? Does
> it represent the strong concurrence of a few individuals,
> with others being silent, or does the WG as a whole
> understand and agree with it?

WG agrees.

>(1.f) Has anyone threatened an appeal or otherwise indicated
> extreme discontent? If so, please summarise the areas of
> conflict in separate email messages to the Responsible Area
> Director. (It should be in a separate email because this
> questionnaire is entered into the ID Tracker.)

No.

>(1.g) Has the Document Shepherd personally verified that the
> document satisfies all ID nits? (See
> http://www.ietf.org/ID-Checklist.html and
> http://tools.ietf.org/tools/idnits/). Boilerplate checks
> are not enough; this check needs to be thorough.

Yes.

> Has the document met all formal review criteria it needs
> to, such as the MIB Doctor, media type and URI type
> reviews?

Yes.

>(1.h) Has the document split its references into normative and
> informative?

Yes.

> Are there normative references to documents that
> are not ready for advancement or are otherwise in an
> unclear state? If such normative references exist, what is
> the strategy for their completion?

There is a normative reference to draft-ietf-ospf-cap that is
in the RFC Editor Queue.

> Are there normative references that are downward
> references, as described in [RFC3967]? If so, list these
> downward references to support the Area Director in the
> Last Call procedure for them [RFC3967].

No.

>(1.i) Has the Document Shepherd verified that the document IANA
> consideration section exists and is consistent with the
> body of the document? If the document specifies protocol
> extensions, are reservations requested in appropriate IANA
> registries? Are the IANA registries clearly identified?
> If the document creates a new registry, does it define the
> proposed initial contents of the registry and an allocation
> procedure for future registrations? Does it suggest a
> reasonable name for the new registry? See [RFC2434].

IANA section is correct.

IANA allocation is dependent on the registries created for
draft-ietf-ospf-cap that is in the RFC Editor Queue.
Identification of the registries is, therefore, necessarily
slightly ambiguous.

> If the document describes an Expert Review process has
> Shepherd conferred with the Responsible Area Director so
> that the IESG can appoint the needed Expert during the IESG
> Evaluation?

None required.

>(1.j) Has the Document Shepherd verified that sections of the
> document that are written in a formal language, such as XML
> code, BNF rules, MIB definitions, etc., validate correctly
> in an automated checker?

Not applicable.

>(1.k) The IESG approval announcement includes a Document
> Announcement Write-Up. Please provide such a Document
> Announcement Write-Up? Recent examples can be found in the
> "Action" announcements for approved documents. The
> approval announcement contains the following sections:

> 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 (PCE),
along with some information that can be used 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 discover PCEs
consists of using IGP flooding. For that purpose, this document
defines extensions to the Open Shortest Path First (OSPF) routing
protocol for the advertisement of PCE Discovery information within an
OSPF area or within the entire OSPF routing domain.

> Working Group Summary

The Working Group had consensus on this document.

> Document Quality

The protocol extensions have been implemented multiple times.

> Personnel
>
> Who is the Document Shepherd for this document?

Adrian Farrel

> Who is the Responsible Area Director(s)?

Ross Callon, David Ward.

> Is an IANA expert needed?

No.