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

From: "Eric Osborne (eosborne)" <[email-masked]>
Date: Tue, 23 Nov 2010 12:05:17 -0600

I'm trying to follow the thread and I would like to make sure I understand the issue.

It seems like Sasha's point is:

---
> > 1. I have, some time ago, raised a technical issue with the proposed
> > SPME concept, namely that the results of
> >    SPME monitoring are not necessarily correlated with the behavior of
> > traffic in the original monitored LSP.
---

and that the proposed solutions are:

#1:
---
> One possible resolution could be:
> - Use Option 2 I've proposed in my email to Italo (i.e., add the
> appropriate caveats for the SPME concept)
> - Define that the draft, once it becomes an RFC, updates 5921.
---

or

#2:
---
> Another option would be to initiate the process of updating 5921. But this
> would probably take much more time.
---

Is my understanding of the problem and the two proposed solutions correct?

eric

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Alexander Vainshtein
> Sent: Tuesday, November 23, 2010 11:43 AM
> To: Maarten Vissers
> Cc: [email-masked]
> Subject: Re: [mpls-tp] about open discussion about MIPMEP in MPLS-TP
> networks
> 
> Maarten,
> Yes, unfortunately 5921 has defined SPME as a hierarchical LSP.
> One possible resolution could be:
> - Use Option 2 I've proposed in my email to Italo (i.e., add the
> appropriate caveats for the SPME concept)
> - Define that the draft, once it becomes an RFC, updates 5921.
> 
> Another option would be to initiate the process of updating 5921. But this
> would probably take much more time.
> 
> Regards,
>      Sasha
> 
> -----Original Message-----
> From: Maarten Vissers [mailto:[email-masked]]
> Sent: Tuesday, November 23, 2010 5:06 PM
> To: Alexander Vainshtein; 'BUSI, ITALO (ITALO)'
> Cc: [email-masked]; [email-masked]
> Subject: RE: [mpls-tp] about open discussion about MIP MEP in MPLS-TP
> networks
> 
> Sasha,
> 
> The SPME has been defined in RFC5921.
> The problem has therefore to be resolved within the scope of RFC5921 in my
> opinion.
> 
> Regards,
> Maarten
> 
> > -----Original Message-----
> > From: Alexander Vainshtein [mailto:[email-masked]]
> > Sent: 23 November 2010 15:33
> > To: BUSI, ITALO (ITALO)
> > Cc: [email-masked]; Maarten Vissers; [email-masked]
> > Subject: RE: [mpls-tp] about open discussion about MIP MEP in MPLS-TP
> > networks
> >
> > Italo,
> > In this message I will only refer to the SPME issue (which I am
> > raising as the IETF LC comment on the MPLS-TP FW draft).
> > I have added Dave Allan (your co-editor) to the CC list.
> >
> > This is how I see the situation after reading your email:
> >
> > 1. I have, some time ago, raised a technical issue with the proposed
> > SPME concept, namely that the results of
> >    SPME monitoring are not necessarily correlated with the behavior of
> > traffic in the original monitored LSP.
> >    My original comment has been discussed on the MPLS-TP mailing list
> > for some time.
> > 2. In your email you agree that this issue is real, and even refer to
> > some individual drafts
> >    that have raised the same issue.
> > 3. Nevertheless, you, as the co-editor of the draft, retain the SPME
> > concept "as is" in the WG document now in the
> >    final round IESG discussions before approval for publication as an
> > RFC. And the current version
> >    of the draft, while discussing some specific aspects of SPME,
> > completely ignores a known issue with SPME.
> >
> > I do not think that it is reasonable to expect that the target
> > audience of the RFC-to-be has followed the discussion of the draft on
> > this mailing list, or read some individual submissions dealing with
> > one of the concepts introduced in the draft (and which are not even
> > referenced in the draft). Hence, IMHO and FWIW, if the draft were
> > approved for publication as an RFC "as is", it would be misleading its
> > target audience regarding actual usefulness of SPME.
> >
> > I see two possibilities for resolving the issue:
> >
> > 1. You can withdraw the current SPME concept from the draft. Whether
> > you replace it with another solution for the
> >    problem or not SPME is supposed to solve or not, is not so relevant
> > at the moment.
> > 2. You retain the current SPME concept but add clarifications and
> > caveats pertaining to the issue raised.
> >    By doing that you transfer the responsibility for using this
> > concept and dealing with the potentially
> >    useless results to the operators.
> >
> > Hopefully these notes clarify my position on the subject.
> >
> > Regards,
> >      Sasha
> >
> > -----Original Message-----
> > From: BUSI, ITALO (ITALO) [mailto:[email-masked]]
> > Sent: Monday, November 22, 2010 8:06 PM
> > To: Alexander Vainshtein; Maarten Vissers
> > Cc: [email-masked]
> > Subject: R: [mpls-tp] about open discussion about MIP MEP in MPLS-TP
> > networks
> >
> > Sasha,
> >
> > See my comments in line marked with [ib]
> >
> > Thanks, Italo
> >
> > > -----Messaggio originale-----
> > > Da: Alexander Vainshtein [mailto:[email-masked]]
> > > Inviato: lunedì 22 novembre 2010 14.41
> > > A: Maarten Vissers
> > > Cc: [email-masked]; BUSI, ITALO (ITALO)
> > > Oggetto: RE: [mpls-tp] about open discussion about MIP MEP in
> > > MPLS-TP networks
> > >
> > > Maarten,
> > >
> > > Please see some answers inline below.
> > > I will snip the fragments where we seem to be in agreement in hope
> > that
> > > this will improve readability.
> > >
> > > Regards,
> > >      Sasha
> > >
> > >
> > > -----Original Message-----
> > > From: Maarten Vissers [mailto:[email-masked]]
> > > Sent: Monday, November 22, 2010 12:50 PM
> > > To: Alexander Vainshtein; 'BUSI, ITALO (ITALO)'
> > > Cc: [email-masked]
> > > Subject: RE: [mpls-tp] about open discussion about MIP MEP in
> > > MPLS-TP networks
> > >
> > > Sasha,
> > >
> > > See inline...
> > >
> > > > -----Original Message-----
> > > > From: [email-masked] [mailto:[email-masked]]
> > > > On Behalf Of Alexander Vainshtein
> > > > Sent: 15 November 2010 08:03
> > > > To: BUSI, ITALO (ITALO)
> > > > Cc: [email-masked]
> > > > Subject: Re: [mpls-tp] about open discussion about MIP MEP in
> > > > MPLS-
> > TP
> > > > networks
> > > >
> > > > Italo,
> > > > Lots of thanks for a prompt response.
> > > >
> > > > I will look up my archives and resend the specific comment
> > regarding
> > > > SPME.
> > > > But the gist of this comment has been, that SPME is a new LSP, so
> > that
> > > > monitoring it does not necessarily say anything about the original
> > LSP
> > > > passing thru the segment in question. The simplest use case
> > > > demonstrating the difference is a case of incomplete
> > > > configuration, when the original LSP has not been configured in
> > > > one of the
> > internal
> > > > nodes of the segment, but SPME was (and vice versa).
> > > [[[Sasha]]] Looks like you've decided not to comment on this point.
> > > Does it mean that you agree with me that there is an issue with SPME?
> > > >
> >
> > [ib] I think there is not disagreement here: see section 3.8 of the
> > OAM Framework well as draft-koike-mpls-tp-temporal-hitless-psm and
> > draft- zhang-mpls-tp-path-segment-monitoring.
> >
> > > > Regarding MIPs, I'd like to explain my doubts.
> > > >
> > > > 1. We all agree (or so it seems) that intermediate points of LSPs
> > and
> > > > PWs can only be reached due to TTL expiration.
> > >
> > > [maarten] That is what MPLS experts tell me; so this is the
> > assumption for
> > > MPLS-TP.
> > > [[[Sasha]]] Great! So at least here we are on the same page.
> > >
> >
> > [ib] I think this is described in section 3.4 of the OAM Framework:
> >
> >    When sending an OAM packet to a MIP, the source MEP should set
> >    the TTL field to indicate the number of hops necessary to reach
> >    the node where the MIP resides.
> >
> >    The source MEP should also include Target MIP information in the
> >    OAM packets sent to a MIP to allow proper identification of the
> >    MIP within the node. The MEG the OAM packet is associated with
> >    is inferred from the MPLS label.
> >
> > [ib] I am less familiar with the MIP/MEP Map draft but when I read it
> > I understood it to be aligned with the OAM Framework.
> >
> > > > 2. By default TTL expiration extracts a packet from the data plane
> > and
> > > > sends it to the control plane instead.
> > >
> > > [maarten] see my previous email. Packet transport network equipment
> > > without control plane are required to support MIP functions as well.
> > > [[[Sasha]]] I've already explained that in a separate email.
> > >
> > > >     As per RFC 4379, this process includes preservation of the
> > original
> > > > received label stack
> > > >     and noting the actual ingress interface so that they are
> > available
> > > > for the CP processing.
> > >
> > > [maarten] in nodes with and without control plane these OAM packets
> > have
> > > to
> > > be processed as if the MIP is functionally located on the ingress
> > port.
> > > [[[Sasha]]] Please note that this is basic MPLS data plane
> > functionality
> > > that does not depend on configuration of MIPs. Or, if you prefer it
> > in a
> > > different way, a per-node MIP is by default enabled in any MPLS node.
> > >
> >
> > [ib] I think that neither the OAM Framework nor the MIP/MEP Map
> > precludes the implementation of per-node MIPs. However, they allow
> > also the implementation of per-interface MIPs.
> >
> > > [maarten] Per-node and per-interface are two **implementation
> > > alternatives** within
> > > equipment. The ITU-T functional models provide an unambiguous
> > requirement
> > > of
> > > the functional location of a half-MIP or MIP function in each
> > interface
> > > port. Both implementation alternatives must comply with the
> > > behaviour specified by the functional model.
> > > [[[Sasha]]] Do ITU-T functional models match ITU-T-standardized SDH
> > > equipment in this regard?
> > > If yes, could you please explain how a MIP half-function on an
> > > egress
> > SDH
> > > port is mapped to the ITU-T model of SDH?
> > > This explanation would be most helpful.
> > >
> > > > 3. Taking (1) and (2) above as given, could you please clarify,
> > what
> > > > exactly does it mean if:
> > > >     (a) A per-node MIP is disabled?
> > >
> > > [maarten] A per-node MIP is an implementation of two Down half-MIP
> > > functions, one located at NNI port A and the other located at NNI
> > port B.
> > > [[[Sasha]]] I disagree. A per-node MIP is not, IMHO, related to any
> > > specific port.
> > > If the model does not support this kind of MIP, the problem is with
> > the
> > > model IMO.
> > >
> > > [maarten] The PW/LSP is set up over ports A and B. Those Down half-
> > MIP
> > > functions are
> > > able to accept e.g. loopback requests that arrive via the physical
> > port,
> > > and
> > > are unable to accept such requests that arrive via the fabric.
> > > [[[Sasha]]] Is the Fabric a mandatory element in the ITU-T
> > > functional model?
> > > What is going to happen to Fabric-less implementations?
> > >
> > > [maarten] the 'Down half-MIP function' on a NNI port is disabled,
> > > and
> > OAM
> > > packets destined for this function will not be processed.
> > >
> >
> > [ib] According to section 3.4 of the OAM Framework, a per-node MIP is
> > located in an unspecified location within the node. What Maarten
> > describes is the way we can model such a MIP using the ITU-T
> > functional components.
> > In any case, the conclusion is the same: when a per-node MIP is
> > disabled, all OAM packets addressed to it are discarded.
> >
> > > >     (b) A per-interface MIP is disabled?
> > >
> > > [maarten] A per-interface MIP is an implementation of a MIP function
> > (i.e.
> > > two back-to-back half-MIP functions) on each NNI port. Those MIP
> > functions
> > > are able to accept e.g. loopback requests that arrive via the
> > physical
> > > port,
> > > and such requests that arrive via the fabric.
> > >
> > > [maarten] the 'MIP function' on a NNI port is disabled, and OAM
> > packets
> > > destined for this function will not be processed.
> > >
> >
> > [ib] Correct: when a per-node MIP is disabled, all OAM packets
> > addressed to it are discarded.
> >
> > > > 4. Are MIPs bound to specific Managed Entities (LSPs)?
> > >
> > > [maarten] MIPs and half-MIPs are bound to Managed Entities (PWs,
> > LSPs,
> > > Sections).
> > >
> > > > If they are, what should happen if:
> > > >     a) An LSP uses labels from the per-platform label stace, and
> > hence
> > > > packets associated with this LSP can be received from any
> > interface?
> > >
> > > [maarten] In MPLS-TP merging is not supported. As such per-platform
> > labels
> > > are 1-to-1 associated with a single NNI port. E.g. if Label 500 is
> > > associated with a PW or LSP on NNI port X, then reception of a
> > > packet
> > with
> > > label 500 on NNI port Y (X<>Y) must be discarded.
> > > [[[Sasha]]] To the best of my understanding this is not how the
> > labels
> > > from the per-platform label space are treated in IP/MPLS. And RFC
> > 5960
> > > which lists all specific deviations from the IP/MPLS data plane that
> > MPLS-
> > > TP introduces, does not list any such as well.
> > > What's more, PW labels MUST be allocated from the per-platform label
> > space
> > > (as per RFC 4447) and, AFAIK, are accepted on all MPLS-enabled
> > physical
> > > ports in most (if not all)implementations. And RFC 5690 explicitly
> > states
> > > that it does not specify any deviations for the PW data plane for
> > MPLS-TP.
> > >
> >
> > [ib] Please refer to Errata 2534. However, this is a MAY, so the
> > problem you raise can happen (I guess you are considering the case the
> > OAM packet is addressed to the per-interface MIP at the ingress side
> > because the one at the egress side can still be addressed).
> > In such a case, the per-interface MIP on the ingress side does not
> > receive the OAM packet and does not reply. The OAM packet is received
> > by the per-interface MIP on the egress side that drops it because it
> > is not addressed to it.
> >
> > > >     b) A per-interface MIP is enabled for this LSP on one
> > > > interface
> > and
> > > > disabled on another one?
> > >
> > > [maarten] Assume that LSP X with endpoint a (EPa) and z (EPz) is
> > > transported via NNI ports P and Q in a node. Assume that the
> > > per-interface MIP on
> > port
> > > P
> > > is enabled and on port Q is disabled. This implies that e.g. a LSP
> > > loopback OAM packet from EPa or EPz can be looped on NNI port P and
> > > can not be looped on NNI port Q.
> > >
> >
> > [ib] In a nutshell, the disabled per-interface MIP is dropping all the
> > oAM packets addressed to itself (and not replying to them)
> >
> > > Regards,
> > > Maarten
> > >
> > > >
> > > >
> > > > Regards,
> > > >      Sasha
> > > >
> > > > ________________________________________
> > > > From: BUSI, ITALO (ITALO) [[email-masked]]
> > > > Sent: Monday, November 15, 2010 12:54 AM
> > > > To: Alexander Vainshtein; [email-masked]
> > > > Cc: [email-masked]
> > > > Subject: R: [mpls-tp] about open discussion about MIP MEP in
> > MPLS-TP
> > > > networks
> > > >
> > > > Sasha,
> > > >
> > > > See in line marked with [ib]
> > > >
> > > > Thanks in advance
> > > >
> > > > Italo
> > > >
> > > > > -----Messaggio originale-----
> > > > > Da: [email-masked] [mailto:[email-masked]]
> > Per
> > > > conto
> > > > > di Alexander Vainshtein
> > > > > Inviato: venerdì 12 novembre 2010 11.37
> > > > > A: [email-masked]
> > > > > Cc: [email-masked]
> > > > > Oggetto: Re: [mpls-tp] about open discussion about MIP MEP in
> > MPLS-TP
> > > > > networks
> > > > >
> > > > > Adrian,
> > > > > I've looked up the MPLS-TP OAM framework draft and it indeed
> > > > discusses
> > > > > per-interface MIPs that have not been considered (according to
> > > > > my
> > > > reading)
> > > > > in RFC 5654.
> > > > >
> > > > > I think that, at the very least, the notion of a per-interface
> > MIP
> > > > > requires additional clarification. E.g., can you introduce a
> > > > > per-
> > > > interface
> > > > > MIP in an LSP that uses labels from the per-platform space?
> > > >
> > > > [ib] Could you be more specific about how the label space impacts
> > the
> > > > support of per-interface vs per-node MIP?
> > > >
> > > > > On a more generic level, taking into account that the only way
> > > > > to
> > > > reach a
> > > > > MIP in an LSP is to send a packet that would experience TTL
> > > > expiration in
> > > > > the node of interest, what is the difference in behavior of LSPs
> > with
> > > > > configured MIPs and LSPs without them?
> > > > >
> > > >
> > > > [ib] We discussed this point during the development of the OAM
> > > > framework and we have agreed that every node has MIP(s) and that
> > the
> > > > operator can disable them. See the following text extracts from
> > section
> > > > 3.4:
> > > >
> > > >    An intermediate node within a MEG can either:
> > > >
> > > >    o Support per-node MIP (i.e. a single MIP per node in an
> > > >       unspecified location within the node);
> > > >
> > > >    o Support per-interface MIP (i.e. two or more MIPs per node on
> > > >       both sides of the forwarding engine).
> > > >
> > > > And
> > > >
> > > >    Once a MEG is configured, the operator can enable/disable the
> > > >    MIPs on the nodes within the MEG. All the intermediate nodes and
> > > >    possibly the end nodes host MIP(s). Local policy allows them to
> > > >    be enabled per function and per MEG. The local policy is
> > > >    controlled by the management system, which may delegate it to
> > > >    the control plane.
> > > >
> > > > I hope this would help.
> > > >
> > > > > I also note that the framework draft still promotes hierarchy of
> > > > labels
> > > > > for SPMEs and/or TCM.
> > > > > I believe that I've commented on this concept earlier, and in
> > > > > any
> > > > case I
> > > > > plan to send an IESG LC comment on this point: IMO my previous
> > > > comments in
> > > > > this regard have not been resolved.
> > > > >
> > > >
> > > > [ib] Could you please re-send your comment? This would help
> > expediting
> > > > its resolution as I fear we have missed it. I apologize for that.
> > > >
> > > > > Regards,
> > > > >      Sasha
> > > > >
> > > > > ________________________________________
> > > > > From: [email-masked] [[email-masked]] On
> > Behalf
> > > > Of
> > > > > Adrian Farrel [[email-masked]]
> > > > > Sent: Thursday, November 11, 2010 6:28 PM
> > > > > To: 'D'Alessandro Alessandro Gerardo'
> > > > > Cc: [email-masked]
> > > > > Subject: Re: [mpls-tp] about open discussion about MIP MEP in
> > MPLS-TP
> > > > > networks
> > > > >
> > > > > Hi,
> > > > >
> > > > > >> I think the difference in the way we are presenting this lies
> > in
> > > > me
> > > > > saying
> > > > > >> that we have to have a model and tools that allow vendors to
> > build
> > > > > >> equipment that allows operators to deploy MPLS-TP networks
> > that
> > > > > >> follow the "legacy transport network" mode of operation.
> > > > > >
> > > > > > [Alessandro] It seems to me we are claiming the same thing
> > > > > >
> > > > > >> It seems to me that you are saying that the architecture must
> > > > prohibit
> > > > > >> people from building and deploying in other modes, and I
> > > > > >> can't
> > see
> > > > > >> the value of that prohibition.
> > > > > >
> > > > > > [Alessandro] No, I haven't said that. I said the architecture
> > must
> > > > > include
> > > > > > all the constructs that are required to get the above
> > > > > > mentioned
> > > > goal
> > > > > > (e.g. a per interface MIP).
> > > > >
> > > > > My apologies. It looks like we are perfectly aligned.
> > > > > In addition, I believe that the OAM Framework (section 3.4
> > already
> > > > > includes the
> > > > > function). So I think we are done.
> > > > >
> > > > > Adrian
> > > > >
> > > > > _______________________________________________
> > > > > mpls-tp mailing list
> > > > > [email-masked]
> > > > > https://www.ietf.org/mailman/listinfo/mpls-tp
> > > > > _______________________________________________
> > > > > mpls-tp mailing list
> > > > > [email-masked]
> > > > > https://www.ietf.org/mailman/listinfo/mpls-tp
> > > > _______________________________________________
> > > > mpls-tp mailing list
> > > > [email-masked]
> > > > https://www.ietf.org/mailman/listinfo/mpls-tp
> 
> 
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 23 Nov 2010 22:04:45 +0200

Eric,
Your understanding of the issue is correct.

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.

Regards,
     Sasha
________________________________________
From: Eric Osborne (eosborne) [[email-masked]]
Sent: Tuesday, November 23, 2010 8:05 PM
To: Alexander Vainshtein; Maarten Vissers
Cc: [email-masked]
Subject: RE: [mpls-tp] about open discussion about MIPMEP       in      MPLS-TP networks

---
---

#1:
---
---

or

#2:
---
---

eric

---

From: Dan Frost <[email-masked]>
Date: Wed, 24 Nov 2010 16:58:32 +0000

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.
> 

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.

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

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 24 Nov 2010 19:10:40 +0200

Dan,
Lots of thanks for the clarification.

I fully agree that the root cause of the conflict is the contradiction between the actual capabilities of the MPLS data plane and the restrictions imposed by the supposedly generic network model.

It would be definitely preferable to remove these restrictions and to adapt the model to the reality of the MPLS data plane along the lines you've mentioned; this is also what has been already proposed by many people (including Dave in the message to which you refer). 

I must admit that I do not understand why this proposal has not been adopted and incorporated in the revised draft. 

But I have accepted this as a "fact on the ground" and tried to provide what they call "a creative solution" to an obvious impasse. 

Regards,
     Sasha

-----Original Message-----
From: Dan Frost [mailto:[email-masked]] 
Sent: Wednesday, November 24, 2010 6:59 PM
To: Alexander Vainshtein
Cc: [email-masked]
Subject: Re: [mpls-tp] about open discussion about MIPMEP in MPLS-TP networks

-d

---

From: John E Drake <[email-masked]>
Date: Thu, 25 Nov 2010 09:18:30 -0800

Comment inline

Sent from my iPhone

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Dan Frost
> Sent: Wednesday, November 24, 2010 8:59 AM
> To: Alexander Vainshtein
> Cc: [email-masked]

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.