![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
Marc Blanchet escribió:
marcelo bagnulo braun a écrit :Scott Brim escribió:Excerpts from marcelo bagnulo braun on Thu, Jan 29, 2009 09:09:55PM +0100:makes sense to me Marc Blanchet escribió:to me, the main difference is that the 'multiple interface' issue is not bound to mobility, and more specifically to mobility protocols (mobileIPv4, mobileipv6, nemo, ...). Therefore, the MIF work is not scoping about mobility protocols and shall not require mobility protocols. I would see that if some part of the MIF work is looking at the mobility protocols, then these should be then "transfered" to MEXT.Even without mobility considerations, the issue of how to handle multiple interfaces overlaps with IntArea, RRG, and Behave (those are the ones I can think of offhand). Have you seen the arguments, for example, about session initialization when multiple addresses can be in play simultaneously at both ends? I apologize but I still don't understand the MIF boundaries.I wrote a draft a long time ago about the problems for selecting the source address in multiaddressed hosts, not sure if this is related to what you asking about... you can check it at http://www.watersprings.org/pub/id/draft-bagnulo-6man-rfc3484-update-00.txtthere is an address selection design team that is looking at this currently.
mmm, not reallymaybe i missing somehting, but i understnad that the scope of the design team is limited to the automatic update of the rfc3484 policy table, and they are not dealing with the issue of how the properly select the source address, for instance, in the case that you need to retry due to ingress filtering and the like
regards, marcelo
Marc.regards, marceloThanks ... Scott
_______________________________________________ MEXT mailing list MEXT at ietf.org https://www.ietf.org/mailman/listinfo/mext