Reshad,
On Fri, Oct 26, 2018 at 06:32:26PM +, Reshad Rahman (rrahman) wrote:
>On 2018-10-25, 11:38 AM, "Jeffrey Haas" wrote:
> > The draft I had previously worked on with Xiao Min discussing probing
> > using
> > BFD Echo had the concept of probes that would happen wherein the
> > s
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.ietf.org/doc/draft-chen-bfd-unsolicited/
This relatively minor change from the RFC 5880 spec is implemented by at
l
Mahesh,
On Mon, Oct 15, 2018 at 09:24:59PM -0700, Greg Mirsky wrote:
> thank you for your quick response. The comment regarding the state change,
> as I understand from the minutes, came from Jeff.
> Yes, the question was about the periodic authentication in Up state. I
> believe that at the meeti
Hi Jeff,
I'd be fine with the text below on BFD echo in the discussion section.
Regards,
Reshad.
On 2018-10-29, 11:36 AM, "Jeffrey Haas" wrote:
Reshad,
On Fri, Oct 26, 2018 at 06:32:26PM +, Reshad Rahman (rrahman) wrote:
>On 2018-10-25, 11:38 AM, "Jeffrey Haas" wrote:
Changed milestone "Submit a BFD Yang module to the IESG to be considered as a
Proposed Standard", resolved as "Done", added draft-ietf-bfd-yang to
milestone.
URL: https://datatracker.ietf.org/wg/bfd/about/
Deleted milestone "Submit a BFD MIB extension in support of the generic
keying document to the IESG to be considered as a Proposed Standard".
Deleted milestone "Submit the BFD MPLS extension MIB to the IESG to be
considered as a Proposed Standard".
URL: https://datatracker.ietf.org/wg/bfd/about/
Jeff/Albert -
Given the MTU issue is associated with a link coming up - and the use of Echo
would allow the problem to be detected and prevent the BFD session from coming
up -
and you are acknowledging that the protocol allows padded Echo packets today ...
is there really a need to do anything
On Mon, Oct 29, 2018 at 04:39:04PM +, Les Ginsberg (ginsberg) wrote:
> Given the MTU issue is associated with a link coming up - and the use of Echo
> would allow the problem to be detected and prevent the BFD session from
> coming up -
> and you are acknowledging that the protocol allows pa
Jeff -
I note that no one supports "large-packets" today.
So is the gap between supporting echo mode for this purpose any larger than the
gap for introducing large packet support?
Les
> -Original Message-
> From: Jeffrey Haas
> Sent: Monday, October 29, 2018 9:42 AM
> To: Les Ginsb
Hi Jeff,
> On Oct 29, 2018, at 9:10 AM, Jeffrey Haas wrote:
>
> Mahesh,
>
> On Mon, Oct 15, 2018 at 09:24:59PM -0700, Greg Mirsky wrote:
>> thank you for your quick response. The comment regarding the state change,
>> as I understand from the minutes, came from Jeff.
>> Yes, the question was ab
Les,
On Mon, Oct 29, 2018 at 04:55:05PM +, Les Ginsberg (ginsberg) wrote:
> I note that no one supports "large-packets" today.
A vapid phrase that I generally loathe hearing on IETF mailing lists. We
need our own version of [1]. When meant pleasantly, sometimes implies, "no,
I'm not aware o
Hi Les,
> Jeff/Albert -
>
> Given the MTU issue is associated with a link coming up - and the use of Echo
> would allow the problem to be detected and prevent the BFD session from
> coming up -
> and you are acknowledging that the protocol allows padded Echo packets today
> ...
>
> is there
Albert –
Do not confuse the current lack of detection with when the problem gets
introduced.
The fact that the problem is not detected on protocol adjacency formation does
not mean the problem gets introduced afterwards. Unless you are saying that
folks change the link MTU AFTER the link comes
Les,
On Mon, Oct 29, 2018 at 06:13:53PM +, Les Ginsberg (ginsberg) wrote:
> The fact that the problem is not detected on protocol adjacency formation
> does not mean the problem gets introduced afterwards. Unless you are
> saying that folks change the link MTU AFTER the link comes up and has b
Hi Jeff,
I have read the draft and support WG adoption.
Thanks,
Acee
On 10/29/18, 11:53 AM, "Rtg-bfd on behalf of 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 Session
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
Yes/support
Makes sense, in Redback times we had a design to build it that way (never did
though), not an IPR disclosure .
Cheers,
Jeff
On Oct 29, 2018, 2:32 PM -0700, Naiming Shen (naiming) ,
wrote:
>
> Support as a co-author.
>
> Regards,
> - Naiming
>
> > On Oct 29, 2018, at 8:52 AM, Jeffrey
The problem the draft addresses is valid and makes sense to address. But I know
there are implementations which have addressed this issue w/o requiring any
changes to their BFD implementation - so I am not sure how popular this
solution will be.
So long as this stays Informational I think it is
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
Naiming -
I did not say that implementations had done exactly what you propose in this
draft. I said:
" there are implementations which have addressed this issue w/o requiring any
changes to their BFD implementation"
There is more than one way to solve this problem. :-)
I raise this point bec
20 matches
Mail list logo
