Subject: [bmwg] Comments on draft-vapiwala-frr-failover-measurement-methodology-02.txt

From: JP Vasseur <[email-masked]>
Date: Thu, 16 Mar 2006 16:57:27 -0500

Here are a few comments:

First of all, very useful work.

* The ID definitely requires a fair amount of editorial work but  
useful content
* Section 1:

      In figure 1, TG & TA are Traffic Generator & Analyser  
respectively.
      A tester is set outside the node as it sends and receives IP  
traffic
      along the working Path, run protocol emulations simulating real  
world
      peering scenarios.

You may want to detail which variables should be considered in order  
to gather accurate metrics. For instance, do we want to
measure the restoration times and see whether there are any  
dependencies with the total LSDB size, number of prefixes, ... ?
* Section 3.2
         Failures on Ethernet technology links such as
         Gigabit Ethernet rely upon Layer 3 signaling indication for  
failure.
BFD ?
* Section 3.2
I would suggest to say a few words to determine/benchmark the failure  
detection times as it may not always be a negligible component of the  
overall rerouting time
* Section 3.4
         It is intended with Fast Reroute
         that the less than 45msec failover requirement be maintained  
when
         scaling the number of protected LSPs.
Why 45ms ?
* When you refer to MPLS Protection, I guess that you focus on Local  
Protection (RFC4090) ?
*  Section 4
- When you mention the number of labels before and after failure,  
mention where (since this may vary along the backup path if PHP is in  
use)
- With Layer3 VPN, PE to PE TE LSPs, mention that there's no LDP in use
- I did not read all the scenarios but you may want to mention why  
testing of each scenario is required
* Section 5
- In the procedure you may want to look at the IGP convergence;  
indeed, there might be scenarios where the IGP convergence will lead  
to packet drops due to micro-loops. Although this is generally not  
the case, such packet drops may interfere with MPLS protection  
depending on the IGP tuning
- I did not see anything about the testing of the RSVP refresh (along  
the backup tunnel path): indeed, if this is not properly handled this  
may lead to state time-out.

JP.

_______________________________________________
bmwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/bmwg

---

From: JP Vasseur <[email-masked]>
Date: Thu, 16 Mar 2006 17:05:22 -0500

Begin forwarded message:

> From: JP Vasseur <[email-masked]>
> Date: March 16, 2006 4:57:27 PM EST
> To: "Samir Vapiwala ((svapiwal))" <[email-masked]>,  
> [email-masked], [email-masked]
> Cc: [email-masked]
> Subject: [bmwg] Comments on draft-vapiwala-frr-failover-measurement- 
> methodology-02.txt
>
> Here are a few comments:
>
>      along the working Path, run protocol emulations simulating  
> real world
>      peering scenarios.
>
> You may want to detail which variables should be considered in  
> order to gather accurate metrics. For instance, do we want to
> I would suggest to say a few words to determine/benchmark the  
> failure detection times as it may not always be a negligible  
> component of the overall rerouting time
> * Section 3.4
>         that the less than 45msec failover requirement be  
> maintained when
> * When you refer to MPLS Protection, I guess that you focus on  
> Local Protection (RFC4090) ?
> *  Section 4
> mention where (since this may vary along the backup path if PHP is  
> in use)
> indeed, there might be scenarios where the IGP convergence will  
> lead to packet drops due to micro-loops. Although this is generally  
> not the case, such packet drops may interfere with MPLS protection  
> - I did not see anything about the testing of the RSVP refresh  
> (along the backup tunnel path): indeed, if this is not properly  
> handled this may lead to state time-out.
>
> JP.
>

---

From: Rajiv Papneja <[email-masked]>
Date: Mon, 20 Mar 2006 00:05:42 -0500

Hello JP,

Thanks for your comments, and I really appreciate you spending time in
reviewing our draft.

Please see my responses inline.

Regards,
Rajiv

Quoting JP Vasseur <[email-masked]>:

>>      In figure 1, TG & TA are Traffic Generator & Analyser  respectively.
>>      A tester is set outside the node as it sends and receives IP  traffic
>>      along the working Path, run protocol emulations simulating  real world
>>      peering scenarios.
>>
>> order to gather accurate metrics.
[rp] We will definitely try to clarify this.
>> For instance, do we want to
[rp] Yes.
>>         Gigabit Ethernet rely upon Layer 3 signaling indication for  
[rp] Yes, may be. We can consider this. But many vendors currently do not
support this feature. BFD could also be used for IGP liveliness detection, for
MPLS LSPs failure detection, and Ethernet. This may be the ideal way 
and we can
definitely consider adding this as an option.
>> component of the overall rerouting time
[rp] Yes, agree. This is very good input.
>>         that the less than 45msec failover requirement be  maintained when
[rp] We can remove the mention of 45ms limit or we can change this to 
state that
how many prefixes or tunnel can get switched in 45ms.

>> Local Protection (RFC4090) ?
[rp] yes.
>> mention where (since this may vary along the backup path if PHP is  
[rp] On Point of local repair, we will update

>> - With Layer3 VPN, PE to PE TE LSPs, mention that there's no LDP in  use
[rp] We will mention it.
>> testing of each scenario is required
[rp] Good point, we will try to add a motivation section to all
scenarios
>> depending on the IGP tuning
[rp] we will definitely consider
>> handled this may lead to state time-out.
[rp] We will add this in procedure