Subject: [mpls-tp] Comments on draft-tp-loss-delay

From: David Allan I <[email-masked]>
Date: Thu, 7 Oct 2010 12:38:43 -0400

HI

I've looked over the draft. Kudos in a well written document. A few nits...

Section 1.1.2

The sentence "Accurate quantification of one-way delay may require clock synchronization, the means for which are outside the scope of this document." does not say what entities need clock synch..  Can I suggest rephrasing to "Accurate quantification of one-way delay may require clock synchronization between the MEPs in the measured ME, the means for which ... :

Section 1.1.2

The sentence "This function should be performed between End Points of PWs, LSPs and Sections."...perhaps "This function can be performed....", should sounds rather strange in this context.

Section 3.1

The error code 14 15 and 16 implying some form of misconnectivity....IMO if an LD or DM message is received from an unexpected source/destination/connection it should be silently discarded as the implication is a misconnection fault. There is no guarantee that the return path has integrity either. Or if it does the error code will be returned to a MEP that did not originate the message.

Section 4.1.7

A long discussion on misordering etc. is in the document followed by a note suggesting this will be revised to consider sequence numbers and threasholds. Given that the message does contain a sequence number, isn't the correct statement "measurements are only valid between messages where the sequence number has monotonically increased. Out of order receipt invalidates measurement state." Else a lot of heuristic is requried for a function that will need a lot of hardware assist already.

Section 7

Would not a third concern be tampering of information (man in the middle), wildly unlikely but corrupting measurements is a form of DOS attack...?

Cheers
Dave

---

From: Dan Frost <[email-masked]>
Date: Thu, 14 Oct 2010 10:12:33 +0100

Hi David,

David Allan I <[email-masked]> writes:
> The sentence "Accurate quantification of one-way delay may require
> clock synchronization, the means for which are outside the scope of
> this document." does not say what entities need clock synch..  Can I
> suggest rephrasing to "Accurate quantification of one-way delay may
> require clock synchronization between the MEPs in the measured ME, the
> means for which ... :
>
> Section 1.1.2
>
> The sentence "This function should be performed between End Points of
> PWs, LSPs and Sections."...perhaps "This function can be
> performed....", should sounds rather strange in this context.

The text in Section 1.1 comes directly from RFC 5860, so comments on it
are best addressed to the authors of that document.

> Section 3.1
>
> The error code 14 15 and 16 implying some form of
> misconnectivity....IMO if an LD or DM message is received from an
> unexpected source/destination/connection it should be silently
> discarded as the implication is a misconnection fault. There is no
> guarantee that the return path has integrity either. Or if it does the
> error code will be returned to a MEP that did not originate the
> message.

Fair point, thanks.  These types of error conditions are probably more
germane to local logging/reporting than to responses.

> Section 4.1.7
>
> A long discussion on misordering etc. is in the document followed by a
> note suggesting this will be revised to consider sequence numbers and
> threasholds. Given that the message does contain a sequence number,
> isn't the correct statement "measurements are only valid between
> messages where the sequence number has monotonically increased. Out of
> order receipt invalidates measurement state." Else a lot of heuristic
> is requried for a function that will need a lot of hardware assist
> already.

We agree and the text in the next version will reflect this.

> Section 7
>
> Would not a third concern be tampering of information (man in the
> middle), wildly unlikely but corrupting measurements is a form of DOS
> attack...?

Good point; we'll add this consideration.

Thanks for the review!

-d

---

From: Vishwas Manral <[email-masked]>
Date: Thu, 14 Oct 2010 10:28:14 -0700

Hi,

>> middle), wildly unlikely but corrupting measurements is a form of DOS
I know the ACH TLV draft expired.

I was however wondering if atleast for the security side, we should
use the TLV, that way every mechanism over MPLT-TP will not need to
support the same and define its own set of algorithms etc.

Thanks,
Vishwas

On Thu, Oct 14, 2010 at 2:12 AM, Dan Frost <[email-masked]> wrote:
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp
>

---

From: Dan Frost <[email-masked]>
Date: Fri, 15 Oct 2010 14:08:02 +0100

> support the same and define its own set of algorithms etc.

One option would be to create a generic TLV (not ACH TLV) registry and
allow specific drafts to add types to it.  The type space could be split
into generic and protocol-specific portions, thereby allowing types with
generic applicability to be specified as such, and allowing protocols to
use the same type space for both private and generic functions.

-d

---

From: Vishwas Manral <[email-masked]>
Date: Fri, 15 Oct 2010 10:36:28 -0700

Hi Dan,

One thing we could do is to have the TLV structure at the end of the
ACH message. As the ACH TLV is optional, this is how things would look
in my view

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  GAL                  |  TC |S|       TTL     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             ACH                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               ~
   ~                         G-ACh message                         ~
   ~                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Trailer TLV Header (if present)              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               ~
   ~                     Zero or more TLVs                         ~
   ~                         (if present)                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

We could then reuse the ACH TLV draft. Ofcourse the TLV's to support
for each message would be well defined and at a fixed place.

Thanks,
Vishwas

---

From: "Shahram Davari" <[email-masked]>
Date: Fri, 15 Oct 2010 11:07:50 -0700

Hi,

I agree with Vishwas. Any TLV should be after the G_ACH message to make it suitable for Hardware processing or filtering.

Thanks,
Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Vishwas Manral
Sent: Friday, October 15, 2010 10:36 AM
To: Dan Frost
Cc: [email-masked]
Subject: Re: [mpls-tp] Generic TLVs

Hi Dan,

    0                   1                   2                   3

Thanks,
Vishwas

---

From: Vishwas Manral <[email-masked]>
Date: Fri, 15 Oct 2010 21:47:45 -0700

Hi Shahram,

I agree. Like mentioned by Dan there is a need to use common
functionality and one of the ways to achieve it using common TLV
structures, so that MPLS-TP protocols are uniform and do not define
the same thing in multiple places.

However the ACH TLV like you mentioned is not hardware friendly and
may not be usable in a lot of cases. I am therefore proposing we have
the ACH TLV's at the end of the packet rather then the beginning which
is the case right now.

What do other folks think about this?

Thanks,
Vishwas

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 18 Oct 2010 15:51:17 +0100

>>> middle), wildly unlikely but corrupting measurements is a form of DOS
An attacker in the middle of a TP net is extremely unlikely, but if 
there were one this seems to be one of the least likely attack modes.

- Stewart