Re: [Mipshop] Comments on draft-ietf-mipshop-pfmipv6-05.txt

[Hidetoshi Yokota <[e-mail]>]

Hi Vijay,

Thanks again for your quick review and comments. Attached please find
the latest version, which has already reflected the received comments.

Also please see inline:

Vijay Devarapalli wrote:
> Hello,
> 
> Hidetoshi Yokota wrote:
> 
>>  > I went through the draft one more time before sending it to the IESG. I
>>  > have one major comment and a number of minor comments. I think one more
>>  > revision is needed before it can be sent to the IESG.
>>  >
>>  > The major comment - I think we should introduce a flag in the HI message
>>  > that says it is related to PFMIPv6 as opposed to FMIPv6. There are too
>>  > many subtle differences between the processing of FMIPv6 HI and PFMIPv6
>>  > HI messages. Having a flag that indicates this explicitly would be good.
>>
>> Good idea. Now the HI and Hack have the 'P' flag to distinguish them
>> from those in FMIPv6.
> 
> You would also need to add text about setting the 'P' flag and
> processing the flag.

Brief explanations are added in Sections 4 (1st paragraph) and 4.1
(steps (c) and (d) for both predictive and reactive modes).

>>  >>    (f)  If the F flag is set in the previous step, a bi-directional
>>  >>         tunnel is established between the PAR and NAR and packets
>>  >>         destined for the MN are forwarded from the PAR to the NAR over
>>  >>         this tunnel.  After decapsulation, those packets may be buffered
>>  >>         at the NAR.  If the connection between the N-AN and NAR has
>>  >>         already been established, those packet may be forwarded towards
>>  >>         the N-AN; this is access technology specific.
>>  >
>>  > If the MN has not attached to N-AN, yet, what happens to the forwarded
>>  > packets? If the N-AN required to buffer too? Or does the N-AN drop the
>>  > packets? This needs to be clarified.
>>
>> The above paragraph was revised as follows:
>>
>>    (f)  If the F flag is set in the previous step, a bi-directional
>>         tunnel is established between the PAR and NAR and packets
>>         destined for the MN are forwarded from the PAR to the NAR over
>>         this tunnel.  After decapsulation, those packets may be buffered
>>         at the NAR.  If the connection between the N-AN and NAR has
>>         already been established, those packets may be forwarded towards
>>         the N-AN, which then becomes responsible for them (e.g.,
>>         buffering or delivering depending on the condition of the MN's
>>         attachment); this is access technology specific.
> 
> It could even drop the packets right?

It still depends on the implementation, so it could drop the packets in
the worst case. In Section 4.1, the phrase "In order to eliminate the
packet loss..." was modified to "In order to alleviate the packet loss..."

>>  >>    The encapsulation type for these user packets SHOULD follow that used
>>  >>    in the tunnel between the LMA and MAG (e.g., IPv6-in-IPv6 [RFC5213]
>>  >>    or GRE [GREKEY]).
>>  >
>>  > I guess you need to mention UDP encapsulation too, in case an UDP tunnel
>>  > is setup between the PMAG and the NMAG.
>>
>> The above paragraph was revised as follows:
>>
>>    The encapsulation type for these user packets SHOULD follow that used
>>    in the tunnel between the LMA and MAG (IPv6-in-IPv6, IPv6-in-IPv4,
>>    IPv6-in-IPv4-UDP, IPv6-in-IPv4-UDP-TLV as specified in [RFC5213], GRE
>>    as specified in [GREKEY] or any new method defined in the future).
> 
> Ok, but TLV is specified in [GREKEY], not in RFC 5213.

You mean "draft-ietf-netlmm-pmip6-ipv4-support-13.txt" [IPv4PMIPv6]? The
references are modified as such.

>>  >>    Code        [RFC5268bis] defines this field and its values 0 and 1.
>>  >>                In this specification, if F flag is not set, this field
>>  >>                MUST be set to zero.  Otherwise, it has the following
>>  >>                meaning:
>>  >>
>>  >>                          2: Forwarding is not requested
>>  >>
>>  >>                          3: Request forwarding
>>  >>
>>  >>                          4: Indicate the completion of forwarding
>>  >
>>  > When is code '4' used? I couldn't find the corresponding text that
>>  > explains when the code is set to '4' and what the receiving node needs
>>  > to do.
>>
>> I just realized that the corresponding text was left unupdated. More
>> importantly, the F flag was used to distinguish the HI in this spec from
>> that in FMIPv6 and overwrapping the code values was avoided, but now
>> that the P flag is introduced, there is no ambiguity between them any
>> more and the Code values 2 and 3 can be represented purely by the F
>> flag. I also realized that it is necessary to have the equivalent Code
>> value 6 in the HAck if the context information is fragmented in multiple
>> pieces. So, the new document has the following text and Code values:
>>
>>    Code        [RFC5268bis] defines this field and its values 0 and 1.
>>                In this specification, with the P flag set, this field
>>                can be set to zero by default or the following values:
>>
>>                          1: Indicate the completion of forwarding
>>
>>                          2: All available context transferred
>>
>>                Code value 2 is set when the transfer of all necessary
>>                context information is completed with this message.  This
>>                Code value is used in both cases where the context
>>                information is fragmented into several pieces and the
>>                last fragment is contained in this message and where the
>>                whole information is transferred in one piece.
> 
> hmm.. I think it would be good to avoid an overlap of the "Code" values,
> even though there is a new flag indicating the HI message is related to
> PFMIPv6.

Code values are modified from 1,2 to 2,3 to avoid overlapping.

>>  >> 6.2.3.  IPv4 Address Option
>>  >>
>>  >>    As described in Section 4.3, if the MN is IPv4-only mode or dual-
>>  >>    stack mode, the MN requires IPv4 home address (IPv4-MN-HoA).  This
>>  >>    option has alignment requirement of 4n.
>>  >>
>>  >>       0                   1                   2                   3
>>  >>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>  >>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>  >>      | Option-Type   | Option-Length |  Option-Code  |    Reserved   |
>>  >>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>  >>      |                      IPv4 Address                             |
>>  >>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>  >>
>>  >>    Option-Type    TBD3
>>  >>
>>  >>    Option-Length  6
>>  >>
>>  >>    Option-Code
>>  >>
>>  >>                   0  Reserved
>>  >>
>>  >>                   1  IPv4-MN-HoA
>>  >
>>  > It looks like you don't need a "Option-Code" field here. This options
>>  > seems to be only for carrying the MN's IPv4 address. There is no 
>> other use.
>>  >
>>  > BTW, can't we re-use the IPv4 Home Address Option that we already have?
>>  > See section 3.1.1 of RFC 5555.
>>
>> Thanks for your input. We should reuse this option. Section 6.2.3 was
>> moved to 6.2.7 without defining a new option. Section 8 (IANA
>> Considerations) was revised accordingly.
> 
> On second thoughts lets not re-use the IPv4 Home Address Option from RFC
> 5555. I heard from Sri, that we might have to define a new option for
> carrying the IPv4 address of the mobile node in
> draft-ietf-netlmm-pmip6-ipv4-support-13.txt. I think we should that option.

It seems that -13.txt hasn't had that option, yet, but our latest
document refers to it hoping that the above reference will be defined in
the future...

> Please submit the revised document ASAP. I will then forward that
> document to the IESG.

Will submit the latest version shortly.

Regards,
-- 
Hidetoshi

> Vijay
> 
> 
>