Re: [MEXT] TLV header in DSMIP

["Sri Gundavelli" <sgundave at cisco.com>]

> >  After the signaling is complete, there should be tunnel encaps
> >  with proper UDP port numbers on both ends for sending the data
> >  traffic. If we treat them separate, how does the HA know what
> >  encap to use for the initial traffic comming from the CN towards
> >  the MN (Note that the signaling is complete and there is a NAT
> >  state for the signaling flow and no data traffic yet from the
> >  MN and so there is no NAT state for the second flow). MN is
> >  behind a NAT and so the trigger needs to come from the MN for
> >  the second flow.
> >
> 
> GT> Yes, which means that the MN must immediately start sending
> keepalives for the data traffic i.e., to the DSMIPv6 port number. This
> allows the tunnel to be open for outgoing as well as incomming
> sessions. The draft has language to this effect already.
> 

I will take a look at the draft again, I missed this language.
Also, requires some text in Security Considerations (quite a bit
of text in 3519 related to this, it has the "R" bit support and
the HA keeps the tunnel in half-created state .. very similar).
Need to understand the implications of this ...



> >  Secondly, if the two flows are not tied, how does keepalive
> >  messaging work for keeping the NAT states active ? Will there be
> >  two NAT keepalive messaging for both the flows ?
> >
> 
> GT> If both of the flows need to be maintained then I think we need
> two keepalives. It is not clear to me, however, why we need to
> maintain the signaling flow in that case, since we might not have to
> send another BU for hours; or am I missing something?

All along during DSMIP6 discussions, the general though from the
Authors was that we dont need a seperate KA mechanism, we can very
well use BU/BA and that changes now. If we dont keep the NAT mapping
active for the  control flow, HA cannot send any asynchronous events
such as  Revocation or Notification events.




> GT> In any case the cost of two keepalives is probably lower than the
> cost of turning on encryption which then only requires a single
> keepalive. Also note that sending two keepalives is not that bad for
> the MN since most of the cost of keepalives is in the fact that the MN
> must come out of sleep mode to transmit something. Once the MN wakes
> up, transmitting one vs two small packets makes little difference.
> There is of course processing cost at the HA side to consider too.
> 

Sure, there needs to be two keepalives. One in control and the
other in data plane. I assume the KA for control is still BU/BA ?
For data flow, how will this be achieved ?


> >  Also, the two flows needs to be tied for removing the data path
> >  upon terminating the MIP session.
> >
> 
> GT> Yes I think they are still tied in the HA based on the HoA, no?
> 

HoA is just a route over the tunnel. The tunnel endpoints with
src/dest address and port numbers, needs to be reflected in the
BCE. Implementation wise, its very difficult to locate a tunnel
by looking at the routing table.

Sri

_______________________________________________
MEXT mailing list
MEXT at ietf.org
https://www.ietf.org/mailman/listinfo/mext