Re: [TICTOC] I-D Action: draft-ietf-tictoc-1588overmpls-06.txt

[Shahram Davari <[e-mail]>]

Hi Greg,

Thanks for your comments. Please see my response inline.

Thx
SD

From: TICTOC [mailto:[e-mail]] On Behalf Of Gregory Mirsky
Sent: Thursday, May 08, 2014 10:51 AM
To: Bhatia, Manav (Manav); [e-mail]; [e-mail]
Subject: Re: [TICTOC] I-D Action: draft-ietf-tictoc-1588overmpls-06.txt

Dear Authors, et. al,
please find my comments and questions to the latest version below:
*         In the Introduction and throughout the document MPLS/MPLS-TP environment being presented as alternative to MPLS environment, e.g. "One is applicable to MPLS environment and the other one is applicable to MPLS/MPLS-TP environment." Two questions:
*         architecturally MPLS-TP data plane is a subset of MPLS, so everything applicable to MPLS-TP is applicable to MPLS data plane. Thus, if there's something that relies on MPLS-TP specific architectural characteristics the sentence may be re-worded like "One is applicable to all variants of MPLS environments and the other one is applicable to only MPLS-TP environment."
*         As you've noticed I've removed MPLS from "MPLS/MPLS-TP" because I don't understand what MPLS signifies in this case. I think it would benefit the document if MPLS related terminology be added to Section 2.
SD> Your replacement text does not capture what we intend to say. We are saying one encapsulation can be used by MPLS & MPLS-TP, while the other one can only be used by MPLS and not MPLS-TP. So the "/" mean either.
*         In the Introduction stated "When signaling is used to setup the PTP LSP, extensions to signaling protocols (e.g., RSVP-TE) are required for establishing PTP LSPs." Are you planning to submit extensions to LDP? Otherwise, changing 'protocols' from plural to singular and making reference to RSVP-TE more explicit may be considered.
SD. We are not planning to submit extensions to any signaling at this time. All we are saying is that if signaling is required then extensions to signaling is needed, where it is RSVP-TE, LDP or anything else. RSVP-TE is just an example. I don't agree with your logic that "if you are not planning to submit a signaling extensions then you should not mention that such extensions may be required".
*         Section 5. In "The Timing LSP MAY be MPLS LSP/MPLS-TP LSP" use of "MPLS LSP/MPLS-TP LSP" is not clear. Does "/" signify "and", "or", something else?
SD> "/" means "either". We can clarify this.
*         Section 8. "Ring protection switching or MPLS Fast Reroute (FRR) can switch to an alternative path that can cause a change in delay, ..." If your intention is to provide exhaustive list then you may consider adding Linear protection to the list.
SD> God point we can add the Linear protection as well.

Please consider them as WG LC comments.

Regards,
        Greg

-----Original Message-----
From: TICTOC [mailto:[e-mail]] On Behalf Of Bhatia, Manav (Manav)
Sent: Monday, April 28, 2014 9:09 AM
To: [e-mail]<mailto:[e-mail]>
Subject: Re: [TICTOC] I-D Action: draft-ietf-tictoc-1588overmpls-06.txt

Hi Yaakov,

This version addresses the final set of comments that we received as per the MPLS and TICTOC WG last call.

Can we move it further now?

Cheers, Manav

> -----Original Message-----
> From: TICTOC [mailto:[e-mail]] On Behalf Of internet-
> [e-mail]<mailto:[e-mail]>
> Sent: Monday, April 28, 2014 9:34 PM
> To: [e-mail]<mailto:[e-mail]>
> Cc: [e-mail]<mailto:[e-mail]>
> Subject: [TICTOC] I-D Action: draft-ietf-tictoc-1588overmpls-06.txt
>
>
> 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 Timing messages over MPLS
> Networks
>         Authors         : Shahram Davari
>                           Amit Oren
>                           Manav Bhatia
>                           Peter Roberts
>                           Laurent Montini
>        Filename        : draft-ietf-tictoc-1588overmpls-06.txt
>        Pages           : 36
>        Date            : 2014-04-28
>
> Abstract:
>    This document defines the method for transporting Timing messages
>    such as PTP and NTP 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 Timing messages inside dedicated MPLS
>    LSPs.  These LSPs only carry Timing messages and possibly Control
> and
>    Management packets, but they do not carry customer traffic.
>
>    Two methods for transporting Timing messages over MPLS are defined.
>    The first method is to transport Timing messages directly over the
>    dedicated MPLS LSP via UDP/IP encapsulation, which is suitable for
>    MPLS networks.  The second method is to transport Timing messages
>    inside a PW via Ethernet encapsulation.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-tictoc-1588overmpls/
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-tictoc-1588overmpls-06
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-tictoc-1588overmpls-06
>
>
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> TICTOC mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/tictoc

_______________________________________________
TICTOC mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/tictoc