[Last-Call] Re: Opsdir last call review of draft-ietf-bfd-unaffiliated-echo-11

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Dhruv,


Thank you for the confirmation.

For the last two open items, please see inline.

Original
From: DhruvDhody <dhruv.ietf@xxxxxxxxx>
To: 肖敏10093570;
Cc: dd@xxxxxxxxxxxxxx <dd@xxxxxxxxxxxxxx>;ops-dir@xxxxxxxx <ops-dir@xxxxxxxx>;draft-ietf-bfd-unaffiliated-echo.all@xxxxxxxx <draft-ietf-bfd-unaffiliated-echo.all@xxxxxxxx>;last-call@xxxxxxxx <last-call@xxxxxxxx>;rtg-bfd@xxxxxxxx <rtg-bfd@xxxxxxxx>;
Date: 2024年10月10日 11:45
Subject: [Last-Call] Re: Opsdir last call review of draft-ietf-bfd-unaffiliated-echo-11
-- 
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
Hi Xiao,

I am happy with your resolutions! Snipping to...




The document does not include an explicit manageability & operational
considerations section. Authors could consider adding it. RFC 5880 has it and
it would make sense to call out considerations that are specific to
Unaffiliated BFD Echo (if any). For instance - Does BFD enabled system A know
that the BFD Echo session is unaffiliated? Is there a configuration? How does
it work with affiliated BFD Echo sessions?

[XM]>>> OK. Propose to add a new section 4 as below.

NEW

4.  Operational Considerations


   All Operational Considerations from [RFC5880] apply, except that

   the Unaffiliated BFD Echo can only be used across one hop, which

   result in unneccessity of a congestion control mechanism.


   Some devices that would benefit from the use of BFD may be unable to

   support the full BFD protocol.  Examples of such devices include

   servers running virtual machines, or Internet of Things (IoT)

   devices.


   As specified in Section 2 of this document, some configurations are

   needed to make the Unaffiliated BFD Echo work, although the

   configurations won't be beyond the scope of [RFC5880].

   At a BFD-enabled local system, the Unaffiliated BFD Echo session

   can coexist with other BFD session, in which scenario the remote

   systems and the local discriminators must be different, at the same

Dhruv: I am not able to parse this sentence. Do you mean that the ""My Discriminator" used by the local systems for unaffiliated BFD echo session should be different from affiliated ones?

[XM]>>> Yes. Exactly there is no affiliated BFD Echo session, because in RFC 5880 the Echo function is an adjunct to Asynchronous mode or Demand mode. For the relationship between the local discriminator and the "My Discriminator" field in the BFD Control packet, please refer to Section 6.3 of RFC 5880, it says

"

   Each system MUST choose an opaque discriminator value that identifies    each session, and which MUST be unique among all BFD sessions on the    system.  The local discriminator is sent in the My Discriminator    field in the BFD Control packet, and is echoed back in the Your    Discriminator field of packets sent from the remote end.

"


Dhruv2: I understand that, but I still can't parse "the remote systems and the local discriminators", perhaps this should be -  "the remote system's and the local system's discriminators must be different" or "the remote and the local system's discriminators must be different"....  

[XM]>>> I see the confusion in my proposed text.  Propose to rephrase the related text as below.

OLD

   At a BFD-enabled local system, the Unaffiliated BFD Echo session

   can coexist with other BFD session, in which scenario the remote

   systems and the local discriminators must be different, ...

NEW

   At a BFD-enabled local system, the Unaffiliated BFD Echo session

   can coexist with other BFD session, in which scenario the remote

   system for the Unaffiliated BFD Echo session must be different from the remote system for the other BFD session, and the local system's discriminators for different BFD sessions must be different, ...

END

 

<snip>

 

- It would make sense to have the use case described in this document itself

with suitable references. Reading section 6.2.2 of [BBF-TR-146] does not help
in having a clear description of why an Unaffiliated BFD Echo is needed.

[XM]>>> The original section 4 "Unaffiliated BFD Echo Applicability" was removed in version -11 as per suggestion from Eric Vyncke. In order to address your comments, I suggest to add some text from the original section 4 to the new added section 4 "Operational Considerations" as above.



Dhruv: Yes, just a sentence or two on usecase would be fine. 
[XM]>>> To make the usecase more explicit to the reader, I'll add one more sentence to the second paragraph of "Operational Considerations", now it reads
 "Some devices that would benefit from the use of BFD may be unable to

   support the full BFD protocol.  Examples of such devices include

   servers running virtual machines, or Internet of Things (IoT)

   devices. By using the Unaffiliated BFD Echo, what such devices need to support is only a simple loop-back function."

Is that ok for you?


Dhruv2: How about "By using Unaffiliated BFD Echo, these devices only need to support a basic loopback function."

[XM]>>> Yes, will use your text in the next revision.


Cheers,

Xiao Min


<snip>

Thanks! 
Dhruv


-- 
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux