Subject: RE: your mail

From: Shahram Davari <[email-masked]>
Date: Mon, 22 Jul 2002 12:06:57 -0700

> -----Original Message-----
> From: Eric Rosen [mailto:[email-masked]]
> Sent: Monday, July 22, 2002 2:56 PM
> To: Shahram Davari
> Cc: 'Giles Heron'; [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: your mail 
> 
> 
> 
> 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.)

This was just a theoretical suggestion. You could always do ACL.

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

I haven't seen that in PWE3 or PPVPN yet.

  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:

Let's stick to the issue. 

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

"Deep" or "not deep" you need potentially unlimited packet parsing
(uo to MTU size), since as you said the number of labels are not limited to 2.

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

What is the relevance?

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

Please stick to the technical issue. 

-Shahram

---

From: Eric Rosen <[email-masked]>
Date: Mon, 22 Jul 2002 15:15:13 -0400

Shahram> "Deep" or "not deep"  you need potentially unlimited packet parsing
Shahram> (uo to  MTU size), since as you  said the number of  labels are not
Shahram> limited to 2. 

To  the MTU  size?   That would  be for  the  case where  the entire  packet
contains the MPLS label stack and there is no payload?

As has been made  clear repeatedly, you can hash on any  label, you just get
more fine-grained load balancing the  further down you go.  So generally you
would look  at the  bottom-most label  that you can  easily see,  given your
particular forwarding architecture.