Subject: Re: [mpls-tp] about open discussion about MIPMEP in MPLS-TP networks

From: venkatesan mahalingam <[email-masked]>
Date: Fri, 26 Nov 2010 00:37:52 +0530

Maarten,
Thanks for your detailed explanation.
>> A sub-Path LSP MEP Sink function reads bits 32-51, 55 and
72-74....................
........................................
>> A sub-Path PW MEP Sink function reads bits 32-35 and 40-42 of a
labelled.........
...........................

<<VM>> I don't think, we can always assume constant label stak i.e LSP (LSP
label, GAL) and PW (PW label) exist in all the MPLS packets.
If we have multiple labels then parsing until BOS to see the ACH with MEL is
very difficult and it
results into switching performance impact in the intermediate nodes.

JD:  If you define the SPME endpoints to be MEPs, then the restriction can
be finessed.  If one wants to monitor an individual LSP, these MEPs can add
a GAL to that LSP's label stack and transmit packets to each other using TTL
expiry.

<<VM>> Yes, correct, but  we need a scalable (multiple clients and servers)
SPME solution.

From: John E Drake <jdrake at juniper.net>
To: Dan Frost <danfrost at cisco.com>, Alexander Vainshtein
<Alexander.Vainshtein at ecitele.com>
Cc: "mpls-tp at ietf.org" <mpls-tp at ietf.org>
Date: Thu, 25 Nov 2010 09:18:30 -0800
In-reply-to: <20101124165832.GB17168 at cisco.com>
References: <D29E470202D67745B61059870F433B54039A711D at
XMB-RCD-202.cisco.com> <A3C5DF08D38B6049839A6F553B331C76D6B6FD6532 at
ILPTMAIL02.ecitele.com> <20101124165832.GB17168 at cisco.com>

--------------------------------------------------------------------------------

Comment inline

Sent from my iPhone

> -----Original Message-----
> From: mpls-tp-bounces at ietf.org [mailto:mpls-tp-bounces at ietf.org] On
> Behalf Of Dan Frost
> Sent: Wednesday, November 24, 2010 8:59 AM
> To: Alexander Vainshtein
> Cc: mpls-tp at ietf.org
> Subject: Re: [mpls-tp] about open discussion about MIPMEP in MPLS-TP
> networks
>
> On Tue, Nov 23, 2010 at 10:04:45PM +0200, Alexander Vainshtein wrote:
> > [...]
> > As for its resolution:
> > - #1 is IMHO a valid and relatively cheap (for IETF) resolution: the
> > caveats associated with the SPME construct would be explicitly
> > presented for consideration of potential "users". If they still agree
> > to use this construct, this would be a case of "informed consent".
> >
> > - #2 is much more complicated for the IETF, since it would mean at
> > least retraction of the SPME construct as defined in RFC 5921 and
> > appropriate correction of the MPLS-TP OAM FW draft. If an alternative
> > solution is required, this would add to complexity of the task, but,
> > hopefully, the operators would be presented with a valid solution.
> >
> > Hopefully this clarifies my position.
>
> Since it seems we're sentenced to run through the same circles every
> three months or so with different subject headings, it will save time
> to
> refer to Dave Allan's message
>
> http://www.ietf.org/mail-archive/web/mpls-tp/current/msg04422.html
>
> and the related messages in the thread.
>
> The key technical issue for segment monitoring is whether intermediate
> nodes are "allowed" by the architecture to initiate OAM operations.
> This however is purely a modeling issue, as the MPLS data plane already
> supports this behaviour.  The sane thing to do in this situation is to
> remove the artificial restriction from the model.  The earlier
> discussions show broad consensus on this among protocol designers, and
> service providers have been saying that it really is important because
> of the alternative options for segment monitoring it enables.

JD:  If you define the SPME endpoints to be MEPs, then the restriction can
be finessed.  If one wants to monitor an individual LSP, these MEPs can add
a GAL to that LSP's label stack and transmit packets to each other using TTL
expiry.

>
> Given this, it's not clear to me why the restriction is still present
> in
> the OAM framework.  If the consensus reading is correct, the
> restriction
> should either be removed from the document, or an update drafted
> accordingly.
>
> Regarding SPME monitoring, it seems entirely reasonable to make its
> properties as clear as possible, and if the above restriction is
> lifted,
> to contrast the two approaches in the documentation for the benefit of
> operators and protocol designers.  The OAM framework, or its update, is
> the right place to do this.
>
> -d
>
> > Regards, Sasha
> _______________________________________________
> mpls-tp mailing list
> mpls-tp at ietf.org
> https://www.ietf.org/mailman/listinfo/mpls-tp

-- 
Best Regards,
Venkatesan Mahalingam.

---

From: Maarten Vissers <[email-masked]>
Date: Fri, 26 Nov 2010 07:37:30 +0100

Venkat,

The MEPs in a MPLS-TP transport path layer are not allowed to look at the
OAM of its client layer signals (i.e. at the OAM of the MPLS-TP transport
service layer signals). This implies that a transport-LSP MEP is not allowed
to look at the OAM of the service-LSP, PW and VPLS signals that are carried
by the transport-LSP. As such it is not allowed for a MEP Sink function to
parse the label stack until BOS and look for OAM of its client signals.

When service-LSP, PW and VPLS signals are multiplexed into a transport-LSP,
each user and OAM packet in those signals will get a label stack entry
header added to it. The presence of those service-LSP and PW label stack
entry headers will make the OAM of those transport service layer signals
invisible for the transport-LSP. The service-LSP, PW and VPLS OAM packets
have as such become user packets in the transport-LSP. The transport-LSP MEP
Source functions can now add the transport-LSP OAM, and the transport-LSP
MEP sink functions can detect this by inspecting the mentioned bits.

Regards,

Maarten 

From: [email-masked] [mailto:[email-masked]] On Behalf
Of venkatesan mahalingam
Sent: 25 November 2010 20:08
To: [email-masked]
Subject: Re: [mpls-tp] about open discussion about MIPMEP in MPLS-TP
networks

Maarten,
labelled.........

----------------------------------------------------------------------------
----

Comment inline

Sent from my iPhone

 

-- 
Best Regards,
Venkatesan Mahalingam.