Hi Greg, The question about whether we need a new variable wasn’t referring to MultipointClient state (I agree this is well explained). Since I mentioned “state variable” I realize the confusion…
The question was whether we need a new state variable (not for the MultipointClient state) to control the behavior explained in this paragraph, e.g the new state variable could be called bfd.TrackTails. If the head wishes to know the identity of the tails, it sends multipoint Polls as needed. Previously known tails that don't respond to the Polls will be detected. Regards, Reshad. On 2018-01-31, 8:41 PM, "Greg Mirsky" <[email protected]> wrote: Hi Reshad, thank you for your expedient response to the proposed update. I'll mark the draft as potentially updating RFCs 5880 and 7880. I'm glad that you consider acceptable almost all proposed changes. I think that the one open questions is: - 3.4. 3rd paragraph : add reference to section 5.3? Also do we need a state variable which controls this behaviour (discovering tails)? GIM>> In the reverse order. Then the variable be per tail? What if number of tails is unknown to the head? I'd rather not define that in the base specification. <RR> No, the variable would be on the head for all tails. Let me try to construct already defined variables: - section New State Variable Value has defined MultipointClient as the new state of bfd.SessionType: MultipointClient: A session on the head that tracks the state of an individual tail, when desirable. That is how MultipointClient use explained in section Multipoint Client Session. I think that the text in the remainder of the Controlling Multipoint BFD Options does provide reasonable explanation of use of MultipointClient state. What do you think? Regards, Greg On Wed, Jan 31, 2018 at 4:51 PM, Reshad Rahman (rrahman) <[email protected]> wrote: > Hi Greg, > > Please see inline <RR>. > > Regards, > Reshad. > > > On 2018-01-30, 10:47 PM, "Greg Mirsky" <[email protected]> wrote: > > Hi Reshad, > thank you for your detailed review of > draft-ietf-bfd-multipoint-active-tail and comments. I have copied > parts of the review an i-lined my answers and notes tagged GIM>>. > I've attached the diff to highlight the update and the new working > version of the draft. Greatly appreciate your help. > > Regards, > Greg > > :(16) Will publication of this document change the status of any > : existing RFCs? Are those RFCs listed on the title page header, listed > : in the abstract, and discussed in the introduction? If the RFCs are not > : listed in the Abstract and Introduction, explain why, and point to the > : part of the document where the relationship of this document to the > : other RFCs is discussed. If this information is not in the document, > : explain why the WG considers it unnecessary. > This document will update RFCs 5880 and 7880. They are not in the > title page header. > GIM>> This draft is Informational while RFCs 5880 and 7880 are > Standard track. Would an Informational track document be updating > Standard? Please confirm. > <RR> This draft was experimental at a certain point but got changed to Standards Track because AFAIR of a normative reference from the TRILL P2MP BFD. > > - General. There are a few instances where singular is used instead of > plural (e.g. for session, tail) and also where “a” or “the” is > missing. I have tried to indicate all such occurrences below. > - General. A few sentences have the period ‘.’ before the closing > parenthesis instead of after, e.g. in Introduction “path as is > feasible.)”. I have not called out all of them, search for “.)” > GIM>> I think I've hunted down them all down. > > - 1 Introduction. s/which allows tail/which allows tails/ > - 1 Introduction. Clarifications/explanations are desirable on “it is > preferable if unicast paths share as little fate with the multipoint > path as is feasible.)” > GIM>> Please consider the following text update: > OLD TEXT > and in fact it is preferable if unicast paths share as little fate > with the multipoint path as is feasible > NEW TEXT > and in fact it is preferable if unicast paths share as little fate > with the multipoint path as is feasible, so to increase probability of > delivering the notification from the tail to the head) > <RR> Ack. > > - 1 Introduction. s/Goal of this application/The goal of this application/ > GIM>> Done > - 1 Introduction mentions “…state implosion towards the head”. Not > sure implosion is the right term there, if it is the right term then > clarification is needed. > GIM>> Agree. I think that 'state explosion' is what we're concerned > with.Would s/implosion/explosion/ be acceptable? > <RR> Ack. > > - 2 Overview. Change “Head may wish” to “A head may wish” or “Heads may wish” > GIM>> Used the former. > - 2 Overview. “…the head can direct the tails to transmit…”: add > reference or explanation on how the head does that. Also > s/direct/request/? > GIM>> Controlling Multipoint BFD Options section provides the details. > Will add reference ', as described in Section 3.4' Would that address > this comment? > <RR> Yes. > > - 2 Overview. 1st paragraph, I know it’s obvious when you read the > draft but might be good to have 1 sentence to explain why this is > unreliable. > GIM>> Section 5.2 gives good explanation of what is being considered > unreliable. I' agree that using different shades of reliable > notification to the head is not the best terminology but I don't have > better to offer. Would reference to section 5.2 be acceptable? Do we > want to characterize the level of guaranteed notification to the head > otherwise than 'notification reliability'? > <RR> Reference to 5.2 is good enough. > > - 2 Overview. 3rd paragraph: s/as a unicast to the tail/as a unicast > to that tail/? > GIM>> Done > - 2 Overview. 3rd paragraph: “or the single reply thereto is lost”, > rephrase that sentence e.g. to “or the single reply os also lost”? > GIM>> ".. or the single reply also lost ..." > <RR> Ack. > > - 2 Overview. “If some tails are more equal than others…”. I know what > you mean but plus change the wording. > GIM>> Proposed update: > OLD TEXT > If some tails are more equal than others, ... > NEW TEXT > If the awareness of the state of some nodes is more important for the head, ... > <RR> Ack. > > - 3 Protocol Details. s/This section is update/This section is an update/ > - 3.2 Multipoint Client Session Failure. s/know the tail state/know > the tail’s state/ > GIM>> Done and done. > > - 3.3 State Variables. As discussed, bfd.SessionType should be in “new > variable values” section and the others in “new variables” section. > - 3.3.1 New State Variables. The paragraph on bfd.ReportTailDown says > “If 0, the tail..”. Mention that the packets sent from the tail are in > response to the head’s periodic BFD control packets? Also when set to > 1, how do the tails know from the head that they need to notify the > head? This paragraph needs some clarification. > 3.3.2 State Variable Initialization and Maintenance. s/section 6.8.1 > of the [RFC5880] needs/section 6.8.1 of [RFC5880] need/ > - 3.4 Controlling Multipoint BFD Options. 2nd paragraph: add reference > to section 5.1? > GIM>> Agree > - 3.4. 3rd paragraph : add reference to section 5.3? Also do we need a > state variable which controls this behaviour (discovering tails)? > GIM>> In the reverse order. > Then the variable be per tail? What if number of tails is unknown to > the head? I'd rather not define that in the base specification. > <RR> No, the variable would be on the head for all tails. > > Reference added. > - 3.4. Paragraph 5 should be after paragraph 3? > GIM>> I agree, makes the narrative more logical. > - 3.4. Paragraph 6, regarding “initial delay”, add a reference to > 3.13.3 which describes the delay. > - 3.5 State Machine. s/State machine for/The state machine for/ > GIM>> Done and done > - 3.8 Soliciting the Tails. “random delay”, add a reference to 3.13.3 > which describes the delay. > - 3.13. “in the base specification” refers to base BFD or base BFD > multipoint? Add a reference. > GIM>> In fact it is both. Added references accordingly. > - 3.13.1. Should reception at head also be covered here? If not, add > “at tail” to the title > GIM>> You're right, the changes update processing at MultipointTail > but the base specification does not differentiate processing of the > received BFD control packet based on the bfd.SessionType. I propose to > have the text without update. > - 3.13.1. s/by head below procedure MUST be/by the head, the procedure > below MUST be/ > GIM>> Agree. I think more changes can benefit the text: > OLD TEXT > In addition to that if tail tracking is desired by head below > procedure MUST be applied. > NEW TEXT > In addition to that, if tail tracking is desired by head, below > procedure MUST be applied. > Would you agree? > <RR> Ack. > > - 3.13.1 and 3.13.2. Both are adding to the procedures in > draft-ietf-bfd-multipoint, specify where the addition is taking place > (e.g. at the end). > GIM>> > - 7 Security Considerations. Should we add at the beginning “The same > security considerations as those described in [RFC5880] and > [I-D.ietf-bfd-multipoint] apply to this document.”? > GIM>> Agree. > > On Wed, Jan 24, 2018 at 2:42 PM, Reshad Rahman (rrahman) > <[email protected]> wrote: > > Hi, > > > > > > > > I forgot to mention that last week I did the shepherd write-up for both > > drafts. > > > > > > > > https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint/shepherdwriteup/ > > > > https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint-active-tail/shepherdwriteup/ > > > > > > > > Regards, > > > > Reshad. > > > > > > > > From: Greg Mirsky <[email protected]> > > Date: Tuesday, January 16, 2018 at 11:01 PM > > > > > > To: "Reshad Rahman (rrahman)" <[email protected]> > > Cc: "Carlos Pignataro (cpignata)" <[email protected]>, Jeffrey Haas > > <[email protected]>, "[email protected]" <[email protected]> > > Subject: Re: WGLC for BFD Multipoint documents (last round) > > > > > > > > Hi Reshad, > > > > sorry for my sloppiness. Fixed. > > > > > > > > Regards, Greg > > > > > > > > On Jan 16, 2018 7:05 PM, "Reshad Rahman (rrahman)" <[email protected]> > > wrote: > > > > Hi Greg, > > > > > > > > In 4.4.1 of MP, “A number values of the state variable are added to the…”, > > looks like there is a missing “of”? > > > > > > > > For the active-tail draft I haven’t completed my review of -06 yet: there > > are parts which aren’t clear to me and I don’t know yet if this is because > > there’s something missing in the document or whether it’s just lack of > > understanding on my part. > > > > > > > > Regards, > > > > Reshad. > > > > > > > > From: Greg Mirsky <[email protected]> > > Date: Tuesday, January 16, 2018 at 9:25 PM > > To: "Reshad Rahman (rrahman)" <[email protected]> > > Cc: "Carlos Pignataro (cpignata)" <[email protected]>, Jeffrey Haas > > <[email protected]>, "[email protected]" <[email protected]> > > Subject: Re: WGLC for BFD Multipoint documents (last round) > > > > > > > > Hi Reshad, et. al, > > > > the attached are diff to highlight updates to BFD in Multipoint Network and > > the working copy of Active Tails. After checking through the Active Tails > > draft, I've found no additional changes to make resulting from removing all > > references to bfd.SilentTail from BFD in Multipoint Networks draft. Your > > review and comments are most welcome. > > > > > > > > Regards, > > > > Greg > > > > > > > > On Tue, Jan 16, 2018 at 2:51 PM, Greg Mirsky <[email protected]> wrote: > > > > Hi Reshad, > > > > thank you. I'll add it into the working version to others updates. I believe > > changes to active tails be more extensive as now it must introduce the > > bfd.SilentTail variable, not just its new state. Will work on that now. > > > > > > > > Regards, > > > > Greg > > > > > > > > On Tue, Jan 16, 2018 at 1:58 PM, Reshad Rahman (rrahman) <[email protected]> > > wrote: > > > > Hi Greg, > > > > > > > > I am fine with the change below. > > > > > > > > Regards, > > > > Reshad. > > > > > > > > From: Greg Mirsky <[email protected]> > > Date: Tuesday, January 16, 2018 at 2:20 PM > > To: "Reshad Rahman (rrahman)" <[email protected]> > > Cc: "Carlos Pignataro (cpignata)" <[email protected]>, Jeffrey Haas > > <[email protected]>, "[email protected]" <[email protected]> > > > > > > Subject: Re: WGLC for BFD Multipoint documents (last round) > > > > > > > > Hi Reshad, > > > > I think this is very good idea. Then in section 4.13.3 Transmitting BFD > > Packets of BFD for Multipoint Networks should be edited. Perhaps the > > following be acceptable: > > > > OLD TEXT > > > > A system MUST NOT transmit any BFD Control packets if bfd.SilentTail > > > > is 1. > > > > NEW TEXT > > > > A system MUST NOT transmit any BFD Control packets if bfd.SessionType is > > > > MultipointTail. > > > > Will look into related changes in active tails if others agree with the > > proposal in general. > > > > > > > > Regards, > > > > Greg > > > > > > > > > > > > On Tue, Jan 16, 2018 at 10:53 AM, Reshad Rahman (rrahman) > > <[email protected]> wrote: > > > > Regarding bfd.SilentTail, I am wondering if instead it should be removed > > from MP draft (always 1 in there) and kept as new state variable in > > active-tail? > > > > > > > > Regards, > > > > Reshad. > > > > > > > > From: "Reshad Rahman (rrahman)" <[email protected]> > > Date: Tuesday, January 16, 2018 at 9:32 AM > > To: "Carlos Pignataro (cpignata)" <[email protected]>, Greg Mirsky > > <[email protected]> > > Cc: Jeffrey Haas <[email protected]>, "[email protected]" <[email protected]> > > > > > > Subject: Re: WGLC for BFD Multipoint documents (last round) > > > > > > > > Hi Greg, > > > > > > > > The changes for bfd.SessionType (in both drafts) look good. > > > > > > > > bfd.SilentTail is fine in multipoint but in active-tail it is in the New > > State Variables section. It should be in 3.3.2 instead and there should be > > a reference to the multipoint draft. > > > > > > > > Also, I am in the process of doing the shepherd write-up. So you don’t have > > to push these changes immediately, you can wait for the review, up to you. > > > > > > > > Regards, > > > > Reshad. > > > > > > > > From: "Carlos Pignataro (cpignata)" <[email protected]> > > Date: Tuesday, January 16, 2018 at 1:47 AM > > To: Greg Mirsky <[email protected]> > > Cc: "Reshad Rahman (rrahman)" <[email protected]>, Jeffrey Haas > > <[email protected]>, "[email protected]" <[email protected]> > > Subject: Re: WGLC for BFD Multipoint documents (last round) > > > > > > > > Looks good to me, Greg. Thanks. > > > > Thumb typed by Carlos Pignataro. > > > > Excuze typofraphicak errows > > > > > > On Jan 16, 2018, at 15:32, Greg Mirsky <[email protected]> wrote: > > > > Hi Reshad and Carlos, > > > > thank you for your suggestions. Please check the diffs with proposed changes > > to BFD Multipoint and BFD Multipoint with active tails drafts (attached). > > > > > > > > Regards, > > > > Greg > > > > > > > > On Mon, Jan 15, 2018 at 8:25 PM, Carlos Pignataro (cpignata) > > <[email protected]> wrote: > > > > Reshad, Greg, > > > > > > > > Indeed, it seems the content of the section is updated, but the title is > > misleading. The same applies to the active-tail doc: > > > > > > > > https://tools.ietf.org/html/draft-ietf-bfd-multipoint-active-tail-06#section-3.3.1 > > > > https://tools.ietf.org/html/draft-ietf-bfd-multipoint-12#section-4.4.1 > > > > > > > > Thanks, > > > > > > > > — > > Carlos Pignataro, [email protected] > > > > “Sometimes I use big words that I do not fully understand, to make myself > > sound more photosynthesis." > > > > > > > > On Jan 16, 2018, at 10:52 AM, Reshad Rahman (rrahman) <[email protected]> > > wrote: > > > > > > > > Hi Greg, > > > > > > > > Section 4.4.1 still says “New state variables” for bfd.SessionType and the > > text still starts with “A number of state variables and their values are > > added…”, so I misinterpreted that as bfd.SessionType is being added as new > > state variable. > > > > > > > > Please consider splitting this section in 2 parts for clarification e.g. > > 4.4.1 for New State Variables (bfd.SilentTail) and 4.4.2 for New State > > Variable Values (bfd.SessionType). > > > > > > > > https://tools.ietf.org/html/draft-ietf-bfd-multipoint-12#section-4.4.1 > > > > > > > > Regards, > > > > Reshad. > > > > > > > > From: Greg Mirsky <[email protected]> > > Date: Monday, January 15, 2018 at 6:17 PM > > To: "Reshad Rahman (rrahman)" <[email protected]> > > Cc: Jeffrey Haas <[email protected]>, "Carlos Pignataro (cpignata)" > > <[email protected]>, "[email protected]" <[email protected]> > > Subject: Re: WGLC for BFD Multipoint documents (last round) > > > > > > > > Hi Reshad, > > > > I thought I've addressed them as per Carlos suggestion. Have I missed > > anything? > > > > > > > > Regards, Greg > > > > > > > > On Jan 15, 2018 3:00 PM, "Reshad Rahman (rrahman)" <[email protected]> > > wrote: > > > > The changes for bfd.SessionType (it’s not a new state variable but uses > > what’s defined in RFC7880) weren’t made in the latest revision. > > > > Greg, do you plan on addressing this soon? Or there’s no consensus on this > > topic yet? > > > > Regards, > > Reshad. > > > > On 2017-12-20, 12:09 PM, "Rtg-bfd on behalf of Jeffrey Haas" > > <[email protected] on behalf of [email protected]> wrote: > > > > Greg, > > > > On Tue, Dec 19, 2017 at 02:17:02PM -0800, Greg Mirsky wrote: > > > Hi Carlos and Jeff, > > > thank you for responding so expediently. I think we've reached the > > rough > > > consensus. Attached are the diffs for both BFD documents and the > > updated > > > copies. Please let me know if the changes being made have addressed > > all the > > > comments received during the WGLC. I'll then upload new versions. > > > > I believe this covers all points I've seen on the mailing list to date. > > > > Please push the updates. > > > > We'll have further discussion about the need for a registry in > > conjunction > > with the Yang module implications discussion. > > > > -- Jeff > > > > > On Tue, Dec 19, 2017 at 8:05 AM, Jeffrey Haas <[email protected]> wrote: > > [...] > > > > At this point it is also worth noting that the session type has no > > > > centralized location covering their enumerations. This leads to two > > > > interesting observations: > > > > - We could have an IANA registry for such things. However, I'm not > > sure > > > > this is really need. But this also means: > > > > - Here's another case why some pieces of the BFD yang module likely > > shoudl > > > > be IANA maintained. In this case, the bfd-path-type identity as > > the > > > > relevant example. > > > > > > > > > > > > <Diff_ draft-ietf-bfd-multipoint-active-tail-06.txt - > > draft-ietf-bfd-multipoint-active-tail-07.txt.html> > > > > <Diff_ draft-ietf-bfd-multipoint-12.txt - > > draft-ietf-bfd-multipoint-13.txt.html> > > > > > > > > > > > > > >
