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

John,

If we consider the on-demand sub-path monitoring as a non-intrusive
monitoring application, which is only there for a short period in which it
is highly unlikely that number of hops is changed, then I agree with you
that those maintenance signals have to go to the LSP endpoints. In addition,
the 'MIP with on-demand MEP sink functionality' will have to non-intrusively
detect those maintenance signals (i.e. without terminating) and report these
conditions as it will clarify why a CC/CV loss is detected.

Note that a 'MIP with such on-demand MEP functionality' is a compound
function, which can (and should) be decomposed into a true MIP plus  an
'on-demand MEP' function below it. Those on-demand MEP functions will be
bounding an on-demand SPME.

For the case a sub-path monitor function is to be activated for a longer
period, use of TTL is not appropriate in my opinion.

Regards,

Maarten

From: John E Drake [mailto:jdrake@juniper.net] 
Sent: 30 November 2010 20:20
To: Maarten Vissers; 'Greg Mirsky'
Cc: mpls-tp@ietf.org; mpls-tp-bounces@ietf.org
Subject: RE: [mpls-tp] R: Intermediate nodes and segment monitoring in
draft-ietf-mpls-tp-oam-framework-09

I think AIS/LDI/LKR should go to the LSP endpoints

Sent from my iPhone

From: Maarten Vissers [mailto:maarten.vissers@huawei.com] 
Sent: Tuesday, November 30, 2010 12:21 AM
To: 'Greg Mirsky'
Cc: John E Drake; mpls-tp@ietf.org; mpls-tp-bounces@ietf.org
Subject: RE: [mpls-tp] R: Intermediate nodes and segment monitoring in
draft-ietf-mpls-tp-oam-framework-09

Dear Greg,

I am very concerned by using TTL for MEP type OAM like CC/CV, LM, AIS, etc.
A change of the route of the transport path will require an update of the
TTL value the "MIP"s sourcing the MEP type OAM packets and in the
intermediate server MEPs that generate e.g. AIS.

Regards,

Maarten

From: Greg Mirsky [mailto:gregimirsky@gmail.com] 
Sent: 30 November 2010 08:52
To: Maarten Vissers
Cc: John E Drake; mpls-tp@ietf.org; mpls-tp-bounces@ietf.org
Subject: Re: [mpls-tp] R: Intermediate nodes and segment monitoring in
draft-ietf-mpls-tp-oam-framework-09

Dear Maarten,

I am thinking of this possible change too. I agree that then we'll need to
introduce MEG or similar ID. But I consider TTL as replacement of GAL only
as exception trigger. I agree with John that GAL will always be at BoS to
indicate OAM packet. Though letting MIP source OAM BFD-like packet changes
context of Your Discriminator and, in my view, requires proper TLV ID of the
source or TTL TLV.

Regards,

Greg

On Mon, Nov 29, 2010 at 11:38 PM, Maarten Vissers
<maarten.vissers@huawei.com> wrote:

John,

There seems to be a discussion if a MIP can be used to  source and sink
CC/CV and other MEP type OAM packets. For such case there will be a
maintenance entity level with endpoints in MIPs and use of TTL instead of
GAL.

Regards,

Maarten

From: John E Drake [mailto:jdrake@juniper.net] 
Sent: 29 November 2010 21:57
To: Greg Mirsky

Cc: Maarten Vissers; zhang.fei3@zte.com.cn; mpls-tp-bounces@ietf.org;
mpls-tp@ietf.org

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

Greg,

The GAL will be there in all cases.  I don't think I have read any
discussion of using TTL for MEP-MEP and MIP-MEP - it's really not necessary
as the MEP will be popping labels in any event and it will see the GAL.  We
seem to agree on the other points.

Thanks,

John

Sent from my iPhone

From: Greg Mirsky [mailto:gregimirsky@gmail.com] 
Sent: Monday, November 29, 2010 12:05 PM
To: John E Drake
Cc: Maarten Vissers; zhang.fei3@zte.com.cn; mpls-tp-bounces@ietf.org;
mpls-tp@ietf.org
Subject: Re: [mpls-tp] R: Intermediate nodes and segment monitoring in
draft-ietf-mpls-tp-oam-framework-09

Dear John,

I think that MEP-MEP and MIP-MEP OAM exception can be both GAL and TTL
based. Only TTL-based exception is available for MIP directed OAM packets in
MEP-MIP and MIP-MIP OAM. 

I think that hop counts of working and protecting LSPs can be both
statically configured or dynamically discovered.

Regards,

Greg

On Mon, Nov 29, 2010 at 8:12 AM, John E Drake <jdrake@juniper.net> wrote:

Snipped trailing emails

----------------------------------------------------------------------------
----------------------------------------------------------------------------
----------------------------------------------------

Maarten,

There seems to be some confusion.  Packets sent between MEPs or from a MIP
to a MEP do not rely on TTL expiry for delivery.  So, the only issue is
packets sent from a MEP to a MIP.  As I indicated in my email, the MEPs can
be configured with the TTLs of the working and protecting LSPs, and when
they are notified of a protection switch, per draft-ietf-mpls-tp-fault, they
can switch to the TTL of the protecting LSP.

Alternatively, when the MEPs are notified of a protection switch, they can
use LSP Traceroute (draft-ietf-mpls-tp-on-demand-cv)  to learn the TTL and
MIP identifiers.

Thanks,

John

Sent from my iPhone

From: Maarten Vissers [mailto:maarten.vissers@huawei.com] 
Sent: Sunday, November 28, 2010 3:21 AM
To: zhang.fei3@zte.com.cn
Cc: John E Drake; Dan Frost; BUSI, ITALO (ITALO); mpls-tp@ietf.org;
mpls-tp-bounces@ietf.org

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

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

_______________________________________________
mpls-tp mailing list
mpls-tp@ietf.org
https://www.ietf.org/mailman/listinfo/mpls-tp