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

[Y Prasad <[e-mail]>]

Thanks karl. Yes this would work if we are at the sending side.
Unfortunately we are at the receiving. We have got no other option
except implementing bundle keep alive reply though its optional.

Regards
yp

-----Original Message-----
From: Karl Fox [mailto:[e-mail]] 
Sent: Thursday, March 18, 2010 7:46 PM
To: Y Prasad
Cc: Vernon Schryver; [e-mail]; [e-mail];
[e-mail]
Subject: Re: [Pppext] LCP echo request/reply support over multilink
interface (RFC 1990)

A simple solution to your problem would be for the vendor sending LCP
Echo-Requests on the bundle to instead send them on the individual
links.  If any of your bundle member links reply, then your bundle is
OK, and there's no need to bring down the bundle, keeping your routes
from unnecessarily flapping.

It's compliant with the current RFC and it works.

Come on, now, this isn't that hard.

Karl

On Mar 15, 2010, at 12:51 PM, Y Prasad wrote:
> Folks,
> 
> IMO, having only Bundle LCP keep alives is still a good choice(in
cases
> where large number of members/bundles exists and link flap could lead
to
> larger bundle re-bring-up time).
> 
> I was just trying to mention a case where RFC1990 is giving a scope of
> incompatibility.
> In fact there are installations from a big vendor where bundles being
> disconnected due to no-reply to bundle LCP ECHO req. Solution to the
> peer is either mandatorily reply (though its optional from RFC point
of
> view) to bundle-keep-alives or ask sender side to disable this feature
> :( In fact bundle-keep-alive feature cannot implemented if the reply
is
> not made mandatory. 
> 
> Yaah!, I agree RFC1990 is very old. But we still see such of these
> issues.
> 
> Anyway if somebody out there trying to obsolete RFC1990, the mentioned
> items can be taken care. I can help here if needed. Not worth trying
> just this update though :)
> 
> Thanks for the discussions.
> 
> Regards
> yp
> 
> -----Original Message-----
> From: Vernon Schryver [mailto:[e-mail]] 
> Sent: Thursday, March 11, 2010 8:51 PM
> To: [e-mail]; Y Prasad
> Cc: [e-mail]; [e-mail]
> Subject: Re: [Pppext] LCP echo request/reply support over multilink
> interface (RFC 1990)
> 
> } From: James Carlson <[e-mail]>
> 
> } >  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 <[e-mail]>
> 
>> 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    [e-mail]
> _______________________________________________
> Pppext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pppext