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

From: Dan Frost <[email-masked]>
Date: Wed, 24 Nov 2010 20:05:20 +0000

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

----- End forwarded message -----

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 25 Nov 2010 08:49:29 +0200

Dan,

Yes. Removing the unnecessary restrictions AND, preferably, defining a MPLS data plane-compliant solution for sub-path monitoring is definitely preferable.

BTW, such a solution could, if so desired, support monitoring of overlapping sub-paths as well.

Regards,
     Sasha

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Dan Frost [[email-masked]]
Sent: Wednesday, November 24, 2010 10:05 PM
To: [email-masked]
Subject: [mpls-tp] Intermediate nodes and segment monitoring in draft-ietf-mpls-tp-oam-framework-09

-d

----- Forwarded message -----

-d

---

From: John E Drake <[email-masked]>
Date: Thu, 25 Nov 2010 11:39:22 -0800

Dan,

The intermediate node restriction is utter nonsense.

Btw, thanks for this email.  It caused me to read through the thread and discover this gem from Maarten:

http://www.ietf.org/mail-archive/web/mpls-tp/current/msg04506.html

It reminds of me of a Professor Irwin Corey routine.

John

Sent from my iPhone

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Dan Frost
> Sent: Wednesday, November 24, 2010 12:05 PM
> To: [email-masked]

---

From: "BUSI, ITALO (ITALO)" <[email-masked]>
Date: Fri, 26 Nov 2010 14:50:00 +0100

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.

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

> > 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: [email-masked] [mailto:[email-masked]] Per conto
> di Dan Frost
> Inviato: mercoledì 24 novembre 2010 21.05
> A: [email-masked]
> Oggetto: [mpls-tp] Intermediate nodes and segment monitoring in draft-
> ietf-mpls-tp-oam-framework-09
>

---

From: Maarten Vissers <[email-masked]>
Date: Fri, 26 Nov 2010 16:00:34 +0100

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

> Behalf Of BUSI, ITALO (ITALO)
> Sent: 26 November 2010 14:50
> To: Dan Frost
> Cc: [email-masked]
> 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.
> 
> 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.
> 
> 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.
> 
> 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
>

---

From: Alexander Vainshtein <[email-masked]>
Date: Fri, 26 Nov 2010 17:06:19 +0200

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

Dan,

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

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

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

**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

---

From: John E Drake <[email-masked]>
Date: Fri, 26 Nov 2010 08:54:25 -0800

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

> Behalf Of Maarten Vissers
> Sent: Friday, November 26, 2010 7:01 AM
> To: 'BUSI, ITALO (ITALO)'; 'Dan Frost'
> Cc: [email-masked]
> Subject: Re: [mpls-tp] R: Intermediate nodes and segment monitoring in
> > - http://tools.ietf.org/html/draft-koike-mpls-tp-temporal-hitless-
> psm-
> > 01
> > > OAM framework.  It would be useful to hear brief yea/nays from the
> WG
> > as
> > > Subject: Re: [mpls-tp] about open discussion about MIPMEP in MPLS-
> TP
> > > networks
> > >
> > > three months or so with different subject headings, it will save
> time
> > to
> > > Given this, it's not clear to me why the restriction is still
> present
> > in
> > > operators and protocol designers.  The OAM framework, or its
> update,
> > is

---

From: [email-masked]
Date: Sun, 28 Nov 2010 11:04:14 +0800

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 d
raft-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 <[email-masked]> 
发件人:  [email-masked]
2010-11-27 00:54

收件人
Maarten Vissers <[email-masked]>, "'BUSI, ITALO (ITALO)'" 
<[email-masked]>, 'Dan Frost' <[email-masked]>
抄送
"[email-masked]" <[email-masked]>
主题
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

---

From: Maarten Vissers <[email-masked]>
Date: Sun, 28 Nov 2010 12:20:37 +0100

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 [email-masked] 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: 
> 
> (2)Increasing the MEP definition for path segment, a little revision to the document [tp-identifier]. 
> 
> Just my two cents. 
> 
> Fei :)
> 
> 
> 
> Maarten Vissers <[email-masked]>, "'BUSI, ITALO (ITALO)'" <[email-masked]>, 'Dan Frost' <[email-masked]>
> 抄送
> Re: [mpls-tp] R: Intermediate nodes and segment monitoring in draft-ietf-mpls-tp-oam-framework-09
> 
> 
> 
> 
> 
> Maarten,
>

---

From: John E Drake <[email-masked]>
Date: Sun, 28 Nov 2010 06:41:22 -0800

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

John:

Italo, Dan:

Just my two cents.

Fei :)

2010-11-27 00:54

收件人

抄送

主题

Maarten,

Thanks,

John

Sent from my iPhone

---

From: [email-masked]
Date: Mon, 29 Nov 2010 13:33:30 +0800

Hi Maarten

See in line, jut my two cents

Fei :)

Maarten Vissers <[email-masked]> 
2010-11-28 19:20

收件人
"[email-masked]" <[email-masked]>
抄送
John E Drake <[email-masked]>, Dan Frost <[email-masked]>, "BUSI, 
ITALO (ITALO)" <[email-masked]>, "[email-masked]" 
<[email-masked]>, "[email-masked]" <[email-masked]>
主题
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. 
ZF: Firstly, I do not think what you said will happen, for SPME is used 
for monitoring and protection. It normally exists between ingress and 
egress port of a recovery domain, so it will aware of the hops of working 
and protection 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.
ZF: A recovery domain does not mean that the information of the hops will 
be hidden, Even it is located outside the recovery domain (a very little 
chance), can also be learned by NMS or Control plane [see RFC4873]. 

Of course,two Up MEPs will work, but why do not use the simplier solution 
if it can work?

Regards,
Maarten

Op 28 nov. 2010 om 04:04 heeft [email-masked] 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. 

Italo, Dan: 

Just my two cents. 

Fei :)

收件人
Maarten Vissers <[email-masked]>, "'BUSI, ITALO (ITALO)'" <
[email-masked]>, 'Dan Frost' <[email-masked]> 
抄送
"[email-masked]" <[email-masked]> 
主题
Re: [mpls-tp] R: Intermediate nodes and segment monitoring in 
draft-ietf-mpls-tp-oam-framework-09

Maarten,

Thanks,

John

Sent from my iPhone

---

From: John E Drake <[email-masked]>
Date: Mon, 29 Nov 2010 08:12:04 -0800

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]]
Sent: Sunday, November 28, 2010 3:21 AM
To: [email-masked]
Cc: John E Drake; Dan Frost; BUSI, ITALO (ITALO); [email-masked]; [email-masked]
Subject: Re: [mpls-tp] R: Intermediate nodes and segment monitoring in draft-ietf-mpls-tp-oam-framework-09

John, Fei,

Regards,
Maarten

Op 28 nov. 2010 om 04:04 heeft [email-masked]<mailto:[email-masked]> het volgende geschreven:

John:

Italo, Dan:

Just my two cents.

Fei :)

John E Drake <[email-masked]<mailto:[email-masked]>>
发件人:  [email-masked]<mailto:[email-masked]>

2010-11-27 00:54

收件人

Maarten Vissers <[email-masked]<mailto:[email-masked]>>, "'BUSI, ITALO (ITALO)'" <[email-masked]<mailto:[email-masked]>>, 'Dan Frost' <[email-masked]<mailto:[email-masked]>>

抄送

"[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

主题

Maarten,

Thanks,

John

Sent from my iPhone

> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On
> Cc: [email-masked]<mailto:[email-masked]>

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 29 Nov 2010 12:05:15 -0800

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]> wrote:

> 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]]
> *Sent:* Sunday, November 28, 2010 3:21 AM
> *To:* [email-masked]
> *Cc:* John E Drake; Dan Frost; BUSI, ITALO (ITALO); [email-masked];
> [email-masked]
>
> *Subject:* Re: [mpls-tp] R: Intermediate nodes and segment monitoring in
> 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.
>
>
>
> 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
>
>
> I agree with you, but TTL scheme will face scaling issues if it is used for
> nested path segment monitoring, as I addressed in
>   *John E Drake <[email-masked]>*
> 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
>

---

From: John E Drake <[email-masked]>
Date: Mon, 29 Nov 2010 12:56:32 -0800

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]]
Sent: Monday, November 29, 2010 12:05 PM
To: John E Drake
Cc: Maarten Vissers; [email-masked]; [email-masked]; [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,

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]>

John, Fei,

Regards,
Maarten

John:

Italo, Dan:

Just my two cents.

Fei :)

2010-11-27 00:54

收件人

抄送

主题

Maarten,

Thanks,

John

Sent from my iPhone

> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On

_______________________________________________
mpls-tp mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 29 Nov 2010 18:56:20 -0800

Hi John,
yes, the GAL will always be there as BoS, but it is TTL expiration that
creates the exception in this scenario. There's a question whether MIP
functionality is implicit or explicit on a MEP that can be addressed in
draft-farrel-mpls-tp-mep-mip-map. I believe that MEP should be able to
process TTL expiring exception as it processes GAL exception
(traceroute/link trace scenario).

Regards,
Greg

2010/11/29 John E Drake <[email-masked]>

>  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]]
> *Sent:* Monday, November 29, 2010 12:05 PM
> *To:* John E Drake
> *Cc:* Maarten Vissers; [email-masked]; [email-masked];
> [email-masked]
>

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 30 Nov 2010 08:38:06 +0100

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]] 
Sent: 29 November 2010 21:57
To: Greg Mirsky
Cc: Maarten Vissers; [email-masked]; [email-masked];
[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

Cc: Maarten Vissers; [email-masked]; [email-masked];

Dear John,

Regards,

Greg

Snipped trailing emails

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

Maarten,

Thanks,

John

Sent from my iPhone

From: Maarten Vissers [mailto:[email-masked]] 
Sent: Sunday, November 28, 2010 3:21 AM
To: [email-masked]
Cc: John E Drake; Dan Frost; BUSI, ITALO (ITALO); [email-masked];
[email-masked]

John, Fei,

Regards,

Maarten

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 29 Nov 2010 23:51:30 -0800

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]> wrote:

> *From:* John E Drake [mailto:[email-masked]]
> *Sent:* 29 November 2010 21:57
> *To:* Greg Mirsky
>
> *Subject:* RE: [mpls-tp] R: Intermediate nodes and segment monitoring in

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 30 Nov 2010 09:21:00 +0100

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,

 

Regards,

Greg

On Mon, Nov 29, 2010 at 11:38 PM, Maarten Vissers
<[email-masked]> wrote:

John,

Regards,

Maarten

Greg,

Thanks,

John

Sent from my iPhone

Dear John,

Regards,

Greg

Snipped trailing emails

Maarten,

Thanks,

John

Sent from my iPhone

John, Fei,

Regards,

Maarten

---

From: John E Drake <[email-masked]>
Date: Tue, 30 Nov 2010 05:01:38 -0800

Maarten,

There has been some discussion of supplementing the existing SPME construct (LSP hierarchy) with an on-demand single LSP monitoring capability.  An operator would select a pair of nodes along the path of the LSP to be monitored and instantiate the monitoring  capability by configuring on each the TTL required to reach each other.   The two nodes would then exchange OAM packets by taking the monitored LSPs label stack, adding a GAL to it, and setting the TTL to the configured value.

Thanks,

John

Sent from my iPhone

From: Maarten Vissers [mailto:[email-masked]]
Sent: Monday, November 29, 2010 11:38 PM
To: John E Drake
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] R: Intermediate nodes and segment monitoring in draft-ietf-mpls-tp-oam-framework-09

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]]
Sent: 29 November 2010 21:57
To: Greg Mirsky
Cc: Maarten Vissers; [email-masked]; [email-masked]; [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

Dear John,

Regards,
Greg

Thanks,

John

Sent from my iPhone

John, Fei,

Regards,
Maarten

---

From: John E Drake <[email-masked]>
Date: Tue, 30 Nov 2010 05:44:47 -0800

Greg,

I think you’re right, but traceroute could actually be considered either way.  I.e.,  TTL expiry will be used by all of the intermediate nodes along the path of a given LSP (MIP exception processing).  When the traceroute packet is received by the LSP’s egress node, is the exception caused by TTL expiry (MIP exception processing) or label stack processing (MEP exception processing)?

Thanks,

John

Sent from my iPhone

From: Greg Mirsky [mailto:[email-masked]]
Sent: Monday, November 29, 2010 6:56 PM
To: John E Drake
Cc: Maarten Vissers; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls-tp] R: Intermediate nodes and segment monitoring in draft-ietf-mpls-tp-oam-framework-09

Hi John,
yes, the GAL will always be there as BoS, but it is TTL expiration that creates the exception in this scenario. There's a question whether MIP functionality is implicit or explicit on a MEP that can be addressed in draft-farrel-mpls-tp-mep-mip-map. I believe that MEP should be able to process TTL expiring exception as it processes GAL exception (traceroute/link trace scenario).

Regards,
Greg
2010/11/29 John E Drake <[email-masked]<mailto:[email-masked]>>
Greg,

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]>

Dear John,

Regards,
Greg

Thanks,

John

Sent from my iPhone

John, Fei,

Regards,
Maarten

John:

Italo, Dan:

Just my two cents.

Fei :)

2010-11-27 00:54

收件人

抄送

主题

Maarten,

Thanks,

John

Sent from my iPhone

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 30 Nov 2010 17:27:19 +0200

Resending as plain text to meet the size limits.

Regards,
     Sasha

From: Alexander Vainshtein 
Sent: Tuesday, November 30, 2010 5:26 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, Greg,
I’ve looked up RFC 3443 Section 3.4 “Incoming TTL Determination”  and the answer to your question
When the traceroute packet is received by the LSP’s egress node, is the exception caused by TTL expiry (MIP exception processing) or label stack processing (MEP exception processing)?
seems to depend on whether GAL is treated according to the Pipe or Uniform model.

If you use the Uniform model, then expiration of TTL in the LSP label at egress would case exception because this TTL would be considered the incoming TTL when GAL is looked up.

If you use the Pipe model (which I, personally, believe the proper way to do – see also Section 3.1.1 in RFC 5960) then TTL check on the LSP label at egress will be skipped (because this label is popped), and exception would be caused by the GAL look-up.

Unfortunately, RFC 5586 does not, IMO, clarify which of these models must be applied to GAL.

Regards,
     Sasha

From: [email-masked] [mailto:[email-masked]] On Behalf Of John E Drake
Sent: Tuesday, November 30, 2010 3:45 PM
To: 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

Greg,

Thanks,

John

Sent from my iPhone

Hi John,

Regards,
Greg

Thanks,
 
John
 
Sent from my iPhone

 
Dear John,
 
Regards,
Greg

 
Thanks,
 
John
 
Sent from my iPhone

 
John, Fei,

Regards,
Maarten

John: 

Italo, Dan: 

Just my two cents. 

Fei :)

Maarten,

Thanks,

John

Sent from my iPhone

---

From: John E Drake <[email-masked]>
Date: Tue, 30 Nov 2010 11:20:16 -0800

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

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,

Regards,
Maarten

From: John E Drake [mailto:[email-masked]<mailto:[email-masked]>]
Sent: 29 November 2010 21:57
To: Greg Mirsky

Greg,

Thanks,

John

Sent from my iPhone

Dear John,

Regards,
Greg

Thanks,

John

Sent from my iPhone

John, Fei,

Regards,
Maarten

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 01 Dec 2010 08:49:23 +0100

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

Sent from my iPhone

Dear Greg,

Regards,

Maarten

Dear Maarten,

 

Regards,

Greg

John,

Regards,

Maarten

Greg,

Thanks,

John

Sent from my iPhone

Dear John,

Regards,

Greg

Snipped trailing emails

Maarten,

Thanks,

John

Sent from my iPhone

John, Fei,

Regards,

Maarten