Subject: Re: [TICTOC] Transporting PTP messages (1588) over MPLS Networks

From: [email-masked]
Date: Tue, 18 Jan 2011 20:32:49 +0800

Hi Manav,
In section 8 ECMP, since it is said PTP LSPs and PWs MUST NOT be subject 
to ECMP, why in section 5.2 the encapsulation of figure 2 has entroy 
label? I am a bit confused.

Regards
Lizhong

> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Sat, 15 Jan 2011 16:25:59 +0530
> From: "Bhatia, Manav (Manav)" <[email-masked]>
> Subject: [TICTOC] Transporting PTP messages (1588) over MPLS Networks
> To: "[email-masked]" <[email-masked]>
> Message-ID:
>    <[email-masked].
> alcatel-lucent.com>
> 
> Content-Type: text/plain; charset="us-ascii"
> 
> Hi,
> 
> We have posted a revised version of draft-davari-
> tictoc-1588overmpls-01 and would appreciate a feedback from the WG.
> 
> The draft is available here:
> http://www.ietf.org/id/draft-davari-tictoc-1588overmpls-01.txt
> 
> Cheers, Manav
> 
> --
> Manav Bhatia,
> IP Division, Alcatel-Lucent,
> Bangalore - India
> 
> 
> 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Wed, 26 Jan 2011 22:58:48 +0530

Hi Lizhong,

You can only ensure that 1588aware LSRs will not do ECMP on PTP LSPs. What if we have a non-1588aware LSR in the path? The head end when setting up the RSVP path would know this (by inspecting the IS-IS or OSPF TE info) and could in such cases make use of the Entropy label to ensure that all PTP packets follow the same path. This is one scenario where i think we may want to use Entropy labels.

Cheers, Manav

________________________________
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, January 18, 2011 6.03 PM
To: Bhatia, Manav (Manav)
Cc: [email-masked]
Subject: Re: [TICTOC] Transporting PTP messages (1588) over MPLS Networks

Hi Manav,
In section 8 ECMP, since it is said PTP LSPs and PWs MUST NOT be subject to ECMP, why in section 5.2 the encapsulation of figure 2 has entroy label? I am a bit confused.

Regards
Lizhong

---

From: [email-masked]
Date: Thu, 27 Jan 2011 11:24:36 +0800

Hi Manav,
I don't think I fully understand and need some clarification. See in line.

Thanks.
Lizhong

"Bhatia, Manav (Manav)" <[email-masked]> wrote on 
2011-01-27 01:28:48:

> Hi Lizhong,
> 
> You can only ensure that 1588aware LSRs will not do ECMP on PTP 
> LSPs. What if we have a non-1588aware LSR in the path? 
[Lizhong] All the LSRs and LERs along PTP LSP MUST be 1588aware, right?

>The head end 
> when setting up the RSVP path would know this (by inspecting the IS-
> IS or OSPF TE info) and could in such cases make use of the Entropy 
> label to ensure that all PTP packets follow the same path. 
[Lizhong] How to use entropy label to ensure all PTP packets follow the 
same path? If there is entropy label, it is possible that the forward and 
reverse path would be different.

>This is 
> one scenario where i think we may want to use Entropy labels.
> 
> Cheers, Manav
> 

> 
> Hi Manav, 
> In section 8 ECMP, since it is said PTP LSPs and PWs MUST NOT be 
> subject to ECMP, why in section 5.2 the encapsulation of figure 2 
> has entroy label? I am a bit confused. 
> 
> Regards 
> Lizhong 
> 
> 
> ZTE Information Security Notice: The information contained in this 
> mail is solely property of the sender's organization. This mail 
> communication is confidential. Recipients named above are obligated 
> to maintain secrecy and are not permitted to disclose the contents 
> of this communication to others.
> This email and any files transmitted with it are confidential and 
> intended solely for the use of the individual or entity to whom they
> are addressed. If you have received this email in error please 
> notify the originator of the message. Any views expressed in this 
> message are those of the individual sender.

---

From: Manav Bhatia <[email-masked]>
Date: Thu, 27 Jan 2011 09:29:38 +0530

Hi Lizhong,

> [Lizhong] All the LSRs and LERs along PTP LSP MUST be 1588aware, right?

In an ideal world Yes, all routers would be 1588aware. However, this 
being far from an ideal world, you can always have some LSRs that are 
not draft-ietf-tictoc-1588overmpls aware. You will note that this draft 
also has some text on the non 1588aware LSRs. These LSRs could be doing 
ECMP and without an entropy label, may cause PTP messages to be load 
distributed across different paths.

> same path?

Using an entropy label will ensure that all PTP packets in one direction 
follow the same path.

> If there is entropy label, it is possible that the forward
> and reverse path would be different.

Since LSPs are unidirectional there is no guarantee that the two paths 
would be symmetrical. So this really is an issue orthogonal to the use 
of entropy labels for carrying PTP traffic.

We should probably add some text in the draft that says that the two 
paths must be symmetrical.

Cheers, Manav

---

From: [email-masked]
Date: Thu, 27 Jan 2011 15:21:47 +0800

Hi Manav,
See my comments in line.

Thanks
Lizhong

Manav Bhatia <[email-masked]> wrote on 2011-01-27 

> distributed across different paths.
[Lizhong] then in section 13, it is said: "This capability MUST then be 
taken into account during path computation to prefer nodes that advertise 
themselves as 1588-aware, so that the PTP LSPs can be properly handled." 
How to understand "prefer nodes"? If there is a shortest path with some 
non 1588aware LSRs, and a less optimal path with all 1588aware LSRs, which 
path the ingress LER should take?

> follow the same path.
[Lizhong] since control word is required for 1588 over PW encapsulation, 
if without entropy label, all PTP packets in one direction will also 
follow the same path.

> paths must be symmetrical.
[Lizhong] If there is a boundled interface between two LSRs, the control 
plane will only see one logical interface. Then it is still possible the 
forward and reverse path be different at the physical level in ECMP case.

> > ZTE  Information  Security  Notice:  The  information  contained 
> in  this  mail  is  solely  property  of  the  sender's 
> organization.  This  mail  communication  is  confidential. 
> Recipients  named  above  are  obligated  to  maintain  secrecy  and
> are  not  permitted  to  disclose  the  contents  of  this 
> communication  to  others.
> > This  email  and  any  files  transmitted  with  it  are 
> confidential  and  intended  solely  for  the  use  of  the 
> individual  or  entity  to  whom  they  are  addressed.  If  you 
> have  received  this  email  in  error  please  notify  the 
> originator  of  the  message.  Any  views  expressed  in  this

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Thu, 27 Jan 2011 16:03:17 +0530

Hi Lizhong,

> distributed across different paths.
[Lizhong] then in section 13, it is said: "This capability MUST then be taken into account during path computation to prefer nodes that advertise themselves as 1588-aware, so that the PTP LSPs can be properly handled." How to understand "prefer nodes"? If there is a shortest path with some non 1588aware LSRs, and a less optimal path with all 1588aware LSRs, which path the ingress LER should take?

[Manav] There is nothing new here and it happens all the time while computing CSPF. You pick the path which satisfies your contraints. Now, if you want a path with all 1588aware LSRs then thats precisely what CSPF will return you. If you want to insist on a shorter path then you need to add other constraints in addition to this.

> Using an entropy label will ensure that all PTP packets in one direction
[Lizhong] since control word is required for 1588 over PW encapsulation, if without entropy label, all PTP packets in one direction will also follow the same path.

[Manav] I think we must use a stronger language in Sec 5.2 regarding using control word. I think i will concur with you here that if CW is being used then we may not need an entropy label. However, i dont see a strong reason why we should restrict it. The current draft says that control word usage is optional and i dont find any issue with that. Do you?

> paths must be symmetrical.
[Lizhong] If there is a boundled interface between two LSRs, the control plane will only see one logical interface. Then it is still possible the forward and reverse path be different at the physical level in ECMP case.

[Manav] Is the assumption that the two ends of LAG could be connected to two different systems, something like a multi-chassis lag? I am not sure if there is much that we can do about this except add a note against such a form of load distribution in the document.

Cheers, Manav

---

From: [email-masked]
Date: Fri, 28 Jan 2011 00:17:48 +0800

Manav,
See comments in line.

Lizhong

2011-01-27 18:33:17:

> [Lizhong] then in section 13, it is said: "This capability MUST then
> be taken into account during path computation to prefer nodes that 
> advertise themselves as 1588-aware, so that the PTP LSPs can be 
> properly handled." How to understand "prefer nodes"? If there is a 
> shortest path with some non 1588aware LSRs, and a less optimal path 
> with all 1588aware LSRs, which path the ingress LER should take? 
> 
> [Manav] There is nothing new here and it happens all the time while 
> computing CSPF. You pick the path which satisfies your contraints. 
> Now, if you want a path with all 1588aware LSRs then thats precisely
> what CSPF will return you. If you want to insist on a shorter path 
> then you need to add other constraints in addition to this.
[Lizhong] OK, I see. Actually my first impression is that it is a bit 
difficult to define such policy for CSPF, in order to fullfill the timing 
accuracy.

> [Lizhong] since control word is required for 1588 over PW 
> encapsulation, if without entropy label, all PTP packets in one 
> direction will also follow the same path. 
> 
> [Manav] I think we must use a stronger language in Sec 5.2 regarding
> using control word. I think i will concur with you here that if CW 
> is being used then we may not need an entropy label. However, i dont
> see a strong reason why we should restrict it. The current draft 
> says that control word usage is optional and i dont find any issue 
> with that. Do you?
[Lizhong] the current draft says control word SHOULD be used. And yes, 
stronger language is welcome.

> [Lizhong] If there is a boundled interface between two LSRs, the 
> control plane will only see one logical interface. Then it is still 
> possible the forward and reverse path be different at the physical 
> level in ECMP case. 
> 
> [Manav] Is the assumption that the two ends of LAG could be 
> connected to two different systems, something like a multi-chassis 
> lag? I am not sure if there is much that we can do about this except
> add a note against such a form of load distribution in the document.
[Lizhong] I mean the LAG between two end-points, not MC-LAG. E.g, one LAG 
interface with physical link A & B between two end-points, it is possible 
that the forward path will go through A, and backward path will go through 
B, then the physical path is not symmetric. If I understand correctly, you 
just assume the transport delay on link A & B are the same, but this is 
not always true, especially for the composite link defined in RTGWG (
draft-ietf-rtgwg-cl-requirement).

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Fri, 28 Jan 2011 05:39:50 +0530

Lizhong,
 
> [Lizhong] I mean the LAG between two end-points, 
> not MC-LAG. E.g, one LAG interface with physical link 
> A & B between two end-points, it is possible that the forward 
> path will go through A, and backward path will go through B, 
> then the physical path is not symmetric. If I understand correctly, 
> you just assume the transport delay on link A & B are the 

On an ordinary lag, unless it's a MC-LAG this can be assumed to be more or less the same.

> same, but this is not always true, especially for the composite 
> link defined in RTGWG (draft-ietf-rtgwg-cl-requirement). 

I quickly glanced through this draft and these can imo be easily avoided by defining a new link type - Composite link, in the link type sub-TLV of Link TLV in OSPF [RFC3630]. Such links MUST be avoided for setting up the PTP LSPs. Similarly the extended IS reachability TLV could be extended for IS-IS to avoid composite links.

One could also use coloring to avoid these links, but this would entail manual configuration which may not be desirable.

Cheers, Manav

---

From: [email-masked]
Date: Mon, 31 Jan 2011 08:39:46 +0800

Hi Manav,
I see the discussion at RTGWG, it is good.
Share within TICTOC: 
http://www.ietf.org/mail-archive/web/rtgwg/current/msg03181.html

Thanks
Lizhong

2011-01-28 08:09:50:

> I quickly glanced through this draft and these can imo be easily 
> avoided by defining a new link type - Composite link, in the link 
> type sub-TLV of Link TLV in OSPF [RFC3630]. Such links MUST be 
> avoided for setting up the PTP LSPs. Similarly the extended IS 
> reachability TLV could be extended for IS-IS to avoid composite links.
> 
> One could also use coloring to avoid these links, but this would 
> entail manual configuration which may not be desirable.
> 
> Cheers, Manav
>

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Mon, 31 Jan 2011 07:37:55 +0530

Hi Lizhong,

As a result of this discussion the RTGWG will add another requirement where the solution should be able to indicate to a composite link that both the directions of a bidirectional LSP must be bound to the same component link.

This is indeed what we want for 1588. We will also include a pointer to this in the next revision.

Cheers, Manav

________________________________
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, January 31, 2011 6.10 AM
To: Bhatia, Manav (Manav)
Cc: [email-masked]
Subject: RE: [TICTOC] Transporting PTP messages (1588) over MPLS Networks

Hi Manav,
I see the discussion at RTGWG, it is good.
Share within TICTOC: http://www.ietf.org/mail-archive/web/rtgwg/current/msg03181.html

Thanks
Lizhong

---

From: Tony Li <[email-masked]>
Date: Sun, 30 Jan 2011 19:26:03 -0800

Hi,

I'd go further and suggest that we should recommend bidirectional LSPs as the preferred approach, regardless of composite links.

Tony

On Jan 30, 2011, at 6:07 PM, Bhatia, Manav (Manav) wrote:

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

---

From: Yaakov Stein <[email-masked]>
Date: Mon, 31 Jan 2011 13:13:08 +0000

Hi all, 

The issue of ensuring a bidirectional co-routed path is what I wanted to explain regarding NTP.

I was discussing this last week with the routing ADs, 
and was told that co-routing is a standard feature of GMPLS (RFC 3471 section 4).
Since the control plane of MPLS-TP will be GMPLS, this is a good fit.

I looked up some experiments I performed a few years ago using NTP with HW timestamps.
For Internet paths, the fraction of the inaccuracy resulting from asymmetry
was about three times that resulting from PDV. 
Thus asymmetry reduction is often a more important goal than TC.
Of course if we are speaking of full peer-to-peer TC asymmetry doesn't matter,
but if we had that we don't need 1588 either - just sending a timestamp is enough.

I realize that this is not relevant for a well-engineered network
where one could use management to configure a co-routed bidirectional path.

Setting up a co-routed bidirectional path using standard RSVP-TE 
is equally useful for NTP and 1588,
and leads me to return to my original request for a single mechanism for both.

I am thus led to reiterate my proposal for completely generic MPLS mechanism for TC, 
a method that eliminates all the FCS and UDP checksum problems that we have recently discussed.

We need only to define a new PW type with an extended control word that carries a CF. 
The payload could be anything - NTP, 1588, RFC-868, one-way delay OAM, etc.
We can use the label-range idea from the present draft, and similar routing extensions
to signal the TC capability.

Y(J)S

---

From: Jack Kohn <[email-masked]>
Date: Mon, 31 Jan 2011 18:56:01 +0530

Yakov,

> We can use the label-range idea from the present draft, and similar routing extensions

What label range are you referring to? AFAIK there isnt any label
range defined in this document. The label that 1588 uses is signalled
by RSVP to all the other nodes.

Also, what prevents the same mechanism to be used for NTP? If its NTP
that we are supporting then one does not need to provide the offset in
the RSVP object. The routing extensions remain the same and it NTP
also works. Thus the mechanism defined in this draft will work for NTP
as well.

Jack

---

From: Yaakov Stein <[email-masked]>
Date: Mon, 31 Jan 2011 17:19:39 +0000

Jack

There was a long discussion at the conference call and on the list,
with the draft authors and others maintaining that this method
is not applicable to NTP (mainly because its sole purpose is to identify
LSRs that can perform TC correction to 1588 packets).

By label range I mean the method used to identify the timing packets
in transit, whatever that method is.

Y(J)S

-----Original Message-----
From: Jack Kohn [mailto:[email-masked]] 
Sent: Monday, January 31, 2011 15:26
To: Yaakov Stein
Cc: [email-masked]
Subject: Re: [TICTOC] Transporting PTP messages (1588) over MPLS Networks

Yakov,

Jack

---

From: "Shahram Davari" <[email-masked]>
Date: Mon, 31 Jan 2011 10:39:43 -0800

Hi Yaakov,

I agree that we need co-routed LSPs, but I don't understand why we need a complete new method of carrying CF. I think we have to reuse what exists today and our draft really doesn't change the encapsulation, and therefore Min HW change is required to support it. On the other hand defining a new CW and PW is going to be very painful since it has major HW impact.

So I don't support such change. I think if needed we could accommodate the NTP as well, we just need a requirements document to evaluate.

Thx
Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Yaakov Stein
Sent: Monday, January 31, 2011 5:13 AM
To: [email-masked]
Subject: Re: [TICTOC] Transporting PTP messages (1588) over MPLS Networks

Hi all, 

Y(J)S

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Tue, 1 Feb 2011 05:39:55 +0530

Hi Yaakov,
 
I am not sure if I understand why you think that the method described in this draft will not work for NTP? I agree that we have been concentrating on 1588, but that's ok for a draft that's called "Transporting PTP messages (1588) over MPLS Networks". We would require some very minimal changes to also accommodate NTP.

The draft states that a subset of PTP messages MUST be transported over some dedicated LSPs, lets call them timing LSPs for now. When setting up the RSVP tunnel we had also given a pointer to the start of the packet, thus it is trivial for implementations to note whether the incoming packet is 1588 or some other. If its 1588 event messages then they may want to compensate for residence time by updating the PTP packet Correction Field. At the very least such packets should be given some sort of priority over the others. 

Now this draft can be easily extended to carry NTP as well. All we need to say is that NTP packets MUST be transported over the timing LSPs. We will need to change section 13 where we have described routing extensions to now indicate the protocol (1588 or NTP) that the router supports. Additionally, it can also indicate that if its 1588, then is it capable of updating the CF. Similarly, we may need some minor changes in the RSVP section as well.

The section on ECMP and QoS will remain as is without any changes. There can be a subsection for 1588 where we discuss the UDP checksum, etc.

So I don't see why you think that this draft precludes the possibility of supporting NTP.

Cheers, Manav

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Yaakov Stein
> Sent: Monday, January 31, 2011 10.50 PM
> To: Jack Kohn
> Cc: [email-masked]
> > a method that eliminates all the FCS and UDP checksum 
> problems that we have recently discussed.
> >