Subject: RE: [NSIS] mobility-related requirements from nsis-req-08

From: Marcus Brunner <[email-masked]>
Date: Tue, 05 Aug 2003 16:32:12 +0200

> 1. The identifier that should not change during mobilily (if there is
> one) is called the Session Identifier, while its detailed structure is
> still open.
> [reh] this is my view. designing it is an NTLP design matter (i.e.
> the framework at least will not comment further on it). i think this
> is generally agreed so far as it goes.
>

Yes, I think it is even a design requirement in the req draft.

> 2. The flow identifier is the low level identifier that is used to
> acutally route the packet at the NTLP level, its structure could contain
> IP 5-tuple, IPv6 flow label, or related IP fields.
> [reh] this is also my view. the precise definition is 'it has to contain
> whatever fields that are used by routers to route packets'. discussion
> post-Vienna on the mailing list implies to me that this is also generally
> agreed.

I think it is agreed not seen any objection.

 Marcus

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: Xiaoming Fu <[email-masked]>
Date: Wed, 13 Aug 2003 07:39:28 +0200

Hi,

(trying to follow up this thread and give short comments below:)

Hancock, Robert wrote:
(snip)
> [reh] your draft is certainly the one referred to, i have seen the
> same idea since in other places. the key distinction is
> whether the stable identifier is only in the control plane, and 
> you accept an update (probably end to end as well) in the data plane;
> or whether you attempt to put a stable identifier in the data plane 
> itself. You could try to use the HA (or something else) in either 
> place as part of the stable identifier, but the main point of the 
> above distinction is to claim that the second is impossible for
> fairly fundamental reasons.

My understanding is also that a seperation of control and data planes is 
of particular importance for NSIS.

(snip..)

> 3. The association of the two (layer split functionality, etc.) is still
> open.
> [reh] basically, yes. My current proposal is that the framework will
> explain the implications of the open-ness of this, but that the details
> will be worked out in 'later activities', i.e. individual mobility
> analysis work. The only thing I will assert is that the association
> machinery is in the NSLP rather than the NTLP - but we still don't
> really know what that machinery is.

I like your idea of keeping the open-ness of this. To sum up, it looks 
to me that mobility, even basic Mobile IP or Mobile IPv6, brings 
troubles in three main aspects: 1) change of end host address (CoA), 2) 
change of routing (in mobility agent and/or end hosts), while a 
"cross-over router" is actually the first NSIS hop where two routes 
diverges and needs to be discoverd correctly, 3) IP-in-IP encapsulation 
in the data path. 1) and 2) - already introduce various challenges - 
have been explored in many docs, while IMO the addition of 3) also 
contributes to the reasons why today's RSVP has not been extended by the 
IETF for operations in mobility scenarios. Probably we need to look at 
exact implications for NSLP/NTLP seperation in "later activities" (to 
which I am looking forward).

> 
> I think the framework draft already contains very good descriptions of
> the two IDs, but it would be helpful to document explicitly what are
> still open issues, either in that draft or somewhere else. 
> [reh] i hope this reply goes some way in that direction.

Thanks for your nice elaboration and hope this discussion helps for the 
next.

Cheers,
Xiaoming