Re: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)

[xiao.min2]

Jeff,






Please see inline...









Original



From: JeffreyHaas 
To: 肖敏10093570;
Cc: Greg Mirsky ;rtg-bfd@ietf.org ;
Date: 2023年04月11日 01:34
Subject: Re: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)




Xiao Min,

On Apr 9, 2023, at 10:42 PM,   
wrote:







After further thought, I think copying the RFC 5881 advice is perhaps best 
answer.  It provides wisdom that attempts to avoid redirect messages.  However, 
since it's SHOULD NOT rather than MUST NOT, it doesn't make any existing 
implementations non-conformance; e.g. Broadcom.
[XM]>>> Got it. I'll copy the RFC 5881 advice.




Best Regards,

Xiao Min




-- Jeff







From: JeffreyHaas 







"could" isn't one of our RFC 2119 normative terms.  Do you believe "SHOULD" is 
more appropriate?

[XM-2]>>> If we would like to use normative term for SA, then that can also 
apply to DA, suggest s/would/MUST. As Greg pointed out, there may be implicit 
conflict with RFC 5881 section 4 that says "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".

Re: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)

[Jeffrey Haas]

Xiao Min,


> On Apr 9, 2023, at 10:42 PM,   
> wrote:
> From: JeffreyHaas 
> 
> "could" isn't one of our RFC 2119 normative terms.  Do you believe "SHOULD" 
> is more appropriate?
> [XM-2]>>> If we would like to use normative term for SA, then that can also 
> apply to DA, suggest s/would/MUST. As Greg pointed out, there may be implicit 
> conflict with RFC 5881 section 4 that says "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".
> 
> 

After further thought, I think copying the RFC 5881 advice is perhaps best 
answer.  It provides wisdom that attempts to avoid redirect messages.  However, 
since it's SHOULD NOT rather than MUST NOT, it doesn't make any existing 
implementations non-conformance; e.g. Broadcom.

-- Jeff

Re: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)

[xiao.min2]

Jeff,






Please see inline...



Original



From: JeffreyHaas 
To: 肖敏10093570;
Cc: gregimir...@gmail.com ;rtg-bfd@ietf.org 
;
Date: 2023年04月07日 23:32
Subject: Re: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)


Xiao Min,

On Apr 7, 2023, at 3:15 AM, xiao.m...@zte.com.cn wrote:
That's an interesting deficiency.  I will ask Juniper BFD developers if there's 
any similar consideration for our current implementation.
"could" isn't one of our RFC 2119 normative terms.  Do you believe "SHOULD" is 
more appropriate?
[XM-2]>>> If we would like to use normative term for SA, then that can also 
apply to DA, suggest s/would/MUST. As Greg pointed out, there may be implicit 
conflict with RFC 5881 section 4 that says "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".




Best Regards,

Xiao Min




-- Jeff









On Apr 6, 2023, at 3:35 AM,   wrote:

One of the considerations may be whether a IPv6 link local address is 
preferable to a global address.  

The only consideration for the draft as it is written is that the address used 
as the destination may be looped back by the unaffiliated device.  Link local 
helps address the security considerations that impact this feature, and it 
might be worth noting that when link local can be used for the use case that it 
assists in this point.

[XM]>>> I checked this with the implementer of this feature, and I'm told 
setting the DA to a IPv6 link local address doesn't work, because the link 
local address can't be looped back by the neighboring device.

Re: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)

[xiao.min2]

Jeff, Aijun,






Thank you for the comments.


Please see inline...



Original



From: JeffreyHaas 
To: Aijun Wang ;
Cc: rtg-bfd@ietf.org ;
Date: 2023年04月07日 23:27
Subject: Re: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)


Aijun,
 
 
> On Apr 6, 2023, at 8:53 PM, Aijun Wang  wrote:
>> Providing additional detail to help illustrate the mechanism would be
>> in-scope and perhaps helpful.  Did you have any explicit recommendations for
>> the text?
> [WAJ] How about to refer the style of
> https://datatracker.ietf.org/doc/html/draft-ietf-idr-vpn-prefix-orf-00#secti
> on-8?
 
That seems reasonable.  Let's see what the authors say.
 [XM]>>> I propose to add a summary using the style suggested by Aijun into the 
end 
of section 3, highlighting how to set the fields of the BFD Unaffiliated Echo 
packets. In 
addition, I'll switch the order of section 2 and section 3 as you suggested.




Best Regards,

Xiao Min




>>> Is there any other better style to point out the update to RFC5880?
>>  
>> Unfortunately, this is a common problem for internet-drafts that impact
>> protocol state machinery.  We have either the option of trying to issue a
>> "patch" on the draft, as we're doing here, or do a -bis of the base RFC to
>> more cleanly integrate the changes.
> [WAJ] How about to give the RFC also the version attribute like the draft?
> That is to say, for such "patch" or verbose text update, once the proposed
> draft is published, the updated contents will be incorporated into the base
> RFC automatically(no need to the overall long procedures for the bis
> document), but give its one new version number?  The bit RFC document can be
> labelled with the source that the updates are coming from.
> Maybe this should be discussed in more general scope?
> The final bis RFC document will be more easily referred and readable.
 
Using IEEE documents as an example, if there is an update to the base document, 
all of the changes are included in it.  If we ever do a RFC 5880-bis, or 
potentially do work to advance BFD to Internet Standard, this might be 
reasonable to do.
 
For now, the document is consistent with procedures we see in other working 
groups.
 
-- Jeff

Re: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)

[Jeffrey Haas]

Greg,


> On Apr 7, 2023, at 1:10 PM, Greg Mirsky  wrote:
> On Thu, Apr 6, 2023 at 7:36 AM Jeffrey Haas  > wrote:
> Greg,
> 
> 
>> On Mar 27, 2023, at 1:40 AM, Greg Mirsky > > wrote:
>> 
>> Dear Authors,
>> I read the latest version of the draft. I appreciate your work on improving 
>> its readability. I have several concerns and appreciate your consideration:
>> It appears like the document defines the format of the Echo message. As I 
>> understand the RFC 5880, the format of the Echo message is not specified in 
>> the RFC 5880. It seems like by defining the format in this document, you 
>> affect RFC 5880 compliance of implementations that do support RFC 5880 as it 
>> exists today.
> One way to alternatively view this is we're documenting what one 
> implementation puts in its Echo packets.  This draft does not try to require 
> that all BFD Echo implementations use these procedures.
> GIM>> That is an interesting perspective. If that is the purpose of this 
> specification, then the amount of updates it requires seems excessive. On the 
> other hand, if the group agrees to reflect such intention in the draft, it 
> will alleviate my concern.

The intention for the RFC 5880 changes are to deal with the fact that BFD 
normally expects to be able to send Echo packets only after a session is Up.  
In the case of this document, BFD Async procedures may not happen.

> Furthermore, if that is the position explicitly communicated in the draft, 
> making it Experimental seems like the next logical step. 

I don't think this explicitly follows.

> 
>> The draft, in my opinion, significantly changes the architecture of the BFD, 
>> as it is defined in RFC 5880. I believe that characterizing Echo as a 
>> function stresses its dependency from a BFD mode, Asynchronous and Demand. 
>> The changes proposed in this draft are very extensive and severely affect 
>> the existing architecture of BFD by setting the Echo function on par, 
>> unrelated with the BFD modes.
> 
> Interesting.  My view has been that this mechanism leverages existing BFD 
> Async procedures to avoid trying to completely invent new mechanisms for the 
> unafilliated case.  Where I might have some level of agreement with your 
> point is this "mode" needs to be clearly defined from a configuration 
> standpoint.  For example, how would it manifest in YANG?
> GIM>> It seems that we have different views. I consider the limitation of 
> using the Echo function, specified in RFC 5880, only after the session 
> reaches the Up state as a part of the BFD security mechanism. Personally, I 
> would encourage not to use a well-known UDP port for the type of operation 
> described in the draft. I think it would be more secure to use a port number 
> from the dynamic range. Defining that function as a new optional BFD function 
> without severely updating RFC 5880, in my opinion, is a safer path.

I must give you the same answer we'd have to give to the security ADs: A form 
of this feature has been deployed via BBF TR-146 for quite some time, and 
leverages the BFD Echo port.

At one point, it had been described to me that the motivation for the invention 
of this feature was that it was trivial to enable in some third party chipsets. 
 A quick Google brought me to a manual covering some Broadcom chips.  Some of 
the information in the document is helpful for this discussion:

https://manualzz.com/doc/o/1277tk/broadcom-bcm88690--bcm88800--bcm88480--and-bcm88280-packe...-32.13.5--configuring-bfd-echo

Section 32.13 suggests that dst ip and src ip must be identical and that the 
service will use udp port 3785.

Particularly interesting:
"The Device OAMP supports transmission BFD Echo frames and processing 
looped-back Echo frames. BFD Echo frames are generated by the OAMP as BFD 
Control packets. Upon reception, BFD echo packets are identified at the PMF 
using a specific rule (based on Your-Discriminator), and are sent to the OAMP 
for monitoring through trap mechanisms. The OAMP verifies the applicable 
fields, and monitor reception of the packet to determine LoC."

So, the chipset appears to largely do what we're describing in this document. 
:-)



> 
>> Also, I think that the normative language in the last paragraph of the 
>> Secrity Considerations sections are too soft. Currently used recommendation 
>> level, in my opinion, is insufficient and should be brought to the 
>> requirement level. I.e., I propose s/RECOMMENDED/MUST/ and s/SHOULD 
>> NOT/SHALL NOT/
> 
> I'd recommend that you show the explicit sections you want updated.
> GIM>> Thank you for pointing that out for me. Below are the proposed updates:
> OLD TEXT:
>In order to mitigate the potential reflector attack by the remote
>attackers, or infinite loop of the BFD Unaffiliated Echo packets,
>it's RECOMMENDED to put two requirements, also known as Generalized
>TTL Security Mechanism (GTSM) [RFC5082], on the device looping 

Re: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)

[Jeffrey Haas]

Greg,


> On Apr 7, 2023, at 1:03 PM, Greg Mirsky  wrote:
> Since the feature is intended to be used for single-hop, the source address 
> SHOULD be an address on the shared subnet with the interface of the device 
> that is looping the packets back.  Perhaps it might even be reasonable to 
> require that the source and destination addresses are identical when possible?
> GIM2>> As I understand RFC 5881 , 
> Section 4 recommends not to use an address on the same network as the 
> destination IP address, nor use a link-local IPv6 address as the source IP 
> address for an Echo message:
>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.
> Do you think that the normative part of Section 4 is applicable to 
> draft-ietf-bfd-unaffiliated-echo?

Fantastic reference and one I should have looked for.  I believe you're correct 
and that this is an appropriate reference for the unaffiliated draft.

One consideration that is interesting is what address is appropriate to 
configure when a system has exactly one interface?  

-- Jeff

Re: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)

[Greg Mirsky]

Hi Jeff,
thank you for your thoughtful response. Please find my notes below under
the GIM>> tag.

Regards,
Greg


On Thu, Apr 6, 2023 at 7:36 AM Jeffrey Haas  wrote:

> Greg,
>
>
> On Mar 27, 2023, at 1:40 AM, Greg Mirsky  wrote:
>
> Dear Authors,
> I read the latest version of the draft. I appreciate your work on
> improving its readability. I have several concerns and appreciate your
> consideration:
>
>- It appears like the document defines the format of the Echo message.
>As I understand the RFC 5880, the format of the Echo message is not
>specified in the RFC 5880. It seems like by defining the format in this
>document, you affect RFC 5880 compliance of implementations that do support
>RFC 5880 as it exists today.
>
> One way to alternatively view this is we're documenting what one
> implementation puts in its Echo packets.  This draft does not try to
> require that all BFD Echo implementations use these procedures.
>
GIM>> That is an interesting perspective. If that is the purpose of this
specification, then the amount of updates it requires seems excessive. On
the other hand, if the group agrees to reflect such intention in the draft,
it will alleviate my concern. Furthermore, if that is the position
explicitly communicated in the draft, making it Experimental seems like the
next logical step.

>
>
>- The draft, in my opinion, significantly changes the architecture of
>the BFD, as it is defined in RFC 5880. I believe that characterizing Echo
>as a function stresses its dependency from a BFD mode, Asynchronous and
>Demand. The changes proposed in this draft are very extensive and severely
>affect the existing architecture of BFD by setting the Echo function on
>par, unrelated with the BFD modes.
>
>
> Interesting.  My view has been that this mechanism leverages existing BFD
> Async procedures to avoid trying to completely invent new mechanisms for
> the unafilliated case.  Where I might have some level of agreement with
> your point is this "mode" needs to be clearly defined from a configuration
> standpoint.  For example, how would it manifest in YANG?
>
GIM>> It seems that we have different views. I consider the limitation of
using the Echo function, specified in RFC 5880, only after the session
reaches the Up state as a part of the BFD security mechanism. Personally, I
would encourage not to use a well-known UDP port for the type of operation
described in the draft. I think it would be more secure to use a port
number from the dynamic range. Defining that function as a new optional BFD
function without severely updating RFC 5880, in my opinion, is a safer path.

>
>
>- Also, I think that the normative language in the last paragraph of
>the Secrity Considerations sections are too soft. Currently used
>recommendation level, in my opinion, is insufficient and should be brought
>to the requirement level. I.e., I propose s/RECOMMENDED/MUST/ and s/SHOULD
>NOT/SHALL NOT/
>
>
> I'd recommend that you show the explicit sections you want updated.
>
GIM>> Thank you for pointing that out for me. Below are the proposed
updates:
OLD TEXT:
   In order to mitigate the potential reflector attack by the remote
   attackers, or infinite loop of the BFD Unaffiliated Echo packets,
   it's RECOMMENDED to put two requirements, also known as Generalized
   TTL Security Mechanism (GTSM) [RFC5082], on the device looping BFD
   Unaffiliated Echo packets, the first one is that a packet SHOULD NOT
   be looped unless it has a TTL or Hop Limit value of 255, and the
   second one is that a packet being looped MUST NOT reset the TTL or
   Hop Limit value to 255, and MUST use a TTL or Hop Limit value of 254.
NEW TEXT:
   In order to mitigate the potential reflector attack by the remote
   attackers, or infinite loop of the BFD Unaffiliated Echo packets,
   this specification puts two requirements, also known as Generalized
   TTL Security Mechanism (GTSM) [RFC5082], on the device looping BFD
   Unaffiliated Echo packets, the first one is that a packet MUST NOT
   be looped unless it has a TTL or Hop Limit value of 255, and the
   second one is that a packet being looped MUST NOT reset the TTL or
   Hop Limit value to 255, and MUST use a TTL or Hop Limit value of 254.


 Using version -06:
> - I would not personally suggest that the RECOMMENDED for authentication
> turn into a MUST.  BFD Authentication simply isn't used in enough
> circumstances to try to turn this into the default case, especially when
> the intent of this feature is to deal with systems that don't have a
> matching BFD on the opposite side.
> - I not super supportive of the SHOULD NOT for the TTL 255 loop being
> upgraded to SHALL NOT.  This will likely make a number of existing
> deployments of this feature non-conformant.
>
> Please note that I expect to have a repeat of this conversation with the
> security AD during review.  So, your comments are apropos.
>
> -- Jeff
>
>

Re: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)

[Greg Mirsky]

Hi Jeff,
I hope you will agree with my using your response to continue the
discussion. Please find my notes below under the GIM2>> tag. I will respond
to other discussion topics in another follow-up mail.

Regards,
Greg

On Thu, Apr 6, 2023 at 7:28 AM Jeffrey Haas  wrote:

> Xiao Min,
>
> Thanks for addressing Greg's comments.  I some additional comment on
> Greg's points:
>
GIM2>> I greatly appreciate the attention Xiao Min extended to my comments.

>
>
> On Apr 6, 2023, at 3:35 AM,  
> wrote:
>
>-
>
>The draft describes how the destination IP address of the Echo packet
>is set. Are there any special considerations for selecting IPv6 destination
>address?
>
>[XM]>>> The draft currently says "Device A would send BFD Unaffiliated
>Echo packets with IP destination address destined for itself, such as the
>IP address of interface 1 of device A". No any special considerations.
>
>
> One of the considerations may be whether a IPv6 link local address is
> preferable to a global address.
>
> The only consideration for the draft as it is written is that the address
> used as the destination may be looped back by the unaffiliated device.
> Link local helps address the security considerations that impact this
> feature, and it might be worth noting that when link local can be used for
> the use case that it assists in this point.
>

>
>-
>
>Also, are there any special considerations for selecting the source IP
>address for IPv4 and/or IPv6 network?
>
>[XM]>>> No. If you have any suggestions, please let me know. :)
>
>
> Since the feature is intended to be used for single-hop, the source
> address SHOULD be an address on the shared subnet with the interface of the
> device that is looping the packets back.  Perhaps it might even be
> reasonable to require that the source and destination addresses are
> identical when possible?
>
GIM2>> As I understand RFC 5881 ,
Section 4 recommends not to use an address on the same network as the
destination IP address, nor use a link-local IPv6 address as the source IP
address for an Echo message:
   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.
Do you think that the normative part of Section 4 is applicable to
draft-ietf-bfd-unaffiliated-echo?

>
> Where this may complicate procedure is the initial demultiplexing step
> when the session is Down.  Once the session is Up, the Discriminators can
> be used for this purpose.
>
> -- Jeff
>
>

Re: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)

[Jeffrey Haas]

Xiao Min,


> On Apr 7, 2023, at 3:15 AM, xiao.m...@zte.com.cn wrote:
>>> On Apr 6, 2023, at 3:35 AM, >> > >> > wrote:
>> One of the considerations may be whether a IPv6 link local address is 
>> preferable to a global address.  
>> 
>> The only consideration for the draft as it is written is that the address 
>> used as the destination may be looped back by the unaffiliated device.  Link 
>> local helps address the security considerations that impact this feature, 
>> and it might be worth noting that when link local can be used for the use 
>> case that it assists in this point.
> [XM]>>> I checked this with the implementer of this feature, and I'm told 
> setting the DA to a IPv6 link local address doesn't work, because the link 
> local address can't be looped back by the neighboring device.
> 
> 

That's an interesting deficiency.  I will ask Juniper BFD developers if there's 
any similar consideration for our current implementation.

> [XM]>>> I propose the text change as below.
> 
> OLD
> 
> Device A would send BFD Unaffiliated Echo packets with IP destination
>address destined for itself, such as the IP address of interface 1 of
>device A.
> NEW
> 
> Device A would send BFD Unaffiliated Echo packets with IP destination
>address destined for itself, such as the IP address of interface 1 of
>device A. The IP source address of the BFD Unaffiliated Echo packets
>could be identical to the IP destination address or other address 
> provisioned
>on device A.
> 
> 
"could" isn't one of our RFC 2119 normative terms.  Do you believe "SHOULD" is 
more appropriate?

-- Jeff

Re: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)

[Jeffrey Haas]

Aijun,


> On Apr 6, 2023, at 8:53 PM, Aijun Wang  wrote:
>> Providing additional detail to help illustrate the mechanism would be
>> in-scope and perhaps helpful.  Did you have any explicit recommendations for
>> the text?
> [WAJ] How about to refer the style of
> https://datatracker.ietf.org/doc/html/draft-ietf-idr-vpn-prefix-orf-00#secti
> on-8?

That seems reasonable.  Let's see what the authors say.

>>> Is there any other better style to point out the update to RFC5880?
>> 
>> Unfortunately, this is a common problem for internet-drafts that impact
>> protocol state machinery.  We have either the option of trying to issue a
>> "patch" on the draft, as we're doing here, or do a -bis of the base RFC to
>> more cleanly integrate the changes.
> [WAJ] How about to give the RFC also the version attribute like the draft?
> That is to say, for such "patch" or verbose text update, once the proposed
> draft is published, the updated contents will be incorporated into the base
> RFC automatically(no need to the overall long procedures for the bis
> document), but give its one new version number?  The bit RFC document can be
> labelled with the source that the updates are coming from.
> Maybe this should be discussed in more general scope?
> The final bis RFC document will be more easily referred and readable.

Using IEEE documents as an example, if there is an update to the base document, 
all of the changes are included in it.  If we ever do a RFC 5880-bis, or 
potentially do work to advance BFD to Internet Standard, this might be 
reasonable to do.

For now, the document is consistent with procedures we see in other working 
groups.

-- Jeff

Re： WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)

[Yisong Liu]

Hi WG，




I have read the document and support the publication.




Best Regards





Yisong

 



发件人: Jeffrey Haas

时间: 2023/03/22(星期三)00:02

收件人: rtg-bfd;

主题: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)Working 
Group,

https://datatracker.ietf.org/doc/draft-ietf-bfd-unaffiliated-echo/05/

The authors of draft-ietf-bfd-unaffiliated-echo have requested WGLC.

The draft, in my opinion, is in fairly good shape.  However, since it
functions via looping packets back to itself and trying to exercise the
normal RFC 5880 state machine behaviors to a large extent, the draft could
use very high scrutiny for several matters:

- Does the state machine behave appropriately at all stages?
- Are the descriptions of the values of the BFD fields clear in all cases?

Please supply the authors and the Working Group with your feedback.

The intended finish date for this WGLC is 7 April, 2023.  This is one week
after the end of IETF 116.

Note that Reshad is an author on the draft, so I'll be handling the full set
of review and shepherding work.

-- Jeff

Re: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)

[xiao.min2]

Jeff,






Thank you for the comments.


Please see inline...




Original



From: JeffreyHaas 
To: 肖敏10093570;
Cc: gregimir...@gmail.com ;rtg-bfd@ietf.org 
;
Date: 2023年04月06日 22:28
Subject: Re: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)


Xiao Min,
Thanks for addressing Greg's comments.  I some additional comment on Greg's 
points:


On Apr 6, 2023, at 3:35 AM,   wrote:
One of the considerations may be whether a IPv6 link local address is 
preferable to a global address.  
The only consideration for the draft as it is written is that the address used 
as the destination may be looped back by the unaffiliated device.  Link local 
helps address the security considerations that impact this feature, and it 
might be worth noting that when link local can be used for the use case that it 
assists in this point.
[XM]>>> I checked this with the implementer of this feature, and I'm told 
setting the DA to a IPv6 link local address doesn't work, because the link 
local address can't be looped back by the neighboring device.




Since the feature is intended to be used for single-hop, the source address 
SHOULD be an address on the shared subnet with the interface of the device that 
is looping the packets back.  Perhaps it might even be reasonable to require 
that the source and destination addresses are identical when possible?

Where this may complicate procedure is the initial demultiplexing step when the 
session is Down.  Once the session is Up, the Discriminators can be used for 
this purpose.

[XM]>>> I propose the text change as below.


OLD

Device A would send BFD Unaffiliated Echo packets with IP destination
 address destined for itself, such as the IP address of interface 1 of
 device A.
NEW

Device A would send BFD Unaffiliated Echo packets with IP destination
 address destined for itself, such as the IP address of interface 1 of
 device A. The IP source address of the BFD Unaffiliated Echo packets
 could be identical to the IP destination address or other address provisioned
 on device A.


Regards,

Xiao Min




-- Jeff












The draft describes how the destination IP address of the Echo packet is set. 
Are there any special considerations for selecting IPv6 destination address?


[XM]>>> The draft currently says "Device A would send BFD Unaffiliated Echo 
packets with IP destination address destined for itself, such as the IP address 
of interface 1 of device A". No any special considerations.

Re: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)

[Gyan Mishra]

Support publication.

Thank you

Gyan

On Tue, Mar 21, 2023 at 12:02 PM Jeffrey Haas  wrote:

> Working Group,
>
> https://datatracker.ietf.org/doc/draft-ietf-bfd-unaffiliated-echo/05/
>
> The authors of draft-ietf-bfd-unaffiliated-echo have requested WGLC.
>
> The draft, in my opinion, is in fairly good shape.  However, since it
> functions via looping packets back to itself and trying to exercise the
> normal RFC 5880 state machine behaviors to a large extent, the draft could
> use very high scrutiny for several matters:
>
> - Does the state machine behave appropriately at all stages?
> - Are the descriptions of the values of the BFD fields clear in all cases?
>
> Please supply the authors and the Working Group with your feedback.
>
> The intended finish date for this WGLC is 7 April, 2023.  This is one week
> after the end of IETF 116.
>
> Note that Reshad is an author on the draft, so I'll be handling the full
> set
> of review and shepherding work.
>
> -- Jeff
>
> --



*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mis...@verizon.com *



*M 301 502-1347*

RE: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)

[Aijun Wang]

Hi, Jeffrey:

Please see the inline replies [WAJ]

-Original Message-
From: Jeffrey Haas  
Sent: Thursday, April 6, 2023 10:22 PM
To: Aijun Wang 
Cc: rtg-bfd@ietf.org
Subject: Re: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April,
2023)

Aijun,


> On Apr 4, 2023, at 5:28 AM, Aijun Wang  wrote:
> From the description of this document, the state machine of local 
> device is conformed that described in RFC5880, the main standard parts 
> of this document are the contents of related fields within the BFD 
> ECHO Packet. If so, I suggested to point out these fields and its 
> value in more explicit manner, to facilitate the implementation
interoperability.

Perversely, the fact that this mechanism has an implementation "talking to
itself" means the interoperability considerations are not a primary issue.

Providing additional detail to help illustrate the mechanism would be
in-scope and perhaps helpful.  Did you have any explicit recommendations for
the text?
[WAJ] How about to refer the style of
https://datatracker.ietf.org/doc/html/draft-ietf-idr-vpn-prefix-orf-00#secti
on-8?

> Should the section 2(update to RFC5880) be moved afterwards the 
> section 3(Unaffiliated BFD Echo Procedures)?
> And I am worrying that is it easy for the reader/implementer to keep 
> up with the updated contents in current manner, because they must 
> compare the two documents simultaneously?

I agree that this would be a helpful change.  It would move the procedure
ahead of the changes that impact the BFD normative text.

> 
> Is there any other better style to point out the update to RFC5880?

Unfortunately, this is a common problem for internet-drafts that impact
protocol state machinery.  We have either the option of trying to issue a
"patch" on the draft, as we're doing here, or do a -bis of the base RFC to
more cleanly integrate the changes.
[WAJ] How about to give the RFC also the version attribute like the draft?
That is to say, for such "patch" or verbose text update, once the proposed
draft is published, the updated contents will be incorporated into the base
RFC automatically(no need to the overall long procedures for the bis
document), but give its one new version number?  The bit RFC document can be
labelled with the source that the updates are coming from.
Maybe this should be discussed in more general scope?
The final bis RFC document will be more easily referred and readable.

Since I think this feature is best documented as an optional extension at
this time, the "patch" format is our best option.

-- Jeff

Re: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)

[Jeffrey Haas]

Greg,


> On Mar 27, 2023, at 1:40 AM, Greg Mirsky  wrote:
> 
> Dear Authors,
> I read the latest version of the draft. I appreciate your work on improving 
> its readability. I have several concerns and appreciate your consideration:
> It appears like the document defines the format of the Echo message. As I 
> understand the RFC 5880, the format of the Echo message is not specified in 
> the RFC 5880. It seems like by defining the format in this document, you 
> affect RFC 5880 compliance of implementations that do support RFC 5880 as it 
> exists today.
One way to alternatively view this is we're documenting what one implementation 
puts in its Echo packets.  This draft does not try to require that all BFD Echo 
implementations use these procedures.

> The draft, in my opinion, significantly changes the architecture of the BFD, 
> as it is defined in RFC 5880. I believe that characterizing Echo as a 
> function stresses its dependency from a BFD mode, Asynchronous and Demand. 
> The changes proposed in this draft are very extensive and severely affect the 
> existing architecture of BFD by setting the Echo function on par, unrelated 
> with the BFD modes.

Interesting.  My view has been that this mechanism leverages existing BFD Async 
procedures to avoid trying to completely invent new mechanisms for the 
unafilliated case.  Where I might have some level of agreement with your point 
is this "mode" needs to be clearly defined from a configuration standpoint.  
For example, how would it manifest in YANG?

> Also, I think that the normative language in the last paragraph of the 
> Secrity Considerations sections are too soft. Currently used recommendation 
> level, in my opinion, is insufficient and should be brought to the 
> requirement level. I.e., I propose s/RECOMMENDED/MUST/ and s/SHOULD NOT/SHALL 
> NOT/

I'd recommend that you show the explicit sections you want updated.  Using 
version -06:
- I would not personally suggest that the RECOMMENDED for authentication turn 
into a MUST.  BFD Authentication simply isn't used in enough circumstances to 
try to turn this into the default case, especially when the intent of this 
feature is to deal with systems that don't have a matching BFD on the opposite 
side.
- I not super supportive of the SHOULD NOT for the TTL 255 loop being upgraded 
to SHALL NOT.  This will likely make a number of existing deployments of this 
feature non-conformant.

Please note that I expect to have a repeat of this conversation with the 
security AD during review.  So, your comments are apropos.

-- Jeff

Re: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)

[Jeffrey Haas]

Xiao Min,

Thanks for addressing Greg's comments.  I some additional comment on Greg's 
points:


> On Apr 6, 2023, at 3:35 AM,   
> wrote:
> The draft describes how the destination IP address of the Echo packet is set. 
> Are there any special considerations for selecting IPv6 destination address?
> 
> [XM]>>> The draft currently says "Device A would send BFD Unaffiliated Echo 
> packets with IP destination address destined for itself, such as the IP 
> address of interface 1 of device A". No any special considerations.
> 
> 
One of the considerations may be whether a IPv6 link local address is 
preferable to a global address.  

The only consideration for the draft as it is written is that the address used 
as the destination may be looped back by the unaffiliated device.  Link local 
helps address the security considerations that impact this feature, and it 
might be worth noting that when link local can be used for the use case that it 
assists in this point.

> Also, are there any special considerations for selecting the source IP 
> address for IPv4 and/or IPv6 network?
> 
> [XM]>>> No. If you have any suggestions, please let me know. :)
> 
> 
Since the feature is intended to be used for single-hop, the source address 
SHOULD be an address on the shared subnet with the interface of the device that 
is looping the packets back.  Perhaps it might even be reasonable to require 
that the source and destination addresses are identical when possible?

Where this may complicate procedure is the initial demultiplexing step when the 
session is Down.  Once the session is Up, the Discriminators can be used for 
this purpose.

-- Jeff

Re: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)

[Jeffrey Haas]

Aijun,


> On Apr 4, 2023, at 5:28 AM, Aijun Wang  wrote:
> From the description of this document, the state machine of local device is
> conformed that described in RFC5880, the main standard parts of this
> document are the contents of related fields within the BFD ECHO Packet. If
> so, I suggested to point out these fields and its value in more explicit
> manner, to facilitate the implementation interoperability.

Perversely, the fact that this mechanism has an implementation "talking to 
itself" means the interoperability considerations are not a primary issue.

Providing additional detail to help illustrate the mechanism would be in-scope 
and perhaps helpful.  Did you have any explicit recommendations for the text?

> Should the section 2(update to RFC5880) be moved afterwards the section
> 3(Unaffiliated BFD Echo Procedures)? 
> And I am worrying that is it easy for the reader/implementer to keep up with
> the updated contents in current manner, because they must compare the two
> documents simultaneously? 

I agree that this would be a helpful change.  It would move the procedure ahead 
of the changes that impact the BFD normative text.

> 
> Is there any other better style to point out the update to RFC5880?

Unfortunately, this is a common problem for internet-drafts that impact 
protocol state machinery.  We have either the option of trying to issue a 
"patch" on the draft, as we're doing here, or do a -bis of the base RFC to more 
cleanly integrate the changes.

Since I think this feature is best documented as an optional extension at this 
time, the "patch" format is our best option.

-- Jeff

Re: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)

[xiao.min2]

Greg,






Thank you for the detailed reply.


I suspect I've known where your concern derive from, that's a misunderstanding.


Note that the Unaffiliated BFD Echo is NOT intended to replace the BFD Echo 
function defined in RFC 5880.


I don't think an interoperability between a system using the RFC5880-style Echo 
function and a system with the unaffiliated Echo is needed.


In Figure 1, device A supports BFD and device B does not support BFD, that 
means neither device A nor device B can run RFC5880-style Echo function in this 
scenario.


With that said, I suggest to add below text into the third paragraph from the 
bottom of Introduction section, clarifying the relationship between the 
Unaffiliated BFD Echo and the RFC5880-style Echo.


NEW


The former scenario is not changed by this document in any way.







As to your new technical questions, please see inline...



Original



From: GregMirsky 
To: 肖敏10093570;
Cc: jh...@pfrc.org ;rtg-bfd@ietf.org ;
Date: 2023年04月06日 09:03
Subject: Re: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)




Hi Xiao Min,thank you for sharing your views. I have several technical 
questions:
As this specification replaces the Echo function defined in RFC 5880, I expect 
it will describe the applicability of the new Echo functionality when the link 
in Figure 1 is a tunnel or a member link of a LAG.

[XM]>>> As said above, this specification does NOT replace the Echo function 
defined in RFC 5880, it adds a new usage of BFD Echo while not affecting the 
existing one. In section 2.2 of RFC 7130 (BFD on LAG), it says "the use of the 
BFD echo function is outside the scope of this document".

The draft describes how the destination IP address of the Echo packet is set. 
Are there any special considerations for selecting IPv6 destination address?

[XM]>>> The draft currently says "Device A would send BFD Unaffiliated Echo 
packets with IP destination address destined for itself, such as the IP address 
of interface 1 of device A". No any special considerations.

Also, are there any special considerations for selecting the source IP address 
for IPv4 and/or IPv6 network?

[XM]>>> No. If you have any suggestions, please let me know. :)




Best Regards,

Xiao Min




Furthermore, please find my notes below under the GIM>> tag.


Regards,
Greg




On Sun, Apr 2, 2023 at 6:51 PM  wrote:


Dear Greg,






Thanks for sharing your thoughts, even if they're concerns.


Please see inline...



Original


From: GregMirsky 
To: Jeffrey Haas ;
Cc: rtg-bfd@ietf.org ;
Date: 2023年03月27日 13:40
Subject: Re: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)


Dear Authors,I read the latest version of the draft. I appreciate your work on 
improving its readability. I have several concerns and appreciate your 
consideration:
It appears like the document defines the format of the Echo message. As I 
understand the RFC 5880, the format of the Echo message is not specified in the 
RFC 5880. It seems like by defining the format in this document, you affect RFC 
5880 compliance of implementations that do support RFC 5880 as it exists today.

[XM]>>> As far as I can tell, several vendors have implemented this feature and 
nobody reports the problem.









GIM>>I think that it would be beneficial to reflect information about existing 
implementation in the Implementation State section as described in RFC 7942. At 
the same time, your update about deployed implementations doesn't resolve my 
concern about the impact of the proposal on earlier implementations of the Echo 
function as it is defined in RFC 5880.






The draft, in my opinion, significantly changes the architecture of the BFD, as 
it is defined in RFC 5880. I believe that characterizing Echo as a function 
stresses its dependency from a BFD mode, Asynchronous and Demand. The changes 
proposed in this draft are very extensive and severely affect the existing 
architecture of BFD by setting the Echo function on par, unrelated with the BFD 
modes.

[XM]>>> Please see above.









GIM>> My question is about the impact on implementations that support the Echo 
function as currently defined in RFC 5880. Perhaps you have verified that 
there's no adverse impact? Please, if you have it, share information about any 
interoperability between a system using the RFC5880-style Echo function and a 
system with the unaffiliated Echo.






Also, I think that the normative language in the last paragraph of the Secrity 
Considerations sections are too soft. Currently used recommendation level, in 
my opinion, is insufficient and should be brought to the requirement level. 
I.e., I propose s/RECOMMENDED/MUST/ and s/SHOULD NOT/SHALL NOT/

[XM]>>> I agree we can strengthen the requirements for security. I'll 
incorporate the changes you proposed if no objection from others.




In conclusion, I am very much concerned with 

Re: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)

[xiao.min2]

Aijun,






Thanks for your support and review.



Please see inline...



Original



From: AijunWang 
To: 'Jeffrey Haas' ;rtg-bfd@ietf.org ;
Date: 2023年04月04日 17:28
Subject: RE: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)


Support its forwarding.
 
The implementation and deployment of unaffiliated-echo can extend the BFD
based fault detection technology in large scale, because it has no special
BFD related requirements to the other side.
 [XM]>>> I absolutely agree.




>From the description of this document, the state machine of local device is
conformed that described in RFC5880, the main standard parts of this
document are the contents of related fields within the BFD ECHO Packet. If
so, I suggested to point out these fields and its value in more explicit
manner, to facilitate the implementation interoperability.
 [XM]>>> Note that BFD Unaffiliated Echo does not use the AdminDown state.

Jeff has proposed a number of text changes to improve the readability, and I'm 
sure there is still room for improvement.




Should the section 2(update to RFC5880) be moved afterwards the section
3(Unaffiliated BFD Echo Procedures)?  
And I am worrying that is it easy for the reader/implementer to keep up with
the updated contents in current manner, because they must compare the two
documents simultaneously?  
 
Is there any other better style to point out the update to RFC5880?
 [XM]>>> There was a discussion among the authors on how to describe the 
updates to RFC 5880, and the current style was the best one we can think of. If 
there is a better style, I'm happy to do a switch.




Thanks,

Xiao Min




Best Regards
 
Aijun Wang
China Telecom
 
-Original Message-
From: rtg-bfd-boun...@ietf.org  On Behalf Of
Jeffrey Haas
Sent: Wednesday, March 22, 2023 12:02 AM
To: rtg-bfd@ietf.org
Subject: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)
 
Working Group,
 
https://datatracker.ietf.org/doc/draft-ietf-bfd-unaffiliated-echo/05/
 
The authors of draft-ietf-bfd-unaffiliated-echo have requested WGLC.
 
The draft, in my opinion, is in fairly good shape.  However, since it
functions via looping packets back to itself and trying to exercise the
normal RFC 5880 state machine behaviors to a large extent, the draft could
use very high scrutiny for several matters:
 
- Does the state machine behave appropriately at all stages?
- Are the descriptions of the values of the BFD fields clear in all cases?
 
Please supply the authors and the Working Group with your feedback.
 
The intended finish date for this WGLC is 7 April, 2023.  This is one week
after the end of IETF 116.
 
Note that Reshad is an author on the draft, so I'll be handling the full set
of review and shepherding work.
 
-- Jeff

Re: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)

[Greg Mirsky]

Hi Xiao Min,
thank you for sharing your views. I have several technical questions:

   - As this specification replaces the Echo function defined in RFC 5880,
   I expect it will describe the applicability of the new Echo functionality
   when the link in Figure 1 is a tunnel or a member link of a LAG.
   - The draft describes how the destination IP address of the Echo packet
   is set. Are there any special considerations for selecting IPv6 destination
   address?
   - Also, are there any special considerations for selecting the source IP
   address for IPv4 and/or IPv6 network?

Furthermore, please find my notes below under the GIM>> tag.

Regards,
Greg

On Sun, Apr 2, 2023 at 6:51 PM  wrote:

> Dear Greg,
>
>
> Thanks for sharing your thoughts, even if they're concerns.
>
> Please see inline...
> Original
> *From: *GregMirsky 
> *To: *Jeffrey Haas ;
> *Cc: *rtg-bfd@ietf.org ;
> *Date: *2023年03月27日 13:40
> *Subject: **Re: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7
> April, 2023)*
> Dear Authors,
> I read the latest version of the draft. I appreciate your work on
> improving its readability. I have several concerns and appreciate your
> consideration:
>
>-
>
>It appears like the document defines the format of the Echo message.
>As I understand the RFC 5880, the format of the Echo message is not
>specified in the RFC 5880. It seems like by defining the format in this
>document, you affect RFC 5880 compliance of implementations that do support
>RFC 5880 as it exists today.
>
>[XM]>>> As far as I can tell, several vendors have implemented this
>feature and nobody reports the problem.
>
> GIM>>I think that it would be beneficial to reflect information about
existing implementation in the Implementation State section as described in RFC
7942 <https://datatracker.ietf.org/doc/rfc7942/>. At the same time, your
update about deployed implementations doesn't resolve my concern about the
impact of the proposal on earlier implementations of the Echo function as
it is defined in RFC 5880.

>
>-
>
>
>-
>
>The draft, in my opinion, significantly changes the architecture of
>the BFD, as it is defined in RFC 5880. I believe that characterizing Echo
>as a function stresses its dependency from a BFD mode, Asynchronous and
>Demand. The changes proposed in this draft are very extensive and severely
>affect the existing architecture of BFD by setting the Echo function on
>par, unrelated with the BFD modes.
>
>[XM]>>> Please see above.
>
> GIM>> My question is about the impact on implementations that support the
Echo function as currently defined in RFC 5880. Perhaps you have verified
that there's no adverse impact? Please, if you have it, share information
about any interoperability between a system using the RFC5880-style Echo
function and a system with the unaffiliated Echo.

>
>-
>
>
>-
>
>Also, I think that the normative language in the last paragraph of the
>Secrity Considerations sections are too soft. Currently used recommendation
>level, in my opinion, is insufficient and should be brought to the
>requirement level. I.e., I propose s/RECOMMENDED/MUST/ and s/SHOULD
>NOT/SHALL NOT/
>
>[XM]>>> I agree we can strengthen the requirements for security. I'll
>incorporate the changes you proposed if no objection from others.
>
>
>
> In conclusion, I am very much concerned with the amount of changes to the
> BFD architecture proposed in the document. I am also concerned with the
> affect on the protocol conformance standing of the established BFD
> implementations, SH BFD in particular. Hence, I propose changing this draft
> to the Experimental track.
>
> [XM]>>> As said, I have different opinion on the implication of this
> feature. As to the Standards Track vs Experimental Track, I'm open to it, I
> personally prefer the former.
>
>
> Cheers,
>
> Xiao Min
>
>
> Regards,
> Greg
>
> On Tue, Mar 21, 2023 at 11:02 AM Jeffrey Haas  wrote:
>
>> Working Group,
>>
>> https://datatracker.ietf.org/doc/draft-ietf-bfd-unaffiliated-echo/05/
>>
>> The authors of draft-ietf-bfd-unaffiliated-echo have requested WGLC.
>>
>> The draft, in my opinion, is in fairly good shape.  However, since it
>> functions via looping packets back to itself and trying to exercise the
>> normal RFC 5880 state machine behaviors to a large extent, the draft could
>> use very high scrutiny for several matters:
>>
>> - Does the state machine behave appropriately at all stages?
>> - Are the descriptions of the values of the BFD fields clear in all cases?
>>
>> Please supply the authors and the Working Group with your feedback.
>>
>> The intended finish date for this WGLC is 7 April, 2023.  This is one week
>> after the end of IETF 116.
>>
>> Note that Reshad is an author on the draft, so I'll be handling the full
>> set
>> of review and shepherding work.
>>
>> -- Jeff
>>
>>
>>
>

RE: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)

[Aijun Wang]

Support its forwarding.

The implementation and deployment of unaffiliated-echo can extend the BFD
based fault detection technology in large scale, because it has no special
BFD related requirements to the other side.

>From the description of this document, the state machine of local device is
conformed that described in RFC5880, the main standard parts of this
document are the contents of related fields within the BFD ECHO Packet. If
so, I suggested to point out these fields and its value in more explicit
manner, to facilitate the implementation interoperability.

Should the section 2(update to RFC5880) be moved afterwards the section
3(Unaffiliated BFD Echo Procedures)? 
And I am worrying that is it easy for the reader/implementer to keep up with
the updated contents in current manner, because they must compare the two
documents simultaneously? 

Is there any other better style to point out the update to RFC5880?

Best Regards

Aijun Wang
China Telecom

-Original Message-
From: rtg-bfd-boun...@ietf.org  On Behalf Of
Jeffrey Haas
Sent: Wednesday, March 22, 2023 12:02 AM
To: rtg-bfd@ietf.org
Subject: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)

Working Group,

https://datatracker.ietf.org/doc/draft-ietf-bfd-unaffiliated-echo/05/

The authors of draft-ietf-bfd-unaffiliated-echo have requested WGLC.

The draft, in my opinion, is in fairly good shape.  However, since it
functions via looping packets back to itself and trying to exercise the
normal RFC 5880 state machine behaviors to a large extent, the draft could
use very high scrutiny for several matters:

- Does the state machine behave appropriately at all stages?
- Are the descriptions of the values of the BFD fields clear in all cases?

Please supply the authors and the Working Group with your feedback.

The intended finish date for this WGLC is 7 April, 2023.  This is one week
after the end of IETF 116.

Note that Reshad is an author on the draft, so I'll be handling the full set
of review and shepherding work.

-- Jeff

Re: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)

[linchangwang]

Hi all，


I've read the document and believe it is ready for publication.

We have lots of deployments using BFD Echo，such as local protection for faster 
failure dection.
It would be greatly appreciated if this draft could be standardized ASAP!

Best Regards，
Changwang lin



Original
From: JeffreyHaas 
To: rtg-bfd@ietf.org ;
Date: 2023年03月22日 00:02
Subject: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)
Working Group,

https://datatracker.ietf.org/doc/draft-ietf-bfd-unaffiliated-echo/05/

The authors of draft-ietf-bfd-unaffiliated-echo have requested WGLC.

The draft, in my opinion, is in fairly good shape.  However, since it
functions via looping packets back to itself and trying to exercise the
normal RFC 5880 state machine behaviors to a large extent, the draft could
use very high scrutiny for several matters:

- Does the state machine behave appropriately at all stages?
- Are the descriptions of the values of the BFD fields clear in all cases?

Please supply the authors and the Working Group with your feedback.

The intended finish date for this WGLC is 7 April, 2023.  This is one week
after the end of IETF 116.

Note that Reshad is an author on the draft, so I'll be handling the full set
of review and shepherding work.

-- Jeff



-
本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出
的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、
或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本
邮件！
This e-mail and its attachments contain confidential information from New H3C, 
which is
intended only for the person or entity whose address is listed above. Any use 
of the
information contained herein in any way (including, but not limited to, total 
or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify 
the sender
by phone or email immediately and delete it!

Re: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)

[xiao.min2]

Dear Greg,






Thanks for sharing your thoughts, even if they're concerns.


Please see inline...



Original



From: GregMirsky 
To: Jeffrey Haas ;
Cc: rtg-bfd@ietf.org ;
Date: 2023年03月27日 13:40
Subject: Re: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)



Dear Authors,I read the latest version of the draft. I appreciate your work on 
improving its readability. I have several concerns and appreciate your 
consideration:
It appears like the document defines the format of the Echo message. As I 
understand the RFC 5880, the format of the Echo message is not specified in the 
RFC 5880. It seems like by defining the format in this document, you affect RFC 
5880 compliance of implementations that do support RFC 5880 as it exists today.

[XM]>>> As far as I can tell, several vendors have implemented this feature and 
nobody reports the problem.




The draft, in my opinion, significantly changes the architecture of the BFD, as 
it is defined in RFC 5880. I believe that characterizing Echo as a function 
stresses its dependency from a BFD mode, Asynchronous and Demand. The changes 
proposed in this draft are very extensive and severely affect the existing 
architecture of BFD by setting the Echo function on par, unrelated with the BFD 
modes.

[XM]>>> Please see above.




Also, I think that the normative language in the last paragraph of the Secrity 
Considerations sections are too soft. Currently used recommendation level, in 
my opinion, is insufficient and should be brought to the requirement level. 
I.e., I propose s/RECOMMENDED/MUST/ and s/SHOULD NOT/SHALL NOT/

[XM]>>> I agree we can strengthen the requirements for security. I'll 
incorporate the changes you proposed if no objection from others.




In conclusion, I am very much concerned with the amount of changes to the BFD 
architecture proposed in the document. I am also concerned with the affect on 
the protocol conformance standing of the established BFD implementations, SH 
BFD in particular. Hence, I propose changing this draft to the Experimental 
track.

[XM]>>> As said, I have different opinion on the implication of this feature. 
As to the Standards Track vs Experimental Track, I'm open to it, I personally 
prefer the former.





Cheers,

Xiao Min




Regards,
Greg




On Tue, Mar 21, 2023 at 11:02 AM Jeffrey Haas  wrote:

Working Group,
 
 https://datatracker.ietf.org/doc/draft-ietf-bfd-unaffiliated-echo/05/
 
 The authors of draft-ietf-bfd-unaffiliated-echo have requested WGLC.
 
 The draft, in my opinion, is in fairly good shape.  However, since it
 functions via looping packets back to itself and trying to exercise the
 normal RFC 5880 state machine behaviors to a large extent, the draft could
 use very high scrutiny for several matters:
 
 - Does the state machine behave appropriately at all stages?
 - Are the descriptions of the values of the BFD fields clear in all cases?
 
 Please supply the authors and the Working Group with your feedback.
 
 The intended finish date for this WGLC is 7 April, 2023.  This is one week
 after the end of IETF 116.
 
 Note that Reshad is an author on the draft, so I'll be handling the full set
 of review and shepherding work.
 
 -- Jeff

Re: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)

[xiao.min2]

Jeff,






Thank you for initiating WGLC on this draft per request of the authors.


I support progressing this draft to publication (as a co-author).


I agree with you that the draft could use very high scrutiny.



Note that I've posted version -06 attempting to address your last call 
comments, and the detailed reply has been sent to the mailing list. Links as 
below.


https://datatracker.ietf.org/doc/html/draft-ietf-bfd-unaffiliated-echo-06 




https://mailarchive.ietf.org/arch/msg/rtg-bfd/si2-rPPZxe6l8tq8xJZEEY8DlDM/
 
Best Regards,


Xiao Min



Original



From: JeffreyHaas 
To: rtg-bfd@ietf.org ;
Date: 2023年03月22日 00:02
Subject: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)


Working Group,
 
https://datatracker.ietf.org/doc/draft-ietf-bfd-unaffiliated-echo/05/
 
The authors of draft-ietf-bfd-unaffiliated-echo have requested WGLC.
 
The draft, in my opinion, is in fairly good shape.  However, since it
functions via looping packets back to itself and trying to exercise the
normal RFC 5880 state machine behaviors to a large extent, the draft could
use very high scrutiny for several matters:
 
- Does the state machine behave appropriately at all stages?
- Are the descriptions of the values of the BFD fields clear in all cases?
 
Please supply the authors and the Working Group with your feedback.
 
The intended finish date for this WGLC is 7 April, 2023.  This is one week
after the end of IETF 116.
 
Note that Reshad is an author on the draft, so I'll be handling the full set
of review and shepherding work.
 
-- Jeff

Re: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)

[Greg Mirsky]

Dear Authors,
I read the latest version of the draft. I appreciate your work on improving
its readability. I have several concerns and appreciate your consideration:

   - It appears like the document defines the format of the Echo message.
   As I understand the RFC 5880, the format of the Echo message is not
   specified in the RFC 5880. It seems like by defining the format in this
   document, you affect RFC 5880 compliance of implementations that do support
   RFC 5880 as it exists today.
   - The draft, in my opinion, significantly changes the architecture of
   the BFD, as it is defined in RFC 5880. I believe that characterizing Echo
   as a function stresses its dependency from a BFD mode, Asynchronous and
   Demand. The changes proposed in this draft are very extensive and severely
   affect the existing architecture of BFD by setting the Echo function on
   par, unrelated with the BFD modes.
   - Also, I think that the normative language in the last paragraph of the
   Secrity Considerations sections are too soft. Currently used recommendation
   level, in my opinion, is insufficient and should be brought to the
   requirement level. I.e., I propose s/RECOMMENDED/MUST/ and s/SHOULD
   NOT/SHALL NOT/

In conclusion, I am very much concerned with the amount of changes to the
BFD architecture proposed in the document. I am also concerned with the
affect on the protocol conformance standing of the established BFD
implementations, SH BFD in particular. Hence, I propose changing this draft
to the Experimental track.

Regards,
Greg

On Tue, Mar 21, 2023 at 11:02 AM Jeffrey Haas  wrote:

> Working Group,
>
> https://datatracker.ietf.org/doc/draft-ietf-bfd-unaffiliated-echo/05/
>
> The authors of draft-ietf-bfd-unaffiliated-echo have requested WGLC.
>
> The draft, in my opinion, is in fairly good shape.  However, since it
> functions via looping packets back to itself and trying to exercise the
> normal RFC 5880 state machine behaviors to a large extent, the draft could
> use very high scrutiny for several matters:
>
> - Does the state machine behave appropriately at all stages?
> - Are the descriptions of the values of the BFD fields clear in all cases?
>
> Please supply the authors and the Working Group with your feedback.
>
> The intended finish date for this WGLC is 7 April, 2023.  This is one week
> after the end of IETF 116.
>
> Note that Reshad is an author on the draft, so I'll be handling the full
> set
> of review and shepherding work.
>
> -- Jeff
>
>

Re: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)

[Jeffrey Haas]

Note that the draft is currently expired and will be refreshed when the IETF 
116 restrictions permit that to happen.

-- Jeff


> On Mar 21, 2023, at 12:02 PM, Jeffrey Haas  wrote:
> 
> Working Group,
> 
> https://datatracker.ietf.org/doc/draft-ietf-bfd-unaffiliated-echo/05/
> 
> The authors of draft-ietf-bfd-unaffiliated-echo have requested WGLC.
> 
> The draft, in my opinion, is in fairly good shape.  However, since it
> functions via looping packets back to itself and trying to exercise the
> normal RFC 5880 state machine behaviors to a large extent, the draft could
> use very high scrutiny for several matters:
> 
> - Does the state machine behave appropriately at all stages?
> - Are the descriptions of the values of the BFD fields clear in all cases?
> 
> Please supply the authors and the Working Group with your feedback.
> 
> The intended finish date for this WGLC is 7 April, 2023.  This is one week
> after the end of IETF 116.
> 
> Note that Reshad is an author on the draft, so I'll be handling the full set
> of review and shepherding work.
> 
> -- Jeff

WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)

[Jeffrey Haas]

Working Group,

https://datatracker.ietf.org/doc/draft-ietf-bfd-unaffiliated-echo/05/

The authors of draft-ietf-bfd-unaffiliated-echo have requested WGLC.

The draft, in my opinion, is in fairly good shape.  However, since it
functions via looping packets back to itself and trying to exercise the
normal RFC 5880 state machine behaviors to a large extent, the draft could
use very high scrutiny for several matters:

- Does the state machine behave appropriately at all stages?
- Are the descriptions of the values of the BFD fields clear in all cases?

Please supply the authors and the Working Group with your feedback.

The intended finish date for this WGLC is 7 April, 2023.  This is one week
after the end of IETF 116.

Note that Reshad is an author on the draft, so I'll be handling the full set
of review and shepherding work.

-- Jeff