Re: [mpls-tp] about open discussion about MIP MEP in MPLS-TP networks

[Alexander Vainshtein <[e-mail]>]

Italo,
I've re-read Section 3.8 of the draft (and also Section 3.6 to which it points). 

IMHO the text of Section 3.8 can be interpreted as a caveat against using temporal SPMEs - if the reader is looking for such a caveat with a magnifying glass. Otherwise the chances that the reader gets the message are slim.

I would suggest the following change for your consideration:

OLD

3.8. Further considerations of enhanced segment monitoring

   Segment monitoring in transport network should meet the
   following network objectives:
   1. The monitoring and maintenance of existing transport paths has to
      be conducted in service without traffic disruption.
   2. The monitored or managed transport path condition has to be
      exactly the same irrespective of any configurations necessary for
      maintenance.
   SPMEs defined in section 3.2 meet the above two objectives, when
   they are pre-configured or pre-instantiated as exemplified in
   section 3.6. However, pre-design and pre-configuration of all
   the considered patterns of SPME are not sometimes preferable in
   real operation due to the burden of design works, a number of
   header consumptions, bandwidth consumption and so on.
   When SPMEs are configured or instantiated after the transport
   path has been created, network objective (1) can be met, but
   network objective (2) cannot be met due to new assignment of
   MPLS labels.
 
NEW

3.8. Further considerations of enhanced segment monitoring

   Functionality of segment monitoring using SPMEs as defined in Section 3.2 above 
   is affected by the relationship between the lifespan of SPME and that of the transport
   entity whose segment is monitored using SPME.

   If the lifespan of SPME contains that of the transport entity (or entities) whose segment is monitored
   by this SPME (or, in other words, the monitored entity always uses an SPME in order to cross the
   monitored segment), then the results of SPME monitoring reflect behavior of traffic passing thru
   the monitored entity. However, if the monitored entity uses SPME only for part of its lifespan, 
   then, generally speaking, the results of SPME monitoring are not necessarily correlated
   with the behavior of traffic in the monitored entity when it does not use SPME. 

   E.g., application of SPME to a problematic/faulty monitoring entity is apt to "fix" the problem
   encountered by the latter - for as long as SPME is applied. And vice versa, application of
   SPME to a faultless monitored entity may result in in making it faulty - again, as long
   as SPME is applied. These effects stem from the fact that application and removal of SPME
   result in using a different set of cross-connects between incoming and outgoing LSP labels when
   compared to the original state of the monitored entity.

   At the same time application and removal of SPME to a faultless monitored transport entity
   can be performed in such a way as not to introduce any loss of traffic, e.g., by using "make
   before break" technique.

END

Hopefully this proposal would be acceptable to you.

My 2c,
     Sasha

________________________________________
From: Alexander Vainshtein
Sent: Friday, November 26, 2010 5:12 PM
To: BUSI, ITALO (ITALO)
Cc: [e-mail]; Maarten Vissers; [e-mail]
Subject: RE: [mpls-tp] about open discussion about MIP MEP      in      MPLS-TP networks

Italo,
I will re-read Section 3.8 to check if it addresses the issue.
regards,
Sasha________________________________________
From: BUSI, ITALO (ITALO) [[e-mail]]
Sent: Friday, November 26, 2010 3:08 PM
To: Alexander Vainshtein
Cc: [e-mail]; Maarten Vissers; [e-mail]
Subject: R: [mpls-tp] about open discussion about MIP MEP       in      MPLS-TP networks

Sasha,

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

Actually section 3.8 was added to "add clarifications and caveats pertaining to the issue raised" so I think we have already adopted the solution 2. you proposed above.

The individual drafts I referred to (together with a reference to section 3.8) are discussing detailed requirements and solutions to resolve this problem.

Italo

> -----Messaggio originale-----
> Da: Alexander Vainshtein [mailto:[e-mail]]
> Inviato: martedì 23 novembre 2010 15.33
> A: BUSI, ITALO (ITALO)
> Cc: [e-mail]; Maarten Vissers; [e-mail]
> Oggetto: 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:[e-mail]]
> Sent: Monday, November 22, 2010 8:06 PM
> To: Alexander Vainshtein; Maarten Vissers
> Cc: [e-mail]
> 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:[e-mail]]
> > Inviato: lunedì 22 novembre 2010 14.41
> > A: Maarten Vissers
> > Cc: [e-mail]; 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:[e-mail]]
> > Sent: Monday, November 22, 2010 12:50 PM
> > To: Alexander Vainshtein; 'BUSI, ITALO (ITALO)'
> > Cc: [e-mail]
> > Subject: RE: [mpls-tp] about open discussion about MIP MEP in MPLS-TP
> > networks
> >
> > Sasha,
> >
> > See inline...
> >
> > > -----Original Message-----
> > > From: [e-mail] [mailto:[e-mail]] On
> > > Behalf Of Alexander Vainshtein
> > > Sent: 15 November 2010 08:03
> > > To: BUSI, ITALO (ITALO)
> > > Cc: [e-mail]
> > > 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