Subject: [mpls-tp] A question on T-MPLS OAM based on ITU-T G.8114

From: Eli Stein <[email-masked]>
Date: Mon, 16 Mar 2009 18:39:00 +0200

Hello,

I am reading the G.8114 ITU document; however I fail to understand how it is
expected to handle MEG levels, especially in nested domains.

In section 5.6 of G.8114  it says: "In case MEGs are nested, the OAM packets
of each MEG have to be clearly identifiable and separable from the OAM
packets of the other MEGs. In case the OAM packets are not distinguishable
by the T-MPLS layer encapsulation itself, the MEG Level in the OAM packet
distinguishes between the OAM packets of nested MEGs. . . . . . .  In order
to distinguish OAM packets of nested MEGs, each MEP tunnels incoming OAM
packets by incrementing the MEL in the source direction and decrementing it
in the sink direction."

Why is such mechanism required and when should it be used? According to my
understanding OAM packets monitoring the blue (Pa1a) ME (see figure below
from G.8114 document), although pass through nested domains such as Ob2a,
will never be trapped by the MEPs in these domains but only by the blue Pa1a
MEPs.

Is the intention of the standard that the MEPs of the light blue (Oa1a &
Ob1b), orange (Oa2a) and red (Ob2a) will increment and decrement
respectively the MEG level is the OAM packets monitoring the blue (Pa1a)
domain?

If yes, what should be the trigger to trap the blue domain OAM packets by
the nested domain MEPs? The blue domain MEPs follow the path of the data
packets of the LSP they monitored and the LSRs in the way simply forward
those packets based on the external label and are not expose to the OAM
label (14)

Thanks a lot for your help.

Eli

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 16 Mar 2009 17:02:40 +0000

Eli

There is no ITU-T Recommendation G.8114.
This Recommendation was withdrawn before publication by ITU-T due to 
architectural inconsistency between T-MPLS and IETF-MPLS.

Regards

Stewart

Eli Stein wrote:
>
> Hello,
>
>  
>
> I am reading the G.8114 ITU document; however I fail to understand how 
> it is expected to handle MEG levels, especially in nested domains.
>
>
> In section 5.6 of G.8114  it says: "In case MEGs are nested, the OAM 
> packets of each MEG have to be clearly identifiable and separable from 
> the OAM packets of the other MEGs. In case the OAM packets are not 
> distinguishable by the T-MPLS layer encapsulation itself, the MEG 
> Level in the OAM packet distinguishes between the OAM packets of 
> nested MEGs. . . . . . .  In order to distinguish OAM packets of 
> nested MEGs, each MEP tunnels incoming OAM packets by incrementing the 
> MEL in the source direction and decrementing it in the sink direction."
>
>  
>
> Why is such mechanism required and when should it be used? According 
> to my understanding OAM packets monitoring the blue (Pa1a) ME (see 
> figure below from G.8114 document), although pass through nested 
> domains such as Ob2a, will never be trapped by the MEPs in these 
> domains but only by the blue Pa1a MEPs.
>
>  
>
> Is the intention of the standard that the MEPs of the light blue (Oa1a 
> & Ob1b), orange (Oa2a) and red (Ob2a) will increment and decrement 
> respectively the MEG level is the OAM packets monitoring the blue 
> (Pa1a) domain?
>
>  
>
> If yes, what should be the trigger to trap the blue domain OAM packets 
> by the nested domain MEPs? The blue domain MEPs follow the path of the 
> data packets of the LSP they monitored and the LSRs in the way simply 
> forward those packets based on the external label and are not expose 
> to the OAM label (14)
>
>  
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp
>