Subject: [mpls] Comments on draft-weingarten-mpls-smp-requirements-00.txt

From: Pablo Frank <[email-masked]>
Date: Tue, 17 Jul 2012 16:51:31 -0400

Good draft and certainly something that needs to be done before we can
start discussing specific solutions.

Only a few comments / questions:

- In 4.1.1, if one is operating in an MPLS-TP network that requires
exclusive use of the protection resources, doesn't this SHOULD requirement
become a MUST requirement?
- Nit: you might want to avoid using the "query" verb in the title of 4.1.1
because it subtly suggests some kind of protocol messaging is required.  I
would use the more generic verb "checking" or "verifying".
- In 4.3, there is no suggestion for what should happen if one or more
failing paths in an MPLS-TP network are of equal priority.  I presume it
will be some kind of first-come, first-serve requirement but this will
bring up the question of how to break ties.
- Also in 4.3, there is an allowance for a high priority path and a lower
priority path to temporarily share the protection resources while
preemption is taking place.  Two questions:

- Is the ingress node to the shared segment expected to discard excess
traffic now that the protection-path is temporarily oversubscribed?
- If not, how do we ensure that other transport paths are unaffected?

- The first paragraph of 4.4 appears to contradict 4.1.1.  4.4 seems to
suggest that one MUST switch the traffic onto the protection path first and
then get notified if there's not enough resources.  That's probably okay in
the general case.  But in an MPLS-TP network, I don't think it's a good
idea to blindly switch low priority traffic onto the protection path and
possibly disrupt a high priority path that is already using that resource.
- In section 4.5, there's an attempt to define "protection switching time"
as not including preemption time.  I don't think end-users really care
about "protection switching time".  They care about recovery time and IMO,
that should also include fault detection time (although it doesn't per RFC
5654) and any preemption time.

regards,
Pablo