Re: [mpls] [mpls-tp] [PWE3] 1588 over MPLS draft

[Curtis Villamizar <[e-mail]>]

A section on backwards compatibility with non-compliant LSR would be
helpful.  It might be as simple as a bit of RSVP-TE signaling that
indicates capability and actions to take when a non-compliant LSR is
found in a path.  Normally IEEE-1588 (or very high precision NTP)
would be with adjacent LSR so non-compliance would mean no peering
would be attempted.

Curtis


In message <[e-mail]>
John E Drake writes:
>  
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On
> > Behalf Of Shahram Davari
> > Sent: Thursday, July 15, 2010 12:52 PM
> > To: Joel M. Halpern
> > Cc: [e-mail]; [e-mail]; S. Davari; [e-mail]; mpls-
> > [e-mail]
> > Subject: Re: [mpls-tp] [mpls] [PWE3] 1588 over MPLS draft
> > 
> > Hi Joel,
> > 
> > There are 2 aspects to this puzzle:
> > 
> > 1) Hardware support for 1588 in a device.
> > 2) Software support for 1588 in the form of allocating labels to PTP
> > LSPs
> > 
> > A router that wants to perform 1588 time stamping must have both (1)
> > and (2) functionality. While a router in the path of a PTP LSP that
> > does not support (1) should support (2) and advertise labels from some
> > arbitrary range for PTP LSP.
> > 
> > It is quite easy to upgrade a router software so that when it receives
> > RSVP-TE label request to assign label from an arbitrary local range.
>  
> JD:  What happens in the case where a router's software has not been upgraded?
>  
> > 
> > So I don't see any issue here.
> > 
> > Thanks,
> > Shahram
> > 
> > 
> > 
> > -----Original Message-----
> > From: Joel M. Halpern [mailto:[e-mail]]
> > Sent: Thursday, July 15, 2010 12:06 PM
> > To: Shahram Davari
> > Cc: Mach Chen; S. Davari; Jia HE; [e-mail]; [e-mail];
> > [e-mail]; [e-mail]
> > Subject: Re: [mpls] [PWE3] 1588 over MPLS draft
> > 
> > Architecturally, as I understand the draft, the downstream neighbor of
> > a
> > 1588 supporting device (on the PTP carrying LSP) may not itself be a
> > 1588 supporting device.  Is that correct?  If that is not correct, if
> > instead the structure is that PTP supporting LSPs are established
> > between adjacent enhanced devices, then I can see how some sort of a
> > label range might make sense.
> > 
> > If however, the downstream node you refer to may be an existing LSR,
> > then I do not see how you can ask an existing LSR to allocate a label
> > range for a function it does not understand.
> > 
> > Yours,
> > Joel
> > 
> > Shahram Davari wrote:
> > > Hi Joel,
> > >
> > > I agree with your logic, but the idea is a bit different:
> > >
> > > All we need is a label range, it does not need to be globally unique
> > in the network and it does
> >  >not even need to be the same on the Tx and Rx direction of the same
> > link. Although we need time
> >  >stamping both on Rx and on Tx, but on Rx a node is in control of its
> > own label and on Tx the
> >  >downstream node should advertise some label range. What we don't want
> > is that the downstream
> >  >node to advertise random labels for each LSP carrying PTP.
> > >
> > > I will update the draft to mention that the label range does not
> > require to be global but it can
> >  >be per-platform or even per-interface.
> > >
> > > Thanks,
> > > Shahram
> > >
> > > -----Original Message-----
> > > From: Joel M. Halpern [mailto:[e-mail]]
> > > Sent: Wednesday, July 14, 2010 8:21 PM
> > > To: Mach Chen
> > > Cc: Shahram Davari; S. Davari; Jia HE; [e-mail]; [e-mail];
> > [e-mail]; [e-mail]
> > > Subject: Re: [mpls] [PWE3] 1588 over MPLS draft
> > >
> > > Remember that if what is required is that the message arriving at the
> > > 1588 supporting device have a certain label range, that is a purely
> > > local matter.  As long as the singaling carries the indication that
> > the
> > > LSP is to be dedicated to 1588 traffic (a reasonable extension to the
> > > signaling), the downstream switch can pick what label to assign to
> > that LSP.
> > >
> > > If the goal is to have the outgoing label be from a specific range,
> > that
> > > is essentially impossible in the proposed architecture.  The proposed
> > > architecture is one in which 1588 switches are peers with existing
> > LSRs
> > > using MPLS.  As such, in order to have a label range for outgoing
> > > labels, the existing MPLS LSR would somehow have to know about this
> > > reserved label range, not use those labels for other purposes, and
> > > assign those labels to 1588 LSPs.  All of which is
> > > non-backwards-compatible.  If the 1588 LSPs were actually
> > pseudowires,
> > > tunneled over LSPs, then any number of things are possible.
> > >
> > > Yours,
> > > Joel M. Halpern
> > >
> > > Mach Chen wrote:
> > >> Hi Shahram,
> > >>
> > >> I agree that the label range idea is an efficient way that could
> > reduce
> > >> the storage requirement of PHY chips.
> > >>
> > >> It's easy to require one or limited nodes to reserve a label range,
> > but
> > >> IMHO, it very difficut to require all nodes of a large network to do
> > >> this and even worse when some labels are already used by other LSPs,
> > >> unless there are some mechanisms to negotiate/advertise(e.g.,
> > flooding
> > >> the label range by IGP within the network) the proper label range
> > hence
> > >> to aviod label collision.
> > >>
> > >> Best regards,
> > >> Mach
> > >>
> > >> --------------------------------------------------
> > >> From: "Shahram Davari" <[e-mail]>
> > >> Sent: Thursday, July 15, 2010 1:58 AM
> > >> To: "Mach Chen" <[e-mail]>; "S. Davari" <[e-mail]>;
> > >> "Jia HE" <[e-mail]>
> > >> Cc: <[e-mail]>; <[e-mail]>; <[e-mail]>;
> > >> <[e-mail]>
> > >> Subject: RE: [mpls] [PWE3] 1588 over MPLS draft
> > >>
> > >>> Hi Mach,
> > >>>
> > >>> When a service provider wants to create these PTP LSPs, what is
> > wrong
> > >>> with allocating a range of labels for this purpose? This is purely
> > a
> > >>> software exercise. There are 2 million labels available to each
> > node,
> > >>> why can't some of them be allocated by software to PTP?
> > >>>
> > >>> In theory what you say is correct and should work, but in practice
> > >>> there is a function called 1-step Transparent clocking that
> > requires
> > >>> time stamping at the PHY (immediately when the packet is received
> > or
> > >>> transmitted). PHY chips don't have CAM or lots of memory to store a
> > >>> few thousand random labels. The label range will solve that problem
> > >>> and is consistent with MPLS architecture.
> > >>>
> > >>> Thanks,
> > >>> Shahram
> > >>>
> > >>> -----Original Message-----
> > >>> From: Mach Chen [mailto:[e-mail]]
> > >>> Sent: Wednesday, July 14, 2010 1:53 AM
> > >>> To: S. Davari; Jia HE; Shahram Davari
> > >>> Cc: [e-mail]; [e-mail]; [e-mail]; mpls-
> > [e-mail]
> > >>> Subject: Re: [mpls] [PWE3] 1588 over MPLS draft
> > >>>
> > >>> Hi Shahram,
> > >>>
> > >>> From the view of implementation, there is no more difference
> > between
> > >>> SHOULD
> > >>> and MUST :-)
> > >>> For me, the Label Range is more like a mechanim to notify related
> > >>> nodes that
> > >>> some LSPs are dedicated for PTP messages other than the chips
> > memory
> > >>> limitation, because the memory restriction is always there whatever
> > >>> you use
> > >>> Label Range or not.
> > >>> IMHO, since the objective is to tell related MPLS nodes which LSPs
> > are
> > >>> PTP
> > >>> LSPs, an indication in the signaling(RSVP-TE/GMPLS/LDP) is enough
> > and
> > >>> seems
> > >>> more common. And it will avoid the strict requirement of "the
> > network and
> > >>> all nodes required to support the Label range".
> > >>> In addition, there should be some mechanims(e.g., ISIS/OSPF
> > >>> extensions) for
> > >>> nodes to advertise their PTP capability hence to help PTP LSPs
> > >>> computation.
> > >>>
> > >>> Best regards,
> > >>> Mach
> > >>>
> > >>>
> > >>> --------------------------------------------------
> > >>> From: "S. Davari" <[e-mail]>
> > >>> Sent: Wednesday, July 14, 2010 2:31 PM
> > >>> To: "Jia HE" <[e-mail]>; "Shahram Davari"
> > <[e-mail]>
> > >>> Cc: <[e-mail]>; <[e-mail]>; <[e-mail]>;
> > >>> <[e-mail]>
> > >>> Subject: Re: [mpls] [PWE3] 1588 over MPLS draft
> > >>>
> > >>>> Hi Jia,
> > >>>>
> > >>>> Label range is a SHOULD requirements and not MUST. The reason for
> > Label
> > >>>> Range is
> > >>>> mainly for PHY chips that don't have large memory and can't store
> > a
> > >>>> lot of
> > >>>> Labels. Otherwise the PTP LSP is setup via signaling that
> > specifies the
> > >>>> LSP as
> > >>>> carrying 1588.
> > >>>>
> > >>>> So the answer is that if a Label range is used it must be a Global
> > range
> > >>>> within
> > >>>> a network and should not be used by any router for other
> > applications.
> > >>>>
> > >>>> Thanks,
> > >>>> Shahram
> > >>>>
> > >>>>
> > >>>>
> > >>>> ________________________________
> > >>>> From: Jia HE <[e-mail]>
> > >>>> To: Shahram Davari <[e-mail]>
> > >>>> Cc: [e-mail]; [e-mail]; [e-mail]; mpls-
> > [e-mail]
> > >>>> Sent: Tue, July 13, 2010 9:50:37 PM
> > >>>> Subject: Re: [mpls] [PWE3] 1588 over MPLS draft
> > >>>>
> > >>>>
> > >>>> Hi Shahram,
> > >>>>
> > >>>> One question about "PTP Label Range":
> > >>>>
> > >>>> To my knowledge, label in MPLS network is a local  matter. For
> > >>>> example, we
> > >>>> may
> > >>>> have per-interface or per-platform label space. Will  this
> > specificed
> > >>>> "PTP
> > >>>> Label
> > >>>> Range" conflict with the current in-use labels  for common LSPs?
> > >>>>
> > >>>>
> > >>>> B.R.
> > >>>> Jia
> > >>>>
> > >>>> ----- Original Message -----
> > >>>>> From: Shahram    Davari
> > >>>>> To: [e-mail] ; [e-mail] ; [e-mail] ;
> > [e-mail]
> > >>>>> Sent: Thursday, July 08, 2010 3:12 AM
> > >>>>> Subject: [PWE3] 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