Subject: [Idr] Comments on draft-ietf-l3vpn-ibgp-02.txt

From: <[email-masked]>
Date: Mon, 18 Apr 2011 15:04:09 +0200

Hi all,

* Regarding $7 :
 
If you consider a VPN that spans across multiple service provider ASes,
when the egress PE is advertising the VPN route (coming from iBGP CE
peer at ingress PE) towards an eBGP CE, does the PE prepends only his
own AS after prepending customer origin AS (as it seems to be mentionned
in the statement below), or do you think there is an interrest to
prepend the all "backbone" ASPATH ? :
 
"When advertising the VRF route to an Exterior BGP peer, a PE
      router shall apply steps 1 to 3 defined above and subsequently
      prepend its own autonomous-system number to the AS_PATH
attribute."
 
I'm wondering  in some tricky scenarios , when a customer has multiple
MPLS VPN providers (for backup purpose), if there is a need (like for
eBGP PE-CE) to reflect the backbone ASPATH to prefer the provider with
the shortest ASPATH length.

* Regarding ATTR_SET attribute and BGP update storage/generation,  I
don't think that there is an impact on update generation (mainly
packing) by Service Provider route-reflectors, but I would be
interrested if someone see something bad in this area. But even if there
is no impact (TBC) on generating updates by the Service Provider
route-reflectors, I think there could be an impact :
    - on memory usage : mainly depending on how much informations are
stored in ATTR_SET, moreover it would be hard to share datastructures
between different customer routes (as attributes are "customer
dependent")
 
    - on size of BGP datas transmitted on the TCP session and so impact
on time to transfer it

* It is sometime useful that VPN CEs  advertise special "Backbone"
communities to the service provider to permit for example for a remote
PE to select his own prefered egress PE (loadsharing scenario). With
ATTR_SET, attributes from CE are tunneled and are no more visible from
the service provider. Due to this, the previous scenario is no more
achievable and customer can't anymore use Backbone communities to
influence service provider backbone behavior.

Regards,
 
Stephane

********************************************************************************
IMPORTANT.Les informations contenues dans ce message electronique y compris les fichiers attaches sont strictement confidentielles
et peuvent etre protegees par la loi.
Ce message electronique est destine exclusivement au(x) destinataire(s) mentionne(s) ci-dessus.
Si vous avez recu ce message par erreur ou s il ne vous est pas destine, veuillez immediatement le signaler  a l expediteur et effacer ce message 
et tous les fichiers eventuellement attaches.
Toute lecture, exploitation ou transmission des informations contenues dans ce message est interdite.
Tout message electronique est susceptible d alteration.
A ce titre, le Groupe France Telecom decline toute responsabilite notamment s il a ete altere, deforme ou falsifie.
De meme, il appartient au destinataire de s assurer de l absence de tout virus.

IMPORTANT.This e-mail message and any attachments are strictly confidential and may be protected by law. This message is
intended only for the named recipient(s) above.
If you have received this message in error, or are not the named recipient(s), please immediately notify the sender and delete this e-mail message.
Any unauthorized view, usage or disclosure ofthis message is prohibited.
Since e-mail messages may not be reliable, France Telecom Group shall not be liable for any message if modified, changed or falsified.
Additionally the recipient should ensure they are actually virus free.
********************************************************************************

---

From: Pedro Marques <[email-masked]>
Date: Tue, 19 Apr 2011 10:14:54 -0700

Stephane,
Thank you for your comments. Answers inline.

On Mon, Apr 18, 2011 at 6:04 AM,  <[email-masked]> wrote:
> Hi all,
>
>
> * Regarding $7 :
>
> If you consider a VPN that spans across multiple service provider ASes, when
> the egress PE is advertising the VPN route (coming from iBGP CE peer at
> ingress PE) towards an eBGP CE, does the PE prepends only his own AS after
> prepending customer origin AS (as it seems to be mentionned in the statement
> below), or do you think there is an interrest to prepend the all "backbone"
> ASPATH ? :
>
>       prepend its own autonomous-system number to the AS_PATH attribute."
>
> I'm wondering  in some tricky scenarios , when a customer has multiple MPLS
> VPN providers (for backup purpose), if there is a need (like for eBGP PE-CE)
> to reflect the backbone ASPATH to prefer the provider with the shortest
> ASPATH length.

That is a good point. In order to be consistent with the eBGP behavior
it is best to
prepend both the AS_PATH of the VPN route and its own autonomous-system
number, in case the AS_PATH is not empty.

>
> * Regarding ATTR_SET attribute and BGP update storage/generation,  I don't
> think that there is an impact on update generation (mainly packing) by
> Service Provider route-reflectors, but I would be interrested if someone see
> something bad in this area.

This mechanism has been deployed in production for over 5 years. I'm
not aware of
"something bad" happening. The ATTR_SET attribute doesn't
significantly change the
packing of updates.

> But even if there is no impact (TBC) on
> generating updates by the Service Provider route-reflectors, I think there
> could be an impact :
>     - on memory usage : mainly depending on how much informations are stored
> in ATTR_SET, moreover it would be hard to share datastructures between
> different customer routes (as attributes are "customer dependent")

In the worst case scenario, each customer route has its own unique set
of attributes. That
worst case scenario can occur today via the use of communities. The
common case is for
different sets of CE route attributes to be providing useful
information and be advertised through
the VPN network, either with the current ebgp PE-CE interaction or
with the method that is
proposed in this document.

>
>     - on size of BGP datas transmitted on the TCP session and so impact on
> time to transfer it

The added size to updates is statistically insignificant considering
link bandwidth.

> communities to the service provider to permit for example for a remote PE to
> select his own prefered egress PE (loadsharing scenario). With ATTR_SET,
> attributes from CE are tunneled and are no more visible from the service
> provider. Due to this, the previous scenario is no more achievable and
> customer can't anymore use Backbone communities to influence service
> provider backbone behavior.

There is no reason to believe that the VPN export policies that
compute the VPN network
attributes cannot impose communities depending on the attributes of
the CE routes. I also
note that this document is not ment to replace but to complement the
existing EBGP based
PE-CE iteration. But contrary to the current mechanism, the default is
to segregate attributes
between the two networks. As the document explains there are several
scenarios in which this
proposal enables a simpler behavior.

regards,
  Pedro.