Subject: RE: [bmwg] draft-vapiwala-bmwg-frr-failover-meth-00.txt

From: "Arun Gandhi" <[email-masked]>
Date: Wed, 12 Apr 2006 17:00:54 -0400

Hello Authors:

Overall, it's a well versed draft. However, I have couple comments that
may need clarifications.

Review comments:
----------------

a) Abstract: 

> The failover time could also greatly differ based on
> the design and implementation and by factors like the
> number of prefixes carried by the tunnel, the number
> of primary tunnels affected by the event that caused
> the failover, number of primary tunnels the backup
> protects and type of failure etc.

IMHO, there are 3 more important factors that may well 
impact the failover time and they are:

1- Switchover mechanism (to the backup path) following
   failure (which tells how soon the failure is known 
   to the node initiating switchover). 
2- Resources allocated on the backup path (are they same
   or comparable to primary path). This has not been 
   mentioned in the draft. If the assumption is that the
   backup path is exactly the same as the primary, it'll
   be nice to be clearly outlined.
3- Type of physical media (Note: this nicely considered 
   in the draft but has been missing here).

b) Section 1:

The term "working path" is used but it never gets defined
or used again elsewhere in the draft. I'd request the 
authors to add to Section 2 some definitions for terms 
such as "working path", "primary path", "backup path", 
"Additive Latency", "Reversion Time", "Failover Time" for 
sake of completeness.

Also, IMO, "packets received" and "packets sent" besides 
other items such as "IP packet", "sequence numbers", 
"departure time", and "arrival time" should be added that
the tester must record inorder to characterize/measure 
packet drops.

c) Section 3:
 
IMO, as a general observation, the "Protection Mechanism"
and "Resources available on the backup path" must also be
added to the list of fundamentals of MPLS Protection
testing. 

   *	Section 3.1:
      Another possible causes are: Node shutdown; Node 
      failure/crash.

   *	Section 3.2:
      Ethernet technologies such as Gigabit Ethernet can
      rely on BFD (Bidirectional Failure Detection). Also,
      here it will nice to explicitly mention about it's
      dependency on the configured timer values.

   *	Section 3.3:
      Can you please explain or elaborate the statement..
      "There is no need to rely on the DUT to produce the
      test results."? 

   *	Section 3.7: 
      IMHO, the last sentence should be considered for
      revision or further clarification.

d) Section 5:

IMHO, bullet (5) in Procedure should be considered for 
revision.
 
Regards,
Arun Gandhi.

> ________________________________
> 
> 	From: [email-masked] 
>  [mailto:[email-masked]] On Behalf Of Samir Vapiwala (svapiwal)
> 	Sent: Tuesday, January 03, 2006 11:00 AM
> 	To: [email-masked]
> 	Cc: Rajiv Papneja
> 	Subject: [bmwg] draft-vapiwala-bmwg-frr-failover-meth-00.txt 
> 	
> 	
> 	FYI
> 	 
> 	Please send your comments on new draft
> 	 
>
http://www.ietf.org/internet-drafts/draft-vapiwala-bmwg-frr-failover-met
h-00.txt
>	 
>	Thanks
>	Samir Vapiwala, Rajiv Papneja , Jay Karthik

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