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

["Leaf Yeh" <[e-mail]>]

#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:[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