headers
Internet-Drafts | 4 Jun 2002 13:43
Picon
Favicon

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

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Neighbor Discovery via PPP
	Author(s)	: J. Sadler, B. Mack-Crane
	Filename	: draft-sadler-pppext-disc-01.txt
	Pages		: 7
	Date		: 03-Jun-02
	
Work has been progressing in the Common Control and Measurement
Protocol (CCAMP) working group on the application of MPLS technology
to non-packet switching networks.  Development of the Generalized
MPLS (GMPLS) signaling draft [1] has allowed for Optical, SONET/SDH,
and spatial switching systems to be controlled using IP protocols.
In a GMPLS network, the path that a TDM connection will use is
developed using constraint based routing.  The developed route
utilizes TDM link state information announced via OSPF or IS-IS by
other nodes in the network.  However, a node cannot advertise the
existence of a link without first identifying the remote node
connected to the link and the capabilities of the neighboring node.
In a packet network, this function would typically be accomplished
using OSPF or IS-IS Hello messages repeated every 10 or so seconds.
However, the TDM link cannot transmit similar messages because the
port terminating the link cannot be shared between a TDM service
user and the OSPF/IS-IS termination function.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-sadler-pppext-disc-01.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Internet-Drafts | 4 Jun 2002 13:44
Picon
Favicon

I-D ACTION:draft-song-pppext-sip-support-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: SIP server IPCP configuration option for PPP
	Author(s)	: J. Song, D. Kim
	Filename	: draft-song-pppext-sip-support-00.txt
	Pages		: 6
	Date		: 03-Jun-02
	
The Point-to-Point Protocol (PPP) [1] provides a standard method for
transporting multi-protocol datagrams over point-to-point links.  
PPP defines an extensible Link Control Protocol (LCP) for 
establishing, configuring, and testing the data-link connection; and
a family of Network Control Protocols (NCPs) for establishing and 
configuring different network-layer protocols.
This document defines the PPP IPCP configuration option that contains
a list of IPv4 addresses that can be mapped to one or more SIP
proxy servers. It is just one of the many possible mechanism to 
locate the proxy server, such as DHCP option [6] and manual 
configuration. This approach is applicable to the system using PPP 
for the link layer protocol and IP address allocaiton (ex. 3GPP2 
Packet Data network)

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-song-pppext-sip-support-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
(Continue reading)

Permalink | Reply | 1 comment |
headers
James Carlson | 4 Jun 2002 14:05
Picon

Re: I-D ACTION:draft-song-pppext-sip-support-00.txt

>   The SIP (Session Initiation Protocol) [3] is a signaling protocol 
>   used for the session invitation, modification and termination. 
>   The UAC (User Call Agent) sends a request to the callee UAC.  
>   However, the request message (INVITE) is not directly sent to the 
>   callee UAC, it rather go through proxy servers, and redirect
>   servers.  This draft is specifying one of the many possible mechanism
>   to locate the proxy server, such as DHCP option [6] and manual 
>   configuration.
[...]
>   Note : the format and behavior of these options are quoted from 
>   RFC1877 [2] for the sake of consistent implementation of PPP. 

Please do not do this.  DHCP works just fine over PPP, and it's the
appropriate mechanism for distributing application configuration
information such as SIP server addresses.  Negotiating this within
IPCP isn't the right thing to do because IPCP is part of the link
layer.  Would a SIP implementation expect to reach around IP to get
SIP server addresses from the Ethernet driver?  Or from a CLIP driver
on ATM?  Since it doesn't do that, why should it expect that same
configuration data from PPP?

In other words, with this proposal, you still need to have DHCP
distribution of these addresses on all L2 media other than PPP.  Thus,
it may as well be consistent on PPP rather than requiring a special
L2-specific mechanism.

RFC 1877 was a technical mistake and ought not be repeated.  If only
we could get rid of it ...

--

--
(Continue reading)

Permalink | Reply | 0 comments |
headers
James Carlson | 4 Jun 2002 14:37
Picon

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

> 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).  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.  That doesn't
mean that all NCPs should be negotiated in LCP.

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

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
(Continue reading)

Permalink | Reply | 2 comments |
headers
Bernard Aboba | 4 Jun 2002 15:21

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

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

I think that this would work fine. In particular, there is nothing in RFC
2284 that prohibits sending an EAP-Request/Identity, receiving an
EAP-Response/Identity, and then sending an EAP-Success to end the
exchange.
Permalink | Reply | 1 comment |
headers
James Carlson | 4 Jun 2002 16:27
Picon

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

Bernard Aboba writes:
> > 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.
> 
> I think that this would work fine. In particular, there is nothing in RFC
> 2284 that prohibits sending an EAP-Request/Identity, receiving an
> EAP-Response/Identity, and then sending an EAP-Success to end the
> exchange.

Nor is there anything that actually says what (if any) internal
structure might exist in the "Identity" value.  It's all based on
prior agreement between the peers.

--

-- 
James Carlson, Solaris Networking         <james.d.carlson <at> east.sun.com>
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
Permalink | Reply | 0 comments |
headers
Jonathan Sadler | 4 Jun 2002 20:35
Picon
Favicon

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

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)
(Continue reading)

Permalink | Reply | 1 comment |
headers
James Carlson | 4 Jun 2002 21:32
Picon

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

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.

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

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
(Continue reading)

Permalink | Reply | 0 comments |
headers
James Carlson | 5 Jun 2002 17:58
Picon

Re: I-D ACTION:draft-hiller-dns-addr-00.txt

Because I commented on the SIP server address draft, someone pointed
out this draft to me as well.  I somehow overlooked it the first time
around.  Sorry for the extreme time delay.

>  A major portion of the text in this memo was stolen from RFC 1877 
>  [8].

Indeed.  And the proposal is flawed for exactly the same reasons that
RFC 1877 is flawed.  These include:

	- There's no reason to expect that the "server" end of the
          connection can supply or that the "client" end can use these
          addresses.  It works only when the server has special
          configuration, and the client *happens* to also be running a
          local set of applications that care about DNS server
          addresses.  It fails utterly if either peer happens to be a
          mere router or bridge.

	- Using draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt with
          DHCPINFORM gives simple support for this feature on PPP, as
          well as over any other medium that can carry UDP/IPv6.
          Having one mechanism rather than N (where N>1) is better.

	- The negotiation is backwards; the Configure-Request sender
          is somehow obliged to "guess" at the addresses of the DNS
          servers that actually reside on the other end of the link.

More fundamentally, DNS server addresses (and search paths, and boot
image names, and log hosts, and print servers, and home page URLs, and
so on) are application-level details.  PPP's NCPs are a mechanism for
(Continue reading)

Permalink | Reply | 5 comments |
headers
Jonathan Sadler | 5 Jun 2002 18:41
Picon
Favicon

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

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
(Continue reading)

Permalink | Reply | 1 comment |

Gmane