Hi Reshad, nits fixed and the new text below: OLD TEXT A number of values of the state variable are added to the base BFD… NEW TEXT A number of new values of the state variable bfd.SessionType are added to the base BFD… Would you accept this update?
Regards, Greg On Mon, Jan 29, 2018 at 5:52 AM, Reshad Rahman (rrahman) <rrah...@cisco.com> wrote: > Hi Greg, > > > > - Section 4.2. s/The head has a session of type MultipointHead Section > 4.4.1/ The head has a session of type MultipointHead, as defined in Section > 4.4.1, / > - Section 4.4.1. “A number of values of the state variable are added > to the base BFD…”. That sentence needs rewording IMO but maybe I’m just > missing what it’s trying to convey. > - Section 4.6. s/Active role , / Active role, / > - Section 4.10. “MUST send packets with P bit set.”. Did we agree on > “MUST send packets with *the* P bit set.”? > > > > Regards, > > Reshad. > > > > *From: *Greg Mirsky <gregimir...@gmail.com> > *Date: *Saturday, January 27, 2018 at 11:38 PM > > *To: *"Reshad Rahman (rrahman)" <rrah...@cisco.com> > *Cc: *"Carlos Pignataro (cpignata)" <cpign...@cisco.com>, Jeffrey Haas < > jh...@pfrc.org>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org> > *Subject: *Re: WGLC for BFD Multipoint documents (last round) > > > > Hi Reshad, > > many thanks for your guidance and support. Should I upload the new version > of the draft? > > > > Kind regards, > > Greg > > > > PS. Diff and the current working version are attached. > > > > On Sat, Jan 27, 2018 at 6:36 PM, Reshad Rahman (rrahman) < > rrah...@cisco.com> wrote: > > Thanks Greg. PSI <RR2>. > > > > I think we’ve closed on these comments. > > > > Regards, > > Reshad. > > > > *From: *Greg Mirsky <gregimir...@gmail.com> > *Date: *Friday, January 26, 2018 at 7:42 PM > *To: *"Reshad Rahman (rrahman)" <rrah...@cisco.com> > *Cc: *"Carlos Pignataro (cpignata)" <cpign...@cisco.com>, Jeffrey Haas < > jh...@pfrc.org>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org> > *Subject: *Re: WGLC for BFD Multipoint documents (last round) > > > > Hi Reshad, et. al, > > thank you for your kind consideration of the update. I'm applied all the > changes you've agreed to. Remaining are few nits I wanted to confirm with > you and one update that is not editorial: > > In 4.13.1 > <https://tools.ietf.org/html/draft-ietf-bfd-multipoint-12#section-4.13.1>. > Reception of BFD Control Packets > > OLD TEXT: > > Else (bfd.SessionType is not PointToPoint) > > NEW TEXT > > Else (bfd.SessionType is MultipointTail) > > Please find my notes in-line tagged GIM2>>. > > > > Kind regards, > > Greg > > > > On Fri, Jan 26, 2018 at 7:14 AM, Reshad Rahman (rrahman) < > rrah...@cisco.com> wrote: > > Hi Greg, > > > > Thank you for the prompt response. The changes look good. Some nits I may > missed during my review and nits on new rev: > > - 3 Overview. s/Details of how head keeps track/Details of how heads > keep track/ (or if singular “of how a head keeps track”) > > GIM2>> I think that singular is consistent with the preceding sentence 'A > head may wish to be alerted to the tails' connectivity (or lack thereof).' > And because there's 'a head' should the next reference be 'the head', thus > making 'Details of how the head keeps track ...'? > > <RR2> Good. > > > - > - 4.2 Session Model. References to Section 4.4.1 were added but > consider making a change e.g adding () around the reference or “, as > defined in Section 4.4.1, “ . > > GIM2>> Done > > > - > - 4.4.1 New State Variable Values. First paragraph starts “A number > values of the state variable are added to the base BFD…”. Should be “A > number of values…”? Or reword that paragraph to something along the lines > of “A number of values are added to some existing state variables defined > in the base BFD…” > > GIM2>> Used the former 'A number of values ...' > > <RR2> Ack. > > > - > - 4.10 Timer Manipulation. s/However to indicate a change in the > packets MultipointHead session MUST send packets with P bit set. > MultipointTail session/However to indicate a change in the packets, > MultipointHead sessions MUST send packets with the P bit set. > MultipointTail sessions/ > > GIM2>> Or should it be 'However, to indicate a change in the packets, > MultipointHead MUST send packets with the P bit set.'? > > <RR2> Good. > > > - > > > > Please see inline <RR>. > > > > Regards, > > Reshad. > > > > *From: *Greg Mirsky <gregimir...@gmail.com> > *Date: *Thursday, January 25, 2018 at 4:46 PM > *To: *"Reshad Rahman (rrahman)" <rrah...@cisco.com> > *Cc: *"Carlos Pignataro (cpignata)" <cpign...@cisco.com>, Jeffrey Haas < > jh...@pfrc.org>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org> > *Subject: *Re: WGLC for BFD Multipoint documents (last round) > > > > Hi Reshad, > > sincere thank you for your help and support. In this note I'll address > Shepherd Write-up on BFD for Multipoint Networks draft (active tails will > be addressed in the separate response shortly). Please find my responses to > your comments in-line tagged GIM>>. Attached are diffs to the updated > version and the current working text. > > > > : (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>> Fixed. > > > > - General. There are a few instances where singular is used instead of > plural (e.g. for session, packet) 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 4.9 “(… than it did previously.)”. I > have not called out all of them, search for “.)” > > GIM>> Got 10+ of those > > > > - General. s/this protocol/Multipoint BFD/? > > GIM>> > > - General. Use of term tree e.g. multipoint tree. Should we use path > instead? > > - Abstract. Remove “Comments on this draft…” > > GIM>> Done > > - 1 Introduction. “Details of tail notification…”. Add reference to > draft-ietf-bfd-multipoint-active-tail? > > GIM>> Current text puts them outside the scope. I agree that alternative > may be to point to draft-ietf-bfd-multipoint-active-tail directly, though > then we have new informational reference. Perhaps > > OLD TEXT > > Details of tail notification to head are outside the scope of this > document. > > NEW TEXT > > Details of tail notification to head are outside the scope of this > document and are discussed in [I_D.ietf-bfd-multipoint-active-tail]. > > > > Acceptable? > > <RR> Yes. > > > > - 1 Introduction. s/is not being used in context/is not being used in the > context/ > > GIM>> Done > > - 1 Introduction. Add reference to [RFC5880] after “… and adds to the base > BFD specification.” > > GIM>> Done > > - 1 Introduction. Remove “It is the intention of the authors to fold…” > > GIM>> Done > > - 2 Goals. Not sure about “multicast or multipoint medium”, maybe > “multipoint or multicast path”? > > GIM>> Would "Another goal is for the mechanism to work on any multipoint > network segments or multicast technologies" work? > > <RR> I am fine with something along the lines of "Another goal is for the > mechanism to work on any multicast technology." > > > > - 2 Goals. “… multipoint paths with multiple heads” should that be > “multipoint-to-multipoint”? > > GIM>> Yes, indeed. Would referring to multipoint explicitly as > point-to-multipoint make it more clear? > > OLD TEXT > > A further goal is to support multiple, overlapping multipoint paths, as > well as multipoint paths with multiple heads... > > NEW TEXT > > A further goal is to support multiple, overlapping point-to-multipoint > paths, as well as multipoint-to-multipoint paths ... > > <RR> Yes. > > > > - 2 Goals. Remove “A final goal is to integrate multipoint operation…”. If > this is still relevant we need clarification on how this is being done. May > need to also explain what is meant by “relatively easy” > > GIM>> Agree and done. > > - 2 Goals. s/any tails/any tail/ > > - 2 Goals. s/It is a non-goal/It is not a goal/? > > GIM>> Done and done > > - 3 Overview. s/Details of how head keeps track/Details of how heads keep > track/. Add reference to draft-ietf-bfd-multipoint-active-tail after that > sentence? > > GIM>> Not sure that changing to plural in this sentence is warranted. I > interpret it as reference to a single p2mp BFD session. Would you agree? > > <RR> You’re right, no need for plural. So “Details of how a head keeps > track”? > > > > GIM>> RE: reference to the active tails draft. As noted above, it will > introduce new informational reference. Any concern with that? > > <RR> No need for reference to active-tail. > > > > - 3 Overview. s/Head may wish/A head may wish/ > > GIM>> Done > > - 3 Overview. s/it’s connectivity/its connectivity/ > > GIM>> I think that more extensive change is required here: > > OLD TEXT > > ... how tails alert it's connectivity to head ... > > NEW TEXT > > ... how tails alert their connectivity to the head ... > > or > > ... how tail alerts its connectivity to the head ... > > Acceptable? Which one? > > <RR> I’d go for “…how tails alert their connectivity to the head…”. > > > > - 4.1 Multipoint BFD Control Packets. Add reference to [RFC5880] after > “…via the setting of the M bit.” > > GIM>> Done > > - 4.2 Session Model. s/from the head over multicast path/from the head > over the multicast path/. > > - 4.2 Session Model. MultipointHead and MultipointTail: add reference for > each to section 4.4.1 where they are defined. > > GIM>> Done and done > > > > - 4.4.1 New State Variables. Already discussed splitting this into new > variables and new values. > > - 4.4.1 New State Variables. Already discussed taking bfd.SilentTail out > of draft-ietf-bfd-multipoint > > - 4.4.2 State Variable Initialization and Maintenance. s/defined in > section 6.8.1 of the [RFC5880] needs/defined in section 6.8.1 of [RFC5880] > need/ > > GIM>> Done > > - 4.5 State Machine. s/Session of type/Sessions of type/ > > - 4.5 State Machine. s/and must be ignored/and MUST be ignored/ > > GIM>> Done and done > > - 4.5 State Machine. Should there be a state machine for the head or is it > too simple since no packets are received from tail? e.g. if the multipoint > path goes down does the MultipointHead session go down? > > GIM>> I think that the very last sentence addresses your question: > > Sessions of type MultipointHead never receive packets and have no > > Detection Timer, and as such all state transitions are > > administratively driven. > > <RR> Ack. > > > > - 4.6 Session Establishment. s/Unlike Point-to-point/Unlike point-to-point/ > > GIM>> Done > > - 4.6 Session Establishment. “Except when terminating BFD service…”, does > terminating mean shutting down (as in admin down)? > > GIM>> Yes, I think that is exactly as you've described. Should that be > clarified, e.g. "Except when administratively terminating BFD service ..."? > > <RR> “Except when administratively terminating the BFD service”? > > > > - 4.6 Session establishment. Active and passive roles: add reference to > the appropriate section of [RFC5880]. > > GIM>> Like to Section 6.1 Overview in RFC 5880? How I would refer to the > particular section in XML? > > <RR> Just reference to [5880] is fine. > > > > - 4.7 Discriminators and Packet Demultiplexing. s/over the MultipointHead > session with/over the Multipoint path va the MultipointHead session with/ > > GIM>> Done as s/over the MultipointHead session with/over the multipoint > path via the MultipointHead session with/ > > > > - 4.7. s/PointToPoint/point-to-point/. PointToPoint is to be used only > when referring to bfd.SessionType. > > - 4.7. s/Bootstrapping BFD session to a multipoint LSP/Bootstrapping a BFD > session to multipoint MPLS LSP/ > > - 4.8 Packet consumption on tails. s/for a multicast group/for an IP > multicast group/ > > - 4.8. s/For multipoint LSP/For multipoint LSPs/ > > - 4.8. s/encapsulation of BFD control packet/encapsulation of BFD control > packets/ > > GIM>> Done to all the above > > - For IPv4/IPv6 address range, add reference to [RFC5884]? > > GIM>> I think that first use of martian addresses as IP DA was for LSP > Ping RFC4379 now RFC8029. Should refer to RFC8029? > > <RR> Yes. > > > > - 4.8. s/Packet identified as BFD packet/Packets identified as BFD packets/ > > - 4.8. s/used,/is used,/ > > GIM>> Done and done > > - 4.10 Timer Manipulation. s/However to indicate change in packet/However > to indicate a change in the packets, / > > - 4.10. s/MUST send packet with P bit/MUST send packets with P bit/ > > - 4.10/ s/MultipointHead MAY also/A MultipointHead session MAY also/ > > GIM>> Done * 3 > > - 4.11 Detection times. s/Since the MultipointHead session never receives > packets, it does not/Since MultipointHead sessions never receive packets, > they do not/ > > - 4.11 Detection times. s/the Detection Time/the detection time/ > > GIM>> Done and done > > - 4.13 Base Specification Text Replacement. Clarify here or in the > introduction that processing for point-to-point BFD does NOT change. > > GIM>> Please check if the following update is acceptable > > OLD TEXT > > The following sections are meant to replace the corresponding sections in > the base specification > > NEW TEXT > > The following sections are meant to replace the corresponding sections in > the base specification [RFC5880] > > in support of BFD for multipoint networks while not changing processing > for point-to-point BFD. > > <RR> Ack. > > > > - 4.13.1. Add reference to [RFC5880] before mentioning section 6.7, e.g > “under of rules of section 6.7 of [RFC5880]” > > GIM>> Done on two occurences > > - 4.13.2 P14. If the State field is Init and bfd.SessionType is not > PointToPoint. Instead of checking “is not PointToPoint” should we check “is > MultipointTail”? Otherwise this has an impact on S-BFD? > > GIM>> I agree. Should we get WG confirmation as for technical update or it > is editorial? > > <RR> WG confirmation would be good. > > - 7 Security Considerations. s/ex:/e.g./ > > GIM>> Done > > - 7 Security Considerations. Should we add at the beginning “The same > security considerations as those described in [RFC5880] apply to this > document. Additionally …”? > > GIM>> Agreed and done > > > > On Wed, Jan 24, 2018 at 2:42 PM, Reshad Rahman (rrahman) < > rrah...@cisco.com> 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 <gregimir...@gmail.com> > *Date: *Tuesday, January 16, 2018 at 11:01 PM > > > *To: *"Reshad Rahman (rrahman)" <rrah...@cisco.com> > *Cc: *"Carlos Pignataro (cpignata)" <cpign...@cisco.com>, Jeffrey Haas < > jh...@pfrc.org>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org> > *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)" <rrah...@cisco.com> > 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 <gregimir...@gmail.com> > *Date: *Tuesday, January 16, 2018 at 9:25 PM > *To: *"Reshad Rahman (rrahman)" <rrah...@cisco.com> > *Cc: *"Carlos Pignataro (cpignata)" <cpign...@cisco.com>, Jeffrey Haas < > jh...@pfrc.org>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org> > *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 <gregimir...@gmail.com> > 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) < > rrah...@cisco.com> wrote: > > Hi Greg, > > > > I am fine with the change below. > > > > Regards, > > Reshad. > > > > *From: *Greg Mirsky <gregimir...@gmail.com> > *Date: *Tuesday, January 16, 2018 at 2:20 PM > *To: *"Reshad Rahman (rrahman)" <rrah...@cisco.com> > *Cc: *"Carlos Pignataro (cpignata)" <cpign...@cisco.com>, Jeffrey Haas < > jh...@pfrc.org>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org> > > > *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) < > rrah...@cisco.com> 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)" <rrah...@cisco.com> > *Date: *Tuesday, January 16, 2018 at 9:32 AM > *To: *"Carlos Pignataro (cpignata)" <cpign...@cisco.com>, Greg Mirsky < > gregimir...@gmail.com> > *Cc: *Jeffrey Haas <jh...@pfrc.org>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org> > > > *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)" <cpign...@cisco.com> > *Date: *Tuesday, January 16, 2018 at 1:47 AM > *To: *Greg Mirsky <gregimir...@gmail.com> > *Cc: *"Reshad Rahman (rrahman)" <rrah...@cisco.com>, Jeffrey Haas < > jh...@pfrc.org>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org> > *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 <gregimir...@gmail.com> 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) < > cpign...@cisco.com> 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, car...@cisco.com > > *“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) <rrah...@cisco.com> > 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 <gregimir...@gmail.com> > *Date: *Monday, January 15, 2018 at 6:17 PM > *To: *"Reshad Rahman (rrahman)" <rrah...@cisco.com> > *Cc: *Jeffrey Haas <jh...@pfrc.org>, "Carlos Pignataro (cpignata)" < > cpign...@cisco.com>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org> > *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)" <rrah...@cisco.com> > 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" < > rtg-bfd-boun...@ietf.org on behalf of jh...@pfrc.org> 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 <jh...@pfrc.org> > 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> > > > > > > > > > > > > >
