Subject: Re: Usage of ML Endpoint Discriminator Option

From: Vernon Schryver <[email-masked]>
Date: Thu, 26 Aug 1999 16:19:23 -0600 (MDT)

> From: "John R. Martz" <[email-masked]>

> In our case we were using an IBM 2210 router. But I'm sure ...
> that is I don't really know, but I'd bet a small amount of money
> on it being true ... that this scenario is also quit possible with
> other routers still in common use today.

Again, I've seen packet traces from more than 1 or 2 routers, albeit
never as far as I know from an IBM box, but I don't recall a router
not having an IP address.

> Yes, you can configure the 2210 to have a local IP address. And
> depending on what you're doing this might be the "better" thing to
> do. 

If the 2210 does not have an IP address, how do you manage it?
A router that cannot be remotely managed had better cost almost
nothing in today,s market.

>     My point was just that I don't think I can always assume that
> the remote peer is going to tell me it's IP address. That's just
> too big a leap for me.

Yes, besides the dogma "be conservative in what you send and generous
in what you receive," it is a fact that the peer is not required to
negotiate an IP address.

> (Customers are notorious for wanting to do things I personally don't
> think are very reasonable. Not so long ago I was called for a customer
> who had an old "clunker" 2400 baud IBM modem that AS/400 PPP wasn't working
> with. He could have simply switched to a Sporster 28.8 (or such) and both
> eliminated the problem and increased his throughput for what I considered
> a very negligible cost. But nope. He had an IBM modem and he darn well
> expected it to work with an IBM system! How could I say no?? :)

yes, customers can be picky.

Still, if you have any influence on this 2210 IBM product, and you have
any reason to hope it does well in the market, it would be wise to exert
your influence to make it less unreasonable.  A router that does not
divulge its IP address is legal, but not reasonable and not competative.

Vernon Schryver    [email-masked]

---

From: Eric Michelsen <[email-masked]>
Date: Fri, 27 Aug 1999 14:13:40 -0700

I'm not familiar with BF&I.  Can someone give me reference for it?  Or tell
me what it stands for?
-------------------------------------------
Eric L. Michelsen, Copper Mountain Networks 

> -----Original Message-----
> From: James Carlson [mailto:[email-masked]]
> Sent: Wednesday, August 25, 1999 15:07
> To: [email-masked]
> Subject: Re: Usage of ML Endpoint Discriminator Option
> 
> 
> [email-masked] (Vernon Schryver) writes:
> > Agreed, but at least in BSD kernels, the identity of the 
> entire bundle
> > will be closely associated with that original IP address.  
> Anything that
> > conflicts with that original IP address, such as recycling 
> through IPCP
> > and getting a different IP address, is problem.
> 
> True, but I'm missing something here.  When you get a new connection
> from a peer (one that *you* didn't originate, and therefore have no
> reason to associate with any particular IP address), how do you a
> priori know the address at the other end?
> 
> I think that was the point I was trying to make.  You generally have
> to wait until authentication is done until you put a new link into an
> existing bundle.
> 
> > Also, if you consciously associate the IP address with the 
> identity of
> > the bundle, it's easy to use BF&I instead of RFC 1990.
> > 
> > I can't tell if BF&I still matters.
> 
> Very much so!  MP is horrid at very high speeds, or if you have to
> deal with fail-over.
> 
> -- 
> James Carlson, System Architect                     
> <[email-masked]>
> IronBridge Networks / 55 Hayden Avenue   71.246W   Vox:  +1 
> 781 372 8132
> Lexington MA  02421-7996 / USA           42.423N   Fax:  +1 
> 781 372 8090
> "PPP Design and Debugging" --- 
> http://people.ne.mediaone.net/carlson/ppp
>

---

From: Vernon Schryver <[email-masked]>
Date: Fri, 27 Aug 1999 15:29:19 -0600 (MDT)

> From: Eric Michelsen <[email-masked]>

> I'm not familiar with BF&I.  Can someone give me reference for it?  Or tell

It stands for Brute Force & Ignorance, and I apply it to the obvious way
to reverse multiplex IP packets over serial links.  It is not pejoritive,
at least in my mind.  I also believe that simpler is usually better.

---

From: [email-masked]
Date: Mon, 30 Aug 1999 11:34:25 -0500

> Yes, many can.  I side with Vern on this one, though:
> setting it up that way isn't a feature.  It's a bug.

James,

Point taken. However "bug" seems too strong a description since "setting it up
that way" is still a correct implementation of RFC1332. If you want to call it a
bug, shouldn't you negotiate a change to the description of IP address
negotiation in RFC1332?

I also feel I should clarify one more time "for the record" that the 2210 (and
many other routers actively in use) CAN be configured to provide an IP address
as part of IPCP negotiation. So when a router does not provides an IP address
when you connect, it is doing this because the customer decided to do it this
way. Even if RFC1332 required an IP address to be provided (which it does not)
an implementation that does not send an IP address as a result of a customer
configuration choice is still technically correct, no?

Speaking from my end of the link, an implementation cannot break ... cause a
link attempt to fail ...  because a customer set up my peer with a legal
configuration that may not be viewed as appropriate for a wider context. And I
don't recall any of the points that have been made as being stronger than
reasons why one peer SHOULD tell the other peer what its IP address is. So while
it may be a very good idea to do this, it cannot be depended on. I cannot drop
the link if a peer does NOT give me its IP address. Correct?

Finally, whatever else it did, this discussion has at least made me feel better
about AS/400. A while back we made a design decision that AS/400 MUST always
have a local IP address to give to its peer in order to use PPP. Nice to know
that we appear to have made a "right" decision (... even though we made it for
other reasons :)

-john martz, 8-852-5539,  [email-masked]
IBM AS/400 TCP/IP PPP development (and stuff)