MPLS Traffic Engineering Soft Preemption
RFC 5712
Yes
No Objection
Note: This ballot was opened for revision 18 and is now closed.
Lars Eggert No Objection
(Adrian Farrel; former steering group member) Yes
(Cullen Jennings; former steering group member) No Objection
(Dan Romascanu; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
(Lisa Dusseault; former steering group member) No Objection
(Magnus Westerlund; former steering group member) No Objection
Regarding the "Soft preemption timer", the interoperability section has some recommendations on its value. However, I would guess that for small values larger than 0 there would still be useless. Any desire to have a minimal usable value? And what unit is this timer in? The text talks all about seconds, but wouldn't values of the magnitude of some RTTs potentially useful, thus milliseconds may be appropriate here.
(Ralph Droms; former steering group member) No Objection
Missing right paren somewhere in this sentence from the first para of section 1? Without an alternative, network operators either accept this limitation, or remove functionality by using only one preemption priority or using invalid bandwidth reservation values. Understandably desirable features like ingress (Label Edge Router) LER automated (Traffic Engineering (TE) reservation adjustments are less palatable when preemption is intrusive and high network stability levels are a concern.
(Robert Sparks; former steering group member) No Objection
(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
Section 1: s/ingress (Label Edge Router) LER/ingress Label Edge Router (LER)/ s/(Traffic Engineering (TE)/Traffic Engineering (TE)/