Re: [bess] Genart early review of draft-ietf-bess-evpn-mvpn-seamless-interop-06

[Kesavan Thiruvenkatasamy (kethiruv)]

Hi Susan,

Many thanks for a detailed review and comments.  Will get back with document 
updates and  clarifications shortly.

Thanks,
Kesavan

From: Susan Hares via Datatracker 
Date: Tuesday, January 9, 2024 at 3:51 PM
To: gen-...@ietf.org 
Cc: bess@ietf.org , 
draft-ietf-bess-evpn-mvpn-seamless-interop@ietf.org 

Subject: Genart early review of draft-ietf-bess-evpn-mvpn-seamless-interop-06
Reviewer: Susan Hares
Review result: Almost Ready

GEN-ART review

Status: Almost ready

Summary Comment:
==
Multicast distribution can aid the network, so it is important to have a solid
standard.

Wow! This is an amazing amount of work to combine EVPN and MVPN.
I went between RFC6513, RFC6514, RFC7432, and RFC8542. You caught many of the
issues between the EVPN-MVPN.

I'm hopeful this will help catch a few additional issues.

Sue


Status Early Review: On the right track,
 6 technical issues, editorial issues

===
Summary of Technical issues:

1. Technical issue #1:  Section 5.3 - refers to section 8 and 9
How you do you restriction of importing the same type-5 Route to IPVPN VRF from
multiple PEs (Section 8.1)?

The issue is the same Route-5 from different PEs (MVPN PE or EVPN PE) into the
IPVPN cloud with the same VRF. If type-5  Route is sent from different PEs with
different VRFs, there is not a problem. If type-5 Route is sent once from
different PE with same VRF,  then route selection policy should handle the
resolution. If type-5 Route is sent multiple times from different PEs with Same
VRF, it can encounter the count to infinity problem.

Level: IDR chairs indicate this ia well-known issue, and can be noted in
manageability. Issue: No manageability section.

2. VXLAN tunnels under the MVPN network (Section 8.2.2)
Question: How does the network limit the reach of these tunnels to keep the
EVPN and MVPN?

level: Security/managemeability issue

3. Section 8.2.3 - It is unclear what tunnel types that this RFC draft supports.
Does it support VXLAN plus NVGRE (type = 9) , GRE (type = 2), GENEVE or GPE (?).
Are you supporting any other tunnel types for encapsulation?

Level: Clarity of what is supported in draft

4.  Section 9 – MVPN VPN overlay tunnel over DC network is terminated on
IP-VRF (rather than MAC-VRF/BTs).

Problem 1 – Does the split horizon for EVPN (RFC7432, section 8.3] require MPLS
forwarding in the EVPN-MVPN network? 4a) Does this functioning require MPLS
forwarding of traffic in EVPN--MVPN network? 4b) How is this BUM (Broadcast,
Unknown Unicast, and Multicast traffic) handled in the MVPN/EVPN gateway
(section 6.3) for three types of tunnels?

5. TTL decrement - the IDR chairs do not think this is a problem.

6. The Security section does not seem to cover all the security and
mangeability issue for the EVPN-MVPN?
==

Full Description of 6 Technical issues


Level: Split-horizon + effective split horizon (RFC8584)

===
Explanation of technical comments:

General overview:
The procedures in this draft are an extension of RFC6513 and RFC6514.
Figure 1-2 shows two ways to EVPN and MVPN in seamless operation.

Figure 1:
EVPN glued to MVPN via IP VRFs

EVPN PE1
 ++
   Src1 +|(MAC-VRF1)  |   MVPN PE3
  Rcvr1 +|  \ |+-+   ++
 |(IP-VRF)|| |---|(IP-VRF)|--- Rcvr5
 |  / || |   ++
   Rcvr2 +---|(MAC-VRF2)  || |
 ++| |
   |  MPLS/  |
EVPN PE2   |  IP |
 ++| |
   Rcvr3 +---|(MAC-VRF1)  || |MVPN PE4
 |   \|| |   ++
 |(IP-VRF)|| |---|(IP-VRF)|--- Rcvr6
 |   /|+-+   ++
   Rcvr4 +---|(MAC-VRF3)  |
 ++

   Figure 1:  MVPN PEs Seamless Interop

Figure 2:
EVPN as MVPN PEs

   EVPN PE1
 ++
   Src1 +|(MAC-VRF1)  |
 | \  |
  Rcvr1 +|  ++|+-+   ++
 |  |MVPN PE1||| |---|MVPN PE3|--- Rcvr5
 |  ++|| |   ++
 |  / || |
   Rcvr2 +---|(MAC-VRF2)  || |
 ++| |
   |  MPLS/  |
EVPN PE2   |  IP |
 ++| |
   Rcvr3 +---|(MAC-VRF1)  || |
 |   \ 

Re: [bess] Murray Kucherawy's Discuss on draft-ietf-bess-evpn-bum-procedure-updates-11: (with DISCUSS and COMMENT)

[Kesavan Thiruvenkatasamy (kethiruv)]

FYI:

We will be requesting the following bits from Multicast Flags Extended 
Community Registry for draft-ietf-bess-evpn-mvpn-seamless-interop.

Bit 5 – SEMG  (Seamless interop EVPN Multicast Gateway)
Bit 6 – evpn-mvpn seamless interop supported

Regards,
Kesavan

From: BESS  on behalf of John E Drake 

Date: Thursday, October 21, 2021 at 7:14 AM
To: "Murray S. Kucherawy" , Benjamin Kaduk 
Cc: "ext-zzhang_i...@hotmail.com" , 
"bess-cha...@ietf.org" , The IESG , BESS 
, "draft-ietf-bess-evpn-bum-procedure-upda...@ietf.org" 

Subject: Re: [bess] Murray Kucherawy's Discuss on 
draft-ietf-bess-evpn-bum-procedure-updates-11: (with DISCUSS and COMMENT)

Hi,

Ben is correct in his email, below:

The IGMP and MLD Proxy for EVPN draft (draft-ietf-bess-evpn-igmp-mld-proxy-13) 
is going to create the Multicast Flags Extended Community Registry.  The 
complete list of assignments to be is:

7 SBD (draft-ietf-bess-evpn-irb-mcast)
8 Segment support (draft-ietf-bess-evpn-bum-procedure-updates)
9 IPMG (draft-ietf-bess-evpn-irb-mcast)
10MEG (draft-ietf-bess-evpn-irb-mcast)
11PEG (draft-ietf-bess-evpn-irb-mcast)
12OISM-supported (draft-ietf-bess-evpn-irb-mcast)
13Extended AR (draft-wsv-bess-extended-evpn-optimized-ir)
14MLD Proxy support (draft-ietf-bess-evpn-igmp-mld-proxy)
15IGMP Proxy support (draft-ietf-bess-evpn-igmp-mld-proxy)

Yours Irrespectively,

John



Juniper Business Use Only
From: BESS  On Behalf Of Murray S. Kucherawy
Sent: Thursday, October 21, 2021 3:42 AM
To: Benjamin Kaduk 
Cc: ext-zzhang_i...@hotmail.com ; 
bess-cha...@ietf.org; The IESG ; BESS ; 
draft-ietf-bess-evpn-bum-procedure-upda...@ietf.org
Subject: Re: [bess] Murray Kucherawy's Discuss on 
draft-ietf-bess-evpn-bum-procedure-updates-11: (with DISCUSS and COMMENT)

[External Email. Be cautious of content]

On Wed, Oct 20, 2021 at 11:17 PM Benjamin Kaduk 
mailto:ka...@mit.edu>> wrote:

I'm pretty sure it's the registry to be created by
draft-ietf-bess-evpn-igmp-mld-proxy (also on this week's telechat), though
the specification there doesn't really provide a clear title for the new
registry itself.

Looks like it's on the 10/28 telechat.  I'll have a look at it.  A vague title 
would indeed be a problem.

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

Re: [bess] WG and IPR poll adoption poll for draft-krattiger-evpn-modes-interop

[Kesavan Thiruvenkatasamy (kethiruv)]

Support for adoption

Kesavan


From: BESS  on behalf of "slitkows.i...@gmail.com" 

Date: Monday, April 19, 2021 at 11:07 AM
To: "bess@ietf.org" 
Cc: "bess-cha...@ietf.org" 
Subject: [bess] WG and IPR poll adoption poll for 
draft-krattiger-evpn-modes-interop

Hello,

This email begins a two-weeks WG adoption poll for 
draft-krattiger-evpn-modes-interop-03 [1].

Please review the draft and post any comments to the BESS working group list.

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, copying the BESS mailing list. The document will not  progress 
without answers from all of the authors and contributors.

Currently, there are no IPR disclosures 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.

This poll for adoption closes on 4th May 2021.

Regards,
Matthew and Stephane


[1]  https://datatracker.ietf.org/doc/draft-krattiger-evpn-modes-interop/

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

Re: [bess] WG Last Call and Implementation Poll for draft-ietf-bess-rfc5549revision-00

[Kesavan Thiruvenkatasamy (kethiruv)]

Support.

Kesavan


From: BESS  on behalf of "Bocci, Matthew (Nokia - GB)" 

Date: Monday, January 6, 2020 at 9:54 AM
To: "bess@ietf.org" 
Subject: [bess] WG Last Call and Implementation Poll for 
draft-ietf-bess-rfc5549revision-00

This email starts a two weeks Working Group Last Call on 
draft-ietf-bess-rfc5549revision-00.

Please review the draft and send any comments to the BESS list. Also, please 
indicate if you support publishing the draft as a standards track RFC.

This poll runs until Monday 20th January 2019.

We have only just completed an IPR poll on the draft prior to adoption in 
December 2019, so I will not run another one now.

There is currently no IPR disclosed.

We are also polling for any existing implementation as per [1]. Please indicate 
if you are aware of any implementations of the modified protocol described in 
this draft.

 Thank you,

Matthew

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

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

Re: [bess] WG Adoption and IPR Poll for draft-litkowski-bess-rfc5549revision-00

[Kesavan Thiruvenkatasamy (kethiruv)]

Support.

Regards,
Kesavan


From: BESS  on behalf of "Bocci, Matthew (Nokia - GB)" 

Date: Wednesday, November 27, 2019 at 4:37 AM
To: "bess@ietf.org" 
Cc: "bess-cha...@ietf.org" 
Subject: [bess] WG Adoption and IPR Poll for 
draft-litkowski-bess-rfc5549revision-00

Hello,

This email begins a two-weeks WG adoption poll for 
draft-litkowski-bess-rfc5549revision-00 [1] .

Please review the draft and post any comments to the BESS working group list.

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, copying the BESS mailing list. The document won't progress 
without answers from all the authors and contributors.

Currently, there are no IPR disclosures 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.

This poll for adoption closes on Wednesday 11th December 2019.

Regards,
Matthew

[1] https://datatracker.ietf.org/doc/draft-litkowski-bess-rfc5549revision/



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

Re: [bess] WG adoption poll for draft-sajassi-bess-evpn-mvpn-seamless-interop

[Kesavan Thiruvenkatasamy (kethiruv)]

Support as a co-author. Not aware of any undisclosed IPR.

Regards,
Kesavan


From: BESS  on behalf of "slitkows.i...@gmail.com" 

Date: Monday, October 28, 2019 at 3:10 AM
To: "bess@ietf.org" 
Cc: "bess-cha...@ietf.org" 
Subject: [bess] WG adoption poll for 
draft-sajassi-bess-evpn-mvpn-seamless-interop

Hello,

This email begins a two-weeks WG adoption poll for 
draft-sajassi-bess-evpn-mvpn-seamless-interop [1] ..

Please review the draft and post any comments to the BESS working group list.

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, copying the BESS mailing list. The document won't progress 
without answers from all the authors and contributors.
Currently, there are no IPR disclosures 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.

This poll for adoption closes on 11th November 2019.

Regards,
Matthew and Stephane

[1] 
https://datatracker.ietf.org/doc/draft-sajassi-bess-evpn-mvpn-seamless-interop/

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

Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-evpn-pref-df

[Kesavan Thiruvenkatasamy (kethiruv)]

Support.

Regards,
Kesavan


From: BESS  on behalf of "slitkows.i...@gmail.com" 

Date: Tuesday, October 22, 2019 at 7:48 AM
To: "bess@ietf.org" , "draft-ietf-bess-evpn-pref...@ietf.org" 

Cc: "bess-cha...@ietf.org" 
Subject: [bess] WGLC, IPR and implementation poll for 
draft-ietf-bess-evpn-pref-df

Hello WG,

This email starts a two weeks Working Group Last Call on 
draft-ietf-bess-evpn-pref-df-04 [1].

This poll runs until * the 5th Of November *.


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.

There is currently no IPR disclosed.



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-evpn-pref-df/
[2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Comments on draft-sajassi-bess-evpn-mvpn-seamless-interop-04

[Kesavan Thiruvenkatasamy (kethiruv)]

Hi Jingrong

Thanks for your comments. Please find responses below.

Regards,
Kesavan



[bess] Comments on draft-sajassi-bess-evpn-mvpn-seamless-interop-04

Xiejingrong  Mon, 08 July 2019 11:47 UTCShow 
header

Hi



Thanks the authors to introduce this very useful, very clear draft.

I do think it deserves very much the adoption by the WG as an solution option.



Here are some minor comments after I read the latest draft (which I think does 
not affect the adoption):



6.  Solution Overview

   This section describes a multicast VPN solution based on [RFC6513]

   and [RFC6514] for EVPN PEs operating in IRB mode that want to perform

   seamless interoperability with their counterparts MVPN PEs.

[XJR] with or without their counterparts MVPN PEs (since this document covers 
both).



Kesavan>> This section covers with MVPN PE. Later section covers EVPN only PEs.





   EVPN-PEs advertise unicast routes as host routes using EVPN route

   type 2 for sources that are directly attached to a tenant BD that has

   been extended in the EVPN fabric. EVPN-PE may summarize sources (IP

   networks) behind a router that are attached to EVPN-PE or sources

   that are connected to a BD, which is not extended across EVPN fabric

   and advertises those routes with EVPN route type 5. EVPN host-routes

   are advertised as IPVPN host-routes to MVPN-PEs only incase of

   seamless interop mode.

[XJR] Editorial error. Incase of -> in case of



Kesavan>> Will take care in the next revision





   In gateway model, EVPN-PE advertises unicast routes as IPVPN routes

   along with VRI extended community for all multicast sources attached

   behind EVPN-PEs. All IPVPN routes SHOULD be summarized while

   adverting to MVPN-PEs.

[XJR] VRI is used before its definition  VRF Route Import(6514) or IPv6 VRF 
Route Import(rfc6515) in my opinion.





Kesavan>> Will take care in the next revision







   VRI is constructed as following:

  -  The 4-octet Global Administrator field MUST be set to an IP

 address of the PE.  This address SHOULD be common for all the

 IP-VRFs on the PE (e.g., this address may be the PE's loopback

 address or VTEP address).

  -  The 2-octet Local Administrator field associated with a given

 IP-VRF contains a number that uniquely identifies that IP-VRF

 within the PE that contains the IP-VRF.

[XJR] Does this document want to cover Underlay IPv6 network (described in 
RFC6515) ? If it does(I guess), then the VRI can be IPv6 VRF Route Import as 
pointed above, and the Global Administrator can be a 16-octet field.





Kesavan>>  Thanks for pointing this out.  Will add this in the next revision.







   EVPN PE MUST have Route Target Extended Community to import/export

   MVPN routes. In data center environment, it is desirable to have this

   RT configured using auto-generated method than static configuration.

[XJR] is it a new specification for EVPN PE to have RT Extended Community ? if 
it does not, then MUST word is unnecessary.





   The following is one recommended model to auto-generate MVPN RT:

  - The Global Administrator field of the MVPN RT MAY be set

to BGP AS Number.

  - The Local Administrator field of the MVPN RT MAY be set to

the VNI associated with the tenant VRF.

[XJR] It's very helpful to have a method to auto-generate RT. Should this case 
be pointed out to help decision of using this method or not : the VNI is 24bit, 
and the Local Administrator is 16bit ?





Kesavan>> This is an AS specific EC. Local Administrator field is 4 bytes







9.2.3.  Other Encapsulation

   In order to signal a different tunneling encapsulation such as NVGRE,

  GPE, or GENEVE the corresponding BGP encapsulation extended community

   [TUNNEL-ENCAP] SHOULD be appended to the MVPN I-PMSI and S-PMSI A-D

   routes. If the Tunnel Type field in the encapsulation extended-

   community is set to a type which requires Virtual Network Identifier

   (VNI), e.g., VXLAN-GPE or NVGRE [TUNNEL-ENCAP], then the MPLS label

   in the PMSI Tunnel Attribute MUST be the VNI associated with the

   customer MVPN. Same as in VXLAN case, a gateway is needed for inter-

   operation between the EVPN-IRB PEs and non-EVPN MVPN PEs.

[XJR] I suggest remove the over-thought about various Encapsulation, we have 
seen different BGP attribute other than the TUNNEL-ENCAP attribute in 
https://datatracker.ietf.org/doc/draft-geng-bier-ipv6-inter-domain/

Hope you have a look at that one, and see if this kind of BIERv6 tunnel be 
useful for some scenario this document want to solve  to have a 
non-segmented P2MP tunnel from TOR in SPDC to BNGs outside of the SPDC.

Welcome your comments as well.



Kesavan>>  We need to cover encapsulation methods used in the underlay.  Will 
check other draft that has been pointed out here and get back to you.





Thanks

Re: [bess] Comments on draft-sajassi-bess-evpn-mvpn-seamless-interop

[Kesavan Thiruvenkatasamy (kethiruv)]

Hi  Jeffrey,

Thanks for your comments. Please find inline responses below (Kesavan>>)

Thanks,
Kesavan


--



Hi Ashutosh,

Sorry for the late response. Please see zzh> below.

From: Ashutosh Gupta 
mailto:ashutoshgupta.i...@gmail.com>>
Sent: Wednesday, August 15, 2018 3:57 AM
To: Jeffrey (Zhaohui) Zhang mailto:zzh...@juniper.net>>
Cc: Ali Sajassi mailto:saja...@cisco.com>>; 
bess@ietf.org
Subject: Re: [bess] Comments on draft-sajassi-bess-evpn-mvpn-seamless-interop

Hey Jeffrey,

Thanks for your comments & please find my responses inline  .

On Fri, Jul 20, 2018 at 9:53 AM, Jeffrey (Zhaohui) Zhang 
mailto:zzh...@juniper.net>> wrote:
Hi Ali,

Here are the comments that I did not get a chance for in the meeting today.

Regarding "ttl decrement" and "src mac change":
--

Since "bridging/switching in the same BD" is not put down as a requirement in 
the spec but rather discounted citing "emulation", the listed "requirements" 
should be changed to "properties" as well - one could also argue that those may 
not be true requirements and could also discounted.

 seamless-Interop solution supports both intra-subnet and inter-subnet 
forwarding which are the basic requirement along with Efficient fabric 
utilization and Operational simplicity. More specifically, having many 
discussions with customers we didn't come across any use-case where strict 
intra-subnet bridging was needed along with inter-subnet routing, so we can 
argue that "strict bridging/switching in the same BD" is just an idealistic 
requirement.

Zzh> The point is, those “requirements” are really somewhat 
arbitrary/subjective. We have not heard real requirements about “seamless 
integration” either, and even when the requirement comes, the OISM can do that 
seamless integration by having every EVPN as an MEG.

Even if RFC7432 does not prove true ethernet service, "ttl decrement" and "src 
mac change" for intra-subnet traffic does NOT happen with RFC7432. In other 
words, this is a step-down from RFC7432.

Kesavan>>  New revision proposes a method to keep ttl and src mac intact for 
intra subnet traffic.

 It is not a step down since we are not losing any needed functionality.

Zzh> It is a step down from what RFC7432 provides. The argument that TTL/mac 
change for intra-subnet is not an issue is subjective.

Again, seamless-interop solution utilizes existing and well deployed technology 
(MVPN) instead of re-defining all the constructs of MVPN into EVPN. 
evpn-irb-multicast draft takes later approach and achieves in-signification 
functionality gain at the expense of huge overhead in control-plane (Explained 
on a separate thread). From our customer interactions, we understand that 
Multicast is a complex technology to deploy, operate and troubleshoot. So any 
amount of simplification results in Opex reduction. Additionally, re-use of 
existing MVPN implementation for additional EVPN use-cases results in quick 
time-to-market with lower investment.

Zzh> Please see Eric’s comment on a separate thread. Both Eric and I are from 
MVPN background - trust us that we’d not be against “just use MVPN” if it 
solves EVPN problems effectively.

>> Have responded to Eric’s comments. If there are any other comments, we can 
>> discuss.


Zzh> BTW, with the seamless approach, aren’t you guys abandoning the SMET 
solution defined in draft-ietf-bess-evpn-igmp-mld-proxy?

Kesavan>> SMET solution is not needed for L3 only fabric ( Where all nodes 
support routing on their IRB interfaces).

About the comment "MVPN also decrements ttl and change src mac address" - 
that's expected behavior because it is routing between subnets not "intra 
subnet", and no application that uses MVPN service has assumption on constant 
TTL and src mac.

More regarding the "requirements" (or "properties")
---

With the other solution (evpn-irb-multicast, aka OISM), if every EVPN PE runs 
the MEG procedures then the same set of "requirements" is also achieved - it is 
also "seamless interop" but based on the OISM procedures, but that does not 
"translate into this method" (as defined in the seamless-interop draft) (I 
think that's what you mentioned when addressing Jorge's comment). What's more, 
it does not have the "ttl decrementing" and "src mac change" issue for intra 
subnet traffic.
 The point was made that once multicast traffic reaches MVPN domain, it 
doesn't belong to any specific BD and hence intra-subnet and inter-subnet 
receivers are treated similarly. Even with evpn-irb-multicast solution, it 
would be the same unless a second copy of traffic is send over BD specific 
tunnel.

Zzh> But for traffic reaching MVPN domain, we don’t need to worry about TTL and 
src mac address change, while we do need to worry about that on EVPN side in 
case of intra-subnet. Indeed separate copies are sent for EVPN and MVPN, but 
the 

Re: [bess] Comments on draft-sajassi-bess-evpn-mvpn-seamless-interop

[Kesavan Thiruvenkatasamy (kethiruv)]

Hi Eric,

Thanks for  your comments.   Please see the inline responses below.

Regards,
Kesavan

From: BESS  on behalf of Eric C Rosen 

Date: Monday, September 10, 2018 at 10:39 AM
To: "Ali Sajassi (sajassi)" , Bess WG 
Subject: Re: [bess] Comments on draft-sajassi-bess-evpn-mvpn-seamless-interop

Eric> 1. It seems that the proposal does not do correct ethernet emulation.  
Intra-subnet multicast only sometimes preserves MAC SA and IP TTL, sometimes 
not, depending upon the topology.

Ali> EVPN doesn't provide LAN service per IEEE 802.1Q but rather an emulation 
of LAN service. This document defines what that emulation means

The fact that the proposal doesn't do correct ethernet emulation cannot be 
resolved by having the proposal redefine "emulation" to mean "whatever the 
proposal does".

EVPN needs to ensure that whatever works on a real ethernet will work on the 
emulated ethernet as well; the externally visible service characteristics on 
which the higher layers may depend must be properly offered by the emulation.  
This applies to both unicast and multicast equally.

Otherwise anyone attempting to replace a real ethernet with EVPN will find that 
not every application and/or protocol working on the real ethernet will 
continue to work on the EVPN.

Kesavan>>  A solution has been proposed  in the new revision to preserve MAC-SA 
and IP TTL for intra-subnet  traffic.


Eric> TTL handling for inter-subnet multicast seems inconsistent as well, 
depending upon the topology.

Ali> BTW, TTL handling for inter-subnet IP multicast traffic is done consistent!

Consider the following in a pure MVPN environment:

- Source S is on subnet1, which is attached to PE1.

- Receivers R1 and R2 are on subnet2, which is attached to both PE1 and PE2.

- Subnet1 and subnet2 are different subnets.

Now every (S,G) packet will follow the same path: either (a) 
subnet1-->PE1-->subnet2 or (b) subnet1-->PE1-->PE2-->subnet2.

Both paths cannot be used at the same time, because L3 multicast will not allow 
both PE1 and PE2 to transmit the (S,G) flow to subnet2.  So an (S,G) packet 
received by R1 will always have the same TTL as the same packet received by R2. 
 TTL scoping will therefore work consistently; depending on the routing, and 
from the perspective of any given flow, the two subnets are either one hop away 
from each other, or two hops away from each other.

In the so-called "seamless-mcast" scheme, on the other hand, if R1 and R2 get 
the same (S,G) packet, each may see a different TTL.  Suppose R1 is on an ES 
attached to PE1 but not to PE2, S is on an ES attached to PE1 but not to PE2, 
and R2 is on an ES attached to PE2 but not to PE1.  Then a given (S,G) packet 
received by R1 will have a smaller TTL than the same packet received by R2, 
even though R1 and R2 are on the same subnet.

Note that the seamless-mcast proposal does not provide the behavior that would 
be provided by MVPN, despite the claim that it is "just MVPN".

This user-visible inconsistency may break any use of TTL scoping, and is just 
the sort of thing that tends generate a stream of service calls from customers 
that pay attention to this sort of stuff.

In general, TTL should be decremented by 0 for intra-subnet and by 1 (within 
the EVPN domain) for inter-subnet.  Failure to handle the TTL decrement 
properly will break anything that depends upon RFC 3682 ("The Generalized TTL 
Security Mechanism").  Have you concluded that no use of multicast together 
with RFC 3682 will, now or in the future, ever need to run over EVPN?  I'd like 
to know how that conclusion is supported.  You may also wish to do a google 
search for "multicast ttl scoping".

A related issue is that the number of PEs through which a packet passes should 
not be inferrable by a tenant.  Any sort of multicast traceroute tool used by a 
tenant will give unexpected results if TTL is not handled properly; at the very 
least this will result in service calls.

The OISM proposal (as described in the irb-mcast draft) will decrement TTL by 1 
when packets go from one subnet to another, as an IP multicast frame is 
distributed unchanged to the PEs that need it, and its TTL is decremented by 1 
if an egress PE needs to deliver it to a subnet other than its source subnet.

Kesavan>>  TTL is handled very similar to inter-subnet unicast traffic.  ( In 
EVPN-IRB model,  TTL will get decremented once for hosts that are attached to 
same PE.  TTL. will get decremented twice, if hosts are connected behind two 
different PEs.)


The draft still makes the following peculiar claim:

   "Based on past experiences with MVPN over last dozen years for supported IP 
multicast applications, layer-3 forwarding of intra-subnet multicast traffic 
should be fine."

Since MVPN does not do intra-subnet multicast, experience with MVPN has no 
bearing whatsoever on the needs of intra-subnet multicast.

Kesavan>>The above mentioned statement has been removed in the new revision.


Eric> 2. In order to 

Re: [bess] WG adoption poll and IPR poll for draft-sajassi-bess-evpn-per-mcast-flow-df-election

[Kesavan Thiruvenkatasamy (kethiruv)]

Support.

One comment: The procedure may be made  as address family agnostic .

Regards,
Kesavan

From: BESS  on behalf of "stephane.litkow...@orange.com" 

Date: Wednesday, August 8, 2018 at 6:38 AM
To: "bess@ietf.org" 
Subject: [bess] WG adoption poll and IPR poll for 
draft-sajassi-bess-evpn-per-mcast-flow-df-election

Hi WG,

This email begins a two-week poll for BESS working group adoption of 
draft-sajassi-bess-evpn-per-mcast-flow-df-election-01 [1]

Please review the draft and post any comments to the BESS working group list, 
stating whether or not you support adoption.

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, copying the BESS mailing list. The document won't progress 
without answers from all the authors and contributors.

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.

The poll for working group adoption closes on Wed 22th Aug.

Regards,
Stéphane and Matthew

[1] 
https://datatracker.ietf.org/doc/draft-sajassi-bess-evpn-per-mcast-flow-df-election/




_



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