Subject: RE: your mail

From: Shahram Davari <[email-masked]>
Date: Tue, 2 Jul 2002 07:20:42 -0700

-----Original Message-----
From: Eric Osborne
To: Shahram Davari
Cc: 'Eric Osborne'; [email-masked]'; George Sheng; [email-masked]; [email-masked]
Sent: 7/2/02 5:56 AM
Subject: Re: your mail

> > Why not?  Given that LDP (not CR-LDP) simply follows the IGP
routing,
> > shouldn't you have said something like "...to overcome {ISIS|OSPF}'s
> > ability to TE..."?  At the very least, that's spitting into the
wind;
> > what we have with IP now has made a lot of people happy for a very
> > long time.
> 
> I don't believe dynamic routing = TE 
>  

ok...so not that I agree with you, but if your definition of TE means
"non-SPF paths" then things are starting to make sense.

Yes.

Certainly
using SPF is pretty coarse, but I've always considered it a form of
TE.

SD=> Interesting !!!! SPF ~= TE. I let others judge.

To me, TE is manipulating your traffic to fit your network
topology, and changing IGP metrics to steer traffic around is one way
to do that.

> > Not sure what "hash states" are, but at least in one implementation
> > I'm familiar with, there's no state kept for any sort of load
> > balancing, be it IP ECMP, MPLS ECMP, or MPLS unequal-cost balancing.
> > No per-flow state, no per-packet state, nothing.
> 
> To do ECMP, you need to assign hashed values to egress ports. This
> assignment is the hash state that I said you need.
> 

Then I guess I don't see what's inherently bad about them?

SD=>This was in response to your comment that said no state is required.

  So I add a
hash lookup - so what?

SD=> So you do more than one lookup- so what? so you need to parse the whole packet in the core-so what? so you need to keep state in the core, so what? so you have no longer a simple label swap- so what? so you may hash an encripted packet-so what?.....

 From an IP perspective, as long as I avoid out
of order packets, I'm OK, and any reasonable implementation is going
to keep the same conversation/flow/whatever following the same path.

> > It's true that the
> > forwarding path involves a hash lookup during forwarding to a
> > load-balanced prefix, but to inherently declare that unacceptable
> > doesn't seem right.  And for what it's worth, the same forwarding
> > implementation handles MPLS-TE loadsharing as well, which I think
> > we've agreed so far is pretty useful.
> 
> Agree, but only if the top label is used for hashing. 
> 

Why does it matter what value you use for hashing?

SD=> I was responding to your comment that the same technique handles
MPLS-TE.

    What's the
fundamental objection to using label stack/underlying payload?

SD=> MPLS was designed to have simple forwarding. Hashing takes it
to new levels of simplification never seen before.

-Shahram

  This
is like saying it's OK to use only IP SA/DA for hashing, and not
things like L4 ports.  From my perspective, as long as 
	a) you keep conversations in order
	b) you can balance traffic reasonably well

then your hash function has done its job.  Right?

And for that matter, is it OK to use SA/DA on an IP packet for
hashing?  If so, why can't I use the same information (as found
underneath a label stack) in an MPLS packet to do the same thing?
It's not like this is *forwarding*, it's just hashing.

eric

---

From: Eric Rosen <[email-masked]>
Date: Tue, 02 Jul 2002 11:01:31 -0400

SD=> So you do more than one lookup- so what? so you need to parse the whole
SD=> packet in the core-so what? so you need to keep state in the core,

Please pay attention. 

There is not  more than one lookup; doing the hash  does not require looking
anything up. 

Finding the bottom label does not involve parsing the whole packet. 

There is no state kept in the core. 

SD=> so you have no longer a simple label swap

It is true that the essence of  load balancing over equal cost paths is that
the outgoing interface  is not chosen solely on the basis  of the top label.
So? 

SD=> MPLS was  designed to have simple  forwarding. Hashing takes  it to new
SD=> levels of simplification never seen before.  

You might take a peek at section 3.12 of RFC 3031.