Re: [mpls-tp] R: Intermediate nodes and segment monitoring in draft-ietf-mpls-tp-oam-framework-09

[Alexander Vainshtein <[e-mail]>]

Italo,
Please see a couple of comments inline below.
Regards,
__Sasha______________________________________
From: [e-mail] [[e-mail]] On Behalf Of BUSI, ITALO (ITALO) [[e-mail]]
Sent: Friday, November 26, 2010 3:50 PM
To: Dan Frost
Cc: [e-mail]
Subject: [mpls-tp] R: Intermediate nodes and segment monitoring in draft-ietf-mpls-tp-oam-framework-09

Dan,

I think that the proposed changes are quite substantial and require a lot of further investigation so I do not feel comfortable to just apply them without further investigating all the associated issues.

**Sasha** Yes. They break the NEP/MIP model because it does not fit MPLS data plane reality.
 In particular we need to consider that:

1) Regardless of the mechanisms, MEPs and MIPs are functionally different: MEPs are active component while MIPs are passive components.

The fact that the OAM packet delivery is achieved via TTL-expiry does not change the nature of MEP-MEP and MEP-MIP communications from a functional perspective.

**Sasha** Delivery to MEPs does not require TTL expiration.


2) The TTL-expiry mechanism is not a very reliable one: TTL distance between two nodes can change during the lifetime of a transport path.

**Sasha** Well, this IS the ONLY mechanism MPLS provides, see 5960. 
So - take it or break it!

This issue has major impacts especially with pro-active OAM tools.

As a consequence my proposal is:

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

These caveats have been already added in version -09 of the draft. Please check section 3.8 and let me know if you have any concern with the current text.

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

This work has already started, please see the following individual drafts:
- http://tools.ietf.org/html/draft-koike-mpls-tp-temporal-hitless-psm-01
- http://tools.ietf.org/html/draft-zhang-mpls-tp-path-segment-monitoring-01

During IETF 79, I had some offline conversations with the authors of these drafts and I think the requirements need to be further detailed.

Based on this discussion, it is my understanding that the SPME would work well-enough for inter-domain segment monitoring. The only issue that needs to be addressed is related only to the temporal segment monitoring.

I would therefore propose to move forward the OAM framework draft in its current form (with the caveats in section 3.8) and, in parallel, to progress the work on temporal PSM within the MPLS WG.

**Sasha** A permanent SPME means that there is NO original LSP in the segment. soI wonder if this czn be conxidered an OAM tool. 

Italo

> -----Messaggio originale-----
> Da: [e-mail] [mailto:[e-mail]] Per conto
> di Dan Frost
> Inviato: mercoledì 24 novembre 2010 21.05
> A: [e-mail]
> Oggetto: [mpls-tp] Intermediate nodes and segment monitoring in draft-
> ietf-mpls-tp-oam-framework-09
>
> Resending to note that this is intended as a (late) LC comment on the
> OAM framework.  It would be useful to hear brief yea/nays from the WG as
> to whether lifting the restriction on intermediate nodes is desirable.
>
> -d
>
> ----- Forwarded message -----
>
> Date: Wed, 24 Nov 2010 16:58:32 +0000
> From: Dan Frost <[e-mail]>
> To: Alexander Vainshtein <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [mpls-tp] about open discussion about MIPMEP in MPLS-TP
> networks
>
> On Tue, Nov 23, 2010 at 10:04:45PM +0200, Alexander Vainshtein wrote:
> > [...]
> > As for its resolution:
> > - #1 is IMHO a valid and relatively cheap (for IETF) resolution: the
> > caveats associated with the SPME construct would be explicitly
> > presented for consideration of potential "users". If they still agree
> > to use this construct, this would be a case of "informed consent".
> >
> > - #2 is much more complicated for the IETF, since it would mean at
> > least retraction of the SPME construct as defined in RFC 5921 and
> > appropriate correction of the MPLS-TP OAM FW draft. If an alternative
> > solution is required, this would add to complexity of the task, but,
> > hopefully, the operators would be presented with a valid solution.
> >
> > Hopefully this clarifies my position.
>
> Since it seems we're sentenced to run through the same circles every
> three months or so with different subject headings, it will save time to
> refer to Dave Allan's message
>
> http://www.ietf.org/mail-archive/web/mpls-tp/current/msg04422.html
>
> and the related messages in the thread.
>
> The key technical issue for segment monitoring is whether intermediate
> nodes are "allowed" by the architecture to initiate OAM operations.
> This however is purely a modeling issue, as the MPLS data plane already
> supports this behaviour.  The sane thing to do in this situation is to
> remove the artificial restriction from the model.  The earlier
> discussions show broad consensus on this among protocol designers, and
> service providers have been saying that it really is important because
> of the alternative options for segment monitoring it enables.
>
> Given this, it's not clear to me why the restriction is still present in
> the OAM framework.  If the consensus reading is correct, the restriction
> should either be removed from the document, or an update drafted
> accordingly.
>
> Regarding SPME monitoring, it seems entirely reasonable to make its
> properties as clear as possible, and if the above restriction is lifted,
> to contrast the two approaches in the documentation for the benefit of
> operators and protocol designers.  The OAM framework, or its update, is
> the right place to do this.
>
> -d
>
> > Regards, Sasha
> _______________________________________________
> mpls-tp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls-tp
>
> ----- End forwarded message -----
> _______________________________________________
> 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