Re: [Mipshop] Section 4.3.1 of draft-ietf-mipshop-transient-bce-pmipv6

["Laganier, Julien" <[e-mail]>]

Vijay Devarapalli wrote:
> 
> On 9/10/10 3:20 PM, Laganier, Julien wrote:
> > Vijay Devarapalli wrote:
> >>
> >> On 9/10/10 3:59 AM, Jari Arkko wrote:
> >>> Is some document change needed?
> >>
> >> Yes, IMO. Section 4.3.1 talks about the nMAG creating a transient
> BCE
> >> only if it knows the MN supports transient BCE. Two issues with this.
> >>
> >> 1. If its a single radio handover, nothing needs to be supported on
> the
> >> MN. Just whatever is needed according to RFC 5213.
> >>
> >> 2. For a dual radio handover, to get the true benefit from transient
> >> BCE, the MN needs to be able to receive packets on two interfaces at
> >> the same time for a short while. If it does not do this, transient
> BCE
> >> would still work, and the MN does benefit, but there will be some
> packet loss.
> >>
> >> This is not really captured in the draft.
> >>
> >> For the actual text changes, it is going to be hard for me to
> suggest
> >> text changes since its been a year since I read the draft. I have to
> go
> >> through it again. Marco would probably be able to come up with text
> >> changes much more quickly.
> >>
> >> Perhaps we should add a section on the mobile node support for
> >> transient BCE and explain clearly what needs to be supported on the
> >> mobile node.
> >
> > All of the NETLMM work has happened under the premise that the host
> > is unmodified, and NETEXT has pushed this a bit further with only
> > mandating that the IP stack is unmodified, e.g., quoting current NETEXT
> > charter:
> >
> >    The work in this charter is entirely internal to the network and does
> >    not affect host IP stack operation in any way (except perhaps through
> >    impacting packet forwarding capacity visible to the hosts). The working
> >    group is not allowed to specify new IP layer protocol mechanisms to
> >    signal mobility related events between the host and the network.
> >
> > We should adhere to the same guidelines in this situation.
> 
> I wasn't suggesting otherwise.
> 
> > Thus the only way for the BCE to work in the dual radio case is to
> > have a logical interface that hides to the IP layer the two physical
> > interfaces, as described in this draft from the NETEXT WG:
> 
> No, that goes too far. The Netext logical interface is *one* way to do
> it.

Clarifying: I am not saying a logical interface is the only way for BCE to work with dual interfaces. One could of course modify an IP stack to get it to work. All I'm saying is that, to the extent that the IP layer is unmodified, you need a logical interface to hide the two physical interfaces for BCE, otherwise it can't work with a generic IP stack. 

> > http://tools.ietf.org/html/draft-ietf-netext-logical-interface-support
> >
> > Thus we should add to the BCE draft a sentence that explains that for
> > BCE to be beneficial in dual radio case it requires support for the
> > logical interface, and reference the NETEXT draft.
> 
> Fine with me. But we should avoid a normative dependency to this draft,
> mainly based on the fact that it is just one way to hide the two
> physical interfaces.

Clarifying: I wasn't suggesting to add a normative dependency to the draft -- the logical interface draft is not normative anyway, it is meant to become an informational document that explains the requirements that needs to be satisfied when designing a logical interface. 

--julien