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

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Tue, 22 Nov 2011 04:33:32 +0530

FYI

________________________________
From: Shahram Davari [mailto:[email-masked]]
Sent: Thursday, November 17, 2011 11:14 PM
To: Greg Mirsky; Bhatia, Manav (Manav); Amit Oren; [email-masked]; Roberts, Peter (Peter)
Subject: RE: [TICTOC] I-D Action: draft-ietf-tictoc-1588overmpls-02.txt

Hi Greg,

Here are our suggested resolution to your comments. Please let us know whether they are satisfactory.

Thx
Shahram

 ---------- Forwarded message ----------
From: Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Date: Wed, Oct 12, 2011 at 2:16 PM
Subject: RE: [TICTOC] I-D Action: draft-ietf-tictoc-1588overmpls-02.txt
To: [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]>, [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>

Dear Authors, et al.,
below are my notes to the latest version of the document. thank you for your kind consideration.

 *   Abstract. In last paragraph UDP/IP encapsulation presented as more preferable for IP/MPLS PSN while Ethernet PW as more preferable for MPLS-TP PSN. I think that applicability statements will benefit from more extensive and argumented discussion.
SD> suggest simply removing the last paragraph from the Abstract.

 *   Section 5, third para. Since MPLS-TP is a subset of MPLS statement "The PTP LSP MAY be MPLS LSP or MPLS-TP LSP" might be not the most accurate form of expression. At the same time the fourth paragraph suggests that PTP LSP might be configured by NMS (static configuration) or signaled by RSVP-TE/GMPLS. Have to note that RSVP-TE/GMPLS signaling is applicable only to MPLS-TP PSN. IP/MPLS LSPs are LDP signaled, MPLS-TE LSPs are signaled via RSVP-TE/MPLS.
SD> Suggest adding the following clarification: "MPLS or MPLS-TP LSP may be used. The LSPs are P2P (not P2MP) and that they could be unidirectional or co-routed bidirectional LSPs.  The setup could use either manual configuration or RSVP-TE."

 *   Section 6.1 Statement "In order for an LSR to process PTP messages, the PTP Label must be the top label of the label stack" implies that Facility Backup MPLS FRR should not be used for PTP LSP. Further in Section 8 suggested that FRR Backup tunnel label must be as well associated with the PTP application. I'll note that then all LSPs that to be protected by this PTP Backup will be viewed as PTP LSPs and that might be undesirable. I think that Facility Backup FRR is not practical local protection for PTP LSP.

SD> A dedicated FRR tunnel only carries PTP LSPs and therefore the issue you mention won't arise. We suggest clarification by adding this text: "FRR tunnel that use PTP label shall only carry PTP LSPs."

 *   Section 6.2, p.11, third para. A "PTP label range" is first time referred here. How this range is defined? Where it is defined - across all MPLS PSN or only along particular PTP LSP?
SD> This is a typo and is a remainder from first version. We will remove the term Range.

 *   Section 6.2, p.11, third para "... the PW label may be the top label in the stack, such as cases where there is only one-hop between PEs or in case of PHP ..." illustrates the same as text at the top of p.12
SD> Suggestion is to delete Para 3 of section 6.2 since it is redundant.

 *   section 6.2, p.12 refers not to "PTP label range" but to some mechanism to associate a label, PW label, with PTP application. Are there two mechanisms to make a label into a PTP application label - static and dynamic? Where PTP Association extensions will be defined?
SD> Type. We will delete the term Range.

 *   Section 10, p.17. s/G-ACH/G-ACh/ Will note that VCCV Type 1 Control Channel is ACH, not G-ACH.
SD> Typo. Will correct as per your suggestion.

Regards,
Greg
---------- Forwarded message ----------
From: <[email-masked]<mailto:[email-masked]>>
Date: Thu, Oct 6, 2011 at 10:23 PM
Subject: [TICTOC] I-D Action: draft-ietf-tictoc-1588overmpls-02.txt
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Timing over IP Connection and Transfer of Clock Working Group of the IETF.

       Title           : Transporting PTP messages (1588) over MPLS Networks
       Author(s)       : Shahram Davari
                         Amit Oren
                         Manav Bhatia
                         Peter Roberts
                         Laurent Montini
       Filename        : draft-ietf-tictoc-1588overmpls-02.txt
       Pages           : 34
       Date            : 2011-10-06

  This document defines the method for transporting PTP messages (PDUs)
  over an MPLS network.  The method allows for the easy identification
  of these PDUs at the port level to allow for port level processing of
  these PDUs in both LERs and LSRs.

  The basic idea is to transport PTP messages inside dedicated MPLS
  LSPs.  These LSPs only carry PTP messages and possibly Control and
  Management packets, but they do not carry customer traffic.

  Two methods for transporting 1588 over MPLS are defined.  The first
  method is to transport PTP messages directly over the dedicated MPLS
  LSP via UDP/IP encapsulation, which is suitable for IP/MPLS networks.
  The second method is to transport PTP messages inside a PW via
  Ethernet encapsulation, which is more suitable for MPLS-TP networks.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-tictoc-1588overmpls-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-tictoc-1588overmpls-02.txt
_______________________________________________
TICTOC mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tictoc

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 22 Nov 2011 09:12:57 +0000

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

---

From: "Shahram Davari" <[email-masked]>
Date: Tue, 22 Nov 2011 07:20:55 -0800

Hi Stewart,

Thanks for your valuable input. Since these PTP LSPs are defined to only carry IP or Ethernet encapsulated 1588 packets, the LSRs could easily parse them without requiring to know the Payload type per PW label. In other words if the LSP is a PTP LSP then the payload type is knwon and we don't need to keep the payload type state per PW label. So I don't think we are doing any layer violation.

All an LSR has to do is to go to the BoS and check the first nibble after BoS label to find out whether payload is IPv4 (nibble = '0100'), IPv6 (nibble = '0110'), OAM (nibble = '0001') or Ethernet (nibble = '0000') traffic. Only IP and Ethernet traffic needs further parsing to verify the 1588 packets. So really no knowledge of the payload type per PW label is required and therefore I think no layer violation.

Best Regards,
Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stewart Bryant
Sent: Tuesday, November 22, 2011 1:13 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [TICTOC] FW: I-D Action: draft-ietf-tictoc-1588overmpls-02.txt

- Stewart

[email-masked]

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 22 Nov 2011 17:31:03 +0200

Shahram,
I must admit that I have not been following discussions about PTP over MPLS, but I would like to clarify an issue that stems from reading your response to Stewart.

If I interpret you correctly, you say that, instead of sending PTP in PWs you are going to send them in dedicated LSPs. The advantage is that the transit nodes may derive the need to examine PRP packets by just looking at the labels at the top of stack.

The question is: what is supposed to happen if, for some reason, a transit node pushes yet another label on top of what has been originally allocated for a PTP-carrying LSP?  FRR (in the facility mode when multiple LSPs would be tunneled in the same bypass) is one valid example IMO, but there could be more.

Regards,
     Sasha

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Shahram Davari
> Sent: Tuesday, November 22, 2011 5:21 PM
> To: [email-masked]; [email-masked]
> Thanks for your valuable input. Since these PTP LSPs are defined to only
> carry IP or Ethernet encapsulated 1588 packets, the LSRs could easily parse
> them without requiring to know the Payload type per PW label. In other
> words if the LSP is a PTP LSP then the payload type is knwon and we don't
> need to keep the payload type state per PW label. So I don't think we are
> doing any layer violation.
> 
> All an LSR has to do is to go to the BoS and check the first nibble after BoS
> label to find out whether payload is IPv4 (nibble = '0100'), IPv6 (nibble =
> '0110'), OAM (nibble = '0001') or Ethernet (nibble = '0000') traffic. Only IP and
> Ethernet traffic needs further parsing to verify the 1588 packets. So really no
> knowledge of the payload type per PW label is required and therefore I
> think no layer violation.
> 
> 
> Best Regards,
> Shahram
> 
> 
> 
> 

This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof.

---

From: "Shahram Davari" <[email-masked]>
Date: Tue, 22 Nov 2011 07:33:58 -0800

Hi Sasha,

Good question. We have mentioned in the draft that any label pushed such as FRR case must also be a PTP label. We have also provided extension to signaling so that labels are identified as being PTP label.

Thanks
Shahram

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]] 
Sent: Tuesday, November 22, 2011 7:31 AM
To: Shahram Davari
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [TICTOC] FW: I-D Action: draft-ietf-tictoc-1588overmpls-02.txt

Shahram,

Regards,
     Sasha

> Of Stewart Bryant

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 22 Nov 2011 17:38:13 +0200

Shahram,
Lots of thanks for a prompt clarification.

But doesn't it mean that facility protection mode in FRR is effectively not applicable to PTP LSPs?

Regards,
     Sasha

> Sent: Tuesday, November 22, 2011 5:34 PM
> To: Alexander Vainshtein
> Good question. We have mentioned in the draft that any label pushed such
> as FRR case must also be a PTP label. We have also provided extension to
> signaling so that labels are identified as being PTP label.
> 
> Thanks
> Shahram
> 
> I must admit that I have not been following discussions about PTP over
> MPLS, but I would like to clarify an issue that stems from reading your
> response to Stewart.
> 
> If I interpret you correctly, you say that, instead of sending PTP in PWs you
> are going to send them in dedicated LSPs. The advantage is that the transit
> nodes may derive the need to examine PRP packets by just looking at the
> labels at the top of stack.
> 
> The question is: what is supposed to happen if, for some reason, a transit
> node pushes yet another label on top of what has been originally allocated
> for a PTP-carrying LSP?  FRR (in the facility mode when multiple LSPs would
> be tunneled in the same bypass) is one valid example IMO, but there could
> be more.
> 
> Regards,
>      Sasha
> 
> This e-mail message is intended for the recipient only and contains
> information which is CONFIDENTIAL and which may be proprietary to ECI
> Telecom. If you have received this transmission in error, please inform us by
> e-mail, phone or fax, and then delete the original and all copies thereof.
> 
>

---

From: "Shahram Davari" <[email-masked]>
Date: Tue, 22 Nov 2011 07:43:29 -0800

Hi Sasha,

Good point. This has been pointed out by other as well. It is still possible to use facility FRR, but now you need 2 FRR tunnels, one Special FRR tunnel using a PTP label for carrying PTP LSPs and another normal FRR tunnel for carrying other LSPs. This is possible but not efficient. 

Thanks
Shahram 

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]] 
Sent: Tuesday, November 22, 2011 7:38 AM
To: Shahram Davari
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [TICTOC] FW: I-D Action: draft-ietf-tictoc-1588overmpls-02.txt

Shahram,

Regards,
     Sasha

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 22 Nov 2011 19:52:36 +0000

Shahram

I would note three technical points here.

Firstly the normal practice in MPLS is that when you see the label
you know precisely what to do, you do not need to take a further
parsing decision. Thus IPv4 and IPv4 and PWs all have a label
that is signaled to say the type of payload. Parsing the payload
to determine type breaks that model.

Secondly, the assumption that the payload can only be
one of three types breaks the generality of the design, something
that we normally try hard in MPLS to preserve. You do not actually
need to know the payload type anywhere other than the endpoints
if we reduce the midpoints to only recording dwell time in an
abstract way. This more general approach would allow
the same mechanism to be used for any timing protocol, i.e.
NTP, and 1588v3 etc. In other words it would allow us to
introduce a new timing type without needing to upgrade the
P routers.

Finally the normal practice in MPLS is to minimise the actions
in the forwarding path, and this design does not represent
that minimization.

I also made a point about protocol review, and I would
really suggest that you should undertake the wider review
to make sure you will get buy-in before you take this approach
to completion.

- Stewart

-- 
For corporate legal information go to:

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

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 22 Nov 2011 12:50:10 -0800

Dear Shahram, et al.,
I'd like to take a step back and revisit, I think it might have been
discussed, different model. Assume that PTP-capable NEs advertize their
capability, i.e. through IGP TE extension, and that MPLS domain is MPLS-TP
network. Then a graph of LSPs provisioned to connect PTP-capable NEs. The
graph can be used to flood IP-encapsulated PTP or map MS-PW for
Ethernet-encapsulated PTP.
Do you think that such transport would be sufficient for 1588-over-MPLS?

Regards,
Greg

On Tue, Nov 22, 2011 at 7:43 AM, Shahram Davari <[email-masked]> wrote:

> Hi Sasha,
>
> Good point. This has been pointed out by other as well. It is still
> possible to use facility FRR, but now you need 2 FRR tunnels, one Special
> FRR tunnel using a PTP label for carrying PTP LSPs and another normal FRR
> tunnel for carrying other LSPs. This is possible but not efficient.
>
> Thanks
> Shahram
>
> > > '0110'), OAM (nibble = '0001') or Ethernet (nibble = '0000') traffic.
> Only IP
> > and
> > > Ethernet traffic needs further parsing to verify the 1588 packets. So
> really
> > no
> Telecom. If you have received this transmission in error, please inform us
> by e-mail, phone or fax, and then delete the original and all copies
> thereof.
>
>
>

---

From: "Shahram Davari" <[email-masked]>
Date: Tue, 22 Nov 2011 13:19:33 -0800

Hi Greg,

Yes that model will work. Also note that it is not required that all LSRs in the path of PTP LSP be PTP-Capable. It is still acceptable if some are not.

Thx
Shahram

From: Greg Mirsky [mailto:[email-masked]]
Sent: Tuesday, November 22, 2011 12:50 PM
To: Shahram Davari
Cc: Alexander Vainshtein; [email-masked]; [email-masked]
Subject: Re: [TICTOC] FW: I-D Action: draft-ietf-tictoc-1588overmpls-02.txt

Dear Shahram, et al.,
I'd like to take a step back and revisit, I think it might have been discussed, different model. Assume that PTP-capable NEs advertize their capability, i.e. through IGP TE extension, and that MPLS domain is MPLS-TP network. Then a graph of LSPs provisioned to connect PTP-capable NEs. The graph can be used to flood IP-encapsulated PTP or map MS-PW for Ethernet-encapsulated PTP.
Do you think that such transport would be sufficient for 1588-over-MPLS?

Regards,
Greg
On Tue, Nov 22, 2011 at 7:43 AM, Shahram Davari <[email-masked]<mailto:[email-masked]>> wrote:
Hi Sasha,

Thanks
Shahram

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, November 22, 2011 7:38 AM
To: Shahram Davari
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: [TICTOC] FW: I-D Action: draft-ietf-tictoc-1588overmpls-02.txt

Shahram,

Regards,
    Sasha

> From: Shahram Davari [mailto:[email-masked]<mailto:[email-masked]>]
> Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
> From: Alexander Vainshtein [mailto:[email-masked]<mailto:[email-masked]>]
> Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
> > From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf
> > Of Shahram Davari
> > To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
> > Cc: [email-masked]<mailto:[email-masked]>
> > From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf
> > Of Stewart Bryant
> > To: [email-masked]<mailto:[email-masked]>
> > Cc: [email-masked]<mailto:[email-masked]>

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 23 Nov 2011 09:39:52 +0000

On 22/11/2011 20:50, Greg Mirsky wrote:
> discussed, different model. Assume that PTP-capable NEs advertize 
> their capability, i.e. through IGP TE extension, and that MPLS domain 
> is MPLS-TP network. 
Why would you have an IGP running in a -TP domain?

- Stewart

---

From: "Shahram Davari" <[email-masked]>
Date: Wed, 23 Nov 2011 07:10:42 -0800

In case of MPLS-TP if IGP is not used then Management should know the LSR capabilities.

Thx
SD

----- Original Message -----
From: Stewart Bryant [mailto:[email-masked]]
Sent: Wednesday, November 23, 2011 01:39 AM
To: Greg Mirsky <[email-masked]>
Cc: Shahram Davari; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [TICTOC] FW: I-D Action: draft-ietf-tictoc-1588overmpls-02.txt

- Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 24 Nov 2011 15:58:46 +0000

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

---

From: "Shahram Davari" <[email-masked]>
Date: Thu, 24 Nov 2011 08:34:19 -0800

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

- Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 24 Nov 2011 17:29:33 +0000

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:
> To: [email-masked]<[email-masked]>
> Cc: [email-masked]<[email-masked]>; [email-masked]<[email-masked]>

---

From: Yaakov Stein <[email-masked]>
Date: Sat, 26 Nov 2011 20:24:34 +0000

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

- Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Sun, 27 Nov 2011 00:13:00 +0000

Yaakov

I was not thinking of a particularly radical packet type.

A label stack, a 64 bit delay field, and then any timing payload
you like (specific details out of scope for the draft).

The P routers then just add and subtract the current time from
the delay field to update it with the dwell time.

The Edge will know what the timing payload type is and can
make the TC correction based on the delay field.

The important point is that this works for any packet type that
needs to know delay, be that a timing payload such as 1588v2,
1588v3, NTPv4, NTPv5 etc etc. It also as Yaakov notes works
for any other payload type such as a payload that needs to
perform synchronous delivery at multiple disjoint endpoints,
or a 1+1 protection system that is required to provide
synchronied streams etc etc.

- Stewart

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Sun, 27 Nov 2011 06:12:41 +0530

Hi Stewart,

I don't see how this design is better than the one that we have in the current TICTOC WG document. Let me address the objections that you have raised.

1. Layer Violation

Both designs do layer violation. Even yours does, since each LSR has to understand that it's a special MPLS packet and has to deep inspect and modify a few fields in the shim header. I don't think looking at a layer violation is a valid thing to do because transparent clocking by itself is layer violation. Even in the current WG draft if one only implements boundary clocks then there would be no layer violation.

2. Parsing the MPLS payload to determine the kind of packet it is.

In the current WG draft you don't need to parse the packet to determine what needs to be done with it. When the LSP was set up you knew the exact offset at which you had to do your rewrite. The LSR knows exactly what it needs to do when it sees the packet with a specific MPLS label.

While I will agree that the approach that you have suggested will also work and could also be explored. I don't necessarily see ours not working or it breaking the basic tenets of the MPLS. 

Cheers, Manav

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Stewart Bryant
> Sent: Sunday, November 27, 2011 5:43 AM
> To: Yaakov Stein
> Cc: [email-masked]'
> A label stack, a 64 bit delay field, and then any timing 
> payload you like (specific details out of scope for the draft).
> 
> The P routers then just add and subtract the current time 
> from the delay field to update it with the dwell time.
> 
> The important point is that this works for any packet type 
> that needs to know delay, be that a timing payload such as 
> 1588v2, 1588v3, NTPv4, NTPv5 etc etc. It also as Yaakov notes 
> works for any other payload type such as a payload that needs 
> to perform synchronous delivery at multiple disjoint 
> endpoints, or a 1+1 protection system that is required to 
> provide synchronied streams etc etc.
> 
> - 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.
> >
> > (after ensuring that 1588 is supported) and to inform the 
> intermediate 
> > nodes that the particular label value being used is special.
> > 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 
> > 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
> >
> > 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
> >
> >
> >
> >> 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
> >>
> >>
> >>
> >> 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
> >>
> >>
> >>> 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 
> >>> 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
> >>>
> >>>

---

From: "Shahram Davari" <[email-masked]>
Date: Sat, 26 Nov 2011 18:51:44 -0800

Hi Stewart,

Your proposal also does layer violation. TC by nature does layer violation. Advantage of our approach is that it uses existing PW encapsulation, and doesn't require new protocol. 

Your solution can be further explored in a new draft as a more generic solution, noting that requires new protocol and new parsing.  

Thx
Shahram.

----- Original Message -----
From: Stewart Bryant [mailto:[email-masked]]
Sent: Saturday, November 26, 2011 04:13 PM
To: Yaakov Stein <[email-masked]>
Cc: Shahram Davari; [email-masked]' <[email-masked]>
Subject: Re: [TICTOC] FW: I-D Action: draft-ietf-tictoc-1588overmpls-02.txt

Yaakov

- Stewart

---

From: Yaakov Stein <[email-masked]>
Date: Sun, 27 Nov 2011 06:54:54 +0000

Stewart

I proposed precisely this approach at IETF-80
(unfortunately, since becoming AD you haven't been able to attend TICTOC meetings :(  )

The WG decided to proceed with the simpler approach first,
and to consider pursuing the more generic approach after the first one progressed.

I call the present draft "simpler" because it reuses existing encapsulations and 1588 procedures.
It just requires control protocol work and having the LSR recognize a specific label.
The idea is that the specific label triggers some specific processing,
just like specific MAC addresses or IP addresses trigger specific functionality in switches or routers respectively.
(I agree that it is not just a matter of sending the packet up to a CPU for special processing,
since it requires a HW timestamp, but there are several approaches to solving this problem.)

We originally spoke about using a reserved label, 
but feedback from the MPLS WG was that we had little chance of getting such a limited resource.
So the obvious choice was telling the LSR about specific labels.

Since Beijing we have had regular participation of people from the MPLS WG (including George)
and some of the TICTOC regulars, including the draft authors and yours truly, participate in MPLS too.

Y(J)S

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]] 
Sent: Sunday, November 27, 2011 02:13
To: Yaakov Stein
Cc: Shahram Davari; [email-masked]'
Subject: Re: [TICTOC] FW: I-D Action: draft-ietf-tictoc-1588overmpls-02.txt

Yaakov

- Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Sun, 27 Nov 2011 10:13:48 +0000

On 27/11/2011 00:42, Bhatia, Manav (Manav) wrote:
> Both designs do layer violation.
I am not sure it's a layer violation to modify the field immediately after
BOS in a FEC that is defined to carry that field in that way.

> Even yours does, since each LSR has to understand that it's a special MPLS packet
That is the definition of this FEC.
> and has to deep inspect and modify a few fields in the shim header.
One field, located immediately after BOS, which is an offset that is
known when we set up the LSP.
> I don't think looking at a layer violation is a valid thing to do because transparent clocking by itself is layer violation.
Not exactly. We have a new MPLS tunnel that has the property that it 
records the time
taken to traverse the tunnel. We have a tunnel endpoint that knows what 
is going
in and out of the tunnel and can apply the correction directly on the 
payload
or transmit that information along with the payload in some other format.

P routers do not need to explore beyond the first field after BOS and
are entirely agnostic WRT what is carried. It is this agnosticism of payload
type that is central to the design of MPLS.

> Even in the current WG draft if one only implements boundary clocks then there would be no layer violation.
But the draft looks to be about TC not BC.
> In the current WG draft you don't need to parse the packet to determine what needs to be done with it.
So why the long discussion earlier in the thread about how to parse the 
packet?

BTW, the offset mechanism that you propose only provides the start of 
the PTP
header, you have to backtrack to the IP packet to determine if it is v4 
or v6 and
then do forward again to fine the UDP c/s. You could signal all this, 
but I did
not see that text in the draft.

These more complex operations are not really operations that you want do in
a P router.

> When the LSP was set up you knew the exact offset at which you had to do your rewrite. The LSR knows exactly what it needs to do when it sees the packet with a specific MPLS label.
Not quite. You could I suppose provide the offsets of the UDP c/s as 
well in
the control protocol but you have not done that.
> While I will agree that the approach that you have suggested will also work and could also be explored. I don't necessarily see ours not working or it breaking the basic tenets of the MPLS.
No one is saying that yours will not work, it's just more expensive in 
processing
and far less general. So for example, you will not be able to support 
the next gen of
timing protocols without updating all LSRs. The shim method only requires
updating the PEs.

As to whether this breaks the basic tenets of MPLS, that is  a question
that needs to be put to the MPLS WG, and the sooner it goes there
the sooner you will know if you are on solid grounds.

Note that there is a 100% certainly that the draft will need to be Last 
Called
in MPLS WG, so it would be wise for the chairs to request an initial review
early in the process.

- Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Sun, 27 Nov 2011 10:17:08 +0000

On 27/11/2011 02:51, Shahram Davari wrote:
> Hi Stewart,
>
> Your proposal also does layer violation.
Not in a transit time recording FEC. Time recording is a property of the 
FEC.

> TC by nature does layer violation. Advantage of our approach is that it uses existing PW encapsulation, and doesn't require new protocol.
That depends on how it is done.

Recording the transit time and feeding that time along with the
packet into a BC is not LVing.

Also this draft is not just about PW encaps.
> Your solution can be further explored in a new draft as a more generic solution, noting that requires new protocol and new parsing.
Compared to existing P routers you require new protocol and new parsing.

Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Sun, 27 Nov 2011 10:24:33 +0000

> (unfortunately, since becoming AD you haven't been able to attend TICTOC meetings :(  )
Yes and understand that I am not participating in this
discussion as an AD, other than on one specific process point:
i.e. to advise you to get a formal signoff that the MPLS WG are
cool with this.

> The idea is that the specific label triggers some specific processing,
This we need with any approach, and is a cool idea.
> So the obvious choice was telling the LSR about specific labels.
This bit I like and should be carried forward.
> and some of the TICTOC regulars, including the draft authors and yours truly, participate in MPLS too.

That is not the same as presenting this at MPLS WG (which I do not think has
happened yet) or asking for a review by the MPLS WG.

- Stewart

---

From: "Shahram Davari" <[email-masked]>
Date: Sun, 27 Nov 2011 07:13:28 -0800

Hi Stewart, 

looking or modifying anything beyond the top label is technically LV in MPLS. The only difference your approach has is that it doesn't need the offset to update the CF field, but the drawback is that it requires new protocol.

Note that the offset provided in Signaling is to the start of PTP PDU after all IP, UDP or Ethernet encapsulation and doesn't need to track it back to find out what is the encapsulation.

Thx
Shahram

Thx
Shahram

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

Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Sun, 27 Nov 2011 15:17:38 +0000

>  Note that the offset provided in Signaling is to the start of PTP PDU after all IP, UDP or Ethernet encapsulation and>  doesn't need to track it back to find out what is the encapsulation.

How do you do the IPv6 UDP c/s correction without looking further back?

Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Sun, 27 Nov 2011 15:19:42 +0000

> Note that the offset provided in Signaling is to the start of PTP PDU after all IP, UDP or Ethernet encapsulation and doesn't need to track it back to find out what is the encapsulation.
Ah well that gets to the question of why you are carrying the L2/L3 
headers at all?

All that is needed is the PTP payload itself.

Stewart

---

From: "Shahram Davari" <[email-masked]>
Date: Sun, 27 Nov 2011 09:24:31 -0800

Good question. Two answers:

1) Doing so, means we can reuse existing  encapsulation

2) Doing do enables us tunneling PTP messages.

Thx
Shahram

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

Stewart

---

From: Gregory Mirsky <[email-masked]>
Date: Mon, 28 Nov 2011 14:28:52 -0500

Dear Shahram, et al.,
I think that adding MPLS WG to the discussion is helpful. Thus I'll take the liberty to copy to the list.
And I don't agree that combination of TC transport over MPLS domain with clock distribution within it inherently creates layer violation. As I've mentioned, PTP can be distributed over PSN that interconnects 1588-capable nodes if IP encapsulation used or as MS-PW if Ethernet encapsulation used.

	Regards,
		Greg

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

Hi Stewart,

Thx
Shahram.

----- Original Message -----
From: Stewart Bryant [mailto:[email-masked]]
Sent: Saturday, November 26, 2011 04:13 PM
To: Yaakov Stein <[email-masked]>
Cc: Shahram Davari; [email-masked]' <[email-masked]>
Subject: Re: [TICTOC] FW: I-D Action: draft-ietf-tictoc-1588overmpls-02.txt

Yaakov

A label stack, a 64 bit delay field, and then any timing payload you like (specific details out of scope for the draft).

The P routers then just add and subtract the current time from the delay field to update it with the dwell time.

The Edge will know what the timing payload type is and can make the TC correction based on the delay field.

The important point is that this works for any packet type that needs to know delay, be that a timing payload such as 1588v2, 1588v3, NTPv4, NTPv5 etc etc. It also as Yaakov notes works for any other payload type such as a payload that needs to perform synchronous delivery at multiple disjoint endpoints, or a 1+1 protection system that is required to provide synchronied streams etc etc.

- Stewart

On 26/11/2011 20:24, Yaakov Stein wrote:
> 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.
>
> (after ensuring that 1588 is supported) and to inform the intermediate 
> higher field), but correcting a field inside 1588 in UDP in IP in MPLS 
> 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
>
> I will ponder the answer to this question, but will note that you have 
>> 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, 
>> Does the WG have any input to suggest that the design will survive a 
>>> understanding why it is necessary to have quite the egregious layer 
>>> violation that this draft uses.
>>>
>>> time of passage through the network is a good idea. However MPLS is 
>>> The function that you require could be achieved by including a shim 
>>> payload on egress from the LSP. That would be rather more consistent 
>>> 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 
>>> 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
>>>
>>>

---

From: Gregory Mirsky <[email-masked]>
Date: Mon, 28 Nov 2011 14:53:26 -0500

Dear Stewart,
I think that at least in case of MPLS PTN any modification of client data constitutes layer violation. 

	Regards,
		Greg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stewart Bryant
Sent: Sunday, November 27, 2011 2:14 AM
To: Bhatia, Manav (Manav)
Cc: [email-masked]'
Subject: Re: [TICTOC] FW: I-D Action: draft-ietf-tictoc-1588overmpls-02.txt

> Both designs do layer violation.
I am not sure it's a layer violation to modify the field immediately after BOS in a FEC that is defined to carry that field in that way.

> and has to deep inspect and modify a few fields in the shim header.
One field, located immediately after BOS, which is an offset that is known when we set up the LSP.
> I don't think looking at a layer violation is a valid thing to do because transparent clocking by itself is layer violation.
Not exactly. We have a new MPLS tunnel that has the property that it records the time taken to traverse the tunnel. We have a tunnel endpoint that knows what is going in and out of the tunnel and can apply the correction directly on the payload or transmit that information along with the payload in some other format.

P routers do not need to explore beyond the first field after BOS and are entirely agnostic WRT what is carried. It is this agnosticism of payload type that is central to the design of MPLS.

> In the current WG draft you don't need to parse the packet to determine what needs to be done with it.
So why the long discussion earlier in the thread about how to parse the packet?

BTW, the offset mechanism that you propose only provides the start of the PTP header, you have to backtrack to the IP packet to determine if it is v4 or v6 and then do forward again to fine the UDP c/s. You could signal all this, but I did not see that text in the draft.

These more complex operations are not really operations that you want do in a P router.

> When the LSP was set up you knew the exact offset at which you had to do your rewrite. The LSR knows exactly what it needs to do when it sees the packet with a specific MPLS label.
Not quite. You could I suppose provide the offsets of the UDP c/s as well in the control protocol but you have not done that.
> While I will agree that the approach that you have suggested will also work and could also be explored. I don't necessarily see ours not working or it breaking the basic tenets of the MPLS.
No one is saying that yours will not work, it's just more expensive in processing and far less general. So for example, you will not be able to support the next gen of timing protocols without updating all LSRs. The shim method only requires updating the PEs.

As to whether this breaks the basic tenets of MPLS, that is  a question that needs to be put to the MPLS WG, and the sooner it goes there the sooner you will know if you are on solid grounds.

Note that there is a 100% certainly that the draft will need to be Last Called in MPLS WG, so it would be wise for the chairs to request an initial review early in the process.

- Stewart

---

From: Anthony Magee <[email-masked]>
Date: Tue, 29 Nov 2011 18:35:49 +0000

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

---

From: Ron Cohen <[email-masked]>
Date: Tue, 29 Nov 2011 23:00:46 +0200

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:

> 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
>
>
> Of Yaakov Stein
> 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.
>
> 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.
>
> 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 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
>
>
>
> > 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: Greg Mirsky <[email-masked]>
Date: Tue, 29 Nov 2011 13:08:53 -0800

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:

>> 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
>>
>>
>> not addressed my second question which relates to whether there is MPLS WG

---

From: Lars Ellegaard <[email-masked]>
Date: Tue, 29 Nov 2011 21:12:17 +0000

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

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

On 24/11/2011 16:34, Shahram Davari wrote:
> 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]>>

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: Greg Mirsky <[email-masked]>
Date: Tue, 29 Nov 2011 13:14:58 -0800

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:

> *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,
> > Cc: [email-masked]<[email-masked]>;
>
> > [email-masked]<[email-masked]>
> *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: Tue, 29 Nov 2011 21:26:56 +0000

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

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: Tue, 29 Nov 2011 23:28:26 +0200

Since the approach is that the LSP is signaled as timing-only LSP, PTP can
be carried on its own PW hop by hop. The point is that the layer violation
is in the assumption that the Ethernet PW/ IP over MPLS runs end to end and
the TC fiddles with the PTP bits in mid transit. If the circuits are
terminated and regenerated at the TC there is no layer violation.

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 29 Nov 2011 13:33:04 -0800

Hi Ron,
I agree with your model. It is similar to one I've suggested to consider
earlier in our discussion. I think that in this model there's nothing
"special" about LSP as it connects TC-capable NEs and no DPI or payload
modification required by LSRs.

Regards,
Greg

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

> On Tue, Nov 29, 2011 at 11:08 PM, Greg Mirsky <[email-masked]>wrote:
>
>> Dear Ron,
>>> If the encapsulation was directly over MPLS, i.e. no Ethernet / IP
>>> layers in between MPLS and PTP, there were no layers to violate....
>>>
>>>
>>>> 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
>>>> 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.
>>>>
>>>> thus can solve other problems), but requires inventing yet another timing
>>>> distribution protocol.
>>>> > 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.
>>>> >
>>>> >

---

From: "Shahram Davari" <[email-masked]>
Date: Tue, 29 Nov 2011 14:20:17 -0800

Ron,

If the LSP is not terminated at a hop and any field inside the packet is updated, that to me is a LV. Unless you are proposing to create one hop LSPs and stitch them together, which I don't think is practical.

1588 over Ethernet and IP updates CRC and HECs and why can't the same be done in mpls.

Thx
SD

Thx
Shahram

From: Ron Cohen [mailto:[email-masked]]
Sent: Tuesday, November 29, 2011 01:28 PM
To: Greg Mirsky <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [TICTOC] FW: I-D Action: draft-ietf-tictoc-1588overmpls-02.txt

Since the approach is that the LSP is signaled as timing-only LSP, PTP can be carried on its own PW hop by hop. The point is that the layer violation is in the assumption that the Ethernet PW/ IP over MPLS runs end to end and the TC fiddles with the PTP bits in mid transit. If the circuits are terminated and regenerated at the TC there is no layer violation.

On Tue, Nov 29, 2011 at 11:08 PM, Greg Mirsky <[email-masked]<mailto:[email-masked]>> wrote:
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

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: Wed, 30 Nov 2011 07:05:48 +0200

Hi Shahram, In 1588 over Ethernet the decision was to terminate at any hop
(and hence update the source Ethernet MAC address at each TC) in order not
to violate layerings. To be precise, this was the decision taken by
802.1(AS) members that use the 802.1 baggy pants layer model and insisted
on correct layer processing. The 1588 group was not that strict on
layering, and the IP encapsulation TC implementation 'breaks the layers'
and updates the PTP field while not updating the source IP address - this
is similar to other IP applications like NAT etc.
Here in PTP over MPLS we are free to make our own decision; if we want to
preserve the layering model we should indeed terminate the LSP at each hop
(yes, stitching the LSP together - what's wrong about it?, we need to
control the path at each hop to set it across the timing enabled LSRs
anyhow), or we can keep the current proposal that setups end to end LSPs
and use DPI/Break layers, which is ok too. I personally thought (and still
think) that a non-breaking PTP over MPLS encapsulation is a needed option,
and since the LSP is terminated at each hop in this option I didn't see any
logic to add additional Ethernet/IP layers between the MPLS and PTP layers.
I thought that this would also fit in well with ITU's more-strict layer
modeling. However, at least at that time, ITU sync experts didn't see the
need for running PTP over MPLS for distribution of timing within a provider
(which is the problem they were interested in), and the problem mainly
addressed by the IETF (as I understand it) is to carry multiple timing
streams (not necessarily synched to each other) over a
'carrier-of-carriers' that will still provide TC functionality (See my
presentation in TICTOC from the IETF in the Netherlands a while back), and
for this problem setting end to end LSPs seems to be the right approach
(and hence 'breaking the layers'). So basically it depends which problem
you want to solve and how strict we want to be with regards to layering.
Best, Ron

On Wed, Nov 30, 2011 at 12:20 AM, Shahram Davari <[email-masked]>wrote:

> Ron,
>
> If the LSP is not terminated at a hop and any field inside the packet is
> updated, that to me is a LV. Unless you are proposing to create one hop
> LSPs and stitch them together, which I don't think is practical.
>
>  *From*: Ron Cohen [mailto:[email-masked]]
> *Sent*: Tuesday, November 29, 2011 01:28 PM
> *To*: Greg Mirsky <[email-masked]>
> *Cc*: [email-masked] <[email-masked]>
> *Subject*: Re: [TICTOC] FW: I-D Action:

---

From: "Shahram Davari" <[email-masked]>
Date: Tue, 29 Nov 2011 21:32:45 -0800

Hi Ron,

I completely agree with your statement. So may be we should introduce 2 models:

1) Intra-SP timing
2) Inter-SP timing (requires tunneling)

First model can use Multi-segment LSPs, and second model can use single segment LSP.

Regards
Shahram

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

Hi Shahram, In 1588 over Ethernet the decision was to terminate at any hop (and hence update the source Ethernet MAC address at each TC) in order not to violate layerings. To be precise, this was the decision taken by 802.1(AS) members that use the 802.1 baggy pants layer model and insisted on correct layer processing. The 1588 group was not that strict on layering, and the IP encapsulation TC implementation 'breaks the layers' and updates the PTP field while not updating the source IP address - this is similar to other IP applications like NAT etc.
Here in PTP over MPLS we are free to make our own decision; if we want to preserve the layering model we should indeed terminate the LSP at each hop (yes, stitching the LSP together - what's wrong about it?, we need to control the path at each hop to set it across the timing enabled LSRs anyhow), or we can keep the current proposal that setups end to end LSPs and use DPI/Break layers, which is ok too. I personally thought (and still think) that a non-breaking PTP over MPLS encapsulation is a needed option, and since the LSP is terminated at each hop in this option I didn't see any logic to add additional Ethernet/IP layers between the MPLS and PTP layers. I thought that this would also fit in well with ITU's more-strict layer modeling. However, at least at that time, ITU sync experts didn't see the need for running PTP over MPLS for distribution of timing within a provider (which is the problem they were interested in), and the problem mainly addressed by the IETF (as I understand it) is to carry multiple timing streams (not necessarily synched to each other) over a 'carrier-of-carriers' that will still provide TC functionality (See my presentation in TICTOC from the IETF in the Netherlands a while back), and for this problem setting end to end LSPs seems to be the right approach (and hence 'breaking the layers'). So basically it depends which problem you want to solve and how strict we want to be with regards to layering. Best, Ron

On Wed, Nov 30, 2011 at 12:20 AM, Shahram Davari <[email-masked]<mailto:[email-masked]>> wrote:
Ron,

Thx
SD

Thx
Shahram

From: Ron Cohen [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, November 29, 2011 01:28 PM
To: Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: Re: [TICTOC] FW: I-D Action: draft-ietf-tictoc-1588overmpls-02.txt

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: Greg Mirsky <[email-masked]>
Date: Tue, 29 Nov 2011 21:49:33 -0800

Hi Ron,
you've said:
"Here in PTP over MPLS we are free to make our own decision ..."
If by "we" you understand TICTOC WG, then I think I strongly disagree. As
Stewart pointed out the MPLS WG must review and agree to the proposed
mechanism. Thus "we" is the IETF. And even if proposed mechanism to be
accepted then it would not be applicable to Packet Transport Networks as
these are clearly do not allow Layer Violation.

Regards,
Greg

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

>> Since the approach is that the LSP is signaled as timing-only LSP, PTP
>> can be carried on its own PW hop by hop. The point is that the layer
>> violation is in the assumption that the Ethernet PW/ IP over MPLS runs end
>> to end and the TC fiddles with the PTP bits in mid transit. If the circuits
>> are terminated and regenerated at the TC there is no layer violation.
>>
>>>>> > This draft has been implemented by vendors, so we have a working
>>>>> code and I believe we also have rough consensus.
>>>>> >
>>>>> > Thanks
>>>>> > Shahram
>>>>> >
>>>>> >
>>>>> >
>>>>> time
>>>>> it

---

From: Ron Cohen <[email-masked]>
Date: Wed, 30 Nov 2011 09:30:22 +0200

Hi Greg, I'm with you. In 'we' I meant the IETF as a standard body, not the
TICTOC WG. The 1588 group delegated the definition of 1588-over-Foo to the
standard body that is responsible for the 'Foo' transport. Since I believe
IETF has the responsibility for 'Foo'=MPLS, its the IETF decision how to
standardize the processing of PTP over MPLS and whether to define a
specific PTP-over-MPLS encapsulation. Best, Ron

On Wed, Nov 30, 2011 at 7:49 AM, Greg Mirsky <[email-masked]> wrote:

>> Hi Shahram, In 1588 over Ethernet the decision was to terminate at any
>> hop (and hence update the source Ethernet MAC address at each TC) in order
>> not to violate layerings. To be precise, this was the decision taken by
>>>> On Tue, Nov 29, 2011 at 1:00 PM, Ron Cohen <[email-masked]>wrote:
>>>>
>>>>> On Tue, Nov 29, 2011 at 8:35 PM, Anthony Magee <[email-masked]
>>>>> > wrote:
>>>>>
>>>>>> Hi Yaakov,
>>>>>>
>>>>>> 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
>>>>>>
>>>>>> 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
>>>>>> > 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.
>>>>>> >