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

From: "Hancock, Robert" <[email-masked]>
Date: Wed, 30 Jul 2003 19:45:12 +0100

hi charles,

see below, marked [reh]

-----Original Message-----
From: Charles Q. Shen
To: Hancock, Robert; 'Xiaoming Fu'
Cc: 'Paulo Mendes'; [email-masked]
Sent: 30/07/2003 19:22
Subject: RE: [NSIS] mobility-related requirements from nsis-req-08

Hi Robert, a few comments.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Hancock, Robert
> Sent: Monday, July 28, 2003 11:27 AM
> To: 'Xiaoming Fu'
> Cc: 'Charles Q. Shen'; 'Paulo Mendes'; [email-masked]
> Subject: RE: [NSIS] mobility-related requirements from nsis-req-08
> 
> 
> hi xiaoming,
> 
> more clarifications (I hope):
> 
> > I followed up your previous mail regarding universe flow id because 
> > this is also (for both you and I) meant how to route the NSIS 
> > messages. Actually, in a previous version of fw draft it stated 
> > either way of using flow-id:
> >      *) Use a flow identification based on low level IP 
> > addresses (e.g.
> >     the Care of Address) and other 'standard' fields in the 
> IP header.
> >     This makes least demands on the packet classification
> > engines within
> >     the network. However, it means that even on a part of the 
> > flow path
> >     which is unchanged, the reservation will need to be modified to
> >     reflect the changed flow identification (see section 5.3.3).
> > 
> >      *) Use a flow identification that does not change
> (e.g. based on
> >     Home Address); this is the approach assumed in [23]. This 
> > simplifies
> >     the problem of reservation update, at the likely cost of
> > considerably
> >     complicating the flow identification requirements.
> 
> [reh] and what we are assuming is the first approach and not
> the second.
> 

Since the second approach seems to be referring to our RSVP-MIP draft, I
would like to make a slight clarification. The key point in that draft
is the necessity to keep a unique Identifier (which I called Flow
Identifer back then) during mobility, so that handoff signaling overhead
may be minimized. Using Home Address is one possibily to achieve that.
But the draft also mentioned other possibilities, such as using IPv6
flow label. 

[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.

A breif summary of my understanding so far is: 

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.

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.

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 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 and regards,

Charles

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

---

From: "Charles Q. Shen" <[email-masked]>
Date: Wed, 30 Jul 2003 15:52:28 -0400

Hi Robert, comments in the bottom marked [CS]

> From: Hancock, Robert [mailto:[email-masked]] 
> Sent: Wednesday, July 30, 2003 2:45 PM
> To: 'Charles Q. Shen '; Hancock, Robert; ''Xiaoming Fu' '
> Cc: ''Paulo Mendes' '; [email-masked] '
> > From: [email-masked] [mailto:[email-masked]] On Behalf Of 
> > Hancock, Robert
> > >     This makes least demands on the packet classification engines 
> > > within
> > [reh] and what we are assuming is the first approach and not the 
> > second.
> > 
> 
> Since the second approach seems to be referring to our 
> RSVP-MIP draft, I would like to make a slight clarification. 
> The key point in that draft is the necessity to keep a unique 
> Identifier (which I called Flow Identifer back then) during 
> mobility, so that handoff signaling overhead may be 
> minimized. Using Home Address is one possibily to achieve 
> that. But the draft also mentioned other possibilities, such 
> as using IPv6 flow label. 
> 
> [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 
> above distinction is to claim that the second is impossible 
> for fairly fundamental reasons.
> 

[CS] First, I completely agree with your view here. In fact I also
discussed briefly the control/data plane identifer distinction issue in
my later NSIS-mobility draft. 

Second (less important): the need for a unique identifier is still the
starting point of the "Home address" approach, not the other way around.
It was after that practice that the importance of separate views on
control/data plane identifers became very clear to me.

The rest all agreed and snipped :)

Thanks and regards,

Charles