Yaakov,
Please see inline below.
Regards,
Sasha
________________________________________
From: [email protected] [[email protected]] On Behalf Of Yaakov
Stein [[email protected]]
Sent: Tuesday, July 13, 2010 10:11 PM
To: Tony Li; Ron Cohen; Shahram Davari; [email protected]
Cc: [email protected]
Subject: Re: [TICTOC] FW: 1588 over MPLS draft
Hi all,
I have been out of contact for a few days, and just found that quite a few of
you have commented on this issue.
There seem to have been two issues raised.
1) Why do we need to define an MPLS (or MPLS-TP) encap ?
As many have said TC (or BC) is one reason.
[[Sasha]] TC is the reason, BC, IMO, is not.
I am not sure we are going to see TC handling in LSRs any time soon, but it is
a reason.
Perhaps a better reason for now is QoS. I really want to easily recognize a
timing flow to give it EF service.
[[Sasha]] QoS is IMO not an issue. It exists over IP as well as over MPLS.
Of course this can be done by giving it its own label and assigning the proper
QoS to that label
(which is Shahram suggests), but it may be easier to make timing flows
universally recognizable
(as router alerts are).
[[Sasha]] Exactly!!! If you want every LSR on the way to be able to inspect and
modify the packet, you need a RA label or, rather, its analog - let's call it
the PTP Alert label, or PTPA for (not so) short.
This would be a new reserved label (and yes, some are still left) with the
following rules:
- just as the RA label, it can be anywhere in the stack except at the bottom
- An LSR that observes this label (because it was at the top of the stack or
because it has popped all the labels
above it) will do the following:
* Check the payload of the MPLS packet for being a PTP packet in one of the
existing encapsulations
(my personal preference is PTP over UDP/IP, but it is not that relevant)
* If the check succeeds and the LSR is a TC, update the correction field in
this packet
* Forward this packet as indicated by the label immediately below the PTPA.
If this means sending
a labeled packet, add PTPA at the top of the resulting label stack (again,
same treatment as for the RA).
The forwarding rule is applied regardless of the results of check for
carrying PTP.
The only differences with RA is that passing the PTPA-labeled packet to a
software module is not required
(and probably should be avoided).
It would be also pretty easy to check if there any malicious LSRs on your LSP
that do not recognize PTPA: just use ICMP-Ping in this LSP with and without
added PTPA on top... if it does not work with PTPA but works without it, there
is an LSR that treats PTPA as an unknown label and discards the packet...
Does this make sense?
My 2c,
Sasha
2) Why do we need a new encap. Why not just use the UDP/IP one and put it in
MPLS, or the Ethernet one in a PW.
Of course it is fine to carry 1588 inside UDP/IP or Ethernet inside MPLS.
For that matter you can put the 1588 in Ethernet inside an Ethernet PW inside
IP (using RFC 4023) inside MPLS,
and many other encaps. The problem is the predictability of finding the fields
inside.
When you say 1588 in Ethernet encap, is that untagged ? 1 VLAN tag ? 2 tags ?
MAC-in-MAC ?
In UDP/IP is that without IP options ?
The idea behind defining another transport layer (and, incidentally, there are
already more defined in 1588)
We COULD standardize one of these (e.g., never tagged),
but what would we do in a hybrid scenario when it comes in from Ethernet with a
tag ?
Y(J)S
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of
Tony Li
Sent: Saturday, July 10, 2010 10:46
To: Ron Cohen
Cc: [email protected]
Subject: Re: [TICTOC] FW: 1588 over MPLS draft
Ron,
All true, but the cost is implementing Yet Another Encapsulation.
The bandwidth delta isn't big enough to be worth discussing. What's another 20
bytes?
And the reason why OAM isn't in IP is wholly due to politics. If folks really
wanted to do good engineering, they would have done BFD for reachability and IP
based traceroute. Adding more complexity just so that we can each have our own
little standards is NOT efficient engineering and a good use of any of our
resources.
Tony
On Jul 9, 2010, at 11:43 PM, Ron Cohen wrote:
> Tony,
>
> The idea is that this encapsulation is used in scenarios where the MPLS cloud
> is PTP-aware. MPLS LSRs act as boundary (or transparent) clocks and ensure
> that time delivery is will not be affected by queuing and forwarding delays.
>
> I think the question in these scenarios should be the other way round: why
> should PTP messages sent between two PTP aware LSRs be encapsulated in
> Ethernet and/or IP? Beyond bandwidth efficiency, addition of superfluous
> layers adds complications and implementation assumptions. I think it is
> similar to the reason why OAM messages between two LSRs are not encapsulated
> in Ethernet/IP.
>
> Does this make sense?
>
> Best,
> Ron
>
>
>
>
> On Sat, Jul 10, 2010 at 8:53 AM, Tony Li <[email protected]> wrote:
>
> Thanks Ron.
>
> Please pardon my ignorance, but what's the benefit of this over doing an
> EthernetPW?
>
> Tony
>
>
> On Jul 9, 2010, at 10:27 PM, Ron Cohen wrote:
>
> > Hi Tony,
> >
> > PTP is designed to be extended over multiple transports. Some transports
> > are included in IEEE1588-2008 Annex-s, while the idea was that others (such
> > as MPLS) will be developed by the expert standardization bodies.
> >
> > I wrote a proposal a while ago for direct PTP over MPLS mapping. It is
> > still available here http://tools.ietf.org/html/draft-ronc-ptp-mpls-00 . At
> > least part of it still makes sense.
> >
> > Best,
> > Ron
> >
> > On Fri, Jul 9, 2010 at 10:41 PM, Tony Li <[email protected]> wrote:
> >
> > And, how can the encapsulation be anything other than EthernetPW?
> >
> > Tony
> >
> >
> > On Jul 9, 2010, at 12:38 PM, <[email protected]> wrote:
> >
> > > Hi Yaakov,
> > >
> > > when you say encapsulation what is the intention e.g. at the interface?
> > >
> > > Mike
> > > ________________________________
> > > From: [email protected] [[email protected]] On Behalf Of
> > > Yaakov Stein [[email protected]]
> > > Sent: 09 July 2010 05:06
> > > To: [email protected]; [email protected];
> > > [email protected]
> > > Subject: Re: [TICTOC] FW: 1588 over MPLS draft
> > >
> > > Sebastien
> > >
> > > Yes, developing an MPLS encapsulation for 1588 is high on TICTOC's list
> > > of things to accomplish.
> > >
> > > Y(J)S
> > >
> > > From: [email protected] [mailto:[email protected]] On Behalf
> > > Of [email protected]
> > > Sent: Thursday, July 08, 2010 18:37
> > > To: [email protected]; [email protected]
> > > Subject: Re: [TICTOC] FW: 1588 over MPLS draft
> > >
> > > Hi,
> > >
> > > After reading this interesting draft, I would have some questions for
> > > clarification (sorry, I will not attend to the Maastricht meeting).
> > >
> > > My first general question is related to the objective of TICTOC regarding
> > > this topic: is it planned that TICTOC would develop a specific mechanism
> > > for transporting PTP over MPLS as the one proposed in this document? If
> > > so, is it oriented to telecoms applications, or to other types of
> > > applications?
> > >
> > > My second question would be to better understand why there is a need for
> > > transporting PTP over MPLS. It is still unclear to me. FYI, similar
> > > discussions happened in June in ITU-T Q13/15 during the last Geneva
> > > meeting.
> > >
> > > My understanding of the context of this draft is that the network between
> > > a PTP master and a PTP slave experiences full timing support for PTP,
> > > such as TC in every node (or possibly BC, that is also slightly evoked in
> > > the document?). In this context, it can be questioned if the PTP timing
> > > delivery is really done "end-to-end", since every node has to process the
> > > PTP messages. Therefore, is it really appropriate in this case to put the
> > > PTP messages into a tunneling transport, such as MPLS?
> > >
> > > It looks more logical to me in this situation to transport the PTP timing
> > > flows outside MPLS (e.g. simply over UDP/IP) on a hop-by-hop basis (e.g.
> > > each node delivers its timing to the next one).
> > > But maybe I misunderstood or missed something...
> > >
> > > Any thoughts?
> > >
> > > Thanks.
> > >
> > > BR,
> > >
> > > Sébastien
> > > ________________________________
> > > De : [email protected] [mailto:[email protected]] De la part
> > > de Shahram Davari
> > > Envoyé : mercredi 7 juillet 2010 21:36
> > > À : [email protected]
> > > Objet : [TICTOC] FW: 1588 over MPLS draft
> > >
> > >
> > > From: Shahram Davari
> > > Sent: Wednesday, July 07, 2010 12:12 PM
> > > To: '[email protected]'; '[email protected]'; '[email protected]';
> > > '[email protected]'
> > > Subject: 1588 over MPLS draft
> > >
> > > Hi All,
> > >
> > > Please find attached our first draft of 1588 over MPLS. Since we have
> > > some technical issues converting the Word format to Txt we couldn’t
> > > upload the draft before the cut-off date. However we will present the
> > > draft in the next IETF meeting and will upload the draft after the
> > > meeting.
> > >
> > > Note that the main WG is TicToc but may require consultation with MPLS
> > > and PWE3 WGs.
> > >
> > > Thanks,
> > > Shahram Davari
> > > _______________________________________________
> > > TICTOC mailing list
> > > [email protected]
> > > https://www.ietf.org/mailman/listinfo/tictoc
> >
> > _______________________________________________
> > TICTOC mailing list
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/tictoc
> >
>
>
_______________________________________________
TICTOC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tictoc
_______________________________________________
TICTOC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tictoc
_______________________________________________
TICTOC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tictoc
