Hi Robert, Thanks for your comments!
>If your implementation configures a same VPN label across N sites >manual or by SDN magic you are free to advertise it along with VPNv4 >routes. I am not sure why any draft is needed for that at all. After >all it is your implementation. [ZMG] The point is that each PE used to allocate the VPN label for each VRF locally without knowing what label has been assigned by other PEs. Now, we need them “happen to” allocate the same label for each VRF. >To the best of my knowledge L3VPN spec does not prohibit in any RFC to >advertise the same label across N PEs. In fact it does not mandate any >correlation of label value across PEs so you are pretty free to go. [ZMG] Or you can speak in this way. It’s free for this draft to mandate a REQ to the label allocation that PEs in a Redundant Group always allocate the same label for each VRF. <snip> >I am a bit implicitly assuming you are talking about per vrf label >only. [ZMG] Yes, you are right. We are assuming the “per VRF” allocation in our draft for the sake of scalability. >Other modes of label allocation would be rather cumbersome [ZMG] I agree with you. Other two finer grained label allocations are not recommended. <snip> >As Eric mentioned today devil is in details and where you go down to >actually implement robust solution I can bet that you will start very >much to like to concept of context labels for protection and >independent VPN (or for that matter any other application - pwe3/l2vpn >etc) label allocation pardigm :) [ZMG] I believe when Eric made that statement, he assumed the label allocation was done by a “SDN central controller”. I guess that was simply an abstraction caused by the chaos of the “central controlled” conception. [ZMG] To make the discussion clear, let’s forget about the “central controlled” like stuff from now on. We proposed the draft leveraging ICCP connection to do the label negotiation. Please focus on that choice. ICCP has already provided that robustness. Why reinvent the wheel? :) Regards, Mingui ________________________________________ From: [email protected] [[email protected]] on behalf of Robert Raszuk [[email protected]] Sent: Saturday, November 09, 2013 14:20 To: Mingui Zhang Cc: Jakob Heitz; [email protected]; [email protected] Subject: Re: Why we consider the method of "label sharing for fast PE protection" Hi Mingui, If your implementation configures a same VPN label across N sites manual or by SDN magic you are free to advertise it along with VPNv4 routes. I am not sure why any draft is needed for that at all. After all it is your implementation. To the best of my knowledge L3VPN spec does not prohibit in any RFC to advertise the same label across N PEs. In fact it does not mandate any correlation of label value across PEs so you are pretty free to go. However if you go that path please notice that this is not just about .. "let's configure same VPN label". We do have three types of VPN labels: - per vrf - per next hop - per prefix I am a bit implicitly assuming you are talking about per vrf label only. Other modes of label allocation would be rather cumbersome to be done manually or even programmatically as their appearance and allocation must be coordinated with new CE or new VPN advertisement in any VPN site and across existence of already provisioned sites. As Eric mentioned today devil is in details and where you go down to actually implement robust solution I can bet that you will start very much to like to concept of context labels for protection and independent VPN (or for that matter any other application - pwe3/l2vpn etc) label allocation pardigm :) Best regards, R. On Thu, Nov 7, 2013 at 11:15 PM, Mingui Zhang <[email protected]> wrote: > Hi Jakob, > > > > There are three ways, > > > > 1. Always, this label can be configured. > > > > 2. We do have a companion draft to realize this. Please look at > http://tools.ietf.org/html/draft-zhang-pwe3-iccp-label-sharing-00 . We > already presented this draft in pwe3. (Let me copy this track to the pwe3 > mailing list.) With the ICCP connection established, PEs can negotiate this > label. > > > > 2. The last choice is to use a global label if it was supported. > > > Thanks, > Mingui > ________________________________ > From: Jakob Heitz [[email protected]] > Sent: Friday, November 08, 2013 5:50 > To: Mingui Zhang; [email protected] > Subject: RE: Why we consider the method of "label sharing for fast PE > protection" > > Several people at the mike asked this question: > How do you make sure that the PEs allocate the same label? > > This needs to be part of the document, because it is quite important. > If an external entity allocates the labels, the protocol > between the PEs and that entity needs to be standardized. > Since this is a feature that provides redundancy, the > label allocating entity also needs to be backed up by a > redundant entity. The protocol between the redundant > label allocators needs to be standardized. > > -- > > Jakob Heitz. > > ________________________________ > From: [email protected] [[email protected]] on behalf of Mingui > Zhang [[email protected]] > Sent: Thursday, 07 November 2013 11:40 AM > To: [email protected] > Subject: Why we consider the method of "label sharing for fast PE > protection" > > Hi, > > As a choice of fast PE protection, > > 1. This solution is simple and light-weight. We need not introduce the > complex context label table in PE routers. So label table need not be stored > repeatedly on RG members. > > > 2. Also, it’s easy to be deployed. It does not bring any change to P routers > (control plane & data plane). It even does not change the data plane of PE > routers. > > > 3. In addition, it does not bear the restriction of “no > penultimate-hop-popping”. > > > > Thanks, > Mingui
