Re: [DMM] New DMM draft: draft-bernardos-dmm-distributed-anchoring-00.txt
Carlos, please see inline. -Original Message- From: Carlos Jesús Bernardos Cano [mailto:c...@it.uc3m.es] Sent: Sonntag, 18. März 2012 20:59 To: Marco Liebsch Cc: dmm@ietf.org Subject: RE: [DMM] New DMM draft: draft-bernardos-dmm-distributed- anchoring-00.txt Hi Marco, Thanks for your comment. Please see inline below. On Fri, 2012-03-16 at 10:00 +, Marco Liebsch wrote: Carlos, thanks for your feedback. Please see inline. -Original Message- From: Carlos Jesús Bernardos Cano [mailto:c...@it.uc3m.es] Sent: Freitag, 16. März 2012 09:51 To: Marco Liebsch Cc: dmm@ietf.org Subject: RE: [DMM] New DMM draft: draft-bernardos-dmm-distributed- anchoring-00.txt Hi Marco, Apologies for the late reply. Thanks for reading the draft. Please see some answers to your questions/comments inline below. On Fri, 2012-03-09 at 11:51 +, Marco Liebsch wrote: Hi Carlos, I have a few clarifying questions to your new draft. The draft proposes the distributed logical interface. I don't really get the advantage of virtualizing the previous LMA on the MN's current LMA if packets are routed through the previous LMA anyway. Why not using the current LMA to serve simply as MAG for forwarded traffic (which remains anchored at previous LMA) and using the new LMA to anchor the new address/prefix? What you just mention is exactly what the draft does. Additionally, the logical interface simplifies the interface between the MN and the access router that behaves as LMA/MAG. It does so because by interacting with the MN as different logical routers (one per anchoring LMA), you can make full use of the ND based features (e.g., RFC4191) in a very easy way. The draft writes that the idea hides the change of the anchor from the mobile node. The DGW2IF on the new LMA does not pretend to be LMA1, or? I don't see how the anchor change is kept transparent to the MN. The point is that from the point of view of the MN, it always sees as directly connected (1-hop away) each of the anchor LMAs. Every time the MN moves and attaches to a new access router, the only thing it notices is that a new (logical) router appears on the link, advertising a new prefix (and, in most use cases, the others start advertising the prefixes with lifetime=0 to deprecate them). The LMA function should be transparent to the MN anyway, so it does not matter whether the LMA, which serves as anchor, is on the previous AR or on the current one. Invalidating the previous HNP and validating the new HNP can be done independently of whether the responsible LMA instance is co-located with the local AR or the previous AR. But I must admit that I probably have to check that part of your draft again. If it just invalidating the prefix, this can be done, true. But the point is that the DLIF concept enables to do more that just invalidating a prefix. Besides, it makes easier to implement this prefix deprecation. Ok, I'll check the description to better understand the DLIF function. I somehow agree also to Pete's opinion that solving the packet routing after anchor relocation above the anchors is a good option. It simply allows more optimal routes. I have to read his draft, but unless you have control on the routing infrastructure (and this is not always possible, and it takes time to converge), I don't see many other options to ensure address continuity. I don't expect this to take long time, as the routing states are not to be enforced in all routers, at least not in our proposal. Intention is to keep the routing plane as it is and update states only is one dedicated router per data session, which translates the MN's IP address into a routable one to ensure that remaining routers in the network forward the downlink packet to the MN's current anchor point. The previous anchor point is released from any forwarding tasks. Further advantage is that routes are potentially more optimal compared to forwarding from a previous anchor. Which does not mean that both approaches cannot co-exist. A DMM solution could rely on forwarding while the state in the routing plane is established. I have to admit I haven't checked your proposal yet. No problem ;-) What you mention seems like a NAT-based approach, is it true? We propose NAT to save per-packet overhead and use the prefix/IP address being assigned and anchored at the new anchor as locator, which intrinsically has identifier information. So, reverse NAT on the new anchor is easily possible. But that's not the key of the approach, as NAT can be easily replaced by IP tunnels. The key approach is to solve DMM in the routing plane above anchors while using the existing routing plane. and if there is a dedicated router, isn't it a centralized entity? It's exactly the
Re: [DMM] New DMM draft:draft-bernardos-dmm-distributed-anchoring-00.txt
Hi Pierrick, I agree that this is an interesting approach from research point of view. The question is how practical this is. Intelligence on the MN is ok, but to take a decision about which IP address to use, the MN needs information. If information is solely a binding between the prefix and the level of the associated anchor in a hierarchy of anchors, then the MN may select a prefix/address according to the expected IP session duration to avoid a change in the topological anchor of the used IP address. Taking such decision requires also some information about the topology, which I doubt operators will reveal. Important here is the location of the anchor and the location of the used serving point. Latter could be a public Internet service, hence knowledge of the operator's IX peering points may be relevant. If the serving point is operator CDN-like, typically the MN is served by transparent caching, hence, the location of the cache is not known to the MN. A different and pragmatic approach is to select the closest anchor point to serve any IP session of the UE and to provide a good solution to handle routing after anchor relocation plus renewal of the MN's IP address from time to time. IMO, such approach enables short routing paths between any source and the MN while offloading traffic from the core network as its best. marco -Original Message- From: pierrick.se...@orange.com [mailto:pierrick.se...@orange.com] Sent: Montag, 19. März 2012 11:17 To: jouni.nos...@gmail.com; c...@it.uc3m.es; Marco Liebsch Cc: dmm@ietf.org Subject: RE: [DMM] New DMM draft:draft-bernardos-dmm-distributed- anchoring-00.txt I think it is worth to work on solution providing more information on the type of address. IMHO, it is a requirement for the UE to play with more than one IP address and select the more appropriate source address according the topological anchor point. DMM is clearly one use-case but, this feature is also required for offload purpose in current centralized network based mobility. The ongoing proposals for RA extensions, that allow to distinguish anchored from local prefix, are interesting. Now, the UE shall have the intelligence to make the source address selection according to prefix properties; at least extensions to RFC3484 may be defined but more sophisticated selection behavior may be required, typically, policies based selection, e.g. offload policies. Pierrick -Message d'origine- De : dmm-boun...@ietf.org [mailto:dmm-boun...@ietf.org] De la part de jouni korhonen Envoyé : dimanche 18 mars 2012 21:47 À : Carlos Jesús Bernardos Cano; Marco Liebsch Cc : dmm@ietf.org Objet : Re: [DMM] New DMM draft:draft-bernardos-dmm-distributed- anchoring-00.txt So you think that the UE should receive multiple IP addresses and treat them differently according to the associated topological anchor point? Hmm, yes, possible. What about real time streaming and other IP data sessions, which could have a longer lifetime, they should be anchored than at a central point as well, right? If the MN had such intelligence and information, it could treat the HNPs differently, true. I think thank kind of approaches make sense. There are a couple proposals on table that go into this direction. We put those under addressing enhancements slot. Basically piggybacking anchoring properties of a prefix along with address configuration. - Jouni Carlos marco ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] New DMM draft:draft-bernardos-dmm-distributed-anchoring-00.txt
Pierrick, On Mar 19, 2012, at 12:16 PM, pierrick.se...@orange.com pierrick.se...@orange.com wrote: I think it is worth to work on solution providing more information on the type of address. IMHO, it is a requirement for the UE to play with more than one IP address and select the more appropriate source address according the topological anchor point. DMM is clearly one use-case but, this feature is also required for offload purpose in current centralized network based mobility. The ongoing proposals for RA extensions, that allow to distinguish anchored from local prefix, are interesting. Now, the UE shall have the intelligence to make the source address selection according to prefix To me offloading and DMM go hand in hand, since how the current charter is described emphasizes the use of CoAs (could be the local prefix). With some care, solutions developed in DMM space apply to both. At least this is what I want to see to happen. properties; at least extensions to RFC3484 may be defined but more sophisticated selection behavior may be required, typically, policies based selection, e.g. offload policies. For example, draft-korhonen-dmm-prefix-properties discuss briefly how to hook into RFC3484bis (and even to RFC3484). The text superseding source address selection Rule 8: Rule 8 may be superseded if the implementation has other means of choosing among source addresses. For example, if the implementation somehow knows which source address will result in the best communications performance. is especially a good fit here. - Jouni Pierrick -Message d'origine- De : dmm-boun...@ietf.org [mailto:dmm-boun...@ietf.org] De la part de jouni korhonen Envoyé : dimanche 18 mars 2012 21:47 À : Carlos Jesús Bernardos Cano; Marco Liebsch Cc : dmm@ietf.org Objet : Re: [DMM] New DMM draft:draft-bernardos-dmm-distributed- anchoring-00.txt So you think that the UE should receive multiple IP addresses and treat them differently according to the associated topological anchor point? Hmm, yes, possible. What about real time streaming and other IP data sessions, which could have a longer lifetime, they should be anchored than at a central point as well, right? If the MN had such intelligence and information, it could treat the HNPs differently, true. I think thank kind of approaches make sense. There are a couple proposals on table that go into this direction. We put those under addressing enhancements slot. Basically piggybacking anchoring properties of a prefix along with address configuration. - Jouni Carlos marco ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] New DMM draft:draft-bernardos-dmm-distributed-anchoring-00.txt
-Message d'origine- De : jouni korhonen [mailto:jouni.nos...@gmail.com] Envoyé : lundi 19 mars 2012 11:59 À : SEITE Pierrick RD-RESA-REN Cc : c...@it.uc3m.es; marco.lieb...@neclab.eu; dmm@ietf.org Objet : Re: [DMM] New DMM draft:draft-bernardos-dmm-distributed- anchoring-00.txt Pierrick, On Mar 19, 2012, at 12:16 PM, pierrick.se...@orange.com pierrick.se...@orange.com wrote: I think it is worth to work on solution providing more information on the type of address. IMHO, it is a requirement for the UE to play with more than one IP address and select the more appropriate source address according the topological anchor point. DMM is clearly one use-case but, this feature is also required for offload purpose in current centralized network based mobility. The ongoing proposals for RA extensions, that allow to distinguish anchored from local prefix, are interesting. Now, the UE shall have the intelligence to make the source address selection according to prefix To me offloading and DMM go hand in hand, since how the current charter is described emphasizes the use of CoAs (could be the local prefix). With some care, solutions developed in DMM space apply to both. At least this is what I want to see to happen. I couldn't agree more. Pierrick properties; at least extensions to RFC3484 may be defined but more sophisticated selection behavior may be required, typically, policies based selection, e.g. offload policies. For example, draft-korhonen-dmm-prefix-properties discuss briefly how to hook into RFC3484bis (and even to RFC3484). The text superseding source address selection Rule 8: Rule 8 may be superseded if the implementation has other means of choosing among source addresses. For example, if the implementation somehow knows which source address will result in the best communications performance. is especially a good fit here. - Jouni Pierrick -Message d'origine- De : dmm-boun...@ietf.org [mailto:dmm-boun...@ietf.org] De la part de jouni korhonen Envoyé : dimanche 18 mars 2012 21:47 À : Carlos Jesús Bernardos Cano; Marco Liebsch Cc : dmm@ietf.org Objet : Re: [DMM] New DMM draft:draft-bernardos-dmm-distributed- anchoring-00.txt So you think that the UE should receive multiple IP addresses and treat them differently according to the associated topological anchor point? Hmm, yes, possible. What about real time streaming and other IP data sessions, which could have a longer lifetime, they should be anchored than at a central point as well, right? If the MN had such intelligence and information, it could treat the HNPs differently, true. I think thank kind of approaches make sense. There are a couple proposals on table that go into this direction. We put those under addressing enhancements slot. Basically piggybacking anchoring properties of a prefix along with address configuration. - Jouni Carlos marco ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
