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

From: "Eric Osborne (eosborne)" <[email-masked]>
Date: Tue, 23 Nov 2010 15:07:51 -0600

Hi Sasha-

  Thanks for the clarification.  As far as resolution, I'm of two minds.  I don't really quite understand the need to clarify the caveats at all.  If RFCs (indeed, if any technical documents) had to list all the things they *couldn't* do and that could go wrong if improperly understood, they'd be much longer than they are now.  And I live in America, the land of the unnecessary disclaimer. :)

  I'd have to see a pretty strong argument that this particular behavior needed a caveat before I would buy off that it even needed to exist. 

  On the other hand, if you absolutely must 'fix' whatever is 'wrong' with the current approach, #1 makes sense.  For #2 I'm not sure what you would even replace it with that would be more congruent to the data path without gutting most of MPLS packet forwarding.  We've also made extensive use of SPMEs as hierarchical tunnels for some of the protection work, and to remove that means we'd just have to reinvent it so we could continue to use it.

eric

> -----Original Message-----
> From: Alexander Vainshtein [mailto:[email-masked]]
> Sent: Tuesday, November 23, 2010 3:05 PM
> To: Eric Osborne (eosborne)
> Cc: [email-masked]; Maarten Vissers
> Subject: RE: [mpls-tp] about open discussion about MIPMEP in MPLS-TP
> networks
> 
> 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
> 
> 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: Maarten Vissers <[email-masked]>
Date: Wed, 24 Nov 2010 07:46:04 +0100

Eric,

Hierarchical tunnels for protection (carrying multiple client signals)
should not be impacted by a fix of the SPME construct. The SPME fix is
required for the case of pure sub path/tandem connection monitoring of a PW
or LSP connection, in which case there is a 1-to-1 relationship between the
PW/LSP and the additional monitoring entity. The fix must assure that the
original PW/LSP label values are maintained when the additional maintenance
entity level is activated or deactivated.

There are a couple of alternatives to fix this SPME issue:
1) introduce a well known MEG Level field in the MPLS-TP OAM packets and
extend NNI and UNI ports with the capability to read and interpret this MEG
Level field
2) introduce a SPME reserved label (e.g. Label_12) and add this label below
the PW/LSP label into either the PW/LSP OAM packets entering the SPME, or
all PW/LSP packets entering the SPME. Remove this label from the PW/LSP
(OAM) packets leaving the SPME.
3) extend the Label_13 usage and allow Label_13 to be combined with both S=1
(current case) and S=0 (additional case); add this Label_13/S=0 label below
the PW/LSP label of the PW/LSP OAM packets entering the SPME. Remove this
Label_13/S=0 label from the PW/LSP OAM packets leaving the SPME.

Regards,
Maarten

> From: Eric Osborne (eosborne) [mailto:[email-masked]]
> Sent: 23 November 2010 22:08
> To: Alexander Vainshtein
>   Thanks for the clarification.  As far as resolution, I'm of two
> minds.  I don't really quite understand the need to clarify the caveats
> at all.  If RFCs (indeed, if any technical documents) had to list all
> the things they *couldn't* do and that could go wrong if improperly
> understood, they'd be much longer than they are now.  And I live in
> America, the land of the unnecessary disclaimer. :)
> 
>   I'd have to see a pretty strong argument that this particular
> behavior needed a caveat before I would buy off that it even needed to
> exist.
> 
>   On the other hand, if you absolutely must 'fix' whatever is 'wrong'
> with the current approach, #1 makes sense.  For #2 I'm not sure what
> you would even replace it with that would be more congruent to the data
> path without gutting most of MPLS packet forwarding.  We've also made
> extensive use of SPMEs as hierarchical tunnels for some of the
> protection work, and to remove that means we'd just have to reinvent it
> so we could continue to use it.
> 
> 
> 
> 
> eric
> 
> 
> > > > From: Alexander Vainshtein
> [mailto:[email-masked]]
> > > > > Da: Alexander Vainshtein
> [mailto:[email-masked]]

---

From: "Eric Osborne (eosborne)" <[email-masked]>
Date: Wed, 24 Nov 2010 05:30:06 -0600

I'm sorry, I don't quite follow the problem statement.  If there's no hierarchy why not just run OAM or what-have-you directly over the LSP that carries your PW?  My take on SPME was that it was designed to let you monitor some fairly arbitrary subset of an e2e path (thus, Sub-Path).

eric

> Sent: Wednesday, November 24, 2010 1:46 AM
> To: Eric Osborne (eosborne); 'Alexander Vainshtein'
> Cc: [email-masked]
> required for the case of pure sub path/tandem connection monitoring of a
> PW or LSP connection, in which case there is a 1-to-1 relationship between
> the PW/LSP and the additional monitoring entity. The fix must assure that
> the original PW/LSP label values are maintained when the additional
> maintenance entity level is activated or deactivated.
> 
> extend NNI and UNI ports with the capability to read and interpret this
> MEG Level field
> 2) introduce a SPME reserved label (e.g. Label_12) and add this label
> below the PW/LSP label into either the PW/LSP OAM packets entering the
> SPME, or all PW/LSP packets entering the SPME. Remove this label from the
> PW/LSP
> 3) extend the Label_13 usage and allow Label_13 to be combined with both
> S=1 (current case) and S=0 (additional case); add this Label_13/S=0 label
> below the PW/LSP label of the PW/LSP OAM packets entering the SPME. Remove
> this
> > minds.  I don't really quite understand the need to clarify the
> > caveats at all.  If RFCs (indeed, if any technical documents) had to
> > list all the things they *couldn't* do and that could go wrong if
> > improperly understood, they'd be much longer than they are now.  And I
> > live in America, the land of the unnecessary disclaimer. :)
> >
> > you would even replace it with that would be more congruent to the
> > data path without gutting most of MPLS packet forwarding.  We've also
> > made extensive use of SPMEs as hierarchical tunnels for some of the
> > protection work, and to remove that means we'd just have to reinvent
> > it so we could continue to use it.
> >
> >
> >
> >
> > eric
> >
> >
> > > 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
> > > > > 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.
> > > > >
> > > > > 2. You retain the current SPME concept but add clarifications
> > > > > and caveats pertaining to the issue raised.
> > > > > > [[[Sasha]]] Do ITU-T functional models match
> > > > > > ITU-T-standardized SDH equipment in this regard?
> > > > > > [maarten] A per-node MIP is an implementation of two Down
> > > > > > half-
> > MIP
> > > > > > [[[Sasha]]] I disagree. A per-node MIP is not, IMHO, related
> > > > > > to any specific port.
> > > > > > are 1-to-1 associated with a single NNI port. E.g. if Label
> > > > > > 500
> > is
> > > > > > which lists all specific deviations from the IP/MPLS data
> > > > > > plane that
> > > > > MPLS-
> > > > > > loopback OAM packet from EPa or EPz can be looped on NNI port
> > > > > > P and can not be looped on NNI port Q.
> > > > > >
> > > > >
> > > > > > > > per-interface MIPs that have not been considered
> > > > > > > > (according
> > to
> > > > > > > > my
> > > > > > > reading)
> > > > > > > > in RFC 5654.
> > > > > > > >
> > > > > > > > the node of interest, what is the difference in behavior
> > > > > > > > of LSPs
> > > > > with
> > > > > > >    controlled by the management system, which may delegate
> > > > > > > it
> > to
> > > > > > >    the control plane.
> > > > > > >
> > > > > > > I hope this would help.
> > > > > > >
> > > > > > > > >> I think the difference in the way we are presenting
> > > > > > > > >> this lies
> > > > > in
> > > > > > > me
> > > > > > > > saying
> > > > > > > > >> 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

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 24 Nov 2010 13:53:38 +0100

Eric,

There are a couple of architectural different entities supported by means of
stacking labels:

1) connection hierarchy: multiple client LSP/PW/VPLS signals are transported
over a server LSP connection, which latter was set up under control of
network planning to provide for a virtual link between PE nodes

2) OAM maintenance entity hierarchy: multiple OAM maintenance entity levels
may exist within a LSP or PW connection. One end-to-end LSP or PW
maintenance entity level will exist by default when the LSP or PW connection
is created, other sub-path maintenance entity levels between arbitrary
points along the connection may be created during LSP or PW connection set
up, or after set up. In all cases the creation of such sub-path maintenance
entities should not change the LSP or PW connection configuration.

3) when a group of LSP or PW signals is to be protected in the network, it
is an option to protect each LSP or PW signal independently, or to protect
the group of LSP or PW signals by means of multiplexing those signals into a
group protection dedicated server LSP signal. The latter approach has
scalability advantages.

All three entities are today supported by label stacking. Label stacking is
the correct method for items 1 and 3. 

For item 2 label stacking is not the right method, at least with the current
specification in which a new label is added at the top of the stack. This
approach changes the PW/LSP connection configuration in the network, which
is not allowed. 

What is required is the behaviour present in e.g. OTN ODU connections and
Ethernet VLAN connections. In those two cases, it is possible to activate
additional OAM insertion/extraction at points along the connection without
touching the configuration of the connection in the matrices passed by the
connection.

For MPLS-TP this would imply that it should be possible to set up a PW or
LSP connection with OAM insertion/extraction at the endpoints only, and then
be able to just activate additional OAM insertion/extraction functions
(MEPs) at arbitrary points along the connection. The value of labels in the
label stack should not be changed.

To realize this required behaviour, it is necessary that the sub-path MEP
functions on MPLS-TP NNI ports can read some of the bits below the top
label, and when there is a match with an expected value can extract the
packet for further OAM processing.

Regards,
Maarten

> Sent: 24 November 2010 12:30
> To: Maarten Vissers; Alexander Vainshtein
> Cc: [email-masked]
> I'm sorry, I don't quite follow the problem statement.  If there's no
> hierarchy why not just run OAM or what-have-you directly over the LSP
> that carries your PW?  My take on SPME was that it was designed to let
> you monitor some fairly arbitrary subset of an e2e path (thus, Sub-
> Path).
> 
> 
> 
> 
> 
> eric
> 
> 
> > > > -  # 1 is IMHO a valid and relatively cheap (for IETF)
> resolution:
> > > the
> > > > for consideration of potential "users". If they still agree to
> use
> > > this
> > > > - #2 is much more complicated for the IETF, since it would mean
> at
> > > least
> > > > > Another option would be to initiate the process of updating
> 5921.
> > > But
> > > > > Subject: Re: [mpls-tp] about open discussion about MIPMEP in
> MPLS-
> > > TP
> > > > > networks
> > > > >
> > > > > Maarten,
> > > > > Another option would be to initiate the process of updating
> 5921.
> > > But
> > > > > > 3. Nevertheless, you, as the co-editor of the draft, retain
> the
> > > SPME
> > > > > >    final round IESG discussions before approval for
> publication
> > > as
> > > > > > > I will snip the fragments where we seem to be in agreement
> in
> > > hope
> > > > > > that
> > > > > > > > Subject: Re: [mpls-tp] about open discussion about MIP
> MEP
> > > > > > > > in
> > > > > > > > MPLS-
> > > > > > TP
> > > > > > > > networks
> > > > > > > >
> > > > > > > > Italo,
> > > > > > > > configuration, when the original LSP has not been
> configured
> > > in
> > > > > > > > one of the
> > > > > > internal
> > > > > > > [[[Sasha]]] Looks like you've decided not to comment on
> this
> > > point.
> > > > > > [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
> > > > > >    The source MEP should also include Target MIP information
> in
> > > the
> > > > > >    OAM packets sent to a MIP to allow proper identification
> of
> > > the
> > > > > > > >     As per RFC 4379, this process includes preservation
> of
> > > the
> > > > > > original
> > > > > > > > received label stack
> > > > > > > functions, one located at NNI port A and the other located
> at
> > > NNI
> > > > > > port B.
> > > > > > [ib] According to section 3.4 of the OAM Framework, a per-
> node
> > > MIP
> > > > > > > two back-to-back half-MIP functions) on each NNI port.
> Those
> > > MIP
> > > > > > functions
> > > > > > > >     a) An LSP uses labels from the per-platform label
> stace,
> > > and
> > > > > > hence
> > > > > > > from the per-platform label space are treated in IP/MPLS.
> And
> > > RFC
> > > > > > 5960
> > > > > > > that it does not specify any deviations for the PW data
> plane
> > > for
> > > > > > MPLS-TP.
> > > > > > >
> > > > > >
> > > > > > In such a case, the per-interface MIP on the ingress side
> does
> > > not
> > > > > > received by the per-interface MIP on the egress side that
> drops
> > > it
> > > > > > > [maarten] Assume that LSP X with endpoint a (EPa) and z
> (EPz)
> > > is
> > > > > > > is enabled and on port Q is disabled. This implies that
> e.g. a
> > > LSP
> > > > > > [ib] In a nutshell, the disabled per-interface MIP is
> dropping
> > > all
> > > > > > > > > Oggetto: Re: [mpls-tp] about open discussion about MIP
> MEP
> > > in
> > > > > > MPLS-TP
> > > > > > > > > networks
> > > > > > > > >
> > > > > > > > > Adrian,
> > > > > > > > > requires additional clarification. E.g., can you
> introduce
> > > a
> > > > > > > > > per-
> > > > > > > > interface
> > > > > > > > > On a more generic level, taking into account that the
> only
> > > way
> > > > > > > > > to
> > > > > > > > reach a
> > > > > > > > [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:
> > > > > > > >
> > > > > > > >    Once a MEG is configured, the operator can
> enable/disable
> > > the
> > > > > > > >    possibly the end nodes host MIP(s). Local policy
> allows
> > > them to
> > > > > > > > > I believe that I've commented on this concept earlier,
> and
> > > in
> > > > > > > > > any
> > > > > > > > case I
> > > > > > > > its resolution as I fear we have missed it. I apologize
> for
> > > that.
> > > > > > > >
> > > > > > > > > Regards,
> > > > > > > > >      Sasha
> > > > > > > > >
> > > > > > > > > From: [email-masked] [mpls-tp-
> [email-masked]]
> > > On
> > > > > > Behalf
> > > > > > > > Of
> > > > > > > > > Subject: Re: [mpls-tp] about open discussion about MIP
> MEP
> > > in
> > > > > > MPLS-TP
> > > > > > > > > networks
> > > > > > > > >
> > > > > > > > > Hi,
> > > > > > > > >

---

From: "Eric Osborne (eosborne)" <[email-masked]>
Date: Wed, 24 Nov 2010 08:43:04 -0600

Email trimmed a bit...

...

> 2) OAM maintenance entity hierarchy: multiple OAM maintenance entity
> levels may exist within a LSP or PW connection. One end-to-end LSP or PW
> maintenance entity level will exist by default when the LSP or PW
> connection is created, other sub-path maintenance entity levels between
> arbitrary points along the connection may be created during LSP or PW
> connection set up, or after set up. In all cases the creation of such sub-
> path maintenance entities should not change the LSP or PW connection
> configuration.
> 

...

> 
> For item 2 label stacking is not the right method, at least with the
> current specification in which a new label is added at the top of the
> stack. This approach changes the PW/LSP connection configuration in the
> network, which is not allowed.

I think I understand the desire to not add hierarchy simply to provide OAM, but whether this really changes anything in device behavior or traffic treatment will probably always be something up for debate.  

> LSP connection with OAM insertion/extraction at the endpoints only, and
> then be able to just activate additional OAM insertion/extraction
> functions
> (MEPs) at arbitrary points along the connection. The value of labels in
> the label stack should not be changed.
> 

Is this what Sasha meant by "an alternative solution" in his email to me earlier?  I'm not clear how you would build something like this (that is, a label underneath the top one which indicates OAM) without changing something in the label stack from the client payload.  

I accept that this will address what you view as a problem.  If I understand your proposal correctly it is of course a complete non-starter, as it's not how MPLS works.  This seems like one of those dead-horse issues, so I'm going to be polite to the horse and just let it lie.  Insofar as caveating this, I stand by my initial email on this thread - describing what a particular technology doesn't do and how it might go wrong seems like a poor use of a standard.

eric

> > > 2) introduce a SPME reserved label (e.g. Label_12) and add this
> > > label below the PW/LSP label into either the PW/LSP OAM packets
> > > entering
> > the
> > > SPME, or all PW/LSP packets entering the SPME. Remove this label
> > > from
> > the
> > > PW/LSP
> > > > behavior needed a caveat before I would buy off that it even
> > > > needed
> > to
> > > > exist.
> > > >
> > > > made extensive use of SPMEs as hierarchical tunnels for some of
> > > > the protection work, and to remove that means we'd just have to
> > reinvent
> > > > > Is my understanding of the problem and the two proposed
> > > > > solutions
> > > > correct?
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > eric
> > > > >
> > > > >
> > > > >
> > > > > > > Subject: RE: [mpls-tp] about open discussion about MIP MEP
> > > > > > > in MPLS-TP networks
> > > > > > >
> > > > > > > Italo,
> > > > > > > dealing with one of the concepts introduced in the draft
> > > > > > > (and which are
> > > > not
> > > > > > > be misleading its target audience regarding actual
> > > > > > > usefulness
> > of
> > > > SPME.
> > > > > > >
> > > > > > >    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.
> > > > > > > > > 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
> > > > > > > > > 1. We all agree (or so it seems) that intermediate
> > > > > > > > > points
> > of
> > > > > > > > > LSPs
> > > > > > > and
> > > > > > >    When sending an OAM packet to a MIP, the source MEP
> > > > > > > should
> > set
> > > > > > > [ib] I am less familiar with the MIP/MEP Map draft but when
> > > > > > > I
> > > > read
> > > > > > > > [maarten] in nodes with and without control plane these
> > > > > > > > OAM packets
> > > > > > > have
> > > > > > > > to
> > > > > > > > port. Both implementation alternatives must comply with
> > > > > > > > the behaviour specified by the functional model.
> > > > > > > > If yes, could you please explain how a MIP half-function
> > > > > > > > on
> > an
> > > > > > > > egress
> > > > > > > SDH
> > > > > > > > If the model does not support this kind of MIP, the
> > > > > > > > problem
> > is
> > > > > > > > with
> > > > > > > the
> > > > > > > > model IMO.
> > > > > > > >
> > > > > > > > [maarten] A per-interface MIP is an implementation of a
> > > > > > > > MIP function
> > > > > > > (i.e.
> > > > > > > problem you raise can happen (I guess you are considering
> > > > > > > the
> > > > case
> > > > > > > > >     b) A per-interface MIP is enabled for this LSP on
> > > > > > > > > one interface
> > > > > > > and
> > > > > > > > > disabled on another one?
> > > > > > > >
> > > > > > > > > Subject: R: [mpls-tp] about open discussion about MIP
> > > > > > > > > MEP
> > in
> > > > > > > MPLS-TP
> > > > > > > > > networks
> > > > > > > > >
> > > > > > > > > Sasha,
> > > > > > > > >
> > > > > > > > > [ib] Could you be more specific about how the label
> > > > > > > > > space impacts
> > > > > > > the
> > > > > > > > >    o Support per-interface MIP (i.e. two or more MIPs
> > > > > > > > > per
> > > > node on
> > > > > > > > >    MIPs on the nodes within the MEG. All the
> > > > > > > > > intermediate
> > > > nodes
> > > > > and
> > > > > > > > > > > all the constructs that are required to get the
> > > > > > > > > > > above mentioned
> > > > > > > > > goal

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 24 Nov 2010 16:09:21 +0100

Eric,

You write:
" If I understand your proposal correctly it is of course a complete
non-starter, as it's not how MPLS works."

I am aware of MPLS ports that are able to look below the top label. One of
the applications that requires this is ECMP, another application is T-MPLS
OAM. Both are existing, non-standard applications supported by many
equipment. As such, reuse of the capability to read a number of bits/bytes
below the top label (for a to be standardized sub-path monitoring usage)
would not require much effort, and would smartly reuse capabilities
originally build into the MPLS port devices for those non-standard
applications.

The MEG level field solution does not require the addition of a label in the
packet. As such there is no change in the packets at all when sub-path
maintenance entity OAM is inserted or extracted. Note that this solution is
used in Ethernet successfully, and is supported in MPLS PEs in (H)VPLS
connections.

Regards,
Maarten

> Sent: 24 November 2010 15:43
> I think I understand the desire to not add hierarchy simply to provide
> OAM, but whether this really changes anything in device behavior or
> traffic treatment will probably always be something up for debate.
> 
> >
> Is this what Sasha meant by "an alternative solution" in his email to
> me earlier?  I'm not clear how you would build something like this
> (that is, a label underneath the top one which indicates OAM) without
> changing something in the label stack from the client payload.
> 
> I accept that this will address what you view as a problem.  If I
> understand your proposal correctly it is of course a complete non-
> starter, as it's not how MPLS works.  This seems like one of those
> dead-horse issues, so I'm going to be polite to the horse and just let
> it lie.  Insofar as caveating this, I stand by my initial email on this
> thread - describing what a particular technology doesn't do and how it
> might go wrong seems like a poor use of a standard.
> 
> 
> 
> 
> eric
> 
> 
> > Maarten
> >
> > > > should not be impacted by a fix of the SPME construct. The SPME
> fix
> > > is
> > > > required for the case of pure sub path/tandem connection
> monitoring
> > > of a
> > > > PW or LSP connection, in which case there is a 1-to-1
> relationship
> > > between
> > > > the PW/LSP and the additional monitoring entity. The fix must
> assure
> > > that
> > > > 1) introduce a well known MEG Level field in the MPLS-TP OAM
> packets
> > > and
> > > > extend NNI and UNI ports with the capability to read and
> interpret
> > > this
> > > > MEG Level field
> > > > 3) extend the Label_13 usage and allow Label_13 to be combined
> with
> > > both
> > > > S=1 (current case) and S=0 (additional case); add this
> Label_13/S=0
> > > label
> > > > below the PW/LSP label of the PW/LSP OAM packets entering the
> SPME.
> > > Remove
> > > > this

---

From: "Eric Osborne (eosborne)" <[email-masked]>
Date: Wed, 24 Nov 2010 09:23:32 -0600

> Sent: Wednesday, November 24, 2010 10:09 AM
non-
> starter, as it's not how MPLS works."
> 
> OAM.

Ah, OK...one semantic point...there's a big difference between "look
below the top label" and "look below the label stack".  The former is
something you could do with context labels, the latter is what you
describe.

eric

> Both are existing, non-standard applications supported by many
> The MEG level field solution does not require the addition of a label
in
> the packet. As such there is no change in the packets at all when
sub-path
> maintenance entity OAM is inserted or extracted. Note that this
solution
> is used in Ethernet successfully, and is supported in MPLS PEs in
(H)VPLS
> > > levels may exist within a LSP or PW connection. One end-to-end LSP
> > > or
> > PW
> > > arbitrary points along the connection may be created during LSP or
> > > PW connection set up, or after set up. In all cases the creation
of
> > > such
> > sub-
> > > current specification in which a new label is added at the top of
> > > the stack. This approach changes the PW/LSP connection
configuration
> > > What is required is the behaviour present in e.g. OTN ODU
> > > connections
> > and
> > > touching the configuration of the connection in the matrices
passed
> > by the
> > > connection.
> > >
> > > For MPLS-TP this would imply that it should be possible to set up
a
> > PW or
> > > LSP connection with OAM insertion/extraction at the endpoints
only,
> > > (MEPs) at arbitrary points along the connection. The value of
labels
> > > To realize this required behaviour, it is necessary that the
> > > sub-path
> > MEP
> > > label, and when there is a match with an expected value can
extract
> > it lie.  Insofar as caveating this, I stand by my initial email on
> > this thread - describing what a particular technology doesn't do and
> > how it might go wrong seems like a poor use of a standard.
> >
> >
> >
> >
> > eric
> >
> >
> > > Maarten
> > >
MPLS-
> > TP
> > > > networks
> > > >
> > > > I'm sorry, I don't quite follow the problem statement.  If
there's
> > no
> > > > hierarchy why not just run OAM or what-have-you directly over
the
> > LSP
> > > > that carries your PW?  My take on SPME was that it was designed
to
> > let
> > > > you monitor some fairly arbitrary subset of an e2e path (thus,
> > > > Sub- Path).
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > eric
> > > >
> > > >