Re: [Pppext] Pppext Digest, Vol 44, Issue 6

[<[e-mail]>]

Please stop e.mailing me!

> From: [e-mail]
> Subject: Pppext Digest, Vol 44, Issue 6
> To: [e-mail]
> Date: Thu, 11 Mar 2010 12:00:10 -0800
> 
> If you have received this digest without all the individual message
> attachments you will need to update your digest options in your list
> subscription.  To do so, go to 
> 
> https://www.ietf.org/mailman/listinfo/pppext
> 
> Click the 'Unsubscribe or edit options' button, log in, and set "Get
> MIME or Plain Text Digests?" to MIME.  You can set this option
> globally for all the list digests you receive at this point.
> 
> 
> 
> Send Pppext mailing list submissions to
> 	[e-mail]
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://www.ietf.org/mailman/listinfo/pppext
> or, via email, send a message with subject or body 'help' to
> 	[e-mail]
> 
> You can reach the person managing the list at
> 	[e-mail]
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Pppext digest..."
> 
> 
> Today's Topics:
> 
>    1. Re: LCP echo request/reply support over multilink	interface
>       (RFC 1990) (Vernon Schryver)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Thu, 11 Mar 2010 15:20:51 GMT
> From: Vernon Schryver <[e-mail]>
> Subject: Re: [Pppext] LCP echo request/reply support over multilink
> 	interface (RFC 1990)
> To: [e-mail], [e-mail]
> Cc: [e-mail], [e-mail]
> Message-ID: <[e-mail]>
> 
> } 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
> 
> 
> End of Pppext Digest, Vol 44, Issue 6
> *************************************
 		 	   		  
_________________________________________________________________
Hotmail: Trusted email with powerful SPAM protection.
http://clk.atdmt.com/GBL/go/201469227/direct/01/