Hi Greg, Jeffrey, co-authors,






About the questions provided by Jeffrey, I have some concerns, please see below 
with Sandy>.


And I have some other questions:


1. According to "draft-ietf-bfd-multipoint-19" and the function defined in this 
draft, IMO the BFD session should be demultiplexed by the combination of 
upstream peer address, the discriminator and the X-PMSI which is used for flow 
forwarding. IMO these content should be written in the draft clearly.



2. The P2MP BFD packet should be delivered in the X-PMSI tunnel. The BFD 
multicast packet MUST be encapsulated in associated tunnel. It seems like there 
is no specifiction for it. 


3. I am confused with section 3.1.1/3.1.2/3.1.3. IMO only the X-PMSI tunnel's 
state influence the BFD session, there is no need for other decision. 


4. For section 3.1.5, IMO the counter method has no relationship with the BFD 
function defined in this document. If the counter method will be used as a 
supplement for BFD session?






Thanks,


Sandy



原始邮件



发件人:GregMirsky <gregimir...@gmail.com>
收件人:zzh...@juniper.net <zzh...@juniper.net>;
抄送人:bess-cha...@ietf.org <bess-cha...@ietf.org>;Thomas Morin 
<thomas.mo...@orange.com>;Robert Kebler <rkeb...@juniper.net>;BESS 
<bess@ietf.org>;
日 期 :2018年12月06日 02:38
主 题 :Re: [bess] WGLC,IPR and implementation poll for 
draft-ietf-bess-mvpn-fast-failover


_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess







Hi Jeffrey,thank you for the review, detailed questions and helpful comments. 
Please find my notes, answers in-line tagged GIM>>.

Regards,
Greg



On Fri, Nov 30, 2018 at 5:14 PM Jeffrey (Zhaohui) Zhang <zzh...@juniper.net> 
wrote:




Hi,


 


I have the following questions/comments:


 


   The procedure described here is an OPTIONAL procedure that consists


   of having a downstream PE take into account the status of P-tunnels


   rooted at each possible upstream PEs, for including or not including


   each given PE in the list of candidate UMHs for a given (C-S,C-G)


   state.  The result is that, if a P-tunnel is "down" (see


   Section 3.1), the PE that is the root of the P-tunnel will not be


   considered for UMH selection, which will result in the downstream PE


   to failover to the upstream PE which is next in the list of


   candidates.


 


Is it possible that a p2mp tunnel is considered up by some leaves  but down by 
some other leaves, leaving to them choosing different UMH? In that case, 
procedures described in Section 9.1.1 ("Discarding Packets from Wrong PE") of 
RFC 6513 must be used. I see that this is actually pointed out later in section 
6 – good to have  a pointer to it right here.



GIM>> Would the following new text that follows the quoted text address your 
concern:
NEW TEXT: 
   If rules to determine the state of the P-tunnel are not
   consistent across all PEs, then some may arrive at a different
   conclusion regarding the state of the tunnel, In such a scenario,
   procedures described in Section 9.1.1 of [RFC 6513] MUST be used.

Sandy> I think Jeffrey means that a egress PE may choose a new UMH after the 
the "old" UMH fails. Then the egress PE may also receive (C-S, C-G) flows from 
old UMH p-tunnel, these flows MUST be discarded according to section 9.1.1 of 
RFC6513. 








 


Additionally, the text in section 3 seems to be more biased on Single  
Forwarder Election choosing the UMH with the highest IP address. Section 5 of 
RFC6513 also describes two other options, hashing or based on “installed UMH 
route” (aka unicast-based). It is not clear how the text in this document 
applies to hashing based selection,  and I don’t see how the text applies to 
unicast-based selection. Some rewording/clarification are needed here.



GIM>> How would the use of an alternative UMH selection algorithm change 
documented use of p2mp BFD? Do you think that if the Upstream PE selected 
using, for example, hashing then defined use of BGP-BFD and p2mp BFD itself no 
longer applicable?

Sandy> Diffrent UMH selection methods don't influent p2mp BFD documented in 
this draft. IMO both of section 3 and section 5 need to be mentioned here in 
order to avoid confusion.







 


   For P-tunnels of type P2MP MPLS-TE, the status of the P-tunnel is


   considered up if one or more of the P2MP RSVP-TE LSPs, identified by


   the P-tunnel Attribute, are in Up state. 


 


Why is “one or more of …” used in the above text?



GIM>> Would s/one or more of/at least one of/ address your concern? 

Sandy> I am not sure there are the situations that  two or more LSPs are used 
to deliver a same (C-S, C-G). IMO only the LSP used by forwarding need to be 
mointor in egress PE. 







 


There are several occurrences of ((S, G)). I assume they should be  changed to 
(C-S, C-G).



GIM>> Indeed, globally replaced s/((S,G))/(C-S,C-G)/ 






 


   A PE can be removed from the UMH candidate list for a given ((S, G))


   if the P-tunnel for this (S, G) (I or S , depending) is leaf


   triggered (PIM, mLDP)


 


Perhaps either remove the (I or S , depending)or  move it to before the “for”.



GIM>> Moved before the "for". 






 


   This document defines the format and ways of usingr a new BGP


   attribute called the "BGP- BFD attribute". 


 


s/usingr/using/



GIM>> Yes, great catch. 






 


   o  MUST use [Ed.note] address as destination IP address when


      transmitting BFD control packets;


 


[Ed.note]?



GIM>> Replaced [Ed...note] to make it as follows:
    o  MUST use address in 127.0.0.0/8 range for IPv4 or in
      0:0:0:0:0:FFFF:7F00:0/104 range for IPv6 as destination IP address
      when transmitting BFD control packets;






 


   If tracking of the P-tunnel by using a p2mp BFD session is to be


   enabled after the P-tunnel has been already signaled, the the


   procedure described above MUST be followed.


 


What if the tracking is to  be enabled before the P-tunnel has been signaled? 
The text implies different behavior?



GIM>> Not really, I guess. I think that the second sentence is important:
   Note that x-PMSI A-D Route MUST be re-sent with exactly the same attributes 
as before and
   the BGP-BFD Attribute included.







s/the the/then the/



GIM>> Done. 






 


   … The dedicated p2mp BFD session MAY monitor the state of


   the Standby Upstream PE.


 


What does the above text mean? Do you mean “A different p2mp BFD session  …”?



GIM>> Yes, thank you for the suggested re-wording. Applied s/The dedicated/A 
different/ 






 


   When such a procedure is used, in the context where fast restoration


   mechanisms are used for the P-tunnels, leaf PEs should be configured


   to wait before updating the UMH, to let the P-tunnel restoration


   mechanism happen.  A configurable timer MUST be provided for this


   purpose, and it is recommended to provide a reasonable default value


   for this timer.


 


What does “such a procedure” refers to?



GIM>> Would s/When such a procedure is used/In such a scenario/






s/recommended/RECOMMENDED/?



GIM>> Great catch, thank you. Done. 






 


3.1.7.  Per PE-CE link BFD Discriminator


 


   The following approach is defined for the fast failover in response


   to the detection of PE-CE link failures, in which UMH selection for a


   given C-multicast route takes into account the state of the BFD


   session associated with the state of the upstream PE-CE link.


 


3.1.7.1.  Upstream PE Procedures


 


   For each protected PE-CE link, the upstream PE initiates a multipoint


   BFD session [I-D.ietf-bfd-multipoint] as MultipointHead toward


   downstream PEs.  A downstream PE monitors the state of the p2mp


   session as MultipointTail and MAY interpret transition of the BFD


   session into Down state as the indication of the associated PE-CE


   link being down.


 


Since  the BFD packets are sent over the P2MP tunnel not the PE-CE link, my 
understanding is that the BFD discriminator is still for the tunnel and not 
tied to the PE-CE link; but different from the previous case, the root will 
stop sending BFD messages when it detects  the PE-CE link failure. As far as 
the egress PEs are concerned, they don’t know if it is the tunnel failure or 
PE-CE link failure.


 


If my  understanding is correct, the wording should be changed.



GIM>> There are other than stopping transmission of BFD control packets ways to 
distinguish two conditions for the egress PE. For example, the MultipointHead 
MAY set the State to AdminDown and continue sending BFD control packets. If and 
when PE-CE link restored to Up, the MultipointHead can set the state to Up in 
the BFD control packet.

Sandy> I agree with Jeffrey. The BFD detection should be mapping to specific 
flow/flows associated with X-PMSIs, not the PE-CE link. The PE-CE link should 
influence the X-PMSIs and associated (C-S, C-G) flows. The AdminDown function 
defined in BFD works normally.







 


   …  If the route to the


   src/RP changes such that the RPF interface is changed to be a new PE-


   CE interface, then the upstream PE will update the S-PMSI A-D route


   with included BGP-BFD Attribute so that value of the BFD


   Discriminator is associated with the new RPF link.


 


If the RPF interface changes on the upstream PE, why should it update  the 
route to send a new discriminator? As long as there is a new RPF interface 
couldn’t the upstream PE do nothing but start tracking the new RPF interface?



GIM>> I'll defer this one to Thomas and Rob.

Sandy> I have the same question with Jeffrey. If RPF interface changes on the 
upstream PE, and a new route generated with a new BFD discriminator, a new P2MP 
BFD session need to be established and the network stability will be 
influenced. We need a function to guarantee the existed BFD session should not 
be influenced.







 


Regardless which way (the currently described way and my imagined  way), some 
text should be added to discuss how the downstream would not switch to another 
upstream PE when the primary PE is just going through a RPF change.



GIM>>  Would appending the following text be acceptable to address your concern:
NEW TEXT:
   To avoid unwarranted switchover a downstream PE MUST gracefully handle the
   updated S-PMSI A-D route and switch to the use of the associated BFD
   Discriminator value.







 


4.  Standby C-multicast route


 


   The procedures described below are limited to the case where the site

   that contains C-S is connected to exactly two PEs. The procedures 
   require all the PEs of that MVPN to follow the single forwarder PE


   selection, as specified in [RFC6513].   


 


 


Why would it not work with more than two upstream PEs?


Why is it limited to single forwarder selection? What about unicast  based 
selection?



GIM>> Again, asking for Thomas and Rob to help. 

Sandy> I agree with Jeffrey. There is no limition for advertising same flows 
through more than two PEs. Maybe the text should be modify to the UMH and the 
next best UMH.







 


This route, that has the semantics of being a 'standby'


   C-multicast route, is further called a "Standby BGP C-multicast


   route", and is constructed as follows:


 


   o  the NLRI is constructed as the original C-multicast route, except


      that the RD is the same as if the C-multicast route was built


      using the standby PE as the UMH (it will carry the RD associated


      to the unicast VPN route advertised by the standby PE for S)


 


Since you mention RD, you might as well mention it carries a Route  Target 
derived from the standby RE’s UMH route’s VRF RT Import EC.



GIM>> Woud the following be acceptable:
NEW TEXT:
   o  the NLRI is constructed as the original C-multicast route, except
      that the RD is the same as if the C-multicast route was built
      using the standby PE as the UMH (it will carry the RD associated
      to the unicast VPN route advertised by the standby PE for S and a
      Route Target derived from the standby PE's UMH route's VRF RT
      Import EC)







 


   If at some later point the local PE determines that C-S is no longer


   reachable through the Primary Upstream PE, the Standby Upstream PE


   becomes the Upstream PE, and the local PE re-sends the C-multicast


   route with RT that identifies the Standby Upstream PE, except that


   now the route does not carry the Standby PE BGP Community (which


   results in replacing the old route with a new route, with the only


   difference between these routes being the presence/absence of the


   Standby PE BGP Community).


 


Additionally the LOCAL_PREF should also change?



GIM>> Like normative SHOULD? 






 


4.3.  Reachability determination


 


   The standby PE can use the following information to determine that


   C-S can or cannot be reached through the primary PE:


 


Shouldn’t this be 4.2.1 instead of 4.3?



GIM>> Yes, agree. Thank you.  






 


5.  Hot leaf standby


 


   The mechanisms defined in sections Section 4 and Section 3 can be


   used together as follows.


 


This section is a little confusing to me. It seems that it really  should be 
how a leaf should behave when hot root standby is used, not that there is a 
“hot leaf” mode. A leaf is just a leaf, not a cold/warm/hot/primary/standby 
leaf.



GIM>> Would re-naming the section to "Use of Standby C-multicast Route" better 
reflect the content of the section?






 


Thanks.


 


Jeffrey


 




From: BESS <bess-boun...@ietf.org> On Behalf Of stephane.litkow...@orange.com
 Sent: Thursday, November 22, 2018 2:54 AM
 To: bess@ietf.org
 Cc: bess-cha...@ietf.org
 Subject: [bess] WGLC, IPR and implementation poll for 
draft-ietf-bess-mvpn-fast-failover




 


Hello Working Group,


   


This email starts a two-week Working Group Last Call on 
draft-ietf-bess-mvpn-fast-failover-04  [1]


 


This poll runs until *the 6th of December*.


 


We are also polling for knowledge of any undisclosed IPR that applies to this 
Document, to ensure that IPR has been disclosed in compliance with IETF IPR 
rules (see RFCs 3979, 4879, 3669 and 5378 for more details).


If you are listed as an Author or a Contributor of this Document please respond 
to this email and indicate whether or not you are aware of any relevant 
undisclosed IPR. The Document won't progress without answers from all the 
Authors  and Contributors.


 


Currently two IPRs have been disclosed against this Document.


 


If you are not listed as an Author or a Contributor, then please explicitly 
respond only if you are aware of any IPR that has not yet been disclosed in 
conformance with IETF rules.


 


We are also polling for any existing implementation as per [2].


   


    Thank you,


    Stephane & Matthew


 


    [1] https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-fast-failover/


 


    [2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw


 

  
_________________________________________________________________________________________________________________________
   Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites 
ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez 
le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les 
messages electroniques etant susceptibles d'alteration, Orange decline toute 
responsabilite si ce message a ete altere, deforme ou falsifie. Merci.   This 
message and its attachments may contain confidential or privileged information 
that may be protected by law; they should not be distributed, used or copied 
without authorisation. If you have received this email in error, please notify 
the sender and delete this message and its attachments. As emails may be 
altered, Orange is not liable for messages that have been modified, changed or 
falsified. Thank you.
_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Reply via email to