Subject: RPF neighbor

From: Brian Edwards <[email-masked]>
Date: Mon, 9 Apr 2001 16:00:56 -0700

How would you choose an RPF neighbor if the MRIB has multiple equal cost
paths to the source/RP address? In other words, the MRIB indicates that
there are multiple neighbors that should be used to forward packets to that
address.

Thanks,
Brian

---

From: "Moeller, John" <[email-masked]>
Date: Tue, 10 Apr 2001 09:47:40 -0400

Brian:

I believe that the RPF mechanism is supposed to pick the route with the
highest next-hop gateway address, regardless of any other route-choosing
scheme involved.  This eliminates any problem with round-robin or other
multi-path schemes on the RPF mechanism.

> -----Original Message-----
> From: Brian Edwards [mailto:[email-masked]]
> Sent: Monday, April 09, 2001 5:01 PM
> To: [email-masked]
> Subject: RPF neighbor
> 
>

---

From: "Sundeep Singatwaria" <[email-masked]>
Date: Tue, 10 Apr 2001 09:39:10 -0700

-----Original Message-----
From: Moeller, John [mailto:[email-masked]]
Sent: Tuesday, April 10, 2001 6:48 AM
To: [email-masked]'
Subject: RE: RPF neighbor

Brian: 

scheme involved.   

I don't agree with this stmt.

 This eliminates any problem with round-robin or other multi-path schemes on
the RPF mechanism. 

For ECMP routes, you could do round-robin or any other mechanism to load
balance traffic. 

> From: Brian Edwards [ mailto:[email-masked]
<mailto:[email-masked]> ]

---

From: "Moeller, John" <[email-masked]>
Date: Tue, 10 Apr 2001 14:19:51 -0400

If a router had more than one route back to a source, which one would it
pick to be the IIF?  A router cannot arbitrarily pick which interface to
receive traffic on.  You can have multiple OIFs, but you can only have one
IIF.  If the router recieved traffic on a different interface, it would drop
the packets.

Even if you could have more than one IIF, that means you would have to
maintain state in all of the routers that may be in between the two routers
that are multipathing, which isn't the best idea to do, since state can be
expensive.

John Moeller
Firmware Engineer
Salt Lake City Firmware

[email-masked] 

JM>I believe that the RPF mechanism is supposed to pick the route with the
highest next-hop 
JM>gateway address, regardless of any other route-choosing scheme involved.

SS>I don't agree with this stmt.

JM>This eliminates any problem with round-robin or other multi-path schemes
on the RPF 
JM>mechanism. 

SS>For ECMP routes, you could do round-robin or any other mechanism to load
balance traffic.

---

From: Billy Ng <[email-masked]>
Date: Tue, 10 Apr 2001 15:19:18 -0400

IP Multicast will not work with ECMP.  The highest IP address is chosen.
If you really want load balance, you will need to send the multicast packets
thru a tunnel such as GRE.
 
--Billy

-----Original Message-----
From: Sundeep Singatwaria [mailto:[email-masked]]
Sent: Tuesday, April 10, 2001 11:39 AM
To: 'Moeller, John'; [email-masked]'
Subject: RE: RPF neighbor

-----Original Message-----
From: Moeller, John [mailto:[email-masked]]
Sent: Tuesday, April 10, 2001 6:48 AM
To: [email-masked]'
Subject: RE: RPF neighbor

Brian:

---

From: "Moeller, John" <[email-masked]>
Date: Tue, 10 Apr 2001 16:59:42 -0400

Brian,

RPF isn't really even defined in the old PIMv2.  I found the definition I
use in S. Deering's paper "Multicast Routing in Internetworks and Extended
LANs", section 5.2.  I don't have a date on my copy, so judging by the
references, it could be as old as May of 1988.

I'm not sure if the protocol needs to be revised in order to accomodate
ECMP, but I would recommend against it, as it would require potentially more
state.

John Moeller
Firmware Engineer
Salt Lake City Firmware

[email-masked]
www.enterasys.com 

> Sent: Tuesday, April 10, 2001 2:04 PM
> To: 'Moeller, John'; 'Sundeep Singatwaria'; [email-masked]'
> John,
> I can't find this the latest PIM draft. Is it necessary for different
> implementations to use the same tie-breaker or does this need to be
> specified in the spec?
> 
> Thanks,
> Brian
>

---

From: "Sundeep Singatwaria" <[email-masked]>
Date: Tue, 10 Apr 2001 14:05:37 -0700

-----Original Message-----
From: Moeller, John [mailto:[email-masked]]
Sent: Tuesday, April 10, 2001 11:20 AM
To: Singatwaria, Sundeep [SC7:370-M:EXCH]; [email-masked]'
Subject: RE: RPF neighbor

For a given S,G you should have only one IIF.

I don't think we need multiple IIF. For a given S,G1 take path A  , for S,G2
take path B. and so on. Do you see a problem with this paradigm.

Sundeep

John Moeller 
Firmware Engineer 
Salt Lake City Firmware 

[email-masked]

---

From: "Moeller, John" <[email-masked]>
Date: Tue, 10 Apr 2001 17:19:41 -0400

Well, yes, of course you could use different paths for different groups,
because the route selection algorithm is arbitrary.  You just can't use more
than one route for a SINGLE group, which I believe was the thrust of this
discussion.

John Moeller
Firmware Engineer
Salt Lake City Firmware

[email-masked] 

-----Original Message-----
From: Sundeep Singatwaria [mailto:[email-masked]]
Sent: Tuesday, April 10, 2001 3:06 PM
To: 'Moeller, John'; [email-masked]'
Subject: RE: RPF neighbor

-----Original Message-----
From: Moeller, John [mailto:[email-masked]]
Sent: Tuesday, April 10, 2001 11:20 AM
To: Singatwaria, Sundeep [SC7:370-M:EXCH]; [email-masked]'
Subject: RE: RPF neighbor

JM>If a router had more than one route back to a source, which one would it
pick to be the 
JM>IIF?  A router cannot arbitrarily pick which interface to receive traffic
on.  You can have 
JM>multiple OIFs, but you can only have one IIF.  If the router recieved
traffic on a 
JM>different interface, it would drop the packets. 

SS>For a given S,G you should have only one IIF.

JM>Even if you could have more than one IIF, that means you would have to
maintain state in 
JM>all of the routers that may be in between the two routers that are
multipathing, which 
JM>isn't the best idea to do, since state can be expensive. 

SS>I don't think we need multiple IIF. For a given S,G1 take path A  , for
S,G2 take path B. 
SS>and so on. Do you see a problem with this paradigm.

SS>Sundeep

---

From: "Sundeep Singatwaria" <[email-masked]>
Date: Tue, 10 Apr 2001 16:07:19 -0700

Well,  a lot of customers who are doing video distribution wouldn't want all
their feeds to be egressing on a single link - when there are other equal
costs path available. They could benefit a lot.
 
If we don't see a problem with this than the standard should recommend this
mechanism to reduce congestion.
 
Sundeep

-----Original Message-----
From: Moeller, John [mailto:[email-masked]]
Sent: Tuesday, April 10, 2001 2:20 PM
To: Singatwaria, Sundeep [SC7:370-M:EXCH]; [email-masked]'
Subject: RE: RPF neighbor

John Moeller 
Firmware Engineer 
Salt Lake City Firmware 

[email-masked] 

-----Original Message----- 
From: Sundeep Singatwaria [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Tuesday, April 10, 2001 3:06 PM 
To: 'Moeller, John'; [email-masked]' 
Subject: RE: RPF neighbor 

-----Original Message----- 
From: Moeller, John [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Tuesday, April 10, 2001 11:20 AM 
To: Singatwaria, Sundeep [SC7:370-M:EXCH]; [email-masked]' 
Subject: RE: RPF neighbor 

SS>Sundeep

---

From: "Sundeep Singatwaria" <[email-masked]>
Date: Tue, 10 Apr 2001 21:12:25 -0700

-----Original Message-----
From: Moeller, John [mailto:[email-masked]]
Sent: Tuesday, April 10, 2001 2:00 PM
To: 'Brian Edwards'; [email-masked]'
Subject: RE: RPF neighbor

Brian, 

Are u proposing there shouldn't be any traffic engineering stuff for
multicast. BTW, OSPF TE extensions maintains more state info than vanilla
flavored OSPF.

Sundeep

John Moeller 
Firmware Engineer 
Salt Lake City Firmware 

[email-masked] <mailto:[email-masked]>  
www.enterasys.com