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

From: John E Drake <[email-masked]>
Date: Wed, 1 Dec 2010 04:26:32 -0800

Maarten,

Excellent.   I consider the modeling of the function  unnecessary, but  I am sure it will eventually be detailed in an ITU document 8->.  The other point is that we can work on this function as an adjunct to the existing SPME functionality and hence there is no reason to delay the OAM Framework.

Thanks,

John

Sent from my iPhone

From: Maarten Vissers [mailto:[email-masked]]
Sent: Tuesday, November 30, 2010 11:49 PM
To: John E Drake; 'Greg Mirsky'
Cc: [email-masked]; [email-masked]
Subject: 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:[email-masked]]
Sent: 30 November 2010 20:20
To: Maarten Vissers; 'Greg Mirsky'
Cc: [email-masked]; [email-masked]
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:[email-masked]]
Sent: Tuesday, November 30, 2010 12:21 AM
To: 'Greg Mirsky'
Cc: John E Drake; [email-masked]; [email-masked]
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:[email-masked]]
Sent: 30 November 2010 08:52
To: Maarten Vissers
Cc: John E Drake; [email-masked]; [email-masked]
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 <[email-masked]<mailto:[email-masked]>> 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:[email-masked]<mailto:[email-masked]>]
Sent: 29 November 2010 21:57
To: Greg Mirsky

Cc: Maarten Vissers; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
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:[email-masked]<mailto:[email-masked]>]
Sent: Monday, November 29, 2010 12:05 PM
To: John E Drake
Cc: Maarten Vissers; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
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 <[email-masked]<mailto:[email-masked]>> 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:[email-masked]<mailto:[email-masked]>]
Sent: Sunday, November 28, 2010 3:21 AM
To: [email-masked]<mailto:[email-masked]>
Cc: John E Drake; Dan Frost; BUSI, ITALO (ITALO); [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls-tp