I’m not aware of any IPR applicable to this draft.
thanks.
- Naiming
> On Oct 20, 2021, at 7:07 AM, Jeffrey Haas wrote:
>
> BFD Unsolicited Authors,
>
> As part of doing the document shepherd writeup for BFD Unsolicited prior to
> sending it to the IESG for publication, I reviewed the archive
Also regarding the simplification, normally this is operated in some ’trusted’
environment,
e.g. in some trusted IXP subnet where the route server is at. Even the router
does apply
the ‘access control’ on the subnet, it is much simpler than pre-configuring
hundreds of BFD
peers on the subnet,
Hi Magnus,
Thanks for the review and comments. We will update the draft soon to address
some of them. Please see some replies inline with and .
> 1) Section 7.1
> The formulations around the mitigations are poorly worded.
> a) First the lead in to the bullet list states that this is mandatory
Hi Magnus,
Thanks again for the comments and discussions. See more replies inline with
…
> On Nov 22, 2022, at 03:09, Magnus Westerlund
> wrote:
>
> Hi,
>
> Please see inline for my comments prefix with [MW].
>
>
>
>
> > b) "Limit the feature to specific
> > interfaces, and to single
Support.
- Naiming
On Oct 17, 2018, at 6:06 PM, Reshad Rahman (rrahman)
mailto:rrah...@cisco.com>> wrote:
Hello BFD WG,
We have received an adoption request for “BFD encapsulated in large packets”.
https://datatracker.ietf.org/doc/draft-haas-bfd-large-packets/
The adoption call will end on
It probably should say “the payload size MAY be increased to this value and it
is
not recommended for a BFD session to always use the large size packet for
padding.
How frequent the large size packet being used is application specific”.
for the variety of encaps, the internal application probab
Les,
On Oct 21, 2018, at 3:26 PM, Les Ginsberg (ginsberg)
mailto:ginsb...@cisco.com>> wrote:
Naiming –
Inline…
From: Naiming Shen (naiming)
Sent: Sunday, October 21, 2018 3:12 PM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Cc: Reshad Rahman (rrahman) mailto:rrah.
:ginsb...@cisco.com>> wrote:
Naiming -
Thanx for the good discussion. Responses inline.
From: Naiming Shen (naiming)
Sent: Sunday, October 21, 2018 3:36 PM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Cc: Reshad Rahman (rrahman) mailto:rrah...@cisco.com>>;
rtg-bfd@ietf.org
I understand in some networks (such as in the network Albert mentioned about)
it may need sub-second detection if the MTU has been impacted on the path,
but that should only be an implementation/operational option, I would think most
of the networks will not use this way. The draft should handle
Support as a co-author.
Regards,
- Naiming
> On Oct 29, 2018, at 8:52 AM, Jeffrey Haas wrote:
>
> Working Group,
>
> Reviewing my notes, I was remiss in sending out an adoption request for
> draft-chen-bfd-unsolicted (Unsolicited BFD for Sessionless Applications).
>
> https://datatracker.ie
I’m not aware of an implementation taking in the inbound BFD packets,
then dynamically seting up a session to the received packet sender end-point.
As Jeff mentioned Redback planed on this, but didn’t implement. So there most
likely needs some BFD implementation changes.
Regards,
- Naiming
> On
raise this point because an implementation which has already addressed the
> issue has little motivation to move to a different solution (such as you
> propose).
> Which is why I am OK if this is merely informational - but not otherwise.
>
> Les
>
>
>> -Original M
12 matches
Mail list logo
