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

From: Jonathan Sadler <[email-masked]>
Date: Tue, 04 Jun 2002 13:35:23 -0500

James -

James Carlson wrote:
> 
> > 6.1.4 Misconnection failure modes
> >
> >    Because successful LCP negotiation is dependent on a full-duplex
> >    link existing between two neighboring nodes, a misconnection will
> >    not allow LCP to complete successfully.  As a result, any support
> >    for identifying a misconnection must be done via an LCP option.
> >    Given that a misconnection may occur for any supported Interface,
> >    the exchange of Interface Names provides the best information for
> >    debugging a misconnection.
> 
> I'm failing to see the justification of a new LCP option here (or
> 6.1.3).

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.

While full-duplex electrical serial interfaces typically have the RX and
TX signals on the same connector (eg. RS-232 on a DB-25 or DB-9,
Ethernet on a DB15 or RJ45), fiber-optics serial interfaces typically do
not (eg. OC-n on ST or SC).  As the draft points out, it is possible for
the following misconnection scenarios to exist:
   - 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

This is not the same as misconfiguration of a PPP option.

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

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

Instead, we are looking to provide an aid to the technition that is
trying to figure out how things are misconnected.  Finding a
misconnection may seem simple when the number of terminations to choose
between is less than 10.  However, modern Digital Cross Connect systems
are located in offices with fiber patch frames containing hundreds to
thousands of terminations.

Consequently, knowing the ID of the port that a span has connected to
will provide significant help in figuring out where the misconnection
is.

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

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

If a port does support an NCP, then the port would continue to negotiate
MLPPP, Authentication, and the NCP just like PPP does today.

> This raises several significant problems: the document does
> not describe exactly when and how this hand-off occurs, it does not
> describe what happens if the peer attempts to restart LCP (unless
> physical end-to-end signaling is always required, and that's not a
> requirement of PPP), and it does not describe how this feature
> 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.

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

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

> 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 doesn't have to go through the pains of interoperability testing
 - It removes the issue of having to distingush between PPP and the
   "other" protocol.
 - It provides the opportunity for non-router devices to learn the
   identity of a router without requiring routers to do significant
   software development.

I'm not certain why you say this is redefining the PPP subprotocols.  It
is an extension to the LCP option set only.  No other PPP sub-protocol
is touched.

> There are other issues with the draft (e.g., the session ID doesn't
> appear to be necessary, since the peers themselves already know over
> which port they're communicating -- there can be only one session on
> any given peer-to-peer connection), but I think those can wait until
> the fundamental questions are addressed.

Actually, the session ID is a hold over from the LMP test message that
this draft is attempting to replace.  I agree that it is not necessary.

If you have been following the work in the CCAMP WG, you will notice
that LMP is proposing a non-standard use of PPP to carry the test
message.  Specifically, they are looking to send the this IP-based
message without the successful negotiation of LCP or IPCP.

This draft proposes a mechanism to do the same thing as the test message
without violating the requirement stated in RFC 1661 that LCP and NCPs
MUST be succesfully negotiated before sending IP frames.

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: Tue, 4 Jun 2002 15:32:46 -0400

> been correctly terminated on a corresponding RX/TX pair on the remote

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.

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

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.

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

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.

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

> will provide significant help in figuring out where the misconnection

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.

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

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

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

> MLPPP, Authentication, and the NCP just like PPP does today.

So, then, how does this differ from the existing authentication
protocols?

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

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

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

>  - It leverages the existing PPP code-base 

It proposes a code change that everyone has to support.

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

>  - It removes the issue of having to distingush between PPP and the

Do you have to distinguish between PPP and Cisco HDLC?  Or between PPP
and ATM?

I don't think that goes away.

> is an extension to the LCP option set only.  No other PPP sub-protocol

That's exactly what I'm saying.  I don't see the need for changes to
PPP at all for this particular application.

> this draft is attempting to replace.  I agree that it is not necessary.

OK.

> message without the successful negotiation of LCP or IPCP.

Actually, no, I've been trying to ignore CCAMP.  I just picked up
again because of this draft ...

> MUST be succesfully negotiated before sending IP frames.

I'm not sure that this proposal is necessarily better.

By prior arrangement, peers can certainly send IP packets without
doing LCP and NCP.  That's what all of the old HDLC-based protocols
used to do.  Of course, such a hack is never really necessary.

That is to say, I don't see the need for either case.

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.