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

[John E Drake <[e-mail]>]

Fei,

That’s what I was thinking, and while I suggested (2), I think I would be okay with (1) as well .  (Whichever is less work.)

 On a related topic, I don’t think we need to hold up the framework I-D, which describes the former mechanism,  while working on the latter mechanism.

Thanks,

John

Sent from my iPhone

From: [e-mail] [mailto:[e-mail]]
Sent: Saturday, November 27, 2010 7:04 PM
To: John E Drake
Cc: 'Dan Frost'; 'BUSI, ITALO (ITALO)'; Maarten Vissers; [e-mail]; [e-mail]
Subject: Re: [mpls-tp] R: Intermediate nodes and segment monitoring in draft-ietf-mpls-tp-oam-framework-09


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