Re: [Teas] Eric Rescorla's No Objection on draft-ietf-teas-rsvp-egress-protection-15: (with COMMENT)

[Huaimo Chen <[e-mail]>]

Hi Eric,

Thank you very much for your quick reply.
Answers are inline below with prefix [HC].

Best Regards,
Huaimo
From: Eric Rescorla [mailto:[e-mail]]
Sent: Wednesday, March 07, 2018 11:33 PM
To: Huaimo Chen <[e-mail]>
Cc: The IESG <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Re: Eric Rescorla's No Objection on draft-ietf-teas-rsvp-egress-protection-15: (with COMMENT)



On Wed, Mar 7, 2018 at 8:27 PM, Huaimo Chen <[e-mail]<mailto:[e-mail]>> wrote:
Hi Eric,

    Thank you very much for your time and valuable comments.
    Answers to them are inline below with prefix [HC].

Best Regards,
Huaimo
-----Original Message-----
From: Eric Rescorla [mailto:[e-mail]<mailto:[e-mail]>]
Sent: Wednesday, March 07, 2018 9:26 PM
To: The IESG <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; Vishnu Beeram <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Eric Rescorla's No Objection on draft-ietf-teas-rsvp-egress-protection-15: (with COMMENT)

Eric Rescorla has entered the following ballot position for
draft-ietf-teas-rsvp-egress-protection-15: No Objection

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-egress-protection/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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?
[HC]. Yes. We will consider putting some details in the introduction.


   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?
[HC] Yes. In general, locally protecting an egress node of an LSP
means that when the egress node fails, the traffic that the LSP carries
will be delivered to its destination continually by the direct upstream node
of the egress node and the backup egress node.
Without protecting the egress node of the LSP, when the egress node
fails, the traffic will be lost (i.e., the traffic will not be delivered
to its destination).

Sorry, I apologize for being unclear. I meant perhaps you could say it in the intro.
[HC] We will say it accordingly in the introduction.



   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.
[HC] We will revise the related text accordingly as below:
egresses L1 and L2 of a primary P2MP LSP starting from ingress R1.


   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?
[HC] Yes. We will specify it according to your suggestion as follows:
The exact mechanism by which the failure of the primary egress node is
detected by the upstream node R3 is out of the scope of this document.


   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 ....."
[HC] We will update the related text accordingly as below:
If the direct upstream node does not provide any fast local protection
against the failure of the primary egress node, the branch node can be
a (upstream) node on the primary LSP, but not the direct upstream node.


   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?
[HC] A optional subobject means that this subobject is optional (i.e.,
this subobject may be there or may not be there).

Sorry, I got that. I mean, what are the semantics if those are present.
[HC] We will add the text accordingly as follows:
IPv4 and IPv6 primary egress node subobjects indicate the IPv4 and IPv6 address of the primary egress node respectively. IPv4 and IPv6 P2P LSP ID subobjects contains the information for identifying IPv4 and IPv6 backup point-to-point (P2P) LSP tunnels respectively.


-Ekr



   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"
[HC] Yes. It is reroute by R1 instead of R3. We will update the related text
accordingly as follows:
To protect the VPN traffic against the failure of the egress node L1 of
the LSP, when the egress node fails, the ingress R1 of the LSP does
the reroute in an existing solution (refer to Figure 2). The solution
includes:


       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"
[HC] We will update the related text accordingly.