Subject: [TICTOC] PTP over MPLS draft

From: Yaakov Stein <[email-masked]>
Date: Wed, 1 Aug 2012 20:58:19 +0000

Shahram,

Karen just remarked to me that with the draft becoming more generic,
the new version really needs to be renamed something like
"Transporting Timing Flows over MPLS".

Y(J)S

---

From: Yaakov Stein <[email-masked]>
Date: Wed, 1 Aug 2012 21:10:50 +0000

During today's TICTOC meeting I raised the following questions. We need your feedback on these questions in order to progress this draft.

  1.  Should CW be mandatory?
     *   If not, then a PTP-LSP needs to carry only one type of PW (either with CW or without CW) but not mix so that LSRs can correctly parse the packet
     *
     *   Without PW the job of LSRs becomes more complex to identify the OAM packets
[YJS] I believe that it is fine to require a CW. RFC 5994 makes the CW mandatory for Ethernet PWs over MPLS-TP,
I believe that TP will be the main use case.

  1.  Should ECMP/Entropy be disallowed?
     *   The current consensus is yes, no ECMP or Entropy shall be used.
[YJS] entropy labels should be disallowed.
Obviously timing flows should in general should not be shifted from one path
to another path with different delay, if undetected the delay jump will cause
an accumulating phase error.
I understand that with TC this point is less important, but this draft explicitly speaks of only partial on-path support.

Should PHP (Penultimate Hop Popping) be allowed?
[YJS] Once again, if the main use case is MPLS-TP, then this may be automatic

  1.  How to transport 1588 messages that don't need TS or CF update?
     *   Send them over non-PTP LSP?
     *   Let the LSRs do the parsing and perform TS or CF updated based on message type?
[YJS] They should be sent over the same PW.
Since the setup specifies the timing flow type,
the regular 1588 parser will be called anyway.

  1.  Should P2MP LSP & P2MP PW be supported?
[YJS] No strong opinion.

  1.  Should protection be supported for PTP-LSP?
     *   FRR, 1:1 and 1+1
[YJS] Similar to my response above, protection should NOT be supported,
as a change of path means a change in delay, which if undetected can be worse than losing the timing flow
and going into holdover.

  1.  How does LSP/PW connectivity failure interact with 1588?
     *   Does the Slave select another master when a failure happens?
     *   Can the protection make the failure invisible to Salve clock?
[YJS] b. should never be allowed. a. is a configuration option.

  1.  Should only VCCV1 and VCCV4 be allowed?
     *   If not then the VCCV type needs to be the same for all PW in the PTP-LSP so that LSRs can correctly parse the packet
[YJS] We are presently in the process of obsoleting type 2 anyway.
So we are left with the issue of type 3, which is mostly for MS-PWs.
Do you see this being used for the MS case ?

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 01 Aug 2012 22:17:53 +0100

> [YJS] Once again, if the main use case is MPLS-TP, then this may be 
Wrong way about.

MPLS-TP does not support PHP.

You should not all PHP of these LSP'S since you need to trap these pkts 
in the receiving PE

- Stewart

---

From: "Shahram Davari" <[email-masked]>
Date: Wed, 1 Aug 2012 21:20:18 +0000

Hi Yaakov,

Yes, that is what I had in mind as well.

Thx
SD

From: Yaakov Stein [mailto:[email-masked]]
Sent: Wednesday, August 01, 2012 1:58 PM
To: Shahram Davari; [email-masked]
Subject: PTP over MPLS draft

Shahram,

Y(J)S

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 01 Aug 2012 22:21:09 +0100

On 01/08/2012 22:17, Stewart Bryant wrote:
> You should not all PHP of these LSP'S since you need to trap these 
> pkts in the receiving PE
>
> - Stewart

That last incoherent sentence should read, that you cannot PHP since you 
need
to trap these packets at the ingress PE.

This also means that you can avoid burning the limited number of PTP labels
by allocating them to both LSP and PW.

Stewart

---

From: Yaakov Stein <[email-masked]>
Date: Wed, 1 Aug 2012 21:28:19 +0000

Stewart

Sorry for the unfortunate wording on my part.

What I meant is that automatically you DON'T have PHPing.

So I think we are in agreement.

Y(J)S

From: Stewart Bryant [mailto:[email-masked]]
Sent: Thursday, August 02, 2012 00:18
To: Yaakov Stein
Cc: Shahram Davari; [email-masked]
Subject: Re: [TICTOC] Questions regaridng 1588 over MPLS

You should not all PHP of these LSP'S since you need to trap these pkts in the receiving PE

- Stewart

---

From: "Shahram Davari" <[email-masked]>
Date: Wed, 1 Aug 2012 21:30:04 +0000

Yaakov,

This brings an interesting question. Can we say UDP/IP encap is for MPLS and PW Encap is for MPLS-TP?

Thx
SD

From: Yaakov Stein [mailto:[email-masked]]
Sent: Wednesday, August 01, 2012 2:28 PM
To: [email-masked]
Cc: Shahram Davari; [email-masked]
Subject: RE: [TICTOC] Questions regaridng 1588 over MPLS

Stewart

Y(J)S

- Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 01 Aug 2012 22:30:31 +0100

> So I think we are in agreement.
Approximately, I don't see why we wouldn't forbid PHP.

Stewart

---

From: Gregory Mirsky <[email-masked]>
Date: Wed, 1 Aug 2012 17:43:52 -0400

Dear Yaakov, Sharham, et al.,
________________________________
Should CW be mandatory?

 1.

GIM>> I think that with upcoming introduction of PW VCCV CC Type 4 requirement to use CW, Section 2 of RFC 5994, can be relaxed. As result use of CW in MPLS-TP PW can not be expected.

    Regards,
        Greg

---

From: "Meyer, Peter" <[email-masked]>
Date: Tue, 14 Aug 2012 11:20:43 -0400

Hi Shahram,

I think another topic that would be good to progress was discussed on
the exploder in March -- how to handle packets that do not flow through
the network element, but are generated & terminated each node (e.g.
peer-delay messages).  These packets (similar to point 3 below) may be
event or general messages.  Refer to last e-mail of chain on March 22,
subject "[TICTOC] Updated 1588 over MPLS draf-03".

Regards,

Peter

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Yaakov Stein
Sent: August 1, 2012 5:11 PM
To: Shahram Davari; [email-masked]
Subject: Re: [TICTOC] Questions regaridng 1588 over MPLS

During today's TICTOC meeting I raised the following questions. We need
your feedback on these questions in order to progress this draft.

	a.	If not, then a PTP-LSP needs to carry only one type of
PW (either with CW or without CW) but not mix so that LSRs can correctly
parse the packet 
	b.	 
	c.	Without PW the job of LSRs becomes more complex to
identify the OAM packets 

[YJS] I believe that it is fine to require a CW. RFC 5994 makes the CW
mandatory for Ethernet PWs over MPLS-TP,

2.	Should ECMP/Entropy be disallowed? 

	a.	The current consensus is yes, no ECMP or Entropy shall
be used. 

Obviously timing flows should in general should not be shifted from one
path

to another path with different delay, if undetected the delay jump will
cause

I understand that with TC this point is less important, but this draft
explicitly speaks of only partial on-path support.

[YJS] Once again, if the main use case is MPLS-TP, then this may be
automatic

3.	How to transport 1588 messages that don't need TS or CF update? 

	a.	Send them over non-PTP LSP? 
	b.	Let the LSRs do the parsing and perform TS or CF updated
based on message type? 

4.	Should P2MP LSP & P2MP PW be supported? 

[YJS] No strong opinion.

5.	Should protection be supported for PTP-LSP? 

	a.	FRR, 1:1 and 1+1 

as a change of path means a change in delay, which if undetected can be
worse than losing the timing flow

and going into holdover.

6.	How does LSP/PW connectivity failure interact with 1588? 

	a.	Does the Slave select another master when a failure
happens? 
	b.	Can the protection make the failure invisible to Salve
clock? 

7.	Should only VCCV1 and VCCV4 be allowed? 

	a.	If not then the VCCV type needs to be the same for all
PW in the PTP-LSP so that LSRs can correctly parse the packet