Les,
While the capability may be of generic value, it is most useful
when used to select an explicit path. We target MPLS in the draft for a large
number of reasons, but most importantly because this is the currently most
common mechanism for realistic explicit paths.
At least as far as I am aware. :)
If there are other common approaches to selecting and
establishing an explicit path, it is likely that there will be not much in
common with the specifics for establishing such paths with the means we define
in this specification. That would argue for a separate (set of) draft(s) to
support any such other approach(es).
Also, because the essential enabling capability for doing RTM
relies heavily (if not entirely) on hardware capabilities (because it is done
to packets as they are being forwarded) the capability would most likely be
explicitly tied to specific forwarding technologies, the capability will be
very much tied to specific hardware capabilities of a hardware interface.
While it is relatively easy to imagine a means for generic
support of RTM, it is not at all certain that this will be common, let alone
universal.
--
Eric
From: Les Ginsberg (ginsberg) [mailto:[email protected]]
Sent: Thursday, January 19, 2017 4:46 PM
To: Eric Gray <[email protected]>; Uma Chunduri <[email protected]>;
John E Drake <[email protected]>; Acee Lindem (acee) <[email protected]>;
Alexander Vainshtein <[email protected]>; Greg Mirsky
<[email protected]>
Cc: [email protected]; [email protected]; [email protected]; [email protected];
[email protected]; Abhay Roy (akr) <[email protected]>;
Robert Sparks <[email protected]>
Subject: RE: [mpls] Review of draft-ietf-mpls-residence-time-12
Importance: High
Eric -
From: Eric Gray [mailto:[email protected]]
Sent: Thursday, January 19, 2017 12:32 PM
To: Les Ginsberg (ginsberg); Uma Chunduri; John E Drake; Acee Lindem (acee);
Alexander Vainshtein; Greg Mirsky
Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>;
Abhay Roy (akr); Robert Sparks
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.
[Les:] There is context you may not have.
"I" only became aware of this because - as one of the Designated Experts for
IS-IS Registries - I was asked by IANA to approve the allocation of codepoints
for the GENINFO proposal in the draft.
It would have been better had the IGP WGs been apprised of this draft and asked
for feedback earlier in the process - but AFAIK that did not happen. This is a
bit strange given that the draft authors include folks with long experience in
MPLS/IGP interworking - but I am not trying to place blame. For whatever reason
this did not happen.
I do appreciate how late in the game this discussion is - but as I do not
personally follow MPLS drafts in general I was unaware of this draft until the
IANA request was sent.
Too late to fix this now - but something to be considered in the future when
there are IGP extensions involved in MPLS Drafts.
But I have some difficulty is seeing how this usage is "clearly
not TE information."
[Les:] The packet timing capability which you are asking IGPs to advertise is a
generic capability which could be used for many purposes. The fact that you are
applying it to MPLS LSPs does not make the capability an MPLS/TE related
capability.
Les
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:[email protected]] On Behalf Of Les Ginsberg (ginsberg)
Sent: Thursday, January 19, 2017 3:11 PM
To: Uma Chunduri <[email protected]<mailto:[email protected]>>;
John E Drake <[email protected]<mailto:[email protected]>>; Acee Lindem
(acee) <[email protected]<mailto:[email protected]>>; Alexander Vainshtein
<[email protected]<mailto:[email protected]>>;
Greg Mirsky <[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>;
Abhay Roy (akr) <[email protected]<mailto:[email protected]>>; Robert Sparks
<[email protected]<mailto:[email protected]>>
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:[email protected]]
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); [email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>;
Robert Sparks; [email protected]<mailto:[email protected]>
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:[email protected]] On Behalf Of Les Ginsberg (ginsberg)
Sent: Thursday, January 19, 2017 9:25 AM
To: John E Drake <[email protected]<mailto:[email protected]>>; Acee Lindem
(acee) <[email protected]<mailto:[email protected]>>; Alexander Vainshtein
<[email protected]<mailto:[email protected]>>;
Greg Mirsky <[email protected]<mailto:[email protected]>>
Cc: Abhay Roy (akr) <[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>;
Robert Sparks <[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>
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:[email protected]]
Sent: Thursday, January 19, 2017 8:54 AM
To: Acee Lindem (acee); Alexander Vainshtein; Greg Mirsky; Les Ginsberg
(ginsberg)
Cc: Robert Sparks; [email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>; 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:[email protected]]
Sent: Thursday, January 19, 2017 11:47 AM
To: John E Drake <[email protected]<mailto:[email protected]>>; Alexander
Vainshtein
<[email protected]<mailto:[email protected]>>;
Greg Mirsky <[email protected]<mailto:[email protected]>>; Les Ginsberg
(ginsberg) <[email protected]<mailto:[email protected]>>
Cc: Robert Sparks <[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>; Abhay Roy (akr)
<[email protected]<mailto:[email protected]>>
Subject: Re: [mpls] Review of draft-ietf-mpls-residence-time-12
Hi John,
From: John E Drake <[email protected]<mailto:[email protected]>>
Date: Thursday, January 19, 2017 at 10:43 AM
To: Acee Lindem <[email protected]<mailto:[email protected]>>, Alexander Vainshtein
<[email protected]<mailto:[email protected]>>,
Greg Mirsky <[email protected]<mailto:[email protected]>>, "Les
Ginsberg (ginsberg)" <[email protected]<mailto:[email protected]>>
Cc: Robert Sparks <[email protected]<mailto:[email protected]>>,
"[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>,
"[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>,
"[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>,
"[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>,
"[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>, "Abhay Roy (akr)"
<[email protected]<mailto:[email protected]>>
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:[email protected]]
Sent: Thursday, January 19, 2017 11:38 AM
To: Alexander Vainshtein
<[email protected]<mailto:[email protected]>>;
Greg Mirsky <[email protected]<mailto:[email protected]>>; Les Ginsberg
(ginsberg) <[email protected]<mailto:[email protected]>>
Cc: Robert Sparks <[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>; Abhay Roy (akr)
<[email protected]<mailto:[email protected]>>
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
<[email protected]<mailto:[email protected]>>
Date: Thursday, January 19, 2017 at 10:15 AM
To: Greg Mirsky <[email protected]<mailto:[email protected]>>, "Les
Ginsberg (ginsberg)" <[email protected]<mailto:[email protected]>>
Cc: Acee Lindem <[email protected]<mailto:[email protected]>>, Robert Sparks
<[email protected]<mailto:[email protected]>>,
"[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>,
"[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>,
"[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>,
"[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>,
"[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>, "Abhay Roy (akr)"
<[email protected]<mailto:[email protected]>>
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:
[email protected]<mailto:[email protected]>
From: Greg Mirsky [mailto:[email protected]]
Sent: Thursday, January 19, 2017 6:01 PM
To: Les Ginsberg (ginsberg) <[email protected]<mailto:[email protected]>>
Cc: Acee Lindem (acee) <[email protected]<mailto:[email protected]>>; Robert Sparks
<[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>; Abhay Roy (akr)
<[email protected]<mailto:[email protected]>>
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)
<[email protected]<mailto:[email protected]>> 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:[email protected]<mailto:[email protected]>]
Sent: Thursday, January 19, 2017 7:44 AM
To: Acee Lindem (acee)
Cc: Robert Sparks; [email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>; Les Ginsberg (ginsberg);
[email protected]<mailto:[email protected]>; 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)
<[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> on behalf of
Greg Mirsky <[email protected]<mailto:[email protected]>>
Date: Wednesday, January 18, 2017 at 1:25 PM
To: Robert Sparks <[email protected]<mailto:[email protected]>>
Cc: "[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>,
"[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>,
"[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>,
"[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>
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
<[email protected]<mailto:[email protected]>> 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
<[email protected]<mailto:[email protected]>> 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
<[email protected]<mailto:[email protected]>> 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].
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
