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

[Vijay Devarapalli <[e-mail]>]

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.

>  >>    (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?

> 
>  >>    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.


>  >>    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.


>  >> 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.

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

Vijay