Subject: [mpls-tp] comments on draft-asm-mpls-tp-bfd-cc-cv

From: D'Alessandro Alessandro Gerardo <[email-masked]>
Date: Thu, 20 May 2010 10:17:05 +0200

Some comments and questions for clarification about draft-asm-mpls-tp-bfd-cc-cv-04:

par. 1 says "procedure for uni-directional paths are for further study". Uni-directional path configuration should be got from that one used for bidirectional path without any further effort. Was uni-directional BFD procedure left for further study because it cannot be derived from BFD proposal for bidirectional path in a simple way?
According to draft-ietf-bfd-base-11 "BFD can provide failure detection on any kind of path between systems, including  ... unidirectional links (so long as there is some return path, of course.)". Should I expect a further mode of operation besides the two ones already defined?

Par 3.5 says that "BFD operate in asynchronous mode" and "fate sharing operation is as described in draft-ietf-bfd-base-11". Is echo function supported?

Par 3.5 says that "..an operator has a reason to change session parameters, poll/final discipline is used". Could you clarify what are the parameters you are referring to?

It seems to me that there are some contradictions in the draft about the BFD packet rate:
-         BFD packet rate is declared to be fixed in par 3.5 whatever the operation mode is: "this rate is typically a fixed value for the lifetime of the session. In the rare circumstance where an operator has a reason to change session parameters....."
-         For independent operation mode, BFD packet rate is declared to be fixed in par 3.5 "independent operation is characterized by the setting of MinRxInterval to zero"
-         For independent operation mode, BFD packet rate is declared to be variable in par 3.5  "...a zero interval source send BFD control messages with a one second period until such time that the state change is confirmed by the session peer. At this point the zero interval source can resume quiescent behaviour"
-         For independent operation mode, BFD packet rate is declared to be variable in par 3.5 "...the zero interval peer will continue to send DOWN state messages ..."
-         For fate sharing operation mode, BFD packet rate is described in draft-ietf-bfd-base-11 where it can be found "When bfd.SessionState is not Up, the system MUST set bfd.DesiredMinTxInterval to a value of not less than one second"

The draft proposes "two modes of operations for bidirectional paths" in par. 3.5. What are the transport network scenarios requiring to differentiate between the two modes?

The draft proposes a "normal usage" for the two modes of operations that is:
1:1 protected path must use fate sharing
1+1 protected paths make use of independent operation
Are you saying that the draft foresees different implementations for the same functionalities (Continuity Checks and Connectivity Verifications) depending on the protection architecture types (e.g. 1+1/1:1)?

Do the two BFD mode of operations described in the draft cover other protection architecture types (e.g. 1:n; (1:1)^n; ring based) or other modes of operations have to be added?

When Independent operation mode is used, do I have to establish two (bi-directional) BFD sessions for a bi-directional path (e.g. a bi-directional session for each direction)?

When fate sharing operation mode is used on a bidirectional A-Z path and a unidirectional A->Z fail occurs, which is the BFD session state on A end? Which is the BFD packet rate from Z->A?

Editorial:

 1.  par. 1: PST terminology still used
 2.  Par 3.3 uses  "Unique MEP-ID"  whilst par 3.5 uses " globally Unique MEP-ID"
 3.  some terminology appears ambiguous (to me) and it could be useful to clarify:
    *   "base spec" -> are you referring to draft-ietf-bfd-base-11
    *   "Zero interval source"
    *   "Zero interval peer"
    *   "session originator" ->Active role?
    *   Par 3.4 BFD session ends -> does it mean disabled or deleted?
    *   Par 3.5.2 receiving from an incorrect source (determined by whatever means)
    *   Par 3.5.2receiving from a correct source (as near as can be determined)
    *   Receiving control packets in all discernable ways correct

Thanks in advance.
Best regards,
Alessandro
------------------------------------------------------------------
Telecom Italia
Alessandro D'Alessandro
Transport & OPB Innovation
Via Reiss Romoli, 274 - 10148 Torino
phone:  +39 011 228 5887
mobile: +39 335 766 9607
fax: +39 06 418 639 07

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

Rispetta l'ambiente. Non stampare questa mail se non ? necessario.

---

From: John E Drake <[email-masked]>
Date: Thu, 20 May 2010 10:27:05 -0700

Hi,

I have a few comments inline.

Thanks,

John

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of D'Alessandro Alessandro Gerardo
> Sent: Thursday, May 20, 2010 1:17 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [mpls-tp] comments on draft-asm-mpls-tp-bfd-cc-cv
> 
> par. 1 says "procedure for uni-directional paths are for further study".
> Uni-directional path configuration should be got from that one used for
> bidirectional path without any further effort. Was uni-directional BFD
> procedure left for further study because it cannot be derived from BFD
> proposal for bidirectional path in a simple way?

JD:  As has been discussed, we consider unidirectional p2p LSPs to be a special case of p2mp LSPs and we are waiting for the p2mp BFD spec to be re-issued.  It is also not clear whether p2mp CC/CV/RDI will be described in this I-D or another.

> 
> According to draft-ietf-bfd-base-11 "BFD can provide failure detection on
> any kind of path between systems, including  . unidirectional links (so
> long as there is some return path, of course.)". Should I expect a further
> mode of operation besides the two ones already defined?

JD:  A unidirectional link, in the sense used in the quote, is not the same thing as a unidirectional LSP.

> 
> 
> 
> Par 3.5 says that "BFD operate in asynchronous mode" and "fate sharing
> operation is as described in draft-ietf-bfd-base-11". Is echo function
> supported?
> 
> 
> 
> Par 3.5 says that "..an operator has a reason to change session
> parameters, poll/final discipline is used". Could you clarify what are the
> parameters you are referring to?
> 
> 
> 
> -         BFD packet rate is declared to be fixed in par 3.5 whatever the
> operation mode is: "this rate is typically a fixed value for the lifetime
> of the session. In the rare circumstance where an operator has a reason to
> change session parameters..."
> 
> -         For independent operation mode, BFD packet rate is declared to
> be fixed in par 3.5 "independent operation is characterized by the setting
> of MinRxInterval to zero"
> 
> -         For independent operation mode, BFD packet rate is declared to
> be variable in par 3.5  ".a zero interval source send BFD control messages
> with a one second period until such time that the state change is
> confirmed by the session peer. At this point the zero interval source can
> resume quiescent behaviour"
> 
> -         For independent operation mode, BFD packet rate is declared to
> be variable in par 3.5 ".the zero interval peer will continue to send DOWN
> state messages ."
> 
> -         For fate sharing operation mode, BFD packet rate is described in
> draft-ietf-bfd-base-11 where it can be found "When bfd.SessionState is not
> Up, the system MUST set bfd.DesiredMinTxInterval to a value of not less
> than one second"

JD:  I think you are confusing messages which convey state changes with the messages sent in steady state.  In this mode of operation, once the sink for a given BFD session reaches Up state, it stops sending anything until it stops receiving messages from the source, at which time it starts sending an error indication to the source.

> 
> 
> 
> The draft proposes "two modes of operations for bidirectional paths" in
> par. 3.5. What are the transport network scenarios requiring to
> differentiate between the two modes?

JD:  We were told that independent mode was required for both LSPs that are being used to provide a 1 + 1 service.

> Are you saying that the draft foresees different implementations for the
> same functionalities (Continuity Checks and Connectivity Verifications)
> depending on the protection architecture types (e.g. 1+1/1:1)?

JD:  See above.  We were told that 1 + 1 and 1 : 1 services operated in a fundamentally different fashion

> 
> 
> 
> Do the two BFD mode of operations described in the draft cover other
> protection architecture types (e.g. 1:n; (1:1)^n; ring based) or other
> modes of operations have to be added?

JD:  Fate sharing would be used for 1 : N

> 
> 
> 
> When Independent operation mode is used, do I have to establish two (bi-
> directional) BFD sessions for a bi-directional path (e.g. a bi-directional
> session for each direction)?

JD:  As described above, you effectively have two unidirectional sessions.

> 
> 
> 
> When fate sharing operation mode is used on a bidirectional A-Z path and a
> unidirectional A->Z fail occurs, which is the BFD session state on A end?
> Which is the BFD packet rate from Z->A?

JD:  Normal BFD - the LSP is down at both ends.

> Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle
> persone indicate. La diffusione, copia o qualsiasi altra azione derivante
> dalla conoscenza di queste informazioni sono rigorosamente vietate.
> Qualora abbiate ricevuto questo documento per errore siete cortesemente
> pregati di darne immediata comunicazione al mittente e di provvedere alla
> sua distruzione, Grazie.
> 
> This e-mail and any attachments is confidential and may contain privileged
> information intended for the addressee(s) only. Dissemination, copying,
> printing or use by anybody else is unauthorised. If you are not the
> intended recipient, please delete this message and any attachments and
> advise the sender by return e-mail, Thanks.
> 
> rispetta l'ambienteRispetta l'ambiente. Non stampare questa mail se non è
> necessario.