PathErr Message Triggered MPLS and GMPLS LSP Reroutes
RFC 5710
Yes
No Objection
Note: This ballot was opened for revision 06 and is now closed.
Lars Eggert No Objection
(Adrian Farrel; former steering group member) Yes
(Alexey Melnikov; former steering group member) No Objection
(Cullen Jennings; former steering group member) No Objection
(Dan Romascanu; former steering group member) No Objection
(Jari Arkko; former steering group member) (was Discuss) No Objection
> the ERO received in the LSP's incoming Path message does not preclude Term ERO not yet defined > A transit node MAY act on a reroute request locally when the ERO > received in the LSP's incoming Path message does not precluded the > reroute. ... does not preclude ?
(Lisa Dusseault; former steering group member) No Objection
(Magnus Westerlund; former steering group member) No Objection
(Ralph Droms; former steering group member) No Objection
(Robert Sparks; former steering group member) (was Discuss) No Objection
I'm a little concerned by this language in the Security Considerations section: This document does introduce a new error code value, but this value is functionally equivalent to existing semantics. If the semantics are the same, why have a new error code at all? Is the sentence really trying to say the semantics are similar enough to other things that the security impacts are already well understood?
(Ron Bonica; former steering group member) No Objection
(Ross Callon; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection
(Tim Polk; former steering group member) No Objection