Subject: [Mipshop] Last Call Comments on draft-ietf-mipshop-fast-mipv6-00.txt

From: おがわ <[email-masked]>
Date: Mon, 10 Nov 2003 11:53:50 +0900

Dear all,

I have three comments about FMIPv6 ID-00.
I would appreciate it if I hear your opinion on that.

1) In the case FMIPv6 is combined with advance DAD to reduce 
hand-over processing time, I suppose an NCoA (a pooled 
Duplicated-free address in the NAR) should be notified to 
the MN by an FBack message prior to its movement. However, 
on page 25 of FMIPv6 ID-00(mipshop), The Destination Address 
of an FBack message is noted "The NCoA".
I suppose the destination address of an FBack message shall 
be "the source address of the FBU message" to carry the 
message to the MN on the old link in such case. 

2) In the case of "predictive HO", I suppose a PAR had 
better start buffering when it receives an FBU message 
instead of a RtSolPr message to reduce buffering delay. 
So, I suppose If an MN knows it can send an FBU message 
prior to its movement, it should send a RtsolPr message with 
its U bit "off", and the PAR starts buffering when it 
receives an FBU message, and sends a HI message to the NAR 
with its U bit "on".

3)In the case the network notifies MNs of NCoAs with FBack 
messages, I suppose there should be some way to notify an MN 
by a PrRtAdv message that the NCoA will be notified by an 
FBack message. For example a new code of PrRtAdv or code "0", 
but NCoA=all "0".

Best regards,

Takeshi

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

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 11 Nov 2003 12:49:23 -0800

Hello Takeshi,

> message to the MN on the old link in such case.

Sending FBack to source address of the FBU always means it could
be lost when the MN has already moved.

On the other hand, sending it always to NCoA ensures that the
MN does not have to wait on the old link and it receives it
reliably on the new link.

For the stateful scenario, even if the MN leaves
link without receiving FBack, the FNA exchange allows NAR
to supply NCoA to use. Besides, the draft states that FBack MAY
also be sent on the old link (to PCoA).

Please note that the draft does not specify how NAR should provide
duplicate-free addresses (i.e., Advance DAD or any other method).
However, any method should be readily usable.

> receives an FBU message, and sends a HI message to the NAR

The problem is that MN may have to move (or forced to move)
without being able to send FBU. In such a case, it could have done
PrRtSol right after establishing connectivity. Setting the 'U' bit in
RtSolPr requests the router to buffer and forward at the same time.
So, if FBU comes from the new link, buffered packets can be tunneled
to the NCoA.

Buffering at PAR after FBU is received is problematic because
we don't know when to stop it and begin tunneling (i.e., two seprate
problems)

> FBack message. For example a new code of PrRtAdv or code "0",

Could you say why ? The current method works without requiring
the MN to wait for FBack.

Thanks,

-Rajeev

---

From: gabriel montenegro <[email-masked]>
Date: Tue, 18 Nov 2003 03:23:06 +0100

Overall looks good. Some (mostly minor) comments below.

Tuple notation [ap-id,ap-info] and *content* is not consistent
throughout. For example, ap-info should be defined (does it
include the lla and prefix information as shown under 6.1.2?

TTL == 255 in ICMP messages is not explained. presumably, this
comes from ND, but that (normative) reference is missing altogether.

Terminology - Aren't some of those terms already defined in
draft-ietf-seamoby-terminology? If so, just refer to that when
appropriate.

Suggest change of name:

	OLD: Router Solicitation for Proxy
	NEW: Router Solicitation for Proxy Advertisement

Seems to reflect more clearly what it actually is.

This seems to be incorrect:

       Proxy Router Advertisement (PrRtAdv)
                A message from the PAR indicating a MN to undergo
                handover

It's more akin to a msg which aids in movement detection, no?

Several places throughout the document says: "MUST be implemented
and SHOULD be supported." Do you mean enabled instead of supported?

section 3.1:
	s/can send Binding/can send a Binding/
	s/at new CoA/at the new CoA/
	s/The protocol/FMIPv6/
	s/again when/while/
	s/present on PAR's/present on the PAR's/
	s/conflicts and SHOULD support/conflicts and SHOULD enable/
	s/would remain active/remains active/
	s/completes Binding Update/completes the Binding Update procedure./

section 3.2, bottom of page 8:

	s/On such network/On such a network/
	s/After transmitting the FBU/After transmitting the PrRtAdv/

section 4

	s/broadly called as/broadly referred to as/

section 5.3

	"When the PAR" s/does request/requests/
	But is it really the PAR that requests it?

section 5.4
	
	s/auto- configuration/autoconfiguration/
	s/can not/cannot/

section 6.1.1 (Title is missing the abbreviation: RtSolPr)

	Can the 'U' bit be abused? Why wouldn't an MN not turn it
	on *always*. In which case why even have a bit? I.e. is this
	something that can be provided at the discretion of the PAR
	without any input from the MN? If so instead a bit issue
	a recommendation on the PAR that it provide this service if
	at all possible. One question, why would buffering be provided if
	the LLA of the new point of attachment is a wildcard?
	Should clarify.

section 6.1.2 (PrRtAdv)

	Only codes 0, 1 and 2 are listed, but 3 is also defined.
	Might as well not list them here and refer the reader to
	the list below (this is futureproof).

	Tuple description and notation is not consistent, please fix.

section 6.3.1 (FBU) and 6.3.2 (FBACK)

	Please let's not assign header values, other than tentatively
	(noting that final assignment is up to IANA).

	This points to the need for an IANA considerations section.

References section

	Must split into "Normative" and "Informative"

-gabriel

---

From: "James Kempf" <[email-masked]>
Date: Tue, 18 Nov 2003 09:05:35 -0800

Gab,

Some comments.

> It's more akin to a msg which aids in movement detection, no?

Actually, it has three purposes:

1) In predictive network initiated handover, it can be sent unsolicited to
the MN indicating that a move is imminent.

2)  If the handover is predictive and mobile initiated, it can be send in
response to the Proxy Advert Request which the mobile sends to the previous
access router, and this process would be done close to the actual link
handover too.

3) If the handover is reactive, then the mobile must send the Proxy Advert
Request prior to handover for which this message would be returned,
essentially as soon as it hears a AP beacon, so that the mobile has
information on the new subnet when it moves there, since that could happen
at any time without any information sent to the IP layer on the mobile or
router.

> and SHOULD be supported." Do you mean enabled instead of supported?

Caution is needed here. IETF documents can't require people to deploy, or
configure in a certain way if there are options. The best one can do is a
BCP describing what the best practice is for deployment, suggesting the best
options for particular circumstances. I'd suggest keeping the number of
recommendations regarding deployment to a minimum in a protocol document
(perhaps only advice about default configuration of parameters) and leave
configuration and deployment advice for a separate, BCP-style or
applicability statement-style document.

            jak

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 18 Nov 2003 16:04:15 -0800

Hi Gabriel,

replies to some of your questions. I will fix the other edits and clarify
text.

Thanks.

-Rajeev

> include the lla and prefix information as shown under 6.1.2?

The tuple is [AP-LLA, AR-LLA, AR-Prefix]

> draft-ietf-seamoby-terminology? If so, just refer to that when

Haven't checked the latest terminology draft. Will do.

> It's more akin to a msg which aids in movement detection, no?

Yes, it is incomplete, as Jim already noted. Will revise.

> and SHOULD be supported." Do you mean enabled instead of supported?

The intention is:
An implementation must have the feature/message, and should use it (unless
some other deployment consideration diminishes the need in a particular
scenario). Any re-wording suggestion ?

>         But is it really the PAR that requests it?

The intent was to state that when the HI message contains
a request for buffering, the originator of HI message (i.e.,PAR)
should also support buffering. The actual request itself could come
from MN or PAR (in the network-initiated case). Will clarify.

>         on *always*. In which case why even have a bit? I.e. is this

If the MN can send FBU from the previous link, it does not have
to turn it on. Buffering will be done at NAR in such a case.

>         the LLA of the new point of attachment is a wildcard?

Even when the wildcard is supplied, buffer-and-forward allows the
MN to reduce packet loss in the event that it handovers to any one
of the target access points without anticipation.

>         This points to the need for an IANA considerations section.

Noted.

>         Must split into "Normative" and "Informative"

okay.

---

From: gabriel montenegro <[email-masked]>
Date: Mon, 24 Nov 2003 21:25:26 +0100

> The tuple is [AP-LLA, AR-LLA, AR-Prefix]

Ok, this notation and tuple contents need to be consistent
instead of the several versions thoughout the draft.

> Yes, it is incomplete, as Jim already noted. Will revise.

ok.

> scenario). Any re-wording suggestion ?

suggest "MUST implement and SHOULD use..."

> from MN or PAR (in the network-initiated case). Will clarify.

ok, thanks.

> to turn it on. Buffering will be done at NAR in such a case

So for buffering to be correctly provided, the MN does not need
to get involved in this case.... [see below]

> of the target access points without anticipation.

[from above] ...nor does the MN need to be involved in this case.
So is there an occasion in which for buffering to be correctly
provided it MUST be requested by the MN? If not, why even have the
U bit in the RtSolPr (RtSolPrAdv) message? I understand why it makes
sense in the HI, but am wondering about the RtSolPrAdv.

-gabriel

---

From: gabriel montenegro <[email-masked]>
Date: Mon, 24 Nov 2003 21:26:39 +0100

> at any time without any information sent to the IP layer on the mobile or

Cool, yes. Rajeev has agreed that this definition needs a bit of
wordsmithing, perhaps your text above will help.

>>and SHOULD be supported." Do you mean enabled instead of supported?

Ok, just checked, the word combination that appears common is:
"MUST be supported and SHOULD be used."

> applicability statement-style document.

Don't think recommendations on use (beyond those for implementation or
support) are limited to BCP's. For example, the MIPv6
document has plenty of examples of this type of text. I'm talking of
text like: "...[MUST|SHOULD|MAY] support and [MUST|SHOULD|MAY] use...".

-gabriel

---

From: Rajeev Koodli <[email-masked]>
Date: Mon, 24 Nov 2003 15:09:52 -0800

> sense in the HI, but am wondering about the RtSolPrAdv.

Buffering _can_ be provided without the MN requesting it. The question
is should the MN have the option of requesting it. I recognize that with NAR
doing buffering, the MN is not involved in requesting buffering. For symmetry,
we either have the 'U' bit in both the cases, or we should drop it. What do
others
think ?

-Rajeev

---

From: "James Kempf" <[email-masked]>
Date: Mon, 24 Nov 2003 15:20:36 -0800

> we either have the 'U' bit in both the cases, or we should drop it. What
do

I think limiting the amount of complexity in a protocol is a good idea and I
can't see any basis upon which an MN could make a decision about whether
buffering was or was not a good idea, since the MN can't know nor can it
easily find out what the access network topology looks like, which would
provide it information about whether buffering was a good idea. Therefore, I
think the 'U' bit should be dropped.

            jak

---

From: "Youn-Hee Han" <[email-masked]>
Date: Tue, 25 Nov 2003 10:06:06 +0900

DQo+IEkgdGhpbmsgbGltaXRpbmcgdGhlIGFtb3VudCBvZiBjb21wbGV4aXR5IGluIGEgcHJvdG9jb2wgaXMgYSBnb29kIGlkZWEgYW5kIEkNCj4gY2FuJ3Qgc2VlIGFueSBiYXNpcyB1cG9uIHdoaWNoIGFuIE1OIGNvdWxkIG1ha2UgYSBkZWNpc2lvbiBhYm91dCB3aGV0aGVyDQo+IGJ1ZmZlcmluZyB3YXMgb3Igd2FzIG5vdCBhIGdvb2QgaWRlYSwgc2luY2UgdGhlIE1OIGNhbid0IGtub3cgbm9yIGNhbiBpdA0KPiBlYXNpbHkgZmluZCBvdXQgd2hhdCB0aGUgYWNjZXNzIG5ldHdvcmsgdG9wb2xvZ3kgbG9va3MgbGlrZSwgd2hpY2ggd291bGQNCj4gcHJvdmlkZSBpdCBpbmZvcm1hdGlvbiBhYm91dCB3aGV0aGVyIGJ1ZmZlcmluZyB3YXMgYSBnb29kIGlkZWEuIFRoZXJlZm9yZSwgSQ0KPiB0aGluayB0aGUgJ1UnIGJpdCBzaG91bGQgYmUgZHJvcHBlZC4NCj4gDQo+ICAgICAgICAgICAgIGphaw0KDQoNCkknZCBsaWtlIHRvIHZvdGUgdGhpcy4gQWN0dWFsbHksIGJ1ZmZlcmluZyBpc3N1ZSBzZWVtcyB0byBiZSBubyBiaWcgaXNzdWUNCmluIGN1cnJlbnQgRk1JUHY2IHN0YW5kYXJkIHByb2Nlc3MuIEJ1dCwgd2hlbiBJIHJlYWQgY3VycmVudCANCjAwLXZlcnNpb24sIHRoZXJlIHdhcyBzb21lIGRvdWJ0cyBhYm91dCBGTUlQdjYncyBidWZmZXJpbmcgDQptZWNoYW5pc20uDQoNCkZpcnN0bHksIEkgZG9uJ3QgYWdyZWUgJ1UnIGJpdCBpbiAnUnRTb2xQcicuIE1hbnkgb3BlcmF0b3JzIHdvdWxkIGxpa2UgDQp0byBtYWtlIEZNSVB2NiBydW4gYXMgcHJlZGljdGl2ZSBtb2RlLCBiZWNhdXNlIHRoZXkga25vdyB0aGUgDQpwcmVkaWN0aXZlIG1vZGUgaXMgYmV0dGVyLiBUaGUgcHJlZGljdGl2ZSBoYW5kb3ZlciByZXF1aXJlcyBNTiANCnRvIHJlY2VpdmUgUHJSdEFkdiBhbmQgRkJBY2sgcHJpb3IgdG8gbW92ZW1lbnQuIFNvLCBNTiB3b3VsZA0KcHJlc2VydmUgaXRzIGNvbm5lY3Rpb24gd2l0aCBQQVIgKGxpa2UgTGV6eSBoYW5kb3ZlcikgYW5kIHJlY2VpdmUNCnBhY2tldHMgY29tZSBmcm9tIFBBUiBhcyBtdWNoIGFzIHBvc3NpYmxlLiBEdXJpbmcgdGhpcyB0aW1lLCBJTU8sDQpidWZmZXJpbmcgaXMgbmVlZGxlc3MuIA0KDQpBbmQsIHRoZSBleGNoYW5nZSBvZiBSdFNvbFByIGFuZCBQclJ0QWR2IHdpbGwgdGFrZSB2ZXJ5IHNob3J0IHRpbWUuDQpTbywgSU1PLCBhdCBsZWFzdCBGQlUgY2FuIGJlIHNlbnQgdG8gUEFSIHByaW9yIHRvIG1vdmVtZW50IHRob3VnaA0KTU4gbW92ZXMgZmFzdCAoYnV0LCBJIGRvbid0IGtub3cgaG93IGZhc3QgTU4gbW92ZXMgdG8gbWlzcyBkZWxpdmVyeQ0Kb2YgRkJVIHRvIFBBUikuIElNTywgdGhlIHRpbWUgZm9yIFBBUiB0byByZWNlaXZlIEZCVSBzZWVtcyB0byBiZQ0KcmlnaHQgYnVmZmVyaW5nIHRpbWUuIA0KDQpXaGVuIFBBUiByZWNlaXZlIEZCVSwgaXQgc2VuZHMgSEkgdG8gTkFSLiBUaGUgbWFpbiBnb2FsIG9mIEhJIGlzDQp0aGUgcHJvc3BlY3RpdmUgTkNvQSBjb25maXJtYXRpb24uIFNvLCBIQWNrIGlzIHNlbnQgdG8gTU4gaW4gDQpyZXNwb25zZSBvZiBISSBhbmQgaXQgaGFzIHRoZSByZXN1bHQgb2YgY29uZmlybWF0aW9uLiBJTU8sIE5vdCB1bnRpbCANCnJlY2V2aW5nIHRoZSBzdWNjZXNzZnVsIHJlc3VsdCBvZiBjb25maXJtYXRpb24sIFBBUiBzaG91bGQgbm90IHR1bm5lbA0KcGFja2V0cyB0byB0aGUgTkNvQS4gU28sIFBBUiBzaG91bGQgYnVmZmVyIHBhY2tldHMgdW50aWwgcmVjZWl2aW5nIA0KSEFjay4gSG93IGRvIHlvdSB0aGluayBhYm91dCB0aGlzPw0KDQpCdXQsIEkgYW0gbm90IGFkdm9jYXRpbmcgJ1UnIGJpdCBpbiAnRkJVJyBpbnN0YWVkIG9mICdSdFNvbFByJy4gDQpJIGRvbid0IHRoaW5rIHRoYXQgYnVmZmVyaW5nIGlzIG5vdCBvbmUgd2hpY2ggTU4gc2hvdWxkIGRldGVyaW1pbmUuIA0KVGhpcyBpcyBhIHN1cHBsZW1lbnRhcnkgZnVuY3Rpb24gd2hpY2ggcm91dGVyIG1heSB2b2x1bnRhcmlseSBzdXBwb3J0Lg0KDQotIFlvdW4tSGVlIChZSCkuDQoNCg==_______________________________________________Mipshop mailing [email-masked]://www1.ietf.org/mailman/listinfo/mipshop