Subject: [bmwg] FW: Comments on draft-poretsky-mpls-meth-00.txt

From: [email-masked]
Date: Tue, 18 Nov 2003 11:33:27 -0500

At the request of the BMWG co-chairs I am forwarding an excellent e-mail
regarding draft-poretsky-mpls-meth-00.txt.  This draft is a proposed BMWG
work item.  Further comments to the mailing list regarding interest in this
document and its technical content would be most welcome.
 
Scott
 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, September 24, 2003 1:33 PM
To: [email-masked]
Subject: Fw: Comments on draft-poretsky-mpls-meth-00.txt

----- Original Message ----- 
From: LE ROUX Jean-Louis  <mailto:[email-masked]>
FTRD/DAC/LAN 
To: [email-masked] <mailto:[email-masked]>  
Sent: Wednesday, September 24, 2003 5:12 AM
Subject: Comments on draft-poretsky-mpls-meth-00.txt

	Hi Scott, 

	I'm JL Le Roux from France Telecom, 
we met us during IETF in Vienna, at the end of the BMWG session. 

	I have performed several MPLS FRR tests on various boxes. 
I red your MPLS Protection Benchmarking  draft with much interest and found
it highly relevant. 

	Here is a set of comments and suggestions: 

	-General comments: 

	-1: As regards terminology, it could be better to make the
distinction between Protection and Rerouting as defined in RFC3469.

	Basically, Rerouting means that there is no pre established backup
LSP, 
whereas Protection means that the backup LSP is pre established. 
Actually, Both Protection and Rerouting are Recovery mechanisms. 
Based on that, I would rename the Draft : "Benchmarking Methodology for MPLS
Recovery Mechanisms" 
I would also rename two of the three recovery mechanisms you address: 
HeadEnd reroute -> LSP rerouting 
Standby LSP -> LSP protection 

	-2: As regards Failover events (section 3.1) it could be good to
address more deeply node failures .  
There are several types of node failures (Line Card, Switch Fabric, Power,
Routing Engine...) 
 that may have different impact on detection time and thus one recovery
delays. 
  
-3: As regards Network failover Indication (section 3.2), It could be
interesting to also address detection based on RSVP Fast Hello (RFC 3209
section 5)

	that is used to detect several node failures and also failures on
links without L2 alarms like for instance GbE links. 
As regards Sonet links, it is important to test several alarms (LOS, AIS ,
RDI). Indeed, we observed in several tests that some LSR don't have the same
behavior with LOS and AIS. Sometime FRR is  triggered only by LOS and not by
AIS.

	-4: Comments regarding TE-LSP utilisation 
TE-LSP can be used  to route IP trafic and also MPLS (LDP) trafic, in case
LDP LSPs are nested into a TE-LSP 
We observed in various FRR tests with PLR at Ingress that the recovery delay
can be distinct for IP and MPLS trafic (distinct rewritting procedure in
hardware).

	-5: As regards scalability, section 3.4 should, IMHO, be detailed. 
As you mention the recovery delay depends on the number of primary LSPs to
reroute. 
Actually, it can also depend on the LSP FEC size, ie on the number of IP
prefixes or LDP labels that are injected in  TE-LSPs at HE. 

	We observed, in all FRR tests we ran, that when the PLR is at
Ingress, the recovery delay depends on the number of IP prefixes injected
into the failed TE-LSP and also on the number of LDP LSP nested into the
failed TE-LSP. Indeed in case the PLR is the Ingress Node, all FIB entries
that correspond to the FEC of  the failed LSP have to be rewritten.

	This is, IMHO, and important point to address in FRR benchmarking. 

	-6: Performance Measurement. 
This comment is related to the previous one. 
One important point for ISPs is to measure: 
        In case DUT = PLR at transit: How many TE-LSPs can be rerouted in
less than 50ms. 
        In case DUT = PLR at ingress: How many IP prefixes and LDP LSP,
injected in a protected TE-LSP, can be rerouted in less than 50ms

	We currently use two distinct methods to measure that: 

	-First method = Per TE-LSP measure 
Setup a large number of primary LSPs between Ingress and Egress, protected
by FRR at a transit PLR. 
Send trafic at a given rate into each LSPs, 
Measure trafic at egress, with the capability to distinguish and measure
trafic on a per-LSP basis 
Trigger failure 
Measure packet loss on each TE-LSP and deduce the recovery time for each
LSP. 
Then count the number of TE-LSP that have been recovered in less than 50ms. 

	This method allows to rapidily obtain the result, but it is not
always possible, with existing test tools, to monitor individually a high
number of flows

	(often limited to 1000 flows). 
Thus we also use a method that correspond to what you call Peak-to-Peak
Convergence Time in your IGP Benchmarking methodology draft .

	-Second Method = Dichotomic approach with peak-to-peak time: 
Setup a large number, N, of primary TE-LSPs 
Send trafic into all LSPs 
Measure global received rate at egress 
Trigger Failure 
Measure peak-to-peak rate time and deduce the global recovery delay. 
Replay the test modifying N in a dichotomic manner, in order to find the
number of TE-LSPs that can be fast rerouted in less than 50ms.

	-7 Reversion test: 
When the failed element is repaired, TE-LSPs must be rerouted onto the
nominal path, this is called reversion. 
FRR reversion can be done, locally, by the PLR or, globally, by the HE
(reoptimization). 
Reversion should be done without packet loss. 
We observed, in several tests, packet loss during reversion. Thus, it could
be interesting to add a Reversion Item to this ID.

	-8: Test cases organization (section 5) 
In your node protection test cases, it could be good to add node failure
tests using RSVP hello detection. 
Regarding administative shutdown, you should also add the ability to
administratively "shutdown" an entire node using the IGP overload bit. 

	This is a current pratice for ISPs. When we want to upgrade a node,
we first set up the IGP overload bit so that trafic is rerouted without
packet loss.

	It could be good to add FRR scalability test cases, to measure the
number of LSPs that can be fast rerouted in less than 50ms.

	There are quite important differences between HE reroute, Standby
LSP and FRR, so in order to make this section easily extensible,

	I would suggest the following test case re-organization: 
  
5.1 : Head End Reroute (with four types of failures: local link failure,
remote link failure, transit node failure, administative link&node shutdown)

	5.2 : Standby LSP (with four types of failures: local link failure,
remote link failure, transit node failure, administative link&node shutdown)

	5.3 : Fast Reroute (with three types of failures: link failure, node
failure, administative link&node shutdown) 
5.3.1 DUT = PLR at transit 
5.3.1.1 Basic test 
5.3.1.2 Scalability test 
5.3.2 DUT = PLR at ingress 
5.3.2.1 Basic test 
5.3.2.2 Scalability test 
5.3.3 DUT = PLR at MP 
5.3.4 DUT = PLR at MP & Egress 

	Other minor comments: 

	-Section 1 page 2: 
You mention that Standby LSP is an extension to RSVP-TE.  IMHO standby LSP
does not require any RSVP-TE extension, it is a mechanism local to the HE
LSR.

	You then mention that its advantage is less than 500msec failover:
Actually it depends on the topology and number of prefixes injected into
tunnels. It could be better to mention that stanby protection is faster than
HE reroute without specifying any value.

	You then mention that it requires high resource utilization at the
ingress. Actually it requires resource utilization not only at the ingress,
but along the whole backup path.

	-Page 3: 
FRR is an extension specified in (missing reference [MPLS-FRR-EXT]) 

	You mention that FRR achieves a goal of less than 45msec. Why this
particular value ? Again it depends on the number of TE-LSPs rerouted, or
prefixes injected into TE-LSPs.

	IMHO, 45ms is a vendor specific value and not an ISP requirement. 
Same comment page 5 section 3.4. 

	That's all, 
Maybe several comments are irrelevant. 
Do not hesitate to contact me for clarifications. 

	Best Regards 

	JL 

-------------------------------------------------------------------------- 
Jean-Louis Le Roux 
IP backbones 
France Telecom R&D DAC/CPN 
av Pierre Marzin 
22300 Lannion 
tel: 00 33 2 96 05 30 20 
--------------------------------------------------------------------------

---

From: [email-masked]
Date: Tue, 18 Nov 2003 11:33:27 -0500

Scott
 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, September 24, 2003 1:33 PM
To: [email-masked]
Subject: Fw: Comments on draft-poretsky-mpls-meth-00.txt

----- Original Message ----- 

	Hi Scott, 

	-General comments: 

  

	-7 Reversion test: 

  

	Other minor comments: 

	-Section 1 page 2: 

	-Page 3: 

	That's all, 

	Best Regards 

	JL