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

[marcelo bagnulo braun <[e-mail]>]

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

>

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

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 :-)

> (2) In this direction, ingress filtering pose a significant, if not the
> 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

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

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

> /rgds
> /cwng
>
>> Regards, marcelo
>>
>>> 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
>>>
>>> On Tue, 2006-04-04 at 16:01 -0700, Vijay Devarapalli wrote:
>>>> 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:[e-mail]]
>>>>> 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>
>>>>>
>>>>>
>>>>
>>>
>>
>>
>