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

[Alexander Vainshtein <[e-mail]>]

Italo,
My original comment on SPME has been sent to the list on 07-Jul-10.
You can see it at http://www.ietf.org/mail-archive/web/mpls-tp/current/msg04369.html .
It has not been posted as an LC comment, presumably because the draft has not been in any kind of LC at that moment.

Adrian, 
Please consider this comment as an IESG LC comment.

Regards,
     Sasha


-----Original Message-----
From: Alexander Vainshtein 
Sent: Monday, November 15, 2010 9:03 AM
To: BUSI, ITALO (ITALO)
Cc: [e-mail]; [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).

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. 
2. By default TTL expiration extracts a packet from the data plane and sends it to the control plane instead.
    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.
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? 
    (b) A per-interface MIP is disabled?
4. Are MIPs bound to specific Managed Entities (LSPs)? 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?
    b) A per-interface MIP is enabled for this LSP on one interface and disabled on another one?


Regards,
     Sasha

________________________________________
From: BUSI, ITALO (ITALO) [[e-mail]]
Sent: Monday, November 15, 2010 12:54 AM
To: Alexander Vainshtein; [e-mail]
Cc: [e-mail]
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: [e-mail] [mailto:[e-mail]] Per conto
> di Alexander Vainshtein
> Inviato: venerdì 12 novembre 2010 11.37
> A: [e-mail]
> Cc: [e-mail]
> 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: [e-mail] [[e-mail]] On Behalf Of
> Adrian Farrel [[e-mail]]
> Sent: Thursday, November 11, 2010 6:28 PM
> To: 'D'Alessandro Alessandro Gerardo'
> Cc: [e-mail]
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls-tp
> _______________________________________________
> mpls-tp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls-tp