Subject: Re: [multimob] Working group last call for draft-ietf-multimob-fmipv6-pfmipv6-multicast-05

From: <[email-masked]>
Date: Mon, 16 Jun 2014 12:00:58 +0200

Hi all,
I also had a look at the latest version -06 and it seems for me to be ok now. 
The only minor concern might be whether the expression "length in four octets" is familiar enough (I didn't find this in any other draft) or should be mentioned especially in terms of a warning "caution!" or explicit (e.g. "i.e. 32 bit") or similar?
Otherwise I am fine with it ...
Thanks!
Best regards
Dirk

-----Original Message-----
From: Stig Venaas [mailto:[email-masked]] 
Sent: Donnerstag, 29. Mai 2014 00:28
To: Thomas C. Schmidt; von Hugo, Dirk; [email-masked]
Subject: Re: [multimob] Working group last call for draft-ietf-multimob-fmipv6-pfmipv6-multicast-05

Hi

On 5/22/2014 4:29 AM, Thomas C. Schmidt wrote:
> Hi Stig, Dirk,
>
> we just updated the document - sorry for me being slow.
>
> We have fixed all nits that you pointed at.
>
> In particular, the length counter issue should be resolved now: As 
> this inherited 8 bit length counter is not long enough to count bytes 
> of MLD state records, we propose to count four octets. This complies 
> to the alignment and should not be a problem. However, it leads to a 
> feasible number of MLD records in the payload which at least comes 
> close to common packet lengths.

Thanks. I'll have a look at this shortly. Great if others can help verify that this change is OK as well.

Stig

> Best,
>
> Thomas
>
>
> On 19.05.2014 22:00, Stig Venaas wrote:
>> Hi
>>
>> On 4/22/2014 11:13 AM, Thomas C. Schmidt wrote:
>>> Hi Stig,
>>>
>>> sorry, we've been busy otherwise.
>>>
>>> We'll try to update asap.
>>
>> How is this going? Looks like we're still waiting.
>>
>> Stig
>>
>>> Cheers,
>>>
>>> Thomas
>>>
>>> On 22.04.2014 19:29, Stig Venaas wrote:
>>>> Thomas/authors, I think we're just waiting for 06 with these minor 
>>>> changes and we can request publication.
>>>>
>>>> Stig
>>>>
>>>> On 4/3/2014 2:15 PM, Stig Venaas wrote:
>>>>> Hi
>>>>>
>>>>> On 3/31/2014 2:57 PM, Thomas C. Schmidt wrote:
>>>>>> Hi Dirk,
>>>>>>
>>>>>> many thanks for carefully looking through the draft. Please see 
>>>>>> comments inline.
>>>>>>
>>>>>> On 27.03.2014 16:30, [email-masked] wrote:
>>>>>>
>>>>>>> Sorry that I missed the preceding WGLC - I do think that this 
>>>>>>> document is ready for publication. It has greatly improved since 
>>>>>>> version 00
>>>>>>> ;-)
>>>>>>>
>>>>>>> Though some (minor) nits came to my mind after re-reading:
>>>>>>>
>>>>>>> p.1.
>>>>>>> Updates: 5568 (if approved) => shouldn't be added 5949 since it 
>>>>>>> does also update PFMIPv6?
>>>>>>>
>>>>>>
>>>>>> I don't think so. The update of 5568 is with the PrRtAdv-Messages.
>>>>>> 5949
>>>>>> does not contain such things, as there is no explicit messaging 
>>>>>> between MAGs and the MN. Mobility Options are explicitly under 
>>>>>> the control of IANA.
>>>>>>
>>>>>>> As mentioned by others for prior versions there is still mixed 
>>>>>>> usage of FBack, Hack, ... and FBACK, HACK, ...
>>>>>>> Same for PMAG/NMAG and pMAG/nMAG.
>>>>>>>
>>>>>>
>>>>>> Oh yes, that was in the figures ...
>>>>>>
>>>>>>> p.10ff
>>>>>>> "Section 3.3.  Protocol Operations Specific to PFMIPv6" and Figs.
>>>>>>> 4/5
>>>>>>> do include "PMAG (PAR)" and "NMAG (NAR)" - isn't it all about 
>>>>>>> PMIP - so no relevance for AR? Otherwise I would expect a 
>>>>>>> statement like that also a mixed scenario MIP/PMIP is in focus 
>>>>>>> here ...
>>>>>>> I tried to find out whether this was explained in prior posts 
>>>>>>> but didn't catch any ... sorry if I missed it!
>>>>>>>
>>>>>>
>>>>>> Actually the terms PAR and NAR in parenthesis are used to 
>>>>>> indicate the correspondence with FMIP ... it does not consider 
>>>>>> mixed terms, but should help the reader to see that this is all 
>>>>>> about the same "abstract entities" here.
>>>>>>
>>>>>>> p.15
>>>>>>> sect. 4.1.3 is on NAR, so I guess:
>>>>>>> of the PAR => of the NAR
>>>>>>>
>>>>>>
>>>>>> Yes, thanks.
>>>>>>
>>>>>>> the NAR joins the groups subscribed
>>>>>>>     for forwarding on the tunnel link. < sounds puzzling to me 
>>>>>>> => the NAR joins the groups the MN has subscribed
>>>>>>>     for (which are then forwarded by PAR) via the tunnel link. < 
>>>>>>> is it that what is meant?
>>>>>>>
>>>>>>
>>>>>> Yes, thanks. This is better.
>>>>>>
>>>>>>> p.21
>>>>>>> number of muticast records => number of multicast records
>>>>>>>
>>>>>>
>>>>>> Thanks, fixed.
>>>>>>
>>>>>>> or Section 4.2 of [RFC3376]) for the => or Section 4.2 of 
>>>>>>> [RFC3376] for the
>>>>>>>
>>>>>>
>>>>>> Thanks, fixed.
>>>>>>
>>>>>>> p.23
>>>>>>> 5.5.  Length Considerations: Number of Records and Addresses I 
>>>>>>> understand why the maximum number of multicast address records 
>>>>>>> is 72 or sources for MLDv2 is 89 (also given in 
>>>>>>> http://tools.ietf.org/html/rfc3810#section-5.1.10), but I miss a 
>>>>>>> consideration of specific limitation due to 8-bit Length format 
>>>>>>> in new Mobility Header Multicast Option (Fig.7).
>>>>>>> Have I misunderstood something or isn't there a much stricter 
>>>>>>> limit for multicast address records to (512-2-4)/(4+16) < 26 
>>>>>>> (w/o source
>>>>>>> addresses) ??
>>>>>>>
>>>>>>
>>>>>> I guess you hit a point: By bringing back length formatting to 
>>>>>> standard mobility options recently, we missed that this will not 
>>>>>> fill an Ethernet packet. I don't think this matters much, but we 
>>>>>> definitely should adjust the section on length considerations.
>>>>>>
>>>>>>> for that multicast address to their MLDv2 (IGMPv2) equivalents 
>>>>>>> => for that multicast address to their MLDv2 (IGMPv3) 
>>>>>>> equivalents
>>>>>>>
>>>>>>
>>>>>> Thanks, fixed.
>>>>>>
>>>>>>> Hope this helps
>>>>>>
>>>>>> Yes, it definitely does.
>>>>>>
>>>>>> We will wait for the next days to pass the call deadline and 
>>>>>> resubmit then.
>>>>>
>>>>> Thanks. Looks like these are the only outstanding issues. Thanks 
>>>>> for having a careful look Dirk.
>>>>>
>>>>> Once you submit the new version I'll allow a couple of days for 
>>>>> myself and others to review changes. If they look good I'll 
>>>>> request publishing.
>>>>>
>>>>> If others have any issues, please let us know, even if passed the 
>>>>> WGLC deadline.
>>>>>
>>>>> Stig
>>>>>
>>>>>> Thanks again & best regards,
>>>>>>
>>>>>> Thomas
>>>>>>
>>>>>>
>>>>>>>   -----Original Message-----
>>>>>>> From: multimob [mailto:[email-masked]] On Behalf Of 
>>>>>>> Stig Venaas
>>>>>>> Sent: Montag, 24. März 2014 21:30
>>>>>>> To: [email-masked]
>>>>>>> Subject: [multimob] Working group last call for
>>>>>>> draft-ietf-multimob-fmipv6-pfmipv6-multicast-05
>>>>>>>
>>>>>>> This is a working group last call for
>>>>>>> draft-ietf-multimob-fmipv6-pfmipv6-multicast-05
>>>>>>>
>>>>>>> Please state whether you think it is ready for publishing or if 
>>>>>>> you believe there are issues with the document or that it is not 
>>>>>>> ready for other reasons.
>>>>>>>
>>>>>>> The document has already been reviewed by several people, but it 
>>>>>>> is still good to hear from the working group what you think.
>>>>>>>
>>>>>>> The last call ends one week from now on Monday March 31st.
>>>>>>>
>>>>>>> The draft is available at
>>>>>>> http://tools.ietf.org/html/draft-ietf-multimob-fmipv6-pfmipv6-mu
>>>>>>> lticast-05
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Stig
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> multimob mailing list
>>>>>>> [email-masked]
>>>>>>> https://www.ietf.org/mailman/listinfo/multimob
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> multimob mailing list
>>>>>>> [email-masked]
>>>>>>> https://www.ietf.org/mailman/listinfo/multimob
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Mon, 16 Jun 2014 12:25:58 +0200

Hi Dirk,

many thanks for you continued effort!

Making the bit counting more apparent, should not be a problem. I agree 
that this is a somewhat uncommon way of counting, but prevents us from 
changing the encoding structure of the mobility options, which I believe 
is the more relevant part.

What is your opinion, Stig?

Best regards,

Thomas

-- 

Prof. Dr. Thomas C. Schmidt
° Hamburg University of Applied Sciences                   Berliner Tor 7 °
° Dept. Informatik, Internet Technologies Group    20099 Hamburg, Germany °
° http://www.haw-hamburg.de/inet                   Fon: +49-40-42875-8452 °
° http://www.informatik.haw-hamburg.de/~schmidt    Fax: +49-40-42875-8409 °

---

From: Brian Haberman <[email-masked]>
Date: Mon, 16 Jun 2014 08:35:37 -0400

You could always borrow legacy text from RFC 791...

"Internet Header Length is the length of the internet header in 32 bit
words"

Regards,
Brian

On 6/16/14 6:25 AM, Thomas C. Schmidt wrote:
>> The only minor concern might be whether the expression "length in four
>> octets" is familiar enough (I didn't find this in any other draft) or
>> should be mentioned especially in terms of a warning "caution!" or
>> explicit (e.g. "i.e. 32 bit") or similar?
>> Subject: Re: [multimob] Working group last call for

---

From: Stig Venaas <[email-masked]>
Date: Mon, 16 Jun 2014 13:23:39 -0700

> "Internet Header Length is the length of the internet header in 32 bit

This does sound better. Less risk of anyone getting it wrong. You could
consider a small example. Just a sentence saying i.e. if the length is
8 octets the length field would be set to 2 or something.

Stig

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Thu, 26 Jun 2014 11:33:01 +0200

Hi all,

as no more comments arrived, we have just updated the draft with the 
proposed text.

Best,

Thomas

--

---

From: Stig Venaas <[email-masked]>
Date: Thu, 26 Jun 2014 10:24:40 -0700

Hi

> as no more comments arrived, we have just updated the draft with the

Great. I'll request publishing of this then. I'll try to get this
done early next week. Please everyone, have a look at the latest
document and let us know if any concerns. If you read the previous
versions the couple of latest diffs would be of help. See
http://tools.ietf.org/wg/multimob/draft-ietf-multimob-fmipv6-pfmipv6-multicast/
for the different versions and diffs.

Stig

---

From: Stig Venaas <[email-masked]>
Date: Mon, 30 Jun 2014 11:01:30 -0700

Hi

I've now requested publication of this document. You can find the
writeup and other details in the tracker at
https://datatracker.ietf.org/doc/draft-ietf-multimob-fmipv6-pfmipv6-multicast/

Stig