Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths
Note: This ballot was opened for revision 11 and is now closed.
(Adrian Farrel) Yes
(Jari Arkko) No Objection
(Ron Bonica) No Objection
(Stewart Bryant) (was Discuss) No Objection
The following text ==== Four values are possible for the leaf type field: 1. New leaves to add; 2. Old leaves to remove; 3. Old leaves whose path can be modified/reoptimized; 4. Old leaves whose path must be left unchanged. ==== Is almost identical to the text two lines above, and the list entry numbers are I think the values, but this is not a clear way to show it. If the authors think there will ever be more than 4 operations, they should consider using a registry.
(Gonzalo Camarillo) No Objection
(Lars Eggert) No Objection
(David Harrington) (was Discuss) No Objection
(Russ Housley) No Objection
(Tim Polk) (was No Record, Discuss) No Objection
(Dan Romascanu) (was Discuss) No Objection
> 4.6. Impact on Network Operation > It is expected that use of PCEP extensions specified in this document > does not have significant impact on network operations. While the addition of PCEP-P2MP extensions may have minimal impact on the level of traffic and operations, the applications that are enabled by activating these extensions may result in increased traffic and operational complexity.
(Peter Saint-Andre) No Objection
(Robert Sparks) No Objection
(Sean Turner) (was Discuss, No Objection) No Objection
I support Tim's DISCUSS position too. Some new comments based on Russ Mundy's SECDIR review: 1) RFC4875 Security Considerations requires that the ingress LSR of a P2MP TE LSP the leaves for the P2MP LSP for use in multi-vendor deployments. Although it's not clear that this document needs to provide this requirement, I wanted to flag the requirement in case that it had been overlooked.