Subject: Re: [spring] Discussions on ESI filtering procedure in SRv6 EVPN (defined in draft-dawra-idr-srv6-vpn-03)

From: <[email-masked]>
Date: Fri, 23 Feb 2018 15:23:04 +0800 (CST)

Hi Patrice,

It seems that I didn't explain my method very well, so you didn't understand it very well either. 

I explain my method again in your lines here, please see it.  

//This solution does not work since an ESI spans over more than one EVI.

//With an ESI SID, the egress PE won’t know the VPN to import coming packets.

WYB: The ESI SID is not carried in the DIP, but in the SIP (as  section 1  of  my original mail described) or the SRH (as my original section 2 described).

          Maybe it should not be called as an "SID", because they are so different.

//If we want to go down that road, we need to have an SID per ESI/EVI.

WYB:  The so-called "ESI SID" is not carried in DIP, the DIP is a new SID similar with End.DT2U (but used for BUM packets) and without a ARGS field.

            so, I don't mean that there is an SID per ESI/EVI either.

+------------------------------+                              

| Outer Ethernet Header      |                               

+------------------------------+                              

| Outer IP Header(other fields)|                               

+------------------------------+                                

| Outer Source IP          |  //"ESI SID" carried in SIP or SRH 

+------------------------------+                       

| Outer Destination IP      |  //DIP won't be a "ESI SID"

+------------------------------+                            

| SRH                  |  //when "ESI SID" in SRH, it won't overrides the DIP.

+------------------------------+                              

| Inner Ethernet Header      |                               

+------------------------------+                               

| Ethernet Payload         |                               

+------------------------------+                               

| Ethernet FCS            |                               

+------------------------------+                               

//The way we are doing it is very similar. By combining 2 information, an per ESI/EVI SID create is used in forwarding.

//It is funny that you think the forwarding will be better since you are getting to same situation.

//In fact, the packet transports an unique SID… so I don’t get why it is complex.

WYB: In section 3 of my original mail, the "complex" means that , when the BUM packet is carried in Multicast Group

    or BIER by the underlay network, the ESI-label need to be upstream-assigned.

   It seems that the current draft only describes the ingress-replicating scenario, but leaves the P-multicast tree scenario neglected.

   By considering 2 scenarios at the same time, the "ESI SID" method may be simpler. Because it has a unified dataplane.

   I my opinion, the "ESI SID" needn't be carried in the DIP.

   and the "ESI SID" in the SIP is not only used in ESI-filtering, 

   but also used to pick a specified soure-ESI out and do specified operations to it.

   I think this is another advantage of the "ESI SID" method.

   as I explained above, the "ESI SID" may be not a accurate concept. 

   and we can discuss the method first, if the method is tenable, we can find another word to replace the "ESI SID" concept.      

From: "Patrice Brissette (pbrisset)" <[email-masked]>

Date: Wed, 21 Feb 2018 15:27:52 +0000

To: "[email-masked]" <[email-masked]>, "[email-masked]"

 <[email-masked]>,

 "Clarence Filsfils (cfilsfil)" <[email-masked]>,

 "Darren Dukes (ddukes)" <[email-masked]>, "Pablo Camarillo (pcamaril)"

 <[email-masked]>, "[email-masked]"

 <[email-masked]>, "[email-masked]"

 <[email-masked]>, "[email-masked]" <[email-masked]>,

 "[email-masked]" <[email-masked]>, "[email-masked]"

 <[email-masked]>,

 "[email-masked]" <[email-masked]>,

 "[email-masked]" <[email-masked]>

Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>

Subject: Re: [spring] Discussions on ESI filtering procedure in SRv6 EVPN (defined in draft-dawra-idr-srv6-vpn-03)

Hi,

This solution does not work since an ESI spans over more than one EVI.

With an ESI SID, the egress PE won’t know the VPN to import coming packets.

If we want to go down that road, we need to have an SID per ESI/EVI.

The way we are doing it is very similar. By combining 2 information, an per ESI/EVI SID create is used in forwarding.

It is funny that you think the forwarding will be better since you are getting to same situation.

In fact, the packet transports an unique SID… so I don’t get why it is complex.

Regards

Patrice Brissette

From: "[email-masked]" <[email-masked]>
Date: Wednesday, February 7, 2018 at 2:29 AM
To: "[email-masked]" <[email-masked]>, "Clarence Filsfils (cfilsfil)" <[email-masked]>, "Darren Dukes (ddukes)" <[email-masked]>, Patrice Brissette <[email-masked]>, "Pablo Camarillo (pcamaril)" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Discussions on ESI filtering procedure in SRv6 EVPN (defined in draft-dawra-idr-srv6-vpn-03)

 

Hi folks,

I have some questions on ESI filtering procedure of draft-dawra-idr-srv6-vpn-03 to discuss together with you.

1) The ESI Label(Arg.FE2) is included in the DIP, following the draft above.

 and the ESI filtering procedures is similar to MPLS EVPN with ESI-label lookup.

 so it's a little complex in both data plane and control plane.

 but, if we introduce a End.ESI SID and make the SIP carry the End.ESI SID, 

 the data plane and control plane is more simpler.

 and The ESI-filtering procedures is that:

    in the egress PE, the SIP is compared with the corresponding End.ESI SID of each outputing AC, 

    when they are the same, the packet passed, otherwise the packet dropped.

 This is very similar to PBB EVPN ESI-filtering, where S-BMAC take the place of End.ESI SID

  How do you think this method?

2) If the Source ESI is carried on the bottom of the SID stack in the SRH,

  and we don't expect that the service SID is the bottom of the SID stack in the SRH,

  we can do the ESI-filtering as the following:

    in the egress PE, the source-ESI is compared with the corresponding ESI of each outputing AC, 

    the packet passed if they are the same, otherwise the packet dropped.

  the ESI in SRH can be used to do differentiated procedures for some pre-configured source-ESIs,

  for example, we can mirror a specified ESI's packets to a server,

  it seems that the differentiated procedures based on source-ESI is not supportted in current SRv6 EVPN procedures. 

  but both the two method can do this.  

  Is there something important I missed?

3) In current SRv6 EVPN procedures, when the BUM packets is replicated on the core Nodes,

  it means that the ESI-label is upstream-assigned, and the dataplane is complex,

  but the above two methods are as simple as the ingress-replication scenario.

  so maybe it's an advantage of the above two methods?

Best Regards,

Wang Yubao