Subject: [scale] new updated slides

From: Loa Andersson <[email-masked]>
Date: Mon, 02 Dec 2013 00:59:37 +0800

Folks,

Lou and I have been editing the slides a bit. Please review and comment.

Next step will be to start working on the problem statement and we will
need help with that. If you are interested please get in contact with
us.

/Loa and Lou
-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: <[email-masked]>
Date: Mon, 2 Dec 2013 10:54:35 +0000

Hi Loa, Lou,

I'm unsure about many drafts that are (still) listed, and that to me, do not address scaling in particular. Among them:
- draft-ietf-l3vpn-end-system-02
- draft-xu-l3vpn-virtual-subnet
- draft-sd-l2vpn-evpn-overlay
- draft-rabadan-l2vpn-evpn-prefix-advertisement
If these drafts are really believed to relate to scaling in some specific way, then I believe that how they do would deserve to be made explicit.

Also factoring-out in one item the set of drafts around the big label proposal would increase readability.

Second, in the possible concerns listed on slide 3:
- scaling wrt. the number of VRFs/VSIs/EVIs on a said PE is probably another relevant metric
- talking about "size of a VPN" sounds vague : maybe talk more specifically about "number of sites, CEs, VRFs, prefixes, MACs, multicast states -- per VPN" would be better

Thanks,

-Thomas

Loa Andersson :
Folks,

/Loa and Lou

_______________________________________________
scale mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/scale

_________________________________________________________________________________________________________________________

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.

---

From: Pedro Roque Marques <[email-masked]>
Date: Tue, 3 Dec 2013 00:11:54 -0800

Loa,
Looking at the slides, it seems that most of the documents sited are aimed at promoting central label allocation. This is hardly a topic that i would consider related to scale other than in it decreases the flexibility of the solutions.

There seem to be a few attempts to justify central allocations in these documents:

a) VLAN emulation
VLANs use global tag to identify the virtual network; the default assumption from some technologies trying to emulate vlans is that this a positive. I believe this is a very significant misconception: a single tag makes it really hard to create topologies that are different from the default. For instance to implement a hub and spoke topology, which in switching is called "private vlans" requires a switch to use multiple internal vlans for the same external tag. Switches actually do map this external tag into an internal tag (locally assigned by the switch). They just lack the communication mechanism to make label assignment hob-by-hop.

There is no reason why VXLAN tags cannot be egress assigned for instance. The EVPN control plane can (and is) used to manage VXLAN encapsulation and does downstream assignment.

LAN services can be provided when downstream assignment is used. Downstream assignment can enable one to, for instance, insert an appliance between two end-points without modifying the network configuration on the end-points. i.e. by simply manipulating next-hops. This has been one of the traditional limitations of LANs.

b) Multicast
Upstream assignment provides the necessary support for being able to send a multicast packet to multiple downstreams. It does not require the central coordination of global allocation.

c) Identifying the ingress of a multicast packet or a packet sent on a mp2p LSP.
This is one issue where there is the need for better solutions.
One practical approach is to use RFC3107. P routers can advertise their loopback to a single RR that modifies the route's next-hop; and use the received route advertisement from the RR as the label that identifies the source. This has a couple of problems that need to be solved: how to have multiple RRs for availability / resiliency and how to allow the domain to use multiple RRs. These are problems that can be solve... imho they should be addressed in the MPLS WG.

As a whole, it seems to me that this issues are unrelated to scale and that most of the proposals seem to be leading towards the path of removing the main feature of MPLS over other solutions: the flexibility provided by the fact that not all nodes in a network must have the same view of a LAN or a route.

My opinion is that there is no basis for a independent WG or BOF.
L3VPN control plane scaling can be address in the respective WG;
L2VPN control plane issues likewise;
The MPLS WG can discuss global label allocation; i believe that i'm not the only one that will suggest that it is misguided to try to adopt global labels and that instead there should be a solution focused on the ingress identification. A new mailing list / WG is not the right place for this discussion.

  Pedro.
 
On Dec 1, 2013, at 8:59 AM, Loa Andersson <[email-masked]> wrote:

> <non-wg-forming-bof-pa8.pptx>_______________________________________________
> scale mailing list
> [email-masked]

---

From: Loa Andersson <[email-masked]>
Date: Fri, 06 Dec 2013 13:34:58 +0800

Pedro,

I'd like to make one or to things clear when it comes to the listed
slides

- we kind of inherited the draft list, and have chosen to be careful
   removing drafts without being very sure that it does not belong in
   the list
- I've have not read the info around the list of drafts as "this is the
   drafts that will give us the solution of the MPLS VPN Scaling Problem"
   I've seen i more like "these drafts might contain information that is
   relevant when we try to figure out what the critical scaling issues
   are"; i.e. the draft does not have to be "about scaling", but it might
   have "an impact on scaling"!
- having said that I do not claim that this "the list", only that it is
   a zero order approximation; if we find it useful let us refine the
   list, if not let us start to write a problem statement and see if
   some/all/more drafts can be used as references.

The discussin on whether central allocation (in all cases) of labels are
not closed for me. Even if I believe I no the answer I willing to listen
some more.

/Loa

--

---

From: Loa Andersson <[email-masked]>
Date: Fri, 06 Dec 2013 13:58:58 +0800

Thomas,

I tried to explain my view of why drafts are listed in a previous
mail, don't know if that works for everyone. If we find we want to
work with the list rather than or in parallel to a problem statement
I would be happy to add and delete drafts as necessary, based on
whether the contain relevant info or not.

On rearranging the list, my response from the reptile brain would be
"please supply text", meaning take the slide and edit it to what you
want it to be.

I've a friend that use to say "If you are talking about a specific
horse called 'Brunte' (yes that is a common name of Swedish horses),
talk about and name him 'Brunte'! Don ot talk about a "quadruped animal
of the Equus genus in the family of Equidae".

Meaning, yes I for be as specific as possible!

/Loa

On 2013-12-02 18:54, [email-masked] wrote:
> Hi Loa, Lou,
>
> I'm unsure about many drafts that are (still) listed, and that to me, do
> not address scaling in particular. Among them:
> If these drafts are really believed to relate to scaling in some
> specific way, then I believe that how they do would deserve to be made
> explicit.
>
> - talking about "size of a VPN" sounds vague : maybe talk more
> specifically about "number of sites, CEs, VRFs, prefixes, MACs,
> multicast states -- per VPN" would be better
>
> Thanks,
>
> -Thomas
>
>
> Loa Andersson :
>> Folks,
>>

--

---

From: Pedro Roque Marques <[email-masked]>
Date: Fri, 6 Dec 2013 09:48:07 -0800

Loa,
Thank you for the clarification. Please see inline.

>  removing drafts without being very sure that it does not belong in

I suspect that i'm not the only one that is going to have an intuitive negative reaction to frame label allocation policy and architecture discussions as "scale". I believe you saw similar comments from others in the list.
I'd strongly recommend you to consider removing these. I believe that there is room for additional discussion when it comes to label allocation techniques. But "scale" wouldn't be typically seen as a "backdoor" attempt and get a default negative reaction.

>  have "an impact on scaling"!

My input would be to try to figure our whether you see this as an ops area effort: deployment best practices, document tradeoffs. Or as a protocol development effort. In my view the later already has its appropriate forums which have been successfully updating the protocols in order to improve issues such as usability and scalability. As an example the L3VPN WG has developed a fair amount of work in the area of limiting the scope of route advertisements in large scale networks (RFC 4684 and other efforts).

>  some/all/more drafts can be used as references.

From your slides the problem statement is really unclear. In fact it is unclear as to whether there is a problem to be solved.

> not closed for me.

I believe we should be open minded. Although it would be great to have in mind previous iterations of the same discussion and have a bit of collective memory. But there are existing forums to have that discussion. Unless of course you can make a compelling argument that: a) this is a issue sufficiently independent of the MPLS, L3VPN and L2VPN protocol developement and b) that the existing forums are not working.

> Even if I believe I no the answer I willing to listen
> some more.
> 
> /Loa

---

From: Loa Andersson <[email-masked]>
Date: Mon, 09 Dec 2013 13:51:11 +0800

Pedro,
<snip>

>
> I suspect that i'm not the only one that is going to have an
   intuitive negative reaction to frame label allocation policy
   and architecture discussions as "scale". I believe you saw
   similar comments from others in the list.

Yes - I think we agree (mostly), but the fact that I recognize
it as an "intuitive negative reaction" makes me wait a bit.

> I'd strongly recommend you to consider removing these. I
   believe that there is room for additional discussion when
   it comes to label allocation techniques. But "scale" wouldn't
   be typically seen as a "backdoor" attempt and get a default
   negative reaction.

hmmmm - I'm not sure about removing, I'd say (if my gut feeling
is right) that we should say that that "different label allocation
policies does not have a (positive) impact on scaling".

/Loa

<snip>

--