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

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:[email protected]] 
Sent: Thursday, March 11, 2010 8:51 PM
To: [email protected]; Y Prasad
Cc: [email protected]; [email protected]
Subject: Re: [Pppext] 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