Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt

[Robert Raszuk <[e-mail]>]

The document is written, accepted, last called and published as Standard
Track RFC.

Ref: RFC 7880.

> If you are operating a private infrastructure

I am building private secure infra over public IXes. Hint: SD-WAN MTU
stability over IX matters to me.

Best,
R.


On Fri, Apr 21, 2017 at 10:57 AM, Nick Hilliard <[e-mail]> wrote:

> Robert Raszuk wrote:
> > But my point is that we can come up with single solution to both
> > problems which would work in a hardware accelerated way equally well.
>
> Then I suggest you author documents to:
>
> - add a new icmp type to define reachability / mtu detection / etc
> mechanism
> - replicate whatever bits of BFD you want to port over
> - get widespread vendor support
>
> Once you've done all this, and not before, then please feel free to
> write an update to draft-ietf-idr-rs-bfd rfc to include your new
> reachability mechanism.
>
> Or you could update bfd to support mtu detection.
>
> > I
> > am also observing that MTU issue is applicable to long distance
> > stretched IXes which as I am sure you are aware is a real IX service
> > offering by number of IX operators today.
>
> IXP core MTU monitoring is orthogonal to draft-ietf-idr-rs-bfd.  IXP
> edge MTU monitoring is the responsibility of the ixp edge participant.
>
> If you are operating a private infrastructure in your company which
> amalgamates these roles and where you have a need to monitor for MTU
> changes, then this is a private problem which can be easily solved using
> any one of a plethora of off-the-shelf tools and there is no reason
> whatsoever for the ietf to standardise a new protocol to solve this
> corner case.
>
> I'm not going further down this rat-hole because it has nothing to with
> this draft.
>
> Nick
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>