date:20150330

Re: [bess] [Pals] Shepherd review of draft-ietf-l2vpn-vpls-pe-etree

2015-03-30 Thread Jiangyuanlong

Hi Sasha,

I agree with you that 2119 language should be used in this paragraph.

Though normal E-Tree service usually consists of at least one root and at least 
two leaves, MEF 6.1 says [Page 16]:”An E-Tree service may have no leaves, for 
example, during times when leaf UNIs are being added or removed.” So we’d 
better add no more limitations to the texts.

Thanks,
Yuanlong

From: Alexander Vainshtein [mailto:alexander.vainsht...@ecitele.com]
Sent: Tuesday, March 31, 2015 12:55 PM
To: Jiangyuanlong; draft-ietf-l2vpn-vpls-pe-et...@tools.ietf.org; 
p...@ietf.org; stbry...@cisco.com
Cc: l2vpn-cha...@tools.ietf.org; bess-cha...@tools.ietf.org; 
pals-cha...@tools.ietf.org; bess@ietf.org
Subject: Re: [Pals] Shepherd review of draft-ietf-l2vpn-vpls-pe-etree



Stewart, authors and all,
One of the nits in the review mentions inconsistent use of "MUST not" in the 
text that defines  what constitutes an E-Tree service.

I have noticed that the same fragment also contains several cases of "may", and 
it is not clear  to me whether it should be replaced by the 2119 "MAY" or not.

After reading this fragment (as quoted in the review) I wonder whether an 
E-Tree service does not require at least one root and at least two leaves. From 
my POV if the second of these conditions is not met, the connectivity 
restrictions become meaningless, and if the first one is not met, the service 
would not pass any traffic at all.

If these observations are correct, it makes sense to state these limitations 
explicitly using 2119 language (MUST include...).

A apologize for inadvertently sending an earlier version of this text in 
response to a wrong message.

My 2c,
Sasha

From: Pals mailto:pals-boun...@ietf.org>> on behalf of 
Stewart Bryant mailto:stbry...@cisco.com>>
Sent: Monday, March 30, 2015 5:06 PM
To: Jiangyuanlong; 
draft-ietf-l2vpn-vpls-pe-et...@tools.ietf.org;
 p...@ietf.org
Cc: l2vpn-cha...@tools.ietf.org; 
bess-cha...@tools.ietf.org; 
pals-cha...@tools.ietf.org; 
bess@ietf.org
Subject: Re: [Pals] Shepherd review of draft-ietf-l2vpn-vpls-pe-etree

Yuanlong

The text has the following nits mostly this is just minor editing but
does need to be fixed.

RFC 6136 can be made an informational ref

=


tmp/draft-ietf-l2vpn-vpls-pe-etree-05.txt:
tmp/draft-ietf-l2vpn-vpls-pe-etree-05.txt(20): Line is too long: the offending 
characters are '.'
tmp/draft-ietf-l2vpn-vpls-pe-etree-05.txt(227): Line is too long: the offending 
characters are '.'
tmp/draft-ietf-l2vpn-vpls-pe-etree-05.txt(415): Line is too long: the offending 
characters are ','
tmp/draft-ietf-l2vpn-vpls-pe-etree-05.txt(579): Line is too long: the offending 
characters are 'e'
tmp/draft-ietf-l2vpn-vpls-pe-etree-05.txt(582): Line is too long: the offending 
characters are 'N,'
tmp/draft-ietf-l2vpn-vpls-pe-etree-05.txt(632): Line is too long: the offending 
characters are 'n'
tmp/draft-ietf-l2vpn-vpls-pe-etree-05.txt(635): Line is too long: the offending 
characters are 'e'
tmp/draft-ietf-l2vpn-vpls-pe-etree-05.txt(917): Line is too long: the offending 
characters are 'n'
tmp/draft-ietf-l2vpn-vpls-pe-etree-05.txt(924): Line is too long: the offending 
characters are '.'
tmp/draft-ietf-l2vpn-vpls-pe-etree-05.txt(1138): Line has weird spacing: '...) 
where  any t...'


  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  http://trustee.ietf.org/license-info):
  

 No issues found here.

  Checking nits according to http://www.ietf.org/id-info/1id-guidelines.txt:
  

 No issues found here.

  Checking nits according to http://www.ietf.org/id-info/checklist :
  

  ** There are 9 instances of too long lines in the document, the longest one
 being 2 characters in excess of 72.


  Miscellaneous warnings:
  

  == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD',
 or 'RECOMMENDED' is not an accepted usage according to RFC 2119.  Please
 use uppercase 'NOT' together with RFC 2119 keywords (if that is what you
 mean).

 Found 'MUST not' in this paragraph:

 The Ethernet-Tree (E-Tree) service is defined in Metro Ethernet
 Forum (MEF) Technical Specification MEF 6.1 as a Rooted-Multipoint
 Ethernet Virtual Connection (EVC) service. It is a multipoint Ethernet
 service with special restrictions: the Ethernet frames from a root may be
 received by any other root or leaf, and the frames from a leaf may be
 received by any root, but MUST not

[bess] Request for WG adoption of draft-mohanty-bess-evpn-df-election

2015-03-30 Thread Satya Mohanty (satyamoh)

Hi,

Given the interest and technical discussions on the topic of the EVPN DF
Election, and the favorable response of the community to the benefits of
the HRW scheme, I would like to request the WG to adopt
draft-mohanty-bess-evpn-df-election.

Thanks to Jakob Heitz for presentation of slides at the IETF.

Best regards,
--Satya

On 3/27/15 8:52 PM, "Rabadan, Jorge (Jorge)"
 wrote:

>Hi Thomas,
>
>You are right.
>
>Kishore, Weiguo and I were discussing face-to-face the scenario drawn by
>Weiguo below. And my conclusion is that there is no loop and there is
>nothing new that it was not discussed in this thread. EVPN single-active
>and split-horizon procedures take care of loops. If there are transient
>DF-DF periods, you can get some duplicate packets, but not infinite loops.
>And an implementation should allow a configurable timer that can be
>adjusted to the scale of the network so that the dual DF transient risk
>can be minimized or eliminated.
>
>About why all-active is not supported in the scenario below, I agree with
>your reasoning. RFC7432 only accepts LAG for all-active, since, otherwise,
>duplicate packets could be forwarded in normal state.
>draft-ietf-bess-dci-evpn-overlay-00 proposes an all-active MH network
>solution, but that is because EVPN runs in the access network too.
>
>Thanks.
>Jorge
>
>-Original Message-
>From: "thomas.mo...@orange.com" 
>Organization: Orange
>Date: Friday, March 27, 2015 at 4:08 PM
>To: Jorge Rabadan , Haoweiguo
>, "Satya Mohanty (satyamoh)" ,
>"bess@ietf.org" 
>Subject: Re: [bess] Handshaking among PEs in an EVPN ES based on Paxos
>algorithm
>
>>Hi Jorge,
>>
>>Jorge:
>>> If you have any other scenario, let’s talk offline. We are boring
>>>people
>>> ;-)
>>
>>I think its nice to keep the discussion on the list, which is here for a
>>reason (that is, not just for polls for adoption and WG last calls...).
>>
>>I'm sure these clarifications can be useful for some of the
>>participants, and the others can very much skip the thread.
>>
>>And there is, I think, perhaps one more thing worth spelling out.
>>
>>RFC7432 explains that for multi-homing in active-active mode, LAG is
>>required.
>>My understanding of the reason why, in this case, it is not supported to
>>connect the bridged
>>network via multiple CEs is that there is no technique to build a LAG
>>between two CEs and two PEs.
>>
>>Best,
>>
>>-Thomas
>>
>>
>>
>>Rabadan, Jorge :
>>> 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.
>>>
>>>
>>>
>>>
>>> Thanks.
>>> Jorge
>>>
>>> -Original Message-
>>> From: Haoweiguo 
>>> Date: Friday, March 27, 2015 at 9:00 AM
>>> To: Jorge Rabadan , "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 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--->CE2>CE1>PE1>PE3-->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 
 Date: Friday, March 27, 2015 at 8:11 AM
 To: Jorge Rabadan , "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 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--->CE2>CE1>PE1>PE3-->CE3-->CE4-

Re: [bess] [Pals] Shepherd review of draft-ietf-l2vpn-vpls-pe-etree

2015-03-30 Thread Alexander Vainshtein



Stewart, authors and all,
One of the nits in the review mentions inconsistent use of "MUST not" in the 
text that defines  what constitutes an E-Tree service.

I have noticed that the same fragment also contains several cases of "may", and 
it is not clear  to me whether it should be replaced by the 2119 "MAY" or not.

After reading this fragment (as quoted in the review) I wonder whether an 
E-Tree service does not require at least one root and at least two leaves. From 
my POV if the second of these conditions is not met, the connectivity 
restrictions become meaningless, and if the first one is not met, the service 
would not pass any traffic at all.

If these observations are correct, it makes sense to state these limitations 
explicitly using 2119 language (MUST include...).

A apologize for inadvertently sending an earlier version of this text in 
response to a wrong message.

My 2c,
Sasha

From: Pals  on behalf of Stewart Bryant 

Sent: Monday, March 30, 2015 5:06 PM
To: Jiangyuanlong; draft-ietf-l2vpn-vpls-pe-et...@tools.ietf.org; p...@ietf.org
Cc: l2vpn-cha...@tools.ietf.org; bess-cha...@tools.ietf.org; 
pals-cha...@tools.ietf.org; bess@ietf.org
Subject: Re: [Pals] Shepherd review of draft-ietf-l2vpn-vpls-pe-etree

Yuanlong

The text has the following nits mostly this is just minor editing but
does need to be fixed.

RFC 6136 can be made an informational ref

=


tmp/draft-ietf-l2vpn-vpls-pe-etree-05.txt:
tmp/draft-ietf-l2vpn-vpls-pe-etree-05.txt(20): Line is too long: the offending 
characters are '.'
tmp/draft-ietf-l2vpn-vpls-pe-etree-05.txt(227): Line is too long: the offending 
characters are '.'
tmp/draft-ietf-l2vpn-vpls-pe-etree-05.txt(415): Line is too long: the offending 
characters are ','
tmp/draft-ietf-l2vpn-vpls-pe-etree-05.txt(579): Line is too long: the offending 
characters are 'e'
tmp/draft-ietf-l2vpn-vpls-pe-etree-05.txt(582): Line is too long: the offending 
characters are 'N,'
tmp/draft-ietf-l2vpn-vpls-pe-etree-05.txt(632): Line is too long: the offending 
characters are 'n'
tmp/draft-ietf-l2vpn-vpls-pe-etree-05.txt(635): Line is too long: the offending 
characters are 'e'
tmp/draft-ietf-l2vpn-vpls-pe-etree-05.txt(917): Line is too long: the offending 
characters are 'n'
tmp/draft-ietf-l2vpn-vpls-pe-etree-05.txt(924): Line is too long: the offending 
characters are '.'
tmp/draft-ietf-l2vpn-vpls-pe-etree-05.txt(1138): Line has weird spacing: '...) 
where  any t...'


  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  http://trustee.ietf.org/license-info):
  

 No issues found here.

  Checking nits according to http://www.ietf.org/id-info/1id-guidelines.txt:
  

 No issues found here.

  Checking nits according to http://www.ietf.org/id-info/checklist :
  

  ** There are 9 instances of too long lines in the document, the longest one
 being 2 characters in excess of 72.


  Miscellaneous warnings:
  

  == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD',
 or 'RECOMMENDED' is not an accepted usage according to RFC 2119.  Please
 use uppercase 'NOT' together with RFC 2119 keywords (if that is what you
 mean).

 Found 'MUST not' in this paragraph:

 The Ethernet-Tree (E-Tree) service is defined in Metro Ethernet
 Forum (MEF) Technical Specification MEF 6.1 as a Rooted-Multipoint
 Ethernet Virtual Connection (EVC) service. It is a multipoint Ethernet
 service with special restrictions: the Ethernet frames from a root may be
 received by any other root or leaf, and the frames from a leaf may be
 received by any root, but MUST not be received by a leaf. Further, an
 E-Tree service may include multiple roots and multiple leaves. Although
 Virtual Private Multicast Service (VPMS) [VPMS] or Point-to-Multipoint
 (P2MP) multicast is a somewhat simplified version of this service, in
 fact, there is no exact corresponding terminology in IETF yet.

  -- The document date (February 26, 2015) is 32 days in the past.  Is this
 intentional?


  Checking references for intended status: Proposed Standard
  

 (See RFCs 3967 and 4897 for information about using normative references
 to lower-maturity documents in RFCs)

  == Unused Reference: 'MEF4' is defined on line 872, but no explicit
 reference was found in the text
 '[MEF4]Metro Ethernet Forum, Metro Ethernet Network Architecture...'

  ** Downref: Normative reference to an Informational RFC: RFC 6136


 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--).


=

Re: [bess] [Pals] Shepherd review of draft-ietf-l2vpn-vpls-pe-etree

2015-03-30 Thread Stewart Bryant


Yuanlong

The text has the following nits mostly this is just minor editing but
does need to be fixed.

RFC 6136 can be made an informational ref

=


tmp/draft-ietf-l2vpn-vpls-pe-etree-05.txt:
tmp/draft-ietf-l2vpn-vpls-pe-etree-05.txt(20): Line is too long: the 
offending characters are '.'
tmp/draft-ietf-l2vpn-vpls-pe-etree-05.txt(227): Line is too long: the 
offending characters are '.'
tmp/draft-ietf-l2vpn-vpls-pe-etree-05.txt(415): Line is too long: the 
offending characters are ','
tmp/draft-ietf-l2vpn-vpls-pe-etree-05.txt(579): Line is too long: the 
offending characters are 'e'
tmp/draft-ietf-l2vpn-vpls-pe-etree-05.txt(582): Line is too long: the 
offending characters are 'N,'
tmp/draft-ietf-l2vpn-vpls-pe-etree-05.txt(632): Line is too long: the 
offending characters are 'n'
tmp/draft-ietf-l2vpn-vpls-pe-etree-05.txt(635): Line is too long: the 
offending characters are 'e'
tmp/draft-ietf-l2vpn-vpls-pe-etree-05.txt(917): Line is too long: the 
offending characters are 'n'
tmp/draft-ietf-l2vpn-vpls-pe-etree-05.txt(924): Line is too long: the 
offending characters are '.'
tmp/draft-ietf-l2vpn-vpls-pe-etree-05.txt(1138): Line has weird spacing: 
'...) where  any t...'



  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  http://trustee.ietf.org/license-info):


 No issues found here.

  Checking nits according to 
http://www.ietf.org/id-info/1id-guidelines.txt:



 No issues found here.

  Checking nits according to http://www.ietf.org/id-info/checklist :


  ** There are 9 instances of too long lines in the document, the 
longest one

 being 2 characters in excess of 72.


  Miscellaneous warnings:


  == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 
'SHOULD',
 or 'RECOMMENDED' is not an accepted usage according to RFC 2119.  
Please
 use uppercase 'NOT' together with RFC 2119 keywords (if that is 
what you

 mean).

 Found 'MUST not' in this paragraph:

 The Ethernet-Tree (E-Tree) service is defined in Metro Ethernet
 Forum (MEF) Technical Specification MEF 6.1 as a Rooted-Multipoint
 Ethernet Virtual Connection (EVC) service. It is a multipoint Ethernet
 service with special restrictions: the Ethernet frames from a root 
may be

 received by any other root or leaf, and the frames from a leaf may be
 received by any root, but MUST not be received by a leaf. Further, an
 E-Tree service may include multiple roots and multiple leaves. 
Although

 Virtual Private Multicast Service (VPMS) [VPMS] or Point-to-Multipoint
 (P2MP) multicast is a somewhat simplified version of this service, in
 fact, there is no exact corresponding terminology in IETF yet.

  -- The document date (February 26, 2015) is 32 days in the past.  Is this
 intentional?


  Checking references for intended status: Proposed Standard


 (See RFCs 3967 and 4897 for information about using normative 
references

 to lower-maturity documents in RFCs)

  == Unused Reference: 'MEF4' is defined on line 872, but no explicit
 reference was found in the text
 '[MEF4]Metro Ethernet Forum, Metro Ethernet Network 
Architecture...'


  ** Downref: Normative reference to an Informational RFC: RFC 6136


 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--).


===

Looking at this text



6141) if the root and leaf VLAN ID in the message match the local root
615   and leaf VLAN ID, then continue to 3);

6172) else {

619   if the bit V is cleared, then {

621 if the PE is capable of VLAN mapping, then it MUST set
622 VLAN-Mapping-Mode to TRUE;

624 else {

626  A label release message with the error code "E-Tree
627  VLAN mapping not supported" is sent to the peer PE
628  and exit the process;

630  }

632   }

634   if the bit V is set, and the PE is capable of VLAN mapping,
635   then the PE with the minimum IP address MUST set VLAN-Mapping-
636   Mode to TRUE;

638   }

6403) If the P bit is set, then:


It might be clearer to apply De Morgan:

Which I think makes it

1) if the root not equal local root or leaf VLAN ID not equal to leaf VLAN ID
   in the message match then


  if the bit V is cleared, then {

if the PE is capable of VLAN mapping, then it MUST set
VLAN-Mapping-Mode to

Re: [bess] ARP ND draft

2015-03-30 Thread Antoni Przygienda

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

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

Comments inline 

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

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

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

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

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

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

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

 [Tony saiz:]  agreed. 

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

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

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

-- tony 

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

Re: [bess] ARP ND draft

2015-03-30 Thread Antoni Przygienda

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

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

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

Thanks

--- tony

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

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

Hi Wim,

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

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

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

Cheers,
R.

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

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

Subject: Re: [bess] ARP ND draft

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

Sent from my iPhone

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

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

Cheers,
r.

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

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

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

___
BESS mailing list
BESS@ietf.org
https://

Re: [bess] [Pals] Shepherd review of draft-ietf-l2vpn-vpls-pe-etree

[bess] Request for WG adoption of draft-mohanty-bess-evpn-df-election

Re: [bess] [Pals] Shepherd review of draft-ietf-l2vpn-vpls-pe-etree

Re: [bess] [Pals] Shepherd review of draft-ietf-l2vpn-vpls-pe-etree

Re: [bess] ARP ND draft

Re: [bess] ARP ND draft

6 matches

Site Navigation

Mail list logo

Footer information