Subject: [bmwg] FW: Minor comments on draft-poretsky-mpls-protection-meth-01.txt

From: [email-masked]
Date: Tue, 18 Nov 2003 18:10:15 -0500

Forwarding message I received today.  Some comments are consistent with
Jean-Louis's comments.

Scott

-----Original Message-----
From: Jay Karthik [mailto:[email-masked]]
Sent: Tuesday, November 18, 2003 2:59 PM
To: [email-masked]
Subject: Minor comments on draft-poretsky-mpls-protection-meth-01.txt

Nice work !. Here are some comments.

Thanks,
Jay

.........................................
1. Introduction
<snipped>
The Standby LSP is an extension to RSVP-TE signaling in which a backup LSP 
is signaled in advance from primary Ingress to Egress
<snipped>

There is no extension to RSVP TE for standby tunnels. A Standby tunnel is 
a  pre-signalled backup LSPs from Ingress to Egress (preferably disjoint).

2. In section 3.4 LSP and Route Scaling L & R

3.
In section 5.1.2 PLR
5.1.2.1 Ingress PLR
Could have 5.1.2.1.1 Local SONET Failure  & 5.1.2.1.2 Local Administrative 
Shutdown
5.1.2.2 Midpoint PLR
Could have 5.1.2.2.1 Local SONET Failure  & 5.1.2.2.2 Local Administrative 
Shutdown

4. In section 5.1.1.3
If the LSP is fully protected, the mid point would failover to it's backup 
and thus cannot be listed as a test under 5.1.1 Ingress
So, you might want to state specifically that the midpoint node were the 
failure occurs does not have protection enabled.

5. Section 4. Test setup
A line could be added to say that 4.1 is also the test setup for standby 
tunnels.

6. List of possible administrative failures could be added
Admin group/color constraint, bandwidth constraint, SRLG, IGP metric, TE 
metric etc

7. Since this draft is not 'Benchmarking Methodology for MPLS Convergence', 
but 'Benchmarking Methodology for MPLS Protection Mechanisms', the 
following could be outlined.
Setup time for standby tunnel, Setup time for backup tunnels and the total 
time taken for the primary to be fully protected.

8. As, JL Le Roux mentioned, all reference to 45 ms should be removed.

9. Where link failure is mentioned, there could be 2 different types of 
failure. 1. Administrator disabling an interface (gracefully) and 2. abrupt 
failures like failed power or damaged fiber.

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

---

From: [email-masked]
Date: Tue, 18 Nov 2003 18:10:15 -0500

Scott

-----Original Message-----
From: Jay Karthik [mailto:[email-masked]]
Sent: Tuesday, November 18, 2003 2:59 PM
To: [email-masked]
Subject: Minor comments on draft-poretsky-mpls-protection-meth-01.txt

Thanks,
Jay

3.
In section 5.1.2 PLR
5.1.2.1 Ingress PLR

4. In section 5.1.1.3

5. Section 4. Test setup