Subject: Re: [TICTOC] FW: 1588 over MPLS draft

From: Tal Mizrahi <[email-masked]>
Date: Mon, 19 Jul 2010 17:54:34 +0300

Hi Sasha, all,

A couple of comments:

1. Generally, regarding using GAL+ACH: according to RFC 5586: "LSRs MUST NOT modify the G-ACh message, the ACH or the GAL towards the targeted destination". However, a PTP capable LSR that functions as a TC must modify the packet (including the correctionField and the UDP checksum). This means that if an LSR functions as a TC, either (a) the functionality in RFC 5586 must be enhanced to allow modification, or (b) the LSR terminates all incoming PTP messages, and then re-generates them, which may burden the control plane.

2. Sasha, regarding your option 1 below: if each packet has a label stack with 1 label (GAL), it raises the question how to distinguish between single-target and multi-target PTP packets. PTP calls for both multicast frames (e.g.), and unicast (e.g. Delay_Req).

That's not to say I am against using the GAL, but it needs some further refinement.

Tal.

-----Original Message-----

Yaakov and all,

Please note that GAL and, by implication, the ACH header are only looked at by

an LSTR if GAL happens to be the top label in the stack (either because it has

been the top label in originally received packet, or because all the labels

above it have been popped by this LSR).

This leaves two options IMO:

1. You carry PTP directly across physical links using labeled packets that

   have a label stack of depth 1 containing GAL.

   In this case you can probably do want you want with the PTP packets'

   payload, (e.g., support TC), but you need some new mechanism for forwarding

   PTP packets along a multi-hop path.

2. You can carry PTP across any LSP using GAL at the bottom of the label stack.

   In this case only the tail end of the LSP will be PTP-aware, i.e., TC will

   not be supported with this option.

I suggest taking a look at http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-data-plane for details

regarding MPLS (and MPLS-TP) data plane.

Regards,

     Sasha

-----Original Message-----

From: tictoc-bounces at ietf.org [mailto:tictoc-bounces at ietf.org] On Behalf Of Yaakov Stein

Sent: Monday, July 19, 2010 12:06 PM

To: Mikael Abrahamsson

Cc: tictoc at ietf.org

Subject: Re: [TICTOC] FW: 1588 over MPLS draft

No. Not a new Ethertype - we are talking about MPLS NOT Ethernet.

There is a protocol type (it's actually called a "channel type")

in the Ach control word. See RFC 4385.

Right now only a few are defined (raw BFD, IPv4, IPv6).

Y(J)S

-----Original Message-----

From: Mikael Abrahamsson [mailto:swmike at swm.pp.se]

Sent: Monday, July 19, 2010 09:48

To: Yaakov Stein

Cc: stbryant at cisco.com; tictoc at ietf.org

Subject: Re: [TICTOC] FW: 1588 over MPLS draft

On Sun, 18 Jul 2010, Yaakov Stein wrote:

> 1) define a new protocol type (plenty of openings in THAT registry!)

New protocol type on what level? Ethernet, so this would involve a new

ethertype?

If routers generally can look that far into the packet on the correct

forwarding level (I doubt it though) then that would be the least

intrusive, but having LSRs look for ethertype within MPLS labeled packets

sounds kind of advanced to do that early in the receive path?

Why not do it more like an MPLS L3 VPN terminated/routed by all

involved&&aware routers, then it would signal special labels to its

neighbours that would be local significance only? But now we're talking

handling it like a tree and that would involve routing protocols as

well... Basically this would be like multicast IP and could leverage all

the multicast MPLS standards out there.

--

Mikael Abrahamsson    email: swmike at swm.pp.se

_______________________________________________

TICTOC mailing list

TICTOC at ietf.org

https://www.ietf.org/mailman/listinfo/tictoc

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 19 Jul 2010 18:06:24 +0300

Tal,
I think that we are in full agreement regarding a single-label GAL-only stack:
It allows the LSRs to modify PTP packets (as TC must do), but it does not support forwarding (unicast and multicast). Hence it is useless.
IMO GAL/G-ACH are a clear dead end in this discussion.

If you have been following this list, I've suggested allocating a new reserved label  which, at the top of the stack, would indicate PTP packets.
IMHO this is the only method that would somehow accommodate TC (which is a layer violation, of course) without completely breaking MPLS data plane.
However, this approach did not gain support on the list.

"PTP FEC" IMO is also a dead end. E.g., you would not be able such popular  recovery techniques as Facility FRR for this FEC, etc.

At the same time, if TC support is not required, there is no need to invent any special encapsulation of PTP over MPLS. All the rest of the  use cases can be easily accommodated with PTP/UDP/IP/MPLS without inventing new wheels.

My 2c,
     Sasha

From: Tal Mizrahi [mailto:[email-masked]]
Sent: Monday, July 19, 2010 5:55 PM
To: Alexander Vainshtein
Cc: [email-masked]
Subject: Re: [TICTOC] FW: 1588 over MPLS draft

Hi Sasha, all,

A couple of comments:

Tal.

-----Original Message-----

Yaakov and all,

Regards,

     Sasha

-----Original Message-----

To: Mikael Abrahamsson

Cc: tictoc at ietf.org

Y(J)S

-----Original Message-----

To: Yaakov Stein

ethertype?

--

TICTOC mailing list

TICTOC at ietf.org

---

From: "Shahram Davari" <[email-masked]>
Date: Mon, 19 Jul 2010 12:07:07 -0700

Hi Sasha,

Although I like your proposal for a reserved label, but if that is not agreeable then what is wrong with an LSP dedicated to PTP (call it PTP LSP)? Also why do you say that PTP FEC can't do FRR?

Thanks,
Shahram

From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexander Vainshtein
Sent: Monday, July 19, 2010 8:06 AM
To: Tal Mizrahi
Cc: [email-masked]
Subject: Re: [TICTOC] FW: 1588 over MPLS draft

Tal,

My 2c,
     Sasha

Hi Sasha, all,

A couple of comments:

Tal.

-----Original Message-----

Yaakov and all,

Regards,

     Sasha

-----Original Message-----

To: Mikael Abrahamsson

Cc: tictoc at ietf.org

Y(J)S

-----Original Message-----

To: Yaakov Stein

ethertype?

--

TICTOC mailing list

TICTOC at ietf.org

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 19 Jul 2010 13:00:37 -0700

Dear Sasha,
I think I disagree with your assessment of applicability of Section
GAL to PTP.propagation throughout MPLS-TP network. If we set
performance (delay, jitter, and latency introduced by an MPLS-TP node
that is end-point of a Section) aside for now, I don't see what
precludes a PTP packet from being forwarded (both unicast and
multicast) over DCN. Yes, the performance hit might be prohibitive but
with enough thrust ...

Regards,
Greg

On Mon, Jul 19, 2010 at 8:06 AM, Alexander Vainshtein
<[email-masked]> wrote:
> It allows the LSRs to modify PTP packets (as TC must do), but it does not
> support forwarding (unicast and multicast). Hence it is useless.
>
> If you have been following this list, I’ve suggested allocating a new
> reserved label  which, at the top of the stack, would indicate PTP packets.
>
> IMHO this is the only method that would somehow accommodate TC (which is a
> layer violation, of course) without completely breaking MPLS data plane.
>
> “PTP FEC” IMO is also a dead end. E.g., you would not be able such popular
>  recovery techniques as Facility FRR for this FEC, etc.
>
>
>
> At the same time, if TC support is not required, there is no need to invent
> any special encapsulation of PTP over MPLS. All the rest of the  use cases
> can be easily accommodated with PTP/UDP/IP/MPLS without inventing new
> wheels.
>
>
>
> My 2c,
>
>      Sasha
>
>
>
> 1. Generally, regarding using GAL+ACH: according to RFC 5586: “LSRs MUST NOT
> modify the G-ACh message, the ACH or the GAL towards the targeted
> destination”. However, a PTP capable LSR that functions as a TC must modify
> the packet (including the correctionField and the UDP checksum). This means
> that if an LSR functions as a TC, either (a) the functionality in RFC 5586
> must be enhanced to allow modification, or (b) the LSR terminates all
> incoming PTP messages, and then re-generates them, which may burden the
> control plane.
>
> 2. Sasha, regarding your option 1 below: if each packet has a label stack
> with 1 label (GAL), it raises the question how to distinguish between
> single-target and multi-target PTP packets. PTP calls for both multicast
> frames (e.g.), and unicast (e.g. Delay_Req).
>
>
>
> That’s not to say I am against using the GAL, but it needs some further
> refinement.
>
>
>
> Tal.
>
>
>
>
>
>
>
>
>
>
>
>
>
> I suggest taking a look at
> http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-data-plane for details
>
> [email-masked]