Re: [bess] Comments about draft-gmsm-bess-evpn-bfd-01

[Rabadan, Jorge (Nokia - US/Mountain View)]

Hi Donald,

Thank you for this.
For the second question, I get from your answer that you will keep both 
encapsulations for the time being? 

Thanks.
Jorge


-Original Message-
From: Donald Eastlake 
Date: Monday, November 5, 2018 at 8:48 PM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" 
Cc: "bess@ietf.org" , 
"draft-gmsm-bess-evpn-bfd.auth...@ietf.org" 

Subject: Re: Comments about draft-gmsm-bess-evpn-bfd-01

Hi Jorge,

On Mon, Nov 5, 2018 at 4:44 AM Rabadan, Jorge (Nokia - US/Mountain
View)  wrote:
>
> Dear authors,
>
> I couldn’t make it to the BESS meeting, so my apologies if some of these 
things have been discussed.
>
> Some comments/questions:

Thanks for sending comments.

> - In the last IETF, I suggested the use of BGP and the BGP-BFD attribute 
to exchange discriminators, as in section 3.1.6 of 
draft-ietf-bess-mvpn-fast-failover. The idea seemed to be accepted, but it is 
not in the new version. This would allow the signaling of the discriminators 
along with MAC/IP routes, IMET routes, AD per-EVI routes, IP-Prefix routes, 
etc. without the burden of having to support the EVPN LSP-ping draft.

There is a draft version -02 in the works intended to include
distribution of BFD discriminators in BGP but this revision was not
completed to the agreement of the authors in time to posted before
this meeting.

> - The draft describes an encapsulation and an alternative encapsulation. 
Is the intend to keep both? Wouldn't be better to leave only one to ease 
implementations and interoperability?

Currently, the candidate version -02 draft dispenses with with the
alternative encapsulation.

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 1424 Pro Shop Court, Davenport, FL 33896 USA
 d3e...@gmail.com

> Thank you.
> Jorge


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

Re: [bess] About draft-brissette-bess-evpn-l2gw-proto-03

[Rabadan, Jorge (Nokia - US/Mountain View)]

Hi Patrice,

Thank you. Please see more in-line with [JORGE].

Thx
Jorge

-Original Message-
From: "Patrice Brissette (pbrisset)" 
Date: Tuesday, November 6, 2018 at 7:49 AM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" , 
"bess@ietf.org" , 
"draft-brissette-bess-evpn-l2gw-proto.auth...@ietf.org" 

Subject: Re: About draft-brissette-bess-evpn-l2gw-proto-03

Hi Jorge,

Please see my comments below ... 

Regards,
 
Patrice Brissette, Principal Engineer
Cisco Systems
Help us track your SP SR/EVPN Customer Opportunity/Status by filling these 
forms: Segment Routing 
 / EVPN 

 
 

On 2018-11-05, 4:44 PM, "Rabadan, Jorge (Nokia - US/Mountain View)" 
 wrote:

Dear authors,

Some comments about this draft:

1- the draft uses some 'non-standard' terminology. Could you use 
RFC7432 terminology please? An example of 'non-standard' term is EVLAG.
 Will do
[JORGE] thank you.

2- the draft proposes a solution for something that works today without 
the need of a multi-homed Ethernet Segment or any new procedures:
- There are already EVPN deployments that use STP/G.8032 access rings.
- The two EVPN PEs that close the ring can participate of the ring 
protocol, therefore the received mac flush messages will withdraw the required 
MAC/IP routes. 
- Since the remote PEs will forward normally based on their MAC FIB 
(populated by MAC/IP routes), there is no need to specify a new "Single Flow 
Active" forwarding mode. This is normal MAC based forwarding. Why do we need to 
create a new mode?? Can you please explain?
- Besides, by adding a bit in the ESI-label ext community different 
than the single-active bit, you make the solution non-backwards compatible.

 I'm not sure why you are mentioning the draft is NOT backward 
compatible. You need to explain that one. May I should add "remote PE not 
support single-flow-active bit may ignore this mode"
[JORGE] Sure, this is what I mean: A PE that receives a non-zero ESI AD per-ES 
route is REQUIRED to process the route as per RFC7432. The route MUST include 
the extended community. The PE also needs to check the single-active bit, which 
can be 0 or 1. Depending on that bit, a non-upgraded PE will either behave as 
all-active or single-active. If you use a different bit, in the best case 
scenario the PE will ignore it and will behave as all-active, so your solution 
won't work. In the worst case scenario, the PE may 'treat as withdraw' the 
route.


 It is true you can support ring using single-homed and you are 
welcome to do so. However, there are important drawbacks. For example, how do 
you achieve ARP and MAC sync?
[JORGE] I don't think you should sync MAC/ARPs in this scenario. In your figure 
1, if you have MAC1 connected to CE2, and PE1 advertises MAC1, you don't want 
to sync MAC1 in PE2 against the ring ESI because PE2 can't reach MAC1 through 
AC2, right? 


3- Section 6 - why do you define yet another extended community for mac 
flush, when we already have one? (RFC7623)

 It is true that we can reuse the MAC mobility from RFC7623. Note 
taken
[JORGE] thanks!

4- there is some value in the proposal though - the mass withdrawal 
(per-BD or per-ES) as opposed to per-MAC withdrawal may speed up convergence. 
Here is an alternative solution that can achieve the same thing and it's 
backwards compatible with RFC7432:

On the L2GWs:
a) Define a single-homed non-zero ESI per L2GW PW. The ESI can be 
auto-derived easily as type 3/4 and be made unique in the network.
b) Since the ES is defined in a single PE, the ES routes will be 
filtered by the RR (use RTC) and won't ever reach other PEs. Alternatively you 
can disable the ES routes.
c) This L2GW ES will be single-active mode (although it does not matter 
much).
d) Since the ES is not shared across the L2GWs, each L2GW will always 
be DF for all the local VLANs. 
e) Each L2GW will send AD per-ES and per-EVI routes for its ESI.
f) When the L2GW receives a mac-flush notification (STP TCN, G.8032 
mac-flush, TLDP MAC withdrawal etc.), the L2GW sends an update of the AD 
per-EVI route with the MAC Mobility extended community and a higher sequence 
number - note that we borrow this well-known mac flush procedure from RFC7623, 
only for AD per-EVI routes.

 As we demonstrated yesterday, there many cases where 
single-active or all-active are simply not working. Relying on single-homed is 
not sufficient even with an ESI. I already gave the example of ARP/MAC sync. 
[JORGE] see my comment above. Sorry that I missed your presentation yesterday. 
Could you please clarify for me how you do ARP/MAC sync so that it 

Re: [bess] About draft-brissette-bess-evpn-l2gw-proto-03

[Patrice Brissette (pbrisset)]

Hi Jorge,

Please see my comments below ... 

Regards,
 
Patrice Brissette, Principal Engineer
Cisco Systems
Help us track your SP SR/EVPN Customer Opportunity/Status by filling these 
forms: Segment Routing 
 / EVPN 

 
 

On 2018-11-05, 4:44 PM, "Rabadan, Jorge (Nokia - US/Mountain View)" 
 wrote:

Dear authors,

Some comments about this draft:

1- the draft uses some 'non-standard' terminology. Could you use RFC7432 
terminology please? An example of 'non-standard' term is EVLAG.
 Will do

2- the draft proposes a solution for something that works today without the 
need of a multi-homed Ethernet Segment or any new procedures:
- There are already EVPN deployments that use STP/G.8032 access rings.
- The two EVPN PEs that close the ring can participate of the ring 
protocol, therefore the received mac flush messages will withdraw the required 
MAC/IP routes. 
- Since the remote PEs will forward normally based on their MAC FIB 
(populated by MAC/IP routes), there is no need to specify a new "Single Flow 
Active" forwarding mode. This is normal MAC based forwarding. Why do we need to 
create a new mode?? Can you please explain?
- Besides, by adding a bit in the ESI-label ext community different than 
the single-active bit, you make the solution non-backwards compatible.

 I'm not sure why you are mentioning the draft is NOT backward 
compatible. You need to explain that one. May I should add "remote PE not 
support single-flow-active bit may ignore this mode"
 It is true you can support ring using single-homed and you are 
welcome to do so. However, there are important drawbacks. For example, how do 
you achieve ARP and MAC sync?


3- Section 6 - why do you define yet another extended community for mac 
flush, when we already have one? (RFC7623)

 It is true that we can reuse the MAC mobility from RFC7623. Note taken

4- there is some value in the proposal though - the mass withdrawal (per-BD 
or per-ES) as opposed to per-MAC withdrawal may speed up convergence. Here is 
an alternative solution that can achieve the same thing and it's backwards 
compatible with RFC7432:

On the L2GWs:
a) Define a single-homed non-zero ESI per L2GW PW. The ESI can be 
auto-derived easily as type 3/4 and be made unique in the network.
b) Since the ES is defined in a single PE, the ES routes will be filtered 
by the RR (use RTC) and won't ever reach other PEs. Alternatively you can 
disable the ES routes.
c) This L2GW ES will be single-active mode (although it does not matter 
much).
d) Since the ES is not shared across the L2GWs, each L2GW will always be DF 
for all the local VLANs. 
e) Each L2GW will send AD per-ES and per-EVI routes for its ESI.
f) When the L2GW receives a mac-flush notification (STP TCN, G.8032 
mac-flush, TLDP MAC withdrawal etc.), the L2GW sends an update of the AD 
per-EVI route with the MAC Mobility extended community and a higher sequence 
number - note that we borrow this well-known mac flush procedure from RFC7623, 
only for AD per-EVI routes.

 As we demonstrated yesterday, there many cases where single-active or 
all-active are simply not working. Relying on single-homed is not sufficient 
even with an ESI. I already gave the example of ARP/MAC sync. 


On the remote PEs:
g) The MACs will be learned against the ESIs, but there will only be one 
next-hop per ES. No aliasing or no backup. And RFC7432-compatible.
h) Upon receiving an AD per-EVI update with a higher SEQ number, the PE 
flushes all the MACs for the BD. If the PE does not understand the MAC Mobility 
ext comm in the AD per-EVI route, it won't do anything and will simply flush 
MACs based on MAC/IP route withdrawals.
i) Upon receiving an AD per-ES route withdrawal the PE will do mass 
withdrawal for all the affected BDs (this is the case where the L2GW local ES 
goes down).

 I think you are considering only failure visible by PE only.

Please let me know your comments.

Thank you.
Jorge






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

Re: [bess] About draft-brissette-bess-evpn-l2gw-proto-03

[John E Drake]

Hi,

I agree w/ Jorge's proposal.

Yours Irrespectively,

John


> -Original Message-
> From: BESS  On Behalf Of Rabadan, Jorge (Nokia -
> US/Mountain View)
> Sent: Monday, November 5, 2018 4:45 AM
> To: bess@ietf.org; draft-brissette-bess-evpn-l2gw-proto.auth...@ietf.org
> Subject: [bess] About draft-brissette-bess-evpn-l2gw-proto-03
> 
> Dear authors,
> 
> Some comments about this draft:
> 
> 1- the draft uses some 'non-standard' terminology. Could you use RFC7432
> terminology please? An example of 'non-standard' term is EVLAG.
> 
> 2- the draft proposes a solution for something that works today without the
> need of a multi-homed Ethernet Segment or any new procedures:
> - There are already EVPN deployments that use STP/G.8032 access rings.
> - The two EVPN PEs that close the ring can participate of the ring protocol,
> therefore the received mac flush messages will withdraw the required
> MAC/IP routes.
> - Since the remote PEs will forward normally based on their MAC FIB
> (populated by MAC/IP routes), there is no need to specify a new "Single Flow
> Active" forwarding mode. This is normal MAC based forwarding. Why do we
> need to create a new mode?? Can you please explain?
> - Besides, by adding a bit in the ESI-label ext community different than the
> single-active bit, you make the solution non-backwards compatible.
> 
> 3- Section 6 - why do you define yet another extended community for mac
> flush, when we already have one? (RFC7623)
> 
> 4- there is some value in the proposal though - the mass withdrawal (per-BD
> or per-ES) as opposed to per-MAC withdrawal may speed up convergence.
> Here is an alternative solution that can achieve the same thing and it's
> backwards compatible with RFC7432:
> 
> On the L2GWs:
> a) Define a single-homed non-zero ESI per L2GW PW. The ESI can be auto-
> derived easily as type 3/4 and be made unique in the network.
> b) Since the ES is defined in a single PE, the ES routes will be filtered by 
> the RR
> (use RTC) and won't ever reach other PEs. Alternatively you can disable the
> ES routes.
> c) This L2GW ES will be single-active mode (although it does not matter
> much).
> d) Since the ES is not shared across the L2GWs, each L2GW will always be DF
> for all the local VLANs.
> e) Each L2GW will send AD per-ES and per-EVI routes for its ESI.
> f) When the L2GW receives a mac-flush notification (STP TCN, G.8032 mac-
> flush, TLDP MAC withdrawal etc.), the L2GW sends an update of the AD per-
> EVI route with the MAC Mobility extended community and a higher sequence
> number - note that we borrow this well-known mac flush procedure from
> RFC7623, only for AD per-EVI routes.
> 
> On the remote PEs:
> g) The MACs will be learned against the ESIs, but there will only be one next-
> hop per ES. No aliasing or no backup. And RFC7432-compatible.
> h) Upon receiving an AD per-EVI update with a higher SEQ number, the PE
> flushes all the MACs for the BD. If the PE does not understand the MAC
> Mobility ext comm in the AD per-EVI route, it won't do anything and will
> simply flush MACs based on MAC/IP route withdrawals.
> i) Upon receiving an AD per-ES route withdrawal the PE will do mass
> withdrawal for all the affected BDs (this is the case where the L2GW local ES
> goes down).
> 
> Please let me know your comments.
> 
> Thank you.
> Jorge
> 
> 
> 
> 
> ___
> BESS mailing list
> BESS@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_bess&d=DwICAg&c=HAkYuh63rsuhr6Sc
> bfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-
> s_xXXup3HzvBSMRj5VE&m=kfwh59Pugrm0xKNQhDY5GPyy_bmYJpBOz8qJlix
> Yj7w&s=5lQsLyRE7AmY0gkMA3vUe8midV3e4qx80blF1vr6snY&e=

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

Re: [bess] Comparing using the SD-WAN Overlay SAFI specified by draft-dunbar-idr-bgp-sdwan-overlay-ext with the EVPN approach described by draft-sajassi-bess-secure-evpn-00

[Robert Raszuk]

Hi Linda,

There are some key differences: Skype and CDN overlay companies don’t have
> any intension to interoperate, but networking needs interoperability.
>

There is no issue about interoperability. Observe that that each endpoint
can today seamlessly be a member of N different SD-WAN orchestration
systems. In fact wise deployment requires that to provide sufficient
robustness on a per site SD-WAN VPN basis.

 Adding a new BGP SAFI is 1% of implementation burden of adding a new
> protocol.
>

Look ... BGP RRs got loaded with carrying dynamic IGP data. Now we are
facing to load it with IPSec data. Where does this end ?

IMHO IDR WG should evaluate each proposal for extension in the view of what
elements of BGP protocol given extension attempts to augment. If this is
solely for transporting opaque data such proposal should be either denied
or ensured by MUST that is has to run on different instance of real BGP
(just to accomodate your 1% code extension) as proposed
in draft-raszuk-mi-bgp-00


4. Registry of Data on AWS etc...
>
> [Linda] sure if AWS is interested in participating to make the needed
> changes. More work is needed to make AWS Data registry to communicate our
> existing BGP?
>

AWS or Azure or GCP should not play any role in that. Those would be purely
compute infra providers taking no responsibility for what data is being
exchanged there. Obviously some vendor neutral entitiy should operate it.
Likely some ICANN analogy on how DNS is being run today.

But as mentioned above for SD-WAN I really do not see a problem. Any open
or closed SD-WAN orchestration with just few clicks of the mouse can add or
delete sites and such sites can participate in more then one SD-WAN. In
fact paying few dollars per month per site allows you to outsource your WAN
networking costs for peanuts as well as benefit from a lot of non limited
custom features between SD-WAN providers.

Do we really want now to limit that innovation by putting them onto IETF
tracks (regardless of WG chosen to own this) ?

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

[bess] what are the problems to anticipate with new SD-WAN SAFI specified by draft-dunbar-idr-bgp-sdwan-overlay-ext ?

[Linda Dunbar]

There are already >60 BGP SAFI being specified: 
https://www.iana.org/assignments/safi-namespace/safi-namespace.xhtml

Many people told me that New SAFI would requires changes to RR.

But to use RR to relay SD-WAN end point properties to the authorized peers, RR 
has to be enhanced.

For normal IPsec, edge nodes have to be provisioned with policies on which 
peers the edge nodes can establish IPsec SA. For large SD-WAN deployment, it 
becomes N square problem, as Ali described at the BESS session today. It scales 
much better if the SD-WAN CPE offload the Security Association Policy work to 
RR, by just advertising its properties to its corresponding RR:

-RR can authenticate if the Peer is authorized to receive the 
Advertisement.
-CPE and RR has to establish a secure channel first (such as TLS or 
DTLS) before CPE can propagate its end points properties to its RR
-IPsec SA needs to re-key periodically, there will be many messages for 
the same tunnel, but with different IPsec SA subTLV.

Having a new SAFI makes RR implementation so much cleaner & simpler.

Really appreciate anyone can elaborate what are the problems to anticipate with 
new SD-WAN SAFI specified by draft-dunbar-idr-bgp-sdwan-overlay-ext ?

Thank you
Linda Dunbar
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Comments about draft-gmsm-bess-evpn-bfd-01

[Donald Eastlake]

Hi Jorge,

On Mon, Nov 5, 2018 at 4:44 AM Rabadan, Jorge (Nokia - US/Mountain
View)  wrote:
>
> Dear authors,
>
> I couldn’t make it to the BESS meeting, so my apologies if some of these 
> things have been discussed.
>
> Some comments/questions:

Thanks for sending comments.

> - In the last IETF, I suggested the use of BGP and the BGP-BFD attribute to 
> exchange discriminators, as in section 3.1.6 of 
> draft-ietf-bess-mvpn-fast-failover. The idea seemed to be accepted, but it is 
> not in the new version. This would allow the signaling of the discriminators 
> along with MAC/IP routes, IMET routes, AD per-EVI routes, IP-Prefix routes, 
> etc. without the burden of having to support the EVPN LSP-ping draft.

There is a draft version -02 in the works intended to include
distribution of BFD discriminators in BGP but this revision was not
completed to the agreement of the authors in time to posted before
this meeting.

> - The draft describes an encapsulation and an alternative encapsulation. Is 
> the intend to keep both? Wouldn't be better to leave only one to ease 
> implementations and interoperability?

Currently, the candidate version -02 draft dispenses with with the
alternative encapsulation.

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 1424 Pro Shop Court, Davenport, FL 33896 USA
 d3e...@gmail.com

> Thank you.
> Jorge

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

[bess] About draft-brissette-bess-evpn-l2gw-proto-03

[Rabadan, Jorge (Nokia - US/Mountain View)]

Dear authors,

Some comments about this draft:

1- the draft uses some 'non-standard' terminology. Could you use RFC7432 
terminology please? An example of 'non-standard' term is EVLAG.

2- the draft proposes a solution for something that works today without the 
need of a multi-homed Ethernet Segment or any new procedures:
- There are already EVPN deployments that use STP/G.8032 access rings.
- The two EVPN PEs that close the ring can participate of the ring protocol, 
therefore the received mac flush messages will withdraw the required MAC/IP 
routes. 
- Since the remote PEs will forward normally based on their MAC FIB (populated 
by MAC/IP routes), there is no need to specify a new "Single Flow Active" 
forwarding mode. This is normal MAC based forwarding. Why do we need to create 
a new mode?? Can you please explain?
- Besides, by adding a bit in the ESI-label ext community different than the 
single-active bit, you make the solution non-backwards compatible.

3- Section 6 - why do you define yet another extended community for mac flush, 
when we already have one? (RFC7623)

4- there is some value in the proposal though - the mass withdrawal (per-BD or 
per-ES) as opposed to per-MAC withdrawal may speed up convergence. Here is an 
alternative solution that can achieve the same thing and it's backwards 
compatible with RFC7432:

On the L2GWs:
a) Define a single-homed non-zero ESI per L2GW PW. The ESI can be auto-derived 
easily as type 3/4 and be made unique in the network.
b) Since the ES is defined in a single PE, the ES routes will be filtered by 
the RR (use RTC) and won't ever reach other PEs. Alternatively you can disable 
the ES routes.
c) This L2GW ES will be single-active mode (although it does not matter much).
d) Since the ES is not shared across the L2GWs, each L2GW will always be DF for 
all the local VLANs. 
e) Each L2GW will send AD per-ES and per-EVI routes for its ESI.
f) When the L2GW receives a mac-flush notification (STP TCN, G.8032 mac-flush, 
TLDP MAC withdrawal etc.), the L2GW sends an update of the AD per-EVI route 
with the MAC Mobility extended community and a higher sequence number - note 
that we borrow this well-known mac flush procedure from RFC7623, only for AD 
per-EVI routes.

On the remote PEs:
g) The MACs will be learned against the ESIs, but there will only be one 
next-hop per ES. No aliasing or no backup. And RFC7432-compatible.
h) Upon receiving an AD per-EVI update with a higher SEQ number, the PE flushes 
all the MACs for the BD. If the PE does not understand the MAC Mobility ext 
comm in the AD per-EVI route, it won't do anything and will simply flush MACs 
based on MAC/IP route withdrawals.
i) Upon receiving an AD per-ES route withdrawal the PE will do mass withdrawal 
for all the affected BDs (this is the case where the L2GW local ES goes down).

Please let me know your comments.

Thank you.
Jorge




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

[bess] About draft-brissette-bess-evpn-mh-pa-02

[Rabadan, Jorge (Nokia - US/Mountain View)]

Hi all,

I think I already made similar comments when the first revision of the draft in 
the subject was presented, but since I see no changes in the last revision, 
please let me throw the comments to the list for discussion:

1) section 3
"Peering PEs MAY exchange only Ethernet-Segment route (Route Type-4)"
Note that the AD per-ES route is REQUIRED in RFC7432. Please don't make this 
solution non-backwards compatible. Besides, mass withdrawal is important in 
this solution.

2) section 4
The document only talks about the default Alg and HRW Alg, but other Algs such 
as Preference make a lot of sense here too.
Also, shouldn't you request a new capability in the DF Election EC capability 
registry? If so, IMO this could be done:
- the ES routes are advertised with existing DF Algs, e.g., default, HRW, Pref
- when the new capability "port-based" is signaled, the Alg should be modified 
to consider the port only and not the Ethernet Tags.
- the "port-based" capability should be compatible with the 'DP' capability 
(for non-revertive) and you should make sure that the AC-DF bit is zero so that 
an AC going down does not influence the DF Election.

3) I assume the ES associated to the port is defined as single-active mode. 
Also, as in RFC7432, the ESI-label based split-horizon procedures should be 
used to avoid transient echo'ed packets.

4) section 5 - Port-active over Integrated Routing-Bridging Interface
In this section you assume that the entire port belongs to a single BD, and 
there are no other ACs in the BD. Without this assumption you cannot drive the 
IRB state out of the ES state. Please let me know if I am missing something, 
otherwise please, make this explicit.

Thank you.
Jorge

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

[bess] Comments about draft-gmsm-bess-evpn-bfd-01

[Rabadan, Jorge (Nokia - US/Mountain View)]

Dear authors,

I couldn’t make it to the BESS meeting, so my apologies if some of these things 
have been discussed.
 
Some comments/questions:

- In the last IETF, I suggested the use of BGP and the BGP-BFD attribute to 
exchange discriminators, as in section 3.1.6 of 
draft-ietf-bess-mvpn-fast-failover. The idea seemed to be accepted, but it is 
not in the new version. This would allow the signaling of the discriminators 
along with MAC/IP routes, IMET routes, AD per-EVI routes, IP-Prefix routes, 
etc. without the burden of having to support the EVPN LSP-ping draft.

- The draft describes an encapsulation and an alternative encapsulation. Is the 
intend to keep both? Wouldn't be better to leave only one to ease 
implementations and interoperability?

Thank you.
Jorge





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

Re: [bess] [Idr] Comparing using the SD-WAN Overlay SAFI specified by draft-dunbar-idr-bgp-sdwan-overlay-ext with the EVPN approach described by draft-sajassi-bess-secure-evpn-00

[Rabadan, Jorge (Nokia - US/Mountain View)]

Ali,

About that granularity, I have a couple of questions about the table in page 
17, and the corresponding sections.
 
a) per PE granularity, EVPN case: wouldn't make sense to use an EVPN route? 
EVPN is the only AFI/SAFI deployed in many networks, so I would really use an 
EVPN route for this. We could use the AD per-ES route with ESI=0, as we did in 
RFC8317.

b) per tenant, EVPN case: in a Layer-3 tenant, a given BD may not be attached 
to all the PEs of the L3 tenant domain, hence the IMET route may not work. An 
alternative for L3 tenants is to use an SBD in all the PEs and use an IMET on 
the SBD.  

And a last comment: I think section 9 is a copy paste error from another draft 
;-)

Thank you.
Jorge




From: Idr  on behalf of "Ali Sajassi (sajassi)" 

Date: Monday, November 5, 2018 at 12:11 AM
To: Linda Dunbar , "i...@ietf.org" , 
"bess@ietf.org" 
Subject: Re: [Idr] [bess] Comparing using the SD-WAN Overlay SAFI specified by 
draft-dunbar-idr-bgp-sdwan-overlay-ext with the EVPN approach described by 
draft-sajassi-bess-secure-evpn-00

 
Linda,
 
You should read my draft again as it explains IPsec tunnels needed at different 
level of granularity and how this can be achieved with existing routes. The 
traffic does not get sent till the IPsec tunnel is established between a pair 
of endpoints and the draft specifies 6 different types of endpoints for 
different level of granularity – i.e., per PE, per tenant, per subnet, per IP, 
per MAC, and per AC.
 
Cheers,
Ali
 
From: Linda Dunbar 
Date: Sunday, November 4, 2018 at 7:00 AM
To: Cisco Employee , "i...@ietf.org" , 
"bess@ietf.org" 
Subject: RE: [bess] Comparing using the SD-WAN Overlay SAFI specified by 
draft-dunbar-idr-bgp-sdwan-overlay-ext with the EVPN approach described by 
draft-sajassi-bess-secure-evpn-00
 
Ali, 
 
Your draft-sajassi-bess-secure-evpn-00 defines two new Tunnel Types along with 
its associated sub-TLVs for The Tunnel Encapsulation Attribute [TUNNEL-ENCAP]. 
 
[Tunnel-Encap] cannot be effectively used for SD-WAN overlay network because a 
SD-WAN Tunnel needs to be established before data arrival. There is no routes 
to be associated with the SD-WAN Tunnel.
 
How do you address those issues? 
 
Linda
 
From: Ali Sajassi (sajassi) [mailto:saja...@cisco.com] 
Sent: Wednesday, October 31, 2018 12:04 PM
To: Linda Dunbar ; i...@ietf.org; bess@ietf.org
Subject: Re: [bess] Comparing using the SD-WAN Overlay SAFI specified by 
draft-dunbar-idr-bgp-sdwan-overlay-ext with the EVPN approach described by 
draft-sajassi-bess-secure-evpn-00
 
Hi Linda,
 
I haven’t read your draft yet. I am traveling now but will plan to read your 
draft over next couple of days and respond to your questions.
 
Cheers,
Ali
 
From: BESS  on behalf of Linda Dunbar 

Date: Tuesday, October 30, 2018 at 9:19 AM
To: "mailto:i...@ietf.org"; , "mailto:bess@ietf.org"; 

Subject: [bess] Comparing using the SD-WAN Overlay SAFI specified by 
draft-dunbar-idr-bgp-sdwan-overlay-ext with the EVPN approach described by 
draft-sajassi-bess-secure-evpn-00
 
IDR group, BESS group,
 
https://datatracker.ietf.org/doc/draft-dunbar-idr-bgp-sdwan-overlay-ext/ 
specifies a new BGP SAFI (=74) in order to advertise a SD-WAN edge node’s 
capabilities in establishing SD-WAN overlay tunnels with other SD-WAN nodes 
through third party untrusted networks. 
 
draft-sajassi-bess-secure-evpn-00 describes an EVPN solution for PE nodes to 
exchange key and policy to create private pair-wise IPsec Security Associations 
without IKEv2 point-to-point signaling or any other direct peer-to-peer session 
establishment messages. 
 
I think those two solutions are not conflicting with each other. Actually they 
are compliment to each other to some degree. For example, 
- the Re-key mechanism described by draft-sajassi-bess-secure-evpn-00 can be 
utilized by draft-dunbar-idr-bgp-sdwan-overlay-ext  
- The SD-WAN Overlay SAFI can be useful to simplify the process on RR to 
re-distribute the Tunnel End properties to authorized peers. 
- When SD-WAN edge nodes use private address, or no IP address, NAT properties 
for the end points distribution described 
draft-dunbar-idr-bgp-sdwan-overlay-ext is necessary. 
- The secure channel between SD-WAN edge nodes and RR described by 
draft-dunbar-idr-bgp-sdwan-overlay-ext is necessary. 
 
Any thoughts? 
 
Thank you very much. 
 
Linda Dunbar

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

[bess] operational problems for draft-brissette-bess-evpn-l2gw-proto

[Susan Hares]

Greetings: 

 

In grow WG today, Randy Bush shared research that that communities may be
erroneous sent up to 4 AS beyond the original sending.   How does the
technology in this draft prevent this from occurring? 

 

Is your only guarantee policy at the edge?  

 

Sue Hares 

 

 

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

Re: [bess] draft-ietf-bess-security-00.txt

[Susan Hares]

+1 on this question.   I hope Ali will discuss. 

 

Sue 

 

From: Henderickx, Wim (Nokia - BE/Antwerp) [mailto:wim.henderi...@nokia.com] 
Sent: Monday, November 5, 2018 3:10 AM
To: Susan Hares; bess@ietf.org
Subject: Re: [bess] draft-ietf-bess-security-00.txt

 

Also how does the solution behave if the edge device is no longer connected to 
the RR and does not get keys in time to refresh. Common issue in SD-WAN context 
which is in scope from what I understood on the discussion with Linda.

 

From: BESS  on behalf of Susan Hares 
Date: Monday, 5 November 2018 at 15:06
To: "bess@ietf.org" 
Subject: [bess] draft-ietf-bess-security-00.txt

 

Ali:

 

It would be useful to indicate how you keep the IPSEC information from going 
outside the AS.   For reference, this is Keyur Patel’s question. 

 

Cheerily, Susan Hares 

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

Re: [bess] draft-ietf-bess-security-00.txt

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

Also how does the solution behave if the edge device is no longer connected to 
the RR and does not get keys in time to refresh. Common issue in SD-WAN context 
which is in scope from what I understood on the discussion with Linda.

From: BESS  on behalf of Susan Hares 
Date: Monday, 5 November 2018 at 15:06
To: "bess@ietf.org" 
Subject: [bess] draft-ietf-bess-security-00.txt

Ali:

It would be useful to indicate how you keep the IPSEC information from going 
outside the AS.   For reference, this is Keyur Patel’s question.

Cheerily, Susan Hares
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

[bess] draft-ietf-bess-security-00.txt

[Susan Hares]

Ali:

 

It would be useful to indicate how you keep the IPSEC information from going
outside the AS.   For reference, this is Keyur Patel's question. 

 

Cheerily, Susan Hares 

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