The MPLS WG Archive

[Eric Rosen <erosen@cisco.com>]

Paul> Mail works  as well as it  does because of the  reliability built into
Paul> the application

Having  had several years'  experience managing  a large  world-wide mailing
list, I will never again speak of the "reliability" of the mail application.
If you  could only  see the  hundreds of error  messages that  are generated
every time someone  sends a message to the MPLS  list!  The Internet routing
is one  of the  most reliable  components of the  whole operation,  far more
reliable than the operations that occur at the mail servers.

Paul> and transfer protocols. 

It may be  comforting to think of TCP as maintaining  an open connection for
weeks while the  operators work heroically to restore  the connectivity that
has been  lost due to the plethora  of major routing failures.   But I don't
think  this  happens  much.   A  lack  of connectivity  will  result  in  an
application-layer retry at some later time.  In any event, the vast majority
of the connectivity problems (from my experience managing the MPLS list) are
due to  problems at the mail  servers.  DNS problems are  probably a distant
second.

Paul> That reliability is  provided because of the unreliable  nature of the
Paul> underlying network layer which can be attributed to a number of causes
Paul> including failures in IDR.

TCP provides  reliability not because  the underlying network  is unreliable
(in any common  sense of the word), but because  the underlying network does
not  provide a service  which guarantees  against loss.   "Doesn't guarantee
against  loss"  is  perhaps  the  technical  meaning  of  "unreliable",  but
rhetorically sliding from the  technical meaning ("IP provides an unreliable
service")  to  the  common  meaning  ("the Internet  is  unreliable")  is  a
fallacy. 

The various TCP  optimizations which presume in-order packet  delivery to be
the normal case are in fact  testimony to the reliability in practice of the
underlying network layer service.

Paul> As an aside I'm not aware of anyone who is suggesting building VPNs to
Paul> deliver email. 

I think that close to 100% of those who have VPNs use them for email.

Anyway, I'm sure you realize that  when Yakov said "email" he was just using
it  as an  example of  a  commonly used  Internet application.   The set  of
commonly used Internet  applications does bear a passing  resemblance to the
set of commonly used intranet applications. 

People build  VPNs to  support the entire  set of network  applications that
they need to run, email being one of them, of course.  

Paul> BGP helps the IP internetwork deliver email ergo it's good for VPNs ? 

I don't think Yakov said that, what he was saying is that if BGP is scalable
enough to handle Internet email, why should we think that it is not scalable
enough to handle VPNs.

Recognizing that "deliver email" is  really placeholder for "support a large
and  varied set  of  networking  applications", let's  rephrase:  if BGP  is
scalable enough to  handle a large and varied  set of Internet applications,
why should we think it is not scalable enough to handle VPNs."

Of course, the fact  that BGP is scalable enough to handle  VPNs does not by
itself imply  that VPNs  should be built  according to RFC2547,  because the
scalability of BGP is only one of the issues.

Paul> What does FUD stand for by the way

Fear, uncertainty, and doubt.  (I.e., marketing.)