Subject: Re: [netlmm] Scope of revised charter: MN impact

From: "Koodli, Rajeev" <[email-masked]>
Date: Wed, 18 Jun 2008 18:14:16 -0400

Hi Raj,

I too can imagine scenarios where you could get benefits. However, I am
not clear about the following:

Whether providing such functionality at the IP layer will actually be
used. I am not questioning the usefulness, but whether it will be
over-ridden by the functionality, if needed, at the lower layers. 

>As an example the ability of the host to parse an RA and understand a
PMIP6
> prefix vs a Local one. This is a small enhancement to the MNs IPv6
stack. 

[RKo:>] I am curious why NETLMM would be a good place for this
scenario.. We _could_ consider such issues, perhaps in a separate WG,
IMO. In fact, we could consider "network-mobility optimizations" as a
whole for such a WG.

Regards,

-Rajeev

>But it
> does enable the host to realize the access routers capability as well
as
> in
> making a choice of mobility mode.
> 
> So I believe that the Netlmm charter should change its perception of
not
> making any changes to the host as being sacred. Because some minimal
> changes
> are useful to the protcols efficient operation.
> 
> -Basavaraj
> 
> 
> On 6/17/08 5:27 PM, "Sri Gundavelli" <[email-masked]> wrote:
> 
> > Hi Charlie,
> >
> > The broad goal is not to involve the client in mobility
> > management signaling. The examples cited here all confirm
> > to this goal. Providing certain hints, to the client
> > either in the form of RA's or through other mechanisms
> > only to improve either the clients ability to make a better
> > decision or for the network to understand the clients
> > intent, are just optimizations. This cannot be a difficult or
> > a controversial decision. We all can differentiate between a
> > an optimization vs what is a client equivalent functional
> > addition to the host.
> >
> >>
> >> I was going to ask how many blind rules we should have,
> >> but then I thought maybe some people would not find it
> >> to be very funny.  Nevertheless, I'd like to find out how
> >
> > :)
> >
> >> an impartial observer could distinguish between a blind
> >> rule and charter mandate.
> >
> > This is clearly the job of the chairs and the AD. They will
> > ensure new proposals meet this criteria.
> >
> >
> > Regards
> > Sri
> >
> >
> >
> >
> > On Tue, 17 Jun 2008, Charles E. Perkins wrote:
> >
> >>
> >> Hello Sri,
> >>
> >> It seems to me that you have certain strong ways of
> >> classifying which changes are legitimate, based on
> >> whether they affect the client's "stack".  Can you be
> >> a bit more specific about this?  How can I tell whether
> >> something affects the "stack"?  Will all such client
> >> signals be handled over some UDP, TCP, or SCTP
> >> port?
> >>
> >> Regarding:
> >>
> >>>        .......      W.G should see the host stack changes
objectively
> >>>  and not go with one blind rule.
> >>
> >> I was going to ask how many blind rules we should have,
> >> but then I thought maybe some people would not find it
> >> to be very funny.  Nevertheless, I'd like to find out how
> >> an impartial observer could distinguish between a blind
> >> rule and charter mandate.
> >>
> >> Regards,
> >> Charlie P.
> >>
> >>
> >>
> >> Sri Gundavelli wrote:
> >>>  Hi Charlie,
> >>>
> >>>  The basic assumption of the NETLMM, the non-involvment of the
client
> >>>  in mobility signaling should always hold true. That requirement
> should
> >>>  not be relaxed. The protocol that is on the table today is
designed
> >>>  with that goal. All aspects of the protocol will function with
> >>>  absolutely zero changes to the host stack. This includes even the
> >>>  inter-technology handoff. There is some confusion that the
> requirement
> >>>  of virtual interface support on the host implies changes to the
host
> >>>  stack. That is absolutely not true, Ryuji and me will demonstrate
> this
> >>>  soon.
> >>>
> >>>  Now, w.r.t to the comment from Raj that we need allow changes to
> host.
> >>>  These changes are minor optimizations. Examples of such
optimizations
> >>>  include:
> >>>
> >>>  - The ability for the host and the access router to perform
> capability
> >>>    exchange
> >>>  - Prefix colouring, the ability for the host to distinguish
between
> >>>    a prefix that has mobility properties to a local prefix
> >>>  - Some minor SEND related extensions
> >>>  - Optimizations w.r.t DNA, for improving the handoff latency
> >>>
> >>>  None of this can be equated to a client stack requirement. These
fall
> >>>  in the scope of the general IPv6 host stack improvements and in
the
> >>>  context of NETLMM. W.G should see the host stack changes
objectively
> >>>  and not go with one blind rule.
> >>>
> >>>  Regards
> >>>  Sri
> >>>
> >>
> > _______________________________________________
> > netlmm mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/netlmm
> 
> _______________________________________________
> netlmm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netlmm
_______________________________________________
netlmm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netlmm

---

From: "Premec, Domagoj" <[email-masked]>
Date: Thu, 19 Jun 2008 11:29:58 +0200

Rajeev,

> Whether providing such functionality at the IP layer will 
> actually be used. I am not questioning the usefulness, but 
> whether it will be over-ridden by the functionality, if 
> needed, at the lower layers. 

The way I see it is that PMIP6 is a network feature at the IP layer and hence the capability to detect PMIP6 service should also be part of the IP layer. Having this information as part of the lower layer doesn't look like a clean layer separation. Another consideration is that lower layer approach means upgrading the existing L2 equipement in the network if the network chooses to make use of this functionality. By having it at the IP layer only the MAG is affected, which is a new node anyway. Modifying L2 also means that different SDOs will be repeating basically the same change.

domagoj

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Koodli, Rajeev
> Sent: 19. lipanj 2008 00:14
> To: Basavaraj Patil; Sri Gundavelli; Charles Perkins
> Cc: [email-masked]
> Subject: Re: [netlmm] Scope of revised charter: MN impact
> 
> 
> Hi Raj,
> 
> I too can imagine scenarios where you could get benefits. 
> However, I am not clear about the following:
> 
> Whether providing such functionality at the IP layer will 
> actually be used. I am not questioning the usefulness, but 
> whether it will be over-ridden by the functionality, if 
> needed, at the lower layers. 
> 
> [RKo:>] I am curious why NETLMM would be a good place for 
> this scenario.. We _could_ consider such issues, perhaps in a 
> separate WG, IMO. In fact, we could consider 
> "network-mobility optimizations" as a whole for such a WG.
> 
> Regards,
> 
> -Rajeev
> 
> 
> 
> 
> >But it
> > changes are useful to the protcols efficient operation.
> > 
> > -Basavaraj
> > 
> > 
> management 
> > > signaling. The examples cited here all confirm to this goal. 
> > > Providing certain hints, to the client either in the form 
> of RA's or 
> > > through other mechanisms only to improve either the 
> clients ability 
> > > to make a better decision or for the network to understand the 
> > > clients intent, are just optimizations. This cannot be a 
> difficult 
> > > or a controversial decision. We all can differentiate 
> between a an 
> > > optimization vs what is a client equivalent functional 
> addition to 
> > > the host.
> > >
> > >>
> but then I 
> > >> thought maybe some people would not find it to be very funny.  
> > >> Nevertheless, I'd like to find out how
> > >
> > > :)
> > >
> > >> an impartial observer could distinguish between a blind rule and 
> > >> charter mandate.
> > >
> > > This is clearly the job of the chairs and the AD. They 
> will ensure 
> > > new proposals meet this criteria.
> > >
> > >
> > > Regards
> > > Sri
> > >
> > >
> > >
> > >
> > >> It seems to me that you have certain strong ways of classifying 
> > >> which changes are legitimate, based on whether they affect the 
> > >> client's "stack".  Can you be a bit more specific about 
> this?  How 
> > >> can I tell whether something affects the "stack"?  Will all such 
> > >> client signals be handled over some UDP, TCP, or SCTP port?
> > >>
> > >> Regarding:
> > >>
> but then I 
> > >> thought maybe some people would not find it to be very funny.  
> > >> Nevertheless, I'd like to find out how an impartial 
> observer could 
> > >> distinguish between a blind rule and charter mandate.
> > >>
> > >> Regards,
> > >> Charlie P.
> > >>
> > >>
> > >>
> > >> Sri Gundavelli wrote:
> > >>>  Hi Charlie,
> > >>>