Re: [bess] WG adoption and IPR poll for draft-thubert-bess-secure-evpn-mac-signaling-04

2024-02-27 Thread Antoni Przygienda 
not aware of undisclosed IPR

support as co-author



Juniper Business Use Only

From: slitkows.i...@gmail.com 
Date: Tuesday, 27 February 2024 at 10:41
To: bess@ietf.org , 
draft-thubert-bess-secure-evpn-mac-signal...@ietf.org 

Cc: bess-cha...@ietf.org 
Subject: WG adoption and IPR poll for 
draft-thubert-bess-secure-evpn-mac-signaling-04
[External Email. Be cautious of content]


Hi,



This email begins a two-week WG adoption and IPR poll for 
draft-thubert-bess-secure-evpn-mac-signaling-04 
(https://datatracker.ietf.org/doc/draft-thubert-bess-secure-evpn-mac-signaling/).



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 the authors and contributors.



If you are not listed as an author or a contributor, then please explicitly 
respond to the IPR poll 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 12th March 2024.



Thanks.


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

Re: [bess] Rtgdir last call review of draft-ietf-bess-mvpn-evpn-aggregation-label-08

2022-12-12 Thread Antoni Przygienda 
Thanks. All adressed AFAIS


  *   Tony

From: Jeffrey (Zhaohui) Zhang 
Date: Monday, 12 December 2022 at 17:50
To: Antoni Przygienda , rtg-...@ietf.org 
Cc: bess@ietf.org , 
draft-ietf-bess-mvpn-evpn-aggregation-label@ietf.org 
, last-c...@ietf.org 

Subject: RE: Rtgdir last call review of 
draft-ietf-bess-mvpn-evpn-aggregation-label-08
Hi Tony,

Thanks for your thorough review and comments. I have posted the -09 version 
that I believe/hope have address your comments/concerns.
https://datatracker.ietf.org/doc/html/draft-ietf-bess-mvpn-evpn-aggregation-label-09

Please see zzh> below for some details.


Juniper Business Use Only

-Original Message-
From: Tony Przygienda via Datatracker 
Sent: Tuesday, November 1, 2022 4:02 PM
To: rtg-...@ietf.org
Cc: bess@ietf.org; draft-ietf-bess-mvpn-evpn-aggregation-label@ietf.org; 
last-c...@ietf.org
Subject: Rtgdir last call review of 
draft-ietf-bess-mvpn-evpn-aggregation-label-08

[External Email. Be cautious of content]


Reviewer: Tony Przygienda
Review result: Has Issues

As first, technically sound except point 18. Rest of the commentes provided are 
all for easier readability/clarity for a reader that may not be super 
instrinsically familiar with the world of overlay multicast tunnels underlying 
VPN technologies first. I am quite versant in it but even then, the complexity 
of the field made me stumble on some assertions given without explanation.
Then, good amount of omitted words etc necessary to read as coherent English 
sentences. Ultimately, some of the transitions in terms of causality chains do 
not connect and can leave the reader stranded which I'm pointing out in 
specific comments.

Numbered:

1.  document only distincts between p2mp and mp2mp rather than using the PMSI 
terminology with inclusisve/selective [RFC6513]. the S/I is not relevant but it 
would help readability if that would be explained. Especially since the S/I 
starts to be introduced in 2.2.2.1 suddenly.

Zzh> The difference between P2MP and MP2MP is actually not important and not 
the focus of the document. The document starts with P2MP because it is more 
common; it does talk about MP2MP's applicability with some specifics afterwards.

Zzh> Use of per-VPN/BD/ES DCB labels does not work for tunnel segmentation, and 
entire section 2.2.2 is about how we mitigate that. Section 2.2.2.1 explains 
the need for per-PMSI labels using selective tunnels example, and section 
2.2.2.2 extends it to inclusive tunnels.
Zzh> For an average reader, selective/inclusive tunnels are easier to 
understand than S/I-PMSI terms so the sections are based on "tunnels" instead 
of PMSIs, but now I have added additional glossaries and text to tie the two 
together.

2. Terminology
-- provide references for BD/BUM/PMSI/IMET/PTA in terms of RFCs defining them 
properly. Currently the section is just acronym expansion really.
-- provide definition of "aggregate tunnel" in the terminology section rather 
than later in the document for consistency
-- add definitons for "context space", "upstream assigned label" and "ESI 
Label" here as well rather than later in the document. This may lead to more 
conscise and readable introduction section
-- add definition for DCB
-- add def for SRGB with according SRGB

--- I suggest to add upstream assigned (and downstream) labels to definitions 
as well since it's so central to the document. Acronym expansion + RFC ref is 
fine AFAIS but at least the reader can peddle back and know in one shot where 
all the stuff comes from or read things upfront to have an inkling. The 
drip-drip technique uesed in the document is ok'ish since it makes an illusion 
of gradual introduction into the solution space on first read but makes it hard 
to find things later, have in one easy shot a quick recall "what was that all 
about". IME good glossary goes a very long way when attempting a 2nd read or 
trying to do a fast page-in later.
-- given 2.2.2.1 I suggest to add PMSI + S/I + PTA defintions + IMET + RBR. And 
maybe minimum definition (or where to find the terminology precisely) for the 
whole (C-*,C-*) machinery involved in context lookups you pull out in 2.2.2.3

Zzh> I added more terms.
Zzh> I assume most people now just read the electronic copy instead of paper 
copy, so the drip-drip technique should not only work well for gradual 
introduction but also not make it hard to find things later? 😊

3. "but each PE would
   know not to allocate labels from that block for other purposes" is difficult
   to read. Rewrite from negative.

Zzh> I removed it entirely. Sometimes less is more 😊

4. "1000 is for VPN 0, 1001 for VPN 1 ...". Write it clearer, maybe "label 1000 
maps to VPN 0, 1001 to VPN1 and so forth"

Zzh> Fixed as suggested.

5. "
network.  (Though if tunnel
   segmentation [RFC6514] is used, each segmentation regio

Re: [bess] [Rift] comments on draft-head-rift-auto-evpn-00

2021-03-14 Thread Antoni Przygienda 
As Jeff pointed out, the scope is very different. The design team is focused on 
standardizing a solution given things that have been for a bit in the wild to 
“auto-peer” BGP, a useful thing non-withstanding how contrary to the original 
BGP design goals it was 😉

AUTO EVPN targets a different problem where auto-peering is kind of understood 
implicitly from the underlay protocol plus lots other things. It brings 
original L2 simplicity to L2 over L3 again. Based on RIFT (other protocols are 
an open question but there are a lot of things needed for that that RIFT 
already does natively) it provides a absolutely zero config plug-and-play 
underlay and overlay EVPN bring-up of devices plugged together to form an IP 
fabric (well, I’m lying, the top of fabric switches in RIFT still need the knob 
for knowing they’re top-of-fabric).

The draft outlines the architecture pretty well, we have the missing algorithms 
figured out quite precisly by now and stuff works but we simply didn’t have 
time for this IETF to fill them in or include the type-5 IRB details either. 
Next rev 


--- tony

From: Jeff Tantsura 
Date: Sunday, 14 March 2021 at 19:51
To: Gyan Mishra 
Cc: Antoni Przygienda , "r...@ietf.org" , 
"ext-zhang.zh...@zte.com.cn" , "bess@ietf.org" 
, Wen Lin , Jordan Head 
Subject: Re: [bess] [Rift] comments on draft-head-rift-auto-evpn-00

[External Email. Be cautious of content]

Hi Gyan,

It doesn’t and has a very different purpose.
BGP work in IDR is meant to facilitate bringing up BGP peering 
session(discovery/config/etc).
RIFT work is specifically for fabrics that run RIFT as the underlay routing 
protocol and wish to use EVPN for overlay. Auto-evpn facilities bringing up BGP 
sessions with EVPN AFI/SAFI as well as auto deriving EVPN attributes, such as  
EVIs,VRFs, IRB/SVIs and so forth.

Regards,
Jeff


On Mar 13, 2021, at 16:12, Gyan Mishra  wrote:

Tony

In IDR their is an BGP Auto config design team.

Does this auto EVPN used by Rift separate effort from IDR DT below:

1. BGP Autoconf Design Team Report (15 mins)
  
https://tools.ietf.org/html/draft-ietf-idr-bgp-autoconf-considerations/<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-idr-bgp-autoconf-considerations/__;!!NEt6yMaO-gk!Uw8Yz8Ov5eX7PEcvbfAUiGCWHBYNdsMkmwG10bI0xeDOxYRGYhQD_vHcA0uGeQ$>

Kind Regards

Gyan


On Fri, Mar 12, 2021 at 3:06 AM Antoni Przygienda 
mailto:40juniper@dmarc.ietf.org>> wrote:
Sandy, if you want to see it that way, yepp, you can think of one of the things 
AUTO EVPN does as “BGP peer auto-configuration”. This is however just a small 
part of the overall and really just kind of “necessary byproduct”, especially 
since the sessions to RR can go multi-hop so even with bgp single-hop discovery 
BGP couldn’t figure it out itself. (Yes, there was work done previously for RR 
autodiscovery in IGP AFAIR, I don’t think I ever saw it deployed).

--- tony


From: "zhang.zh...@zte.com.cn<mailto:zhang.zh...@zte.com.cn>" 
mailto:zhang.zh...@zte.com.cn>>
Date: Friday, 12 March 2021 at 05:01
To: Antoni Przygienda mailto:p...@juniper.net>>, Jordan Head 
mailto:jh...@juniper.net>>, Wen Lin 
mailto:w...@juniper.net>>
Cc: "r...@ietf.org<mailto:r...@ietf.org>" 
mailto:r...@ietf.org>>, "bess@ietf.org<mailto:bess@ietf.org>" 
mailto:bess@ietf.org>>
Subject: Re:[Rift] comments on draft-head-rift-auto-evpn-00

[External Email. Be cautious of content]


Hi Tony,

Thank you for your response! It's interesting.

So in some sense, the BGP auto discovery can be achieved by RIFT own way, in 
this situration, right?

Please find more comments below with Sandy>.

Best regards,

Sandy
ćŽŸć§‹é‚źä»¶
ć‘ä»¶äșșAntoniPrzygienda
收件äșșïŒšćŒ ćŸ7940;Jordan Head;Wen Lin;
抄送äșșr...@ietf.org<mailto:r...@ietf.org>;bess@ietf.org<mailto:bess@ietf.org>;
æ—„ 期 2021ćčŽ03月10æ—„ 23:45
äž» 鹘 Re: [Rift] comments on draft-head-rift-auto-evpn-00
Hey Sandy, yes, all sessions come up automatically

Yes, all the data is derived automatically just from the today’s RIFT database 
on the leaf or ToF (no key value necessary or any new TIEs, just topology info 
we have today already)
Sandy> Most of the info is topology info, but some may not, such as AS number. 
But I agree with you, it can be a small option to be added in the existed TIE 
or a new TIE.

There is _NO_ information about ToF in the leaves, e’thing is scaling just like 
RIFT does today
Sandy> I have a question, If ToF is RR, does it need to establish BGP peering 
with leaf nodes?

KV 😉 will be just optional for telemetry in case that’s desired & will flow 
northbound only so no change in scaling properties.
Sandy> OK. I understand.

In short:

RR elects itself RR or not in the plane (section 6.3.2.1) and based on that  
assumes a special RR loopback with last byte representing its preference

X::[pref]

Every leaf tries to connect to

X::1
X::2
X::3

Wh

Re: [bess] [Rift] comments on draft-head-rift-auto-evpn-00

2021-03-12 Thread Antoni Przygienda 
Sandy, if you want to see it that way, yepp, you can think of one of the things 
AUTO EVPN does as “BGP peer auto-configuration”. This is however just a small 
part of the overall and really just kind of “necessary byproduct”, especially 
since the sessions to RR can go multi-hop so even with bgp single-hop discovery 
BGP couldn’t figure it out itself. (Yes, there was work done previously for RR 
autodiscovery in IGP AFAIR, I don’t think I ever saw it deployed).

--- tony


From: "zhang.zh...@zte.com.cn" 
Date: Friday, 12 March 2021 at 05:01
To: Antoni Przygienda , Jordan Head , Wen 
Lin 
Cc: "r...@ietf.org" , "bess@ietf.org" 
Subject: Re:[Rift] comments on draft-head-rift-auto-evpn-00

[External Email. Be cautious of content]


Hi Tony,

Thank you for your response! It's interesting.

So in some sense, the BGP auto discovery can be achieved by RIFT own way, in 
this situration, right?

Please find more comments below with Sandy>.

Best regards,

Sandy
ćŽŸć§‹é‚źä»¶
ć‘ä»¶äșșAntoniPrzygienda
收件äșșïŒšćŒ ćŸ7940;Jordan Head;Wen Lin;
抄送äșșr...@ietf.org;bess@ietf.org;
æ—„ 期 2021ćčŽ03月10æ—„ 23:45
äž» 鹘 Re: [Rift] comments on draft-head-rift-auto-evpn-00
Hey Sandy, yes, all sessions come up automatically

Yes, all the data is derived automatically just from the today’s RIFT database 
on the leaf or ToF (no key value necessary or any new TIEs, just topology info 
we have today already)
Sandy> Most of the info is topology info, but some may not, such as AS number. 
But I agree with you, it can be a small option to be added in the existed TIE 
or a new TIE.


There is _NO_ information about ToF in the leaves, e’thing is scaling just like 
RIFT does today
Sandy> I have a question, If ToF is RR, does it need to establish BGP peering 
with leaf nodes?

KV 😉 will be just optional for telemetry in case that’s desired & will flow 
northbound only so no change in scaling properties.
Sandy> OK. I understand.

In short:

RR elects itself RR or not in the plane (section 6.3.2.1) and based on that  
assumes a special RR loopback with last byte representing its preference

X::[pref]

Every leaf tries to connect to

X::1
X::2
X::3

Which they know are RRs (# of RRs doesn’t matter, just pick a reasonable 
constant)

Each leaf elects own loopback in a well known range
Sandy> It's a reasonable design. For multiple RIFT instances, if multiple EVPN 
overlays can be built? Will they use the same well know range loopback address?

Y/64 :: something

On each RR any connection attempt from Y/64:: something is accepted (pretty 
much all mature implemenations today support that). If you want to be 
fastidious you could actually on the ToF that is RR (since it sees all node 
N-TIEs) even specify each leaf as allowed peer
Sandy> Do you mean the RR (ToF) is optional, leaf nodes can build BGP peering 
straightly?

All took a bit to figure out and my first input to the idea when brought to me 
was “well, of course it’s impossible to ZTP EVPN, even with RIFT” 😉 But, with 
enough grey matter grease it actually works pretty well from all we see 


It will all become more concrete when we flesh the algorithm appendix albeit 
the description today already gives a pretty good idea but without standardized 
algorithms for the distributed elections interoperability cannot be guaranteed 

Sandy> Sound great. Looking forward to looking at it.

--- tony

From: "zhang.zh...@zte.com.cn" 
Date: Wednesday, 10 March 2021 at 16:31
To: Antoni Przygienda , Jordan Head , Wen 
Lin 
Cc: "r...@ietf.org" 
Subject: [Rift] comments on draft-head-rift-auto-evpn-00

[External Email. Be cautious of content]


Hi Tony, co-author,

Thank for your presentation in RIFT and BESS WG.

I have question about the intent of this draft, before I read more on the 
detail. :-P

From the draft, seems like the leaf node will build BGP connection 
automatically, and exchange the necessary MAC/IP through EVPN advertisement.

But does the info on leaf for BGP building (AS, router-id, etc.) derived from 
the leaf node itself? If it is, the BGP auto discovery function is included in 
(That is also the confusion from BESS WG).

If the info for BGP building on leaf comes from the TOF nodes (RR), then it has 
no relationship with BGP auto discovery, IMO necessary sourcebound KVs are 
needed. But I am not sure because I have not seen explicit description in the 
draft.

Best regards,

Sandy






Juniper Business Use Only




Juniper Business Use Only
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] [Rift] comments on draft-head-rift-auto-evpn-00

2021-03-10 Thread Antoni Przygienda 
Hey Sandy, yes, all sessions come up automatically

Yes, all the data is derived automatically just from the today’s RIFT database 
on the leaf or ToF (no key value necessary or any new TIEs, just topology info 
we have today already)

There is _NO_ information about ToF in the leaves, e’thing is scaling just like 
RIFT does today

KV 😉 will be just optional for telemetry in case that’s desired & will flow 
northbound only so no change in scaling properties.

In short:

RR elects itself RR or not in the plane (section 6.3.2.1) and based on that  
assumes a special RR loopback with last byte representing its preference

X::[pref]

Every leaf tries to connect to

X::1
X::2
X::3

Which they know are RRs (# of RRs doesn’t matter, just pick a reasonable 
constant)

Each leaf elects own loopback in a well known range

Y/64 :: something

On each RR any connection attempt from Y/64:: something is accepted (pretty 
much all mature implemenations today support that). If you want to be 
fastidious you could actually on the ToF that is RR (since it sees all node 
N-TIEs) even specify each leaf as allowed peer

All took a bit to figure out and my first input to the idea when brought to me 
was “well, of course it’s impossible to ZTP EVPN, even with RIFT” 😉 But, with 
enough grey matter grease it actually works pretty well from all we see 


It will all become more concrete when we flesh the algorithm appendix albeit 
the description today already gives a pretty good idea but without standardized 
algorithms for the distributed elections interoperability cannot be guaranteed 


--- tony

From: "zhang.zh...@zte.com.cn" 
Date: Wednesday, 10 March 2021 at 16:31
To: Antoni Przygienda , Jordan Head , Wen 
Lin 
Cc: "r...@ietf.org" 
Subject: [Rift] comments on draft-head-rift-auto-evpn-00

[External Email. Be cautious of content]


Hi Tony, co-author,

Thank for your presentation in RIFT and BESS WG.

I have question about the intent of this draft, before I read more on the 
detail. :-P

From the draft, seems like the leaf node will build BGP connection 
automatically, and exchange the necessary MAC/IP through EVPN advertisement.

But does the info on leaf for BGP building (AS, router-id, etc.) derived from 
the leaf node itself? If it is, the BGP auto discovery function is included in 
(That is also the confusion from BESS WG).

If the info for BGP building on leaf comes from the TOF nodes (RR), then it has 
no relationship with BGP auto discovery, IMO necessary sourcebound KVs are 
needed. But I am not sure because I have not seen explicit description in the 
draft.

Best regards,

Sandy






Juniper Business Use Only
___
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

2019-11-04 Thread Antoni Przygienda 
No unpublished IPR I’m aware of but Wen’s reply is authoritative for J.

--- tony

From: "slitkows.i...@gmail.com" 
Date: Monday, November 4, 2019 at 5:57 AM
To: "bess@ietf.org" , "draft-ietf-bess-evpn-pref...@ietf.org" 
, Wen Lin , Antoni 
Przygienda 
Subject: RE: WGLC, IPR and implementation poll for draft-ietf-bess-evpn-pref-df

Hi Authors,

The poll is ending soon, and if I’m not mistaken, I’m missing the IPR poll 
replies from Tony P. and Wen L.

Tony, Wen,

Could you please reply to the IPR poll ?

Thanks !


From: slitkows.i...@gmail.com 
Sent: mardi 22 octobre 2019 16:46
To: bess@ietf.org; draft-ietf-bess-evpn-pref...@ietf.org
Cc: bess-cha...@ietf.org
Subject: 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/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-bess-evpn-pref-df/__;!8WoA6RjC81c!RIvKxPDUjv00Z_qc1Y_IkmPuuACdhx3RgCy80lNiKMI0o34sTsroV0Zc179fog$>
[2] 
https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw__;!8WoA6RjC81c!RIvKxPDUjv00Z_qc1Y_IkmPuuACdhx3RgCy80lNiKMI0o34sTsroV0aPkx7W6w$>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Poll for adoption: draft-rabadan-bess-evpn-optimized-ir-02

2016-02-08 Thread Antoni Przygienda 
Support, smart extension to the basic IR ...

thanks 

--- tony
_
"Simple, clear purpose and principles give rise to complex and intelligent 
behavior. Complex rules and regulations give rise to simple and stupid 
behavior." 
--- Dee Hock 

> -Original Message-
> From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Thomas Morin
> Sent: Tuesday, January 26, 2016 12:13 AM
> To: bess@ietf.org
> Cc: draft-rabadan-bess-evpn-optimized...@tools.ietf.org
> Subject: [bess] Poll for adoption: draft-rabadan-bess-evpn-optimized-ir-02
> 
> Hello working group,
> 
> This email starts a two-week poll on adopting
> draft-rabadan-bess-evpn-optimized-ir-02 [1] as a working group item.
> 
> Please send comments to the list and state if you support adoption or not (in
> the later case, please also state the reasons).
> 
> This poll runs until **February 9th**.
> 
> 
> *Coincidentally*, we are also polling for knowledge of any IPR that applies to
> this draft, 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 a document author or contributor please respond
> to this email and indicate whether or not you are aware of any relevant IPR.
> 
> The draft will not be adopted until a response has been received from each
> author and contributor.
> 
> If you are not listed as an author or contributor, then please explicitly
> respond only if you are aware of any IPR that has not yet been disclosed in
> conformance with IETF rules.
> 
> Thank you,
> 
> Martin & Thomas
> bess chairs
> 
> [1] https://tools.ietf.org/html/draft-rabadan-bess-evpn-optimized-ir-02
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess

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

Re: [bess] Call for adoption: draft-snr-bess-evpn-proxy-arp-nd-02

2016-02-05 Thread Antoni Przygienda 
Yes, good one, +1, when matures maybe even a BCP kind of status ?

thanks

--- tony
_
“Simple, clear purpose and principles give rise to complex and intelligent 
behavior. Complex rules and regulations give rise to simple and stupid 
behavior.”
--- Dee Hock

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of thomas.mo...@orange.com
Sent: Friday, February 05, 2016 8:57 AM
To: bess@ietf.org
Cc: draft-snr-bess-evpn-proxy-arp...@ietf.org
Subject: [bess] Call for adoption: draft-snr-bess-evpn-proxy-arp-nd-02


Hello working group,

This email starts a two-week poll on adopting draft-snr-bess-evpn-proxy-arp-nd 
[1] as a working group item.

Please send comments to the list and state if you support adoption or not (in 
the later case, please also state the reasons).

This poll runs until **February 19th**.

*Coincidentally*, we are also polling for knowledge of any IPR that applies to 
this draft, 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 a document author or contributor please respond to 
this email and indicate whether or not you are aware of any relevant IPR.

The draft will not be adopted until a response has been received from each 
author and contributor.

If you are not listed as an author or contributor, then please explicitly 
respond only if you are aware of any IPR that has not yet been disclosed in 
conformance with IETF rules.

Thank you,

Martin & Thomas
bess chairs

[1] https://tools.ietf.org/html/draft-snr-bess-evpn-proxy-arp-nd-02

_



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] Regd. DF Election Notes

2016-01-25 Thread Antoni Przygienda 
support as well (as co-author), no IPR I’m aware of

thanks

--- tony
_
“Simple, clear purpose and principles give rise to complex and intelligent 
behavior. Complex rules and regulations give rise to simple and stupid 
behavior.”
--- Dee Hock

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Henderickx, Wim (Nokia - 
BE)
Sent: Sunday, January 24, 2016 6:47 AM
To: bess@ietf.org
Subject: Re: [bess] Regd. DF Election Notes

Support, since this enhances the DF election for EVPN

On 1/11/16, 1:07 AM, "BESS on behalf of Martin Vigoureux" 
mailto:bess-boun...@ietf.org> on behalf of 
martin.vigour...@alcatel-lucent.com>
 wrote:

Hello working group,

This email starts a two-week poll on adopting
draft-mohanty-bess-evpn-df-election-02 [1] as a working group item.

Please state on the list if you support adoption or not (in the both
cases, please also state the reasons).

This poll runs until *the 25th of January*.

Currently no IPR has been disclosed against this document.

*Coincidentally*, we are also polling for knowledge of any IPR that
applies to this draft, 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 a document author or contributor please
respond to this email and indicate whether or not you are aware of any
relevant IPR.

The draft will not be adopted until a response has been received from
each author and contributor.

If you are not listed as an author or contributor, then please
explicitly respond only if you are aware of any IPR that has not yet
been disclosed in conformance with IETF rules.

Thank you,

Martin & Thomas
bess chairs

[1] https://datatracker.ietf.org/doc/draft-mohanty-bess-evpn-df-election/

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

From: "Henderickx, Wim (Wim)" 
mailto:wim.henderi...@alcatel-lucent.com>>
Date: Saturday, July 25, 2015 at 10:28 PM
To: smohanty mohanty mailto:satya...@cisco.com>>
Subject: Re: Regd. DF Election Notes

Here you go

From: "Satya Mohanty (satyamoh)"
Date: Sunday 26 July 2015 08:07
To: Wim Henderickx
Subject: Regd. DF Election Notes

Hi Wim,

Good to talk to you at the airport.
I am following up on the request to please send me the writeup regarding the 
various service models sec 6.1 – 6.3.
About 2-3 years back you had circulated such a dic.
Best would be if you’ve examples.

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

Re: [bess] Poll for adoption: draft-mohanty-bess-evpn-df-election-02

2016-01-12 Thread Antoni Przygienda 
Not aware of any IPR ... 

thanks 

--- tony
_
“Simple, clear purpose and principles give rise to complex and intelligent 
behavior. Complex rules and regulations give rise to simple and stupid 
behavior.” 
--- Dee Hock 


> -Original Message-
> From: Keyur Patel (keyupate) [mailto:keyup...@cisco.com]
> Sent: Tuesday, January 12, 2016 8:54 AM
> To: Keyur Patel (keyupate); Satya Mohanty (satyamoh); Martin Vigoureux;
> bess@ietf.org
> Cc: draft-mohanty-bess-evpn-df-elect...@tools.ietf.org
> Subject: Re: [bess] Poll for adoption: draft-mohanty-bess-evpn-df-election-02
> 
> Not aware of any IPR that hasnÂčt already been disclosed.
> 
> 
> On 1/12/16, 10:19 AM, "Keyur Patel (keyupate)" 
> wrote:
> 
> >Support as a co-author.
> >
> >Regards,
> >Keyur
> >
> >On 1/12/16, 8:53 AM, "Satya Mohanty (satyamoh)" 
> >wrote:
> >
> >>Support as co-author.
> >>
> >>Thanks,
> >>â€čSatya
> >>
> >>On 1/11/16, 1:07 AM, "BESS on behalf of Martin Vigoureux"
> >> >>martin.vigour...@alcatel-lucent.com>
> >>wrote:
> >>
> >>>Hello working group,
> >>>
> >>>This email starts a two-week poll on adopting
> >>>draft-mohanty-bess-evpn-df-election-02 [1] as a working group item.
> >>>
> >>>Please state on the list if you support adoption or not (in the both
> >>>cases, please also state the reasons).
> >>>
> >>>This poll runs until *the 25th of January*.
> >>>
> >>>Currently no IPR has been disclosed against this document.
> >>>
> >>>*Coincidentally*, we are also polling for knowledge of any IPR that
> >>>applies to this draft, 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 a document author or contributor please
> >>>respond to this email and indicate whether or not you are aware of
> >>>any relevant IPR.
> >>>
> >>>The draft will not be adopted until a response has been received from
> >>>each author and contributor.
> >>>
> >>>If you are not listed as an author or contributor, then please
> >>>explicitly respond only if you are aware of any IPR that has not yet
> >>>been disclosed in conformance with IETF rules.
> >>>
> >>>Thank you,
> >>>
> >>>Martin & Thomas
> >>>bess chairs
> >>>
> >>>[1]
> >>>https://datatracker.ietf.org/doc/draft-mohanty-bess-evpn-df-election/
> >>>
> >>>___
> >>>BESS mailing list
> >>>BESS@ietf.org
> >>>https://www.ietf.org/mailman/listinfo/bess
> >>
> >

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

Re: [bess] Poll for adoption: draft-mohanty-bess-evpn-df-election-02

2016-01-11 Thread Antoni Przygienda 
Support as co-author

thanks 

--- tony
_
"Simple, clear purpose and principles give rise to complex and intelligent 
behavior. Complex rules and regulations give rise to simple and stupid 
behavior." 
--- Dee Hock 


> -Original Message-
> From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of RABADAN, Jorge
> (Jorge)
> Sent: Monday, January 11, 2016 4:02 PM
> To: VIGOUREUX, Martin (Martin); bess@ietf.org
> Cc: draft-mohanty-bess-evpn-df-elect...@tools.ietf.org
> Subject: Re: [bess] Poll for adoption: draft-mohanty-bess-evpn-df-election-02
> 
> I support this document for WG adoption.
> It is an important optimization to the RFC7432 DF election and the base for
> future work.
> 
> 
> 
> Thanks.
> Jorge
> 
> 
> On 1/11/16, 1:07 AM, "BESS on behalf of Martin Vigoureux"  boun...@ietf.org on behalf of martin.vigour...@alcatel-lucent.com> wrote:
> 
> >Hello working group,
> >
> >This email starts a two-week poll on adopting
> >draft-mohanty-bess-evpn-df-election-02 [1] as a working group item.
> >
> >Please state on the list if you support adoption or not (in the both
> >cases, please also state the reasons).
> >
> >This poll runs until *the 25th of January*.
> >
> >Currently no IPR has been disclosed against this document.
> >
> >*Coincidentally*, we are also polling for knowledge of any IPR that
> >applies to this draft, 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 a document author or contributor please
> >respond to this email and indicate whether or not you are aware of any
> >relevant IPR.
> >
> >The draft will not be adopted until a response has been received from
> >each author and contributor.
> >
> >If you are not listed as an author or contributor, then please
> >explicitly respond only if you are aware of any IPR that has not yet
> >been disclosed in conformance with IETF rules.
> >
> >Thank you,
> >
> >Martin & Thomas
> >bess chairs
> >
> >[1]
> >https://datatracker.ietf.org/doc/draft-mohanty-bess-evpn-df-election/
> >
> >___
> >BESS mailing list
> >BESS@ietf.org
> >https://www.ietf.org/mailman/listinfo/bess
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess

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

Re: [bess] Introducing a one-implementation requirement before WG last calls

2015-12-14 Thread Antoni Przygienda 
If that's what can be agreed on, I'm for it ... That puts at least something in 
terms of reality check between things being paper and going into STD tracks ... 
 

thanks 

--- tony
_
"Simple, clear purpose and principles give rise to complex and intelligent 
behavior. Complex rules and regulations give rise to simple and stupid 
behavior." 
--- Dee Hock 


> -Original Message-
> From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Martin Vigoureux
> Sent: Monday, December 14, 2015 1:29 AM
> To: bess@ietf.org
> Subject: Re: [bess] Introducing a one-implementation requirement before
> WG last calls
> 
> WG,
> 
> we have reviewed the different comments posted on the list in response to
> our initial proposal.
> After thinking further about that, we'd like to propose the following as a way
> forward:
> 
> At the same time we issue a Working Group Last Call we would ask for
> knowledge of existing implementations, and the more details provided at
> that time, the better.
> In the situation where an implementation would exist we would proceed
> with submission to IESG.
> In the opposite situation (no implementation exists), we would systematically
> ask the WG for reasoned opinions regarding whether we should nevertheless
> proceed with submission to IESG.
> We will gauge consensus on that aspect. In case consensus is in favour of
> proceeding with submission to IESG we will do so. In the opposite case, we
> will put the document in a "Waiting for implementation" state until
> information on an existing implementation is brought to our knowledge or of
> the WG.
> 
> Please share your views on that.
> 
> Thank you
> 
> M&T
> 
> 
> Le 24/11/2015 10:03, Thomas Morin a Ă©crit :
> > Hello everyone,
> >
> > Following the positive feedback received during BESS meeting in
> > Yokohama about introducing a one-implementation requirement in BESS,
> > we propose to do the following for future WG last calls:
> >
> > As a prerequisite before doing a working group last call on a
> > document, the chairs will ask the working group for known
> > implementations of the specifications; a relatively detailed level of
> > information will be required (e.g. "release x.y of solution z shipping
> > date d", "all features implemented", "partial implementation only",
> > etc.) and everyone will be invited to reply (not only co-authors of
> > the specifications); the chairs will then do the working group last
> > call if satisfying information was provided on at least one implementation.
> >
> > We are open for comments on this proposal until December 7th.
> >
> > Martin & Thomas
> >
> > ___
> > BESS mailing list
> > BESS@ietf.org
> > https://www.ietf.org/mailman/listinfo/bess
> >
> >
> 
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess

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

Re: [bess] Introducing a one-implementation requirement before WG last calls

2015-11-24 Thread Antoni Przygienda 
+1  (I don't mean make it 1+1=2 implementations, I just say it's a very good 
new [and old ;-) ] idea ;-) 

thanks 

--- tony
_
"Simple, clear purpose and principles give rise to complex and intelligent 
behavior. Complex rules and regulations give rise to simple and stupid 
behavior." 
--- Dee Hock 


> -Original Message-
> From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Thomas Morin
> Sent: Tuesday, November 24, 2015 1:03 AM
> To: BESS
> Subject: [bess] Introducing a one-implementation requirement before WG
> last calls
> 
> Hello everyone,
> 
> Following the positive feedback received during BESS meeting in Yokohama
> about introducing a one-implementation requirement in BESS, we propose to
> do the following for future WG last calls:
> 
> As a prerequisite before doing a working group last call on a document, the
> chairs will ask the working group for known implementations of the
> specifications; a relatively detailed level of information will be required 
> (e.g.
> "release x.y of solution z shipping date d", "all features implemented",
> "partial implementation only", etc.) and everyone will be invited to reply 
> (not
> only co-authors of the specifications); the chairs will then do the working
> group last call if satisfying information was provided on at least one
> implementation.
> 
> We are open for comments on this proposal until December 7th.
> 
> Martin & Thomas
> 
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess

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

Re: [bess] REG: draft-mohanty-bess-evpn-df-election-02

2015-11-23 Thread Antoni Przygienda 

[Satya] Yes, New PE needs to wait for 3 sec. According to RFC 7438, the 
receiving PEs also need to wait for 3 secs. But, ideally, a PE that is going 
from DF to non-DF or non-DF to non-DF should become the non-DF rightaway. Only 
the PE that is going DF really needs to wait for 3 secs. This is not explicitly 
spelled out in the draft but we are thinking along these lines.

Sudhin>> you are correct Satya but how to deal with traffic for 3 seconds when 
a new type 4 route comes. DF election kicks in and all PE's, For 3 seconds how 
to deal with traffic, the state machines need to be updated like blocking 
traffic or forwarding. if during that time the traffic is forwarded then a loop 
will be created. the EVPN RFC says SH label and BUM drop after the election, 
but correct me if I am totally wrong during the transition how to deal is not 
covered.I request your valid input on this. How to deal in that situation,what 
is the state of PE's during 3 seconds period.How to reach a consensus between 
vendors. Say for example vendors design custom solution to handle this, then 
how the inter op between vendors will not work.
[Tony saiz:] The FSM clarifies that. No DF is given up on arrival of new ES 
routes.


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

Re: [bess] Poll for adoption: draft-sajassi-bess-evpn-etree

2015-06-01 Thread Antoni Przygienda 
Support 

-- tony 

There are basically two types of people. People who accomplish things, and 
people who claim to have accomplished things. The first group is less crowded.
~~~ Mark Twain


> -Original Message-
> From: Wen Lin [mailto:w...@juniper.net]
> Sent: Wednesday, May 27, 2015 1:51 PM
> To: bess@ietf.org
> Subject: Re: [bess] Poll for adoption: draft-sajassi-bess-evpn-etree
> 
> Support.
> 
> Wen
> 

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

Re: [bess] ARP ND draft

2015-03-31 Thread Antoni Przygienda 
> [JORGE] 2 ACs on the same ESI/EVI on the same PE? I suppose to are talking
> about VLAN-aware bundle interfaces, where each VLAN goes to a different BD?
> note that the proxy-arp/nd function is per broadcast domain, i.e. one per EVI 
> for
> VLAN-based and VLAN-bundle and one per BD for VLAN-aware bundle
> interfaces. We can clarify that in the draft.

 [Tony saiz:]  same EVI/ESI/VLAN which for me indicates that the two ACs belong 
to the same customer and are same  ether. very small nitpick, probably not 
worth mentioning ;-) 

> 
> 
> >
> >Small observation for 4.3:  enabling the send-refresh option is a
> >dangerous thing. It's not only they may keep up active entries in the
> >fast-path forever (since there is always some traffic generated by the
> >'probes'), it's also that the IP/MAC binding 'kept up' even if there is
> >no traffic is sitting in all PEs as RT-2.  The section talks about
> >advantages, maybe it deserves a sentence to point out the dangers of
> >such behavior.
> 
> [JORGE] send-fresh is optional and should be enabled/disabled depending on the
> use-case. The purpose is in fact keep local IP->MAC bindings active and make
> sure they are still valid before withdrawing the RT2s. It can also help 
> keeping
> active not only the proxy entry but also the MAC-VRF entry. If the user wants 
> to
> rely purely on the age-time, that should be allowed. Not sure why this is a
> danger?

 [Tony saiz:]  because disabling aging will basically accumulate more and more 
state in fwd path even if the src/dst pairs don't talk to each other anymore. 
In your customer's scenario that's what's needed, in e.g. sparse, large scale 
EVPN deployments in backbone it's probably not what a carrier would be excited 
about given PE state is expensive.

> >
> >[Tony saiz:]   as I wrote in other email, the problem is if the first
> >route goes, the second should be honored IMO. It seems to me we have
> >this very case BTW with the aliased default gateways?
> 
> [JORGE] Yes, if the first route is withdrawn (IP1->M1), the second
> (IP1->M2) will be now installed in the proxy-arp/nd table. As long as the BGP
> route is kept we are good. A different thing is anycast, in which case
> IP1->M1 and IP1->M2 are both valid at the same time. We will tackle this
> in the next rev.
> 

 [Tony saiz:]  I agree with that (i.e. the 2nd best BGP route is GARP'ed).  The 
anycast in ipv4 is a rare animal from the sightings I had so I'm only concered 
about the 'aliased default GW' case I guess. 

> >
> >> >>
> >> >> d)eVPN draft does not explain anything about possibility to snoop
> >> >> @ DHCP
> >>
> >> [JORGE] do you mean in the proxy-arp/nd draft or in the base spec?
> >> In the proxy-arp/nd only ARP/ND messages are used. DHCP is not always
> >>there.
> >> Not there in the IXP use-case anyway.
> >
> > [Tony saiz:]  agreed,  I just read the draft in wider scope than just
> >IXP and that's why I'm asking.
> 
> [JORGE] IMHO focusing on learning arp/nd for the time being is simpler, and 
> it is
> really what we want to keep under control to reduce flooding.
> But we can discuss.

 [Tony saiz:]  agreed. Maybe one sentence placeholder like "DHCP and other 
strange fruit can be snooped beside to learn the IP/MAC bindings" ;-) 


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

Re: [bess] ARP ND draft

2015-03-31 Thread Antoni Przygienda 
The challenge for IPv4 is that I don’t see an easy way to learn dynamically 
from access attachment circuits that a given ipv4 is anycast. Even for default 
gateways, if they are integrated in the EVPN PE, we are good, but if they are 
external and connected to a MAC-VRF, it is not so clear how to learn that 
(unless you learn those entries from the management interface).
[Tony saiz:] agreed

One of the reasons why we have lots of “SHOULDs” in the draft and not “MUST” is 
because the implementation has to be flexible enough to be configured in a 
different way depending on the use-case, which is one of the points that Tony 
mentions below. In the use-case described at the moment there is no anycast and 
duplicate IP detection is very important. We will add the DC use case in the 
next rev as suggested by Robert and others.

[Tony saiz:] agreed.

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

Re: [bess] ARP ND draft

2015-03-30 Thread Antoni Przygienda 
Hey Jorge, I read your draft again in a larger context than simple 
'informational how IXP network runs eVPN ARP stuff'.  Generally I think it 
should be extended beyond 'some customer's use case' and provide BCP or 
'implementation recommendations' or some such thing for the generic issue of 
snooping ARP/ND/DHCP/others to reduce the amount of BU_ traffic across the PEs. 
 ARP/DHCP/ND snooping is a delicate functionality that is vastly underspecified 
in eVPN base and is essential for a good eVPN implementation (i.e. robust, 
interoperable & scalable) IMO. 

Thanks for sharing all this experience BTW, insightful read that enlightened 
bunch of corner cases I didn't think through. 

Comments inline 

> >> a)It is worth explaining what flavor of ARP proxy eVPN implements.
> >> ‘proxy ARP’ I found out has different flavors including e.g. the
> >> router responding with its own MAC to requests representing remote
> >> hosts. Customers & other folks are easily confused by the overloaded
> >> ‘proxy ARP’ term in eVPN context.
> >>
> >Yes, that is a part that is underspecified for EVPN. I assume that the
> >response would include the MAC address of the CE instead of the
> >router's own MAC address.
> 
> [JORGE] From draft-snr-bess-evpn-proxy-arp-nd-00:
> 
> 4.2 Reply sub-function
> 
> ...
> 
>a) When replying to ARP Request or NS messages, the PE SHOULD use the
>   Proxy-ARP/ND entry MAC address as MAC SA. This is recommended so
>   that the resolved MAC can be learnt in the MAC FIB of potential
>   Layer-2 switches seating between the PE and the CE requesting the
>   Address Resolution.

 [Tony saiz:]  agreed. I cannot imagine why it's NOT a MUST (except default GW 
cases where it makes sense e.g. in case of aliased case to resolve GW IP 
request). 

Small observation for 4.2b)  If we want to be double-perfect we should actually 
 not even respond if we have 2 ACs on the same ESI on the same PE ;-)  

Small observation for 4.3:  enabling the send-refresh option is a dangerous 
thing. It's not only they may keep up active entries in the fast-path forever 
(since there is always some traffic generated by the 'probes'), it's also that 
the IP/MAC binding 'kept up' even if there is no traffic is sitting in all PEs 
as RT-2.  The section talks about advantages, maybe it deserves a sentence to 
point out the dangers of such behavior. 

> >> b)It is worth explaining what is suggested behavior if eVPN
> >> advertises the same IP with multiple MACs and what happens when e.g.
> >> the served MAC vanishes
> >>
> >Doesn't the EVPN RFC already stating that the routes would be withdrawn
> >in that case?
> 
> [JORGE] Based on our current version, the IP is unique in a PE’s proxy-ARP 
> table,
> so if a PE receives 2 RT-2s for the same IP different MAC, only one
> IP->MAC binding will be picked up.

[Tony saiz:]   as I wrote in other email, the problem is if the first route 
goes, the second should be honored IMO. It seems to me we have this very case 
BTW with the aliased default gateways?

> >>
> >> c)It is worth explaining what the suggested behavior should be when
> >> ‘local-bit’ MACs are being advertised from remotes (and when those
> >> collide)
> >>
> >Does L2VPN handle that in any interesting way? I don't think EVPN
> >introduces any new failure modes for duplicate MAC addresses.
> 
> [JORGE] indeed, this draft does not introduce any new way to handle MAC
> addresses in the MAC-VRFs. EVPN has a MAC duplication mechanism, there is
> nothing else afaik.

 [Tony saiz:]  agreed. 

> >>
> >> d)eVPN draft does not explain anything about possibility to snoop @
> >> DHCP
> 
> [JORGE] do you mean in the proxy-arp/nd draft or in the base spec?
> In the proxy-arp/nd only ARP/ND messages are used. DHCP is not always there.
> Not there in the IXP use-case anyway.

 [Tony saiz:]  agreed,  I just read the draft in wider scope than just IXP and 
that's why I'm asking.  

One could even talk about initially snooping  IP frames directly in case eVPN 
"attaches" to an already running bridge and snoops already active IP traffic to 
learn IP/MAC bindings from bridge ports. Probably hypothetical only  ;-) 

-- tony 

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

Re: [bess] ARP ND draft

2015-03-30 Thread Antoni Przygienda 
I’m also skeptical whether IP duplicate detection would be a good default 
thing. Especially in case of what I call ‘aliased default gateway’ which 
section 10.1 specifically allows, i.e. default GW IP address is same but each 
PE may use a different MAC when advertising it and consequently responses for 
same IP with different ARPs may be seen in the network.  Yes, default GW 
ExtComm is there to differentiate so it can be called an exception but 
nevertheless.

I also thought a tad about VRRP but I think the IP duplicate detection will not 
apply there, it’s all same IPx->MACx from all routers so if anything, it’s more 
of a MAC move thing.

Generally I think someone who wants a secure, stable eVPN wants IP duplicate 
detection, someone who runs a very dynamic network with tons gateways, possibly 
anycast & floating IPs will probably not be too enamored with it.

Thanks

--- tony

There are basically two types of people. People who accomplish things, and 
people who claim to have accomplished things. The first group is less 
crowded.<http://www.brainyquote.com/quotes/quotes/m/marktwain393535.html>
~~~ Mark Twain<http://www.brainyquote.com/quotes/quotes/m/marktwain393535.html>

From: rras...@gmail.com [mailto:rras...@gmail.com] On Behalf Of Robert Raszuk
Sent: Monday, March 30, 2015 1:19 AM
To: Henderickx, Wim (Wim)
Cc: Erik Nordmark; Antoni Przygienda; bess@ietf.org; Rabadan, Jorge (Jorge)
Subject: Re: [bess] ARP ND draft

Hi Wim,

> There is anycast at IPv4 level for sure but I am not ware this is supported 
> at arp level.

Precisely right. It needs to be documented and addressed if anyone is up to 
proposing automated IP duplicate address detection and disabling.

RFC1546 is rather too old to consider here as solution :)

Cheers,
R.


On Mon, Mar 30, 2015 at 1:10 AM, Henderickx, Wim (Wim) 
mailto:wim.henderi...@alcatel-lucent.com>> 
wrote:
To be clear: RFC4861 section 7.2.7 explains the anycast behaviour in IPv6.
I am not aware of such thing at IPv4/ARP level. Do you have a pointer?
There is anycast at IPv4 level for sure but I am not ware this is supported at 
arp level.

From: , Wim Henderickx
Date: Monday 30 March 2015 07:38
To: Robert Raszuk
Cc: Erik Nordmark, Antoni Przygienda, "bess@ietf.org<mailto:bess@ietf.org>", 
Jorge Rabadan

Subject: Re: [bess] ARP ND draft

At interface level you get dad in most stacks I know.

Sent from my iPhone

On 30 Mar 2015, at 06:45, Robert Raszuk 
mailto:rob...@raszuk.net>> wrote:
Hi Wim,

What makes you say that in IPv4 there is no anycast ? All anycase I have played 
so far is IPv4 :)

Cheers,
r.

On Sun, Mar 29, 2015 at 11:18 PM, Henderickx, Wim (Wim) 
mailto:wim.henderi...@alcatel-lucent.com>> 
wrote:
We will update the draft to highlight the IPv6 anycast behaviour better as 
pointed out by RObert. In IPv4 there is no anycast behaviour and as such there 
should be one option possible.



On 30/03/15 04:59, "Antoni Przygienda" 
mailto:antoni.przygie...@ericsson.com>> wrote:

>Yes, but of course I brought it up to show that 'the last one simply wins' as 
>suggested by the draft is not enough IMO. A good architecture should probably 
>keep track of what it served as answer and when the answer is invalid or a 
>new, better one exists, provide a GARP.
>
>As well, when PE2 sends a newer MAC it may not be a good strategy to serve a 
>GARP if PE1's MAC has already been offered. That could lead IMO to e.g. 
>gateway chasing problems.
>
>--- tony
>
>
>There are basically two types of people. People who accomplish things, and 
>people who claim to have accomplished things. The first group is less crowded.
>~~~ Mark Twain
>
>
>> -Original Message-
>> From: Henderickx, Wim (Wim) 
>> [mailto:wim.henderi...@alcatel-lucent.com<mailto:wim.henderi...@alcatel-lucent.com>]
>> Sent: Thursday, March 26, 2015 6:01 AM
>> To: Antoni Przygienda; Erik Nordmark; Rabadan, Jorge (Jorge)
>> Cc: bess@ietf.org<mailto:bess@ietf.org>
>> Subject: Re: [bess] ARP ND draft
>>
>> For this case you should sent a GARP with the new MAC/IP
>>
>>
>>
>>
>> On 25/03/15 18:56, "Antoni Przygienda" 
>> mailto:antoni.przygie...@ericsson.com>>
>> wrote:
>>
>> >> > b)It is worth explaining what is suggested behavior if eVPN
>> >> > advertises the same IP with multiple MACs and what happens when
>> >> > e.g. the served MAC vanishes
>> >> >
>> >> Doesn't the EVPN RFC already stating that the routes would be
>> >> withdrawn in that case?
>> >
>> >The scenario I had in mind was when eVPN PE receives
>> >
>> >From PE2  IP1/M1  and  later
>> >From PE3  IP1/M2
>> >
>> >while having answered wi

Re: [bess] ARP ND draft

2015-03-29 Thread Antoni Przygienda 
Yes, but of course I brought it up to show that 'the last one simply wins' as 
suggested by the draft is not enough IMO. A good architecture should probably 
keep track of what it served as answer and when the answer is invalid or a new, 
better one exists, provide a GARP. 

As well, when PE2 sends a newer MAC it may not be a good strategy to serve a 
GARP if PE1's MAC has already been offered. That could lead IMO to e.g. gateway 
chasing problems. 

--- tony 


There are basically two types of people. People who accomplish things, and 
people who claim to have accomplished things. The first group is less crowded.
~~~ Mark Twain


> -Original Message-
> From: Henderickx, Wim (Wim) [mailto:wim.henderi...@alcatel-lucent.com]
> Sent: Thursday, March 26, 2015 6:01 AM
> To: Antoni Przygienda; Erik Nordmark; Rabadan, Jorge (Jorge)
> Cc: bess@ietf.org
> Subject: Re: [bess] ARP ND draft
> 
> For this case you should sent a GARP with the new MAC/IP
> 
> 
> 
> 
> On 25/03/15 18:56, "Antoni Przygienda" 
> wrote:
> 
> >> > b)It is worth explaining what is suggested behavior if eVPN
> >> > advertises the same IP with multiple MACs and what happens when
> >> > e.g. the served MAC vanishes
> >> >
> >> Doesn't the EVPN RFC already stating that the routes would be
> >> withdrawn in that case?
> >
> >The scenario I had in mind was when eVPN PE receives
> >
> >From PE2  IP1/M1  and  later
> >From PE3  IP1/M2
> >
> >while having answered with IP1/M1 per proxy alrady. Additionally, in
> >such situation ends up seeing
> >
> >From PE2   IP1/
> >
> >So the answer it gave is not valid anymore all of a sudden.
> >
> >--- tony
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] ARP ND draft

2015-03-25 Thread Antoni Przygienda 
> > b)It is worth explaining what is suggested behavior if eVPN advertises
> > the same IP with multiple MACs and what happens when e.g. the served
> > MAC vanishes
> >
> Doesn't the EVPN RFC already stating that the routes would be withdrawn in
> that case?

The scenario I had in mind was when eVPN PE receives 

>From PE2  IP1/M1  and  later
>From PE3  IP1/M2

while having answered with IP1/M1 per proxy alrady. Additionally, in such 
situation ends up seeing

>From PE2   IP1/

So the answer it gave is not valid anymore all of a sudden.

--- tony 

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

[bess] ARP ND draft

2015-03-25 Thread Antoni Przygienda 
Watching the presentation in the group and instead crowding the mike here are 
my comments:


a)  It is worth explaining what flavor of ARP proxy eVPN implements. 'proxy 
ARP' I found out has different flavors including e.g. the router responding 
with its own MAC to requests representing remote hosts. Customers & other folks 
are easily confused by the overloaded 'proxy ARP' term in eVPN context.

b)  It is worth explaining what is suggested behavior if eVPN advertises 
the same IP with multiple MACs and what happens when e.g. the served MAC 
vanishes

c)  It is worth explaining what the suggested behavior should be when 
'local-bit' MACs are being advertised from remotes (and when those collide)

d)  eVPN draft does not explain anything about possibility to snoop @ DHCP

e)  the IP duplicate detection is an interesting thing given the 
anycast/multicast and other zoo

--- tony

There are basically two types of people. People who accomplish things, and 
people who claim to have accomplished things. The first group is less 
crowded.
~~~ Mark Twain

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

Re: [bess] suggested AUTH48 changes on EVPN draft

2015-02-02 Thread Antoni Przygienda 
John, understood clearer now. As far I thought that through it may be an 
unnecessary restriction but I see the 'uniformity' argument.

My (now tad unrelated to this) question as what ETAG the IMET carries still 
stands (albeit the way I outlined it seems the only logical way to advertise 
multiple ETAGs on an IMET)

--- tony

From: John E Drake [mailto:jdr...@juniper.net]
Sent: Monday, February 02, 2015 5:37 AM
To: Antoni Przygienda; bess@ietf.org
Subject: RE: suggested AUTH48 changes on EVPN draft

Tony,

The change you mention in your email below is editorial, clarifying what was 
already supported in the encodings but not explicitly described.

The technical change is in the last paragraph and deals w/ VLAN Aware Bundle 
service w/ VID translation.  Previously the ingress PE translated from ingress 
VID to Ethernet Tag and the egress PE translated from Ethernet Tag to egress 
VID.  The change is that the ingress PE does not translate but rather sends the 
ingress VID and the egress translates from ingress VID to egress VID.  This is 
makes the data plane behavior consistent across all services and both MPLS and 
VXLAN encapsulations.  It requires the egress PE to advertise an MPLS label w/ 
a granularity of at least [EVI, broadcast domain].

Yours Irrespectively,

John

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Antoni Przygienda
Sent: Monday, February 02, 2015 1:50 AM
To: bess@ietf.org<mailto:bess@ietf.org>
Subject: [bess] suggested AUTH48 changes on EVPN draft

Having seen Adrian's email on the suggested changes (mux'ing VLANs on the same 
IMET) here's a nit-pic _or_  a clarifying question depending how one sees it:

Let me see whether I parse it correctly:

a)  we are talking about BUM P-Tunnels

b)  the text clarifies that multiple VLANs can be mux'ed onto same P-Tunnel

c)   The rule that multiple EVIs can be mux'ed onto a P-tunnel in case of 
p2mp per 16.2.1 still stands.


My question would be: What is the ETAG is multiple VLANs are multiplexed onto a 
P-Tunnel. I assume it's max-ET?  I assume that the choice (each VLAN distinct 
or all VLANs on same P-Tunnel) is a binary decision; otherwise we'd have to 
deal with the situation where we advertise for an EVI 1

EVI1;ETAG=MAX-ET,  PMSI1
EVI1; ETAG=100, PMSI1'

with the semantics of "all VLANs _except_ 100".  Probably not intended.

As well, I was always lost how ETAG can be used once multiple EVIs are mux'ed 
onto a P-tunnel.  It would mean "VLAN 100 for EVI1 _and_ EVI2" which does not 
seem particularly useful.


*  tony

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

[bess] suggested AUTH48 changes on EVPN draft

2015-02-01 Thread Antoni Przygienda 
Having seen Adrian's email on the suggested changes (mux'ing VLANs on the same 
IMET) here's a nit-pic _or_  a clarifying question depending how one sees it:

Let me see whether I parse it correctly:

a)  we are talking about BUM P-Tunnels

b)  the text clarifies that multiple VLANs can be mux'ed onto same P-Tunnel

c)  The rule that multiple EVIs can be mux'ed onto a P-tunnel in case of 
p2mp per 16.2.1 still stands.


My question would be: What is the ETAG is multiple VLANs are multiplexed onto a 
P-Tunnel. I assume it's max-ET?  I assume that the choice (each VLAN distinct 
or all VLANs on same P-Tunnel) is a binary decision; otherwise we'd have to 
deal with the situation where we advertise for an EVI 1

EVI1;ETAG=MAX-ET,  PMSI1
EVI1; ETAG=100, PMSI1'

with the semantics of "all VLANs _except_ 100".  Probably not intended.

As well, I was always lost how ETAG can be used once multiple EVIs are mux'ed 
onto a P-tunnel.  It would mean "VLAN 100 for EVI1 _and_ EVI2" which does not 
seem particularly useful.


n  tony

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

Re: [bess] Tunnel question for ESI next-hop in draft evpn prefix-advert

2015-01-14 Thread Antoni Przygienda 
Jorge, reread the -03, don’t know how I ended up working off and commenting on 
-02, too many context changes here I guess. inline



What do you mean by “and the corresponding tunnel information” for ESI next-hop 
for type-5 in the vxLAN case?


a)  I don’t see how vxLAN will work with that since at least a Router MAC’s 
extended comm is needed in such a case, section 5.4 (4) describing how to 
derive the inner MAC is fuzzy, we cannot look-up the VRF ARP table since NVE2 
has no overlay IP address and ‘EVI-10 FDB table’ is something I don’t 
understand and I don’t think has been defined. The alleged M2 to be used does 
not exist in the figure at all.

We can clarify that section for sure. The idea is that the RT5 in this case 
requires a recursive lookup resolution to the information given by the RT1. The 
tunnel information (destination VTEP, VNI) comes from the RT1. In this use-case 
we want to direct the encapsulated frames to the owner of the active ESI. 
EVI-10 FDB should be replaced by MAC-VRF10 FDB in DCW1/2, we can fix that. In 
the MAC-VRF you could find M2 since it is associated to the ESI23 (NVE2/3 
advertise TS2/3 MACs with ESI23).

[Tony said]  the idea is completely clear to me (and commendable).  I got what 
you say but Figure 5 is missing M2 and M3 in it and maybe a sentence saying to 
be perfectly clear that NVE2 announces M2  type-2 (without IP address 
obviously).  The text still implies an impossible lookup to me. ARP table needs 
IP addresses for NVE2/NVE3, there is no such thing as ESI23<->M2 entry so it’s 
some kind of a completely new beast which I need to think through. I think 
calling it ‘ARP lookup or EVI-10 MACVRF’ is implying magic in this case.

[JORGE] that’s fair. Will clarify that after the call for adoption.

[Tony said]   yes, -03 clearly indicates that encapsualtion extcomm is on 
type-1 now as well. thanks.  However, I still think that


1.  we need M2 over NVE2 in the figure

2.  I would prefer the router MAC extcomm on type-1 in such case since the 
lookup ESI23 to M2 implies new magic not present in other drafts. Adding the 
router MAC extcomm would make it completely analogous to the inter-subnet draft 
cases IMO. And if the ESI to MAC lookup is desired, the example should at least 
describe that NVE2 is advertising an RT-2 with the M2 MAC.







b)  the “tunnel information” provided by A-D route seems to imply ext-comm 
RFC5512 carried on A-D routes as well (original eVPN draft does not provision 
for carrying those ext-comms on type-1 unless I missed some other draft). How 
can we differentiate otherwise between MPLS and vxLAN tunneling? If that’s the 
intention, I think it has to be spelled out.

Definitively RFC5512 bgp encap ext community as per 
http://tools.ietf.org/html/draft-ietf-bess-evpn-overlay-00
[Tony said] ok, yes, but carrying 5512 on type-1 routes is a completely new 
concept I didn’t see in any other draft and I think that should be pointed out 
explicitly. Honestly, the resolve the problem above we may want to carry the 
Gateway MAC ExtComm as other VxLAN cases do. That would make things symmetric 
and resolve the ‘magic lookup’ I see here.

[JORGE] About the 5512 ext community, the above draft explicitly says that all 
the routes, including RT1 should carry the 5512 ext community with the right 
tunnel type. I don’t think it is required a new reference here since the 
evpn-overlay draft is referenced. However if you still think it is better to 
explicitly mention it, please suggest a text and we can add it.

[Tony said]  agreed, -03 is very clear now.


About adding the router’s MAC ext community to the RT5 in this use-case
 do we 
need it assuming that the NVE is sending a RT2 with the MAC associated to the 
ESI?

[Tony said]  as above, I do not think it’s beneficial to add implications of a 
lookup from ESI to a valid MAC just for this specific case.

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

[bess] Tunnel question for ESI next-hop in draft evpn prefix-advert

2015-01-14 Thread Antoni Przygienda 
Attached comments I started on the prefix advertisement draft in eVPN  to get 
e'one a chance to jump in

thanks

--- tony


I shall never be ashamed of citing a bad author if the line is 
good.<http://www.quotationspage.com/quote/26861.html>
~~ Seneca

--- Begin Message ---
inline



From: Rabadan, Jorge (Jorge) [mailto:jorge.raba...@alcatel-lucent.com]
Sent: Tuesday, January 13, 2015 9:04 AM
To: Antoni Przygienda; Henderickx, Wim (Wim); flo...@nuagenetworks.net; Ali 
Sajassi (sajassi) (saja...@cisco.com)
Subject: Re: Tunnel question for ESI next-hop in draft evpn prefix-advert



Hi Tony,



Please see in-line.



From: Antoni Przygienda 
mailto:antoni.przygie...@ericsson.com>>
Date: Monday, January 12, 2015 at 11:33 PM
To: Jorge Rabadan 
mailto:jorge.raba...@alcatel-lucent.com>>, 
"Henderickx, Wim (Wim)" 
mailto:wim.henderi...@alcatel-lucent.com>>, 
"flo...@nuagenetworks.net<mailto:flo...@nuagenetworks.net>" 
mailto:flo...@nuagenetworks.net>>, "Ali Sajassi 
(sajassi) (saja...@cisco.com<mailto:saja...@cisco.com>)" 
mailto:saja...@cisco.com>>
Subject: Tunnel question for ESI next-hop in draft evpn prefix-advert



   Gentlemen,



   specific question for section 5.4 (2) in the evpn prefix advertisement draft 
since the language is difficult to parse



   Do you mean 5.3, ESI next-hop ("Bump in the wire") use-case?



   [Tony said]  yepp, bump-in-the-wire, it’s section 5.4 in revision -02





   What do you mean by “and the corresponding tunnel information” for ESI 
next-hop for type-5 in the vxLAN case?



   a)  I don’t see how vxLAN will work with that since at least a Router 
MAC’s extended comm is needed in such a case, section 5.4 (4) describing how to 
derive the inner MAC is fuzzy, we cannot look-up the VRF ARP table since NVE2 
has no overlay IP address and ‘EVI-10 FDB table’ is something I don’t 
understand and I don’t think has been defined. The alleged M2 to be used does 
not exist in the figure at all.



   We can clarify that section for sure. The idea is that the RT5 in this case 
requires a recursive lookup resolution to the information given by the RT1. The 
tunnel information (destination VTEP, VNI) comes from the RT1. In this use-case 
we want to direct the encapsulated frames to the owner of the active ESI. 
EVI-10 FDB should be replaced by MAC-VRF10 FDB in DCW1/2, we can fix that. In 
the MAC-VRF you could find M2 since it is associated to the ESI23 (NVE2/3 
advertise TS2/3 MACs with ESI23).



   [Tony said]  the idea is completely clear to me (and commendable).  I got 
what you say but Figure 5 is missing M2 and M3 in it and maybe a sentence 
saying to be perfectly clear that NVE2 announces M2  type-2 (without IP address 
obviously).  The text still implies an impossible lookup to me. ARP table needs 
IP addresses for NVE2/NVE3, there is no such thing as ESI23<->M2 entry so it’s 
some kind of a completely new beast which I need to think through. I think 
calling it ‘ARP lookup or EVI-10 MACVRF’ is implying magic in this case.









   b)  the “tunnel information” provided by A-D route seems to imply 
ext-comm RFC5512 carried on A-D routes as well (original eVPN draft does not 
provision for carrying those ext-comms on type-1 unless I missed some other 
draft). How can we differentiate otherwise between MPLS and vxLAN tunneling? If 
that’s the intention, I think it has to be spelled out.



   Definitively RFC5512 bgp encap ext community as per 
http://tools.ietf.org/html/draft-ietf-bess-evpn-overlay-00

   [Tony said] ok, yes, but carrying 5512 on type-1 routes is a completely new 
concept I didn’t see in any other draft and I think that should be pointed out 
explicitly. Honestly, the resolve the problem above we may want to carry the 
Gateway MAC ExtComm as other VxLAN cases do. That would make things symmetric 
and resolve the ‘magic lookup’ I see here.







   Merits couple clarifying sentences would merit addition?



   Yes, we’ll do that.





   As well, the last paragraph is hard to parse with the ‘same BGP next-hop for 
type-5 and type-1’ being ‘valid’?  I also think it is superfluous to imply a 
condition of ‘validity’. There is no check necessary.

   L3VRF will hold two type-5 routes with NH ESI23 but the resolution is 
happening over type-1 of which there is only one so there will the L3 
load-balancing ending however on exactly the same underlying tunnel. Nothing 
wrong with that. It’s basically BGP advertising third-party next-hop which is 
not often seen but perfectly valid.



   Yes, I agree. Will modify that in the next rev.



   [Tony said] ok, cool.



   --- tony

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

[bess] Poll for adoption: draft-rabadan-l2vpn-evpn-prefix-advertisement

2015-01-13 Thread Antoni Przygienda 
support for adoption

Good draft, has couple of holes still due to the complexity of the subject. I'm 
commenting towards the authors on private e-mail

thanks

--- tony


I shall never be ashamed of citing a bad author if the line is 
good.
~~ Seneca

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