Subject: About the WG adoption of draft-xu-l3vpn-virtual-subnet-fib-reduction-00

From: Xuxiaohu <[email-masked]>
Date: Wed, 30 Jul 2014 06:54:19 +0000

Hi all,

Virtual Subnet (http://tools.ietf.org/html/draft-ietf-l3vpn-virtual-subnet) is intended for building L3 network virtualization overlays within and/or across data centers. Since a subnet is extended across multiple PE routers, CE host routes need to be exchanged among PE routers. As a result, the forwarding table size of PE routers (e.g., some old ToR switches) may become a big concern in large-scale data center environments. In fact, some folks had already expressed their concerns about this potential FIB scaling issue during the WG adoption poll of the Virtual Subnet draft.

As CE host routes may still need to be maintained on the control plane of PE routers in some cases (e.g.. MVPN scenario), this draft (http://tools.ietf.org/html/draft-xu-l3vpn-virtual-subnet-fib-reduction-00) proposes a very simple mechanism for reducing the FIB size of PE routers without any change to the RIB and even the routing table.

During the L3VPN WG session at Toronto, many people had expressed their supports for the WG adoption of this work (Thanks a lot for your supports). However, there are still a few people who are not in favor of the WG adoption. According to WG co-chairs' suggestion, I would like to request those opposers to explain their reasons so that we could further improve the draft if possible.

Best regards,
Xiaohu (on behalf of all co-authors)

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Wed, 30 Jul 2014 08:30:43 +0000

What I would like to see is a way to identify the host routes since there
are 2 levels: real loopbacks that need to be installed by default and real
host routes that can be installed on demand. It would be good to show how
the control plane could distinguish them using communities or the likes.

On 30/07/14 08:54, "Xuxiaohu" <[email-masked]> wrote:

>Hi all,
>
>Virtual Subnet 
>(http://tools.ietf.org/html/draft-ietf-l3vpn-virtual-subnet) is intended
>for building L3 network virtualization overlays within and/or across data
>centers. Since a subnet is extended across multiple PE routers, CE host
>routes need to be exchanged among PE routers. As a result, the forwarding
>table size of PE routers (e.g., some old ToR switches) may become a big
>concern in large-scale data center environments. In fact, some folks had
>already expressed their concerns about this potential FIB scaling issue
>during the WG adoption poll of the Virtual Subnet draft.
>
>As CE host routes may still need to be maintained on the control plane of
>PE routers in some cases (e.g.. MVPN scenario), this draft
>(http://tools.ietf.org/html/draft-xu-l3vpn-virtual-subnet-fib-reduction-00
>) proposes a very simple mechanism for reducing the FIB size of PE
>routers without any change to the RIB and even the routing table.
>
>During the L3VPN WG session at Toronto, many people had expressed their
>supports for the WG adoption of this work (Thanks a lot for your
>supports). However, there are still a few people who are not in favor of
>the WG adoption. According to WG co-chairs' suggestion, I would like to
>request those opposers to explain their reasons so that we could further
>improve the draft if possible.
>
>Best regards,

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 30 Jul 2014 08:52:20 +0000

Hi Wim,

Did you mean PE's loopback addresses by "real loopbacks"?

Best regards,
Xiaohu

> -----Original Message-----
> From: Henderickx, Wim (Wim) [mailto:[email-masked]]
> Sent: Wednesday, July 30, 2014 4:31 PM
> To: Xuxiaohu; [email-masked]
> Subject: Re: About the WG adoption of
> draft-xu-l3vpn-virtual-subnet-fib-reduction-00
> 
> What I would like to see is a way to identify the host routes since there are 2
> levels: real loopbacks that need to be installed by default and real host routes
> that can be installed on demand. It would be good to show how the control
> plane could distinguish them using communities or the likes.
> 
> >(http://tools.ietf.org/html/draft-ietf-l3vpn-virtual-subnet) is
> >intended for building L3 network virtualization overlays within and/or
> >across data centers. Since a subnet is extended across multiple PE
> >routers, CE host routes need to be exchanged among PE routers. As a
> >result, the forwarding table size of PE routers (e.g., some old ToR
> >switches) may become a big concern in large-scale data center
> >environments. In fact, some folks had already expressed their concerns
> >about this potential FIB scaling issue during the WG adoption poll of the Virtual
> Subnet draft.
> >
> >As CE host routes may still need to be maintained on the control plane
> >of PE routers in some cases (e.g.. MVPN scenario), this draft
> >supports). However, there are still a few people who are not in favor
> >of the WG adoption. According to WG co-chairs' suggestion, I would like
> >to request those opposers to explain their reasons so that we could
> >further improve the draft if possible.
> >
> >Best regards,

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Wed, 30 Jul 2014 08:54:52 +0000

Real loopbacks. E.g. A loopback /32 or /128 configured in the VRF

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 30 Jul 2014 08:59:17 +0000

Hi Wim,

In the Virtual Subnet context, the host route corresponding to the VRF interface address doesn't need to be advertised.

Best regards,
Xiaohu

> Sent: Wednesday, July 30, 2014 4:55 PM
> >> From: Henderickx, Wim (Wim)
> >> [mailto:[email-masked]]
> >> levels: real loopbacks that need to be installed by default and real
> >>host routes  that can be installed on demand. It would be good to show
> >>how the control  plane could distinguish them using communities or the
> >>likes.
> >>
> >> >intended for building L3 network virtualization overlays within
> >> >and/or across data centers. Since a subnet is extended across
> >> >multiple PE routers, CE host routes need to be exchanged among PE
> >> >routers. As a result, the forwarding table size of PE routers (e.g.,
> >> >some old ToR
> >> >environments. In fact, some folks had already expressed their
> >> >concerns about this potential FIB scaling issue during the WG
> >> >adoption poll of
> >>the Virtual
> >> Subnet draft.
> >> >
> >> >As CE host routes may still need to be maintained on the control
> >> >plane of PE routers in some cases (e.g.. MVPN scenario), this draft
> >> >(http://tools.ietf.org/html/draft-xu-l3vpn-virtual-subnet-fib-reduct
> >> >ion
> >> >-00
> >> >During the L3VPN WG session at Toronto, many people had expressed
> >> >their supports for the WG adoption of this work (Thanks a lot for
> >> >your supports). However, there are still a few people who are not in
> >> >favor of the WG adoption. According to WG co-chairs' suggestion, I
> >> >would like to request those opposers to explain their reasons so
> >> >that we could further improve the draft if possible.
> >> >
> >> >Best regards,

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Wed, 30 Jul 2014 09:20:15 +0000

Why not, if I configure a loopback in the VRF it has to be advertised,
this is generic VRF functionality, nothing to do with virtual subnet. I am
not talking to the IP address on the virtual subnet interface.
In this case you need to distinguish between host routes and these VRFs.
Using communities is the best way afais.

On 30/07/14 10:59, "Xuxiaohu" <[email-masked]> wrote:

>Hi Wim,
>
>In the Virtual Subnet context, the host route corresponding to the VRF
>interface address doesn't need to be advertised.
>
>Best regards,
>Xiaohu
>

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 30 Jul 2014 09:30:24 +0000

Why do you need to distinguish them from each other? In other words, why can't PE routers process the host route to a given VRF loopback address of a remote PE router as a normal remote host route (i.e., on-demand installation)?

Best regards,
Xiaohu

-----Original Message-----
From: Henderickx, Wim (Wim) [mailto:[email-masked]] 
Sent: Wednesday, July 30, 2014 5:20 PM
To: Xuxiaohu; [email-masked]
Subject: Re: About the WG adoption of draft-xu-l3vpn-virtual-subnet-fib-reduction-00

Why not, if I configure a loopback in the VRF it has to be advertised, this is generic VRF functionality, nothing to do with virtual subnet. I am not talking to the IP address on the virtual subnet interface.
In this case you need to distinguish between host routes and these VRFs.
Using communities is the best way afais.

On 30/07/14 10:59, "Xuxiaohu" <[email-masked]> wrote:

>> >> levels: real loopbacks that need to be installed by default and 
>> >>real host routes  that can be installed on demand. It would be good 
>> >>to show how the control  plane could distinguish them using 
>> >>communities or the likes.
>> >>
>> >> >routers. As a result, the forwarding table size of PE routers 
>> >> >(e.g., some old ToR
>> >> >) proposes a very simple mechanism for reducing the FIB size of 
>> >> >PE routers without any change to the RIB and even the routing table.
>> >> >
>> >> >your supports). However, there are still a few people who are not 
>> >> >in favor of the WG adoption. According to WG co-chairs' 
>> >> >suggestion, I would like to request those opposers to explain 
>> >> >their reasons so that we could further improve the draft if possible.
>> >> >
>> >> >Best regards,

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Wed, 30 Jul 2014 09:36:30 +0000

In that case you can argue why not do it for all routes as well.

On 30/07/14 11:30, "Xuxiaohu" <[email-masked]> wrote:

>Why do you need to distinguish them from each other? In other words, why
>can't PE routers process the host route to a given VRF loopback address
>of a remote PE router as a normal remote host route (i.e., on-demand
>installation)?
>
>Best regards,
>Xiaohu
>
>this is generic VRF functionality, nothing to do with virtual subnet. I
>am not talking to the IP address on the virtual subnet interface.

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 30 Jul 2014 09:48:58 +0000

Hi Wim,

I just want to figure out in which scenario the host route to the VRF interface address of a remote PE router should be FIB-installed by default. If there is a scenario, I agree that your proposal of using communities is the best way.

Best regards,
Xiaohu

> Sent: Wednesday, July 30, 2014 5:37 PM
> >Why do you need to distinguish them from each other? In other words,
> >why can't PE routers process the host route to a given VRF loopback
> >address of a remote PE router as a normal remote host route (i.e.,
> >on-demand installation)?
> >
> >Best regards,
> >Xiaohu
> >
> >>> >>real host routes  that can be installed on demand. It would be
> >>> >>good to show how the control  plane could distinguish them using
> >>> >> >multiple PE routers, CE host routes need to be exchanged among
> >>> >> >PE routers. As a result, the forwarding table size of PE routers
> >>> >> >(e.g., some old ToR
> >>> >> >(http://tools.ietf.org/html/draft-xu-l3vpn-virtual-subnet-fib-re
> >>> >> >d
> >>> >> >uct
> >>> >> >ion
> >>> >> >-00
> >>> >> >During the L3VPN WG session at Toronto, many people had
> >>> >> >expressed their supports for the WG adoption of this work
> >>> >> >(Thanks a lot for your supports). However, there are still a few
> >>> >> >people who are not in favor of the WG adoption. According to WG
> co-chairs'

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Wed, 30 Jul 2014 10:10:45 +0000

See right now there is /32 or /128 routes which can come from hosts in
virtual subnet/CE-PE protocol/static routes/loopbacks/etc and to figure
out the origin you have very little means doing so. So if an operator
wants to distinguish the installation by default in the FIB it would be
good to tag the origin and he can than decide based on local policy what
to do. I believe it is a good practice and should be described in the
draft.

This is what I meant to say

On 30/07/14 11:48, "Xuxiaohu" <[email-masked]> wrote:

>Hi Wim,
>
>I just want to figure out in which scenario the host route to the VRF
>interface address of a remote PE router should be FIB-installed by
>default. If there is a scenario, I agree that your proposal of using
>communities is the best way.
>
>Best regards,
>Xiaohu
>

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 31 Jul 2014 07:24:34 +0000

Hi Wim,

Great. How about adding the following text somewhere in the draft:

"If one or more particular remote host routes need to be installed by default for whatever reasons, the best way to realize such goal is to attach a special extended community attribute to those particular host routes by originating PE routers or route reflectors. Upon receiving any host routes attached with the above extended community attribute, non-APR PE routers would install them by default"

Of course, it would be much appreciated if you could provide some text.

Best regards,
Xiaohu

> Sent: Wednesday, July 30, 2014 6:11 PM
> See right now there is /32 or /128 routes which can come from hosts in virtual
> subnet/CE-PE protocol/static routes/loopbacks/etc and to figure out the origin
> you have very little means doing so. So if an operator wants to distinguish the
> installation by default in the FIB it would be good to tag the origin and he can
> than decide based on local policy what to do. I believe it is a good practice and
> should be described in the draft.
> 
> >> >Why not, if I configure a loopback in the VRF it has to be
> >> >advertised, this is generic VRF functionality, nothing to do with
> >> >virtual subnet. I am not talking to the IP address on the virtual subnet
> interface.
> >> >>In the Virtual Subnet context, the host route corresponding to the
> >> >>VRF interface address doesn't need to be advertised.
> >> >>
> >> >>Best regards,
> >> >>Xiaohu
> >> >>
> >> >>> >> levels: real loopbacks that need to be installed by default
> >> >>> >>and real host routes  that can be installed on demand. It would
> >> >>> >>be good to show how the control  plane could distinguish them
> >> >>> >>using communities or the likes.
> >> >>> >>
> >> >>> >> >(http://tools.ietf.org/html/draft-ietf-l3vpn-virtual-subnet)
> >> >>> >> >is intended for building L3 network virtualization overlays
> >> >>> >> >within and/or across data centers. Since a subnet is extended
> >> >>> >> >across multiple PE routers, CE host routes need to be
> >> >>> >> >exchanged among PE routers. As a result, the forwarding table
> >> >>> >> >size of PE routers (e.g., some old ToR
> >> >>> >> >As CE host routes may still need to be maintained on the
> >> >>> >> >control plane of PE routers in some cases (e.g.. MVPN
> >> >>> >> >scenario), this draft
> >> >>> >> >) proposes a very simple mechanism for reducing the FIB size
> >> >>> >> >of PE routers without any change to the RIB and even the
> >> >>> >> >routing
> >> >>>table.
> >> >>> >> >
> >> >>> >> >(Thanks a lot for your supports). However, there are still a
> >> >>> >> >few people who are not in favor of the WG adoption. According
> >> >>> >> >to WG
> >> co-chairs'

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Thu, 31 Jul 2014 07:27:45 +0000

The question is than do we want to standardise this community?

On 31/07/14 09:24, "Xuxiaohu" <[email-masked]> wrote:

>"If one or more particular remote host routes need to be installed by
>default for whatever reasons, the best way to realize such goal is to
>attach a special extended community attribute to those particular host
>routes by originating PE routers or route reflectors. Upon receiving any
>host routes attached with the above extended community attribute, non-APR
>PE routers would install them by default"
>
>>virtual

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 31 Jul 2014 07:45:14 +0000

Although our original intention is to make this draft as an informational draft, it seems fine to me to make it as a standard track draft if the WG believe that extended community needs to be standardized.

Best regards,
Xiaohu

-----Original Message-----
From: Henderickx, Wim (Wim) [mailto:[email-masked]] 
Sent: Thursday, July 31, 2014 3:28 PM
To: Xuxiaohu; [email-masked]
Subject: Re: About the WG adoption of draft-xu-l3vpn-virtual-subnet-fib-reduction-00

On 31/07/14 09:24, "Xuxiaohu" <[email-masked]> wrote:

>routes by originating PE routers or route reflectors. Upon receiving 
>any host routes attached with the above extended community attribute, 
>non-APR PE routers would install them by default"
>
>> See right now there is /32 or /128 routes which can come from hosts 
>>in virtual  subnet/CE-PE protocol/static routes/loopbacks/etc and to 
>>figure out the origin  you have very little means doing so. So if an 
>>operator wants to distinguish the  installation by default in the FIB 
>>it would be good to tag the origin and he can  than decide based on 
>>local policy what to do. I believe it is a good practice and  should 
>>be described in the draft.
>> 
>> >I just want to figure out in which scenario the host route to the 
>> >VRF interface address of a remote PE router should be FIB-installed 
>> >by default. If there is a scenario, I agree that your proposal of 
>> >using communities is the best way.
>> >
>> >Best regards,
>> >Xiaohu
>> >
>> >> >Why do you need to distinguish them from each other? In other 
>> >> >words, why can't PE routers process the host route to a given VRF 
>> >> >loopback address of a remote PE router as a normal remote host 
>> >> >route (i.e., on-demand installation)?
>> >> >
>> >> >Best regards,
>> >> >Xiaohu
>> >> >
>> >> >In this case you need to distinguish between host routes and 
>> >> >these
>> >>VRFs.
>> >> >>In the Virtual Subnet context, the host route corresponding to 
>> >> >>the VRF interface address doesn't need to be advertised.
>> >> >>
>> >> >>Best regards,
>> >> >>Xiaohu
>> >> >>
>> >> >>> >>and real host routes  that can be installed on demand. It 
>> >> >>> >>would be good to show how the control  plane could 
>> >> >>> >>distinguish them using communities or the likes.
>> >> >>> >>
>> >> >>> >> >(http://tools.ietf.org/html/draft-ietf-l3vpn-virtual-subne
>> >> >>> >> >t) is intended for building L3 network virtualization 
>> >> >>> >> >overlays within and/or across data centers. Since a subnet 
>> >> >>> >> >is extended across multiple PE routers, CE host routes 
>> >> >>> >> >need to be exchanged among PE routers. As a result, the 
>> >> >>> >> >forwarding table size of PE routers (e.g., some old ToR
>> >> >>> >> >switches) may become a big concern in large-scale data 
>> >> >>> >> >center environments. In fact, some folks had already 
>> >> >>> >> >expressed their concerns about this potential FIB scaling 
>> >> >>> >> >issue during the WG adoption poll of
>> >> >>> >>the Virtual
>> >> >>> >> Subnet draft.
>> >> >>> >> >
>> >> >>> >> >(http://tools.ietf.org/html/draft-xu-l3vpn-virtual-subnet-
>> >> >>> >> >fib
>> >> >>> >> >-re
>> >> >>> >> >d
>> >> >>> >> >uct
>> >> >>> >> >ion
>> >> >>> >> >-00
>> >> >>> >> >) proposes a very simple mechanism for reducing the FIB 
>> >> >>> >> >size of PE routers without any change to the RIB and even 
>> >> >>> >> >the routing
>> >> >>>table.
>> >> >>> >> >
>> >> >>> >> >(Thanks a lot for your supports). However, there are still 
>> >> >>> >> >a few people who are not in favor of the WG adoption. 
>> >> >>> >> >According to WG
>> >> co-chairs'
>> >> >>> >> >suggestion, I would like to request those opposers to 
>> >> >>> >> >explain their reasons so that we could further improve the 
>> >> >>> >> >draft if
>> >> >>>possible.
>> >> >>> >> >
>> >> >>> >> >Best regards,

---

From: <[email-masked]>
Date: Thu, 31 Jul 2014 08:03:08 +0000

Hi Xiaohu,

> Although our original intention is to make this draft as an informational draft,
> it seems fine to me to make it as a standard track draft if the WG believe that
> extended community needs to be standardized.

FYI: IANA allocated BGP communities are FCFS.
Depending on your use case, you may want a non-transitive extended community which will be FCFS as soon as draft-ietf-idr-reserved-extended-communities gets published i.e. as soon as draft-ietf-idr-as4octet-extcomm-generic-subtype get implemented (<ad> so feel free to implement this short draft in your spare time. ;-) </ad> )

So the draft may be kept informational is this was you intention.

Regards,
Bruno
> >> >> >>> >> >Xiaohu (on behalf of all co-authors)

_________________________________________________________________________________________________________________________

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.