Subject: [mpls-tp] Query w.r.t draft-asm-mpls-tp-bfd-cc-cv-04 and MEG ID TP identifier

From: Mukund Mani <[email-masked]>
Date: Wed, 19 May 2010 00:42:22 +0530

Hello TP-Group

Few queries w.r.t "draft-asm-mpls-tp-bfd-cc-cv-04" and a generic question on
MEG_ID TP identifier. Could the relevant draft authors please clarify the
same..

Section 3.5 of "draft-asm-mpls-tp-bfd-cc-cv-04" mentions "Two independent
BFD sessions are used for independent operation."

-----> Are we talking about Associated bidirectional LSP's in this case..?

Also the Section goes on to mention:

Independent operation is characterized by the setting of MinRxInterval to
zero by the MEP that is typically the session originator, and there will be
a session originator at either end of the bi-directional path.
The base spec is unclear on aspects of how a session with a BFD source set
to zero interval behaves. One interpretation is that no
periodic messages originate with that source, it will only originate
messages on a state change.

-----> Does the "source" here refers to the Source MEP of the forward and
reverse LSP's wherein MinRxInterval is set to 0 or does it refer to its
respective zero Tx interval peer?

   The first clarification is that when a state change occurs 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
   behavior. This adds robustness to all state transitions in the
   RxInterval=0 case.

   The second is that the originating MEP (the one with a non-zero
   TxInterval) will ignore a DOWN state received from a zero interval
   peer. This means that the zero interval peer will continue to send
   DOWN state messages as the state change is never confirmed. This adds
   robustness to the exchange of RDI indication on a uni-directional
   failure (for both session types DOWN with a diagnostic of control
   detection period expired offering RDI functionality).

---> Could this be clarified further with respect to the working of the
state machine..?

Also aside from this draft, a generic question w.r.t TP identifiers
"draft-ietf-mpls-tp-identifiers".
Are there any specific cases wherein MEG ID is carried in any of the OAM
packets?

With Regards
Mukund

---

From: David Allan I <[email-masked]>
Date: Tue, 18 May 2010 16:46:04 -0400

Hi Mukund:

 You wrote...

Few queries w.r.t "draft-asm-mpls-tp-bfd-cc-cv-04" and a generic question on MEG_ID TP identifier. Could the relevant draft authors please clarify the same..

Section 3.5 of "draft-asm-mpls-tp-bfd-cc-cv-04" mentions "Two independent BFD sessions are used for independent operation."

We're more focused on supporting the protection models rather than the routing aspects. 1+1 requires independent operation of each direction. That is independent of whether it is co-routed or associated.

Independent operation is characterized by the setting of MinRxInterval to zero by the MEP that is typically the session originator, and there will be a session originator at either end of the bi-directional path.
The base spec is unclear on aspects of how a session with a BFD source set to zero interval behaves. One interpretation is that no
periodic messages originate with that source, it will only originate messages on a state change.

-----> Does the "source" here refers to the Source MEP of the forward and reverse LSP's wherein MinRxInterval is set to 0 or does it refer to its respective zero Tx interval peer?

Wording could be slightly better. Source refers to the source of the return direction. The one that recevied MinRxInterval=0.

---> Could this be clarified further with respect to the working of the state machine..?

We originally had the state diagrams in a "draft of the draft" and chose to eliminate them. :-( If it really helps, they can be put back...

The first point I'm pretty sure does not really involve any changes to the state diagrams in BFD base, simply a clarification on the behavior to get to state change..

The second point involved a change to the source MEP state transition diagram. The following is the source MEP (the one who signalled MinRXInterval = 0), because it did so, receiving a DOWN state from the sink does not move it from the UP state..(change highlighted in red below).

                                 +--+

                                 |  | UP, ADMIN DOWN, Defects,

                                 |  V

                     INIT      +------+

                  +------------|      |

                  |            | DOWN |

                  |  +-------->|      |<-------+

                  |  |         +------+        |

                  |  |                         |

                  |  |              ADMIN DOWN,|

                  |  |ADMIN DOWN,              |

                  |  |DOWN                     |

                  V  |                         |

                +------+                      +------+

                |      |                      |      |----+

                | INIT |--------------------->|  UP  |    | DOWN

                |      | INIT, UP             |      |<---+

                +------+                      +------+

Also aside from this draft, a generic question w.r.t TP identifiers "draft-ietf-mpls-tp-identifiers".
Are there any specific cases wherein MEG ID is carried in any of the OAM packets?

I'll leave answering that to the Identifiers draft authors...

I hope this helps
cheers
D