Re: LCP echo request/reply support over multilink interface (RFC 1990)

} From: James Carlson <[email protected]>

} >  1) Mention LCP echo reply on the bundle as mandatory
} >                 Or
} >  2) Make LCP echo AVP(optional) is negotiated initially on the bundle.
} > 
} > Choice 2) would be better as there might be implementations out there,
} > that chose the bundle LCP reply as an optional.

} I don't believe that negotiation makes much sense here, given that there
} are already a large number of RFC 1990 implementations in the field, and
} few (if any) are going to change to accommodate this new mechanism.  And
} if any do, they'd likely just agree to it anyway; the Echo-Reply
} generation is far easier than the logic required to negotiate for it.

and less likely to have implementaion errors that cause real problems.

And what would you do if the peer refuses the negotiation?

Given the uselessness of bundle-Echo-Request, many new implementations
would not include code to start the negotation and would reject the
negotiation.


} If we're to write a new spec to cover this issue, I suggest that it
} should make LCP Echo-Reply generation on the bundle be mandatory (in
} order to align better with RFC 1661), and then go on to discuss why
} using LCP Echo-Request on the bundle is pointless, and that it isn't
} recommended.

That would have been a good idea 14 years ago.  Today, the large
number of RFC 1990 implementations that would never be revised to
an RFC 1990-bis imply that requiring bundle-Echo-Reply would do no
good.  Many implementations that don't generate Echo-Replies today
never will, not even when re-released by vendors.  So no implementation
could ever decide whether a failure to provoke a bundle-Echo-Reply
means something is wrong is with the link or that the peer
doesn't support bundle-Echo-Request/Reply.

Worse, some people working on new implemenations in the future would
read a deprecation of bundle-Echo-Request as sufficent justification
to ignore a "MUST" for bundle-Echo-Reply.  The result would be a moot
requirement.  Good (or perhaps more accurately, fussy) implementations
would have code for bundle-Echo-Reply that would never be used in the
real world.  Other implmentations be as they are now.

And you still could infer nothing from bundle-Echo-Reply failures.



> From: James Carlson <[email protected]>

> As Vern correctly pointed out, if you do LCP Echo-Request at the bundle
> level, you cannot reliably detect individual link failures, because the
> messages are no longer specific to any member link.  Thus, doing the
> echoes at that level actually only tests for implementation flaws in the
> MP code itself, rather than external failures.  

Over the decades, it's been shown that some people support such testing
of other people's implementation built into protocols.  "Bake-offs" and
other interoperability testing over the decades have also shown that
the very few failures detected by such tests are almost always only in
the implementations of supporters of such tests.  I think that proves
that such tests are useless wastes, but supporters never agree.


> LCP Echo-Request at the per-link level is different.  It reliably
> detects most "silent" failure modes, where the lower-level link status
> is still positive, but the link no longer carries any traffic, or is
> able to carry traffic in only one direction, or is perhaps just
> experiencing an abnormal error rate.  If you detect such a failure, you
> can fix it by dropping that one link out of the bundle.

Or, if you prefer, doing whatever you might have done if LCP Echo
over the whole bundle had failed, perhaps dropping and restoring
all of the links simultaneously.  Never mind that seems unproductive.



> > Yp> I know that, there can not be versions for RFCs :) 
> > In order to clarify the issue being discussed, we can update a new RFC
> > if any planned (needed to be planned) about/for MLPPP.

> I don't think one is really needed for this sort of issue, but you're
> certainly welcome to contribute if you wish.

It should be noted that submission of an I-D does not mandate consensus
for its eventual publication as a standards-track RFC.  The first RFCs
were individual submissions, but since the IETF got going 20+ years
ago, most individual submissions have failed to get sufficient support.
That's not a bad thing, just as it is for the best that most bills
submitted to the U.S. Congress never reach the President's desk.


Vernon Schryver    [email protected]
_______________________________________________
Pppext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pppext