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

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

Leaf > b. In sec. 4.5,
> "  The OPTION_S46_PORTPARAMS option with an
>   explicit PSID MUST be discarded if the S46 CE isn't configured with a
>   full IPv4 address (e.g.  IPv4 prefix).  "
Ole - this text is trying to cover the misconfiguration case where CE is assigned an IPv4 prefix (e.g. /24) and a PSID. that doesn’t work, as one can not have “shared IPv4 subnets, only individual addresses”.

I got it. The above words in quotation are right, if we suppose the 'full IPv4 address' is a derived address per the rules. Right? 
That might means the length of PSID in bits, q=o-(32-r) >= 0. (e.g. the cases, b1 & b2, as follows)

b1.  If o+r > 32, we can get q-bits (i.e. PSID) from the End-user IPv6 prefix. OTHO, we can also get q-bits (i.e. PSID) from OPTION_S46_PORTPARAMS. If they have not got the same length and value, we might need to drop OPTION_S46_PORTPARAMS. Right?
b2.  If o+r = 32, we can't get q-bits from the End-user IPv6 prefix, but might get q-bits (i.e. PSID) from OPTION_S46_PORTPARAMS. Right?
b3.  If o+r < 32, your above case, we don't need q-bits, so we will drop OPTION_S46_PORTPARAMS.
b4.  If o = 0, we can get q-bits (i.e. PSID) from OPTION_S46_PORTPARAMS.

It seems we might have some case (e.g. the above case 'b1') of mis-configuration while a valid OPTION_S46_PORTPARAMS option is provided with a derived full IPv4 address. If we regard the above "full IPv4 address" as the Rule IPv4 prefix (x.x.x.x/32), then the above statement might need more change.


Leaf - c.
> I guess if F-Flag=0, i.e. not set, this rule is a BMR only, and is not 
> a FMR. That might means hub & spoke mode, right? If yes, I guess we 
> need more words on the hub & spoke mode in this section. Right?
Ole - yes, that means H&S mode. I believe we had this discussion on the mailing list earlier, and that we came to the conclusion that we didn’t want to “re-specify” the MAP mechanism in the MAP DHCP draft, so the “more words” should be in the base specification.

We can't have words on F-Flag in the base spec, which is defined in this draft. OTOH, we do have more words on mesh mode. 
  " It is expected that in a typical mesh deployment scenario, there will
   be a single BMR, which could also be designated as an FMR using the
   F-Flag. " in sec. 4.1.
I guess we could add the following:
  " It is expected that in a typical hub and spoke deployment scenario, there will
   be a single BMR while setting F-flag to be 0, which is not designated as an FMR".


Leaf - d.
> I prefer the above words could be " Such a client MUST include the 
> codes of the S46 Container option(s)...in its ORO…".
Ole - what about: "Such a client MUST request the S46 Container option(s) that it is configured for in its ORO…"

I preferred mime. Your above words specified the behavior, but my words specified the implementation. :-)


Best Regards,
Leaf



-----Original Message-----
From: Ole Troan [mailto:[e-mail]] 
Sent: Saturday, March 07, 2015 4:24 AM
To: Leaf Yeh
Cc: Tomasz Mrugalski; [e-mail]; Suresh Krishnan; Ted Lemon
Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-map-dhcp-11.txt

Leaf,

> 
> Nits found in draft-ietf-softwire-map-dhcp-11:
> 
> a. In sec. 4.4, "o  option-length: 4"
> 
> Per the format defined for OPTION_S46_V4V6BIND, the value of the 
> option-length should be variable. I guess the above text is wrongly 
> copied from other place.

thanks, that was definitely a bug! I will get this fixed.

> b. In sec. 4.5,
> "  The OPTION_S46_PORTPARAMS option with an
>   explicit PSID MUST be discarded if the S46 CE isn't configured with a
>   full IPv4 address (e.g.  IPv4 prefix)."
> 
> I prefer to replace the above "a full IPv4 address" to be "a shared 
> IPv4 address". We can get the address sharing information from the 
> calculation on the 'ea-len' and 'prefix4-len' got from 
> OPTION_S46_RULE, i.e. PSID-length = q = o - p = o - (32-r) != 0.  Right?

this text is trying to cover the misconfiguration case where CE is assigned an IPv4 prefix (e.g. /24) and a PSID. that doesn’t work, as one can not have “shared IPv4 subnets, only individual addresses”.

> c. In sec. 4.1,
> "  o  F-Flag: 1 bit field that specifies whether the rule is to be used
>      for forwarding (FMR).  If set, this rule is used as a FMR, if not
>      set this rule is a BMR only and MUST NOT be used for forwarding.
>      Note: A BMR can also be used as an FMR for forwarding if the
>      F-flag is set.  The BMR rule is determined by a longest-prefix
>      match of the Rule-IPv6-prefix against the End-User IPv6
>      prefix(es)."
> 
> I guess if F-Flag=0, i.e. not set, this rule is a BMR only, and is not 
> a FMR. That might means hub & spoke mode, right? If yes, I guess we 
> need more words on the hub & spoke mode in this section. Right?

yes, that means H&S mode. I believe we had this discussion on the mailing list earlier, and that we came to the conclusion that we didn’t want to “re-specify” the MAP mechanism in the MAP DHCP draft, so the “more words” should be in the base specification.

> d. In sec. 8,
> "  Such
>   a client MUST include the S46 Container option(s) that it is
>   configured for in its ORO in SOLICIT, REQUEST, RENEW, REBIND and
>   INFORMATION-REQUEST messages. "
> 
> I prefer the above words could be " Such a client MUST include the 
> codes of the S46 Container option(s)...in its ORO…".

I agree it is worded a bit awkwardly.
what about:
"Such a client MUST request the S46 Container option(s) that it is configured for in its ORO…"

> e. In sec. 4.5,
> "  o  offset: (PSID offset) 8 bits long field that specifies the numeric
>      value for the S46 algorithm's excluded port range/offset bits
>      (A-bits), as per section 5.1.1 of [I-D.ietf-softwire-map]. "
> 
> I prefer to replace the above "A-bits " to be "a-bits" per 
> I-D.ietf-softwire-map.  'A' looks like the value in the field, while 
> 'a' is the number of the bits.

ack.

> f. In sec. 4.4,
> "  o  bind-ipv6-prefix: a variable length field specifying the IPv6
>      prefix or address for the S46. "
> 
> I prefer to replace the above "the S46" to be "the S46 CE". Right?

right.

> g. In sec. 3,
> "  MAP-E uses RFC2473 [RFC2473] IPv4 over IPv6 tunnelling,
>   while MAP-T uses NAT64 [RFC6145] based translation."
> 
> We only need 1x RFC2473 here.  :-)

you just can’t have enough RFC2473! ;-)

I think the length bug above warrants a quick revision. if no-one objects I’ll also include the other editorial issues that Leaf found.

cheers,
Ole



> 
> 
> Best Regards,
> Leaf
> 
> 
> 
> -----Original Message-----
> From: Softwires [mailto:[e-mail]] On Behalf Of 
> [e-mail]
> Sent: Friday, November 14, 2014 5:52 PM
> To: [e-mail]
> Cc: [e-mail]
> Subject: [Softwires] I-D Action: draft-ietf-softwire-map-dhcp-11.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Softwires Working Group of the IETF.
> 
>        Title           : DHCPv6 Options for configuration of Softwire
> Address and Port Mapped Clients
>        Authors         : Tomek Mrugalski
>                          Ole Troan
>                          Ian Farrer
>                          Simon Perreault
>                          Wojciech Dec
>                          Congxiao Bao
>                          Leaf Y. Yeh
>                          Xiaohong Deng
> 	Filename        : draft-ietf-softwire-map-dhcp-11.txt
> 	Pages           : 18
> 	Date            : 2014-11-14
> 
> Abstract:
>   This document specifies DHCPv6 options, termed Softwire46 options,
>   for the provisioning of Softwire46 Customer Edge (CE) devices.
>   Softwire46 is a collective term used to refer to architectures based
>   on the notion of IPv4 Address+Port (A+P) for providing IPv4
>   connectivity across an IPv6 network.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-softwire-map-dhcp/
> 
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-softwire-map-dhcp-11
> 
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-softwire-map-dhcp-11
> 
> 
> Please note that it may take a couple of minutes from the time of 
> submission until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> Softwires mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/softwires
>