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) <ginsb...@cisco.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:gregimir...@gmail.com] > *Sent:* Thursday, January 19, 2017 7:44 AM > *To:* Acee Lindem (acee) > *Cc:* Robert Sparks; m...@ietf.org; gen-art@ietf.org; > draft-ietf-mpls-residence-time....@ietf.org; i...@ietf.org; Les Ginsberg > (ginsberg); isis-cha...@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, thus > allowing SDN scenario you've described. > > > > Regards, > > Greg > > > > On Wed, Jan 18, 2017 at 2:51 PM, Acee Lindem (acee) <a...@cisco.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-boun...@ietf.org> on behalf of Greg Mirsky < > gregimir...@gmail.com> > *Date: *Wednesday, January 18, 2017 at 1:25 PM > *To: *Robert Sparks <rjspa...@nostrum.com> > *Cc: *"m...@ietf.org" <m...@ietf.org>, "gen-art@ietf.org" < > gen-art@ietf.org>, "draft-ietf-mpls-residence-time....@ietf.org" < > draft-ietf-mpls-residence-time....@ietf.org>, "i...@ietf.org" < > i...@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 in > Section 2 per your suggestion. > > > > Regards, > > Greg > > > > On Wed, Jan 18, 2017 at 10:34 AM, Robert Sparks <rjspa...@nostrum.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 <gregimir...@gmail.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 <rjspa...@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. 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 Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
