RE: [PCN] RSVP and ECMP

Hi Hannes,

> 
> The problems obviously show up if the load balancing device 
> does not inspect the RSVP traffic.
> Then, you cannot ensure that the signaling traffic follows 
> the data traffic anymore.
> 

Sorry, I did not quite understand your point.  Wouldn't a packet
carrying RSVP message be processes just like any other packet in the
node which is not RSVP-capable?  So all that matters for the discussion
on using RSVP message as a probe is whether that packet goes the same
way as the corresponding data packets of the same flow under ecpm
decisions?  Am I missing the point you are making?

Anna

> -----Original Message-----
> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] 
> Sent: Thursday, October 25, 2007 6:14 AM
> To: Georgios Karagiannis
> Cc: pcn@ietf.org
> Subject: Re: [PCN] RSVP and ECMP
> 
> The problems obviously show up if the load balancing device 
> does not inspect the RSVP traffic.
> Then, you cannot ensure that the signaling traffic follows 
> the data traffic anymore.
> 
> Also with tunnels you need to ensure that at least one of the 
> tunnel endpoints is aware of the signaling protocol. This 
> might seem to be a simple requirement but I assume in reality 
> it is not that easy. This is the area where complexity says 
> HELLO to path-coupled signaling.
> 
> Ciao
> Hannes
> 
> PS: When you still think that it is totally trivial then you 
> might want to look at the many tunneling schemes folks use or 
> want to use.
> 
> Georgios Karagiannis wrote:
> > Hi Bruce, Hi all
> >
> > I agree with Bruce! If it is to use probing, then we have to ensure 
> > that the probes should get the similar correct ECMP 
> treatment as the 
> > correct ECMP treatment achieved by RSVP.
> >
> > This means that the probe messages have to have the same 
> addresses and 
> > ports as the data.
> > I think tat this is not difficult and not complex to be achieved.
> >
> > Best regards,
> > Georgios
> >
> >
> >
> > On 10/23/2007, "Bruce Davie" <bdavie@cisco.com> wrote:
> >
> >   
> >> Michael,
> >>  RSVP tries to forward the Path exactly the same way that it would 
> >> forward the data. Since Path messages are processed outside of the 
> >> fast path, it is possible for the router to look at 
> anything that is 
> >> in the path message, including source addr, dest addr, and port 
> >> numbers, and figure out where a data packet that had those 
> values in 
> >> its IP header would get forwarded. It sends the Path 
> message out that 
> >> interface. In practice, this takes care of the vast 
> majority of ECMP 
> >> algorithms. This approach is implemented today.
> >>
> >>  If ECMP was using something from the IP or higher layer 
> header that 
> >> was not in the Path message, then a problem would arise.
> >>
> >>  So, practically speaking, if the probe messages have the same 
> >> addresses and ports as the data, they should get correct ECMP 
> >> treatment. Or at least, fare no worse than RSVP.
> >>
> >> Bruce
> >>
> >> On Oct 23, 2007, at 12:07 PM, Michael Menth wrote:
> >>
> >>     
> >>> Hi,
> >>>
> >>> I've got a question regarding RSVP. PATH messages need to 
> be carried 
> >>> over the same path as subsequent data packets. How is 
> this achieved 
> >>> in the presence of ECMP routing? In theory, PATH messages 
> can take a 
> >>> different route than data packets if the load balancer takes 
> >>> arbitrary parts of the header(s) to calculate a suitable 
> hash value, 
> >>> which decides which route the packet will take.
> >>>
> >>> This issue seems to be related to the problem of how to make sure 
> >>> that PCN probe messages take the same path as subsequent PCN data 
> >>> packets, provided that they have the same source and destination 
> >>> ports and addresses.
> >>>
> >>> I am interested in how this problem is solved in practice 
> or whether 
> >>> it is intentionally avoided.
> >>>
> >>> Regards,
> >>>
> >>>    Michael
> >>>
> >>> --
> >>> Dr. Michael Menth, Assistant Professor University of Wuerzburg, 
> >>> Institute of Computer Science Am Hubland, D-97074 Wuerzburg, 
> >>> Germany, room B206
> >>> phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 
> >>> mailto:menth@informatik.uni-wuerzburg.de
> >>> http://www3.informatik.uni-wuerzburg.de/research/ngn
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> PCN mailing list
> >>> PCN@ietf.org
> >>> https://www1.ietf.org/mailman/listinfo/pcn
> >>>       
> >> _______________________________________________
> >> PCN mailing list
> >> PCN@ietf.org
> >> https://www1.ietf.org/mailman/listinfo/pcn
> >>     
> >
> >
> > _______________________________________________
> > PCN mailing list
> > PCN@ietf.org
> > https://www1.ietf.org/mailman/listinfo/pcn
> >   
> 
> 
> 
> _______________________________________________
> PCN mailing list
> PCN@ietf.org
> https://www1.ietf.org/mailman/listinfo/pcn
> 

_______________________________________________
PCN mailing list
PCN@ietf.org
https://www1.ietf.org/mailman/listinfo/pcn