Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-service-chaining

[Henderickx, Wim (Nokia - BE/Antwerp)]

Stephane, I sent a list of question/clarifications/remarks some time ago. I 
haven’t seen them addresses so far on this draft

From: BESS  on behalf of Stephane Litkowski 

Date: Monday, 3 September 2018 at 10:30
To: "bess@ietf.org" 
Subject: [bess] WGLC, IPR and implementation poll for 
draft-ietf-bess-service-chaining


Hello Working Group,



This email starts a two-week Working Group Last Call on 
draft-ietf-bess-service-chaining-05 [1]



This poll runs until *the 17th of September*.



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-service-chaining/



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




[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.



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

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

[Eric C Rosen]

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.


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.



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.


Eric> 2. In order to do inter-subnet multicast in EVPN, the proposal 
requires L3VPN/MVPN configuration on ALL the EVPN PEs.  This is required 
even when there is no need for MVPN/EVPN interworking. This is portrayed 
as a "low provisioning" solution!


Ali> Using MVPN constructs doesn't requires additional configuration on 
EVPN PEs beyond multicast configuration needed for IRB-mcast operation.


I think you'll find that if you don't reconfigure all the BGP sessions 
to carry AFI/SAFIs 1/128, 2/128, 1/5, and 2/5, you'll have quite a bit 
of trouble running any of the native MVPN procedures ;-) This is perhaps 
the simplest example of additional configuration that is needed.


If doing MVPN/EVPN interworking, one needs to go to every EVPN PE and 
set u

Re: [bess] Comments on draft-ietf-bess-evpn-irb-mcast

[Eric C Rosen]

On 8/15/2018 4:07 AM, Ashutosh Gupta wrote:

Hi Folks,

I have following comments on draft-ietf-bess-evpn-irb-mcast. I also 
compare it to draft-sajassi-bess-evpn-mvpn-seamless-interop, which 
utilizes existing MVPN technology to achieve mcast-irb functionality 
in EVPN.



*1. Re-branding MVPN constructs into EVPN *
/evpn-irb/draft proposes a lot of MVPN constructs into EVPN. 
Originating multicast receiver interest "per PE"  instead of "per BD", 
use of selective tunnels are few examples. If solution really is 
achievable through MVPN, why do we need to re-brand it in EVPN?


As I and others have endeavored to explain in several messages to this 
list, the solution is not achievable by simply using MVPN routes and 
procedures.  Correct emulation of the ethernet muliticast service 
requires the addition of BD-specific information and procedures.  
Without this information, the distinction between "ES" and "BD" is 
lost.   This results in such problems as:


- Failure to correctly emulate ethernet behavior, and

- Inability to summarize routes on a per-subnet basis, thus requiring 
the MVPN PEs to be bombarded with host routes.


The seamless-mcast draft also severely underspecifies the behavior 
needed when interconnecting an EVPN domain to an MVPN domain that uses a 
different tunnel type, and does not appear to recognize either how 
common that scenario is, or how tricky it is to get that right.  (That's 
why the MVPN P-tunnel segmentation procedures are so intricate;  that's 
a whole area that seems to be ignored in the seamless-mcast draft.)


It's also worth reminding folks that 90% of EVPN is based on messages 
and procedures borrowed from L3VPN/MVPN, with the addition of 
information and procedures that are needed to do EVPN-specific things 
involving Ethernet Segments and Broadcast Domains.  This is certainly 
true of the EVPN procedures for advertising unicast IP routes, which do 
not "just use L3VPN".  The OISM proposal in the irb-mcast draft just 
follows along these lines.


Furthermore, it's worth noting that the so-called "seamless-mcast" draft 
has EVPN-specific procedures as well.  And more keep getting added as 
additional problems get discovered (e.g., the new intra-ES tunnels).   
It's very far from being "just use MVPN protocols as is".


Finally, one might also point out that the folks with the most in-depth 
knowledge of MVPN seem to be the least enthusiastic about the 
"seamless-mcast" draft.  Just saying ;-)


In the remainder of this message I want to focus on Ashutosh's 
criticisms of the OISM proposal (as we call the proposal in the 
irb-mcast draft).



*4. Data Plane considerations*
*
*
*4.1.* The data-plane nuances of solution has been underplayed. For 
example, if a PE1 has a (S, G) receivers in BD2, BD3 till BD10, 
whereas source S belongs in BD1 subnet on PE2. And if BD1 is not 
configured locally on PE1, a special BD (called SBD) is programmed as 
IIF in forwarding entry. Later if BD1 gets configured on PE1, it would 
cause IIF to change on PE1 from SBD to BD1.


So far correct.

This would result in traffic disruption for all existing receivers in 
BD2, BD3 till BD10.


The IIF in an (S,G) or (*,G) state can change at any time, due to 
distant (or not so distant) link failures, and/or due to other routing 
changes.  It changes whenever the UMH selection changes, and it changes 
if the ingress PE decides to move a flow from an I-PMSI to an S-PMSI.  
Of all the events that might cause a particular multicast state to 
change its IIF, the addition of a BD on the local PE does not seem to be 
one of the more frequent.


Some PIM implementations try to delay changing the IIF in a given (S,G) 
state until an (S,G) packet actually arrives from the new IIF.  However, 
such data-driven state changes introduce a lot of complexity.  MVPN has 
always tried to avoid data-driven state changes, and MVPN 
implementations will generally see some small amount of disruption when 
the IIF changes.  Methods for minimizing this are really an 
implementation matter.


In the case where a new BD is configured, there may be some risk of an 
(S,G) packet getting lost in the following situation:


- Time t0: The packet arrives and gets marked as being from the SBD.
- Time t1: The IIF changes from SBD to BD1
- Time t2: The packet is processed against the (S,G) state and discarded 
as having arrived from the wrong IIF


Given (a) how short the time t2-t0 is, (b) how infrequently new BDs get 
configured on a PE, and (c) the fact that there are many other causes of 
IIF changes, this does not seem like a real problem.  If it is regarded 
as a problem, resolving it would be an implementation matter.




*4.2. *Also, /evpn-irb/ solution proposes to relax the RPF check for a 
(*, G) multicast entry. This poses a great risk of traffic loops 
especially in transient network conditions in addition to poor 
debug-ability.


In the case where the receiving tenant systems ask for (*,G), and all 
the sources ar

Re: [bess] [Gen-art] Genart last call review of draft-ietf-bess-mvpn-mib-10

[Alissa Cooper]

David, thanks for your review. I have entered a No Objection ballot.

Alissa

> On Sep 6, 2018, at 6:15 PM, David Schinazi  wrote:
> 
> Reviewer: David Schinazi
> Review result: Ready with Nits
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document: draft-ietf-bess-mvpn-mib-10
> Reviewer: David Schinazi
> Review Date: 2018-09-06
> IETF LC End Date: 2018-09-03
> IESG Telechat date: 2018-09-13
> 
> Summary: This document is clearly written and looks ready to me.
> 
> Major issues: None found.
> 
> Minor issues: None found. 
> 
> Nits/editorial comments: Typo "senstive" - please run the internet draft 
> spellchecker tool.
> 
> 
> ___
> Gen-art mailing list
> gen-...@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

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