Re: [bess] WG Last Call on draft-ietf-bess-evpn-etree

[RABADAN, Jorge (Jorge)]

As co-author, I fully support this document for publication. 
Not aware of any relevant IPR.

Thank you.
Jorge




On 1/19/16, 12:51 AM, "BESS on behalf of Thomas Morin"  wrote:

>Hello Working Group,
>
>This email starts a Working Group Last Call on 
>draft-ietf-bess-evpn-etree [1] which is considered mature and ready for 
>a final working group review.
>
>Please read the document if you haven't read the most recent version yet 
>(-03), and send your comments to the list, no later than *February the 
>2nd* (2016-02-02).
>
>This is not only a call for comments on the document, but also a call of 
>support for its publication.
>
>*Coincidentally*, we are also polling for knowledge of any IPR that 
>applies to draft-ietf-bess-evpn-etree, 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 of 
>draft-ietf-bess-evpn-etree please respond to this email and indicate 
>whether or not you are aware of any relevant IPR.
>
>Thank you,
>
>Thomas/Martin
>
>[1] https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-etree
>
>___
>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] WG Last Call for draft-ietf-bess-pta-flags-01

[RABADAN, Jorge (Jorge)]

I fully support this document. Very much needed.

Thanks.
Jorge




On 1/5/16, 6:48 AM, "BESS on behalf of Martin Vigoureux"  wrote:

>Hello Working Group,
>
>This email starts a Working Group Last Call on 
>draft-ietf-bess-pta-flags-01 [1] which is considered mature and ready 
>for a final working group review.
>
>Please read the document if you haven't read the most recent
>version yet, and send your comments to the list, no later than
>*12th of January*.
>
>This is not only a call for comments on the document, but also a call of 
>support for its publication.
>
>*Coincidentally*, we are also polling for knowledge of any IPR that 
>applies to draft-ietf-bess-multicast-damping, 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 of
>draft-ietf-bess-pta-flags-01 please respond to this email and indicate 
>whether or not you are aware of any relevant IPR.
>
>Thank you,
>M
>
>[1] https://datatracker.ietf.org/doc/draft-ietf-bess-pta-flags/
>
>___
>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-rabadan-bess-evpn-ac-df-02

[Rabadan, Jorge (Jorge)]

Hi,

Note that RFC7432 ethernet-segments are assigned to ‘physical’ ports, i.e. a 
logical subinterface will not trigger a type 4 withdrawal as long as the port 
is still oper-up.
The association of logical sub-interfaces to ethernet-segments is tackled in 
https://tools.ietf.org/html/draft-sajassi-bess-evpn-virtual-eth-segment

About the loop, again, the split-horizon procedures and the ESI label protect 
against loops, since there is a data path indication of the ethernet segment 
that originated the BUM traffic. The timer makes sure that all the PEs have the 
same view on who the DF is.

Thx
jorge

From: <sudhinja...@rediffmail.com<mailto:sudhinja...@rediffmail.com>> on behalf 
of sudeep g ggg <sudhinja...@rediffmail.com<mailto:sudhinja...@rediffmail.com>>
Date: Monday, November 30, 2015 at 2:32 PM
To: Jorge Rabadan 
<jorge.raba...@alcatel-lucent.com<mailto:jorge.raba...@alcatel-lucent.com>>
Cc: "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
Subject: Re: [bess] REG: draft-rabadan-bess-evpn-ac-df-02

Hi Jorge,

Section 2.1.1. Current DF election procedure and AC failures

If AC2 is accidentally shutdown or even not configured, CE12
traffic will be impacted. In case of all-active multi-homing, only
the BUM traffic to CE12 will be impacted, whereas for single-active
multi-homing all the traffic to/from CE12 will be discarded. This is
due to the fact that a logical failure in PE-2 AC2 will not trigger
an ES route withdrawn for ESI12 (since there are still other ACs
active on ESI12) and therefore PE-1 will not re-run the DF election
procedures.

In Single Active a sub interface goes down, it will send a type 4 withdrawal 
and other PE will become DF based. This is taken care in SA but AA it makes 
sense.

How about the 3 second timer, there will be a loop if there is transition of 
PE's moving to DF to NON DF when a new PE as added or a link failure. During 
this time, may I know how the traffic is handled because RFC is not clear about 
that period. How you are going to tackle that issue.During this transition 
period if both PE starts forwarding the traffic there will be a loop, how to 
address that.

If you are using AC per Vlan but customers require vlan bundle, some times 
local switching how to handle those situations. Kindly clarify.

Correct me if I am wrong.

Regards,
Sudhin







On Mon, 30 Nov 2015 11:50:09 +0530 "Rabadan, Jorge (Jorge)" wrote
>






Hi Sudhin,



Please see in-line.
Thanks.
Jorge










From: BESS on behalf of sudeep g ggg

Date: Wednesday, November 25, 2015 at 2:58 PM

To: "bess@ietf.org<mailto:bess@ietf.org>"

Subject: [bess] REG: draft-rabadan-bess-evpn-ac-df-02







Respected Authors,



I had gone through the draft at high level,I am happy to see a real provider 
provisioning issues addressed in your draft. Much appreciated.



Some key highlights in your draft.



1. No changes.

2. Using existing features to address a problem.

3. Addresses provisioning issues.






[JORGE] not only provisioning issues but also ‘logical’ failures like an 
"Attachment Circuit” going oper-down due to OAM or admin shutdown.










How ever I have following queries.



May I know how to deal with vlan provisioning issues like one PE will have vlan 
2,3,4 and other PE will have 3,4 this will end up in both PE's as DF correct me 
if I am wrong, you use type 1 Ad per ES and EVI for DF election, how about vlan 
issues.






[JORGE] the draft talks about how to influence the DF election based on the 
status of an “Attachment Circuit (AC)”. For VLAN-based services, a customer VID 
equals an AC (and there is a single VLAN per EVI per ES), hence in this case 
you can actually catch
VLAN provisioning mistakes, i.e. if you don’t provision VLAN 2 in PE1, PE1 
won’t ever send the AD per EVI route for that VLAN, hence PE1 won’t be elected 
the DF within the ES in any PE using the AD per-EVI route in the DF election.










May I know how to handle transient loop during 3 seconds period during DF 
election.May I know the state of PE during the DF election, clarity 
required[humble opinion].






[JORGE] the draft is not changing the DF election itself (where, by the way, 
there is no transient loops). It is only removing PEs from the candidate DF 
list for a given EVI based on the presence of the AD per-EVI route. All the 
rest of the RFC7432 procedures
are kept intact.












This seems to be a good customer focused solution. I appreciate it.[please 
note: this is my humble opinion as an individual not representing any one]



Regards,

Sudhin Jacob




























Get your own

FREE website,
FREE domain &
FREE mobile app with Company email.

Know
More >









___

BESS mailing list

BESS@ietf.org<mailto:BESS@ietf.org>

https://www.ietf.org/mailman/listinfo/bess


[https://sigads.

Re: [bess] REG: draft-rabadan-bess-evpn-ac-df-02

[Rabadan, Jorge (Jorge)]

Hi Sudhin,

Please see in-line.
Thanks.
Jorge

From: BESS > on behalf of 
sudeep g ggg >
Date: Wednesday, November 25, 2015 at 2:58 PM
To: "bess@ietf.org" >
Subject: [bess] REG: draft-rabadan-bess-evpn-ac-df-02

Respected Authors,

I had gone through the draft at high level,I am happy to see a real provider 
provisioning issues addressed in your draft. Much appreciated.

Some key highlights in your draft.

1. No changes.
2. Using existing features to address a problem.
3. Addresses provisioning issues.

[JORGE] not only provisioning issues but also ‘logical’ failures like an 
"Attachment Circuit” going oper-down due to OAM or admin shutdown.



How ever I have following queries.

May I know how to deal with vlan provisioning issues like one PE will have vlan 
2,3,4 and other PE will have 3,4 this will end up in both PE's as DF correct me 
if I am wrong, you use type 1 Ad per ES and EVI for DF election, how about vlan 
issues.

[JORGE] the draft talks about how to influence the DF election based on the 
status of an “Attachment Circuit (AC)”. For VLAN-based services, a customer VID 
equals an AC (and there is a single VLAN per EVI per ES), hence in this case 
you can actually catch VLAN provisioning mistakes, i.e. if you don’t provision 
VLAN 2 in PE1, PE1 won’t ever send the AD per EVI route for that VLAN, hence 
PE1 won’t be elected the DF within the ES in any PE using the AD per-EVI route 
in the DF election.



May I know how to handle transient loop during 3 seconds period during DF 
election.May I know the state of PE during the DF election, clarity 
required[humble opinion].

[JORGE] the draft is not changing the DF election itself (where, by the way, 
there is no transient loops). It is only removing PEs from the candidate DF 
list for a given EVI based on the presence of the AD per-EVI route. All the 
rest of the RFC7432 procedures are kept intact.




This seems to be a good customer focused solution. I appreciate it.[please 
note: this is my humble opinion as an individual not representing any one]

Regards,
Sudhin Jacob








[https://sigads.rediff.com/RealMedia/ads/adstream_nx.ads/www.rediffmail.com/signatureline.htm@Middle]
Get your own FREE website, FREE domain & FREE mobile app with Company email.
Know More 
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

[Rabadan, Jorge (Jorge)]

IMHO if TOR chip vendors can confirm they are seriously looking at 
MPLS/MPLS/UDP, Wim’s suggestion makes all the sense since we know it works and 
scales.
My 2 cents.

Jorge



On 11/20/15, 9:51 AM, "BESS on behalf of UTTARO, JAMES"  wrote:

>+1
>
>-Original Message-
>From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of John E Drake
>Sent: Friday, November 20, 2015 12:19 PM
>To: EXT - thomas.mo...@orange.com; Lucy yong; Henderickx, Wim (Wim); 
>bess@ietf.org
>Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc
>
>Lucy,
>
>My apologies, I misunderstood.
>
>I think we have to accept the fact that we will have to deal with a 
>multiplicity of different encapsulations in the data plane along a packet's 
>e2e path and that we should take a more measured approach to deciding how to 
>deal with this in a general and extensible way before accepting any solutions. 
>  
>Yours Irrespectively,
>
>John
>
>> -Original Message-
>> From: thomas.mo...@orange.com [mailto:thomas.mo...@orange.com]
>> Sent: Friday, November 20, 2015 12:04 PM
>> To: John E Drake; Lucy yong; Henderickx, Wim (Wim); bess@ietf.org
>> Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc
>> 
>> 2015-11-20, John E Drake:
>> > That presupposes that the group likes either of the two proposed solutions
>> in your draft.
>> 
>> John, I think Lucy's "two solutions" was referring to draft-hao-bess-inter-
>> nvo3-vpn-optionc solution and the 3-label Optionc MPLS/MPLS/UDP solution
>> described by Wim.
>> 
>> -Thomas
>> 
>> 
>> 
>> >
>> >> -Original Message-
>> >> From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Lucy yong
>> >> Sent: Friday, November 20, 2015 11:49 AM
>> >> To: EXT - thomas.mo...@orange.com; Henderickx, Wim (Wim);
>> >> bess@ietf.org
>> >> Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc
>> >>
>> >> Share my 2 cent.
>> >>
>> >> Cloud providers want to tunnel its customer traffic through DC (AS)BR.
>> >> Option C is a way to realize it. Both solutions summarized by Thomas
>> >> have no change on WAN VPN side and seamlessly work with WAN VPN
>> option C.
>> >> However, to support either solution, DC has to do some enhancement on
>> >> DC BR or ToR switch, etc, which dictates to different implementations
>> >> within a DC. Option C pro and con remains regardless what
>> >> implementation is used in a DC.
>> >>
>> >> Two solutions should not coexist in one DC (does not make a sense),
>> >> but it does not matter if one DC operator prefers to use one solution
>> >> and another DC prefers to use another solution. Since there are many
>> >> cloud providers today, it is worth for the WG to document both
>> >> solutions and point out the implementation requirements on impacted
>> >> components. Then, up to vendors and operators to select a solution for
>> their DC.
>> >>
>> >> It does not make a sense for us to vote which solution is better here
>> >> because a better solution for a DC depends on many factors.
>> >>
>> >>
>> >> Lucy
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> -Original Message-
>> >> From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of
>> >> thomas.mo...@orange.com
>> >> Sent: Friday, November 20, 2015 3:02 AM
>> >> To: Henderickx, Wim (Wim); bess@ietf.org
>> >> Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc
>> >>
>> >> 2015-11-19, Henderickx, Wim (Wim):
>> >>> WH> I vote for a an evolution of switches/TORs that have proper
>> >>> support for this. I hope some HW vendors of TOR chips shime in, but
>> >>> I am told the MPLS solution is possible in the next generation chips
>> >>> they are working on.
>> >>
>> >> Well, it looks like the key questions are:
>> >> - when would ToR chips support MPLS/MPLS/UDP ?  (the generation that
>> >> has been released recently but not present in most shipping ToRs yet,
>> >> the next one ?)
>> >> - do we want an interim VXLAN-based solution ? (that will involve at
>> >> best a performance penalty with existing chips, and at worse
>> >> impossible to implement -- we haven't seen clear information in this
>> >> thread)
>> >>
>> >> -Thomas
>> >>
>> >>
>>  Zhuangshunwan  :
>> >
>> > Hi Diego,
>> >
>> > Thanks for your comments. Pls see inline with [Vincent].
>> >
>> > Vincent
>> >
>> > *发件人:*BESS [mailto:bess-boun...@ietf.org] *代表 *Diego Garcia
>> >> del Rio
>> > *发送时间:*2015年11月18日14:25 *收件人:*bess@ietf.org *主题
>> >> :*Re: [bess]
>> > draft-hao-bess-inter-nvo3-vpn-optionc
>> >
>> > Some comments from my side, I think the draft makes quite a few
>> > assumptions on specific implementation details that are way too
>> > general to be considered widely available. Most of the TOR devices
>> > today already pay a double-pass penalty when doing routing of
>> > traffic in/out of vxlan-type tunnels. Only the newest generation
>> > can route into tunnels without additional passes. And are
>> > definitively limited in being 

Re: [bess] One question about Route-type2 usage in EVPN base protocol

[Rabadan, Jorge (Jorge)]

Hi Weiguo,

I would recommend you to check out the L2VPN archives… we discussed this at 
length.
For instance:
http://www.ietf.org/mail-archive/web/l2vpn/current/msg04519.html

But check the other emails in the thread.
Sending one or two routes, really depend on how the learning is done.

Hope it helps.
Thanks.
Jorge

From: BESS > on behalf of 
Haoweiguo >
Date: Thursday, November 19, 2015 at 1:37 AM
To: "saja...@cisco.com" 
>
Cc: "bess@ietf.org" >
Subject: [bess] One question about Route-type2 usage in EVPN base protocol

Hi Co-authors,
Through ARP process, each EVPN PE can learn local connecting CE’s MAC and IP 
correspondence, and will notify the MAC and IP association to all remote PEs 
through Route-type2 message. Theoretically, each remote PE can rely on the 
single route-type2 message to populate local Mac VRF(MAC table) , ARP Cache and 
IP VRF(IP routing table) at the same time. However, some vendor doesn’t do in 
this way. In its implementation, each PE will notify two route-type2 message to 
remote PEs, one message(say message 1) only carry MAC information(IP field is 
invalid), another message(say message 2) carry MAC and IP association 
information. The remote PEs rely on message 1 to populate local MAC VRF, and 
rely on message 2 to populate local ARP Cache and IP VRF.


I think EVPN protocol should give a clear suggestion for route type-2 message 
usage, what’s the scenario to announce only one message and what’s scenario to 
announce two messages?



Thanks,

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

Re: [bess] [Idr] One question about 'draft-ietf-bess-evpn-overlay-02' and draft-ietf-idr-tunnel-encaps-00

[Rabadan, Jorge (Jorge)]

Lucy,

There are several implementations with shipping code using the RFC5512 bgp 
tunnel extended community. It cannot be deprecated.
Thanks.
Jorge

From: Idr > on behalf of Lucy 
yong >
Date: Friday, November 13, 2015 at 12:21 PM
To: "thomas.mo...@orange.com" 
>, Gunter Van De Velde 
>
Cc: "Ali Sajassi (sajassi)" >, 
"bess@ietf.org" >, 
IDR >
Subject: Re: [Idr] [bess] One question about 'draft-ietf-bess-evpn-overlay-02' 
and draft-ietf-idr-tunnel-encaps-00

Yes, kindly for backward compatibility. Having two ways to do it is a pain for 
the implementation.
Lucy

From: thomas.mo...@orange.com 
[mailto:thomas.mo...@orange.com]
Sent: Friday, November 13, 2015 2:19 PM
To: Gunter Van De Velde; Lucy yong
Cc: John E Drake; bess@ietf.org; IDR; Ali Sajassi 
(sajassi)
Subject: RE: [Idr] [bess] One question about 'draft-ietf-bess-evpn-overlay-02' 
and draft-ietf-idr-tunnel-encaps-00


Lucy,

The tunnel encap also describe how to use the extended community, in section 6.

Best,

-Thomas


 Lucy yong a écrit 
Hi Gunter,

Thank you to point to the right section. This overlay draft suggests to use 
Encapsulation extended community to indicate the type of data plane 
encapsulation to be used for all EVC routes. But the tunnel encap draft 
proposes to use tunnel encapsulation attribute + sub-TLVs to indicate the type 
of data plane encapsulation to be used for a prefix. Why do we want to have two 
solutions for the same space?

Since this overlay draft is not RFC yet, it is good for the community to make a 
decision on it, which keeps simple for the implementation. It is not hard to 
modify the draft to use tunnel encapsulation attribute indicating the type of 
data plane encapsulation for all EVC routes.

Regards,
Lucy

From: Gunter Van De Velde [mailto:guntervandeveld...@icloud.com]
Sent: Friday, November 13, 2015 1:46 PM
To: Lucy yong
Cc: thomas.mo...@orange.com; John E Drake; 
bess@ietf.org; IDR; Ali Sajassi (sajassi)
Subject: Re: [Idr] [bess] One question about 'draft-ietf-bess-evpn-overlay-02' 
and draft-ietf-idr-tunnel-encaps-00


Hi Lucy,

Did you take time to read
https://tools.ietf.org/html/draft-ietf-bess-evpn-overlay-02
Its used pretty intense by DC orchestration platforms nowadays. Section 5.1 
provides more insight.

Brgds,
G/

Sent using CloudMagic 
Email
On Fri, Nov 13, 2015 at 7:12 PM, Lucy yong 
> wrote:


Hi John,

Since the tunnel encap draft goes with encap tunnel attribute and there was no 
deployment of RFC5512, IMO, we should deprecate encapsulation extended 
community to keep a consistent method.

Thus, should the overlay draft states if BGP tunnel encapsulate attribute is 
not present, 

Regards,
Lucy

-Original Message-
From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of 
thomas.mo...@orange.com
Sent: Friday, November 13, 2015 10:46 AM
To: John E Drake; bess@ietf.org
Cc: IDR; Ali Sajassi (sajassi); Eric Rosen
Subject: Re: [bess] One question about 'draft-ietf-bess-evpn-overlay-02' and 
draft-ietf-idr-tunnel-encaps-00

John,

(Cc'ing IDR.)

2015-11-13, John E Drake:
>
> I spoke with Eric and Ali and we would like to change both the overlay
> draft and the tunnel encaps drafts as follows.
>
> For the overlay draft, replace this text in section 5.1.3:
>
> "If the BGP Encapsulation extended community is not present, then
> thedefault MPLS encapsulation or a statically configured encapsulation
> is
> assumed."
>
> With the following:
>
> "Note that the MPLS encapsulation tunnel type is needed in order to
> distinguish between an advertising node that only supports non-MPLS
> encapsulations and one that supports MPLS and non-MPLS encapsulations.
> An advertising node that only supports MPLS encapsulation does not
> need to advertise any encapsulation tunnel types; i.e., if the BGP
> Encapsulation extended community is not present, then either MPLS
> encapsulation or a statically configured encapsulation is assumed."

Having more text to explain things in the overlay draft does not hurt.


>
> For the tunnel encaps draft, replace this text in section 5:
>
> "If the Tunnel Encapsulation attribute contains several TLVs (i.e.,
> ifit specifies several tunnels), router R may choose any one of those
> tunnels, based upon local policy. If any of tunnels' TLVs contain the  > 
> Color sub-TLV and/or the Protocol Type sub-TLV 

Re: [bess] One question about 'draft-ietf-bess-evpn-overlay-02'

[Rabadan, Jorge (Jorge)]

Weiguo,

There are already implementations using value 10 in the RFC5512 BGP encap ext 
community.
That is the value you would have in RFC7432 compliant networks where you can 
also have overlay tunnels. Value 10 would indicate to the ingress PE that the 
route needs an MPLS tunnel to be resolved.

Thx
Jorge

From: BESS > on behalf of 
Haoweiguo >
Date: Tuesday, November 10, 2015 at 1:05 AM
To: "saja...@cisco.com" 
>, 
"jdr...@juniper.net" 
>
Cc: "bess@ietf.org" >
Subject: [bess] One question about 'draft-ietf-bess-evpn-overlay-02'


Hi Ali & John,

The draft of 'draft-ietf-bess-evpn-overlay-02' describes how EVPN can be used 
for Overlay network, the overlay network includes VXLAN, NVGRE and MPLS Over 
GRE.

In section 13 IANA considerations, several overlay tunnel types are requested 
as follows:

8VXLAN Encapsulation
9NVGRE Encapsulation
10   MPLS Encapsulation   (?)
11   MPLS in GRE Encapsulation
12   VXLAN GPE Encapsulation



IMO, 8,9,11 and 12 are all overlay encapsulations, 10 is an exception. Would 
you like to explain what's the purpose of tunnel type 10?



Thanks,

weiguo

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

Re: [bess] One question about 'draft-ietf-bess-evpn-overlay-02'

[Rabadan, Jorge (Jorge)]

Weiguo,

Well, if an RFC7432 implementation does not use the RFC5512 ext community, the 
following sentence in the evan-overlay draft should help interoperability. I 
personally don’t see any issues.


If the BGP Encapsulation extended community is not present, then the
   default MPLS encapsulation or a statically configured encapsulation
   is assumed.

Thanks.
Jorge

From: Haoweiguo <haowei...@huawei.com<mailto:haowei...@huawei.com>>
Date: Tuesday, November 10, 2015 at 7:03 PM
To: Jorge Rabadan 
<jorge.raba...@alcatel-lucent.com<mailto:jorge.raba...@alcatel-lucent.com>>, 
"saja...@cisco.com<mailto:saja...@cisco.com>" 
<saja...@cisco.com<mailto:saja...@cisco.com>>, 
"jdr...@juniper.net<mailto:jdr...@juniper.net>" 
<jdr...@juniper.net<mailto:jdr...@juniper.net>>
Cc: "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
Subject: RE: [bess] One question about 'draft-ietf-bess-evpn-overlay-02'


Jorge,

Thanks for your explanations. However, i still can't understand, i'm sorry.

RFC 5512 only defines IP tunnel type and encapsulation attribute, like 
L2TPv3,GRE and IP in IP.  For RFC 5512, MPLS tunnel doesn't need to be defined 
specifically, it is default case. In RFC 7432, the tunnel type 10 also hasn't 
been defined. Later, when the EVPN for overlay network solution was proposed, 
the tunnel type 10 was introduced to differentiate MPLS tunnel and 
VXLAN/NVGRE/MPLS Over GRE tunnel, because same route type 1,2,3,4 and 5 are 
used in both RFC 7432 and the draft 'draft-ietf-bess-evpn-overlay-02'. We need 
the tunnel type to clearly notify peer EVPN PE which tunnel(including MPLS 
tunnel type) should be used.  So it introduced updates on RFC 7432 and will 
incur some interoperbility issue for RFC 7432. Am i right?

Thanks,

weiguo



____________

From: BESS [bess-boun...@ietf.org<mailto:bess-boun...@ietf.org>] on behalf of 
Rabadan, Jorge (Jorge) 
[jorge.raba...@alcatel-lucent.com<mailto:jorge.raba...@alcatel-lucent.com>]
Sent: Wednesday, November 11, 2015 0:01
To: Haoweiguo; saja...@cisco.com<mailto:saja...@cisco.com>; 
jdr...@juniper.net<mailto:jdr...@juniper.net>
Cc: bess@ietf.org<mailto:bess@ietf.org>
Subject: Re: [bess] One question about 'draft-ietf-bess-evpn-overlay-02'

Weiguo,

There are already implementations using value 10 in the RFC5512 BGP encap ext 
community.
That is the value you would have in RFC7432 compliant networks where you can 
also have overlay tunnels. Value 10 would indicate to the ingress PE that the 
route needs an MPLS tunnel to be resolved.

Thx
Jorge

From: BESS <bess-boun...@ietf.org<mailto:bess-boun...@ietf.org>> on behalf of 
Haoweiguo <haowei...@huawei.com<mailto:haowei...@huawei.com>>
Date: Tuesday, November 10, 2015 at 1:05 AM
To: "saja...@cisco.com<mailto:saja...@cisco.com>" 
<saja...@cisco.com<mailto:saja...@cisco.com>>, 
"jdr...@juniper.net<mailto:jdr...@juniper.net>" 
<jdr...@juniper.net<mailto:jdr...@juniper.net>>
Cc: "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
Subject: [bess] One question about 'draft-ietf-bess-evpn-overlay-02'


Hi Ali & John,

The draft of 'draft-ietf-bess-evpn-overlay-02' describes how EVPN can be used 
for Overlay network, the overlay network includes VXLAN, NVGRE and MPLS Over 
GRE.

In section 13 IANA considerations, several overlay tunnel types are requested 
as follows:

8VXLAN Encapsulation
9NVGRE Encapsulation
10   MPLS Encapsulation   (?)
11   MPLS in GRE Encapsulation
12   VXLAN GPE Encapsulation



IMO, 8,9,11 and 12 are all overlay encapsulations, 10 is an exception. Would 
you like to explain what's the purpose of tunnel type 10?



Thanks,

weiguo

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

Re: [bess] Seeking Comments for EVPN-VPWS Service Edge Gateway

[Rabadan, Jorge (Jorge)]

Sami,

I already sent you a few comments for rev 0. 
I’ll paste them here (with /*[JORGE]*/) for this version too.
Thanks.
Jorge


--


Abstract

   This document describes how a service node can dynamically terminate
   EVPN virtual private wire transport service (VPWS) from access nodes
   and offer Layer 2, Layer 3 and Ethernet VPN overlay services to
   Customer edge devices connected to the access nodes. Service nodes
   using EVPN will advertise to access nodes the L2, L3 and Ethernet VPN
   overlay services it can offer for the terminated EVPN VPWS transport
   service. On an access node an operator can specify the L2 or L3 or
   Ethernet VPN overlay service needed by the customer edge device
   connected to the access node that will be transported over the EVPN-
   VPWS service between access node and service node.

/* [JORGE] it would be good to clearly state the benefit of doing this.
The main advantages that I see are service extension with single-side
provisioning (no need to provision new ACs at the service node). */




1  Introduction


/* [JORGE] maybe this level of detail at the introduction is a bit
confusing. I think it would be better to state what the goal and
advantages are in the introduction and leave the details for the solution
description. */



...



2.2  Scalability

   (R2a) A single service node PE can be associated with many access
   node PEs. The following requirements give a quantitative measure.

   (R2b) A service node PE MUST support thousand(s) head-end connections
   for a a given access node PE connecting to different overlay VRF
   services on that service node.

   (R2c) A service node PE MUST support thousand(s) head-end connections
   to many access node PEs.


/* [JORGE] It is hard to understand... should the following be better?:

“ (R2b) A service node PE MUST support head-end functionality for
thousands of access node PEs that are connected to different VRFs on the
service node.
  (R2c) A service node PE MUST support hundreds of thousands of CE
connections through the attached access nodes."
*/






2.5 Multi-homing

   TBD

/* [JORGE] The solution should describe how to handle multi-homing at two
levels:
- Access node multi-homed to 2 or more Service nodes
- CE node multi-homed to 2 or more access nodes (this one should be
aligned with the EVPN-VPWS draft)
*/







4 Solution Overview


   +-+ +-+
   | | | |
  ++   +-+ | IP/MPLS | +-+ | IP/MPLS |
  | CE |---| PE1 |-| Access  |-| PE2 |-| Core|
  ++   +-+ | Network | +-+ | Network |
   | | | |
   +-+ +-+
  < EVPN-VPWS >< IP/MAC VRF --->


   Figure 1: EVPN-VPWS Service Edge Gateway.
   AN: Access node
   SE: Service Edge node.

   EVPN-VPWS Service Edge Gateway Operation

/* [JORGE] Should this be section 4.1 on its own? */


   At the service edge node, the EVPN Per-EVI Ethernet A-D routes will
   be advertised with the ESI set to 0 and the Ethernet tag-id set to
   (wildcard 0xFFF). The Ethernet A-D routes will have a unique RD
   and will be associated with 2 BGP RT(s), one RT corresponding to the
   underlay EVI i.e. the EVPN VPWS transport service that's configured
   only among the service edge nodes, and one corresponding to the L2,
   L3 or EVPN overlay service.

   At the access nodes, the EVPN per-EVI Ethernet A-D routes will be
   advertised as described in [draft-ietf-bess-evpn-vpws 
] with the ESI
   field is set to 0 and for single homed CEs and to the CE's ESI for
   multi-homed CE's and the Ethernet Tag field will be set to the VPWS
   service instance identifier that identifies the EVPL or EPL service.
   The Ethernet-AD route will have a unique RD and will be associated
   with one BGP RT corresponding to the L2, L3 or EVPN overlay service
   that will be transported over this EVPN VPWS transport service.

/* [JORGE] What do you mean by EVPN overlay service in this context? why
is it different from L2 or L3 service? should this be clarified in the
introduction? 
Also by L2 and L3 are you referring to the encapsulation? i.e. L2 means
ethernet over the EVI label and L3 IP over the EVI label? */

/* [JORGE] If the service RTs are the same in the access and core network,
PE2 should have two different peering sessions, one to the RR in the
access network and one to the core RR. Is that the intend? if so, it may
be good to clarify */





   Service edge nodes on the underlay EVI will determine the primary
   service node terminating the VPWS transport service and offering the
   L2, L3 or Ethernet VPN service by running the on HWR algorithm as
   described in [draft-mohanty-l2vpn-evpn-df-election 

Re: [bess] draft-ietf-bess-evpn-prefix-advertisement-02

[Rabadan, Jorge (Jorge)]

Sami,

Besides what Ali says, for your second question note that in the use-case 5.4 
we are explicitly avoiding GW-IP non-zero plus router’s mac in the same update:

"The Router's MAC Extended Community MUST be sent if the associated
  RT-5's GW IP Address is zero.”


Thanks.
Jorge



On 10/8/15, 12:31 AM, "Ali Sajassi (sajassi)"  wrote:

>
>Sami,
>
>There are intended for different scenarios. When a subnet is sitting
>behind a TS, there is no need to advertise label/VNI in RT5 for that
>subnet because it gets resolved via label/VNI associated with RT2 for that
>TS. In other scenarios, where subnet gets directly advertised by PE (e.g.,
>no indirection and no RT2), then label/VNI for that subnet gets advertised
>in RT5.
>
>Cheers,
>Ali
>
>On 10/7/15, 2:56 PM, "BESS on behalf of Sami Boutros (sboutros)"
> wrote:
>
>>Hi Jorge,
>>
>>In some of the use case sections in the draft, there is no mention of the
>>label/VNI that will be associated with RT-5.
>>As well if the router-mac will be associated with RT-5 and the GW-IP will
>>be set, why do we need to advertise those again in RT-2?
>>
>>Thanks,
>>
>>Sami
>>___
>>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] PMSI Tunnel Attribute Flags

[Rabadan, Jorge (Jorge)]

Eric,

That’s ok.
As I said, to me it is more important to close on this asap. I would be 
interested to know what that bit is used for ;-) but.. other than that, I fully 
support this document.

Thank you.
Jorge  



On 9/29/15, 7:04 AM, "BESS on behalf of Eric C Rosen"  wrote:

>Jorge,
>
>Sorry about the delay getting back to you; hopefully we can bring this 
>document to WGLC relatively sonn.
>
>> Although I was still leaning towards a registry per tunnel-type or at
>> least per SAFI (since it would save the use of a new EC) I think at this
>> moment it is even more important to close on this as soon as possible to
>> avoid issues.
>
>Slide 6 of the presentation I gave at the Dallas IETF provides some 
>reasons for not setting up a different registry per tunnel-type or SAFI.
>>
>> My only other comment is that it would seem 'cleaner' to use the most
>> significant bit to indicate the existence of the EC instead of bit 1. If
>> would be good to confirm that the rumor about the use of bit 0 is an
>> existing implementation, in which case I agree it can’t be used.
>
>I did hear the "rumor" from a reliable source ;-)
>
>> If that
>> is the case, it would be good if the relevant people document that
>> somewhere.
>
>Indeed it would.  But hopefully, once we set up the registry, similar 
>undocumented uses of the flag bits will be less likely to happen.
>
>Eric
>
>___
>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] PMSI Tunnel Attribute Flags

[Rabadan, Jorge (Jorge)]

Hi Eric and Thomas,

Thanks for this. This work is important.
Although I was still leaning towards a registry per tunnel-type or at
least per SAFI (since it would save the use of a new EC) I think at this
moment it is even more important to close on this as soon as possible to
avoid issues.

My only other comment is that it would seem 'cleaner' to use the most
significant bit to indicate the existence of the EC instead of bit 1. If
would be good to confirm that the rumor about the use of bit 0 is an
existing implementation, in which case I agree it can’t be used. If that
is the case, it would be good if the relevant people document that
somewhere. 

We can't break existing implementations, however we don’t want to keep
defining bits in additional ECs if there are bits available in the
existing PTA flags either.

My two cents..

Thanks.
Jorge


-Original Message-
From: BESS bess-boun...@ietf.org on behalf of Eric C Rosen
ero...@juniper.net
Date: Thursday, August 6, 2015 at 8:17 AM
To: bess@ietf.org bess@ietf.org
Subject: [bess] PMSI Tunnel Attribute Flags

Thomas and I have just posted draft-ietf-bess-pta-flags-01.  This rev
introduces a new proposal for making the PMSI Tunnel attribute's Flags
Field extensible.  It defines a new opaque extended community that can
be used to carry up to 48 new flags, and uses one of the bits in the
existing Flags Field to mean that additional flags are set in the
extended community.  The draft also establishes an IANA registry for the
existing Flags Field and for the flags in the extended community.

The draft registers two bits in the existing Flags Field;

- Bit 7 (least significant): the LIR bit defined in RFC6514

- Bit 1: Extension bit.  If this bit is set, there are additional flags
in the new extended community.

Although not mentioned in the draft, bits 3-6 are given defined uses in
draft-rabadan-bess-evpn-optimized-ir.
Draft-dolganow-bess-mvpn-expl-track defines another bit, LIR-pF, for
which we will likely request Bit 2.  I have heard a rumor that Bit 0
(most significant) is also in use, though not documented in an
internet-draft.  So all 8 bits are now used.  If the WG agrees to
advance draft-ietf-bess, additional flags would have to come from the
new opaque extended community.

This proposal seems like a good way to preserve the existing uses of the
flags field, to discourage squatting, and to allow additional flags to
be defined.

The proposed registration policy for both the existing flags field and
for flags in the new extended community is Standards Action, which
implies the possibilty of early allocation.

Comments?

___
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] PBB-EVPN draft - use of sticky bit in mac mobility ext. com.

[Rabadan, Jorge (Jorge)]

FYI
For everyone else’s benefit, Ali and a bunch of us discussed offline and we 
agreed that the use of the sticky-bit and a non-zero sequence number in the 
same mac mobility extended community has to be optionally permitted in the 
pbb-evpn draft. So if the user decides to advertise a given shared BMAC as 
‘sticky’, if a new update is advertised to indicate a CMAC flush for that given 
BMAC, the PE will add both, a non-zero sequence number and the sticky bit in 
the same mac mobility extended community.

Ali, feel free to add/comment.

Thank you.
Jorge

From: Ali Sajassi (sajassi) saja...@cisco.commailto:saja...@cisco.com
Date: Monday, April 6, 2015 at 11:16 PM
To: Jorge Rabadan 
jorge.raba...@alcatel-lucent.commailto:jorge.raba...@alcatel-lucent.com, 
draft-ietf-l2vpn-pbb-e...@tools.ietf.orgmailto:draft-ietf-l2vpn-pbb-e...@tools.ietf.org
 
draft-ietf-l2vpn-pbb-e...@tools.ietf.orgmailto:draft-ietf-l2vpn-pbb-e...@tools.ietf.org
Cc: bess@ietf.orgmailto:bess@ietf.org bess@ietf.orgmailto:bess@ietf.org
Subject: Re: [bess] PBB-EVPN draft - use of sticky bit in mac mobility ext. com.


Hi Jorge,

The current text in pbb-evpn draft doesn’t prohibit the use of “sticky-bit”. 
The initial advertisement for a BMAC can be sent with this bit set (where the 
sequence # is zero). For flushing CMAC addresses in PBB-EVPN, MAC mobility 
extended community is used with sequence number incremented (for shared BMACs). 
These two functions are separate and are two different things (learning BMAC 
versus flushing CMACs). Are you concern about a scenario where right after 
configuration of the shared BMAC, there is a failure for Single-Active MHD/MHN, 
where another BMAC advertisement with MAC mobility is sent, and the RR only 
sends the latter advertisement?

Cheers,
Ali

From: Rabadan, Jorge (Jorge) 
jorge.raba...@alcatel-lucent.commailto:jorge.raba...@alcatel-lucent.com
Date: Tuesday, March 31, 2015 at 7:28 PM
To: 
draft-ietf-l2vpn-pbb-e...@tools.ietf.orgmailto:draft-ietf-l2vpn-pbb-e...@tools.ietf.org
 
draft-ietf-l2vpn-pbb-e...@tools.ietf.orgmailto:draft-ietf-l2vpn-pbb-e...@tools.ietf.org
Cc: bess@ietf.orgmailto:bess@ietf.org bess@ietf.orgmailto:bess@ietf.org
Subject: [bess] PBB-EVPN draft - use of sticky bit in mac mobility ext. com.

Dear authors,

In PBB-EVPN we advertise PE shared BMACs or dedicated (per-ES) BMACs. Either 
way, I believe it is a good practice to advertise them as ’static’ i.e. along 
with the ’sticky’ bit. That provides a natural protection against BMACs that 
might be learnt locally and are not ‘managed’.

In RFC7432, when the sticky bit is set, the sequence number is zero.
For PBB-EVPN, that means that when shared BMACs are used and per-ISID load 
balancing multihoming is in place, the shared BMACs cannot be advertised as 
static (since the sequence number is used as a CMAC flush notification).

Since the PE BMACs are not subject to mobility procedures and are by nature 
‘static’ and managed, would it be possible to explicitly allow in the pbb-evpn 
draft the advertisement of the sticky bit along with a sequence number, when 
the mac-mobility extended community is used for CMAC flush notification?

This can be optional and would allow an extra level of security in a PBB-EVPN 
network.
If you agree with that, I can provide a text if needed.

Looking forward to your feedback.
Thank you.
Jorge
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

[bess] PBB-EVPN draft - use of sticky bit in mac mobility ext. com.

[Rabadan, Jorge (Jorge)]

Dear authors,

In PBB-EVPN we advertise PE shared BMACs or dedicated (per-ES) BMACs. Either 
way, I believe it is a good practice to advertise them as ’static’ i.e. along 
with the ’sticky’ bit. That provides a natural protection against BMACs that 
might be learnt locally and are not ‘managed’.

In RFC7432, when the sticky bit is set, the sequence number is zero.
For PBB-EVPN, that means that when shared BMACs are used and per-ISID load 
balancing multihoming is in place, the shared BMACs cannot be advertised as 
static (since the sequence number is used as a CMAC flush notification).

Since the PE BMACs are not subject to mobility procedures and are by nature 
‘static’ and managed, would it be possible to explicitly allow in the pbb-evpn 
draft the advertisement of the sticky bit along with a sequence number, when 
the mac-mobility extended community is used for CMAC flush notification?

This can be optional and would allow an extra level of security in a PBB-EVPN 
network.
If you agree with that, I can provide a text if needed.

Looking forward to your feedback.
Thank you.
Jorge
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] ARP ND draft

[Rabadan, Jorge (Jorge)]

Hi Robert and Tony,

As Wim mentioned, ipv6 anycast is something that we will add to the draft in 
the next rev. There is an easy way to know if a given proxy-ND entry belongs to 
an anycast address or not and disable the duplicate IP detection for those.

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

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.
Thanks.
Jorge


From: Antoni Przygienda 
antoni.przygie...@ericsson.commailto:antoni.przygie...@ericsson.com
Date: Monday, March 30, 2015 at 12:12 AM
To: Robert Raszuk rob...@raszuk.netmailto:rob...@raszuk.net, Henderickx, 
Wim (Wim) 
wim.henderi...@alcatel-lucent.commailto:wim.henderi...@alcatel-lucent.com
Cc: Erik Nordmark nordm...@acm.orgmailto:nordm...@acm.org, 
bess@ietf.orgmailto:bess@ietf.org bess@ietf.orgmailto:bess@ietf.org, 
Jorge Rabadan 
jorge.raba...@alcatel-lucent.commailto:jorge.raba...@alcatel-lucent.com
Subject: RE: [bess] ARP ND draft

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 Twainhttp://www.brainyquote.com/quotes/quotes/m/marktwain393535.html

From: rras...@gmail.commailto: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.orgmailto: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) 
wim.henderi...@alcatel-lucent.commailto: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: Henderickx, Wim Henderickx
Date: Monday 30 March 2015 07:38
To: Robert Raszuk
Cc: Erik Nordmark, Antoni Przygienda, bess@ietf.orgmailto: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 
rob...@raszuk.netmailto: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) 
wim.henderi...@alcatel-lucent.commailto: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 
antoni.przygie...@ericsson.commailto: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

Re: [bess] ARP ND draft

[Rabadan, Jorge (Jorge)]

Hey Tony,

Thank you for your comments.
Please see in-line.

-Original Message-
From: Antoni Przygienda antoni.przygie...@ericsson.com
Date: Monday, March 30, 2015 at 12:26 AM
To: Jorge Rabadan jorge.raba...@alcatel-lucent.com, Erik Nordmark
nordm...@acm.org, Henderickx, Wim (Wim)
wim.henderi...@alcatel-lucent.com
Cc: bess@ietf.org bess@ietf.org
Subject: Re: [bess] ARP ND draft

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.

[JORGE] at the moment the draft is Informational and it only includes the
IXP use-case, but based on the feedback we will extend it to the DC
use-case. 

 

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

[JORGE] Thank you for your feedback. This is based on an existing
implementation/shipping code and the result of the issues we found when
implementing proxy-arp/nd for EVPN.


 

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

[JORGE] I am personally a bit reluctant to use “MUST” in this draft, since
the use-cases can be very different. You are highlighting one example.

 

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

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


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?

 

  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?

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


 
  c)It is worth explaining what the suggested behavior should be when
  ‘local-bit’ MACs are being 

Re: [bess] [BESS] Comment to draft-ietf-bess-evpn-usage-00.txt

[Rabadan, Jorge (Jorge)]

Hi Shunwan,

A ‘set’ of A-D routes is used due to the reason you mention. It is indicated in 
the draft too: 'it has to be a set of routes so that the total number of RTs 
can be conveyed’.
The use of different RDs per route is implicit, as per RFC7432:

Advertising a set of Ethernet A-D per ES routes
   for the ES allows each route to contain a subset of the complete set
   of RTs.  Each Ethernet A-D per ES route is differentiated from the
   other routes in the set by a different Route Distinguisher (RD).'

We did not think it was necessary to add that to the evpn-usage draft since it 
is part of the RFC7432, but let us know if you think it helps to add a sentence.

Thank you.
Jorge

From: Zhuangshunwan zhuangshun...@huawei.commailto:zhuangshun...@huawei.com
Date: Friday, March 27, 2015 at 2:52 AM
To: bess@ietf.orgmailto:bess@ietf.org bess@ietf.orgmailto:bess@ietf.org
Subject: [bess] [BESS] Comment to draft-ietf-bess-evpn-usage-00.txt


Dear Authors,

I have a comment, see inline with [Shunwan].

5.2.1. Service startup procedures

   As soon as the EVIs are created in PE1, PE2 and PE3, the following
   control plane actions are carried out:

   o Flooding tree setup per EVI (4k routes): Each PE will send one
 Inclusive Multicast Ethernet Tag route per EVI (up to 4k routes per
 PE) so that the flooding tree per EVI can be setup. Note that
 ingress replication, P2MP LSPs or MP2MP LSPs can optionally be
 signaled in the PMSI Tunnel attribute and the corresponding tree be
 created.

   o Ethernet A-D routes per ESI (a set of routes for ESI12): A set of
 A-D routes with a list of 4k RTs (one per EVI) for ESI12 will be
 issued from PE1 and PE2 (it has to be a set of routes so that the
 total number of RTs can be conveyed). This set will also include

[Shunwan]:
Sorry, maybe I miss something about this feature, I just don’t know how to 
convey a bgp route with 4k RTs.
The BGP specification mandates a maximum BGP message size of 4096 octets, so a 
bgp route can only carry approximately 500 RTs once.
If we send one Ethernet A-D route per ESI with 4k RTs using a set of routes 
(Each route carrying a sub-set of 4K RTs) , because such set of routes have the 
same NLRI, in line with the behavior of BGP [RFC4271], the last route will 
override the previous routes, so the receiver PE can only maintain the last one 
other than a set of routes for one Ethernet A-D route with 4k RTs.

If I miss something, please let me know, thanks.


Rabadan-Palislamovic et al.Expires May 17, 2015[Page 11]


Internet-Draft EVPN Usage  November 13, 2014


 ESI Label extended communities with the active-standby flag set to
 zero (all-active multi-homing type) and an ESI Label different from
 zero (used for split-horizon functions). These routes will be
 imported by the three PEs, since the RTs match the EVI RTs locally
 configured. The A-D routes per ESI will be used for fast
 convergence and split-horizon functions, as discussed in [EVPN].



Regards,

Shunwan



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

Re: [bess] Handshaking among PEs in an EVPN ES based on Paxos algorithm

[Rabadan, Jorge (Jorge)]

Hi Weiguo,

About this:

[weiguo]: Traffic duplication and loop issue both exist in dual DF PE
case. In multi-homed device case, say CE1 is multi-homed to PE1 and PE2
and both PE are DF PE. When CE1 sends traffic to PE1, the traffic will
loop back to CE1 through PE2. If CE1 can filter and drop the traffic , it
is fortunate, maybe no loop.
For multi-homed network scenario, say local network1(CE1 and CE2) is
multi-homed to PE1 and PE2. Similarly, the traffic from CE1 will loop back
through PE1--PE2--CE2, it is very serious. It is absolutely not allowed.


[JORGE] In a MH device case: CE1-BUM-PE1-(ESI-label+BUM)-PE2. PE2 will
not send the traffic back to CE1 due to the ESI-label and split-horizon
procedures.
In MH network case PE2 will NOT send the traffic to CE2 for the same
reason.

Let me know if you disagree please.

Thanks.
Jorge

-Original Message-
From: Haoweiguo haowei...@huawei.com
Date: Thursday, March 26, 2015 at 9:55 PM
To: Satya Mohanty (satyamoh) satya...@cisco.com,
thomas.mo...@orange.com thomas.mo...@orange.com, bess@ietf.org
bess@ietf.org
Subject: Re: [bess] Handshaking among PEs in an EVPN ES based on Paxos
algorithm

Hi Satya,
Pls see inline.

Thanks,
weiguo


From: Satya Mohanty (satyamoh) [satya...@cisco.com]
Sent: Friday, March 27, 2015 12:11
To: Haoweiguo; thomas.mo...@orange.com; bess@ietf.org
Subject: Re: [bess] Handshaking among PEs in an EVPN ES based on Paxos
algorithm

Thomas,

Thanks for your summary. It captures the essence of the discussion.
[weiguo]: Yes, i agree.

One feature of the HRW scheme is that it computes the Active and the
Backup DF upfront.
Whenever the Active PE, say PE1, dies;
the Backup PE, PE2, can become the
Active immediately upon receiving the withdraw of the ES route from PE1.
It need not even have to wait for the 3 seconds time.
[weiguo]: I think maybe your negligence, dies PE1 can't send withdraw
message:) But when PE1 leaves ESI, it can withdraw the ES route
immediately.
When PE1 dies and recovers, assuming PE1 is DF PE, then PE1 and PE2 will
both act as PE for some transiet time.

On the other hand, the 3 second timer will serve as a bulk and batch
mechanism for the case when new PE(s) is(are) coming up, so we don¹t have
to do a DF election ever so often.

Haoweiguo,  I think the loop scenario is speculative.
I think everybody understands that, yes, there may be some transient
duplication of bum traffic; however, there is no loop problem to be
solved.
[weiguo]: Traffic duplication and loop issue both exist in dual DF PE
case. In multi-homed device case, say CE1 is multi-homed to PE1 and PE2
and both PE are DF PE. When CE1 sends traffic to PE1, the traffic will
loop back to CE1 through PE2. If CE1 can filter and drop the traffic , it
is fortunate, maybe no loop.
For multi-homed network scenario, say local network1(CE1 and CE2) is
multi-homed to PE1 and PE2. Similarly, the traffic from CE1 will loop
back through PE1--PE2--CE2, it is very serious. It is absolutely not
allowed.

Thanks,
--Satya



On 3/26/15 9:08 PM, Haoweiguo haowei...@huawei.com wrote:

Hi Thomas,
I know you are neutral, sorry for my reply vulnerable to be miunderstood.

Thanks,
weiguo


From: thomas.mo...@orange.com [thomas.mo...@orange.com]
Sent: Friday, March 27, 2015 11:59
To: Haoweiguo; bess@ietf.org
Subject: Re: [bess] Handshaking among PEs in an EVPN ES based on Paxos
algorithm

Hi Weiguo,

2015-03-26, Haoweiguo:
  Thomas:
  - RFC7432 may have transient periods where the DF election state is
  not yet synchronized between the two peers:
 
 [weiguo]: Yes, i think RFC 7432 has transient periods of traffic loop

Note well that I didn't write that there can be transient _loops_ .
I tried to capture the exchange you had all, and what I gather is that
the split-horizon procedure _prevents_loops_, independently of any
transient period where DF state is not synchronized and which may lead
to transient _duplicates_.

-Thomas


 26/03/2015 20:05, John E Drake :

 Weiguo,

 I guess I wasn¹t clear.  I think you draft, for the reasons I have
 detailed, is a non-solution to a non-problem with tremendous control
 plane cost.

 Yours Irrespectively,

 John

 *From:*Haoweiguo [mailto:haowei...@huawei.com]
 *Sent:* Thursday, March 26, 2015 6:17 PM
 *To:* John E Drake; Patrice Brissette (pbrisset)
 *Cc:* Ali Sajassi (sajassi); bess@ietf.org
 *Subject:* RE: [bess] Handshaking among PEs in an EVPN ES based on
 Paxos algorithm

 Pls see below.

 Thanks,

 weiguo


---
-

 *From:*John E Drake [jdr...@juniper.net]
 *Sent:* Friday, March 27, 2015 6:00
 *To:* Haoweiguo; Patrice Brissette (pbrisset)
 *Cc:* Ali Sajassi (sajassi); bess@ietf.org mailto:bess@ietf.org
 *Subject:* RE: [bess] Handshaking among PEs in an EVPN ES based on
 Paxos algorithm

 To recap,

 We have established that your proposal is untenable because of its
 control plane load.

 We 

Re: [bess] Handshaking among PEs in an EVPN ES based on Paxos algorithm

[Rabadan, Jorge (Jorge)]

Hi Weiguo,

OK, thanks for clarifying, that is the part I did not understand in your
loop :-)

To me a loop means you send a frame and that frame keeps being forwarded
by the same nodes indefinitely till you take a corrective action.
In this case, CE3 might get a few packets during the transient state, but
those packets will have its own MAC SA so CE3 will discard them. I don’t
think that is harmful for CE3 in most of the cases. And if it is, you just
need to make sure the timers are long enough and the DF election properly
implemented to avoid the transient DF-DF state.

The handshaking is definitely overkilling IMHO.

Thanks.
Jorge

-Original Message-
From: Haoweiguo haowei...@huawei.com
Date: Friday, March 27, 2015 at 7:29 AM
To: Jorge Rabadan jorge.raba...@alcatel-lucent.com, Satya Mohanty
(satyamoh) satya...@cisco.com, thomas.mo...@orange.com
thomas.mo...@orange.com, bess@ietf.org bess@ietf.org
Subject: Re: [bess] Handshaking among PEs in an EVPN ES based on Paxos
algorithm

Hi Jorge,
Sorry, maybe i have not explain clearly, pls allow me to clarify it more
clearly.
In MHN case, assuming CE1 and CE2 are multti-homed to PE1 and PE2, CE2 is
single homed to remote PE3. CE1 and CE2 forms one layer 2 network, so it
multi-homed network scenario.
   CE3
 |
PE3


PE1  PE2
  |   |
CE1---CE2

In transiet period, PE1 and PE2 are both DF PE. At this time, CE3 sends
BUM traffic to CE1, the traffic will reach PE1 and PE2, CE1 will receive
two copy of the traffic from CE3, also loop is formed, the form path:

CE3PE3PE2CE2CE1PE1---PE3---CE3

I think the traffic loop is absolutely not allowed. In MHN case, the loop
will formed due to dual-DF PE in transiet period.

Thanks,
weiguo




From: Rabadan, Jorge (Jorge) [jorge.raba...@alcatel-lucent.com]
Sent: Friday, March 27, 2015 20:26
To: Haoweiguo; Satya Mohanty (satyamoh); thomas.mo...@orange.com;
bess@ietf.org
Subject: Re: [bess] Handshaking among PEs in an EVPN ES based on Paxos
algorithm

Hi Weiguo,

About this:

[weiguo]: Traffic duplication and loop issue both exist in dual DF PE
case. In multi-homed device case, say CE1 is multi-homed to PE1 and PE2
and both PE are DF PE. When CE1 sends traffic to PE1, the traffic will
loop back to CE1 through PE2. If CE1 can filter and drop the traffic , it
is fortunate, maybe no loop.
For multi-homed network scenario, say local network1(CE1 and CE2) is
multi-homed to PE1 and PE2. Similarly, the traffic from CE1 will loop back
through PE1--PE2--CE2, it is very serious. It is absolutely not allowed.


[JORGE] In a MH device case: CE1-BUM-PE1-(ESI-label+BUM)-PE2. PE2 will
not send the traffic back to CE1 due to the ESI-label and split-horizon
procedures.
In MH network case PE2 will NOT send the traffic to CE2 for the same
reason.

Let me know if you disagree please.

Thanks.
Jorge

-Original Message-
From: Haoweiguo haowei...@huawei.com
Date: Thursday, March 26, 2015 at 9:55 PM
To: Satya Mohanty (satyamoh) satya...@cisco.com,
thomas.mo...@orange.com thomas.mo...@orange.com, bess@ietf.org
bess@ietf.org
Subject: Re: [bess] Handshaking among PEs in an EVPN ES based on Paxos
algorithm

Hi Satya,
Pls see inline.

Thanks,
weiguo


From: Satya Mohanty (satyamoh) [satya...@cisco.com]
Sent: Friday, March 27, 2015 12:11
To: Haoweiguo; thomas.mo...@orange.com; bess@ietf.org
Subject: Re: [bess] Handshaking among PEs in an EVPN ES based on Paxos
algorithm

Thomas,

Thanks for your summary. It captures the essence of the discussion.
[weiguo]: Yes, i agree.

One feature of the HRW scheme is that it computes the Active and the
Backup DF upfront.
Whenever the Active PE, say PE1, dies;
the Backup PE, PE2, can become the
Active immediately upon receiving the withdraw of the ES route from PE1.
It need not even have to wait for the 3 seconds time.
[weiguo]: I think maybe your negligence, dies PE1 can't send withdraw
message:) But when PE1 leaves ESI, it can withdraw the ES route
immediately.
When PE1 dies and recovers, assuming PE1 is DF PE, then PE1 and PE2 will
both act as PE for some transiet time.

On the other hand, the 3 second timer will serve as a bulk and batch
mechanism for the case when new PE(s) is(are) coming up, so we don¹t have
to do a DF election ever so often.

Haoweiguo,  I think the loop scenario is speculative.
I think everybody understands that, yes, there may be some transient
duplication of bum traffic; however, there is no loop problem to be
solved.
[weiguo]: Traffic duplication and loop issue both exist in dual DF PE
case. In multi-homed device case, say CE1 is multi-homed to PE1 and PE2
and both PE are DF PE. When CE1 sends traffic to PE1, the traffic will
loop back to CE1 through PE2. If CE1 can filter and drop the traffic , it
is fortunate, maybe no loop.
For multi-homed network scenario, say local network1(CE1 and CE2) is
multi-homed

Re: [bess] Handshaking among PEs in an EVPN ES based on Paxos algorithm

[Rabadan, Jorge (Jorge)]

Hi Weiguo,

As I said:
Even if CE3 forwards to CE4-PE4, PE4 is NDF and will discard the frame.
Remember MH network ES' as per your diagram below, only support
single-active MH.”

So there is NO LOOP.

If you have any other scenario, let’s talk offline. We are boring people
;-)


Thanks.
Jorge

-Original Message-
From: Haoweiguo haowei...@huawei.com
Date: Friday, March 27, 2015 at 9:00 AM
To: Jorge Rabadan jorge.raba...@alcatel-lucent.com, Satya Mohanty
(satyamoh) satya...@cisco.com, thomas.mo...@orange.com
thomas.mo...@orange.com, bess@ietf.org bess@ietf.org
Subject: Re: [bess] Handshaking among PEs in an EVPN ES based on Paxos
algorithm

Hi Jorge,
The picture in email is just for a simplified explanation. Source MAC can
be the layer 3 device connecting to CE3, CE3 will not drop the frame so
easily. This is an absolutely loop.

Thanks,
weiguo


From: Rabadan, Jorge (Jorge) [jorge.raba...@alcatel-lucent.com]
Sent: Friday, March 27, 2015 23:39
To: Haoweiguo; Satya Mohanty (satyamoh); thomas.mo...@orange.com;
bess@ietf.org
Subject: Re: [bess] Handshaking among PEs in an EVPN ES based on Paxos
algorithm

Hi Weiguo,

I disagree with your explanation below.

This is the flow assuming PE1-PE2 *might* be both DF and PE3 is DF:

CE3---PE3--PE2---CE2CE1PE1PE3--CE3——DROP

If the MAC SA of the frame is CE3’s MAC, CE3 will discard.
Even if CE3 forwards to CE4-PE4, PE4 is NDF and will discard the frame.
Remember MH network ES' as per your diagram below, only support
single-active MH.


Thanks.
Jorge

-Original Message-
From: Haoweiguo haowei...@huawei.com
Date: Friday, March 27, 2015 at 8:11 AM
To: Jorge Rabadan jorge.raba...@alcatel-lucent.com, Satya Mohanty
(satyamoh) satya...@cisco.com, thomas.mo...@orange.com
thomas.mo...@orange.com, bess@ietf.org bess@ietf.org
Subject: RE: [bess] Handshaking among PEs in an EVPN ES based on Paxos
algorithm

Hi Jorge,
Let give you another indefinitely forwarding loop case, the picture is as
follows:

CE3CE4
  ||
PE3   PE4



PE1   PE2
 | |
CE1CE2

If PE1 and PE2 are dual DF PE in transiet time, assuing PE3 and PE4 are
in stable state ,PE3 is DF PE, PE4 is non-DF PE, the BUM traffic from CE3
to CE1, the forwarding loop path is as follows;
CE3---PE3--PE2---CE2CE1PE1PE3--CE3--CE4---PE4---
-
forever..

Do you think the harm is enough?
Thanks,
weiguo

From: Rabadan, Jorge (Jorge) [jorge.raba...@alcatel-lucent.com]
Sent: Friday, March 27, 2015 22:59
To: Haoweiguo; Satya Mohanty (satyamoh); thomas.mo...@orange.com;
bess@ietf.org
Subject: Re: [bess] Handshaking among PEs in an EVPN ES based on Paxos
algorithm

Hi Weiguo,

OK, thanks for clarifying, that is the part I did not understand in your
loop :-)

To me a loop means you send a frame and that frame keeps being forwarded
by the same nodes indefinitely till you take a corrective action.
In this case, CE3 might get a few packets during the transient state, but
those packets will have its own MAC SA so CE3 will discard them. I don’t
think that is harmful for CE3 in most of the cases. And if it is, you
just
need to make sure the timers are long enough and the DF election properly
implemented to avoid the transient DF-DF state.

The handshaking is definitely overkilling IMHO.

Thanks.
Jorge

-Original Message-
From: Haoweiguo haowei...@huawei.com
Date: Friday, March 27, 2015 at 7:29 AM
To: Jorge Rabadan jorge.raba...@alcatel-lucent.com, Satya Mohanty
(satyamoh) satya...@cisco.com, thomas.mo...@orange.com
thomas.mo...@orange.com, bess@ietf.org bess@ietf.org
Subject: Re: [bess] Handshaking among PEs in an EVPN ES based on Paxos
algorithm

Hi Jorge,
Sorry, maybe i have not explain clearly, pls allow me to clarify it more
clearly.
In MHN case, assuming CE1 and CE2 are multti-homed to PE1 and PE2, CE2
is
single homed to remote PE3. CE1 and CE2 forms one layer 2 network, so it
multi-homed network scenario.
   CE3
 |
PE3


PE1  PE2
  |   |
CE1---CE2

In transiet period, PE1 and PE2 are both DF PE. At this time, CE3 sends
BUM traffic to CE1, the traffic will reach PE1 and PE2, CE1 will receive
two copy of the traffic from CE3, also loop is formed, the form path:

CE3PE3PE2CE2CE1PE1---PE3---CE3

I think the traffic loop is absolutely not allowed. In MHN case, the
loop
will formed due to dual-DF PE in transiet period.

Thanks,
weiguo




From: Rabadan, Jorge (Jorge) [jorge.raba...@alcatel-lucent.com]
Sent: Friday, March 27, 2015 20:26
To: Haoweiguo; Satya Mohanty (satyamoh); thomas.mo...@orange.com;
bess@ietf.org
Subject: Re: [bess] Handshaking among PEs in an EVPN ES based on Paxos
algorithm

Hi Weiguo,

About this:

[weiguo]: Traffic duplication and loop issue both exist

Re: [bess] Handshaking among PEs in an EVPN ES based on Paxos algorithm

[Rabadan, Jorge (Jorge)]

Thanks for the reference Thomas.
As I was saying in my email, this prevents the loop in Weiguo’s diagram,
since only single-active is supported in Weiguo’s example.

Thank you.
Jorge


-Original Message-
From: thomas.mo...@orange.com thomas.mo...@orange.com
Organization: Orange
Date: Friday, March 27, 2015 at 8:40 AM
To: bess@ietf.org bess@ietf.org
Subject: Re: [bess] Handshaking among PEs in an EVPN ES based on Paxos
algorithm

HI Weigo, all,

Let me try to help again...

RFC7432, section 8.5 says:

If a bridged network is multihomed to more than one PE in an EVPN
network via switches, then the support of All-Active redundancy mode
requires the bridged network to be connected to two or more PEs using
a LAG.

If a bridged network does not connect to the PEs using a LAG, then
only one of the links between the bridged network and the PEs must be
the active link for a given ES, VLAN or ES, VLAN bundle.  In this
case, the set of Ethernet A-D per ES routes advertised by each PE
MUST have the Single-Active bit in the flags of the ESI Label
extended community set to 1.

My understanding was that the above excludes the kind of topology in
which you exclude a possible loop.

-Thomas



Weiguo :
 Hi John,
 If you can tolerate indefinite forwarding loop during transiet time, i
have no problem. If the community think it is a serious problem, i think
we must propose an applicable solution for it, maybe there are other
solutions better than handshaking mechanism.

 Thanks,
 weiguo

 
 From: John E Drake [jdr...@juniper.net]
 Sent: Friday, March 27, 2015 23:22
 To: Haoweiguo; Rabadan, Jorge (Jorge); Satya Mohanty (satyamoh); EXT -
thomas.mo...@orange.com; bess@ietf.org
 Subject: RE: [bess] Handshaking among PEs in an EVPN ES based on Paxos
algorithm

 I think we have beaten this topic to death.  For the numerous reason
I've given, I'm not interested in you proposal.

 Yours Irrespectively,

 John

 -Original Message-
 From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Haoweiguo
 Sent: Friday, March 27, 2015 11:12 AM
 To: Rabadan, Jorge (Jorge); Satya Mohanty (satyamoh); EXT -
 thomas.mo...@orange.com; bess@ietf.org
 Subject: Re: [bess] Handshaking among PEs in an EVPN ES based on Paxos
 algorithm

 Hi Jorge,
 Let give you another indefinitely forwarding loop case, the picture is
as
 follows:

 CE3CE4
||
 PE3   PE4



 PE1   PE2
   | |
 CE1CE2

 If PE1 and PE2 are dual DF PE in transiet time, assuing PE3 and PE4
are in
 stable state ,PE3 is DF PE, PE4 is non-DF PE, the BUM traffic from CE3
to CE1,
 the forwarding loop path is as follows;
 
CE3---PE3--PE2---CE2CE1PE1PE3--CE3--CE4---PE4--
--
 forever..
 Do you think the harm is enough?
 Thanks,
 weiguo
 
 From: Rabadan, Jorge (Jorge) [jorge.raba...@alcatel-lucent.com]
 Sent: Friday, March 27, 2015 22:59
 To: Haoweiguo; Satya Mohanty (satyamoh); thomas.mo...@orange.com;
 bess@ietf.org
 Subject: Re: [bess] Handshaking among PEs in an EVPN ES based on Paxos
 algorithm

 Hi Weiguo,

 OK, thanks for clarifying, that is the part I did not understand in
your loop :-)

 To me a loop means you send a frame and that frame keeps being
forwarded
 by the same nodes indefinitely till you take a corrective action.
 In this case, CE3 might get a few packets during the transient state,
but those
 packets will have its own MAC SA so CE3 will discard them. I don't
think that is
 harmful for CE3 in most of the cases. And if it is, you just need to
make sure
 the timers are long enough and the DF election properly implemented to
 avoid the transient DF-DF state.

 The handshaking is definitely overkilling IMHO.

 Thanks.
 Jorge

 -Original Message-
 From: Haoweiguo haowei...@huawei.com
 Date: Friday, March 27, 2015 at 7:29 AM
 To: Jorge Rabadan jorge.raba...@alcatel-lucent.com, Satya Mohanty
 (satyamoh) satya...@cisco.com, thomas.mo...@orange.com
 thomas.mo...@orange.com, bess@ietf.org bess@ietf.org
 Subject: Re: [bess] Handshaking among PEs in an EVPN ES based on Paxos
 algorithm

 Hi Jorge,
 Sorry, maybe i have not explain clearly, pls allow me to clarify it
 more clearly.
 In MHN case, assuming CE1 and CE2 are multti-homed to PE1 and PE2, CE2
 is single homed to remote PE3. CE1 and CE2 forms one layer 2 network,
 so it multi-homed network scenario.
CE3
  |
 PE3


 PE1  PE2
   |   |
 CE1---CE2

 In transiet period, PE1 and PE2 are both DF PE. At this time, CE3
sends
 BUM traffic to CE1, the traffic will reach PE1 and PE2, CE1 will
 receive two copy of the traffic from CE3, also loop is formed, the
form path:

 CE3PE3PE2CE2CE1PE1---PE3---CE3

 I think the traffic loop is absolutely not allowed. In MHN case, the
 loop

Re: [bess] EVPN Draft Comments

[Rabadan, Jorge (Jorge)]

Fully agree with John.
Thanks.
Jorge

-Original Message-
From: John E Drake jdr...@juniper.net
Date: Monday, February 2, 2015 at 12:41 PM
To: Russ White ru...@riw.us, Jorge Rabadan
jorge.raba...@alcatel-lucent.com
Cc: bess@ietf.org bess@ietf.org
Subject: RE: [bess] EVPN Draft Comments

Russ,

Comments inline.  

Yours Irrespectively,

John

 -Original Message-
 From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Russ White
 Sent: Monday, February 02, 2015 3:02 PM
 To: Rabadan, Jorge (Jorge)
 Cc: bess@ietf.org
 Subject: Re: [bess] EVPN Draft Comments
 
 
 If the length of the layer 2 address is fixed, there is no way to
accommodate
 future use cases regardless of the inclusion of a length field. The way
the
 draft is written, it would be justifiable to ignore the length field,
destroying
 future expansion. Adding a length field to a fixed length filed doesn't
mean
 the length of the fixed length field can change -- otherwise it
wouldn't be
 fixed length.


[JD]  What RFC 7432 actually says is:  The MAC Address Length field is
in bits, and it is set to 48.
MAC address length values other than 48 bits are outside the scope of
this document.  So,
The MAC Address field is a variable length field whose length is
currently set to 48.

 
 
 The aliasing procedure, to me,says we didn't think through these
 relationships well, so let's throw in a way to get around the
limitations we put
 into the original draft. This isn't an elegant solution.


[JD]  Just because you don't like/understand it doesn't necessarily mean
it's wrong.


 
 If the esi must be unique, and it's important, then the esi must be
unique as
 used. Using a non-unique part of the esi destroys the point of building
a
 unique esi in the first place.


[JD]  The ESI is unique.  The ES-Import RT is not.  This means that some
PEs may import an Ethernet Segment route
that are not attached to the ES specified in the Ethernet Segment route.
When they examine the Ethernet Segment
route they will realize this and discard it.
 

 
 Two of these are going to be problems in real world deployments, and
need,
 imho, to be fixed in a bis.
 
 :-)
 
 Russ
 
 
  On Feb 2, 2015, at 10:39 AM, Rabadan, Jorge (Jorge)
 jorge.raba...@alcatel-lucent.com wrote:
 
  Hi Russ,
 
  Since we are I think in agreement this must NOT hold the process, I
  give you my 2 cents if I may...
 
  Section 7.2 - the mac length field is fixed in EVPN to 48, but it has
  to be there to allow future use-cases. For instance, it might make
  sense to use variable mac lengths in PBB-EVPN since the BMACs are
 operator-managed.
 
 
  Section 7.6 - this is not an issue to me. The ESI has to be unique in
  the network. The mechanisms to auto-derive the ESI can only be used if
  they guarantee the uniqueness of the ESI. And since the ES-import
  route-target is a route-target, its value can only be present on the
  PEs where you want to import the route. I don’t think there is a need
  for clarification of the text.
 
  Also, I think aliasing is a great thing to support.
 
  Thanks.
  Jorge
 
 
  -Original Message-
  From: Russ White ru...@riw.us
  Date: Monday, February 2, 2015 at 5:42 AM
  To: bess@ietf.org bess@ietf.org
  Subject: [bess] EVPN Draft Comments
 
  Y'all:
 
  I know this is in auth-48 (or maybe past), but I've been through
  these docs a number of times, and still come up with questions that I
  think need to be addressed/answered at some point. In general, eVPN
  seems to be on the receiving end of I can imagine a lot of different
  use cases, some of which are self-contradictory, but let's just throw
  it all in the bucket anyway, regardless of the complexity and other
  problems. But, aside from that -- some specific comments on the base
  draft --
 
  ==
  Section 7.2
 
  The MAC address field in the TLV is specified as 6 octets, but there
  is also a MAC address length field -- normally you would only include
  a length field if the field itself is variable length, which doesn't
  appear to be the case here. Is there some specific reason a length
  field is included, and the length of the field is specified?
 
  ==
  Section 7.6
 
  This is a new transitive Route Target extended community carried with
  the Ethernet Segment route. When used, it enables all the PEs
  connected to the same multi-homed site to import the Ethernet Segment
  routes. The value is derived automatically from the ESI by encoding
  the high order 6-octet portion of the 9-octet ESI Value in the
  ESImport Route Target. The high order 6-octet of the ESI incorporates
  MAC address of ESI (for type 1, 2, and 3) which when encoded in this
  RT and used in the RT constrain feature, it enables proper
  routetarget filtering. The format of this extended community is as
  follows:
 
  However, the high order 6 octet portion of the ESI is not unique --
  the section on forming the ESI actually includes instructions that
  would mean multiple ESIs with the same higher order 6 octet. When

Re: [bess] EVPN Draft Comments

[Rabadan, Jorge (Jorge)]

Hi Russ,

Since we are I think in agreement this must NOT hold the process, I give
you my 2 cents if I may...

Section 7.2 - the mac length field is fixed in EVPN to 48, but it has to
be there to allow future use-cases. For instance, it might make sense to
use variable mac lengths in PBB-EVPN since the BMACs are operator-managed.


Section 7.6 - this is not an issue to me. The ESI has to be unique in the
network. The mechanisms to auto-derive the ESI can only be used if they
guarantee the uniqueness of the ESI. And since the ES-import route-target
is a route-target, its value can only be present on the PEs where you want
to import the route. I don’t think there is a need for clarification of
the text.

Also, I think aliasing is a great thing to support.

Thanks.
Jorge
 

-Original Message-
From: Russ White ru...@riw.us
Date: Monday, February 2, 2015 at 5:42 AM
To: bess@ietf.org bess@ietf.org
Subject: [bess] EVPN Draft Comments

Y'all:

I know this is in auth-48 (or maybe past), but I've been through these
docs
a number of times, and still come up with questions that I think need to
be
addressed/answered at some point. In general, eVPN seems to be on the
receiving end of I can imagine a lot of different use cases, some of
which
are self-contradictory, but let's just throw it all in the bucket anyway,
regardless of the complexity and other problems. But, aside from that --
some specific comments on the base draft --

==
Section 7.2

The MAC address field in the TLV is specified as 6 octets, but there is
also
a MAC address length field -- normally you would only include a length
field
if the field itself is variable length, which doesn't appear to be the
case
here. Is there some specific reason a length field is included, and the
length of the field is specified?

==
Section 7.6

This is a new transitive Route Target extended community carried with
the Ethernet Segment route. When used, it enables all the PEs
connected to the same multi-homed site to import the Ethernet Segment
routes. The value is derived automatically from the ESI by encoding
the high order 6-octet portion of the 9-octet ESI Value in the ESImport
Route Target. The high order 6-octet of the ESI incorporates
MAC address of ESI (for type 1, 2, and 3) which when encoded in this
RT and used in the RT constrain feature, it enables proper routetarget
filtering. The format of this extended community is as
follows:

However, the high order 6 octet portion of the ESI is not unique -- the
section on forming the ESI actually includes instructions that would mean
multiple ESIs with the same higher order 6 octet. When we're dealing with
MAC addresses and overlapping IP address sets, it will be problematic to
install destinations from one ESI into the MAC-VRF in another ESI.

This is related to section 8.1.1, as well, which deals with route
filtering.

==
8.2.1

Throughout most of the document, the ESI is described as being 9 octets.
Here it is described as being 10 octets. No explanation is given.

==
8.4

The entire concept of aliasing appears dangerous to me. It would have been
better to separate the MAC address from the EVI in two separate
advertisements, making reachability to the MAC address in reference to the
EVI, and reachabality to the EVI it's own thing, rather than tying the
two
together and then creating an alias.

==
8.5

The definition of service carving is buried in the text in the middle of
section 8.5. Shouldn't this be included in the glossary, at least?

==
8.5

In step 3 of DF election, the list of IP addresses is ordered in
increasing
numeric value. What if you have a mix of v4 and v6 addresses?

==

:-)

Russ

___
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] Tunnel question for ESI next-hop in draft evpn prefix-advert

[Rabadan, Jorge (Jorge)]

Tony,

Please see in-line.
Thanks for your comments.

From: Antoni Przygienda 
antoni.przygie...@ericsson.commailto:antoni.przygie...@ericsson.com
Date: Wednesday, January 14, 2015 at 5:40 PM
To: Jorge Rabadan 
jorge.raba...@alcatel-lucent.commailto:jorge.raba...@alcatel-lucent.com, 
Henderickx, Wim (Wim) 
wim.henderi...@alcatel-lucent.commailto:wim.henderi...@alcatel-lucent.com, 
flo...@nuagenetworks.netmailto:flo...@nuagenetworks.net 
flo...@nuagenetworks.netmailto:flo...@nuagenetworks.net, Ali Sajassi 
(sajassi) (saja...@cisco.commailto:saja...@cisco.com) 
saja...@cisco.commailto:saja...@cisco.com
Cc: bess@ietf.orgmailto:bess@ietf.org bess@ietf.orgmailto:bess@ietf.org
Subject: RE: Tunnel question for ESI next-hop in draft evpn prefix-advert

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.



[JORGE] will clarify the figure in the next rev. I’m ok to add the router’s mac 
ext-comm as I said in a separate thread. For the next rev, I will share a text 
with you and my co-authors and we can discuss it before publishing.






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.

[JORGE] see above.

___
BESS mailing list
BESS@ietf.org

Re: [bess] 答复: Comments on draft draft-rabadan-bess-dci-evpn-overlay-00

[Rabadan, Jorge (Jorge)]

Weiguo,

In-line [JORGE2].
Thanks.

From: Haoweiguo haowei...@huawei.commailto:haowei...@huawei.com
Date: Friday, November 14, 2014 at 1:08 AM
To: Jorge Rabadan 
jorge.raba...@alcatel-lucent.commailto:jorge.raba...@alcatel-lucent.com, 
bess@ietf.orgmailto:bess@ietf.org bess@ietf.orgmailto:bess@ietf.org
Subject: [bess] 答复: Comments on draft draft-rabadan-bess-dci-evpn-overlay-00


Hi Jorge,

Please see inline with [weiguo2].

Thanks

weiguo


发件人: Rabadan, Jorge (Jorge) 
[jorge.raba...@alcatel-lucent.commailto:jorge.raba...@alcatel-lucent.com]
发送时间: 2014年11月13日 16:42
收件人: Haoweiguo; bess@ietf.orgmailto:bess@ietf.org
主题: Re: [bess] Comments on draft draft-rabadan-bess-dci-evpn-overlay-00

Hi Weiguo,

Please see in-line.

From: Haoweiguo haowei...@huawei.commailto:haowei...@huawei.com
Date: Wednesday, November 12, 2014 at 11:09 PM
To: bess@ietf.orgmailto:bess@ietf.org bess@ietf.orgmailto:bess@ietf.org
Subject: [bess] Comments on draft draft-rabadan-bess-dci-evpn-overlay-00


Hi Co-authors,

In today's BESS meeting, i have some comments, pls allow me to reiterate here.

1. EVPN supports mass MAC withdraw when local PE link failure occurs. If EVPN 
is used for NVO3 network interconnecting, if a local NVE occurs node failure, 
local DCI PE how to notify remote PEs to flush MAC table in mass mode, because 
in this case, there maybe many TS's MAC attached to the local NVE, mass MAC 
withdraw should be supported to provide MAC withdraw efficiecy.

[JORGE] If you are talking about the EVPN-MPLS interconnect model, if there is 
a failure in one of the ESIs at an NVE, the NVE will withdraw the A-D per ESI 
route and the DC GWs will do mass withdraw. That is perfectly supported. The 
NVE ESI A-D route updates/withdraw don’t have to be exported to the WAN PEs.

[weiguo2]: Sorry, it's my mistake, too many similar drafts. In the draft no 
this issue. in your draft data center network is NVO3+EVPN, control plane mac 
learning is used. There is another draft, NVO3 uses data plane MAC learning, no 
EVPN protocol is running within data center network, in this case NVE occurs 
link or node failure, no MASS mac withdraw mechanism.



2. For EVPN multi-homing, DF is elected per I-ESI, can you ensure BUM traffic 
load balancing among multiple PEs?

[JORGE] See the procedures in section 3.4.3.
[weiguo2]: Yes, It can realize per EVI loadbalancing.


3. If DC GW and WAN PE are separated device, Option-B solution should be 
supprted to ensure scalability, Option-A (In your draft, it is called vlan 
hand-off)has two much scalability limitations.

[JORGE] The decoupled model assumes separate admin entities in WAN and DC, 
hence you need a clear demarcation hand off for security and QoS, etc. Of 
course the decouple vs integrated model described in the draft have pros and 
cons, but both are required. Option B is described in 
http://tools.ietf.org/html/draft-sd-l2vpn-evpn-overlay-03

For unicast traffic, the DC GW should support VN ID and MPLS VPN Label 
switching. VN ID and MPLS VPN Label at WAN PE assign machanism also should be 
specified. For BUM traffic, the DC GW should stitch the multicast tree within 
data center and the multicast tree in WAN network.

The description is too simple in your draft, in our previous drafts, the 
option-B solution is described in detail,  your reading are welcomed.

http://datatracker.ietf.org/doc/draft-hao-l2vpn-inter-nvo3-evpn/

http://ietfreport.isoc.org/idref/draft-hao-l3vpn-inter-nvo3-vpn/





[JORGE] If you refer to section 3.4, all the procedures which are *different 
from EVPN* are described in the draft in my opinion. I don’t think EVPN 
procedures have to be explained here, but let us know if there is something 
specific that can be subject to different interpretations.

[weiguo2]: Option-B solution only applies for decouple model. I think the 
solution in your referrence is not clear, if you have spare time, pls read the 
above two drafts. VN ID and MPLS VPN Label assigning principle, how to stitch 
service layer including unicast and multicast are all described in detail. 
Thanks.

[JORGE2] To be clear, this draft does not talk about option B. That is 
explained in the evpn-overlay draft. This draft defines a gateway function, 
where a MAC-VRF is instantiated in the GW, i.e. a MAC lookup is required. As 
such, stitching and translations VNI to VNI or VNI to MPLS label are all fully 
supported. The VNIs or MPLS labels are locally allocated and there are no 
dependencies because we always do a MAC lookup. Can you please let us know what 
exactly is not clear?
Another comment: the decouple vs integrated thing is terminology of this draft 
and it is not used anywhere else, and IMO it does not make sense when talking 
about option B.




In my today's Option-C presentation, transport layer stitching mechanism is 
described. Option-B solution should support service layer stitching, the 
mechansim also should be fully described.



[JORGE] As discussed