Subject: [mpls-tp] MEP Ids in context of BFD-CV

From: Apratim Mukherjee <[email-masked]>
Date: Wed, 25 Aug 2010 10:09:03 -0700

Hi

I will try to frame the query from RSVP-TE point of view since that is how we appear to
have come to the choice of LSP MEP-ID constituents. I will also make an assumption that both nodes
belong to same operator hence having no need of unique global-ids.

 Node1(N1)                                                                                          Node2 ( N2)
                                               T1-LSP1 Working (N1->N2)
 Ingress T1 (MEP1) -------------------------------------------> Egress T1(MEP2)
                                                       T1-LSP2 Protect (N1->N2)
                    (MEP3)  -------------------------------------------> (MEP4)

                                                       T2-LSP1 Working (N2 -> N1)
 Egress T2  (MEP1)<-------------------------------------------  Ingress T2(MEP2)
                                                       T2-LSP2 Protect (N2 -> N1)
                    (MEP3)<-------------------------------------------  (MEP4)

 T1-LSP1 and T1-LSP2 was signalled from N1 and contained Tunnel ID = T1 and LSP ID = L1 , L2 for working and protect lsps.
 Each of these contained a TBD TLV which required association with a reverse direction Tunnel to form a bi-directional working and
 protect lsp from MPLS-TP context.
 Hence , T2-LSP1 and T2-LSP2 was signalled from N2 and contains Tunnel ID = T2 and LSP ID = L3,L4 and the associations ( L3 --> L1 and
 L2 --> L4 ) was propagated via a new TBD TLV contained in the respective RSVP messages ( Resvs for T1 and Paths for T2)

 Does this mean that for fate-sharing operation:
 1) Does MEP1 and MEP2 constitute one LSP MEG ( for working ) and MEP3 and MEP4 constitute a separate LSP MEG ( for protect ) ?
 1) BFD-CV message going in direction N1->N2 should contain Source MEP Id (GlobalId::)N1::T1::L1 for working lsp CV function
 2) BFD-CV message going in direction N2->N1 should contain Source MEP Id (GlobalId::)N2::T2::L1 and NOT ..::L3 for working lsp CV function
 3) Similarly , BFD-CV for protect lsp in N1->N2 would contain Src MEP N1::T1::L3 and N2->N1 would contain N2::T2::L3 ( and not L4) ?

 What is the operation in terms of independent mode :
 1) Are there are still two LSP MEGs ( one for working and another for the protect lsp ) or do we need four MEGs ( one for each direction of working and protect )?

Regards,
Apratim

The devil is in the details.

---

From: Mukund Mani <[email-masked]>
Date: Thu, 26 Aug 2010 02:57:06 +0530

*Hi Apratim

Considering your query, IMO,

MEP1 and MEP2 constitute a MEG and MEP3 and MEP4 would constitue a separate
MEG.

Also,

BFD CV message from N1 to N2 will contain the source MEP N1::T1:L1.

BFD CV message from N2 to N1 will contain the source MEP N2::T2::L1.

 To me it still seems to be a point of concern, when I consider the
definitions given below in the OAM framework:

>>>>>"In case of associated bi-directional point-to-point transport paths,
two independent unidirectional

Maintenance Entities are defined to independently monitor each direction."

 "In case of co-routed bi-directional point-to-point transport paths, a
single bidirectional Maintenance Entity is

defined to monitor both directions congruently. "

 "The collection of one or more MEs that belongs to the same transport path
and that are maintained and

monitored as a group are known as a maintenance entity group (MEG) and the
two points that define a

maintenance entity are called Maintenance Entity Group (MEG) End Points
(MEPs). "<<<<<<<

 that its possible to do independent and coordinated monitoring for both
associated or corouted LSP.

IMO doing the same might be possible but for clarity the definitions
provided in the OAM framework

should be revisited. From the definitions I could make that the valid cases
where doing independent monitoring

for associated bidirectional LSPs and coordinated monitoring for corouted
LSPs.

If I interpret that way then independent monitoring when applied to
"associated bidirectional LSP" would have four MEGs

as you mentioned one for each direction.

 With Regards

Mukund

  *
**
**
**
**
*From*: Apratim Mukherjee <AMukherjee at ixiacom.com<[email-masked]>>

*To*: "mpls-tp at ietf.org <[email-masked]>" <mpls-tp at
ietf.org<[email-masked]>>

*Date*: Wed, 25 Aug 2010 10:09:03 -0700
------------------------------

Hi

I will try to frame the query from RSVP-TE point of view since that is how
we appear to

have come to the choice of LSP MEP-ID constituents. I will also make an
assumption that both nodes

 Node1(N1)
  Node2 ( N2)

                                               T1-LSP1 Working (N1->N2)

 Ingress T1 (MEP1) -------------------------------------------> Egress
T1(MEP2)

                                                       T1-LSP2 Protect
(N1->N2)

                    (MEP3)  ------------------------------------------->
(MEP4)

                                                       T2-LSP1 Working (N2
-> N1)

 Egress T2  (MEP1)<-------------------------------------------  Ingress
T2(MEP2)

                                                       T2-LSP2 Protect (N2
-> N1)

                    (MEP3)<-------------------------------------------
(MEP4)

 T1-LSP1 and T1-LSP2 was signalled from N1 and contained Tunnel ID = T1 and
LSP ID = L1 , L2 for working and protect lsps.

 Each of these contained a TBD TLV which required association with a reverse
direction Tunnel to form a bi-directional working and

 Hence , T2-LSP1 and T2-LSP2 was signalled from N2 and contains Tunnel ID =
T2 and LSP ID = L3,L4 and the associations ( L3 --> L1 and

 L2 --> L4 ) was propagated via a new TBD TLV contained in the respective
RSVP messages ( Resvs for T1 and Paths for T2)

 1) Does MEP1 and MEP2 constitute one LSP MEG ( for working ) and MEP3 and
MEP4 constitute a separate LSP MEG ( for protect ) ?

 1) BFD-CV message going in direction N1->N2 should contain Source MEP Id
(GlobalId::)N1::T1::L1 for working lsp CV function

 2) BFD-CV message going in direction N2->N1 should contain Source MEP Id
(GlobalId::)N2::T2::L1 and NOT ..::L3 for working lsp CV function

 3) Similarly , BFD-CV for protect lsp in N1->N2 would contain Src MEP
N1::T1::L3 and N2->N1 would contain N2::T2::L3 ( and not L4) ?

 1) Are there are still two LSP MEGs ( one for working and another for the
protect lsp ) or do we need four MEGs ( one for each direction of working
and protect )?

Regards,

Apratim