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

[Antoni Przygienda]

Attached comments I started on the prefix advertisement draft in eVPN  to get 
e'one a chance to jump in

thanks

--- tony


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

--- Begin Message ---
inline



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



Hi Tony,



Please see in-line.



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



   Gentlemen,



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



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



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





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



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



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



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









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



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

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







   Merits couple clarifying sentences would merit addition?



   Yes, we’ll do that.





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

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



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



   [Tony said] ok, cool.



   --- tony

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

Re: [bess] Poll for adoption: draft-xu-l3vpn-virtual-subnet-fib-reduction

[Dongjie (Jimmy)]

Support the adoption. Draft provides a useful solution for FIB scalability.

Best regards,
Jie

> -Original Message-
> From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Martin Vigoureux
> Sent: Wednesday, January 07, 2015 7:06 PM
> To: bess@ietf.org
> Cc: draft-xu-l3vpn-virtual-subnet-fib-reduct...@tools.ietf.org
> Subject: [bess] Poll for adoption: draft-xu-l3vpn-virtual-subnet-fib-reduction
> 
> Hello working group,
> 
> This email starts a two-week poll on adopting
> draft-xu-l3vpn-virtual-subnet-fib-reduction [1] as a working group item.
> 
> Please send comments to the list and state if you support adoption or not (in
> the later case, please also state the reasons).
> 
> This poll runs until **January 21st**.
> 
> 
> *Coincidentally*, we are also polling for knowledge of any IPR that applies to
> this draft, to ensure that IPR has been disclosed in compliance with IETF IPR
> rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
> 
> ==> *If you are listed as a document author or contributor* please respond to
> this email and indicate whether or not you are aware of any relevant IPR.
> 
> The draft will not be adopted until a response has been received from each
> author and contributor.
> 
> If you are not listed as an author or contributor, then please explicitly 
> respond
> only if you are aware of any IPR that has not yet been disclosed in 
> conformance
> with IETF rules.
> 
> Thank you,
> 
> Martin & Thomas
> bess chairs
> 
> [1] https://tools.ietf.org/html/draft-xu-l3vpn-virtual-subnet-fib-reduction
> 
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess

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

Re: [bess] Poll for adoption: draft-xu-l3vpn-virtual-subnet-fib-reduction

[Uma Chunduri]

Support.

--
Uma C.


-Original Message-
From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Martin Vigoureux
Sent: Wednesday, January 07, 2015 3:06 AM
To: bess@ietf.org
Cc: draft-xu-l3vpn-virtual-subnet-fib-reduct...@tools.ietf.org
Subject: [bess] Poll for adoption: draft-xu-l3vpn-virtual-subnet-fib-reduction

Hello working group,

This email starts a two-week poll on adopting 
draft-xu-l3vpn-virtual-subnet-fib-reduction [1] as a working group item.

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

This poll runs until **January 21st**.


*Coincidentally*, we are also polling for knowledge of any IPR that applies to 
this draft, to ensure that IPR has been disclosed in compliance with IETF IPR 
rules (see RFCs 3979, 4879, 3669 and 5378 for more details).

==> *If you are listed as a document author or contributor* please respond to 
this email and indicate whether or not you are aware of any relevant IPR.

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

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

Thank you,

Martin & Thomas
bess chairs

[1] https://tools.ietf.org/html/draft-xu-l3vpn-virtual-subnet-fib-reduction

___
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

[Antoni Przygienda]

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



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


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

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

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

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

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


1.  we need M2 over NVE2 in the figure

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







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

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

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

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


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

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

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

[bess] I-D Action: draft-ietf-bess-mvpn-bidir-ingress-replication-00.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the BGP Enabled Services Working Group of the 
IETF.

Title   : Simulating "Partial Mesh of MP2MP P-Tunnels" with 
Ingress Replication
Authors : Zhaohui Zhang
  Yakov Rekhter
  Andrew Dolganow
Filename: draft-ietf-bess-mvpn-bidir-ingress-replication-00.txt
Pages   : 13
Date: 2015-01-14

Abstract:
   RFC 6513 described a method to support bidirectional C-flow using
   "Partial Mesh of MP2MP P-Tunnels".  This document describes how
   partial mesh of MP2MP P-Tunnels can be simulated with Ingress
   Replication, instead of a real MP2MP tunnel.  This enables a Service
   Provider to use Ingress Replication to offer transparent BIDIR-PIM
   service to its VPN customers.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-bidir-ingress-replication/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-bess-mvpn-bidir-ingress-replication-00


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

Re: [bess] WG Last Call for draft-ietf-l3vpn-mvpn-bidir-ingress-replication

[Jeffrey (Zhaohui) Zhang]

Thanks, Thomas. The BESS version has been submitted:

http://www.ietf.org/internet-drafts/draft-ietf-bess-mvpn-bidir-ingress-replication-00.txt

Jeffrey

> -Original Message-
> From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Thomas Morin
> Sent: Monday, January 12, 2015 6:44 AM
> To: BESS
> Subject: [bess] WG Last Call for draft-ietf-l3vpn-mvpn-bidir-ingress-
> replication
> 
> Hello working group,
> 
> This email starts a Working Group Last Call on
> draft-ietf-l3vpn-mvpn-bidir-ingress-replication, which is considered
> mature and ready for a 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 **January 26th**.
> 
> (the document has expired a few days ago, so can authors please repost
> the document, as-is, as
> draft-ietf-bess-mvpn-bidir-ingress-replication-00, to make it easier to
> find the it ?)
> 
> Thank you,
> 
> -Thomas & Martin
> 
> [1]
> 
> http://tools.ietf.org/html/draft-ietf-l3vpn-mvpn-bidir-ingress-
> replication-01
> 
> https://datatracker.ietf.org/doc/draft-ietf-l3vpn-mvpn-bidir-ingress-
> replication
> 
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess

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

Re: [bess] Poll for adoption: draft-xu-l3vpn-virtual-subnet-fib-reduction

[christian.jacquenet]

Hello WG,

I too support the adoption of draft-xu-l3vpn-virtual-subnet-fib-reduction as a 
bess WG item. As a co-author, I'm not aware of any IPR pertaining to this 
document.

Cheers,

Christian.
-Original Message-
From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Martin Vigoureux
Sent: Wednesday, January 07, 2015 3:06 AM
To: bess@ietf.org
Cc: draft-xu-l3vpn-virtual-subnet-fib-reduct...@tools.ietf.org
Subject: [bess] Poll for adoption: draft-xu-l3vpn-virtual-subnet-fib-reduction

Hello working group,

This email starts a two-week poll on adopting 
draft-xu-l3vpn-virtual-subnet-fib-reduction [1] as a working group item.

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

This poll runs until **January 21st**.


*Coincidentally*, we are also polling for knowledge of any IPR that applies to 
this draft, to ensure that IPR has been disclosed in compliance with IETF IPR 
rules (see RFCs 3979, 4879, 3669 and 5378 for more details).

==> *If you are listed as a document author or contributor* please respond to 
this email and indicate whether or not you are aware of any relevant IPR.

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

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

Thank you,

Martin & Thomas
bess chairs

[1] https://tools.ietf.org/html/draft-xu-l3vpn-virtual-subnet-fib-reduction

___
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

_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

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