Eric, Les and all,
I concur with Eric. RTM capability is a kind of TE information that
the path computation algorithm must take into account when selecting
the suitable path for the LSP that would be used for RTM purposes.
My 2c,
Sasha
Office: +972-39266302
Cell: +972-549266302
Email: Alexander(_dot_)Vainshtein(_at_)ecitele(_dot_)com
*From:*Eric Gray [mailto:eric(_dot_)gray(_at_)ericsson(_dot_)com]
*Sent:* Thursday, January 19, 2017 10:32 PM
*To:* Les Ginsberg (ginsberg) <ginsberg(_at_)cisco(_dot_)com>; Uma Chunduri
<uma(_dot_)chunduri(_at_)huawei(_dot_)com>; John E Drake <jdrake(_at_)juniper(_dot_)net>; Acee
Lindem (acee) <acee(_at_)cisco(_dot_)com>; Alexander Vainshtein
<Alexander(_dot_)Vainshtein(_at_)ecitele(_dot_)com>; Greg Mirsky <gregimirsky(_at_)gmail(_dot_)com>
*Cc:* mpls(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org; isis-chairs(_at_)ietf(_dot_)org;
gen-art(_at_)ietf(_dot_)org; draft-ietf-mpls-residence-time(_dot_)all(_at_)ietf(_dot_)org; Abhay
Roy (akr) <akr(_at_)cisco(_dot_)com>; Robert Sparks <rjsparks(_at_)nostrum(_dot_)com>
*Subject:* RE: [mpls] Review of draft-ietf-mpls-residence-time-12
Les,
It’s nice to have a good discussion about technical aspects of a
proposed standard, even late in the game.
But I have some difficulty is seeing how this usage is “clearly not TE
information.”
This information should allow the head-end of an LSP to select a path
based on desirable interface capabilities. For the purposes of
accurate time information, the best path may not also be the shortest
path. Is this not exactly what traffic engineering is about?
As far as extending this argument to the ability to advertise
additional link capabilities, I can easily imagine scenarios where
that would make sense. But nobody is suggesting that every LSR (or
router for that matter) either must have this capability for every
scenario, or that – having the capability – it would need to be turned on.
If there is an application or use-case out there that might require
advertising every conceivable interface capability, then vendors will
want to take a look at the size of the opportunity represented by that
and make a decision as to whether or not to support this.
--
Eric
*From:*mpls [mailto:mpls-bounces(_at_)ietf(_dot_)org] *On Behalf Of *Les Ginsberg
(ginsberg)
*Sent:* Thursday, January 19, 2017 3:11 PM
*To:* Uma Chunduri <uma(_dot_)chunduri(_at_)huawei(_dot_)com
<mailto:uma(_dot_)chunduri(_at_)huawei(_dot_)com>>; John E Drake <jdrake(_at_)juniper(_dot_)net
<mailto:jdrake(_at_)juniper(_dot_)net>>; Acee Lindem (acee) <acee(_at_)cisco(_dot_)com
<mailto:acee(_at_)cisco(_dot_)com>>; Alexander Vainshtein
<Alexander(_dot_)Vainshtein(_at_)ecitele(_dot_)com
<mailto:Alexander(_dot_)Vainshtein(_at_)ecitele(_dot_)com>>; Greg Mirsky
<gregimirsky(_at_)gmail(_dot_)com <mailto:gregimirsky(_at_)gmail(_dot_)com>>
*Cc:* mpls(_at_)ietf(_dot_)org <mailto:mpls(_at_)ietf(_dot_)org>; ietf(_at_)ietf(_dot_)org
<mailto:ietf(_at_)ietf(_dot_)org>; isis-chairs(_at_)ietf(_dot_)org
<mailto:isis-chairs(_at_)ietf(_dot_)org>; gen-art(_at_)ietf(_dot_)org
<mailto:gen-art(_at_)ietf(_dot_)org>; draft-ietf-mpls-residence-time(_dot_)all(_at_)ietf(_dot_)org
<mailto:draft-ietf-mpls-residence-time(_dot_)all(_at_)ietf(_dot_)org>; Abhay Roy (akr)
<akr(_at_)cisco(_dot_)com <mailto:akr(_at_)cisco(_dot_)com>>; Robert Sparks
<rjsparks(_at_)nostrum(_dot_)com <mailto:rjsparks(_at_)nostrum(_dot_)com>>
*Subject:* Re: [mpls] Review of draft-ietf-mpls-residence-time-12
Uma –
I readily admit S-BFD descriptors are – strictly speaking - a
violation of the “non-routing info” policy – this was publicly
acknowledged at the time the drafts were written. The exception was
justified on the basis that:
o IGPs are BFD clients
o The S-BFD discriminator information is unique and extremely modest
in size
What we have here is a proposal to start advertising non-routing
related interface attribute information. There is nothing special or
unique about RTM – it is simply one of many interface attributes which
are generic in nature. Having agreed to advertise RTM in the IGPs, how
would you then determine what other interface attributes should/should
not be advertised by the IGPs? Take a look at your favorite vendors
box and see how many interface attributes can be configured.
It is also concerning that – when using the IGPs – we flood
information which must be stored on every node even though the use
case for it is limited to a much smaller subset.
I think we can and should be smarter in this regard – and given the
extensive work being done to enhance manageability I would like to see
us benefit from this.
The authors of draft-ietf-mpls-residence-time clearly had some
thoughts in this regard – which is why they proposed to use RFC 6823
(GENAPP) in IS-IS to advertise the information –but the proposal in
the draft is flawed in this regard. If we were to head in the
“application” direction I would propose a much more generic
“application” which is capable of advertising many interface
attributes. However this goes back to my original concern – whether we
want to use IGPs to flood interface attribute information unrelated to
routing even if it is segregated under an application. Remember that
RFC 6823 stipulates that a separate instance of the protocol (a la RFC
6822) be used for such cases.
Les
*From:*Uma Chunduri [mailto:uma(_dot_)chunduri(_at_)huawei(_dot_)com]
*Sent:* Thursday, January 19, 2017 11:41 AM
*To:* Les Ginsberg (ginsberg); John E Drake; Acee Lindem (acee);
Alexander Vainshtein; Greg Mirsky
*Cc:* Abhay Roy (akr); mpls(_at_)ietf(_dot_)org <mailto:mpls(_at_)ietf(_dot_)org>;
isis-chairs(_at_)ietf(_dot_)org <mailto:isis-chairs(_at_)ietf(_dot_)org>; gen-art(_at_)ietf(_dot_)org
<mailto:gen-art(_at_)ietf(_dot_)org>; draft-ietf-mpls-residence-time(_dot_)all(_at_)ietf(_dot_)org
<mailto:draft-ietf-mpls-residence-time(_dot_)all(_at_)ietf(_dot_)org>; Robert Sparks;
ietf(_at_)ietf(_dot_)org <mailto:ietf(_at_)ietf(_dot_)org>
*Subject:* RE: [mpls] Review of draft-ietf-mpls-residence-time-12
I support advertising this in IGP.
>This is clearly not TE information –..
>I do not see the IGPs as the appropriate mechanism to flood generic
interface capabilities
We have instances where both the above are not met and we flooded
information.
https://tools.ietf.org/html/rfc7883(Les, you co-authored the same!!)
https://tools.ietf.org/html/rfc7880
--
Uma C.
*From:*mpls [mailto:mpls-bounces(_at_)ietf(_dot_)org] *On Behalf Of *Les Ginsberg
(ginsberg)
*Sent:* Thursday, January 19, 2017 9:25 AM
*To:* John E Drake <jdrake(_at_)juniper(_dot_)net <mailto:jdrake(_at_)juniper(_dot_)net>>;
Acee Lindem (acee) <acee(_at_)cisco(_dot_)com <mailto:acee(_at_)cisco(_dot_)com>>; Alexander
Vainshtein <Alexander(_dot_)Vainshtein(_at_)ecitele(_dot_)com
<mailto:Alexander(_dot_)Vainshtein(_at_)ecitele(_dot_)com>>; Greg Mirsky
<gregimirsky(_at_)gmail(_dot_)com <mailto:gregimirsky(_at_)gmail(_dot_)com>>
*Cc:* Abhay Roy (akr) <akr(_at_)cisco(_dot_)com <mailto:akr(_at_)cisco(_dot_)com>>;
mpls(_at_)ietf(_dot_)org <mailto:mpls(_at_)ietf(_dot_)org>; isis-chairs(_at_)ietf(_dot_)org
<mailto:isis-chairs(_at_)ietf(_dot_)org>; gen-art(_at_)ietf(_dot_)org
<mailto:gen-art(_at_)ietf(_dot_)org>; draft-ietf-mpls-residence-time(_dot_)all(_at_)ietf(_dot_)org
<mailto:draft-ietf-mpls-residence-time(_dot_)all(_at_)ietf(_dot_)org>; Robert Sparks
<rjsparks(_at_)nostrum(_dot_)com <mailto:rjsparks(_at_)nostrum(_dot_)com>>; ietf(_at_)ietf(_dot_)org
<mailto:ietf(_at_)ietf(_dot_)org>
*Subject:* Re: [mpls] Review of draft-ietf-mpls-residence-time-12
John –
For me, this raises the age-old question of when it is/is not
appropriate to use IGPs for flooding information.
This is clearly not TE information – you just happen to be using this
in conjunction with MPLS – but it is a generic capability. I do not
see the IGPs as the appropriate mechanism to flood generic interface
capabilities. It also, as Acee has pointed out, results in flooding
information to all nodes in the domain when only a few care about it.
Les
*From:*John E Drake [mailto:jdrake(_at_)juniper(_dot_)net]
*Sent:* Thursday, January 19, 2017 8:54 AM
*To:* Acee Lindem (acee); Alexander Vainshtein; Greg Mirsky; Les
Ginsberg (ginsberg)
*Cc:* Robert Sparks; mpls(_at_)ietf(_dot_)org <mailto:mpls(_at_)ietf(_dot_)org>;
gen-art(_at_)ietf(_dot_)org <mailto:gen-art(_at_)ietf(_dot_)org>;
draft-ietf-mpls-residence-time(_dot_)all(_at_)ietf(_dot_)org
<mailto:draft-ietf-mpls-residence-time(_dot_)all(_at_)ietf(_dot_)org>; ietf(_at_)ietf(_dot_)org
<mailto:ietf(_at_)ietf(_dot_)org>; isis-chairs(_at_)ietf(_dot_)org
<mailto:isis-chairs(_at_)ietf(_dot_)org>; Abhay Roy (akr)
*Subject:* RE: [mpls] Review of draft-ietf-mpls-residence-time-12
Acee,
Relying on an omniscient controller is a non-starter in general and in
particular because the protocol by which it would learn each node’s
RTM capabilities and distribute them to the other nodes is undefined.
Further, one of the ways by which an omniscient controller learns a
node’s capabilities is by snooping the link/state database.
Yours Irrespectively,
John
*From:*Acee Lindem (acee) [mailto:acee(_at_)cisco(_dot_)com]
*Sent:* Thursday, January 19, 2017 11:47 AM
*To:* John E Drake <jdrake(_at_)juniper(_dot_)net <mailto:jdrake(_at_)juniper(_dot_)net>>;
Alexander Vainshtein <Alexander(_dot_)Vainshtein(_at_)ecitele(_dot_)com
<mailto:Alexander(_dot_)Vainshtein(_at_)ecitele(_dot_)com>>; Greg Mirsky
<gregimirsky(_at_)gmail(_dot_)com <mailto:gregimirsky(_at_)gmail(_dot_)com>>; Les Ginsberg
(ginsberg) <ginsberg(_at_)cisco(_dot_)com <mailto:ginsberg(_at_)cisco(_dot_)com>>
*Cc:* Robert Sparks <rjsparks(_at_)nostrum(_dot_)com
<mailto:rjsparks(_at_)nostrum(_dot_)com>>; mpls(_at_)ietf(_dot_)org <mailto:mpls(_at_)ietf(_dot_)org>;
gen-art(_at_)ietf(_dot_)org <mailto:gen-art(_at_)ietf(_dot_)org>;
draft-ietf-mpls-residence-time(_dot_)all(_at_)ietf(_dot_)org
<mailto:draft-ietf-mpls-residence-time(_dot_)all(_at_)ietf(_dot_)org>; ietf(_at_)ietf(_dot_)org
<mailto:ietf(_at_)ietf(_dot_)org>; isis-chairs(_at_)ietf(_dot_)org
<mailto:isis-chairs(_at_)ietf(_dot_)org>; Abhay Roy (akr) <akr(_at_)cisco(_dot_)com
<mailto:akr(_at_)cisco(_dot_)com>>
*Subject:* Re: [mpls] Review of draft-ietf-mpls-residence-time-12
Hi John,
*From: *John E Drake <jdrake(_at_)juniper(_dot_)net
<mailto:jdrake(_at_)juniper(_dot_)net>>
*Date: *Thursday, January 19, 2017 at 10:43 AM
*To: *Acee Lindem <acee(_at_)cisco(_dot_)com <mailto:acee(_at_)cisco(_dot_)com>>, Alexander
Vainshtein <Alexander(_dot_)Vainshtein(_at_)ecitele(_dot_)com
<mailto:Alexander(_dot_)Vainshtein(_at_)ecitele(_dot_)com>>, Greg Mirsky
<gregimirsky(_at_)gmail(_dot_)com <mailto:gregimirsky(_at_)gmail(_dot_)com>>, "Les Ginsberg
(ginsberg)" <ginsberg(_at_)cisco(_dot_)com <mailto:ginsberg(_at_)cisco(_dot_)com>>
*Cc: *Robert Sparks <rjsparks(_at_)nostrum(_dot_)com
<mailto:rjsparks(_at_)nostrum(_dot_)com>>, "mpls(_at_)ietf(_dot_)org <mailto:mpls(_at_)ietf(_dot_)org>"
<mpls(_at_)ietf(_dot_)org <mailto:mpls(_at_)ietf(_dot_)org>>, "gen-art(_at_)ietf(_dot_)org
<mailto:gen-art(_at_)ietf(_dot_)org>" <gen-art(_at_)ietf(_dot_)org
<mailto:gen-art(_at_)ietf(_dot_)org>>,
"draft-ietf-mpls-residence-time(_dot_)all(_at_)ietf(_dot_)org
<mailto:draft-ietf-mpls-residence-time(_dot_)all(_at_)ietf(_dot_)org>"
<draft-ietf-mpls-residence-time(_dot_)all(_at_)ietf(_dot_)org
<mailto:draft-ietf-mpls-residence-time(_dot_)all(_at_)ietf(_dot_)org>>, "ietf(_at_)ietf(_dot_)org
<mailto:ietf(_at_)ietf(_dot_)org>" <ietf(_at_)ietf(_dot_)org <mailto:ietf(_at_)ietf(_dot_)org>>,
"isis-chairs(_at_)ietf(_dot_)org <mailto:isis-chairs(_at_)ietf(_dot_)org>"
<isis-chairs(_at_)ietf(_dot_)org <mailto:isis-chairs(_at_)ietf(_dot_)org>>, "Abhay Roy
(akr)" <akr(_at_)cisco(_dot_)com <mailto:akr(_at_)cisco(_dot_)com>>
*Subject: *RE: [mpls] Review of draft-ietf-mpls-residence-time-12
Acee,
We discussed all of this with you over a year ago and used your
guidance in adding the indication of RTM capability to OSPF.
I’m sorry but I focused mainly on the OSPF protocol aspects then and
didn’t question the use case. This question came up in the IS-IS WG
discussions.
Thanks,
Acee
Yours Irrespectively,
John
*From:*Acee Lindem (acee) [mailto:acee(_at_)cisco(_dot_)com]
*Sent:* Thursday, January 19, 2017 11:38 AM
*To:* Alexander Vainshtein
<Alexander(_dot_)Vainshtein(_at_)ecitele(_dot_)com
<mailto:Alexander(_dot_)Vainshtein(_at_)ecitele(_dot_)com>>; Greg Mirsky
<gregimirsky(_at_)gmail(_dot_)com
<mailto:gregimirsky(_at_)gmail(_dot_)com>>; Les
Ginsberg (ginsberg) <ginsberg(_at_)cisco(_dot_)com
<mailto:ginsberg(_at_)cisco(_dot_)com>>
*Cc:* Robert Sparks <rjsparks(_at_)nostrum(_dot_)com
<mailto:rjsparks(_at_)nostrum(_dot_)com>>; mpls(_at_)ietf(_dot_)org
<mailto:mpls(_at_)ietf(_dot_)org>; gen-art(_at_)ietf(_dot_)org
<mailto:gen-art(_at_)ietf(_dot_)org>;
draft-ietf-mpls-residence-time(_dot_)all(_at_)ietf(_dot_)org
<mailto:draft-ietf-mpls-residence-time(_dot_)all(_at_)ietf(_dot_)org>;
ietf(_at_)ietf(_dot_)org <mailto:ietf(_at_)ietf(_dot_)org>;
isis-chairs(_at_)ietf(_dot_)org
<mailto:isis-chairs(_at_)ietf(_dot_)org>; Abhay Roy (akr)
<akr(_at_)cisco(_dot_)com
<mailto:akr(_at_)cisco(_dot_)com>>
*Subject:* Re: [mpls] Review of draft-ietf-mpls-residence-time-12
I guess what we were trying to envision the use case and whether
it makes sense for all the nodes in the IGP routing domain to have
this information. Would the LSP ingress LSR only need to if the
egress LSR supports RTM and it is best effort recording for
transit LSRs in the path?
Additionally, if it is needed in the IGPs, should there also be a
BGP-LS Link Attribute TLV proposed?
Thanks,
Acee
*From: *Alexander Vainshtein
<Alexander(_dot_)Vainshtein(_at_)ecitele(_dot_)com
<mailto:Alexander(_dot_)Vainshtein(_at_)ecitele(_dot_)com>>
*Date: *Thursday, January 19, 2017 at 10:15 AM
*To: *Greg Mirsky <gregimirsky(_at_)gmail(_dot_)com
<mailto:gregimirsky(_at_)gmail(_dot_)com>>, "Les Ginsberg (ginsberg)"
<ginsberg(_at_)cisco(_dot_)com <mailto:ginsberg(_at_)cisco(_dot_)com>>
*Cc: *Acee Lindem <acee(_at_)cisco(_dot_)com
<mailto:acee(_at_)cisco(_dot_)com>>, Robert
Sparks <rjsparks(_at_)nostrum(_dot_)com
<mailto:rjsparks(_at_)nostrum(_dot_)com>>,
"mpls(_at_)ietf(_dot_)org <mailto:mpls(_at_)ietf(_dot_)org>"
<mpls(_at_)ietf(_dot_)org
<mailto:mpls(_at_)ietf(_dot_)org>>, "gen-art(_at_)ietf(_dot_)org
<mailto:gen-art(_at_)ietf(_dot_)org>" <gen-art(_at_)ietf(_dot_)org
<mailto:gen-art(_at_)ietf(_dot_)org>>,
"draft-ietf-mpls-residence-time(_dot_)all(_at_)ietf(_dot_)org
<mailto:draft-ietf-mpls-residence-time(_dot_)all(_at_)ietf(_dot_)org>"
<draft-ietf-mpls-residence-time(_dot_)all(_at_)ietf(_dot_)org
<mailto:draft-ietf-mpls-residence-time(_dot_)all(_at_)ietf(_dot_)org>>,
"ietf(_at_)ietf(_dot_)org <mailto:ietf(_at_)ietf(_dot_)org>"
<ietf(_at_)ietf(_dot_)org
<mailto:ietf(_at_)ietf(_dot_)org>>, "isis-chairs(_at_)ietf(_dot_)org
<mailto:isis-chairs(_at_)ietf(_dot_)org>" <isis-chairs(_at_)ietf(_dot_)org
<mailto:isis-chairs(_at_)ietf(_dot_)org>>, "Abhay Roy (akr)"
<akr(_at_)cisco(_dot_)com
<mailto:akr(_at_)cisco(_dot_)com>>
*Subject: *RE: [mpls] Review of draft-ietf-mpls-residence-time-12
Hi all,
I concur with Greg: from my POV an interoperable solution
should not depend on an omniscient NMS client distributing
information about capabilities of each node to each other node.
Regards,
Sasha
Office: +972-39266302
Cell: +972-549266302
Email: Alexander(_dot_)Vainshtein(_at_)ecitele(_dot_)com
<mailto:Alexander(_dot_)Vainshtein(_at_)ecitele(_dot_)com>
*From:*Greg Mirsky [mailto:gregimirsky(_at_)gmail(_dot_)com]
*Sent:* Thursday, January 19, 2017 6:01 PM
*To:* Les Ginsberg (ginsberg) <ginsberg(_at_)cisco(_dot_)com
<mailto:ginsberg(_at_)cisco(_dot_)com>>
*Cc:* Acee Lindem (acee) <acee(_at_)cisco(_dot_)com
<mailto:acee(_at_)cisco(_dot_)com>>; Robert Sparks
<rjsparks(_at_)nostrum(_dot_)com
<mailto:rjsparks(_at_)nostrum(_dot_)com>>; mpls(_at_)ietf(_dot_)org
<mailto:mpls(_at_)ietf(_dot_)org>; gen-art(_at_)ietf(_dot_)org
<mailto:gen-art(_at_)ietf(_dot_)org>;
draft-ietf-mpls-residence-time(_dot_)all(_at_)ietf(_dot_)org
<mailto:draft-ietf-mpls-residence-time(_dot_)all(_at_)ietf(_dot_)org>;
ietf(_at_)ietf(_dot_)org <mailto:ietf(_at_)ietf(_dot_)org>;
isis-chairs(_at_)ietf(_dot_)org
<mailto:isis-chairs(_at_)ietf(_dot_)org>; Abhay Roy (akr)
<akr(_at_)cisco(_dot_)com
<mailto:akr(_at_)cisco(_dot_)com>>
*Subject:* Re: [mpls] Review of draft-ietf-mpls-residence-time-12
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)
<ginsberg(_at_)cisco(_dot_)com <mailto:ginsberg(_at_)cisco(_dot_)com>>
wrote:
Greg –
I am having trouble understanding your response.
The question we are raising is whether we should extend
the IGPs to support advertising RTM capability – an
alternative being to retrieve the capability via network
management.
Saying that the IGP functionality is optional and/or
wouldn’t always be advertised doesn’t really answer the
question of whether we should or should not define the IGP
extensions.
Could you respond more directly to this point?
Les
*From:*Greg Mirsky [mailto:gregimirsky(_at_)gmail(_dot_)com
<mailto:gregimirsky(_at_)gmail(_dot_)com>]
*Sent:* Thursday, January 19, 2017 7:44 AM
*To:* Acee Lindem (acee)
*Cc:* Robert Sparks; mpls(_at_)ietf(_dot_)org
<mailto:mpls(_at_)ietf(_dot_)org>;
gen-art(_at_)ietf(_dot_)org <mailto:gen-art(_at_)ietf(_dot_)org>;
draft-ietf-mpls-residence-time(_dot_)all(_at_)ietf(_dot_)org
<mailto:draft-ietf-mpls-residence-time(_dot_)all(_at_)ietf(_dot_)org>;
ietf(_at_)ietf(_dot_)org <mailto:ietf(_at_)ietf(_dot_)org>; Les
Ginsberg
(ginsberg); isis-chairs(_at_)ietf(_dot_)org
<mailto:isis-chairs(_at_)ietf(_dot_)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, thus allowing SDN scenario you've described.
Regards,
Greg
On Wed, Jan 18, 2017 at 2:51 PM, Acee Lindem (acee)
<acee(_at_)cisco(_dot_)com <mailto:acee(_at_)cisco(_dot_)com>>
wrote:
Hi Greg,
Although it is a bit late, we’ve had some discussions
amongst the IS-IS and OSPF chairs and are wondering
whether the interface capability belongs in the IGPs. This
will be flooded throughout the entire routing domain – 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 easily query them using
YANG?
Thanks,
Acee
*From: *mpls <mpls-bounces(_at_)ietf(_dot_)org
<mailto:mpls-bounces(_at_)ietf(_dot_)org>> on behalf of Greg Mirsky
<gregimirsky(_at_)gmail(_dot_)com
<mailto:gregimirsky(_at_)gmail(_dot_)com>>
*Date: *Wednesday, January 18, 2017 at 1:25 PM
*To: *Robert Sparks <rjsparks(_at_)nostrum(_dot_)com
<mailto:rjsparks(_at_)nostrum(_dot_)com>>
*Cc: *"mpls(_at_)ietf(_dot_)org <mailto:mpls(_at_)ietf(_dot_)org>"
<mpls(_at_)ietf(_dot_)org <mailto:mpls(_at_)ietf(_dot_)org>>,
"gen-art(_at_)ietf(_dot_)org
<mailto:gen-art(_at_)ietf(_dot_)org>" <gen-art(_at_)ietf(_dot_)org
<mailto:gen-art(_at_)ietf(_dot_)org>>,
"draft-ietf-mpls-residence-time(_dot_)all(_at_)ietf(_dot_)org
<mailto:draft-ietf-mpls-residence-time(_dot_)all(_at_)ietf(_dot_)org>"
<draft-ietf-mpls-residence-time(_dot_)all(_at_)ietf(_dot_)org
<mailto:draft-ietf-mpls-residence-time(_dot_)all(_at_)ietf(_dot_)org>>,
"ietf(_at_)ietf(_dot_)org <mailto:ietf(_at_)ietf(_dot_)org>"
<ietf(_at_)ietf(_dot_)org
<mailto:ietf(_at_)ietf(_dot_)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 in Section 2 per your suggestion.
Regards,
Greg
On Wed, Jan 18, 2017 at 10:34 AM, Robert Sparks
<rjsparks(_at_)nostrum(_dot_)com
<mailto:rjsparks(_at_)nostrum(_dot_)com>>
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 making those measurements consistently. (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 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 "as 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
"referred 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
<gregimirsky(_at_)gmail(_dot_)com
<mailto:gregimirsky(_at_)gmail(_dot_)com>> 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 you 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
<rjsparks(_at_)nostrum(_dot_)com
<mailto:rjsparks(_at_)nostrum(_dot_)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. 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
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].