Re: [bess] (Action required from Author)Re: Time to gather WG document status update

[Greg Mirsky]

Hi Mankamana,
apologies for the belated response.
For draft-bess-mvpn-fast-failover - working on addressing comments received
during WGLC. Will try to close by the end of February.

Regards,
Greg

On Tue, Jan 22, 2019 at 3:49 AM Mankamana Mishra (mankamis) <
manka...@cisco.com> wrote:

> Hi WG
>
> So far I have not heard from any one. It would be really great to get
> input from authors.  We would like to make progress before next meeting
> Prauge. If there is any thing which is blocking progress of any document ,
> it might be good to work on it and get things resolved.
>
>
>
> Thanks
>
> Mankamana
>
>
>
>
>
> *From: *"stephane.litkow...@orange.com" 
> *Date: *Tuesday, January 8, 2019 at 5:42 AM
> *To: *"draft-ietf-bess-evpn-inter-subnet-forwarding.auth...@ietf.org" <
> draft-ietf-bess-evpn-inter-subnet-forwarding.auth...@ietf.org>, "
> draft-ietf-bess-evpn-irb-mcast.auth...@ietf.org" <
> draft-ietf-bess-evpn-irb-mcast.auth...@ietf.org>, "
> draft-ietf-bess-evpn-na-flags.auth...@ietf.org" <
> draft-ietf-bess-evpn-na-flags.auth...@ietf.org>, "
> draft-ietf-bess-evpn-per-mcast-flow-df-election.auth...@ietf.org" <
> draft-ietf-bess-evpn-per-mcast-flow-df-election.auth...@ietf.org>, "
> draft-ietf-bess-evpn-pref-df.auth...@ietf.org" <
> draft-ietf-bess-evpn-pref-df.auth...@ietf.org>, "
> draft-ietf-bess-evpn-unequal-lb.auth...@ietf.org" <
> draft-ietf-bess-evpn-unequal-lb.auth...@ietf.org>, "
> draft-ietf-bess-evpn-vpls-seamless-integ.auth...@ietf.org" <
> draft-ietf-bess-evpn-vpls-seamless-integ.auth...@ietf.org>, "
> draft-ietf-bess-evpn-virtual-eth-segment.auth...@ietf.org" <
> draft-ietf-bess-evpn-virtual-eth-segment.auth...@ietf.org>, "
> draft-ietf-bess-evpn-yang.auth...@ietf.org" <
> draft-ietf-bess-evpn-yang.auth...@ietf.org>, "
> draft-ietf-bess-l2vpn-yang.auth...@ietf.org" <
> draft-ietf-bess-l2vpn-yang.auth...@ietf.org>, "
> draft-ietf-bess-l3vpn-yang.auth...@ietf.org" <
> draft-ietf-bess-l3vpn-yang.auth...@ietf.org>, "
> draft-ietf-bess-mvpn-evpn-aggregation-label.auth...@ietf.org" <
> draft-ietf-bess-mvpn-evpn-aggregation-label.auth...@ietf.org>, "
> draft-ietf-bess-mvpn-fast-failover.auth...@ietf.org" <
> draft-ietf-bess-mvpn-fast-failover.auth...@ietf.org>, "
> draft-ietf-bess-service-chaining.auth...@ietf.org" <
> draft-ietf-bess-service-chaining.auth...@ietf.org>, "
> draft-ietf-bess-nsh-bgp-control-plane.auth...@ietf.org" <
> draft-ietf-bess-nsh-bgp-control-plane.auth...@ietf.org>, "
> draft-ietf-bess-datacenter-gateway.auth...@ietf.org" <
> draft-ietf-bess-datacenter-gateway.auth...@ietf.org>, "
> draft-ietf-bess-evpn-fast-df-recovery.auth...@ietf.org" <
> draft-ietf-bess-evpn-fast-df-recovery.auth...@ietf.org>, "
> draft-ietf-bess-evpn-igmp-mld-proxy.auth...@ietf.org" <
> draft-ietf-bess-evpn-igmp-mld-proxy.auth...@ietf.org>, "
> draft-ietf-bess-evpn-vpws-fxc.auth...@ietf.org" <
> draft-ietf-bess-evpn-vpws-fxc.auth...@ietf.org>, "
> draft-ietf-bess-mvpn-msdp-sa-interoperation.auth...@ietf.org" <
> draft-ietf-bess-mvpn-msdp-sa-interoperation.auth...@ietf.org>, "
> bess@ietf.org" 
> *Cc: *"Mankamana Mishra (mankamis)" , "
> bess-cha...@ietf.org" 
> *Subject: *Time to gather WG document status update
>
>
>
> Hi WG,
>
>
>
> I wish you all an happy new year and all the best for 2019 !
>
> We should now all be back to work and we, chairs, are expecting from WG
> document authors to get a status update of your document progress and the
> associated ETA towards the next step. Don’t hesitate to raise the blocking
> points if there is any of if you need help on anything.
>
>
>
> Thanks to provide this update *before end of next week* to our secretary
> Mankamana (manka...@cisco.com).
>
>
>
> Best Regards,
>
>
>
> [image: Orange logo] 
>
>
>
> *Stephane Litkowski *
> Network Architect
> Orange/SCE/EQUANT/OINIS/NET
>
> Orange Expert Future Networks
>
> phone: +33 2 23 *06* 49 83
> 
>  NEW !
> mobile: +33 6 71 63 27 50
> 
>  NEW !
> stephane.litkow...@orange.com
>
>
>
> _
>
>
>
> 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.
>
>
>
> Th

Re: [bess] handling DAD in draft-ietf-bess-evpn-inter-subnet-forwarding-05

[Sowmini Varadhan]

On Wed, Jan 30, 2019 at 9:20 PM Ali Sajassi (sajassi) saja...@cisco.com wrote:

sajassi> AS> RFC 7431 has procedures for duplicate MAC address detection.

rfc 7431 is the Informational RFC titled "Multicast-Only Fast Reroute".

Perhaps you mean rfc 7432. And I suspect you mean Section 15.1

draft*evpn-inter-subnet-forwarding should call out this cross-reference
explicitly, so that the reader does not have to speculate (as I
just did)

sajassi> AS> If ARP probing is done before the target NVE gets to
declare that the TS has moved, then the MAC move is delayed
unnecessarily for ALL the legitimate MAC move cases which in turn can
cause some loss of traffic and degradation in service. It should be
noted that the MAC move procedures in here is consistent with RFC
7432.
sajassi> AS> same reply as above.

it's a bit odd that lot of chaos can happen for approx 3 mins
when there is actually a duplicate address (created accidentally
or maliciously) but I suppose you could say that this is already
based on 7431, so not something introduced by
draft*evpn-inter-subnet-forwarding

Thanks
--Sowmini

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

Re: [bess] WGLC,IPR and implementation poll for draft-ietf-bess-mvpn-fast-failover

[zhang.zheng]

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 
收件人：zzh...@juniper.net ;
抄送人：bess-cha...@ietf.org ;Thomas Morin 
;Robert Kebler ;BESS 
;
日 期 ：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  
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 , depen