Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8E2112896F; Thu, 19 Jan 2017 08:00:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QAebputKslZO; Thu, 19 Jan 2017 08:00:32 -0800 (PST) Received: from mail-ot0-x236.google.com (mail-ot0-x236.google.com [IPv6:2607:f8b0:4003:c0f::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB584129623; Thu, 19 Jan 2017 08:00:31 -0800 (PST) Received: by mail-ot0-x236.google.com with SMTP id 104so35016986otd.3; Thu, 19 Jan 2017 08:00:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jUWhEinA+d0O3bThjJa/JCDUGwwyQn35qbgxho1+tBA=; b=E3HQHQrYyjRgnrUdIz1xl4qwX8GIGl0QOiDh/2geDAVwi6DD03iT46z8p5kWjkPbkV wvp403FN/EEkL4W8Ir+WNijSUd+Nvtk6iyaEluwj0HfRaV+gYx+MKrtxht7NMHMUpIFq LQg+LsjKmFOLac965sXzKlyI7ajI3ikxVTQsy9CzwnUbZ7Yp27KLf9WCO8VQT+H3PdsO 9QRFTdeCy8grBMNbOOBMainNz1pVsqQ/RucdIYUBcNxhnNyyei55bPfMuaprLmIOlLIG 50h0eCnamZz6oceUEIqUBjQsESEjHFUVkAJ2vYozMW+6sp15oKssoYsEivDHbU/FTxtQ kfUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jUWhEinA+d0O3bThjJa/JCDUGwwyQn35qbgxho1+tBA=; b=t773oymf9zlhQFGDuVYF04PfyG15Y5+Z395TsFObz3hNQNCSr13voASWzjec3WqojS YoSUl2VpIKv60HSBqYuYgrUgnKbxLL8sAhzGvSs3n55k/ebhllYJlLTw3UL4x9CQxxlc 8o7E08BIG2LjjjL7Wla1eCvIoTtnk2Yn4rXBEHt84lBqX2rkzXb/GFxdilSgtBpjqrUg kuXkc20Hz83BcFjk/kOFE8ytKGUwR7gimwns9kkZXZ7GcY2YAKs7h11kOus5xZbe5el3 4hVi1pvBISiMXVm09AibXuRYgLOZ6mYiZuF+H11aYXV1TlQD4WrpUvGh27Ny1IPO7c0Z l6yA== X-Gm-Message-State: AIkVDXKKFc1wKWsj8BnxUHwLyyW1oqvv+5mheqr2d1a0jYw8Br8k+r3C5Lv4P3ZPX2YE8MYHHxlc0ZHEm1WiOw== X-Received: by 10.157.38.237 with SMTP id i42mr5246093otd.76.1484841631013; Thu, 19 Jan 2017 08:00:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.1.103 with HTTP; Thu, 19 Jan 2017 08:00:30 -0800 (PST) In-Reply-To: References: <148414970343.8167.4538946698521330202.idtracker@ietfa.amsl.com> <95d41b52-5c85-869f-2139-6713816e9637@nostrum.com> From: Greg Mirsky Date: Thu, 19 Jan 2017 08:00:30 -0800 Message-ID: Subject: Re: [mpls] Review of draft-ietf-mpls-residence-time-12 To: "Les Ginsberg (ginsberg)" Content-Type: multipart/alternative; boundary=001a11353282f6e0dc054674a114 Archived-At: Cc: "mpls@ietf.org" , "ietf@ietf.org" , "gen-art@ietf.org" , "isis-chairs@ietf.org" , "draft-ietf-mpls-residence-time.all@ietf.org" , "Abhay Roy \(akr\)" , "Acee Lindem \(acee\)" X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 16:00:35 -0000 --001a11353282f6e0dc054674a114 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Les, I believe that IGP extensions to advertise RTM capability are required. Regards, Greg On Thu, Jan 19, 2017 at 7:57 AM, Les Ginsberg (ginsberg) wrote: > Greg =E2=80=93 > > > > I am having trouble understanding your response. > > The question we are raising is whether we should extend the IGPs to > support advertising RTM capability =E2=80=93 an alternative being to retr= ieve the > capability via network management. > > > > Saying that the IGP functionality is optional and/or wouldn=E2=80=99t alw= ays be > advertised doesn=E2=80=99t really answer the question of whether we shoul= d or > should not define the IGP extensions. > > > > Could you respond more directly to this point? > > > > Les > > > > > > *From:* Greg Mirsky [mailto:gregimirsky@gmail.com] > *Sent:* Thursday, January 19, 2017 7:44 AM > *To:* Acee Lindem (acee) > *Cc:* Robert Sparks; mpls@ietf.org; gen-art@ietf.org; > draft-ietf-mpls-residence-time.all@ietf.org; ietf@ietf.org; Les Ginsberg > (ginsberg); isis-chairs@ietf.org; Abhay Roy (akr) > > *Subject:* Re: [mpls] Review of draft-ietf-mpls-residence-time-12 > > > > Hi Acee, > > the draft defines optional functionality. If an operator has no use > neither for PTP's Transparent Clock, nor RTM itself as performance metric= , > then RTM sub-TLV would not be included and thus it would not be flooded. = Of > course, it be right to reflect RTM capability through YANG data model, th= us > allowing SDN scenario you've described. > > > > Regards, > > Greg > > > > On Wed, Jan 18, 2017 at 2:51 PM, Acee Lindem (acee) > wrote: > > Hi Greg, > > > > Although it is a bit late, we=E2=80=99ve had some discussions amongst the= IS-IS > and OSPF chairs and are wondering whether the interface capability belong= s > in the IGPs. This will be flooded throughout the entire routing domain = =E2=80=93 is > it really needed on every node or will it the RTM testing be initiated fr= om > an omniscient NMS client that would know the capabilities of each node or > easily query them using YANG? > > > > Thanks, > > Acee > > > > *From: *mpls on behalf of Greg Mirsky < > gregimirsky@gmail.com> > *Date: *Wednesday, January 18, 2017 at 1:25 PM > *To: *Robert Sparks > *Cc: *"mpls@ietf.org" , "gen-art@ietf.org" < > gen-art@ietf.org>, "draft-ietf-mpls-residence-time.all@ietf.org" < > draft-ietf-mpls-residence-time.all@ietf.org>, "ietf@ietf.org" < > ietf@ietf.org> > *Subject: *Re: [mpls] Review of draft-ietf-mpls-residence-time-12 > > > > Hi Robert, > > thank you for the most expedient review and comments. I'll make changes i= n > Section 2 per your suggestion. > > > > Regards, > > Greg > > > > On Wed, Jan 18, 2017 at 10:34 AM, Robert Sparks > wrote: > > The changes all look good. > > I still think you should say something in the document about what "the > time of packet arrival" and "transmission" means, and call out the point > you made about being careful to not introduce apparent jitter by not maki= ng > those measurements consistently. (The definitions you point to in your > earlier mail from G.8013 don't really help - they just say "time of packe= t > arrival". Again, the first and last bit are likely to be several > nanoseconds apart so I think it matters. Perhaps you're saying it doesn't > matter as long as each node is consistent (there will be error in the > residence time measurement, but it will be constant at each node, so the > sum of errors will be constant, and the clocks will be ok?) > > Please look at the new first paragraph of section 2 - there's a mix of "a= s > case" and "in case" that should be made consistent. I suspect it would be > easiest to simply say "referred to as using a one-step clock" and "referr= ed > to as using a two-step clock" or similar. > > RjS > > > > On 1/18/17 12:03 PM, Greg Mirsky wrote: > > Hi Robert, > > Sasha Vainshtein came with elegant idea to address disconnection between > discussion of one-step and two-step modes that you've pointed out. We've > moved Section 7 as sub-section into Section 2 now. Attached are updated > diff and the proposed new version -13. > > > > Regards, > > Greg > > > > On Wed, Jan 18, 2017 at 8:13 AM, Greg Mirsky > wrote: > > Hi Robert, > > once again, thank you for your thorough review and the most detailed > comments. I've prepared updated version and would greatly appreciate if y= ou > review the changes and let us know whether your comments been addressed. > Attached are diff and the new version. > > > > Regards, > > Greg > > > > On Wed, Jan 11, 2017 at 7:48 AM, Robert Sparks > wrote: > > Reviewer: Robert Sparks > Review result: Ready with Nits > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > . > > Document: draft-ietf-mpls-residence-time-12 > Reviewer: Robert Sparks > Review Date: 2017-01-10 > IETF LC End Date: 2017-01-17 > IESG Telechat date: 2017-02-02 > > Summary: Ready (with nits) for publication as a Proposed Standard > > I have two primary comments. I expect both are rooted in the authors > and working group knowing what the document means instead of seeing > what > it says or doesn't say: > > 1) The document is loose with its use of 'packet', and where TTLs > appear when > they are discussed. It might be helpful to rephrase the text that > speaks > of RTM packets in terms of RTM messages that are encoded as G-ACh > messages and > not refer to packets unless you mean the whole encapsulated packet > with MPLS > header, ACH, and G-ACh message. > > 2) Since this new mechanic speaks in terms of fractional nanoseconds, > some > discussion of what trigger-point you intend people to use for taking > the > precise time of a packet's arrival or departure seems warranted. (The > first and > last bit of the whole encapsulated packet above are going to appear at > the > physical layer many nanoseconds apart at OC192 speeds if I've done the > math > right). It may be obvious to the folks discussing this, but it's not > obvious > from the document. If it's _not_ obvious and variation in technique > is > expected, then some discussion about issues that might arise from > different > implementation choices would be welcome. > > The rest of these are editorial nits: > > It would help to pull an overview description of the difference > between > one-step and two-step much earlier in the document. I suggest in the > overview > in section 2. Otherwise, the reader really has to jump forward and > read section > 7 before section 3's 5th bullet makes any sense. > > In section 3, "IANA will be asked" should be made active. Say "This > document > asks IANA to" and point to the IANA consideration section. Apply > similar > treatment to the other places where you talk about future IANA > actions. > > There are several places where there are missing words (typically > articles or > prepositions). You're less likely to end up with misinterpretations > during the > RFC Editor phase if you provide them before the document gets that far > in the > process. The spots I found most disruptive were these (this is not > intended to > be exhaustive): > > Section 3: "set 1 according" -> "set to 1 according" > Section 3: "the Table 19 [IEEE..." -> "Table 19 of [IEEE..." > Section 4.2: "Detailed discussion of ... modes in Section 7." > -> "Detailed discussion of ... modes appears > in Section 7." > Section 10: "most of" -> "most of all" > > In Setion 3.1 at "identity of the source port", please point into the > document > that defines this identity and its representation. I suspect this is a > pointer > into a specific section in IEEE.1588.2008]. > > > > > > > > > > > > --001a11353282f6e0dc054674a114 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Les,
I believe that IGP extensions to advertise RTM= capability are required.

Regards,
Greg<= /div>

On Thu= , Jan 19, 2017 at 7:57 AM, Les Ginsberg (ginsberg) <ginsberg@cisco.com> wrote:

Greg =E2=80=93<= /u>

=C2=A0

I am having trouble under= standing your response.

The question we are raisi= ng is whether we should extend the IGPs to support advertising RTM capabili= ty =E2=80=93 an alternative being to retrieve the capability via network management.

=C2=A0

Saying that the IGP funct= ionality is optional and/or wouldn=E2=80=99t always be advertised doesn=E2= =80=99t really answer the question of whether we should or should not defin= e the IGP extensions.

=C2=A0

Could you respond more di= rectly to this point?

=C2=A0

=C2=A0=C2=A0 Les

=C2=A0

=C2=A0

From: Greg Mir= sky [mailto:greg= imirsky@gmail.com]
Sent: Thursday, January 19, 2017 7:44 AM
To: Acee Lindem (acee)
Cc: Robert Sparks; mpls@ietf.org; = gen-art@ietf.org; draft-ietf-mpls-residence-time.all@ietf.or= g; ietf@ietf.org= ; Les Ginsberg (ginsberg); isis-chairs@ietf.org; Abhay Roy (akr)


Subject: Re: [mpls] Review of draft-ietf-mpls-residence-time-12=

=C2=A0

Hi Acee,

the draft defines optional functionality. If an oper= ator has no use neither for PTP's Transparent Clock, nor RTM itself as = performance metric, then RTM sub-TLV would not be included and thus it woul= d not be flooded. Of course, it be right to reflect RTM capability through YANG data model, thus allowing SDN scena= rio you've described.

=C2=A0

Regards,

Greg

=C2=A0

On Wed, Jan 18, 2017 at 2:51 PM, Acee Lindem (acee) = <acee@cisco.com&= gt; wrote:

Hi Greg,=C2=A0

=C2=A0=

Although it is a bit late, = we=E2=80=99ve had some discussions amongst the IS-IS and OSPF chairs and ar= e wondering whether the interface capability belongs in the IGPs. This will be flooded throughout the entire routing domain =E2=80=93 is it = really needed on every node or will it the RTM testing be initiated from an= omniscient NMS client that would know the capabilities of each node or eas= ily query them using YANG?=C2=A0

=C2=A0=

Thanks,

Acee =C2=A0

=C2=A0=

From: mpls <mpls-bounces@ietf.org> on behalf of Gre= g Mirsky <gre= gimirsky@gmail.com>
Date: Wednesday, January 18, 2017 at 1:25 PM
To: Robert Sparks <rjsparks@nostrum.com>
Cc: "mpls@ie= tf.org" <mpl= s@ietf.org>, "gen-art@ietf.org" <gen-art@ietf.org>, "draft-ietf-mpls-residence-time.all@ietf.org" <= ;draft-ietf-mpls-residence-time.all@ietf.org>, "ietf@ietf.org" <ietf@ietf.org&g= t;
Subject: Re: [mpls] Review of draft-ietf-mpls-residence-time-12=

=C2=A0=

Hi Robert,

thank you for the most expe= dient review and comments. I'll make changes in Section 2 per your sugg= estion.

=C2=A0=

Regards,

Greg

=C2=A0=

On Wed, Jan 18, 2017 at 10:= 34 AM, Robert Sparks <rjsparks@nostrum.com> wrote:

The changes all look good.=

I still think you should say something in the d= ocument about what "the time of packet arrival" and "transmi= ssion" means, and call out the point you made about being careful to not introduce apparent jitter by not making those measurements consistentl= y. (The definitions you point to in your earlier mail from G.8013 don't= really help - they just say "time of packet arrival". Again, the= first and last bit are likely to be several nanoseconds apart so I think it matters. Perhaps you're saying it doesn't matt= er as long as each node is consistent (there will be error in the residence= time measurement, but it will be constant at each node, so the sum of erro= rs will be constant, and the clocks will be ok?)

Please look at the new first paragraph of secti= on 2 - there's a mix of "as case" and "in case" tha= t should be made consistent. I suspect it would be easiest to simply say &q= uot;referred to as using a one-step clock" and "referred to as using a two-st= ep clock" or similar.

RjS

=C2=A0=

On 1/18/17 12:03 PM, Greg M= irsky wrote:

Hi Robert,

Sasha Vainshtein came with = elegant idea to address disconnection between discussion of one-step and tw= o-step modes that you've pointed out. We've moved Section 7 as sub-section into Section 2 now. Attached are updated diff and the pro= posed new version -13.

=C2=A0=

Regards,

Greg

=C2=A0=

On Wed, Jan 18, 2017 at 8:1= 3 AM, Greg Mirsky <gregimirsky@gmail.com> wrote:

Hi Robert,

once again, thank you for y= our thorough review and the most detailed comments. I've prepared updat= ed version and would greatly appreciate if you review the changes and let us know whether your comments been addressed. Attached are diff an= d the new version.

=C2=A0=

Regards,

Greg

=C2=A0=

On Wed, Jan 11, 2017 at 7:4= 8 AM, Robert Sparks <rjsparks@nostrum.com> wrote:

Reviewer: Robert Sparks
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.=C2=A0 Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at
<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-mpls-residence-time-12
Reviewer: Robert Sparks
Review Date: 2017-01-10
IETF LC End Date: 2017-01-17
IESG Telechat date: 2017-02-02

Summary: Ready (with nits) for publication as a Proposed Standard

I have two primary comments. I expect both are rooted in the authors
and working group knowing what the document means instead of seeing
what
it says or doesn't say:

1) The document is loose with its use of 'packet', and where TTLs appear when
they are discussed. It might be helpful to rephrase the text that
speaks
of RTM packets in terms of RTM messages that are encoded as G-ACh
messages and
not refer to packets unless you mean the whole encapsulated packet
with MPLS
header, ACH, and G-ACh message.

2) Since this new mechanic speaks in terms of fractional nanoseconds,
some
discussion of what trigger-point you intend people to use for taking
the
precise time of a packet's arrival or departure seems warranted. (The first and
last bit of the whole encapsulated packet above are going to appear at
the
physical layer many nanoseconds apart at OC192 speeds if I've done the<= br> math
right). It may be obvious to the folks discussing this, but it's not obvious
from the document.=C2=A0 If it's _not_ obvious and variation in techniq= ue
is
expected, then some discussion about issues that might arise from
different
implementation choices would be welcome.

The rest of these are editorial nits:

It would help to pull an overview description of the difference
between
one-step and two-step much earlier in the document. I suggest in the
overview
in section 2. Otherwise, the reader really has to jump forward and
read section
7 before section 3's 5th bullet makes any sense.

In section 3, "IANA will be asked" should be made active. Say &qu= ot;This
document
asks IANA to" and point to the IANA consideration section. Apply
similar
treatment to the other places where you talk about future IANA
actions.

There are several places where there are missing words (typically
articles or
prepositions). You're less likely to end up with misinterpretations
during the
RFC Editor phase if you provide them before the document gets that far
in the
process. The spots I found most disruptive were these (this is not
intended to
be exhaustive):

=C2=A0 Section 3: "set 1 according" -> "set to 1 accordin= g"
=C2=A0 Section 3: "the Table 19 [IEEE..." -> "Table 19 of= [IEEE..."
=C2=A0 Section 4.2: "Detailed discussion of ... modes in Section 7.&qu= ot;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 -> "Detailed discussion of ... modes appears
in Section 7."
=C2=A0 Section 10: "most of" -> "most of all"

In Setion 3.1 at "identity of the source port", please point into= the
document
that defines this identity and its representation. I suspect this is a
pointer
into a specific section in IEEE.1588.2008].


=C2=A0=

=C2=A0=

=C2=A0=

=C2=A0=

=C2=A0


--001a11353282f6e0dc054674a114--