Subject: Re: [TICTOC] FW: I-D Action: draft-ietf-tictoc-1588overmpls-02.txt

From: "Laurent Montini (lmontini)" <[email-masked]>
Date: Thu, 1 Dec 2011 14:49:15 +0100

Hi Lars,

Master and slave ports of a BC can have different, distinct
encapsulations (mappings) as long as PTP message information are
preserved.

As such, LER can receive PTP messages with IP mapping, and, by
implementing BC function, could send the same PTP messages over an LSP
with some MPLS encapsulation and receiving LER can transmit with
Ethernet mapping. 

In this draft, the original encap tends to be preserved over the LSP
with assumption that LER is either an ordinary or a boundary clock. 

Actually LER in this draft might be PTP unaware, thus not providing any
timing assistance but only MPLS transport, with the risk to impair the
quality of the timing distribution.  

One key point, I guess for all LSRs between two LERs (assuming OC or
BC), is either to use the same encapsulation to keep the timestamp point
unique or to define an unique timestamp point for their residence time
measurement. The first option should be fine for most intra-carrier
cases (except, e.g., when adding a label for FRR tunnel) when the second
option could allow adding extra label e.g., for FRR or CSC in
inter-carrier cases.

Thanks,

Laurent

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Lars Ellegaard
Sent: mardi 29 novembre 2011 22:27
To: Greg Mirsky
Cc: [email-masked]
Subject: Re: [TICTOC] FW: I-D Action:
draft-ietf-tictoc-1588overmpls-02.txt

Hi Greg

You are of course right.

My point is merely that if the PTP frame arrives at the MPLS network
encapsulated in Ethernet (for example) the other end (PTP application)
would expect the same encapsulation.

I suppose that in princple the Ethernet header could be stripped, the
PTP frame carried in G-Ach, and then a new, identical Ethernet header
added again?

Rgds

Lars

From: Greg Mirsky [mailto:[email-masked]] 
Sent: 29 November 2011 22:15
To: Lars Ellegaard
Cc: Ron Cohen; [email-masked]
Subject: Re: [TICTOC] FW: I-D Action:
draft-ietf-tictoc-1588overmpls-02.txt

Hi Lars,
I think that non-MPLS portions are outside of scope for 1588 Over MPLS
document.

Regards,
Greg

On Tue, Nov 29, 2011 at 1:12 PM, Lars Ellegaard <[email-masked]> wrote:

And there are cases where MPLS transport is only a part of the e2e path

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Greg Mirsky
Sent: 29 November 2011 22:09
To: Ron Cohen

Cc: [email-masked]
Subject: Re: [TICTOC] FW: I-D Action:
draft-ietf-tictoc-1588overmpls-02.txt

Dear Ron,
need to point that only IP and MPLS payload can be carried over MPLS
natively, directly. Any other payload, including Ethernet, would require
PW. Perhaps PTP can be carried over G-ACh?

Regards,
Greg

On Tue, Nov 29, 2011 at 1:00 PM, Ron Cohen <[email-masked]> wrote:

If the encapsulation was directly over MPLS, i.e. no Ethernet / IP
layers in between MPLS and PTP, there were no layers to violate....

On Tue, Nov 29, 2011 at 8:35 PM, Anthony Magee <[email-masked]>
wrote:

Hi Yaakov,

The layer violation issue is something which I believe needs further
discussion.

If a higher layer entity is placed inside a device and is used to act as
the Transparent Clock i.e. calculating residence time and modifying the
correction field in the layer with which that higher layer entity is
associated, one could use an identifier such as a label, or a  multicast
Destination address in order to address that higher layer entity,
allowing it to make the change without it being a layer violation.
Then on the transmit side, there is nothing specifically incorrect in a
device modifying the Source Address of the packet sent from a
Transparent Clock within the scope of IEEE 1588 and this would be needed
in order to indicate that the device has effectively created a new
packet - however, the function of the node is still that of a
Transparent Clock.

So as long as the various standards are observed and the modifying
devices update the packets in a standards compliant manner, I don't see
that such a Transparent Clock would constitute a layer violation.

Anthony

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Yaakov Stein
Sent: 26 November 2011 20:25
To: [email-masked]; Shahram Davari
Cc: [email-masked]'
Subject: Re: [TICTOC] FW: I-D Action:
draft-ietf-tictoc-1588overmpls-02.txt

Shahram and Stewart

If we need intermediate MPLS nodes to perform special processing on
1588oMPLS packets there are several methods to lower the processing
requirements.
Of course, DPI could be performed to go below the MPLS and IP headers as
Shahram said, but as Stewart pointed out this would be prohibitively
expensive.

Two methods have been proposed.
The method of the present draft is to use the standard encapsulations
(after ensuring that 1588 is supported) and to inform the intermediate
nodes that the particular label value being used is special.
For this special label value the node has been informed of what to do,
e.g., has the offset of a TC.
Any use of TC is necessarily a layer violation (after all, the timestamp
is a layer-0 entity and we are placing it in a layer 2 or higher field),
but correcting a field inside 1588 in UDP in IP in MPLS is not really
that much worse than correcting on in 1588 in UDP in IP in Ethernet.

The alternative method that I proposed is to invent a completely new
timestamping mechanism.
This has the advantage of being applicable to all MPLS packets (and thus
can solve other problems), but requires inventing yet another timing
distribution protocol.
I know that Stewart succeeded in inventing a new packet loss and delay
measurement protocol for TP, but I didn't gauge support in TICTOC for
something new here.

Y(J)S

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]]
Sent: Thursday, November 24, 2011 19:30
To: Shahram Davari

Cc: [email-masked]'; [email-masked]'
Subject: Re: [TICTOC] FW: I-D Action:
draft-ietf-tictoc-1588overmpls-02.txt

Shahram

I will ponder the answer to this question, but will note that you have
not addressed my second question which relates to whether there is MPLS
WG buy-in for this proposal.

- Stewart

On 24/11/2011 16:34, Shahram Davari wrote:
> Hi Stewart,
>
> The parsing required by the draft is not complex and almost all MPLS
routers have support it already. The idea was to reuse existing data
plane mechanisms and not invent a new one. This I believe is in the
spirit of IETF to reuse existing mechanisms.
>
> I don't believe adding a shim makes the design simpler. You still need
to detect that such shim exists and for that you need parsing that
doesn't even exist today.
>
>
> This draft has been implemented by vendors, so we have a working code
and I believe we also have rough consensus.
>
> Thanks
> Shahram
>
>
>
> ----- Original Message -----
> From: Stewart Bryant [mailto:[email-masked]]
> Sent: Thursday, November 24, 2011 07:58 AM
> To: [email-masked]<[email-masked]>
> Cc: [email-masked]<[email-masked]>;

> [email-masked]<[email-masked]>
> Subject: Re: [TICTOC] FW: I-D Action:
> draft-ietf-tictoc-1588overmpls-02.txt
>

> Can we wind back to my original points here which have not addressed.
>
> Why are is the WG proposing a design that needs such complex parsing,
> against the ethos of MPLS, when a simpler design would be more
> universally applicable?
>
> Does the WG have any input to suggest that the design will survive a
> review by MPLS/PWE3 WG and then by IESG?
>
> - Stewart
>
>
> On 22/11/2011 09:12, Stewart Bryant wrote:
>> Speaking as an individual here, I really have a hard time
>> understanding why it is necessary to have quite the egregious layer
>> violation that this draft uses.
>>
>> The idea of having an LSP type that is dedicated to tracking the time
>> of passage through the network is a good idea. However MPLS is
>> completely geared to the concept that only the LSP endpoints know how
>> to resolve the payload type.
>>
>> The function that you require could be achieved by including a shim
>> that contains the time compensation information and adjust the
>> payload on egress from the LSP. That would be rather more consistent
>> with the MPLS architecture.
>>
>> I have not seen a request for review by the MPLS or PWE3 WGs and I
>> would suggest that you request that sooner rather than later since it
>> is inevitable that the draft will be sent there later in it's life,
>> and if they do not subscribe to your mode of operation the draft is
>> unlikely to progress.
>>
>> I would also suggest that you discuss the extent of layer violation
>> with your AD to make sure he is confident that this draft will pass
>> IESG review.
>>

>> - Stewart
>>
>>
>> _______________________________________________
>> TICTOC mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/tictoc
>>
>

--
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

_______________________________________________
TICTOC mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tictoc
_______________________________________________
TICTOC mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tictoc

_______________________________________________
TICTOC mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tictoc

CONFIDENTIALITY NOTICE: This e-mail message, including any attachments,
is for the sole use of the intended recipient(s) and may contain
confidential and privileged information. Any unauthorized review, use,
disclosure or distribution is prohibited. If you are not the intended
recipient, please contact the sender by reply e-mail and destroy all
copies of the original message.

CONFIDENTIALITY NOTICE: This e-mail message, including any attachments,
is for the sole use of the intended recipient(s) and may contain
confidential and privileged information. Any unauthorized review, use,
disclosure or distribution is prohibited. If you are not the intended
recipient, please contact the sender by reply e-mail and destroy all
copies of the original message.

---

From: Lars Ellegaard <[email-masked]>
Date: Thu, 1 Dec 2011 14:13:19 +0000

Hi Laurent
Agree that encapsulations can be different on slave and master side (even different to different slaves) of a BC.
I don't follow you here: "As such, LER can receive PTP messages with IP mapping, and, by implementing BC function, could send the same PTP messages over an LSP with some MPLS encapsulation and receiving LER can transmit with Ethernet mapping. " PTP frames will not pass a BC, but terminated on the slave side and generated on master side. Maybe I misunderstand?

I don't see adding a FRR label as a problem as long as the DPI configuration is updated.

Thx
Lars

From: Laurent Montini (lmontini) [mailto:[email-masked]]
Sent: 01 December 2011 14:49
To: Lars Ellegaard; Greg Mirsky
Cc: [email-masked]
Subject: RE: [TICTOC] FW: I-D Action: draft-ietf-tictoc-1588overmpls-02.txt

Hi Lars,

Master and slave ports of a BC can have different, distinct encapsulations (mappings) as long as PTP message information are preserved.
As such, LER can receive PTP messages with IP mapping, and, by implementing BC function, could send the same PTP messages over an LSP with some MPLS encapsulation and receiving LER can transmit with Ethernet mapping.
In this draft, the original encap tends to be preserved over the LSP with assumption that LER is either an ordinary or a boundary clock.
Actually LER in this draft might be PTP unaware, thus not providing any timing assistance but only MPLS transport, with the risk to impair the quality of the timing distribution.
One key point, I guess for all LSRs between two LERs (assuming OC or BC), is either to use the same encapsulation to keep the timestamp point unique or to define an unique timestamp point for their residence time measurement. The first option should be fine for most intra-carrier cases (except, e.g., when adding a label for FRR tunnel) when the second option could allow adding extra label e.g., for FRR or CSC in inter-carrier cases.

Thanks,
Laurent

From: [email-masked] [mailto:[email-masked]] On Behalf Of Lars Ellegaard
Sent: mardi 29 novembre 2011 22:27
To: Greg Mirsky
Cc: [email-masked]
Subject: Re: [TICTOC] FW: I-D Action: draft-ietf-tictoc-1588overmpls-02.txt

Hi Greg
You are of course right.
My point is merely that if the PTP frame arrives at the MPLS network encapsulated in Ethernet (for example) the other end (PTP application) would expect the same encapsulation.
I suppose that in princple the Ethernet header could be stripped, the PTP frame carried in G-Ach, and then a new, identical Ethernet header added again?
Rgds
Lars

From: Greg Mirsky [mailto:[email-masked]]
Sent: 29 November 2011 22:15
To: Lars Ellegaard
Cc: Ron Cohen; [email-masked]
Subject: Re: [TICTOC] FW: I-D Action: draft-ietf-tictoc-1588overmpls-02.txt

Hi Lars,
I think that non-MPLS portions are outside of scope for 1588 Over MPLS document.

Regards,
Greg
On Tue, Nov 29, 2011 at 1:12 PM, Lars Ellegaard <[email-masked]<mailto:[email-masked]>> wrote:
And there are cases where MPLS transport is only a part of the e2e path

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Greg Mirsky
Sent: 29 November 2011 22:09
To: Ron Cohen

Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [TICTOC] FW: I-D Action: draft-ietf-tictoc-1588overmpls-02.txt

Dear Ron,
need to point that only IP and MPLS payload can be carried over MPLS natively, directly. Any other payload, including Ethernet, would require PW. Perhaps PTP can be carried over G-ACh?

Regards,
Greg
On Tue, Nov 29, 2011 at 1:00 PM, Ron Cohen <[email-masked]<mailto:[email-masked]>> wrote:
If the encapsulation was directly over MPLS, i.e. no Ethernet / IP layers in between MPLS and PTP, there were no layers to violate....

On Tue, Nov 29, 2011 at 8:35 PM, Anthony Magee <[email-masked]<mailto:[email-masked]>> wrote:
Hi Yaakov,

The layer violation issue is something which I believe needs further discussion.

If a higher layer entity is placed inside a device and is used to act as the Transparent Clock i.e. calculating residence time and modifying the correction field in the layer with which that higher layer entity is associated, one could use an identifier such as a label, or a  multicast Destination address in order to address that higher layer entity, allowing it to make the change without it being a layer violation.   Then on the transmit side, there is nothing specifically incorrect in a device modifying the Source Address of the packet sent from a Transparent Clock within the scope of IEEE 1588 and this would be needed in order to indicate that the device has effectively created a new packet - however, the function of the node is still that of a Transparent Clock.

So as long as the various standards are observed and the modifying devices update the packets in a standards compliant manner, I don't see that such a Transparent Clock would constitute a layer violation.

Anthony

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Yaakov Stein
Sent: 26 November 2011 20:25
To: [email-masked]<mailto:[email-masked]>; Shahram Davari
Cc: [email-masked]<mailto:[email-masked]>'
Subject: Re: [TICTOC] FW: I-D Action: draft-ietf-tictoc-1588overmpls-02.txt
Shahram and Stewart

If we need intermediate MPLS nodes to perform special processing on 1588oMPLS packets there are several methods to lower the processing requirements.
Of course, DPI could be performed to go below the MPLS and IP headers as Shahram said, but as Stewart pointed out this would be prohibitively expensive.

Two methods have been proposed.
The method of the present draft is to use the standard encapsulations (after ensuring that 1588 is supported) and to inform the intermediate nodes that the particular label value being used is special.
For this special label value the node has been informed of what to do, e.g., has the offset of a TC.
Any use of TC is necessarily a layer violation (after all, the timestamp is a layer-0 entity and we are placing it in a layer 2 or higher field), but correcting a field inside 1588 in UDP in IP in MPLS is not really that much worse than correcting on in 1588 in UDP in IP in Ethernet.

The alternative method that I proposed is to invent a completely new timestamping mechanism.
This has the advantage of being applicable to all MPLS packets (and thus can solve other problems), but requires inventing yet another timing distribution protocol.
I know that Stewart succeeded in inventing a new packet loss and delay measurement protocol for TP, but I didn't gauge support in TICTOC for something new here.

Y(J)S

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, November 24, 2011 19:30
To: Shahram Davari
Cc: [email-masked]<mailto:[email-masked]>'; [email-masked]<mailto:[email-masked]>'
Subject: Re: [TICTOC] FW: I-D Action: draft-ietf-tictoc-1588overmpls-02.txt
Shahram

I will ponder the answer to this question, but will note that you have not addressed my second question which relates to whether there is MPLS WG buy-in for this proposal.

- Stewart

On 24/11/2011 16:34, Shahram Davari wrote:
> Hi Stewart,
>
> The parsing required by the draft is not complex and almost all MPLS routers have support it already. The idea was to reuse existing data plane mechanisms and not invent a new one. This I believe is in the spirit of IETF to reuse existing mechanisms.
>
> I don't believe adding a shim makes the design simpler. You still need to detect that such shim exists and for that you need parsing that doesn't even exist today.
>
>
> This draft has been implemented by vendors, so we have a working code and I believe we also have rough consensus.
>
> Thanks
> Shahram
>
>
>
> From: Stewart Bryant [mailto:[email-masked]<mailto:[email-masked]>]
> To: [email-masked]<mailto:[email-masked]><[email-masked]<mailto:[email-masked]>>
> Cc: [email-masked]<mailto:[email-masked]><[email-masked]<mailto:[email-masked]>>;
> [email-masked]<mailto:[email-masked]><[email-masked]<mailto:[email-masked]>>
>> [email-masked]<mailto:[email-masked]>

http://www.cisco.com/web/about/doing_business/legal/cri/index.html
_______________________________________________
TICTOC mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tictoc
_______________________________________________
TICTOC mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tictoc

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

CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.

CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.

---

From: "Laurent Montini (lmontini)" <[email-masked]>
Date: Thu, 1 Dec 2011 19:58:39 +0100

Hi Lars,

No misunderstanding.

PTPoUDP/IP  -  slave/LER-BC/master - PTPo[...]oMPLS - slave/LER-BC-master - PTPoETH

What do you mean by DPI configuration?

Thx,

Laurent

From: Lars Ellegaard [mailto:[email-masked]] 
Sent: jeudi 1 décembre 2011 15:13
To: Laurent Montini (lmontini); Greg Mirsky
Cc: [email-masked]
Subject: RE: [TICTOC] FW: I-D Action: draft-ietf-tictoc-1588overmpls-02.txt

Hi Laurent

Thx

Lars

Hi Lars,

Thanks,

Laurent

Hi Greg

You are of course right.

Rgds

Lars

Hi Lars,

Regards,
Greg

From: [email-masked] [mailto:[email-masked]] On Behalf Of Greg Mirsky
Sent: 29 November 2011 22:09
To: Ron Cohen

Cc: [email-masked]

Dear Ron,

Regards,
Greg

On Tue, Nov 29, 2011 at 8:35 PM, Anthony Magee <[email-masked]> wrote:

Hi Yaakov,

Anthony

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Yaakov Stein
Sent: 26 November 2011 20:25
To: [email-masked]; Shahram Davari
Cc: [email-masked]'
Subject: Re: [TICTOC] FW: I-D Action: draft-ietf-tictoc-1588overmpls-02.txt

Shahram and Stewart

Y(J)S

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]]
Sent: Thursday, November 24, 2011 19:30
To: Shahram Davari

Shahram

- Stewart

---

From: "Shahram Davari" <[email-masked]>
Date: Thu, 1 Dec 2011 13:38:34 -0800

Hi,

I think that there are 2 cases:

1)      Intra-carrier: In this case the 1588 is providing a single 1588 domain timing throughout the carrier's network for the carrier. The LERs are Master/Slave or BC. In this case the PTP message is terminated at LERs and therefore any encapsulation can be used in the network.

2)      Inter-carrier: In this case Carrier A is just tunneling the PTP messages of carrier B. Carrier A should not terminate PTP messages and the LERs are TC (not BC). In this case we have to tunnel carrier B's PTP packets that may be Ethernet or IP encapsulated.

The motivation for the draft is to support both cases. By sticking to existing encapsulation, both these cases can be supported.

Thanks
Shahram

From: [email-masked] [mailto:[email-masked]] On Behalf Of Laurent Montini (lmontini)
Sent: Thursday, December 01, 2011 10:59 AM
To: Lars Ellegaard; Greg Mirsky
Cc: [email-masked]
Subject: Re: [TICTOC] FW: I-D Action: draft-ietf-tictoc-1588overmpls-02.txt

Hi Lars,

No misunderstanding.

Thx,
Laurent

Hi Laurent

Thx
Lars

Hi Lars,

Thanks,
Laurent

Hi Greg
You are of course right.

Hi Lars,

Regards,
Greg

Dear Ron,

Regards,
Greg

Anthony

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Yaakov Stein
Sent: 26 November 2011 20:25
To: [email-masked]<mailto:[email-masked]>; Shahram Davari
Cc: [email-masked]<mailto:[email-masked]>'
Subject: Re: [TICTOC] FW: I-D Action: draft-ietf-tictoc-1588overmpls-02.txt
Shahram and Stewart

Y(J)S

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, November 24, 2011 19:30
To: Shahram Davari
Cc: [email-masked]<mailto:[email-masked]>'; [email-masked]<mailto:[email-masked]>'
Subject: Re: [TICTOC] FW: I-D Action: draft-ietf-tictoc-1588overmpls-02.txt
Shahram

- Stewart

---

From: Ron Cohen <[email-masked]>
Date: Fri, 2 Dec 2011 06:40:03 +0200

'By sticking to the existing encapsulation, both these cases can be
supported' - this assumes that in the intra-carrier case each LSR (not only
the edge LSRs) can terminate and regenerate IP/Ethernet PW, which I don't
think is true in the general case, i.e. in particular you assume that each
LSR has IP and/or Ethernet Interfaces. It seems more plausible for me to
assume that each PTP-aware-LSR should be able to terminate and regenerate
direct-PTP--over-MPLS messages (or PWs), similar to the assumption that
each LSR need to be able to 'terminate and regenerate' OAM messages. Best,
Ron

On Thu, Dec 1, 2011 at 11:38 PM, Shahram Davari <[email-masked]> wrote:

> Hi,****
>
> ** **
>
> I think that there are 2 cases:****
>
> ** **
>
> **1)      **Intra-carrier: In this case the 1588 is providing a single
> 1588 domain timing throughout the carrier’s network for the carrier. The
> LERs are Master/Slave or BC. In this case the PTP message is terminated at
> LERs and therefore any encapsulation can be used in the network.****
>
> **2)      **Inter-carrier: In this case Carrier A is just tunneling the
> PTP messages of carrier B. Carrier A should not terminate PTP messages and
> the LERs are TC (not BC). In this case we have to tunnel carrier B’s PTP
> packets that may be Ethernet or IP encapsulated. ****
>
> ** **
>
> The motivation for the draft is to support both cases. By sticking to
> existing encapsulation, both these cases can be supported.****
>
> ** **
>
> Thanks****
>
> Shahram ****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *Laurent Montini (lmontini)
> *Sent:* Thursday, December 01, 2011 10:59 AM
>
> *To:* Lars Ellegaard; Greg Mirsky
> *Cc:* [email-masked]
> *Subject:* Re: [TICTOC] FW: I-D Action:
> draft-ietf-tictoc-1588overmpls-02.txt****
>
> ** **
>
> Hi Lars,****
>
> ** **
>
> No misunderstanding.****
>
> PTPoUDP/IP  –  slave/LER-BC/master – PTPo[...]oMPLS — slave/LER-BC-master
> — PTPoETH****
>
> ** **
>
> What do you mean by DPI configuration?****
>
> ** **
>
> Thx,****
>
> Laurent****
>
> ** **
>
> *From:* Lars Ellegaard [mailto:[email-masked]]
> *Sent:* jeudi 1 décembre 2011 15:13
> *To:* Laurent Montini (lmontini); Greg Mirsky
> *Cc:* [email-masked]
> *Subject:* RE: [TICTOC] FW: I-D Action:
> draft-ietf-tictoc-1588overmpls-02.txt****
>
> ** **
>
> Hi Laurent****
>
> Agree that encapsulations can be different on slave and master side (even
> different to different slaves) of a BC.****
>
> I don’t follow you here: “As such, LER can receive PTP messages with IP
> mapping, and, by implementing BC function, could send the same PTP messages
> over an LSP with some MPLS encapsulation and receiving LER can transmit
> with Ethernet mapping. “ PTP frames will not pass a BC, but terminated on
> the slave side and generated on master side. Maybe I misunderstand?****
>
>  ****
>
> I don’t see adding a FRR label as a problem as long as the DPI
> configuration is updated.****
>
>  ****
>
> Thx****
>
> Lars****
>
>  ****
>
>  ****
>
> *From:* Laurent Montini (lmontini) [mailto:[email-masked]]
> *Sent:* 01 December 2011 14:49
> *To:* Lars Ellegaard; Greg Mirsky
> *Cc:* [email-masked]
> *Subject:* RE: [TICTOC] FW: I-D Action:
> draft-ietf-tictoc-1588overmpls-02.txt****
>
>  ****
>
> Hi Lars,****
>
>  ****
>
> Master and slave ports of a BC can have different, distinct encapsulations
> (mappings) as long as PTP message information are preserved.****
>
> implementing BC function, could send the same PTP messages over an LSP with
> some MPLS encapsulation and receiving LER can transmit with Ethernet
> mapping. ****
>
> In this draft, the original encap tends to be preserved over the LSP with
> assumption that LER is either an ordinary or a boundary clock. ****
>
> quality of the timing distribution.  ****
>
> One key point, I guess for all LSRs between two LERs (assuming OC or BC),
> is either to use the same encapsulation to keep the timestamp point unique
> or to define an unique timestamp point for their residence time
> measurement. The first option should be fine for most intra-carrier cases
> (except, e.g., when adding a label for FRR tunnel) when the second option
> could allow adding extra label e.g., for FRR or CSC in inter-carrier cases.
> ****
>
>  ****
>
> Thanks,****
>
> Laurent****
>
>  ****
>
> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *Lars Ellegaard
> *Sent:* mardi 29 novembre 2011 22:27
> *To:* Greg Mirsky
> *Cc:* [email-masked]
> *Subject:* Re: [TICTOC] FW: I-D Action:
> draft-ietf-tictoc-1588overmpls-02.txt****
>
>  ****
>
> Hi Greg****
>
> You are of course right.****
>
> would expect the same encapsulation.****
>
> I suppose that in princple the Ethernet header could be stripped, the PTP
> frame carried in G-Ach, and then a new, identical Ethernet header added
> again?****
>
> Rgds****
>
> Lars****
>
>  ****
>
> *From:* Greg Mirsky [mailto:[email-masked]]
> *Sent:* 29 November 2011 22:15
> *To:* Lars Ellegaard
> *Cc:* Ron Cohen; [email-masked]
> *Subject:* Re: [TICTOC] FW: I-D Action:
> draft-ietf-tictoc-1588overmpls-02.txt****
>
>  ****
>
> Hi Lars,
> Greg****
> On Tue, Nov 29, 2011 at 1:12 PM, Lars Ellegaard <[email-masked]> wrote:***
> *
>
> And there are cases where MPLS transport is only a part of the e2e path***
> *
>
>  ****
>
> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *Greg Mirsky
> *Sent:* 29 November 2011 22:09
> *To:* Ron Cohen****
>
>
> *Cc:* [email-masked]
> *Subject:* Re: [TICTOC] FW: I-D Action:
> draft-ietf-tictoc-1588overmpls-02.txt****
>
>  ****
>
> Dear Ron,
> Greg****
> On Tue, Nov 29, 2011 at 1:00 PM, Ron Cohen <[email-masked]> wrote:**
> **
>
> If the encapsulation was directly over MPLS, i.e. no Ethernet / IP layers
> in between MPLS and PTP, there were no layers to violate....****
>
>  ****
>
> wrote:****
> Destination address in order to address that higher layer entity, allowing
> it to make the change without it being a layer violation.   Then on the
> transmit side, there is nothing specifically incorrect in a device
> modifying the Source Address of the packet sent from a Transparent Clock
> within the scope of IEEE 1588 and this would be needed in order to indicate
> that the device has effectively created a new packet - however, the
> function of the node is still that of a Transparent Clock.
>
> So as long as the various standards are observed and the modifying devices
> update the packets in a standards compliant manner, I don't see that such a
> Transparent Clock would constitute a layer violation.
>
> Anthony****
>
>
>
> ****
> but correcting a field inside 1588 in UDP in IP in MPLS is not really that
> much worse than correcting on in 1588 in UDP in IP in Ethernet.
>
> To: Shahram Davari****
> ****
> I will ponder the answer to this question, but will note that you have not
> addressed my second question which relates to whether there is MPLS WG
> buy-in for this proposal.
>
> - Stewart
>
>
>
> routers have support it already. The idea was to reuse existing data plane
> mechanisms and not invent a new one. This I believe is in the spirit of
> IETF to reuse existing mechanisms.
> >
> to detect that such shim exists and for that you need parsing that doesn't
> even exist today.
> >
> >
> > Cc: [email-masked]<[email-masked]>;****
>
> >****
> >>****
> >****
> http://www.cisco.com/web/about/doing_business/legal/cri/index.html****
>
> https://www.ietf.org/mailman/listinfo/tictoc****
>
>  ****
>
>
> https://www.ietf.org/mailman/listinfo/tictoc****
>
>  ****
>
> *CONFIDENTIALITY NOTICE: This e-mail message, including any attachments,
> recipient, please contact the sender by reply e-mail and destroy all copies
> of the original message.*****
>
>  ****
>
> *CONFIDENTIALITY NOTICE: This e-mail message, including any attachments,
> recipient, please contact the sender by reply e-mail and destroy all copies
> of the original message.*****
>
> *CONFIDENTIALITY NOTICE: This e-mail message, including any attachments,
> recipient, please contact the sender by reply e-mail and destroy all copies
> of the original message.*****
>

---

From: Lars Ellegaard <[email-masked]>
Date: Fri, 2 Dec 2011 08:16:02 +0000

With DPI I ment deep packet inspection. Put another way, the classifier must be reconfigured.

Sendt fra min HTC-telefon

----- Reply message -----
Fra: "Laurent Montini (lmontini)" <[email-masked]>
Dato: tor., dec. 1, 2011 19:59
Emne: [TICTOC] FW: I-D Action: draft-ietf-tictoc-1588overmpls-02.txt
Til: "Lars Ellegaard" <[email-masked]>, "Greg Mirsky" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>

Hi Lars,

No misunderstanding.
PTPoUDP/IP  –  slave/LER-BC/master – PTPo[...]oMPLS — slave/LER-BC-master — PTPoETH

Thx,
Laurent

Hi Laurent
Agree that encapsulations can be different on slave and master side (even different to different slaves) of a BC.
I don’t follow you here: “As such, LER can receive PTP messages with IP mapping, and, by implementing BC function, could send the same PTP messages over an LSP with some MPLS encapsulation and receiving LER can transmit with Ethernet mapping. “ PTP frames will not pass a BC, but terminated on the slave side and generated on master side. Maybe I misunderstand?

I don’t see adding a FRR label as a problem as long as the DPI configuration is updated.

Thx
Lars

Hi Lars,

Thanks,
Laurent

Hi Greg
You are of course right.

Hi Lars,

Regards,
Greg

Dear Ron,

Regards,
Greg

Anthony

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Yaakov Stein
Sent: 26 November 2011 20:25
To: [email-masked]<mailto:[email-masked]>; Shahram Davari
Cc: [email-masked]<mailto:[email-masked]>'
Subject: Re: [TICTOC] FW: I-D Action: draft-ietf-tictoc-1588overmpls-02.txt
Shahram and Stewart

Y(J)S

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, November 24, 2011 19:30
To: Shahram Davari
Cc: [email-masked]<mailto:[email-masked]>'; [email-masked]<mailto:[email-masked]>'
Subject: Re: [TICTOC] FW: I-D Action: draft-ietf-tictoc-1588overmpls-02.txt
Shahram

- Stewart

---

From: Danny Mayer <[email-masked]>
Date: Mon, 05 Dec 2011 07:36:38 -0500

discussion.
> 
> If a higher layer entity is placed inside a device and is used to
> act
as the Transparent Clock i.e. calculating residence time and modifying
the correction field in the layer with which that higher layer entity is
associated, one could use an identifier such as a label, or a multicast
Destination address in order to address that higher layer entity,
allowing it to make the change without it being a layer violation. Then
on the transmit side, there is nothing specifically incorrect in a
device modifying the Source Address of the packet sent from a
Transparent Clock within the scope of IEEE 1588 and this would be needed
in order to indicate that the device has effectively created a new
packet - however, the function of the node is still that of a
Transparent Clock.

There would be all sorts of violations if you change the Source Address.
NAT is bad enough without some other router also diddling with
addresses. Don't do that.

Danny

---

From: Anthony Magee <[email-masked]>
Date: Mon, 5 Dec 2011 12:59:57 +0000

Hi Danny,

I was intentionally vague here to see what feedback arose.

So in my email, I neglected to mention that the Source Address I was talking about modifying as a result of changing the contents of the packet, is the Layer 2 Source MAC Address.

For a device to modify the contents of a packet, or in this case for the higher layer entity to terminate the packet, and create a new packet, in order to preserve normal networking rules, then in theory the packet should use the address of the device that modified the packet.

If we have a case where 1588 PTP over Ethernet is being transported within a pseudowire and MPLS LSP, and the only addresses modified are the Layer 2 MAC Addresses(of the Layer 2 MAC Address encapsulated within the PW and the Layer 2 MAC address of the Ethernet Transport for the MPLS stack), would this cause any problems for NAT?

Regards,

Anthony

-----Original Message-----
From: Danny Mayer [mailto:[email-masked]] 
Sent: 05 December 2011 12:37
To: Anthony Magee
Cc: Yaakov Stein; [email-masked]; Shahram Davari; [email-masked]'
Subject: Re: [TICTOC] FW: I-D Action: draft-ietf-tictoc-1588overmpls-02.txt

discussion.
> 
> If a higher layer entity is placed inside a device and is used to act
as the Transparent Clock i.e. calculating residence time and modifying the correction field in the layer with which that higher layer entity is associated, one could use an identifier such as a label, or a multicast Destination address in order to address that higher layer entity, allowing it to make the change without it being a layer violation. Then on the transmit side, there is nothing specifically incorrect in a device modifying the Source Address of the packet sent from a Transparent Clock within the scope of IEEE 1588 and this would be needed in order to indicate that the device has effectively created a new packet - however, the function of the node is still that of a Transparent Clock.

There would be all sorts of violations if you change the Source Address.
NAT is bad enough without some other router also diddling with addresses. Don't do that.

Danny

---

From: Danny Mayer <[email-masked]>
Date: Mon, 05 Dec 2011 12:02:18 -0500

On 12/5/2011 7:59 AM, Anthony Magee wrote:
> So in my email, I neglected to mention that the Source Address I was
talking about modifying as a result of changing the contents of the
packet, is the Layer 2 Source MAC Address.

Okay, that's a relief! I was concerned about IP addresses. I have no
clue what the affect of changing a MAC address would be.

> For a device to modify the contents of a packet, or in this case for
the higher layer entity to terminate the packet, and create a new
packet, in order to preserve normal networking rules, then in theory the
packet should use the address of the device that modified the packet.
> 
> If we have a case where 1588 PTP over Ethernet is being transported
within a pseudowire and MPLS LSP, and the only addresses modified are
the Layer 2 MAC Addresses(of the Layer 2 MAC Address encapsulated within
the PW and the Layer 2 MAC address of the Ethernet Transport for the
MPLS stack), would this cause any problems for NAT?

I don't know if the NAT cares about that but I'm only knowledgeable at
the IP address level.

Danny

---

From: Yaakov Stein <[email-masked]>
Date: Thu, 8 Dec 2011 07:14:14 +0000

Ron and Anthony,

First, I don't see the difference between MPLS and Ethernet.
In principle, taking a layer-1 entity and putting it into an MPLS client's payload
is just as much a layer violation as putting it into an Ethernet client's payload.
There may be other reasons that this is less intrusive.
For example, since MPLS doesn't have a standardized security mechanism such as MACsec
it wouldn't be affected by a security mechanism. But then again you wouldn't have the security.

The idea of changing MAC addresses has been discussed before.
Since the intermediate switch is now terminating the Ethernet and originating a "new" message, there is no layer violation.
However this makes a middlebox into something different - mid-way between a TC and a BC.
It is also midway between a switch and a router (perhaps not an IP router, but something that routes the Ethernet's client).

I assume that you want everything else to go through without MAC swapping
(since otherwise you break layer-2 continuity, and a lot of things will malfunction, including ARP, OAM, G.803x).
So we also have the interesting situation where the switch uses two different MAC source addresses
on the same baggy-pants leg. This behavior may cause problems with quite a number of protocols.
I would have to think about it, but STP, TRILL, ELMI, LLDP, and MEF-8 come to mind.

Y(J)S

From: Ron Cohen [mailto:[email-masked]]
Sent: Tuesday, November 29, 2011 23:01
To: Anthony Magee
Cc: Yaakov Stein; [email-masked]; Shahram Davari; [email-masked]
Subject: Re: [TICTOC] FW: I-D Action: draft-ietf-tictoc-1588overmpls-02.txt

Anthony

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Yaakov Stein
Sent: 26 November 2011 20:25
To: [email-masked]<mailto:[email-masked]>; Shahram Davari
Cc: [email-masked]<mailto:[email-masked]>'
Subject: Re: [TICTOC] FW: I-D Action: draft-ietf-tictoc-1588overmpls-02.txt
Shahram and Stewart

Y(J)S

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, November 24, 2011 19:30
To: Shahram Davari
Cc: [email-masked]<mailto:[email-masked]>'; [email-masked]<mailto:[email-masked]>'
Subject: Re: [TICTOC] FW: I-D Action: draft-ietf-tictoc-1588overmpls-02.txt
Shahram

- Stewart

---

From: Anthony Magee <[email-masked]>
Date: Thu, 8 Dec 2011 08:54:23 +0000

Hi Yaakov,

No I assume that only a single MAC address per Ethernet interface is used.

Only those protocols which have an associated higher layer entity on the device should be affected, and only if those protocols are addressed in such a way that causes/allows those higher layer entities to process their associated traffic.

I believe that this is how 802.1 models allow extensions and other functions to sit on alongside the baggy pants model.  This is associated with the internal sublayer service as specified in IEEE Std 802.1Q-2005 clause 8.5.1

I don't see this as affecting any other protocols. Ie the higher layer entity would be specific to 1588oEthernet traffic addressed that higher layer entity.  I assume this function sits above the actual layer 2 transport and MPLS LSP/PW parsing function since the 1588oEthernet traffic will be transported within a PW?

I also think it could be argued that this is still a transparent clock in essence given the previous offical responses to questions/clarifications relating to swapping of source MAC address from IEEE 1588 experts.

As for the layer violation associated with your response, I assume by layer 1 entity you mean the timestamp?  In which case how does NTP get around the layer violation argument?

I am just trying to make it clear that the layer violation arguments are sometimes  unclear and in my view shouldn't be treated as a reason not to realize the transparent clock function.

I agree with your concerns about security, but think this topic applies to BC and TC devices alike and would best be treated as a separate discussion from the layer violation topic.

Best regards,

Anthony

On 8 Dec 2011, at 07:14, "Yaakov Stein" <[email-masked]<mailto:[email-masked]>> wrote:

Ron and Anthony,

Y(J)S

From: Ron Cohen [mailto:[email-masked]]
Sent: Tuesday, November 29, 2011 23:01
To: Anthony Magee
Cc: Yaakov Stein; [email-masked]<mailto:[email-masked]>; Shahram Davari; <mailto:[email-masked]> [email-masked]<mailto:[email-masked]>
Subject: Re: [TICTOC] FW: I-D Action: draft-ietf-tictoc-1588overmpls-02.txt

If the encapsulation was directly over MPLS, i.e. no Ethernet / IP layers in between MPLS and PTP, there were no layers to violate....
On Tue, Nov 29, 2011 at 8:35 PM, Anthony Magee <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>> wrote:
Hi Yaakov,

Anthony

-----Original Message-----
From: <mailto:[email-masked]> [email-masked]<mailto:[email-masked]> [mailto:<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>] On Behalf Of Yaakov Stein
Sent: 26 November 2011 20:25
To: <mailto:[email-masked]> [email-masked]<mailto:[email-masked]>; Shahram Davari
Cc: '<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>'
Subject: Re: [TICTOC] FW: I-D Action: draft-ietf-tictoc-1588overmpls-02.txt
Shahram and Stewart

Y(J)S

-----Original Message-----
From: Stewart Bryant [mailto:<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>]
Sent: Thursday, November 24, 2011 19:30
To: Shahram Davari
Cc: '<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>'; '<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>'
Subject: Re: [TICTOC] FW: I-D Action: draft-ietf-tictoc-1588overmpls-02.txt
Shahram

- Stewart

On 24/11/2011 16:34, Shahram Davari wrote:
> From: Stewart Bryant [mailto:<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>]
> To: <mailto:[email-masked]> [email-masked]<mailto:[email-masked]><<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>>
> Cc: <mailto:[email-masked]> [email-masked]<mailto:[email-masked]><<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>>;
> <mailto:[email-masked]> [email-masked]<mailto:[email-masked]><<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>>
>> <mailto:[email-masked]> [email-masked]<mailto:[email-masked]>
>> <https://www.ietf.org/mailman/listinfo/tictoc> https://www.ietf.org/mailman/listinfo/tictoc
>>
>

<http://www.cisco.com/web/about/doing_business/legal/cri/index.html>http://www.cisco.com/web/about/doing_business/legal/cri/index.html

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