RE: Why we consider the method of "label sharing for fast PE protection"

[Mingui Zhang <[e-mail]>]

Hi Bruno, 

My comments inline below. [Mingui]

>1)      The document does not describe the scaling impact on the core as it
>creates, in the core IGP, states on a per CE (customers'site) basis. For large SP,
>this will represent a significant impact on the IGP and will degrade the IGP
>convergence time. ( o(number of important IGP prefixes to rewrite) )

[Mingui] Here, I need to point out that the vNH is not created per CE. If multiple CEs are connected to an RG, one vNH is enough. When you read the first sentence of Section 2.1, you will be clear.
[Mingui] "A vNH router is created in IGP to represent the set of CEs which are dual-homed to the same egress PEs in the Service Provider's backbone".
[Mingui] Exactly, it's per RG basis. In a real network, the numbers of RGs is comparable to the number of PEs, so it's similar to the per PE basis choice (the best choice) in draft-minto.

>2)  > A master PE is elected in the same way the DR is selected (see section 7.3
>of [RFC2328] <http://tools.ietf.org/html/rfc2328#section-7.3> ), or the DIS is
>selected [ISIS
><http://tools.ietf.org/html/draft-zhang-l3vpn-label-sharing-01#ref-ISIS> ].
>I don't think that this is directly applicable. You may need to elaborate on this
>and specify the corner cases (e.g. CE starts and advertise its routes to both PE
>at the same time. Hence both PE believes they are the first one and hence are
>the master.) Also in BGP VPN or IGP there is no advertisement of "Router
>Priority". I guess that this can always be specified, but this remains to be done.

[Mingui] That's a valid point. We did define the "Priority" in the "vNH TLV" in Section 2.3.3 of the companion draft (http://tools.ietf.org/html/draft-zhang-pwe3-iccp-label-sharing-00). We can change the words to fix this inconsistence.

<snip>
>IMHO additional elaboration may be required as the nominal PE
>may be the nominal because it has advertised a more specific route. Hence a
>look up in the VRF will match the more specific route from the nominal/failed PE.
>Not sure how a vanilia PE implementation would react. The issue is that when
>receiving the packet, the backup PE does not know whether the nominal is dead
>or not. In contrast to draft-minto for which the PE know whether it's used as
>backup or not, thanks to the contextual label.

[Mingui] So you propose the scenario that the backup PE directs packets to the primary PE since the primary PE advertised a more specific route. This makes the primary PE be an inevitable point on all forwarding paths to the CE. Eric ever used "BGP LOCAL_PREF" to compose a similar scenario (http://www.ietf.org/mail-archive/web/l3vpn/current/msg03691.html).

[Mingui] For this subtle case, the redundant connection is not utilized in the first place. If customers prefer resilience to more specific routes, the backup PE should not use the primary PE as the next hop. 

[Mingui] All in all, if customers really want the resilience, those routes via the primary PE SHOULD NOT be installed in the FIBs of backup PEs. 

[Mingui] By the way, the scenario you designed may suffer from transient loop issue. Imagine that the more specific routes fails on the primary PE, the primary PE will resort to the backup PE. At that time, it's probably that the backup PE is unaware of the failure. It will send packet back to the primary PE. Oops, loop occurs. Following the above "SHOULD NOT be installed" requirement, such kind of loops can be avoided.

<snip>
>More seriously:
>- Draft minto does not need to define a new protocol (ICCP) in order to learn the
>labels of the backup PE. BGP already provides this. While ICCP is a 79 pages
>draft, plus 11 for the extension.
>- Draft zhang relies on the having the same label on redundant PE. While this is
>doable, this is a significant change compared to the existing deployed model.
>- regarding context label tabel
>                  - From a standardization standpoint, context-specific label
>space is already defined in RFC 5331, so nothing new.
>                  - From an implementation standpoint, I agree that this
>requires some additional resources in the forwarding plane. But draft minto
>does not require that all PE support this. This can be performed by a protector
>PE if some PE do not support it.

[Mingui] If nothing new for protocols, this becomes an implementation issue. Then, should this be considered in IETF? :-)

[Mingui] We do not define ICCP, we make use of it. If we can have a solution happen in purely the control plane, as IETFers, we should be happy. If customers want this feature, I promise you will see this feature supported by products in several months. For vendors who have already implemented ICCP, it can be faster. More importantly, this is a "once for all" effort compared to the redundant forwarding tables. 

[Mingui] As Robert and I discussed previously, existing deploy model does not prohibit PE to advertise the same label. I don't think this changes the existing deploy model.

>So label table need not be stored repeatedly on RG members.
>
>#Bruno: agreed.
>
>
>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.
>
>#Bruno: It's not easy to deploy as it mandates to update all PE routers, both
>nominal and backup. While with draft-minto-2547-egress-node-fast-protection
><http://tools.ietf.org/html/draft-minto-2547-egress-node-fast-protection-02>
>the deployment of a single protector PE can fast protect all PE of the AS with no
>change on existing PE.

[Mingui] As I explained above, the update to the control plane should be OK.

[Mingui] OK. Let me give an analysis of the draft-minto-2547-egress-node-fast-protection. I hope this is constructive when the draft is updated.

[Mingui] a.	The co-located and hybrid models require configuration, which is error prone and increases a management burden to operators.
[Mingui] b.	The centralized model is not robust. How do you handle the failure of the centralized protector itself? This problem had been proposed for the "central controller" stuff. 
[Mingui] c.	The delegation of protector is topology dependent. I guess the number of possible alternative paths held by the protector is a much smaller set of all possible alternative paths. 
[Mingui] d.	The centralized protector has to manage the context label assignment and maintain multiple forwarding tables for all RGs. I am afraid this model is not scalable. 
[Mingui] e.	There is a brief description on Fast ReRoute in Section 5.3. For the "RSVP" choice, it depends on another individual draft [http://tools.ietf.org/html/draft-minto-2547-egress-node-fast-protection-02]. Does this draft mandates update on P and PE routers? For the "LDP" choice, it's not clear how IGP can find alternative paths (I find the "beyond the scope" words.). I think the coverage of alternative paths cannot be very good, especially when the centralized protector is used.

>3. In addition, it does not bear the restriction of "no penultimate-hop-popping".
>
>#Bruno: ultimate hop poping is only required for the label associated with the
>context table of the backup PE. This is required to identify the context-specific
>label space. This is not an additional argument compared to 1 (context label
>table).

[Mingui] I agree. 

Thanks,
Mingui