Re: [Softwires] Fw: New Version Notification fordraft-sarikaya-softwire-dslitemobility-00
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Softwires] Fw: New Version Notification fordraft-sarikaya-softwire-dslitemobility-00



Hi Yiu,


>
>From: Yiu L. Lee <yiu_lee at cable.comcast.com>
>To: Behcet Sarikaya <sarikaya at ieee.org>; softwires at ietf.org
>Sent: Wednesday, July 15, 2009 8:23:16 AM
>Subject: Re: [Softwires] Fw: New Version Notification fordraft-sarikaya-softwire-dslitemobility-00
>
>
>Hi Sarikaya,
>>
>>>- 3.1 Step 2. Since multiple MNs may use the same MAG to go to the same destination, the LMA can't search only the binding cache for the dst IPv4 address (128.0.0.1). Instead, the LMA must search the <MAG-IPv6-addr, MN-IPv4-addr, src-port, transport-protocol, dst-IPv4-addr, dst-port, transport-protocol> tuple.
>>>
>>
>>Binding cache and NAT state are two different types of states. Binding cache does not contain transport layer info you mentioned above and is searched first. Next NAT state is searched.
>>I hope this is clear, maybe we should make it more clear in the text.
>>
>>[YL] Finally I got a chance to read RFC5213. When the LMA created the binding cache for the MAG, wouldn’t the LMA create the binding cache based on the <MN-Identifier, MAG’s HA and MAG’s CoA>? I thought the binding cache is used for identifying which MN anchors to the LMA. Why does LMA need to search the dst-addr in the encapsulated IPv4 datagram in the binding cache?
>>

Thanks for checking this in detail.

This was to see if the packet has to be routed back down stream for local routing because the corresponding node could be connected to the same LMA. Not for anything else. Maybe we should add some text here to avoid confusion.


>>Thanks,
>>Yiu

Regards,

Behcet


     


Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.