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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
