Subject: [mpls-tp] Questions on draft-ietf-mpls-tp-linear-protection-01

From: Zhi-Wei Lin <[email-masked]>
Date: Tue, 23 Mar 2010 10:22:16 -0400

Hi,

I have some more questions below (sorry, as I read, I am sending out):

   - 4.2: PT field is only 2 bits, and all used up. This means that when
   defining the 1:n types, it would be a different format? (see below, I think
   this should be removed from message)
   - 4.2: there is mention of a hold-off timer in case of server layer
   action. Is this a management configured value, or should protocol exchange
   this to ensure the hold-off is consistent? This is similar to PT where it's
   likely management configured, but you are sending to validate consistency?
   (see below, I think this can be handled as separate message...but definitely
   useful to exchange)
   - 4.2: the document states it is applicable to both p2p and p2mp. Should
   there be some indication in the format to say whether it is p2p or p2mp, or
   this is not necessary?
   - 4.3.2 & 4.3.4: is there a diff between SF and SD? In SONET/SDH, I
   believe there is an order/level of protection switching actions depending on
   whether SF or SD is declared. e.g., if working is SF state and protect is
   SD, you might still switch traffic to protect path even though it may be in
   "unavailable state" in your document. Is this possible?
   - 4.3.6.1: is WTR timer something sent via protocol, again like PT, to
   verify consistent configuration? After WTR expires, I assume the No Request
   would be sent out? What is sent during the WTR period (whatever was sent
   during the protection period)?
   - General: it seems that once failure is declared, traffic is immediately
   switched (without waiting for confirmation), a message is sent to notify of
   this switch. There is no acknowledgement message coming back. Is this
   correct? If yes, if in the future you want to support extra traffic (RFC5654
   does say this is not a requirement), would this pose a problem with
   misconnection?
   - General: in the p2mp case (let's say 4 drops), if a failure occurs on a
   path to the 3rd drop node (therefore SF is declared for link between 2nd and
   3rd nodes), does the entire path get switched to protection? If yes, then
   some of the drop nodes on the "good" side may now be blocked by the failure
   (i.e., 1st and 2nd drop nodes). Is this a valid scenario, or I'm totally
   off-base? In which case, where in document describes this kind of behavior?
   - General: once a protection domain is defined it will be fixed; instead
   of including this type of fixed info in the protection message, should a
   "housekeeping" or "hello" message be sent that verifies the PT, WTR timers,
   and any other fixed configured parameters when the domain is set up? This
   way, the mechanism is "self-checking" to ensure no operator errors were made
   in configuring inconsistent information on nodes within the protection
   domain. This type of message would likely only need to be sent during the
   initial protection domain setup, and every so often (once every couple
   minutes or less) since these configured parameters should not change (unless
   operator chooses to change manually). It doesn't seem to be needed to be
   sent by a protection switch message?

Thanks
Zhi