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

[Maarten Vissers <[e-mail]>]

John, Fei,

The MEPs may be located outside the recovery domain, and will be unaware of the change of the number of hops in their transport path. 

There is of course a workaround to get around this issue... I.e set up a SPME between ingress and egress ports of a recovery domain. You do this by means of two Up MEPs on those NNI ports, if those are supported in MPLS-TP... With such SPME either path through the recovery domain will count as one hop... But this will add further complexity, just because you don't want to use the currently supported non-standard reading capabilities of those NNI ports.

Regards,
Maarten

Op 28 nov. 2010 om 04:04 heeft [e-mail] het volgende geschreven:

> 
> John: 
> 
> I agree with you, but TTL scheme will face scaling issues if it is used for nested path segment monitoring, as I addressed in draft-zhang-mpls-tp-path-segment-monitoring-01. 
> 
> Fortunately, it would not happen if it is only used for on-demand monitoring. 
> 
> So MBB is used for proactive and TTL used for the on-demand monitoring? This would utilize the advantages of these two schemes. 
> 
> Italo, Dan: 
> 
> If TTL is used, two options are applicalbe: 
> 
> (1)lifting the restriction on intermediate nodes, as Dan said. 
> 
> (2)Increasing the MEP definition for path segment, a little revision to the document [tp-identifier]. 
> 
> Just my two cents. 
> 
> Fei :)
> 
> 
> 
> John E Drake <[e-mail]> 
> 发件人:  [e-mail]
> 2010-11-27 00:54
> 
> 收件人
> Maarten Vissers <[e-mail]>, "'BUSI, ITALO (ITALO)'" <[e-mail]>, 'Dan Frost' <[e-mail]>
> 抄送
> "[e-mail]" <[e-mail]>
> 主题
> Re: [mpls-tp] R: Intermediate nodes and segment monitoring in draft-ietf-mpls-tp-oam-framework-09
> 
> 
> 
> 
> 
> Maarten,
> 
> I probably shouldn't tell you how to do this, but a sensible implementation would probably allow the configuration of the TTL for both the working and protecting LSPs, and when a protection switch occurs, such an implementation would switch to the TTL of the protecting LSP.
> 
> Thanks,
> 
> John
> 
> Sent from my iPhone
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On
> > Behalf Of Maarten Vissers
> > Sent: Friday, November 26, 2010 7:01 AM
> > To: 'BUSI, ITALO (ITALO)'; 'Dan Frost'
> > Cc: [e-mail]
> > Subject: Re: [mpls-tp] R: Intermediate nodes and segment monitoring in
> > draft-ietf-mpls-tp-oam-framework-09
> > 
> > Italo,
> > 
> > > 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.
> > 
> > I assume that you refer to the a change of the transport path due to
> > e.g.
> > protection switching or restoration event. Correct?
> > 
> > Use of pro-active OAM based on TTL-expiry would cause problems after
> > the
> > failed transport path was restored via a path with e.g. 4 hops (whereas
> > the
> > original path has e.g. 2 hops). The TTL in the OAM packets would expire
> > too
> > early, and these OAM packets would not reach the far end MEP.
> > 
> > Regards,
> > Maarten
> > 
> > > -----Original Message-----
> > > From: [e-mail] [mailto:[e-mail]] On
> > > Behalf Of BUSI, ITALO (ITALO)
> > > Sent: 26 November 2010 14:50
> > > 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.
> > >
> > > 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.
> > >
> > > 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.
> > >
> > > 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.
> > >
> > > 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
> > 
> > _______________________________________________
> > 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
> 
>