Re: Fw: New Version Notification for draft-ietf-bfd-unaffiliated-echo-07.txt
Hi Greg, Thank you for the continued discussion. As to Standard vs Experimental/Informational, I've stated my opinion and no more to add. For the last two remaining discussion points, please see inline [XM-5]>>>. Original From: GregMirsky To: 肖敏10093570; Cc: rtg-bfd@ietf.org ; Date: 2023年06月15日 20:01 Subject: Re: Fw: New Version Notification for draft-ietf-bfd-unaffiliated-echo-07.txt Hi Xiao Min,thank you for your constructive consideration of my comments. I am glad that we have converged on technical issues. Minor remaining, in my opinion, can remain in the "let's agree to disagree" category. I have added two notes below, tagged GIM4>>. In conclusion, I think that if the document is switched to Experimental (which seems like the most logical to me) or Informational, then perhaps it then doesn't need to update RFC 5880 altogether but define a new, standalone Unaffiated BFD function, using some of the mechanisms defined in RFC 5880. Regards, Greg On Thu, May 18, 2023 at 10:55 AM wrote: Hi Greg, Thank you for the comprehensive and detailed discussion, which improves this document in many aspects. I'll post a new version draft after we reach agreement on the last few points. Please see inline [XM-4]>>>. Original From: GregMirsky To: 肖敏10093570; Cc: rtg-bfd@ietf.org ; Date: 2023年05月18日 12:22 Subject: Re: Fw: New Version Notification for draft-ietf-bfd-unaffiliated-echo-07.txt Hi Xiao Min,thank you for your thoughtful consideration of my notes. I greatly appreciate it and our discussion that helps us to come to resolutions. Please find my follow-up notes tagged GIM3>>. Best regards, Greg On Sun, May 14, 2023 at 11:47 PM wrote: Hi Greg, The points we have converged are trimmed, because I received a notice from rtg-bfd-ow...@ietf.org that "Message body is too big". Please see inline [XM-3]>>>. Original Is the following a requirement or an observation: a network device must be able to quickly detect faults in communication with adjacent devices. If the former, please capitalize the normative language. If the latter, then it appears as an arguable view. Indeed, in some cases, local protection is a viable option, while in other environments, e2e path protection might be preferable. [XM]>>> At the beginning of the sentence "in some cases" can be added, is that acceptable to you? GIM>> I think that the capability to faster detection of a network failure is always desirable. Thus, the statement can be presented as a general node requirement. On the other hand, it can be worded as an observation. Using normative keywords in a lowercase form might confuse readers. [XM-2]>>> I'd like to try again. Please see the proposed changes as below. OLD To minimize the impact of device/link faults on services and improve network availability, a network device must be able to quickly detect faults in communication with adjacent devices.NEW To minimize the impact of device/link faults on services and improve network availability, in some cases a network device needs to be able to quickly detect faults in communication with adjacent devices. GIM2>> In your opinion, how important to the document and this text is it to say "in some cases"? Personally, I think that the ability to quickly detect a network failure is a generic requirement, essential in all scenarios. [XM-3]>>> Please note that "in some cases" is derived from your comments "Indeed, in some cases, local protection is a viable option, while in other environments, e2e path protection might be preferable". The text focuses on the communication with adjacent devices, so "in some cases" is used, does that make sense to you? GIM3>> It seems like my note confused you. I was pointing out that in some cases operator may use local protection; in others - e2e. And, in some cases, both protection methods thus effectively creating a multi-layer OAM environment. But the ability to quickly detect network failure is critical in all cases. I hope that clarifies my views. [XM-4]>>> Let me rephrase my words. :-) As you know, BFD can be used for either single-hop or multi-hop fault detection, while the text says "detect faults in communication with adjacent devices", which means only single-hop application, so "in some cases". In other cases, BFD is used only for multi-hop application, single-hop fault detection is not needed. GIM4>> Thank you for the clarification. In that case, perhaps can explicitly point to the single-hop use of the Unaffiliated BFD Echo function, avoiding somewhat ambiguous "in some cases". [XM-5]>>> OK. Propose to change the text as below. OLD
Re: Fw: New Version Notification for draft-ietf-bfd-unaffiliated-echo-07.txt
Hi Xiao Min, thank you for your constructive consideration of my comments. I am glad that we have converged on technical issues. Minor remaining, in my opinion, can remain in the "let's agree to disagree" category. I have added two notes below, tagged GIM4>>. In conclusion, I think that if the document is switched to Experimental (which seems like the most logical to me) or Informational, then perhaps it then doesn't need to update RFC 5880 altogether but define a new, standalone Unaffiated BFD function, using some of the mechanisms defined in RFC 5880. Regards, Greg On Thu, May 18, 2023 at 10:55 AM wrote: > Hi Greg, > > > Thank you for the comprehensive and detailed discussion, which improves > this document in many aspects. > > I'll post a new version draft after we reach agreement on the last few > points. > > Please see inline [XM-4]>>>. > Original > *From: *GregMirsky > *To: *肖敏10093570; > *Cc: *rtg-bfd@ietf.org ; > *Date: *2023年05月18日 12:22 > *Subject: **Re: Fw: New Version Notification for > draft-ietf-bfd-unaffiliated-echo-07.txt* > Hi Xiao Min, > thank you for your thoughtful consideration of my notes. I greatly > appreciate it and our discussion that helps us to come to resolutions. > Please find my follow-up notes tagged GIM3>>. > > Best regards, > Greg > > On Sun, May 14, 2023 at 11:47 PM wrote: > >> Hi Greg, >> >> >> The points we have converged are trimmed, because I received a notice >> from rtg-bfd-ow...@ietf.org that "Message body is too big". >> >> Please see inline [XM-3]>>>. >> >>> Original >>>> >>>>- >>>> >>>>It is stated in the Abstract: >>>> >>>>BFD Async procedures can be executed over the BFD >>>> >>>>Echo port where the neighboring system only loops packets back to the >>>> >>>>local system. >>>> >>>> Is this conclusion differs from the definition of the BFD Echo function >>>> in RFC 5880? If it is not, what is the value of such a re-statement? If it >>>> is, it seems like an explicit attribution of this conclusion to this >>>> document would be helpful. >>>> [XM]>>> RFC 5880 doesn't say BFD Async procedures can be executed over >>>> the BFD Echo port because it classifies BFD Echo as an affiliated function. >>>> Would you please suggest some text you think helpful? >>>> >>>> GIM>> I am a bit confused by the "BFD Async procedures" term. In your >>> opinion, what are these procedures defined in RFC 5880? BFD state machine? >>> BFD state changes? I believe it would help me if you could give an example, >>> and add more details to the interpretation of that term. >>> >>> [XM-2]>>> The "BFD Async procedures" term was introduced by Jeff in his >>> comments on -05 version of this draft [1]. My understanding to the term is >>> that the BFD Control packet and the procedure on demultiplexing it, as well >>> as the BFD state machine and the procedure on changing the state are mostly >>> reused. >>> >>> [1] >>> https://mailarchive.ietf.org/arch/msg/rtg-bfd/JN4DpQjiudBGUJn8beapEwuhlH0/ >>> >> GIM2>> I imagine that we expect a reader of this document to be familiar >> with RFCs 5880 and 5881. AFAIK, neither of these RFCs uses the term "BFD >> Async procedures". If that is correct, then any new term must be explained >> or defined in this document. Would you agree? >> >> [XM-3]>>> Is s/BFD Async procedures/BFD Control packet and its processing >> procedures more clear? >> > GIM3>> Yes, that would address my concern. > > [XM-4]>>> OK. Will make the change. > >> >>>> >>>>- >>>> >>>>Is the following a requirement or an observation: >>>> >>>>a network device must be able to quickly detect >>>> >>>>faults in communication with adjacent devices. >>>> >>>> If the former, please capitalize the normative language. If the latter, >>>> then it appears as an arguable view. Indeed, in some cases, local >>>> protection is a viable option, while in other environments, e2e path >>>> protection might be preferable. >>>> [XM]>>> At the beginning of the sentence "in some cases" can be added, >>>> is that acceptable to you? >>>> >>>> GIM>> I think that the ca
Re: Fw: New Version Notification for draft-ietf-bfd-unaffiliated-echo-07.txt
Hi Greg, Thank you for the comprehensive and detailed discussion, which improves this document in many aspects. I'll post a new version draft after we reach agreement on the last few points. Please see inline [XM-4]>>>. Original From: GregMirsky To: 肖敏10093570; Cc: rtg-bfd@ietf.org ; Date: 2023年05月18日 12:22 Subject: Re: Fw: New Version Notification for draft-ietf-bfd-unaffiliated-echo-07.txt Hi Xiao Min,thank you for your thoughtful consideration of my notes. I greatly appreciate it and our discussion that helps us to come to resolutions. Please find my follow-up notes tagged GIM3>>. Best regards, Greg On Sun, May 14, 2023 at 11:47 PM wrote: Hi Greg, The points we have converged are trimmed, because I received a notice from rtg-bfd-ow...@ietf.org that "Message body is too big". Please see inline [XM-3]>>>. Original It is stated in the Abstract: BFD Async procedures can be executed over the BFD Echo port where the neighboring system only loops packets back to the local system. Is this conclusion differs from the definition of the BFD Echo function in RFC 5880? If it is not, what is the value of such a re-statement? If it is, it seems like an explicit attribution of this conclusion to this document would be helpful. [XM]>>> RFC 5880 doesn't say BFD Async procedures can be executed over the BFD Echo port because it classifies BFD Echo as an affiliated function. Would you please suggest some text you think helpful? GIM>> I am a bit confused by the "BFD Async procedures" term. In your opinion, what are these procedures defined in RFC 5880? BFD state machine? BFD state changes? I believe it would help me if you could give an example, and add more details to the interpretation of that term. [XM-2]>>> The "BFD Async procedures" term was introduced by Jeff in his comments on -05 version of this draft [1]. My understanding to the term is that the BFD Control packet and the procedure on demultiplexing it, as well as the BFD state machine and the procedure on changing the state are mostly reused. [1] https://mailarchive.ietf.org/arch/msg/rtg-bfd/JN4DpQjiudBGUJn8beapEwuhlH0/ GIM2>> I imagine that we expect a reader of this document to be familiar with RFCs 5880 and 5881. AFAIK, neither of these RFCs uses the term "BFD Async procedures". If that is correct, then any new term must be explained or defined in this document. Would you agree? [XM-3]>>> Is s/BFD Async procedures/BFD Control packet and its processing procedures more clear? GIM3>> Yes, that would address my concern. [XM-4]>>> OK. Will make the change. Is the following a requirement or an observation: a network device must be able to quickly detect faults in communication with adjacent devices. If the former, please capitalize the normative language. If the latter, then it appears as an arguable view. Indeed, in some cases, local protection is a viable option, while in other environments, e2e path protection might be preferable. [XM]>>> At the beginning of the sentence "in some cases" can be added, is that acceptable to you? GIM>> I think that the capability to faster detection of a network failure is always desirable. Thus, the statement can be presented as a general node requirement. On the other hand, it can be worded as an observation. Using normative keywords in a lowercase form might confuse readers. [XM-2]>>> I'd like to try again. Please see the proposed changes as below. OLD To minimize the impact of device/link faults on services and improve network availability, a network device must be able to quickly detect faults in communication with adjacent devices.NEW To minimize the impact of device/link faults on services and improve network availability, in some cases a network device needs to be able to quickly detect faults in communication with adjacent devices. GIM2>> In your opinion, how important to the document and this text is it to say "in some cases"? Personally, I think that the ability to quickly detect a network failure is a generic requirement, essential in all scenarios. [XM-3]>>> Please note that "in some cases" is derived from your comments "Indeed, in some cases, local protection is a viable option, while in other environments, e2e path protection might be preferable". The text focuses on the communication with adjacent devices, so "in some cases" is used, does that make sense to you? GIM3>> It seems like my note confused you. I was pointing out that in some cases operator may use local protection; in others - e2e. And, in some cases, both protection methods thus effectively creati
Re: Fw: New Version Notification for draft-ietf-bfd-unaffiliated-echo-07.txt
Hi Xiao Min, thank you for your thoughtful consideration of my notes. I greatly appreciate it and our discussion that helps us to come to resolutions. Please find my follow-up notes tagged GIM3>>. Best regards, Greg On Sun, May 14, 2023 at 11:47 PM wrote: > Hi Greg, > > > The points we have converged are trimmed, because I received a notice from > rtg-bfd-ow...@ietf.org that "Message body is too big". > > Please see inline [XM-3]>>>. > >> Original >>> >>>- >>> >>>It is stated in the Abstract: >>> >>>BFD Async procedures can be executed over the BFD >>> >>>Echo port where the neighboring system only loops packets back to the >>> >>>local system. >>> >>> Is this conclusion differs from the definition of the BFD Echo function >>> in RFC 5880? If it is not, what is the value of such a re-statement? If it >>> is, it seems like an explicit attribution of this conclusion to this >>> document would be helpful. >>> [XM]>>> RFC 5880 doesn't say BFD Async procedures can be executed over >>> the BFD Echo port because it classifies BFD Echo as an affiliated function. >>> Would you please suggest some text you think helpful? >>> >>> GIM>> I am a bit confused by the "BFD Async procedures" term. In your >> opinion, what are these procedures defined in RFC 5880? BFD state machine? >> BFD state changes? I believe it would help me if you could give an example, >> and add more details to the interpretation of that term. >> >> [XM-2]>>> The "BFD Async procedures" term was introduced by Jeff in his >> comments on -05 version of this draft [1]. My understanding to the term is >> that the BFD Control packet and the procedure on demultiplexing it, as well >> as the BFD state machine and the procedure on changing the state are mostly >> reused. >> >> [1] >> https://mailarchive.ietf.org/arch/msg/rtg-bfd/JN4DpQjiudBGUJn8beapEwuhlH0/ >> > GIM2>> I imagine that we expect a reader of this document to be familiar > with RFCs 5880 and 5881. AFAIK, neither of these RFCs uses the term "BFD > Async procedures". If that is correct, then any new term must be explained > or defined in this document. Would you agree? > > [XM-3]>>> Is s/BFD Async procedures/BFD Control packet and its processing > procedures more clear? > GIM3>> Yes, that would address my concern. > >>> >>>- >>> >>>Is the following a requirement or an observation: >>> >>>a network device must be able to quickly detect >>> >>>faults in communication with adjacent devices. >>> >>> If the former, please capitalize the normative language. If the latter, >>> then it appears as an arguable view. Indeed, in some cases, local >>> protection is a viable option, while in other environments, e2e path >>> protection might be preferable. >>> [XM]>>> At the beginning of the sentence "in some cases" can be added, >>> is that acceptable to you? >>> >>> GIM>> I think that the capability to faster detection of a network >> failure is always desirable. Thus, the statement can be presented as a >> general node requirement. On the other hand, it can be worded as an >> observation. Using normative keywords in a lowercase form might confuse >> readers. >> >> [XM-2]>>> I'd like to try again. Please see the proposed changes as below. >> >> OLD >> >>To minimize the impact of device/link faults on services and improve >> network availability, a network device must be able to quickly detect >> faults in communication with adjacent devices. >> >> NEW >> >>To minimize the impact of device/link faults on services and improve >> network availability, in some cases a network device needs to be able to >> quickly detectfaults in communication with adjacent devices. >> >> GIM2>> In your opinion, how important to the document and this text is it > to say "in some cases"? Personally, I think that the ability to quickly > detect a network failure is a generic requirement, essential in all > scenarios. > > [XM-3]>>> Please note that "in some cases" is derived from your comments > "Indeed, in some cases, local protection is a viable option, while in other > environments, e2e path protection might be preferable". The text focuses on > the communication with adjacent devices, so "in some cases" is used, does > that make sense to you? > GIM3>> It seems like my note confused you. I was pointing out that in some cases operator may use local protection; in others - e2e. And, in some cases, both protection methods thus effectively creating a multi-layer OAM environment. But the ability to quickly detect network failure is critical in all cases. I hope that clarifies my views. > >>> >>>- >>> >>>Further, in Introduction, I read: >>> >>>Section 5 of >>>[RFC5880] indicates that the payload of a BFD Echo packet is a local >>>matter and hence its contents are outside the scope of that >>>specification. This document, on the other hand, specifies the >>>contents of the Echo packets and what to do with them. >>> >>> It seems to me that
Re: Fw: New Version Notification for draft-ietf-bfd-unaffiliated-echo-07.txt
Hi Greg, The points we have converged are trimmed, because I received a notice from rtg-bfd-ow...@ietf.org that "Message body is too big". Please see inline [XM-3]>>>. Original It is stated in the Abstract: BFD Async procedures can be executed over the BFD Echo port where the neighboring system only loops packets back to the local system. Is this conclusion differs from the definition of the BFD Echo function in RFC 5880? If it is not, what is the value of such a re-statement? If it is, it seems like an explicit attribution of this conclusion to this document would be helpful. [XM]>>> RFC 5880 doesn't say BFD Async procedures can be executed over the BFD Echo port because it classifies BFD Echo as an affiliated function. Would you please suggest some text you think helpful? GIM>> I am a bit confused by the "BFD Async procedures" term. In your opinion, what are these procedures defined in RFC 5880? BFD state machine? BFD state changes? I believe it would help me if you could give an example, and add more details to the interpretation of that term. [XM-2]>>> The "BFD Async procedures" term was introduced by Jeff in his comments on -05 version of this draft [1]. My understanding to the term is that the BFD Control packet and the procedure on demultiplexing it, as well as the BFD state machine and the procedure on changing the state are mostly reused. [1] https://mailarchive.ietf.org/arch/msg/rtg-bfd/JN4DpQjiudBGUJn8beapEwuhlH0/ GIM2>> I imagine that we expect a reader of this document to be familiar with RFCs 5880 and 5881. AFAIK, neither of these RFCs uses the term "BFD Async procedures". If that is correct, then any new term must be explained or defined in this document. Would you agree? [XM-3]>>> Is s/BFD Async procedures/BFD Control packet and its processing procedures more clear? Is the following a requirement or an observation: a network device must be able to quickly detect faults in communication with adjacent devices. If the former, please capitalize the normative language. If the latter, then it appears as an arguable view. Indeed, in some cases, local protection is a viable option, while in other environments, e2e path protection might be preferable. [XM]>>> At the beginning of the sentence "in some cases" can be added, is that acceptable to you? GIM>> I think that the capability to faster detection of a network failure is always desirable. Thus, the statement can be presented as a general node requirement. On the other hand, it can be worded as an observation. Using normative keywords in a lowercase form might confuse readers. [XM-2]>>> I'd like to try again. Please see the proposed changes as below. OLD To minimize the impact of device/link faults on services and improve network availability, a network device must be able to quickly detect faults in communication with adjacent devices.NEW To minimize the impact of device/link faults on services and improve network availability, in some cases a network device needs to be able to quickly detect faults in communication with adjacent devices. GIM2>> In your opinion, how important to the document and this text is it to say "in some cases"? Personally, I think that the ability to quickly detect a network failure is a generic requirement, essential in all scenarios. [XM-3]>>> Please note that "in some cases" is derived from your comments "Indeed, in some cases, local protection is a viable option, while in other environments, e2e path protection might be preferable". The text focuses on the communication with adjacent devices, so "in some cases" is used, does that make sense to you? Further, in Introduction, I read: Section 5 of [RFC5880] indicates that the payload of a BFD Echo packet is a local matter and hence its contents are outside the scope of that specification. This document, on the other hand, specifies the contents of the Echo packets and what to do with them. It seems to me that this draft is positioned as the definition of the content of an Echo message and the processing of it, whether as an unaffiliated or affiliated (RTC5880-style) function. Is that correct? [XM]>>> That's incorrect. This document specifies only Unaffiliated BFD Echo, and it doesn't touch affiliated BFD Echo. GIM>> Thank you for the clarification. I feel that the current text and its location are unclear. Reiterating the scope of the proposed solution will certainly make it clearer. [XM-2]>>> OK. Please see the proposed changes as below. OLD Section 5 of [RFC5880] indicates that the payload of a BFD Echo packet is a local matter and hence its contents are outside the scope of that specification. This document, on the other hand, specifies the contents of the Echo packets and what to do with them. NEW
Re: Fw: New Version Notification for draft-ietf-bfd-unaffiliated-echo-07.txt
Hi Xiao Min, thank you for your consideration of my comments. I have added follow-up notes under the GIM2>> tag below. Regards, Greg On Tue, May 9, 2023 at 8:54 PM wrote: > Hi Greg, > > > Please see inline... > Original > *From: *GregMirsky > *To: *肖敏10093570; > *Cc: *rtg-bfd@ietf.org ; > *Date: *2023年05月10日 00:02 > *Subject: **Re: Fw: New Version Notification for > draft-ietf-bfd-unaffiliated-echo-07.txt* > Hi Xiao Min, > thank you for your expedient response. Please find my follow-up notes > below tagged GIM>>. > > Regards, > Greg > > On Thu, May 4, 2023 at 12:28 AM wrote: > >> Hi Greg, >> >> >> Thank you for the detailed review and comments, although I don't think >> your comments justify your conclusion. >> >> Please see inline... >> Original >> *From: *GregMirsky >> *To: *肖敏10093570; >> *Cc: *rtg-bfd@ietf.org ; >> *Date: *2023年04月29日 03:42 >> *Subject: **Re: Fw: New Version Notification for >> draft-ietf-bfd-unaffiliated-echo-07.txt* >> Hi Xiao Min, >> thank you for sharing updates. I've read the new version and have several >> questions and comments. >> >>- >> >>It is stated in the Abstract: >> >>BFD Async procedures can be executed over the BFD >> >>Echo port where the neighboring system only loops packets back to the >> >>local system. >> >> Is this conclusion differs from the definition of the BFD Echo function >> in RFC 5880? If it is not, what is the value of such a re-statement? If it >> is, it seems like an explicit attribution of this conclusion to this >> document would be helpful. >> [XM]>>> RFC 5880 doesn't say BFD Async procedures can be executed over >> the BFD Echo port because it classifies BFD Echo as an affiliated function. >> Would you please suggest some text you think helpful? >> >> GIM>> I am a bit confused by the "BFD Async procedures" term. In your > opinion, what are these procedures defined in RFC 5880? BFD state machine? > BFD state changes? I believe it would help me if you could give an example, > and add more details to the interpretation of that term. > > [XM-2]>>> The "BFD Async procedures" term was introduced by Jeff in his > comments on -05 version of this draft [1]. My understanding to the term is > that the BFD Control packet and the procedure on demultiplexing it, as well > as the BFD state machine and the procedure on changing the state are mostly > reused. > > [1] > https://mailarchive.ietf.org/arch/msg/rtg-bfd/JN4DpQjiudBGUJn8beapEwuhlH0/ > GIM2>> I imagine that we expect a reader of this document to be familiar with RFCs 5880 and 5881. AFAIK, neither of these RFCs uses the term "BFD Async procedures". If that is correct, then any new term must be explained or defined in this document. Would you agree? > >> >>- >> >>Is the following a requirement or an observation: >> >>a network device must be able to quickly detect >> >>faults in communication with adjacent devices. >> >> If the former, please capitalize the normative language. If the latter, >> then it appears as an arguable view. Indeed, in some cases, local >> protection is a viable option, while in other environments, e2e path >> protection might be preferable. >> [XM]>>> At the beginning of the sentence "in some cases" can be added, is >> that acceptable to you? >> >> GIM>> I think that the capability to faster detection of a network > failure is always desirable. Thus, the statement can be presented as a > general node requirement. On the other hand, it can be worded as an > observation. Using normative keywords in a lowercase form might confuse > readers. > > [XM-2]>>> I'd like to try again. Please see the proposed changes as below. > > OLD > >To minimize the impact of device/link faults on services and improve >network availability, a network device must be able to quickly detect >faults in communication with adjacent devices. > > NEW > >To minimize the impact of device/link faults on services and improve >network availability, in some cases a network device needs to be able to > quickly detect >faults in communication with adjacent devices. > > GIM2>> In your opinion, how important to the document and this text is it to say "in some cases"? Personally, I think that the ability to quickly detect a network failure is a generic requirement, essential in all scenarios. > >> >>- >> >>Further, in In
Re: Fw: New Version Notification for draft-ietf-bfd-unaffiliated-echo-07.txt
Hi Greg, Please see inline... Original From: GregMirsky To: 肖敏10093570; Cc: rtg-bfd@ietf.org ; Date: 2023年05月10日 00:02 Subject: Re: Fw: New Version Notification for draft-ietf-bfd-unaffiliated-echo-07.txt Hi Xiao Min,thank you for your expedient response. Please find my follow-up notes below tagged GIM>>. Regards, Greg On Thu, May 4, 2023 at 12:28 AM wrote: Hi Greg, Thank you for the detailed review and comments, although I don't think your comments justify your conclusion. Please see inline... Original From: GregMirsky To: 肖敏10093570; Cc: rtg-bfd@ietf.org ; Date: 2023年04月29日 03:42 Subject: Re: Fw: New Version Notification for draft-ietf-bfd-unaffiliated-echo-07.txt Hi Xiao Min,thank you for sharing updates. I've read the new version and have several questions and comments. It is stated in the Abstract: BFD Async procedures can be executed over the BFD Echo port where the neighboring system only loops packets back to the local system. Is this conclusion differs from the definition of the BFD Echo function in RFC 5880? If it is not, what is the value of such a re-statement? If it is, it seems like an explicit attribution of this conclusion to this document would be helpful. [XM]>>> RFC 5880 doesn't say BFD Async procedures can be executed over the BFD Echo port because it classifies BFD Echo as an affiliated function. Would you please suggest some text you think helpful? GIM>> I am a bit confused by the "BFD Async procedures" term. In your opinion, what are these procedures defined in RFC 5880? BFD state machine? BFD state changes? I believe it would help me if you could give an example, and add more details to the interpretation of that term. [XM-2]>>> The "BFD Async procedures" term was introduced by Jeff in his comments on -05 version of this draft [1]. My understanding to the term is that the BFD Control packet and the procedure on demultiplexing it, as well as the BFD state machine and the procedure on changing the state are mostly reused. [1] https://mailarchive.ietf.org/arch/msg/rtg-bfd/JN4DpQjiudBGUJn8beapEwuhlH0/ Is the following a requirement or an observation: a network device must be able to quickly detect faults in communication with adjacent devices. If the former, please capitalize the normative language. If the latter, then it appears as an arguable view. Indeed, in some cases, local protection is a viable option, while in other environments, e2e path protection might be preferable. [XM]>>> At the beginning of the sentence "in some cases" can be added, is that acceptable to you? GIM>> I think that the capability to faster detection of a network failure is always desirable. Thus, the statement can be presented as a general node requirement. On the other hand, it can be worded as an observation. Using normative keywords in a lowercase form might confuse readers. [XM-2]>>> I'd like to try again. Please see the proposed changes as below. OLD To minimize the impact of device/link faults on services and improve network availability, a network device must be able to quickly detect faults in communication with adjacent devices.NEW To minimize the impact of device/link faults on services and improve network availability, in some cases a network device needs to be able to quickly detect faults in communication with adjacent devices. Further, in Introduction, I read: Section 5 of [RFC5880] indicates that the payload of a BFD Echo packet is a local matter and hence its contents are outside the scope of that specification. This document, on the other hand, specifies the contents of the Echo packets and what to do with them. It seems to me that this draft is positioned as the definition of the content of an Echo message and the processing of it, whether as an unaffiliated or affiliated (RTC5880-style) function. Is that correct? [XM]>>> That's incorrect. This document specifies only Unaffiliated BFD Echo, and it doesn't touch affiliated BFD Echo. GIM>> Thank you for the clarification. I feel that the current text and its location are unclear. Reiterating the scope of the proposed solution will certainly make it clearer. [XM-2]>>> OK. Please see the proposed changes as below. OLD Section 5 of [RFC5880] indicates that the payload of a BFD Echo packet is a local matter and hence its contents are outside the scope of that specification. This document, on the other hand, specifies the contents of the Echo packets and what to do with them. NEW Section 5 of [RFC5880] indicates that the payload of an affiliated BFD Echo packet is a local matter and hence its contents are outside the scope of that specification. This document, on the other hand,
Re: Fw: New Version Notification for draft-ietf-bfd-unaffiliated-echo-07.txt
Hi Xiao Min, thank you for your expedient response. Please find my follow-up notes below tagged GIM>>. Regards, Greg On Thu, May 4, 2023 at 12:28 AM wrote: > Hi Greg, > > > Thank you for the detailed review and comments, although I don't think > your comments justify your conclusion. > > Please see inline... > Original > *From: *GregMirsky > *To: *肖敏10093570; > *Cc: *rtg-bfd@ietf.org ; > *Date: *2023年04月29日 03:42 > *Subject: **Re: Fw: New Version Notification for > draft-ietf-bfd-unaffiliated-echo-07.txt* > Hi Xiao Min, > thank you for sharing updates. I've read the new version and have several > questions and comments. > >- > >It is stated in the Abstract: > >BFD Async procedures can be executed over the BFD > >Echo port where the neighboring system only loops packets back to the > >local system. > > Is this conclusion differs from the definition of the BFD Echo function in > RFC 5880? If it is not, what is the value of such a re-statement? If it is, > it seems like an explicit attribution of this conclusion to this document > would be helpful. > [XM]>>> RFC 5880 doesn't say BFD Async procedures can be executed over the > BFD Echo port because it classifies BFD Echo as an affiliated function. > Would you please suggest some text you think helpful? > > GIM>> I am a bit confused by the "BFD Async procedures" term. In your opinion, what are these procedures defined in RFC 5880? BFD state machine? BFD state changes? I believe it would help me if you could give an example, and add more details to the interpretation of that term. > > >- > >Is the following a requirement or an observation: > >a network device must be able to quickly detect > >faults in communication with adjacent devices. > > If the former, please capitalize the normative language. If the latter, > then it appears as an arguable view. Indeed, in some cases, local > protection is a viable option, while in other environments, e2e path > protection might be preferable. > [XM]>>> At the beginning of the sentence "in some cases" can be added, is > that acceptable to you? > > GIM>> I think that the capability to faster detection of a network failure is always desirable. Thus, the statement can be presented as a general node requirement. On the other hand, it can be worded as an observation. Using normative keywords in a lowercase form might confuse readers. > > >- > >Further, in Introduction, I read: > >Section 5 of >[RFC5880] indicates that the payload of a BFD Echo packet is a local >matter and hence its contents are outside the scope of that >specification. This document, on the other hand, specifies the >contents of the Echo packets and what to do with them. > > It seems to me that this draft is positioned as the definition of the > content of an Echo message and the processing of it, whether as an > unaffiliated or affiliated (RTC5880-style) function. Is that correct? > [XM]>>> That's incorrect. This document specifies only Unaffiliated BFD > Echo, and it doesn't touch affiliated BFD Echo. > > GIM>> Thank you for the clarification. I feel that the current text and its location are unclear. Reiterating the scope of the proposed solution will certainly make it clearer. > > >- > >I hope you can help me understand the demultiplexing of Unaffiliated >BFD sessions: > >Device A performs its >initial demultiplexing of a Unaffiliated BFD Echo session using the >source IP address or UDP source port, once the remote system echoes >back the local discriminator, all further received packets are >demultiplexed based on the "Your Discriminator" field only, which is >conformed to the procedure specified in Section 6.3 of [RFC5880]. > > >- > >Does "initial demultiplexing" refers to the first BFD Control message >transmitted in the Unaffiliated BFD Echo mode? > >[XM]>>> Not exactly. Actually "initial demultiplexing" is applied to >the received BFD Control packet(s) whose "Your Discriminator" is zero. > > GIM>> Perhaps that can be added to the document as "In the case when the value of Your Discriminator in the received packet is zero, demultiplexing is done based on ..."? > >- > >Considering that "device B would not intercept any received >Unaffiliated BFD Echo packet", how "the remote system echoes back the local >discriminator"? > >[XM]>>> Here "echoes back" means "loops back", is "loops back" mor
Re: Fw: New Version Notification for draft-ietf-bfd-unaffiliated-echo-07.txt
Hi Greg, Thank you for the detailed review and comments, although I don't think your comments justify your conclusion. Please see inline... Original From: GregMirsky To: 肖敏10093570; Cc: rtg-bfd@ietf.org ; Date: 2023年04月29日 03:42 Subject: Re: Fw: New Version Notification for draft-ietf-bfd-unaffiliated-echo-07.txt Hi Xiao Min,thank you for sharing updates. I've read the new version and have several questions and comments. It is stated in the Abstract: BFD Async procedures can be executed over the BFD Echo port where the neighboring system only loops packets back to the local system. Is this conclusion differs from the definition of the BFD Echo function in RFC 5880? If it is not, what is the value of such a re-statement? If it is, it seems like an explicit attribution of this conclusion to this document would be helpful. [XM]>>> RFC 5880 doesn't say BFD Async procedures can be executed over the BFD Echo port because it classifies BFD Echo as an affiliated function. Would you please suggest some text you think helpful? Is the following a requirement or an observation: a network device must be able to quickly detect faults in communication with adjacent devices. If the former, please capitalize the normative language. If the latter, then it appears as an arguable view. Indeed, in some cases, local protection is a viable option, while in other environments, e2e path protection might be preferable. [XM]>>> At the beginning of the sentence "in some cases" can be added, is that acceptable to you? Further, in Introduction, I read: Section 5 of [RFC5880] indicates that the payload of a BFD Echo packet is a local matter and hence its contents are outside the scope of that specification. This document, on the other hand, specifies the contents of the Echo packets and what to do with them. It seems to me that this draft is positioned as the definition of the content of an Echo message and the processing of it, whether as an unaffiliated or affiliated (RTC5880-style) function. Is that correct? [XM]>>> That's incorrect. This document specifies only Unaffiliated BFD Echo, and it doesn't touch affiliated BFD Echo. I hope you can help me understand the demultiplexing of Unaffiliated BFD sessions: Device A performs its initial demultiplexing of a Unaffiliated BFD Echo session using the source IP address or UDP source port, once the remote system echoes back the local discriminator, all further received packets are demultiplexed based on the "Your Discriminator" field only, which is conformed to the procedure specified in Section 6.3 of [RFC5880]. Does "initial demultiplexing" refers to the first BFD Control message transmitted in the Unaffiliated BFD Echo mode? [XM]>>> Not exactly. Actually "initial demultiplexing" is applied to the received BFD Control packet(s) whose "Your Discriminator" is zero. Considering that "device B would not intercept any received Unaffiliated BFD Echo packet", how "the remote system echoes back the local discriminator"? [XM]>>> Here "echoes back" means "loops back", is "loops back" more clear? A lengthy copy of a text from Section 4 of RFC 5881 seems like unnecessary: the destination address MUST be chosen in such a way as to cause the remote system to forward the packet back to the local system. The source address MUST be chosen in such a way as to preclude the remote system from generating ICMP or Neighbor Discovery Redirect messages. In particular, the source address SHOULD NOT be part of the subnet bound to the interface over which the BFD Echo packet is being transmitted, and it SHOULD NOT be an IPv6 link-local address, unless it is known by other means that the remote system will not send Redirects. It seems that a reference to that section and something like "rules stated in Section 4 [RFC5881] are applicable to the encapsulation of an Unaffiliated BFD Echo Control message" could be sufficient. [XM]>>> I'd like to follow your suggestion if there is no objection from Jeff. What is the interpretation of "expected value"? It appears that none of these values are used, but are ignored. Right? [XM]>>> As indicated by Jeff, "the desire is that we avoid unset values being a potential vector for disclosure of uninitialized memory". A zero value of the Required Min Echo RX Interval field per RFC 5880 is interpreted as no support for the Echo function. But it is the recommended value. Although it is ignored. Thus, what is the benefit of initializing the field after all? [XM]>>> As indicated by Jeff, "the desire is that we avoid unset values being a potential vector for disclosure of
Re: Fw: New Version Notification for draft-ietf-bfd-unaffiliated-echo-07.txt
that this document doesn't change the > affiliated BFD Echo function. > > * change the order of section 2 "Updates to RFC 5880" and section 3 > "Unaffiliated BFD Echo Procedures". > > * add a summary on the Unaffiliated BFD Echo packet fields setting into > the end of section "Unaffiliated BFD Echo Procedures". > > * change the text on IP address setting to the same as specified in > section 4 of RFC 5881. > > * some editorial changes, e.g., s/BFD Unaffiliated Echo > packet/Unaffiliated BFD Echo packet/g. > > > Best Regards, > > Xiao Min > Original > *From: *internet-dra...@ietf.org > *To: *Raj Boddireddy ;Raj Chetan Boddireddy < > rche...@juniper.net>;Reshad Rahman ;Ruixue Wang < > wangrui...@chinamobile.com>;Weiqiang Cheng >;肖敏10093570; > *Date: *2023年04月24日 10:09 > *Subject: **New Version Notification for > draft-ietf-bfd-unaffiliated-echo-07.txt* > > A new version of I-D, draft-ietf-bfd-unaffiliated-echo-07.txt > has been successfully submitted by Xiao Min and posted to the > IETF repository. > > Name:draft-ietf-bfd-unaffiliated-echo > Revision:07 > Title:Unaffiliated BFD Echo > Document date:2023-04-23 > Group:bfd > Pages:12 > URL: > https://www.ietf.org/archive/id/draft-ietf-bfd-unaffiliated-echo-07.txt > Status: > https://datatracker.ietf.org/doc/draft-ietf-bfd-unaffiliated-echo/ > Htmlized: > https://datatracker.ietf.org/doc/html/draft-ietf-bfd-unaffiliated-echo > Diff: > https://author-tools.ietf.org/iddiff?url2=draft-ietf-bfd-unaffiliated-echo-07 > > Abstract: >Bidirectional Forwarding Detection (BFD) is a fault detection >protocol that can quickly determine a communication failure between >two forwarding engines. This document proposes a use of the BFD Echo >where the local system supports BFD but the neighboring system does >not support BFD. BFD Async procedures can be executed over the BFD >Echo port where the neighboring system only loops packets back to the >local system. > >This document updates RFC 5880. > > > > > > The IETF Secretariat > > >
Re: New Version Notification for draft-ietf-bfd-unaffiliated-echo-07.txt
Working Group, After reviewing draft-07, I believe all pending review comments to date have been addressed. We're waiting on final acknowledgement on one point from Greg and then otherwise might proceed with publication. The shepherd's report is located here for your review: https://datatracker.ietf.org/doc/draft-ietf-bfd-unaffiliated-echo/shepherdwriteup/ -- Jeff > On Apr 23, 2023, at 10:16 PM, > wrote: > > Dear BFD WG, > > > > A -07 revision of draft-ietf-bfd-unaffiliated-echo has been posted, > attempting to address all the WGLC comments. > > The main updates are as below. > > * add a sentence to clarify that this document doesn't change the affiliated > BFD Echo function. > > * change the order of section 2 "Updates to RFC 5880" and section 3 > "Unaffiliated BFD Echo Procedures". > > * add a summary on the Unaffiliated BFD Echo packet fields setting into the > end of section "Unaffiliated BFD Echo Procedures". > > * change the text on IP address setting to the same as specified in section 4 > of RFC 5881. > > * some editorial changes, e.g., s/BFD Unaffiliated Echo packet/Unaffiliated > BFD Echo packet/g. > > > > Best Regards, > > Xiao Min > > Original > From: internet-dra...@ietf.org > To: Raj Boddireddy ;Raj Chetan Boddireddy > ;Reshad Rahman ;Ruixue Wang > ;Weiqiang Cheng > ;肖敏10093570; > Date: 2023年04月24日 10:09 > Subject: New Version Notification for draft-ietf-bfd-unaffiliated-echo-07.txt > > A new version of I-D, draft-ietf-bfd-unaffiliated-echo-07.txt > has been successfully submitted by Xiao Min and posted to the > IETF repository. > > Name:draft-ietf-bfd-unaffiliated-echo > Revision:07 > Title:Unaffiliated BFD Echo > Document date:2023-04-23 > Group:bfd > Pages:12 > URL: > https://www.ietf.org/archive/id/draft-ietf-bfd-unaffiliated-echo-07.txt > Status: > https://datatracker.ietf.org/doc/draft-ietf-bfd-unaffiliated-echo/ > Htmlized: > https://datatracker.ietf.org/doc/html/draft-ietf-bfd-unaffiliated-echo > Diff: > https://author-tools.ietf.org/iddiff?url2=draft-ietf-bfd-unaffiliated-echo-07 > > Abstract: >Bidirectional Forwarding Detection (BFD) is a fault detection >protocol that can quickly determine a communication failure between >two forwarding engines. This document proposes a use of the BFD Echo >where the local system supports BFD but the neighboring system does >not support BFD. BFD Async procedures can be executed over the BFD >Echo port where the neighboring system only loops packets back to the >local system. > >This document updates RFC 5880. > > > > > > The IETF Secretariat > > >
Fw: New Version Notification for draft-ietf-bfd-unaffiliated-echo-07.txt
Dear BFD WG, A -07 revision of draft-ietf-bfd-unaffiliated-echo has been posted, attempting to address all the WGLC comments. The main updates are as below. * add a sentence to clarify that this document doesn't change the affiliated BFD Echo function. * change the order of section 2 "Updates to RFC 5880" and section 3 "Unaffiliated BFD Echo Procedures". * add a summary on the Unaffiliated BFD Echo packet fields setting into the end of section "Unaffiliated BFD Echo Procedures". * change the text on IP address setting to the same as specified in section 4 of RFC 5881. * some editorial changes, e.g., s/BFD Unaffiliated Echo packet/Unaffiliated BFD Echo packet/g. Best Regards, Xiao Min Original From: internet-dra...@ietf.org To: Raj Boddireddy ;Raj Chetan Boddireddy ;Reshad Rahman ;Ruixue Wang ;Weiqiang Cheng ;肖敏10093570; Date: 2023年04月24日 10:09 Subject: New Version Notification for draft-ietf-bfd-unaffiliated-echo-07.txt A new version of I-D, draft-ietf-bfd-unaffiliated-echo-07.txt has been successfully submitted by Xiao Min and posted to the IETF repository. Name:draft-ietf-bfd-unaffiliated-echo Revision:07 Title:Unaffiliated BFD Echo Document date:2023-04-23 Group:bfd Pages:12 URL: https://www.ietf.org/archive/id/draft-ietf-bfd-unaffiliated-echo-07.txt Status: https://datatracker.ietf.org/doc/draft-ietf-bfd-unaffiliated-echo/ Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-bfd-unaffiliated-echo Diff: https://author-tools.ietf.org/iddiff?url2=draft-ietf-bfd-unaffiliated-echo-07 Abstract: Bidirectional Forwarding Detection (BFD) is a fault detection protocol that can quickly determine a communication failure between two forwarding engines. This document proposes a use of the BFD Echo where the local system supports BFD but the neighboring system does not support BFD. BFD Async procedures can be executed over the BFD Echo port where the neighboring system only loops packets back to the local system. This document updates RFC 5880. The IETF Secretariat
