Skip to main content

Extensions to RSVP-TE for Label Switched Path (LSP) Egress Protection
draft-ietf-teas-rsvp-egress-protection-16

Yes

(Deborah Brungard)

No Objection

Warren Kumari
(Adam Roach)
(Alexey Melnikov)
(Alia Atlas)
(Alissa Cooper)
(Alvaro Retana)
(Ben Campbell)
(Benoît Claise)
(Mirja Kühlewind)
(Spencer Dawkins)
(Suresh Krishnan)
(Terry Manderson)

Note: This ballot was opened for revision 12 and is now closed.

Warren Kumari
No Objection
Deborah Brungard Former IESG member
Yes
Yes (for -12) Unknown

                            
Adam Roach Former IESG member
No Objection
No Objection (for -15) Unknown

                            
Alexey Melnikov Former IESG member
No Objection
No Objection (for -15) Unknown

                            
Alia Atlas Former IESG member
No Objection
No Objection (for -15) Unknown

                            
Alissa Cooper Former IESG member
No Objection
No Objection (for -15) Unknown

                            
Alvaro Retana Former IESG member
No Objection
No Objection (for -14) Unknown

                            
Ben Campbell Former IESG member
No Objection
No Objection (for -15) Unknown

                            
Benoît Claise Former IESG member
No Objection
No Objection (for -15) Unknown

                            
Eric Rescorla Former IESG member
No Objection
No Objection (2018-03-07 for -15) Unknown
https://mozphab-ietf.devsvcdev.mozaws.net/D4328

I found this document a little hard to follow because it took me a while to understand the difference between the current situation and the change in the draft. Would you consider putting part of the material from S 6 in the introduction so non-experts could have more context?


   locally protecting the egress node(s) of an LSP.

   This document fills that void and specifies extensions to RSVP-TE for
For those of us who are not experts, can you say what "protecting" means?



   egresses L1 and L2 of a primary P2MP LSP from ingress R1 to two
   egresses L1 and L2.  La and Lb are the designated backup egresses for
   primary egresses L1 and L2 respectively.  The backup LSP for
This might be the tiniest bit confusing, as it mentions L1 and L2 twice.



   The exact mechanism by which the failure of the primary egress is
   detected by the upstream node is out of the scope of this document.
It would be helpful for me if you specified what the upstream node is. Is it R3?



   node does not provide any fast local protection against the failure
   of the primary egress node.  In this case, the backup LSP from the
   branch node to the backup egress node protects against failures on
This sentence would be clearer if it said
"If the direct upstream node does not provide any fast local protection ....."



   the subobject in bytes, including Type, Length and Contents fields.
   The Reserved field MUST be set to zero.
What are the semantics of the optional subobjects?



   To protect the VPN traffic against the failure of the egress L1 of
   the LSP, an existing solution (refer to Figure 2) includes:
I wasn't reading this closely, so it took me a minute to be like "hold on, this is reroute from R1, nor R3". Probably just me being stupid, but it might have helped to have a subsection like "Existing solution before this draft"



       The PLR R3 is closer to L1 than the ingress R1.  It may detect
       the failure of the egress L1 faster and more reliable.  Thus we
       can have faster protection for egress.
Nit: "more more reliably"
Kathleen Moriarty Former IESG member
No Objection
No Objection (2018-03-03 for -14) Unknown
Thank you for addressing the SecDir comments.
Mirja Kühlewind Former IESG member
No Objection
No Objection (for -13) Unknown

                            
Spencer Dawkins Former IESG member
No Objection
No Objection (for -15) Unknown

                            
Suresh Krishnan Former IESG member
No Objection
No Objection (for -15) Unknown

                            
Terry Manderson Former IESG member
No Objection
No Objection (for -14) Unknown