On 12/18/15, 2:07 AM, "Santosh P K" <[email protected]> wrote:
Santosh:
Hi!
>Please see my inline comments tagged [SPK]. I will send diff and updated
>draft after all the received review comments are addressed.
I looked at the update/diffs that you sent in a later message.
Just a couple of comments left below..
Thanks!!
Alvaro.
. . .
>
>
>>
>>
>> * "bfd.RequiredMinRxInterval, value describing how many incoming control
>> packets this reflector BFD session can handle" But rfc5880 defines
>> bfd.RequiredMinRxInterval as "The minimum interval, in microseconds,
>> between received BFD Control packets". IOW, the definitions don't
>>match.
>>
>
>[SPK] Done.
Yes, you made the correction in (what is now) 7.2.2, but the text in 7.2.3
still reads:
o S-BFD control packets transmitted by the SBFDReflector MUST have
"Required Min RX Interval" set to a value which expresses how many
incoming S-BFD control packets this SBFDReflector can handle. The
SBFDReflector can control how fast SBFInitiators will be sending
S-BFD control packets to self by ensuring "Required Min RX
Interval" indicates a value based on the current load.
. . .
>> >o Why isn't the "loop problem" in Appendix A mentioned?
>> >
>> >[SPK] It is mentioned in appendix A. Did you mean why is this
>>mentioned?
>> >This is to give more clarity on why we are overloading D bit to break
>>the
>> >loop.
>>
>> I meant why isn't it mentioned in the Security Considerations section?
>>If
>> it's a problem worth including in the document, I think it would be good
>> to point at it in a section that people may read.
>
>[SPK] It is a security issue and we have a solution for it by overloading
>D bit. Hence it is put in Appendix. If you think it is worth putting in
>security section with solution I shall do that.
You don't have to move the text, just mention it and point to the Appendix
(so people know it's there).
>
>
>>
>>
>> >
>> >8. Nowhere in this document (or draft-ietf-bfd-seamless-ip) is
>>congestion
>> >mentioned. rfc5880 talks about some of the considerations. Are there
>> >new congestion-related considerations that arise because of eliminating
>> >some of the negotiation aspects? Thinking out loud: if a session
>>doesn't
>> >have to be established (and everyone knows a remote discriminator),
>>then
>> >there's a possibility of more nodes sending traffic to a specific
>> >reflector (just as an example). Please include some text indicating
>>any
>> >congestion issues - or at least explaining why there aren't any new
>>ones.
>> >
>> >
>> >[SPK] It has no new congestion issues. SBFDRefelector will be able to
>>use
>> >"Required Min RX interval" to control rate from senders.
>> >
>> > " Required Min RX Interval
>> >
>> > MUST be set to a value describing how many incoming control
>> > packets this reflector BFD session can handle. Further
>>details
>> > are described in Section 7.8."
>> >
>> >
>> >Do you still think we need to add a separate section explaining it?
>>
>> I do.
>>
>> Also, in Carlos' answer (see [1] above), he wrote: "Very much agree. I
>> believe there are subtle differences in the congestion considerations,
>> because if the simplified negotiation. Further, I believe those should
>> live in the -base doc. That is missing, and we should fill in this gap."
>
>[SPK] There will be not much content for separate section. Any suggestion?
If there isn't enough for a separate section, then don't make it one..it's
up to you. I just want the differences included.
