Draft: draft-ietf-taps-impl

Commentary: This is a first attempt to work on the section " Handling Path Changes " ( see issue ) , however , I think more work is needed . To be honest I do n't fully understand this part and it would be could if someone else could provide more input about the System Policy part : " For protocols that do not support multipath or migration , the Protocol Instances should be informed of the path change , but should not be forcibly disconnected if the previously used path becomes unavailable . An exception to this case is if the System Policy changes to prohibit traffic from the Connection based on its properties , in which case the Protocol Stack should be disconnected . " Also the last part about pooled connection should say more but I 'm not sure what . We currently have now only this sentence left : " Pooled Connections { { pooled - connections } } may add or remove underlying transport connections in a similar manner . " And finally the originally issue was also mentioning fallback which I did n't address yet but I have this feeling that that might need a separate section . Should I add a separate issue for that or is that already addressed somewhere and I missed it ? 
 II like your change - makes the text much clearer . 
 : Is the path change problem resolved here - there 's been stuff on paths and policy since this . 
 Section 7.2 on Handling Path Changes in the implementation draft needs to be better aligned to the interface we are currently still discussing for multipath protocols . Currently it reads like an taps implementation can freely decide which paths to use when . That 's probable not the case but in any case needs also more specific guidance . However , we probably need to leave this issue as a reminder for later when we have decided on the final interface for MP protocols . I would eventually like to separate sections for handover ( two parallel paths ) , migration ( move from one to the other but keep same protocol instance ) and fallback ( move form one protocol instance to another ) .
Paragraph (version A):
When a path change occurs, the Transport Services implementation is
responsible for notifying Protocol Instances in the Protocol Stack.
If the Protocol Stack includes a transport protocol that supports
multipath connectivity, an update to the available paths should
inform the Protocol Instance of the new set of paths that are
permissible based on the Selection Properties passed by the
application.  A multipath protocol can establish new subflows over
new paths, and should tear down subflows over paths that are no
longer available.  Pooled Connections pooled-connections may add or
remove underlying transport connections in a similar manner.  If the
Protocol Stack includes a transport protocol that does not support
multipath, but support migrating between paths, the update to
available paths can be used as the trigger to migrating the
connection.  For protocols that do not support multipath or
migration, the Protocol Instances may be informed of the path change,
but should not be forcibly disconnected if the previously used path
becomes unavailable.  An exception to this case is if the System
Policy changes to prohibit traffic from the Connection based on its
properties, in which case the Protocol Stack should be disconnected.
Paragraph (version B):
When a path change occurs, e.g., when the IP address of an interface
changes or a new interface becomes available, the Transport Services
implementation is responsible for notifying the application of the
change.  The path change may interrupt connectivity on a path for an
active connection or provide an opportunity for a transport that
supports multipath or migration to adapt to the new paths.
Paragraph (version B):
For protocols that do not support multipath or migration, the
Protocol Instances should be informed of the path change, but should
not be forcibly disconnected if the previously used path becomes
unavailable.
Paragraph (version B):
If the Protocol Stack includes a transport protocol that also
supports multipath connectivity with migration support, the Transport
Services implementation should also inform the Protocol Instance of
potentially new paths that become permissible based on the Selection
Properties passed by the application.  A protocol can then establish
new subflows over new paths while an active path is still available
or, if migration is supported, also after a break has been detected,
and should attempt to tear down subflows over paths that are no
longer used.  The Transport Services API provides an interface to set
a multipath policy that indicates when and how different paths should
be used.  However, detailed handling of these policies is still
implementation-specific.  The decision about when to create a new
path or to announce a new path or set of paths to the remote
endpoint, e.g., in the form of additional IP addresses, is
implementation-specific or could be be supported by future API
extensions.  If the Protocol Stack includes a transport protocol that
does not support multipath, but does support migrating between paths,
the update to the set of available paths can trigger the connection
to be migrated.
Paragraph (version B):
In case of Pooled Connections pooled-connections, the transport
system may add connections over new paths or different protocols to
the pool if permissible based on the multipath policy and Selection
Properties.  In case a previously used path becomes unavailable, the
transport system may disconnect all connections that require this
path, but should not disconnect the pooled connection object exposed
to the application.  The strategy how is implementation-specific, but
should be consistent with the behavior of multipath transports.