Re: [Seamoby] comments on the paging protocol assessment draft

["James Kempf" <[e-mail]>]

Hi Yoshi,

> Additional comments are in-line.  Note that I'm not objecting the
> selection since it would be better to be constructive, but just to
> make things clearer and have a correct understanding of the result
> as much as possible.
>

I understand.

> As assessment team correctly evaluated,
> draft-ohba-seamoby-last-hop-dmha-02.txt also satisfies independency
> from mobility protocol.
>

Yes.

> draft-ohba-seamoby-last-hop-dmha-02.txt also satisfies indepenency of
> paging area from subnet topology, but unfortunately the selection team
> seems to misunderstand that the protocol does not satisfy this
> requirement, which I also pointed out this both on the mike in the SLC
> meeting and in my comments posted before the SLC meeting.  Actually,
> we paid a special care on this point, for example we explitly
> mentioned in the draft that:
>
>    Paging Area
>
>      (snip)
>
>      An arbitrary mapping between subnets and paging areas is allowed
in
>      this protocol.
>

But do you think it is realistic to expect the paging team to rate
the design based on this single sentence when the name of the protocol
implies a connection between the subnet and paging area, and the
rest of the design is described in terms of having a paging agent (which
controls the paging area) in the last hop subnet?

> Jim also mentioned in the SLC meeting that our protocol requires
> extranous signaling (among separate agents), which is not desirable.
> This is not exactly correct because our protocol allows elimination of
> extranous signaling by implementing those agents in a single box (for
> small size networks).  Extranous signaling is inevitable if
> scalability matters.  For the same reason, extranous signaling is also
> described in the selected protocol if PA is hierachically configured.
> There is always tradeoff between scalability and centralized agent.
>

Exactly what functional elements to group into a network element
is a design, not an implementation, choice. The draft-ohba design chose
a one to one mapping between functional elements and network
elements. While it is certainly possible to deploy by bundling
multiple network entities on a single host, the interface between
the entities, and thus the protocols on those interfaces, remain
as does the potential for extraneous signaling.

That said, I agree that it is certainly a challenge to come up with
a design that minimizes signaling, and I think that, going
forward, we need to keep this in mind.

> Jim also mentioned in the SLC meeting that our protocol does not
> support time-slotted dormant mode at L3.  This is true, but
> time-slotted dormant mode at L3 was not explicitly described in the
> requirements document, and I don't think the basic issue of how to
> synchronize at L3 can be solved by just definig a set of
> synchronization timing parameters.  Additional consideration of
> hardware-based IP-paging implementation and interference with other
> traffic, etc. would be still necessary if we really want to archive
> it.
>

The requirements do call out the need to support multiple dormant
modes, and that requires the ability to support time-slotted paging.
For example, draft-sarikaya has a good description of how
to support time-slotted paging. I recall having discussed this
in the requirements phase, but perhaps we should have been
clearer in the requirements document about what support for multiple
dormant modes means.


            jak


_______________________________________________
Seamoby mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/seamoby