Subject: RE: ingress filtering for (n,n,n) (was Re: [nemo] Charter proposal

From: "Vijay Devarapalli" <[email-masked]>
Date: Tue, 4 Apr 2006 16:01:54 -0700

Chan Wah presented a bunch of slides at the last
IETF, explaining what needs to be done in the
NEMO WG and Monami6 WG when it comes to multihoming.

see the following URL.
http://www3.ietf.org/proceedings/05nov/slides/nemo-2/sld6.htm

I think thats what the following means.

> Aug 2006		Submit -00 draft on (n,n,n) ingress filtering

Vijay

> -----Original Message-----
> From: marcelo bagnulo braun [mailto:[email-masked]] 
> Sent: Tuesday, April 04, 2006 3:53 AM
> To: T.J. Kniveton
> Cc: ml-nemo WG
> Subject: ingress filtering for (n,n,n) (was Re: [nemo] 
> Charter proposal
> 
> Hi all,
> 
> In the proposed nemo charter, there is a bullet stating:
> 
> Aug 2006		Submit -00 draft on (n,n,n) ingress filtering
> 
> I am not sure i understand this point.
> I don't think that  there is much nemo specific in the ingress 
> filtering problem itself
> OTOH, i think that the interesting problem to deal with in nemo 
> multihoming is how to provide an optimization for the provision of 
> fault tolerance in the link between the MR and the AR (or the HA)
> 
> I mean, an important different between the nemo multihoming and the 
> general site multihoming scenario, is that  failures are much more 
> likely to occur in the link between the MR and the AR (or the HA). So 
> haivng special tools to deal with this case would be a useful 
> optimization imho
> The nemo multihoming analysis draft presents one of such solutions in 
> the Appendix B and as i have mentioned already, imho the presented 
> soilution has enough merits to be desribed in a separate draft. 
> However, i don't see this as an ingress filtering solution, 
> but rather 
> an optimization for the fault tolerance support for the most common 
> case of failure. It should be noted that the solution 
> presented in the 
> appendix does not requires new protocol extensions, but it would be 
> more a informational work afaict
> 
> so, not sure what you have in mind with this bullet but i 
> would suggest 
> to reword it into something like
> Nemo multihoming support Optimizations for MR-AR link fault tolerance 
> or something more readable but with this ideas.
> 
> Regards, marcelo
> 
> 
> El 24/03/2006, a las 22:27, T.J. Kniveton escribió:
> 
> > Here is a starting point for charter update. Please send 
> your comments.
> >
> > TJ
> > <charter2.txt>
> 
>

---

From: Chan-Wah Ng <[email-masked]>
Date: Wed, 05 Apr 2006 11:49:31 +0800

Hello all,

Thanks Vijay.  I am certain that's what TJ have in mind when he placed
in that bullet.

In fact, if you read through the appendix B in
draft-ietf-nemo-multihoming, you will find that the mechanism described
can be used to overcome ingress filtering problem as described in 4.2,
although it is worded as a fault tolerance solution.  Ingress filtering,
is in fact main obstacle for fault tolerance in NEMO. 

Having said that, I do agree with marcelo on the rewording of the
charter though.  It would make it specific to NEMO, and raise less
concern for work scope overlaps in WGs.

/rgds
/cwng

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 5 Apr 2006 13:37:00 +0300

> is in fact main obstacle for fault tolerance in NEMO.

i guess this is the point we disagree

imho fault tolerance support presents several difficulties, being 
ingress filtering one of them, but not sure the most importnat one. And 
i think that the solution presented in appendix B addresses soem of the 
difficulties, including ingress filtering but more than that

I mean, consider the case of incoming traffic. In this case, there is 
absolutelly no issues with ingress filtering, right?

However, there are still issues with the multiprefix configuration, 
since packets addressed to a given prefix, will be routed towards a 
given HA. So, in this case we need that the HA reroute the packets 
through the alternative HA, so that packets can be delivered to the 
nemo. This is what is done in the solution of appendix B if i remember 
correctly, but this has no relation with ingress filtering.

So, my point is that the problem that needs to be addressed is the 
general problem of providing fault tolerance support for the case that 
the failure affects the MR - HA links. this is an optimization of the 
general fault tolerance for multihomed nemo support, but it makes sense 
to optimize it because seems to be a quite common type of failure imho

Regards, marcelo

---

From: Chan-Wah Ng <[email-masked]>
Date: Wed, 05 Apr 2006 18:59:54 +0800

Hello, Marcelo,

> absolutelly no issues with ingress filtering, right?

True.

> correctly, but this has no relation with ingress filtering.

This is going deeper than the scope of the original thread, but this
rerouting of packet through the alternative HA is done transparently to
the original HA.

> to optimize it because seems to be a quite common type of failure imho
Again, true.

I have no disagreement with what you pointed out, but for the sake of
discussion, I like to point out a few things:

(1) By definition of ingress filtering, the problem will only occur from
the direction of MNN towards CN, not the other way round.

(2) In this direction, ingress filtering pose a significant, if not the
most, problem for fault tolerance to work.

(3) A solution which provides fault tolerance capability to a (n, n, n)
network can be easily used to overcome ingress filtering problem even if
there is no fault.

/rgds
/cwng

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 5 Apr 2006 14:08:27 +0300

El 05/04/2006, a las 13:59, Chan-Wah Ng escribió:

> the direction of MNN towards CN, not the other way round.

agree that is why i described the difficulties in the provision of  
fault tolernce in this direction, to show that there are relevant  
issues that have no relation with ingress filtering :-)

> most, problem for fault tolerance to work.

well, i guess that the most important issues are posed by failures,  
rather that filters :-)

I mean, in the case of filters, you already know what is wrong and what  
needs to be done in order to make it work. I mean, you can think of  
much more general solutions to the ingress filtering problem, like the  
ones described in  
http://www.watersprings.org/pub/id/draft-huitema-shim6-ingress- 
filtering-00.txt

This approach allows to send the packets through the correct exit  
router, so no problems will occur with ingress filters.

however, such approach is not good enough to deal with failures.
This is because we don't know when failures occur and we need to  
reroute packets through alternative ISPs which do not match with the  
prefix included in the source address.
I mean, if we want to provide ingress filtering capability, we can do  
two things: i) allow that packets with an alternative prefix in the  
source address get routed through an HA/ISP that has not delegated the  
prefix in the source prefix or ii) make sure that  packets are always  
routed through the correct HA/ISP.

However, if you want to deal with failures, the ii) option is no longer  
avialble, and only i) is possible since the original HA/ISP is no  
longer there. That is why i think that ingress filtering is just one  
piece of the faul tolerance provision, and the real problem is fault  
tolerance as a whole

> network can be easily used to overcome ingress filtering problem even  

agree, but the other way around is not true. I mean a solution that  
provides ingress fitlering capability may not provide fault tolerance,  
see  
http://www.watersprings.org/pub/id/draft-huitema-shim6-ingress- 
filtering-00.txt

regards, marcelo