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

From: Y Prasad <[email-masked]>
Date: Tue, 2 Mar 2010 14:42:13 +0530

Thanks for the response, James.

I think there is a room for compliance issue with regard to LCP keelp
alives on the bundle.

RFC1990 page 5:
-------------
   LCP negotiations are not permitted on the bundle itself.  An
   implementation MUST NOT transmit LCP Configure-Request, -Reject,
   -Ack, -Nak, Terminate-Request or -Ack packets via the multilink
   procedure, and an implementation receiving them MUST silently discard
   them.  (By "silently discard" we mean to not generate any PPP packets
   in response; an implementation is free to generate a log entry
   registering the reception of the unexpected packet).  By contrast,
   other LCP packets having control functions not associated with
   changing the defaults for the bundle itself are permitted.  An
   implementation MAY transmit LCP Code-Reject, Protocol-Reject, Echo-
   Request, Echo-Reply and Discard-Request Packets.
--------------

It says LCP echo-req/reply on the bundle is optional. Assume that an
implementation sends LCP ECHO req. on the bundle and the remote chooses
not to reply (as it is optional) then sender would likely to drop the
bundle. Perhaps mentioning one of the following clauses help.

 1. Let the peer negotiate "LCP-echo req on the bundle" during LCP req
and subsequently send LCP echo req on the bundle only if it is accepted
by the remote peer.

OR

 2. Sending LCP ECHO-req on the bundle is option. But LCP ECHO-reply on
the bundle need to be mandatory.

First choice above would be more appropriate as there might be already
installations that would not send lcp-echoreply-on-the-bundle.

Regards
yp

-----Original Message-----
From: James Carlson [mailto:[email-masked]] 
Sent: Tuesday, February 23, 2010 8:05 PM
To: Y Prasad
Cc: [email-masked]
Subject: Re: [Pppext] LCP echo request/reply support over multilink
interface (RFC 1990)

Y Prasad wrote:
> "Bundle interface is a virtual interface. If there has to be LCP keep
> alive on it, it has to go through one of the underlying physical
links.
> But LCP keep alive packet format does not seem to specify any
interface
> details. How does the remote identify that the LCP echo received on a
> physical link belongs to bundle?

If you run those non-negotiation LCP messages on the bundle, they may
need to be encapsulated using RFC 1990 fragment headers if you want to
segregate bundle and link level traffic.  You're not required to do
that, though.

In general, this is more of an implementation issue than anything else.
 For example, you need to inspect LCP Protocol-Reject messages to
deliver them properly.  If the rejected protocol is one of the few
per-link protocols, then it should be handled at the link level.  If
not, then it should be communicated upwards to the bundle head for
processing.

Some implementations will deliver LCP errors at the link level that are
targeting problems detected at the bundle level.  You must be prepared
to handle that.

In the case of LCP Echo Request, if you implement that only at the
bundle level, then you can send requests without encapsulation and
simply have all of the received LCP Echo Reply messages forwarded up to
the bundle head.  If you implement only at the link level, then process
them there, again without encapsulation.  In short, since you know how
you send your requests, you can decide how you want to process the
replies.  (And since implementing at both levels at the same time would
likely not serve much of a purpose, it would probably be wise to choose
one and stick with it.  I'd recommend link-level, as it's links that
usually run into trouble, but it's your code ...)

Note that packets sent at the bundle level are _not_ required to have MP
fragment headers.  Using those headers guarantees ordering and
reassembly where needed, but it's not a requirement -- either for
signaling messages or for user data.

The only special action needed to ensure interoperability is that when
an implementation receives a bare LCP Echo-Request, it must reply on the
same link.

-- 
James Carlson         42.703N 71.076W         <[email-masked]>

---

From: Y Prasad <[email-masked]>
Date: Wed, 3 Mar 2010 10:19:43 +0530

There was email-error issue. Hence resending in case this had not been
received. Sorry if this is a duplicate.

RFC1990 page 5:
-------------

OR

IMO, first choice above, would be more appropriate as there might be
already installations that would not send lcp-echoreply-on-the-bundle.

Regards
yp

-----Original Message-----
From: James Carlson [mailto:[email-masked]] 
Sent: Tuesday, February 23, 2010 8:05 PM
To: Y Prasad
Cc: [email-masked]
Subject: Re: [Pppext] LCP echo request/reply support over multilink
interface (RFC 1990)

links.
interface

---

From: Ignacio Goyret <[email-masked]>
Date: Tue, 09 Mar 2010 11:29:21 -0800

At 10:19 AM 3/3/2010 +0530, Y Prasad wrote:

>bundle.

If it does that, then the sender of the Echo-Request is not
compliant.

> Perhaps mentioning one of the following clauses help.
>

The LCP Echo function is not negotiated. It is mandatory at the link level
and optional at the bundle level.

>the bundle need to be mandatory.

No, the remote peer is not required to respond to the Echo-Request
on the bundle (meaning, with MP headers).

If you make any assumption based on not receiving a response in
this case (other than the remote didn't answer), you are writing
code that it is not interoperable.

-Ignacio

---

From: James Carlson <[email-masked]>
Date: Tue, 09 Mar 2010 15:32:53 -0500

> code that it is not interoperable.

I tend to agree with the sentiment, especially so as I think LCP
Echo-Request on the bundle is a mostly silly idea, but the documents
don't seem to say the same thing.

RFC 1990 says only that you MAY send LCP Echo-Request (et al.) on the
bundle.  It doesn't say anything at all about whether response is
required or optional or what.  RFC 1661, however, says that response to
LCP Echo-Request is mandatory.

Obviously, RFC 1661 applies at the per-link level, but what about LCP
messages at the bundle level?  When using RFC 1661's message atop an RFC
1990 bundle, is the response required or not?  You're saying "no," but
I'm not sure all implementors would agree.

In contrast, if you see LCP Protocol-Reject on the bundle, you'd darn
well better handle it properly.  The NCPs all run at the bundle level,
and it's natural to expect any protocol rejects at that level as well.
(Though it's certainly true that I've seen implementations that insist
on sending Protocol-Reject down at the per-link level at all times, so
you also have to be prepared to handle these by treating them as
applying to the NCPs running atop the bundle _iff_ they don't apply to
any per-link protocol.  These packets are treated as though they were
unencapsulated NCP messages.)

I'm arguing that we're in a grey area.  The best bet, I think, is to
avoid sending LCP Echo-Request on the bundle (unless explicitly
configured to do so), and always reply on the bundle if you receive a
request there.

There's always a bit of a fuzzy line between what's specified in the
documents and what's really required to operate well in the field.

---

From: Ignacio Goyret <[email-masked]>
Date: Tue, 09 Mar 2010 13:34:27 -0800

>I'm not sure all implementors would agree.

Precisely.

My point is that you can't make an assumption based on whether
the remote replied or not your Echo-Request at the bundle level.

If it did, great.

But if it didn't, it doesn't mean anything beyond that the remote
didn't send an Echo-Reply, a choice that is perfectly legal given
the ambiguities in RFC1990.

Some implementors may choose to respond to an Echo-Request at
the bundle level, others may choose to not respond -- and both
implementations would interoperate successfully so long as
there are no assumptions about required responses.

It is a basic application of the "be liberal in what you accept"
principle.

Cheers,
-Ignacio

---

From: James Carlson <[email-masked]>
Date: Tue, 09 Mar 2010 16:52:52 -0500

> the remote replied or not your Echo-Request at the bundle level.

As a default "assumption," no.  But if the administrator configures the
link to fail on a lack of replies, then I see no problem at all with
failing it out when faced with such a peer.  The administrator will have
to configure the feature back off in order to interoperate with such a
system, but as long as the default is "don't bother with bundle-level
LCP echo," there's no problem.

---

From: Y Prasad <[email-masked]>
Date: Thu, 11 Mar 2010 09:48:21 +0530

Having LCP keep-alives on the bundle is not a bad idea in cases where
member links/lines are very stable and dedicated. By enabling LCP
keep-alives only on the bundle, it would reduce the control traffic.
Definitely enabling on both bundle and links does not make sense.

Contention here is, peer that is transmitting LCP echo req on the bundle
can not know if the peer is dead or does not support LCP-echo reply on
the bundle. As I conveyed initially, cleaner way would be to update RFC
with one of the following.
 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.

Regards
yp

-----Original Message-----
From: James Carlson [mailto:[email-masked]] 
Sent: Wednesday, March 10, 2010 3:23 AM
To: Ignacio Goyret
Cc: Y Prasad; [email-masked]
Subject: Re: [Pppext] LCP echo request/reply support over multilink
interface (RFC 1990)

---

From: Vernon Schryver <[email-masked]>
Date: Thu, 11 Mar 2010 05:56:17 GMT

> From: Y Prasad <[email-masked]>
> To: James Carlson <[email-masked]>,
>         Ignacio Goyret
> 	<[email-masked]>
> Cc: [email-masked]

> keep-alives only on the bundle, it would reduce the control traffic.

The reduction in control traffic had better be insignificant,
or you are spending far too many bits on LCP echos.

The reduced control traffic would fail to detect dead members of
the bundle.  Depending on how packets are spread over the links in
the bundle, you could have a bundle of one live link, one dead, and
everything working fine except for an approximate 50% packet loss rate.

Without LCP on individual links, how do you decide which link in
a bundle should be re-established?

If there are persistent problems on one link in a bundle (e.g. a sick
modem/line card/whatever), how do you figure out which if you have
only LCP on the bundle and not on each link?

> Definitely enabling on both bundle and links does not make sense.

I don't think much of LCP echo on the bundle.

> that chose the bundle LCP reply as an optional.

There is no such thing as "update [the] RFC." The closest related notion
would be publishing one or more new RFCs.  The at best minor (and I
think undesirable) change does not justify opening that can of worms.

Vernon Schryver    [email-masked]

---

From: Y Prasad <[email-masked]>
Date: Thu, 11 Mar 2010 12:28:37 +0530

Hi Vernon,

Please see uin-line at yp>

Yp> I presume you meant LCP echo above. LINK down can be identified by
many other ways depending on what type of link it is. Eg. carrier detect
signal becoming up/down can be used for link status.  As per draft
LCP-req is optional and LCP-echo-reply is mandatory (MUST). Many vendors
do support no-keepalive  option even on plane PPP interfaces.

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.

Regards
yp

---

From: James Carlson <[email-masked]>
Date: Thu, 11 Mar 2010 07:34:30 -0500

> Please see uin-line at yp>

If possible, please do use standard quoting practice rather than rolling
your own, so that attributions remain true.

> signal becoming up/down can be used for link status.

That's true, but irrelevant.

If you can completely trust link up/down indications, then this entire
discussion is moot.  You don't need LCP Echo-Request at all.  You can
just avoid sending it, and drive on, trusting the RFC 1661 Down event
from the lower layer to tell you all you need to know.

In order to have a discussion about LCP Echo-Request at all, we have to
start from the point of assuming that there are failure modes in the
links that cannot be detected in the usual way.  The link can be damaged
in some way that makes it useless for traffic, but doesn't cause "Down."
 The next questions are what failures, how detected, and what remedies
are available?

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.  And there's not much you
can do about that except do your design and testing very carefully.

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.

Furthermore, I reject the idea that it's any sort of performance issue.
 If you do send LCP Echo-Request, you're not required to send it at any
particular rate.  Send it as quickly or as slowly as you like.  If you
feel that dividing the rate at which you send it by the number of links
in the bundle is a good strategy (as would occur if echoes were done at
the bundle level), then do it.  Since you're also the one independently
determining when a lack of Echo-Reply messages indicates a problem, you
can choose whether and when to send Echo-Request.

For those reasons, I remain unconvinced that LCP Echo-Request at the
bundle level is more than a curiosity.

>  As per draft

Sure.

> 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.

---

From: James Carlson <[email-masked]>
Date: Thu, 11 Mar 2010 07:45:34 -0500

> that chose the bundle LCP reply as an optional.

Sorry; I read from the end of the thread upwards.  I probably should
have started here.

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.

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.

Since writing a new document is an important opportunity, it should also
cover other neglected areas, such as proper handling of inbound LCP
Protocol-Reject messages.

---

From: Vernon Schryver <[email-masked]>
Date: Thu, 11 Mar 2010 15:20:51 GMT

} From: James Carlson <[email-masked]>

} >  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-masked]>

> 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.

> 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.

> 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.

---

From: Y Prasad <[email-masked]>
Date: Mon, 15 Mar 2010 22:21:55 +0530

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-masked]] 
Sent: Thursday, March 11, 2010 8:51 PM
To: [email-masked]; Y Prasad
Cc: [email-masked]; [email-masked]
Subject: Re: [Pppext] LCP echo request/reply support over multilink
interface (RFC 1990)

} >  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.

---

From: James Carlson <[email-masked]>
Date: Mon, 15 Mar 2010 13:35:12 -0400

> larger bundle re-bring-up time).

I'm unable to parse that statement.  Could you provide specifics on how
running LCP Echo-Request at the bundle level provides some sort of
performance improvement?  Or at least what link flaps have to do with
the problem?  I cannot see how that's so.

As far as I can tell, link flap just takes one link out of the bundle,
and bringing it back into the bundle is dependent on negotiating LCP
(and Authentication, if required).  Neither of those has anything to do
with LCP Echo-Request.

> I was just trying to mention a case where RFC1990 is giving a scope of

True; this is an area where the specification is indeed weak.

At least in my experience having worked on a couple of different
implementations, the issue just didn't matter.  It's the member links we
all care about testing, not the bundle itself, because having a single
bad member link in the bundle is toxic to the bundle, due to the way the
reassembly algorithm works.  LCP Echo-Request/-Reply at the per-link
level provides a clean way to test each link to make sure it's still
working properly.  Doing it at the bundle level doesn't do that.

Multilink (with the segmentation feature enabled) tends to run at the
speed of the slowest link, as everything blocks for that one link to
produce updated sequence numbers.

> :( In fact bundle-keep-alive feature cannot implemented if the reply is

If the peer refuses to reply, then no mere document is going to help
you.  You have to stop depending on the feature if you want to
interoperate with those peers.

Even if it were made mandatory, that'd still just be in the new
document, and there are many devices out there that are designed to RFC
1990, and might never be changed.

> just this update though :)

If you want to take it on, I suspect that you'll likely need to provide
a clear rationale -- complete with worked-out examples that show the
benefits -- in order to convince enough contributors here to achieve
consensus.

It's certainly possible to do that, but it'll take some work.

---

From: Y Prasad <[email-masked]>
Date: Thu, 18 Mar 2010 18:26:09 +0530

Yp> LCP keep-alives help to identify faulty link and peer state
(alive/dead).
If an user depends on link Career detect (or some other means) to
identify faulty link, he may opt for no-keepalives on that link. And in
order to identify whether peer alive or not just a bundle keep alives
are good enough. This would reduce control traffic and flooding of LCP
keep-alives on multiple link flaps/bundle flaps when links rejoin into
bundle after LCP.

Yp> I agree, I meant LCP keepalive traffic after links join.

Yp> I agree in case member links are "bad" (meaning can not reflect
faulty link properly).
 "good link" here means it does reflect its faultiness without the need
of LCP keepalives.

If the peer refuses to reply, then no mere document is going to help
Yp> Peer thinks optional (not refusal) and the local might think peer is
dead.

you.  You have to stop depending on the feature if you want to
interoperate with those peers.
Yp> Yes with the current form in the draft bundle keep alives can not
work with peer who thinks the same is optional.

Yp> I agree. Only way is bundle-keepalive need to made as optional and
negotiable attribute. Then it would work with existing installations.
down-ward-compatible :).

Yp> I think we can club this rectification along with any other if any.
Just for this writing an another draft may not be worth trying :)

Regards,
yp

---

From: James Carlson <[email-masked]>
Date: Thu, 18 Mar 2010 09:51:10 -0400

> keep-alives on multiple link flaps/bundle flaps when links rejoin into

If the user can actually rely on the underlying medium-dependent health
checks, then I don't see what LCP Echo-Request would do at the bundle level.

If the peer is working, then those links should all be healthy, right?
And if the peer fails for some reason, then the links would (since
they're assumed to be reliable) indicate the lack of health, wouldn't they?

In order for LCP Echo-Request at the bundle level to be interesting, we
need to be in a world where the peer can fail completely but leave all
of the links "up," and where the only way any individual link alone
could fail would be something that is detected by the lower layer.

I suppose that's plausible, though I've never seen such a thing in
practice.  All of the systems I've seen have possible failure modes
where links remain "up" at the lower layer, but are not actually usable
for PPP for one reason or another.

As for the claimed control traffic reduction, I still don't get it.  If
a bunch of links go down, you're going to have to renegotiate LCP when
the links come back.  That's a given; it's part of the protocol.  LCP
Echo-Request (whether implemented or not) is no part of that process.
It has nothing to do with it.  In a typical implementation, you don't
bother with LCP Echo-Request at all until some time well after the link
has been established and has been passing data.

Thus, using LCP Echo-Request doesn't slow down the work in
reestablishing the bundle, nor does it impose any greater workload on
that case.

Even if there were such a traffic reduction (I don't believe it to be a
correct analysis), the two solutions can be made equivalent in terms of
overhead in a trivial way.  If you're going to send LCP Echo-Request
messages on the bundle at interval "M" seconds, and that interval is an
acceptable amount of traffic to you, then you can equivalently send LCP
Echo-Request messages at the per-link level at interval "M*N" seconds
(where N is the number of links in the bundle).

The overall message rate is the same.  No savings.  The only difference
is the kinds of errors you can detect.

>  "good link" here means it does reflect its faultiness without the need

How do you know for certain that each of the member links can always
indicate whether they're capable of carrying PPP traffic without
significant error or delay?

And if they're able to do that, then why can't they also tell you
whether the peer is working at all?  That's the only remaining case --
that the peer is completely dead -- that bundle-level LCP Echo-Request
can detect for you.

> negotiable attribute. Then it would work with existing installations.

So you'd be OK with not using LCP Echo-Request on existing platforms, right?

I guess I can agree that if you had a negotiation, you would know
whether you could default LCP Echo-Request operation to "on" or "off"
based on the outcome of the negotiation, without needing operator
intervention.

I'm not sure I see the lasting value in this, given the circumstances,
but ok.

For what it's worth, there's a poor-man's approach to this problem.
When you contact a new peer, you can assume that LCP is still in a
pretty good state one millisecond after it goes to Opened state.  When
you establish your first bundle with a novel peer, send a few LCP
Echo-Request messages over the bundle at some nominal interval (say,
three messages at three seconds apart).  If you receive any replies,
then you can assume that the peer does implement the feature, and you
can then continue to use it, and perhaps record that fact for that peer
in stable storage.  If you receive no replies, then you can assume that
it doesn't implement the feature, so you'll need to disable it.

The messages themselves can be all the negotiation you need.  And, best
of all, this approach works with existing equipment, and needs no new
document.

> Just for this writing an another draft may not be worth trying :)

OK.  It's up to you ... or any others who might be interested enough to
work out such a document.

---

From: Y Prasad <[email-masked]>
Date: Sun, 21 Mar 2010 21:33:27 +0530

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:[email-masked]] 
Sent: Thursday, March 18, 2010 7:46 PM
To: Y Prasad
Cc: Vernon Schryver; [email-masked]; [email-masked];
[email-masked]
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:
> _______________________________________________
> Pppext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pppext

---

From: James Carlson <[email-masked]>
Date: Sun, 21 Mar 2010 15:24:28 -0400

> except implementing bundle keep alive reply though its optional.

I'm confused.

I believe the entire discussion we've had so far was with the assumption
that you wanted to send these messages, and you weren't sure whether the
peer would respond properly or how to find out whether the peer was willing.

If you're the recipient of these LCP Echo-Request messages rather than
the sender, though, then things change quite dramatically.  You're in no
position whatsoever to make any demands on your peer; he'll do what he
wants.

I believe your choices are:

  - Be kind, and respond to his messages, regardless of what you
    or anyone else may think of them.

  - Refuse to respond, and suffer the consequences, which may
    include a lack of interoperability with that specific peer.

  - Ask the person who operates that peer system whether it can
    be configured, upgraded, or otherwise modified such that it
    doesn't rely on this useless feature.  (If not, then opt for
    one of the other two above.)

None of those choices involve protocol-level or documentation changes.

---

From: Y Prasad <[email-masked]>
Date: Mon, 22 Mar 2010 16:54:21 +0530

James,

I understand all the options we have :)
Just wanted make effort to convey the reason for this interoperability
and prevent such of these at the next draft if possible.

Regards
yp

-----Original Message-----
From: James Carlson [mailto:[email-masked]] 
Sent: Monday, March 22, 2010 12:54 AM
To: Y Prasad
Cc: Karl Fox; Vernon Schryver; [email-masked];

I'm confused.

I believe the entire discussion we've had so far was with the assumption
that you wanted to send these messages, and you weren't sure whether the
peer would respond properly or how to find out whether the peer was
willing.

---

From: James Carlson <[email-masked]>
Date: Mon, 22 Mar 2010 07:43:45 -0400

> and prevent such of these at the next draft if possible.

I think the prospects for "prevention" are dim at best.  The peers that
want to send these messages without asking first can already do so, and
will continue to do so regardless of what sort of position we take in
this working group.  RFC 1990 is out the door; we can't reasonably
recall it.  There's no way to "force" the negotiation you're hoping for
to occur, because publishing a new RFC doesn't force anyone to conform.

Rather, it works the other way around: if you have a bunch of people who
want to conform to a single specification (and have the money and skill
to spend on development), then having a published RFC is a good way of
making sure that they're all driving in the same direction.  The
document is a guide, not a reliable demand for posterity.

Although we may disagree on the right new language to use in the
document (I would argue for "must reply" and "should not request"), I
think we do agree that there's a lack of specificity here, and it's one
that may lead to interoperability problems.  It is something that ought
to be fixed, regardless of whether it will actually help your situation
(it won't) or whether it's an important issue in context (I don't think
it is).