Subject: Re: I-D ACTION:draft-sadler-pppext-disc-01.txt

From: Jonathan Sadler <[email-masked]>
Date: Wed, 05 Jun 2002 11:41:58 -0500

James -

James Carlson wrote:
> 
> Jonathan Sadler writes:
> > Misconnection detection identifies the fact that an RX/TX pair has not
> > been correctly terminated on a corresponding RX/TX pair on the remote
> > end.
> 
> Understood.
> 
> > This is not the same as misconfiguration of a PPP option.
> 
> It *is*, however, exactly identical to the misconfiguration that PPP
> option negotiation is designed to detect.  Negotiation will fail to
> converge if the peers do not have a bidirectional data path.

While PPP will have the same failure behavior for misconfiguration as
well as misconnection, the mechanism that is necessary to recover (ie
identify what the fault location is) is completely different.  We are
not looking to handle misconfiguration detection -- that is something
that can already be handled through policy/security mechanisms.  We are
specifically looking to identify the following misconnection cases:
   - Transmit/Receive reversal
   - Transmit/Receive half-connection
   - Transmit/Receive split 1 port -> 2 ports (1 NE -> 1 NE)
   - Transmit/Receive split 2 ports -> 2 ports (1 NE -> 1 NE)
   - Transmit/Receive split 1 NE -> 2 NEs

> > > What the document seems to be saying above is also true of
> > > any NCP that runs over PPP: one doesn't want to have a simple
> > > misconfiguration result in a bad link being established.
> >
> > Your statement has the following two corollaries:
> >   - LCP is the only place that Misconnection detection can
> >     be accomplished as LCP cannot successfully negotiate if
> >     there is a Misconnection.  If LCP cannot successfully
> >     negotiate then no NCP will be started, thereby making
> >     it impossible for an NCP to identify a misconnection.
> 
> This is false.  Detection of misconnections is done at each level in
> PPP -- LCP is merely one component, and by no means the only one.

The above listed misconnections cannot be identified by any protocol
other than LCP as LCP will never succesfully negotiate when one of these
misconnections exists.

Instead when one of the above listed misconnections occurs on a link,
the technician will see that LCP won't come up.  The technician will not
have any assistance in identifying why -- they'll at most see the
CONF-REQs coming from one or both ends in logs.  But they will not know
if its the wiring that is buggered up or if its a lower layer driver
problem or bad hardware.

This draft provides a mechanism that helps to isolate the source of the
problem.  While this may seem trivial for installations with a handful
of terminations, it is a problem for installations that have thousands
of terminations.

> In particular, suppose I have a regular PPP link between hosts A and
> B.  I manage to fat-finger the punch list for the SONET interconnect,
> and I end up instead with a connection between A and C.  LCP still
> comes up, since I happen to have PPP implemented on C as well, but
> then one of the two things then happens:
> 
>         - authentication fails because A has credentials for B
>           associated with this port.
> 
>         - when IPCP attempts to negotiate, A gets the wrong IP-Address
>           in the Configure-Request, sends Configure-Nak, then goes
>           into a request/nak loop until the link falls down.
> 
> In neither case does the link come up.  That's the point of PPP
> negotiation: preventing misconfigured links from being established.
> It's not merely an LCP function.

However, the current negotiation only focusses on attributes of the
particular sub-protocol being negotiated.  They do not provide any
tracing capability for the layer that exists below PPP.  This is what
this mechanism provides.

> >   - The fact that LCP will not negotiate to the OPEN state on a
> >     link because of a Misconnection (not misconfiguration) is good.
> >
> > I agree with both of these ideas.  We are not looking to change the
> > behavior of LCP with respect to negotiating into the OPEN state.
> 
> This proposal is (in some ways) very reminiscent of the old LCP-based
> authentication proposal.  You're doing endpoint identification.

While the mechanism looks similar, the purpose is very different. 
Authentication mechanisms typically assume bi-directional
communications, and therefore can easily be put into a separate
sub-protocol.  Misconnection detection as defined above can only occur
within LCP.  It cannot be turned into a sub-protocol.

> There are lots of ways to do this.  You can hijack the existing LCP
> Endpoint Discriminator option from RFC 1990.  You can encode this
> information in the authentication data passed via PAP/CHAP/EAP.  I
> don't see that you need a new LCP option to do it.

We actually considered using the Endpoint Discriminator option since it
has the same general format as the identifier we are looking to send but
decided against it because it is used to specifically identify an MLP
bundle that a link belongs to -- a completely different purpose than
misconnection detection and transport neighbor discovery.

> That's setting aside, of course, whether PPP belongs here at all.

Specifying a separate protocol leads to new development, new standards,
and new interoperability testing.  Further, some vendors may decide to
delay implementation due to the amount of additional work necessary. 
Adding an option to LCP the amount of work is considerably less (and
none if its use is out of scope for a vendor).

> > Consequently, knowing the ID of the port that a span has connected to
> > will provide significant help in figuring out where the misconnection
> > is.
> 
> True.  You already have to modify the PPP code to support *something*
> to identify links.  If you put the modification into the existing
> mechanisms, then nobody else needs to know about this usage.

However, putting it in a PPP sub-protocol other than LCP won't work as
LCP has to complete negotitation before any other protocol can start up.

> > > That doesn't
> > > mean that all NCPs should be negotiated in LCP.
> >
> > Agreed.  However, we are not looking to create an NCP.  This is
> > specifically to identify a property of a link (specifically, the
> > identity of the neighboring equipment) that is independent of the
> > Network Layer protocols used above it.  The Address being passed is just
> > a "cookie" -- it has no meaning with respect to the USE of the bearer.
> 
> Actually, I suspect that it may well be used there.  A protocol like
> this that can identify endpoints for validation purposes can *also* be
> used for discovering the peer's identity in a dynamic situation.  In
> other words, it's exactly analogous to IPCP's negotiation: it can be
> used just to validate that the right peers are talking (the original
> intent, based on experience with SLIP) or it can be used to distribute
> information.

The information is specifically providing an identifier for a link
endpoint independent of the Network Layer Protocols supported by the
link.  The identifier needs to have network scope so that the endpoint
can be uniquely identified by the operator/technician.

Currently, NCPs don't obtain Network Layer Addressing from LCP, and they
will not need to after introduction of this LCP option.

> > > If I understand this draft correctly, it proposes having LCP
> > > negotiate, go to Opened state, and then somehow, at some point,
> > > release the port so that some other non-PPP service ('TDM') can use
> > > the port.
> >
> > For ports that don't support an NCP, this is correct.  The "somehow, at
> > some point" is immediately after sucessful LCP negotiation.  The release
> > is accomplished using the existing "Send-Termination-Request" message so
> > it is not redefining the operation of the LCP state machine.
> 
> This behavior isn't actually documented in the draft.  In addition,
> per RFC 1661, action 'str' is done only when someone invokes Close on
> LCP or on abject failure.  This eventually results in 'tlf' being
> sent, and the physical layer being torn down (for whatever "torn down"
> might mean in this context).

Exactly -- a Close event would be generated by the neighbor discovery
manager.  I'll look to improve the text describing this.

> Thus, I think this does imply some changes, since the link remains
> usable even though LCP is destroyed.

It may imply changes in specific implementations -- but it is completely
consistent with the existing LCP state machine.

> > If a port does support an NCP, then the port would continue to negotiate
> > MLPPP, Authentication, and the NCP just like PPP does today.
> 
> So, then, how does this differ from the existing authentication
> protocols?

It differs in that it is not providing a mechanism for authenticating a
service user, but is instead providing a trace mechanism for a
misconnected bearer.

> > > interacts with the existing suite of PPP features (e.g.,
> > > Authentication, CHAP rechallenge, LQM, MP, CCP, ECP, and basic LCP
> > > Echo-Request/Response).
> >
> > There is no interaction with any of the other PPP protocols -- it is
> > specifically for identifying a link property.
> 
> You gave part of the answer above -- you expect a switch into TDM mode
> if there are no NCPs expected.  Exactly how the peers know that this
> is the case (how do you know when something is not coming?), and when
> the switch takes effect (after LCP goes down?) should be part of the
> draft.

Thanks for the recommendation -- I'll work on text to incorporate your
comments.

> > > An alternative -- one that would require no changes to PPP at all --
> > > would be an agreement by the peers to use PAP or EAP to exchange
> > > identities, and to place the link identity in the "peer name" field.
> > > Since this proposal is an identification mechanism, it seems logical
> > > to use the existing identification mechanisms to support it.
> >
> > None of these mechanisms happen early enough to allow them to be used
> > for misconnection detection.
> 
> I don't understand that.  How is LCP acceptable but authentication
> unacceptable?  If LCP fails, the link fails.  If authentication fails,
> the link fails.
> 
> What exactly is the difference there?

LCP must succeed for authentication to proceed.  Simple as that.  If you
are looking to solve a wiring problem that causes LCP to fail, you can't
expect authentication to assist.  Therefore either LCP or the bearer
need to provide the trace information needed to solve the problem.

> > > However, this proposal also appears to be using PPP as though it were
> > > a one-shot exchange, which is not the case.  This is troubling in
> > > terms of the feature support outlined above.
> >
> > The one-shot use is similar to what happens today if a PPP line is
> > started and there is a mismatch that prevents proper negotiation of a
> > protocol above LCP.  (eg. authentication mismatch, NCP configuration
> > mismatch, supported NCP mismatch, etc.)
> 
> But, then, the link is left down.  This case uses PPP as though it
> were a way to say "hello" to the peer, and then disconnect, secure in
> the knowledge that the peer is somehow still there.

Correct.  The expectation is that as long as the underlying bearer is
still operationally in service (eg. carrier is asserted, etc.) the
identity of the neighbor is not going to change.  And the draft states
in sec. 4.5 that if a link goes operationally out of service when it
returns to service neighbor discovery will be done again.

> > > It seems to me that a
> > > new protocol -- say, "one time identity exchange protocol" -- would be
> > > preferable to redefinition of all of the PPP subprotocols to fit in
> > > this context.
> >
> > There are many benefits in using PPP as opposed to defining a new
> > protocol, most noteably:
> >  - It leverages the existing PPP code-base
> 
> It proposes a code change that everyone has to support.

Only those vendors that want to provide a maintenance aid for optical
misconnections need to implement it.  Again, this has the most impact in
an environment with thousands of connections in a location.

> >  - It doesn't have to go through the pains of interoperability testing
> 
> The switch-over to TDM mode sounds significant to me.  You need to be
> able to switch to it and back (somehow) without getting PPP confused.
> LCP messages are used for this on normal PPP links.  I don't see what
> keeps PPP in synchronization here.

Once neighbor discovery/misconnection detection is complete, the LCP
session is closed, allowing a new LCP session to be initiated by the
remote endpoint.  Since the lower layer never went out of service, this
new session will not be terminated by the transport equipment.  If any
sort of cross connect is already in place any new LCP session attempted
by the end equipment will be continued to the remote endpoint of the
link.

> >  - It removes the issue of having to distingush between PPP and the
> >    "other" protocol.
> 
> Do you have to distinguish between PPP and Cisco HDLC?  Or between PPP
> and ATM?
>
> I don't think that goes away.

Good point.  Any recommendations on how to solve this?  I'll start
working on an approach...

--8<--SNIP-->8--

> Instead, I think that whatever is used for OAM functionality on that
> TDM interface ought to be used for identification.  That allows the
> port to stay in TDM mode all the time, be managed, and work without
> having to invoke PPP at all.

Unfortunately, the trace signals that exist on TDM interfaces are not
ubiquitous and don't use a common format leading to a variety of issues.
Consequently, in-band signals will be necessary.  This draft attempts to
define a common format using a ubiquitous protocol.

Jonathan Sadler

> --
> James Carlson, Solaris Networking         <[email-masked]>
> SUN Microsystems / 1 Network Drive         71.234W   Vox +1 781 442 2084
> MS UBUR02-212 / Burlington MA 01803-2757   42.497N   Fax +1 781 442 1677
============================================================
The information contained in this message may be privileged 
and confidential and protected from disclosure.  If the 
reader of this message is not the intended recipient, or an 
employee or agent responsible for delivering this message to 
the intended recipient, you are hereby notified that any 
reproduction, dissemination or distribution of this 
communication is strictly prohibited. If you have received 
this communication in error, please notify us immediately by 
replying to the message and deleting it from your computer.

Thank you.
Tellabs
============================================================

---

From: James Carlson <[email-masked]>
Date: Wed, 5 Jun 2002 14:41:36 -0400

Jonathan Sadler writes:
> identify what the fault location is) is completely different.

True, but I think that's really a management application issue, not
something that ought to be coded directly into the wire protocol.

In other words, there are *lots* of ways that things can fail -- not
just the wiring hazards that you've mentioned -- and many of them are
not necessarily present or detectable when the link starts.  By
depending on LCP negotiation at link start, and doing the check only
once over the life of the link, I think you're opening holes in the
administrative model.

> other than LCP as LCP will never succesfully negotiate when one of these

True, but so what?

As I mentioned before, if you need to see some sort of unauthenticated
identity information in LCP, you don't need to change anything.  Use
the existing LCP Endpoint-Discriminator option.  Or use RFC 1570 LCP
Identification.

> if its the wiring that is buggered up or if its a lower layer driver

That, I think, is where you need good diagnostic software, not changes
to the standard protocols.

> of terminations, it is a problem for installations that have thousands

Understood.  Doing OAM well is hard.

> tracing capability for the layer that exists below PPP.  This is what

Fine.  You can also do this using RFC 1570 Identification messages.

If the peer can hear you at all, then putting information into an LCP
option works as well as issuing an Identification message on failure.
If the peer can't hear you at all due to a wiring error, then putting
information into an LCP option doesn't help any more than issuing an
Identification message because neither makes it to the destination.

The two should be equivalent, except that using Identification doesn't
require an extra standard.

> misconnection detection and transport neighbor discovery.

The distinction matters only if you're actually using MP.  Yes, I
agree that's a bit of a hack, but, within a cooperating group, it
matters less than the issue of creating a new option does.

> none if its use is out of scope for a vendor).

Well, then, I think the same issues exist here ...

> LCP has to complete negotitation before any other protocol can start up.

Not true for LCP Identification.

> will not need to after introduction of this LCP option.

I wasn't suggesting that at all.  What I was suggesting was that if
peer A says "I'm server 7 in Chicago, and you're listening to port 5,"
then it's quite likely that peer B will want to use that information
when talking to the rest of the world: id est, advertising this link
(somehow) as a resource for constraint-based routing.

That's not at all the same thing as a network layer address.

In other words, if it's necessary, this may well be more than just a
way to detect wiring errors.  It ought to integrate into the way the
port is to be used.

(Sort of like the BACP Link-ID option ... but better.)

> manager.  I'll look to improve the text describing this.

So, the physical layer is torn down, and a new incarnation of the link
begins with a TDM flavor.  How is the TDM link supposed to be managed?
You've done away with PPP at this point, so it's not possible to
signal the peer to shut down the link.  There's no way to do link
quality monitoring.  There's no way to detect peer restart.

This seems to me to be a very fragile modal interface.  The danger of
having one of the peers in "special PPP" mode while the other is stuck
in the other mode seems pretty high.

What am I missing?

> consistent with the existing LCP state machine.

This is some usage of the word "destroyed" with which I was not
previously familiar.  :-/

> need to provide the trace information needed to solve the problem.

This proposal only covers a small subset of possible configuration
errors.  Is it still worthwhile?  Shouldn't there be some mechanism
that covers the cases where the peers *cannot* hear each other?  Since
this is an in-band mechanism, I don't see how it could be PPP.

More to the point: if the link fails to come up, why can't that
technician start up a link test tool that (using the link as a raw
HDLC interface) sends "I am port 5, server 7, in Chicago" over and
over?  Why does diagnosis of wiring errors have to be integrated into
PPP?

I think it's enough that PPP *detects* that the physical medium is
unusable.  I don't quite see why it should go ahead and include
options to analyze that failure in detail.

> returns to service neighbor discovery will be done again.

That makes assumptions that RFC 1661 does not.  In particular, RFC
1661 does *not* require any notification from the physical layer.
This is quite intentional, because physical layer notifications don't
always work right.

> new session will not be terminated by the transport equipment.

But if this secondary PPP session goes down, then somehow the physical
layer *will* be torn down, right?

>  If any

... making the first LCP Up/Down somewhat unnecessary.

> working on an approach...

SONET/SDH solve it by sending the C2 byte to signal the payload.
Switched protocols (e.g., ISDN and X.25) have similar mechanisms to
signal payload (although they're often mangled by switches and thus
ignored in practice, and caller information is used instead).

Other media are missing this, but don't have a problem because they
never switch modes.  This seems to be a new beast: a transport that
doesn't signal upper layer protocol, but does allow the protocol to
change over time.

> define a common format using a ubiquitous protocol.

There are many existing OAM protocols for TDM interfaces -- FDL on T1,
for example.  Granted, they're not perfect, but I don't quite see how
PPP can be a replacement unless the interface stays in PPP "mode" for
the life of the link, and thus allows LCP Echo-Request, LQM, and thus
more detailed monitoring.

It isn't as though OAM is just a test that's done once when a link
starts.

If the proposal were to add more OAM-like functionality to PPP, I
think that would be a lot more helpful.