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

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)"

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

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" ,

Re: [bess] 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

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

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]

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, 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

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

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

Re: [bess] 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

[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

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

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

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

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

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

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.

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

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

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

+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

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

[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