Subject: RE: your mail

From: Shahram Davari <[email-masked]>
Date: Mon, 22 Jul 2002 10:34:37 -0700

Giles,

> 
> so let's to go back to Yakov's email of 31st May:
> 
> ------
> Giles,
> 
> > 1.  Efficient encapsulation of VPN traffic

Correct, if you mean compared to IP forwarding.

> > 2.  Ability to run VPN on current hardware

Who's hardware? the one who has the most market share?
As I said in another email market share should not be 
used as the basis for a standard organization. Otherwise
whoever has the biggest market share could make ANY thing
they like to be a standard.

> > 
> > There are probably other reasons as well...
> 
> One of the "other reasons" is straightforward protection 
> against packet 
> spoofing.

The packet spoofing that Yakov mentioned relies on the
fact that an edge router never accepts an MPLS packet (which is not always true)
and that it never terminates the MPLS tunnel in an inetrior LSR. 
The same thing could be said for IP tunnels: The edge router
never forwards the incoming packets without encapsulating them in IP tunnel, and
it never terminates an IP tunnel in an interior router.

So IP tunnels have exactly the same packet spoofing prevention level as LDP LSPs.

The only advantage I see using LDP as compared to IP tunneling is 16 bytes BW saving
per packet, at the expense of implementing MPLS signaling and control-plane, as well as inability to decouple availability and QoS and creating new failure modes that are very hard to detect (even with MPLS-ping).

I think somewhere you mentioned that sparing some extra BW may make sense if it makes the network easier to manage.

-Shahram

> 
> Yakov.
> ------
> 
> whether these are "killer" reasons to deploy LDP rather than "pure IP"
> or not depends on your point of view, but they are certainly reasons.
> 
> there are of course others - e.g. the ability to run a BGP free core
> (which some consider important for running carrier-grade voice and
> Internet over the same PSN infrastructure).
> 
> Giles
> 
>  -	VPN survivability is a function of all cross-VPN traffic and is
> > temporally non-deterministic on a per customer basis per 
> epoch.  That is,
> > there is no relationship between a DS codepoint and that pkt's
> > 'survivability priority' vis-a-vis other pkts of same/different DS
> > codepoints in either the same or other VPNs....and that's a 
> consequence of
> > like-DS-class merging across VPN populations.
> > -	because of this hard QoS/availability guarantees per 
> VPN customer
> > are not possible
> > -	because of this we are forced over-engineer and hope
> > -	MPLS introduces new failures modes even in p2p mode (this is the
> > absolute vs relative addressing issue that I mentioned 
> previously), but mp2p
> > LSPs create a new richness of fault-management complexity
> > -	the LDP LSPs track the IGP and so the network is not 
> flexible wrt
> > traffic sensitivities......hence, it requires hashing 
> functions at P nodes
> > which not only breaks the MPLS simple label forwarding idea 
> of MPLS but
> > introduces another level of fault-management to deal with.
> > 
> > So the fault-management issue (which you think is not 
> important given the
> > tone of your response) is but 1 consequence of LDP.  Similarly, the
> > load-balancing issue is another consequence of LDP.  And 
> similarly, another
> > consequence of LDP is the inability to decouple VPN 
> performance/availability
> > on a *per customer basis*.  So all these aspects are 
> compromised when we use
> > LDP......and for what compelling advantage(s) over using an 
> IPinIP solution
> > (or p2p LSPs as/when necessary)?  So please answer that for 
> me so that I can
> > understand what I and others are clearly missing here that 
> makes LDP so
> > wonderful that we simply can't afford to live without it?
> > 
> > regards, Neil
> > <snipped to end>
> > 
> -- 
> =================================================================
> Giles Heron    Principal Network Architect    PacketExchange Ltd.
> ph: +44 7880 506185              "if you build it they will yawn"
> =================================================================
>

---

From: Eric Rosen <[email-masked]>
Date: Mon, 22 Jul 2002 14:55:58 -0400

Shahram> The same thing could be said  for IP tunnels: The edge router never
Shahram> forwards  the incoming  packets  without encapsulating  them in  IP
Shahram> tunnel 

Of course, brilliant  idea!  Configure your edge routers  so that they don't
forward incoming IP packets, and then  you don't have to worry about spoofed
packets at all.  I wonder why no  one else ever thought of that.  (Well, no,
actually I don't wonder.)

Shahram> The only advantage  I see using LDP as compared  to IP tunneling is
Shahram> 16 bytes BW saving per packet

That's  because you're  not thinking  about the  ways in  which LSPs  can be
nested  in   each  other.    Start  combining  pseudowires,   VPNs,  traffic
engineering,  apply  various aggregation  strategies,  and  you  can end  up
building a label stack  with a few more than two label  entries on it, and a
label stack  whose size  changes as  the packet goes  about its  travels.  A
strategy which  says "just replace  the top label  with an IP  header" isn't
really coherent.  You  either have to replace all but  the bottom label with
an IP header,  or you have to have hardware which  can push/pop/replace on a
stack some  of whose  entries are labels  and some  of whose entries  are IP
headers.  Oh  yes, what a  simplification.  A few  nested IP headers  on the
stack and  your high speed hardware probably  won't even be able  to see all
the headers!  And the resulting packet size increase is not 16 bytes, but 16
times n.  (Even  16 is not to be  laughed off, because of its  effect on the
packet MTU.) 

There are quite a few advantages  to having a single, general, flexible, and
efficient encapsulation protocol which can  be put to a variety of different
uses.  

Frankly,  I  do not  believe  this thread  is  being  pursued for  technical
reasons.  To wit:

Eric> A procedure wherein  you make a decision based on  the contents of the
Eric> header would not generally be known as "deep packet parsing".

Shahram> A header that has no length  field (as is in case of MPLS) requires
Shahram> parsing to find out the end of the header.  

Most  forwarding procedures  require  understanding the  header formats  and
being  able  to  find the  header  fields.   I  cannot believe  that  anyone
seriously doesn't  understand the difference between parsing  the header and
"deep packet parsing".  It's hard to take this seriously.

I know, I  know, if Y.1711 doesn't  apply to the world, then  it's the world
that has to change, right?  

I have heard that  there are vendors who are afraid of  getting stuck with a
bunch of Y.1711  chips if it turns  out that Y.1711 is not  adopted, but I'm
sure   you  wouldn't  want   the  standards   process  polluted   with  such
irrelevancies.