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

From: "Samir Vapiwala \(svapiwal\)" <[email-masked]>
Date: Wed, 26 Apr 2006 13:40:21 -0400

Hi Arun 

Sorry for delay in our response. Thanks for your comments and we really
appreciate you spending time in reviewing our draft.

Please see my responses inline. (marked Samir:)

Regards,
Samir

-----Original Message-----
From: Arun Gandhi [mailto:[email-masked]]
Sent: Wednesday, April 12, 2006 5:01 PM
To: Samir Vapiwala (svapiwal)
Cc: 'Rajiv Papneja'; [email-masked]; [email-masked]
Subject: RE: [bmwg] draft-vapiwala-bmwg-frr-failover-meth-00.txt 

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). 

Samir: This will be addressed in the new merged draft that will be
posted soon..

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.

Samir :  We will add text to indicate our assumption that the resource
constraints are met for the backup and that the backups would not be
oversubscribed.

3- Type of physical media (Note: this nicely considered 
   in the draft but has been missing here).

Samir : Good catch, we'll update in merged draft.

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.

Samir : During the next revision of the terminology document, we will
define these terms. Furthermore, if you would like to contribute
definitions of these terms, we would be very happy. 

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.

Samir : We are currently discussing if the next version needs to include
this to be "work item in scope" or not. If we choose not to address
errored packets, duplicate packets and out of packets etc.  we will have
text to justify why recording the same (or not) is required (or not
required).

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.

Samir : We have new procedures in merged draft for node failure events,
which will cover above events

   *	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.

Samir : Sure we will add timer values. Not only for BFD but we'll add it
for RSVP hello too.

   *	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."? 

Samir :You are right. There is a missing word. We will rephrase to
"There is no need to rely on the understanding of the implementation
details of the DUT to get the required test results".

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

Samir : We have similar comments from others too, we'll reword it in
merged draft.

d) Section 5:

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

Samir:  In merged draft we are introducing 4 procedures and in each
procedure we are measuring FRR failure time and reversion time (backup
to  primary path), I don't think we need a separate procedure for just
reversion.
 
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