#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? Best Regards, Leaf -----Original Message----- From: Leaf Yeh [mailto:[email protected]] Sent: Monday, March 09, 2015 11:26 AM To: 'Ole Troan' Cc: 'Suresh Krishnan'; 'Ted Lemon'; '[email protected]' 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:[email protected]] Sent: Saturday, March 07, 2015 3:58 AM To: Leaf Yeh Cc: Suresh Krishnan; Ted Lemon; [email protected] 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 _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
