Re: [Softwires] I-D Action: draft-ietf-softwire-map-12.txt

[Ole Troan <[e-mail]>]

Leaf,

> #15.  One more question,
> 
> in Fig.2 of sec. 5.1 & Fig.9 of sec. B.1, the draft uses k-bits to stand for the field of PSID,
> but in Fig.6 of sec.5.2 & Fig.7 of sec.5.3, the draft uses q-bits to stand for the field of PSID,
> 
> why don't we use the same name, k-bits or q-bits, for PSID?

we could have. I can’t recall now, why we chose to use a different tag for the field in the BMR.
I don’t want to take the risk of changing it.
I hope to get -13 published with some of your other corrections and another clarification from Ian. the dead line for that is today.  then if Ted approves the changes he will pass it onto the RFC Editor.

cheers,
Ole


> -----Original Message-----
> From: Leaf Yeh [mailto:[e-mail]]
> Sent: Monday, March 09, 2015 11:26 AM
> To: 'Ole Troan'
> Cc: 'Suresh Krishnan'; 'Ted Lemon'; '[e-mail]'
> Subject: RE: [Softwires] I-D Action: draft-ietf-softwire-map-12.txt
> 
> Ole - that’s what n/a, null, 0, 0 is meant to indicate.
> 
> Null !=0, right?
> 
> 
> Ole - again, we wanted to be explicit with regards to the PSID and point out how it contrasts with the other examples.
> 
> But the same words on the 'IPv4 address and PSID' looks a little vague. The difference between example 4 & 5 is only about the PSID part.
> 
> 
> Ole - probably, but I don’t want to invent any new algorithm at this point. ;-)
> 
> I haven't propose any new algorithm other than the GMA defined in Appendix.
> I just hope we could drop more words on how to use it better.
> 
> 
> Best Regards,
> Leaf
> 
> 
> 
> -----Original Message-----
> From: Ole Troan [mailto:[e-mail]]
> Sent: Saturday, March 07, 2015 3:58 AM
> To: Leaf Yeh
> Cc: Suresh Krishnan; Ted Lemon; [e-mail]
> Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-map-12.txt
> 
> Leaf,
> 
>> Leaf - In sec. 11
>>> “     They cannot
>>>     exist with MAP because each BRs checks that the IPv6 source
>>>     address of a received IPv6 packet is a CE address based on
>>>     Forwarding Mapping Rule. ”
>> Leaf - but my point was 'each BR (note that we don't need 's' here.) checks that whether the IPv6 source address of a received IPv6 packet is a CE address based on Basic Mapping Rule, not Forwarding Mapping Rule.', right?
>> 
>> I withdraw the above question, cause I suppose we don't have BMR (which is for CE) at BR after more times reading of sec.8.1 in the draft .
>> 
>> 
>> But I might get more nits in the Appendix.
>> 
>> #8. In Example 4 of Appendix A, page 26,
>> "      IPv6 address of MAP CE:  2001:db8:0012:3400:0000:c000:0201:0000
>> " (the last line)
>> 
>> I suppose it should be “IPv6 address of MAP CE:  2001:db8:0012:3400:0000:c000:0212:0000”
> 
> sorry, I can’t see what the difference between the two?
> 
>> #9. In Example 4 of Appendix A, page 26,
>> "     …
>> 　　　EA bits offset:       0
>>     …
>>     PSID start:           0
>>     … ”
>> I don’t think these offset is 0, cause it means the 1st bit of IPv6 address/prefix. I prefer to replace the above ‘0’ to be ‘n/a’.
> 
> right, there isn’t a PSID in example 4. that’s what n/a, null, 0, 0 is meant to indicate. we could have dropped including anything about the PSID in the example, but we did to contrast it with the address sharing case.
> 
>> #10. In Example 5 of Appendix A, page 27,
>> "     Note that the IPv4 address and PSID is not derived from the IPv6
>>     prefix assigned to the CE, but provisioned separately using
>>     e.g., DHCP. "
>> 
>> I guess we don't need this special note here, cause we use DHCPv6 options to provision the Rules, including OPTION_S46_RULE & OPTION_S46_PORTPARAMS as the same manner as example 1 & 4. OTOH, IPv4 address can be directly read from the Rules, and don't need the further calculation as the same as Example 4, but we need OPTION_S46_PORTPARAMS for PSID.
> 
> again, we wanted to be explicit with regards to the PSID and point out how it contrasts with the other examples.
> 
>> #11. In Example 5 of Appendix A, page 27,
>> " Basic Mapping Rule:   {2001:db8:0012:3400::/56 (Rule IPv6 prefix),
>>                            192.0.2.18/32 (Rule IPv4 prefix),
>>                            0 (Rule EA-bits length)}
>>     PSID length:          8. (From DHCP. Sharing ratio of 256)
>>     PSID offset:          6  (Default)
>>     PSID       :          0x34 (From DHCP.)"
>> 
>> I guess we don’t the above words of 'from DHCP', cause all the parameters in BMR are got from DHCPv6 options.
> 
> ref, previous mail.
> 
>> 
>> 
>> #12. In Example 5 of Appendix A, page 27,
>> "      EA bits offset:        0"
>> 
>> Again, I prefer the above to be " EA bits offset:        n/a"
>> 
>> 
>> #13.   In Appendix B,
>> "  o  It SHOULD be possible to exclude subsets of the complete port
>>     numbering space from assignment.  Most operators would exclude the
>>     system ports (0-1023).  A conservative operator might exclude all
>>     but the transient ports (49152-65535).
>> ...
>>  o  i ranges from ceil(N / (R * M)) to trunc(65536/(R * M)) - 1, where
>>     ceil is the operation of rounding up to the nearest integer and N
>>     is the number of ports (e.g., 1024) excluded from the lower end of
>>     the range."
>> 
>> I guess we could use another parameter 'L' (which could be divisible by R*M) instead of 65536 to exclude the upper end of port-range, while keep to meet those requirement mentioned in Appendix B. Right?
> 
> probably, but I don’t want to invent any new algorithm at this point. ;-)
> 
>> #14. Fig.9 in Appendix B looks the same as Fig. 2 in Sec. 5.1, could we replace 'A' in Fig.2 to be 'i', and replace 'M' in Fig.2 to be 'j’?
> 
> I don’t think you can do that. Xing can you confirm?
> looking through Appendix B it would seem that would require quite a lot of changes to how M, R, i and j are used.
> the purpose of Appendix B was to give a different freestanding angle to the port mapping algorithm.
> 
> cheers,
> Ole
>