From: Menachem Dodge <mdo...@drivenets.com>
Date: Saturday, April 1, 2023 at 11:58 PM
To: Ali Sajassi (sajassi) <saja...@cisco.com>, bess@ietf.org <bess@ietf.org>
Subject: Re: Draft draft-ietf-bess-7432bis-07 section 7.11.2
Hello Ali,

Thanks very much for your helpful response.

Referring to #2 below, I assume that the default behavior of RFC 7432 for the 
Flow Label would be “no flow label”.
Is that correct?

That’s correct.

Cheers,
Ali

Thank you kindly.

Best Regards,
Menachem

From: Ali Sajassi (sajassi) <saja...@cisco.com>
Date: Saturday, 1 April 2023 at 3:41
To: Menachem Dodge <mdo...@drivenets.com>, bess@ietf.org <bess@ietf.org>
Subject: Re: Draft draft-ietf-bess-7432bis-07 section 7.11.2
CAUTION: External E-Mail - Use caution with links and attachments

Please refer to my comments below in red …

From: BESS <bess-boun...@ietf.org> on behalf of Menachem Dodge 
<mdo...@drivenets.com>
Date: Thursday, March 30, 2023 at 8:51 AM
To: bess@ietf.org <bess@ietf.org>
Subject: [bess] Draft draft-ietf-bess-7432bis-07 section 7.11.2
Hello All,

Section 7.11.2 of the draft-ietf-bess-7432bis states that if there is a 
mismatch – either of the L2-MTU, the Flow Label, or the Control Word that





“the local PE MUST NOT add the remote PE as the EVPN destination for any of the 
corresponding service instances.”


  1.  Is the reasoning that all PEs of a particular instance must behave in the 
same manner with regard to including the Flow Label / Control word and the L2 
MTU size?
The granularity is either at the EVI level or EVI/ESI level and for ELAN, we 
have any to any connectivity which means the info needs to be consistent for 
that EVI or EVI/ESI. So, if there is a mismatch between local and remote info, 
then that connection is not established and operator should be notified. This 
way we will avoid any unpredictable behavior.


  1.  What should be the behavior if local configuration is enabling the Flow 
Label and/or Control word but the L2-ATTR extended community is not received 
from a remote PE? Is the absence of L2-ATTR taken as meaning disabled and the 
remote PE must not be added ? Or perhaps it should be interpreted as unknown 
and the PE should assume that the local configuration applies also with regard 
to the remote PE?
This needs to be analyzed wrt individual flags and the absence of L2 Attribute 
EC should mean the behavior is that of RFC7432 so that we have backward 
compatibility – i.e., if the local PE is configured with no control word and it 
receives the route without L2 attribute EC, then it should NOT establish 
connection for that EVI because the absence of EC means the remote PE should 
send packets with control word per RFC7432.


  1.  Is the same behavior intended regarding EVPN-VPWS service instances as 
RFC 8214 only mentions L2-MTU mismatch but not control word mismatches.
Yes, mismatch of control word should also apply to EVPN-VPWS.

Cheers,
Ali






Thank you kindly.

Best Regards,

Menachem Dodge​​​​
System Architect
[signature_3683755730]
+972-526175734<tel:+972-526175734>
mdo...@drivenets.com<mailto:mdo...@drivenets.com>
follow us on 
Linkedin<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.linkedin.com_company_drivenets&d=DwMGaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=cezglEhs6Oa_CKN9mhFbT8T8kmWwaNdtBDjE9bvBG_E&m=7vc9kZQGwO-AuvuIpq-9R6fQ_1nzXOBC14weVS_T0X0&s=ZOwlTeTzRwLFnZdUX1cu5e-N21FJb3VkN5kN0vdUb6o&e=>
www.drivenets.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.drivenets.com&d=DwQGaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=cezglEhs6Oa_CKN9mhFbT8T8kmWwaNdtBDjE9bvBG_E&m=7vc9kZQGwO-AuvuIpq-9R6fQ_1nzXOBC14weVS_T0X0&s=6dVpM7D8w3FEU564eePsbsF1IlVd3a5xNnLtukA91UQ&e=>
[DriveNets Network 
Cloud]<https://urldefense.proofpoint.com/v2/url?u=https-3A__drivenets.com_products_&d=DwMGaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=cezglEhs6Oa_CKN9mhFbT8T8kmWwaNdtBDjE9bvBG_E&m=7vc9kZQGwO-AuvuIpq-9R6fQ_1nzXOBC14weVS_T0X0&s=Wat92F_qqgdgBF-q1akiFxmtKBruieVNJheGxIJwcPI&e=>

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

Reply via email to