Subject: [Softwires] Review of I-D draft-ietf-softwire-gateway-init-ds-lite-02

From: <[email-masked]>
Date: Mon, 7 Mar 2011 15:09:05 +0100

Hi folks

@IETF79 I have been asked to do a review of the above mentioned I-D and that's why I had another round of reading this doc (and all the other reviews of this I-D that happened during the last weeks).

>From my perspective this I-D is a well written document that extends the applicability of the DS-lite tunnel approach also to the 3G world and other point-to-point tunnel based network access architectures. GI-DS-lite is furthermore referenced within the 3GPP standardization documents as one of the technologies for supporting IPv6 deployment and IPv4 address exhaustion mitigation. That's why I think, that the GI-DS-lite spec is very useful and also needed in communities outside the IETF.

Since the doc is already in a very good shape I've only to add the follwoing minor comments (Besides the remarks already posted by Yiu Lee :):
- Page 7 - 2nd bullet point: 
	s/can its/can use its/
	s/and IPv4 packet/an IPv4 packet/
- Page 8 - 2nd bullet point: MPLS VPN
	Did I get this right, that your assumption for this tunnel scenario is, that there are "point-to-point" MPLS VPN 
	links between AFTR and Gateway? (I.e. each VPN contains only one Gateway and one AFTR interface.)
	In that case I would suggest:
		s/IPv4 address/IPv4 address of the Gateway/g
- Page 8 - 3rd bullet point - I agree with Yiu Lee's remark that it seems useful to clarify the IP-in-IP case and to explicitely describe
 	from which IP header (inner/outer, IPv4/IPv6) the address or flow label are choosen.
	Perhaps it is also useful to name these cases explicitely "Plain IPv4-in-IPvX".

- Page 9 - Chapter 7.1.: Just a question: Since this example call flow seems to be only for clarification, would it make sense to shift this to some kind of appendix?

- Page 9 - Chapter 7.2: Would it make sense to substitue the word "examples" with "Network scenarios"?

>From my point of view this document is (if the above minor changes are applied) ready for the next steps of the RFC process.

So far my 0,02$. Kind regards
Olaf

---

From: Paco Cortes <[email-masked]>
Date: Tue, 8 Mar 2011 12:26:36 +0100

Hi,

one more comment:
- Page 4, 1st bullet point in section 4:

This bullet is not always applicable.
If the source IP address has been used as CID, as mentioned several times
above as a possibility, then this parameter is already in a traditional NAT
binding entry and no extension is needed for it.
If the softwire technology/implementation used is seen by the AFTR as a
logical interface, traditional NAT binding entries already include it, so
that no extension is needed either.
In particular, in the MPLS VPN embodiement described in section 6, NAT
extensions would not be needed.
A new qualifier part like "depending on the embodiement" should be added to
this bullet.

Kind regards,
  Paco

2011/3/7 <[email-masked]>

> Hi folks
>
> @IETF79 I have been asked to do a review of the above mentioned I-D and
> that's why I had another round of reading this doc (and all the other
> reviews of this I-D that happened during the last weeks).
>
> From my perspective this I-D is a well written document that extends the
> applicability of the DS-lite tunnel approach also to the 3G world and other
> point-to-point tunnel based network access architectures. GI-DS-lite is
> furthermore referenced within the 3GPP standardization documents as one of
> the technologies for supporting IPv6 deployment and IPv4 address exhaustion
> mitigation. That's why I think, that the GI-DS-lite spec is very useful and
> also needed in communities outside the IETF.
>
> Since the doc is already in a very good shape I've only to add the
> follwoing minor comments (Besides the remarks already posted by Yiu Lee :):
>        Did I get this right, that your assumption for this tunnel scenario
> is, that there are "point-to-point" MPLS VPN
> - Page 8 - 3rd bullet point - I agree with Yiu Lee's remark that it seems
> useful to clarify the IP-in-IP case and to explicitely describe
> - Page 9 - Chapter 7.1.: Just a question: Since this example call flow
> seems to be only for clarification, would it make sense to shift this to
> some kind of appendix?
>
> From my point of view this document is (if the above minor changes are
> applied) ready for the next steps of the RFC process.
>
> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires
>

---

From: "Lee, Yiu" <[email-masked]>
Date: Tue, 8 Mar 2011 16:32:04 +0000

Hi Paco,

I agree with you when IPv4-in-IPvY mode is the standard ds-lite model. I guess the extension here means to define a new set of identifiers which can be use by the GW (aka B4) for the . It doesn't necessary mean to extend the NAT table.

Best Regards,
Yiu

From: Paco Cortes <[email-masked]<mailto:[email-masked]>>
Date: Tue, 8 Mar 2011 12:26:36 +0100
To: <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Softwires] Review of I-D draft-ietf-softwire-gateway-init-ds-lite-02

Hi,

one more comment:
- Page 4, 1st bullet point in section 4:
This bullet is not always applicable.
If the source IP address has been used as CID, as mentioned several times above as a possibility, then this parameter is already in a traditional NAT binding entry and no extension is needed for it.
If the softwire technology/implementation used is seen by the AFTR as a logical interface, traditional NAT binding entries already include it, so that no extension is needed either.
In particular, in the MPLS VPN embodiement described in section 6, NAT extensions would not be needed.
A new qualifier part like "depending on the embodiement" should be added to this bullet.
Kind regards,
  Paco

2011/3/7 <[email-masked]<mailto:[email-masked]>>

Hi folks

So far my 0,02$. Kind regards
Olaf
_______________________________________________
Softwires mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/softwires

_______________________________________________ Softwires mailing list [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/softwires

---

From: <[email-masked]>
Date: Tue, 8 Mar 2011 17:36:12 +0100

Hi Paco
 
thx for bringing this up. This directs me to a typo in my email.
My remarks to page 8 2nd bullet point have to read as:
     s/IPv4 address/IPv4 address of the AD/
 
Regards
    Olaf

________________________________

	Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Paco Cortes
	Gesendet: Dienstag, 8. März 2011 12:27
	An: [email-masked]
	Betreff: Re: [Softwires] Review of I-Ddraft-ietf-softwire-gateway-init-ds-lite-02

	Hi, 

	one more comment:

	Kind regards, 
	  Paco

		Hi folks

---

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Wed, 9 Mar 2011 18:54:26 +0100

Hi Paco,

thanks for pointing this out and thanks to Yiu for clarifying things
quickly. The updated draft will reflect your note ("depending on the
embodiement") below.

Regards, Frank

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Lee, Yiu
Sent: Tuesday, March 08, 2011 5:32 PM
To: Paco Cortes; [email-masked]
Subject: Re: [Softwires] Review of I-D
draft-ietf-softwire-gateway-init-ds-lite-02

Hi Paco,

I agree with you when IPv4-in-IPvY mode is the standard ds-lite model. I
guess the extension here means to define a new set of identifiers which
can be use by the GW (aka B4) for the . It doesn't necessary mean to
extend the NAT table.

Best Regards,

Yiu

From: Paco Cortes <[email-masked]>
Date: Tue, 8 Mar 2011 12:26:36 +0100
To: <[email-masked]>
Subject: Re: [Softwires] Review of I-D
draft-ietf-softwire-gateway-init-ds-lite-02

Hi, 

one more comment:

	If the source IP address has been used as CID, as mentioned
several times above as a possibility, then this parameter is already in
a traditional NAT binding entry and no extension is needed for it.

	If the softwire technology/implementation used is seen by the
AFTR as a logical interface, traditional NAT binding entries already
include it, so that no extension is needed either.
	In particular, in the MPLS VPN embodiement described in section
6, NAT extensions would not be needed.
	A new qualifier part like "depending on the embodiement" should
be added to this bullet.

Kind regards, 

  Paco

	Hi folks
	
	@IETF79 I have been asked to do a review of the above mentioned
I-D and that's why I had another round of reading this doc (and all the
other reviews of this I-D that happened during the last weeks).
	
	From my perspective this I-D is a well written document that
extends the applicability of the DS-lite tunnel approach also to the 3G
world and other point-to-point tunnel based network access
architectures. GI-DS-lite is furthermore referenced within the 3GPP
standardization documents as one of the technologies for supporting IPv6
deployment and IPv4 address exhaustion mitigation. That's why I think,
that the GI-DS-lite spec is very useful and also needed in communities
outside the IETF.
	
	Since the doc is already in a very good shape I've only to add
the follwoing minor comments (Besides the remarks already posted by Yiu
Lee :):
	- Page 7 - 2nd bullet point:
	       s/can its/can use its/
	       s/and IPv4 packet/an IPv4 packet/
	- Page 8 - 2nd bullet point: MPLS VPN
	       Did I get this right, that your assumption for this
tunnel scenario is, that there are "point-to-point" MPLS VPN
	       links between AFTR and Gateway? (I.e. each VPN contains
only one Gateway and one AFTR interface.)
	       In that case I would suggest:
	               s/IPv4 address/IPv4 address of the Gateway/g
	- Page 8 - 3rd bullet point - I agree with Yiu Lee's remark that
it seems useful to clarify the IP-in-IP case and to explicitely describe
	       from which IP header (inner/outer, IPv4/IPv6) the address
or flow label are choosen.
	       Perhaps it is also useful to name these cases explicitely
"Plain IPv4-in-IPvX".
	
	- Page 9 - Chapter 7.1.: Just a question: Since this example
call flow seems to be only for clarification, would it make sense to
shift this to some kind of appendix?
	
	- Page 9 - Chapter 7.2: Would it make sense to substitue the
word "examples" with "Network scenarios"?
	
	From my point of view this document is (if the above minor
changes are applied) ready for the next steps of the RFC process.

_______________________________________________ Softwires mailing list
[email-masked] https://www.ietf.org/mailman/listinfo/softwires

---

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Wed, 9 Mar 2011 19:03:52 +0100

Hi Olaf,

thanks for your detailed review. Please see inline...

> -----Original Message-----
> Behalf Of [email-masked]
> 
> Hi folks
> 
> From my perspective this I-D is a well written document that extends
> the applicability of the DS-lite tunnel approach also to the 3G world
> and other point-to-point tunnel based network access architectures.
GI-
> DS-lite is furthermore referenced within the 3GPP standardization
> documents as one of the technologies for supporting IPv6 deployment
and
> IPv4 address exhaustion mitigation. That's why I think, that the
GI-DS-
> lite spec is very useful and also needed in communities outside the
> IETF.
> 
> follwoing minor comments (Besides the remarks already posted by Yiu
Lee
> :):
..FB: ok

> 	Did I get this right, that your assumption for this tunnel
> scenario is, that there are "point-to-point" MPLS VPN
..FB: This could be a "point to point" VPN - but doesn't have to be one.
Much like you could have multiple NAT boxes deployed in a normal NAT
deployment, one could have multiple NAT boxes present in a single VPN -
and setup your routing in a way that you achieve some load balancing
across the different NAT boxes. 
(Though your (corrected) comment - "s/IPv4 address/IPv4 address of the
AD/" applies of course).

> - Page 8 - 3rd bullet point - I agree with Yiu Lee's remark that it
> seems useful to clarify the IP-in-IP case and to explicitely describe
>  	from which IP header (inner/outer, IPv4/IPv6) the address or
flow
> label are choosen.

...FB: Agreed.

> seems to be only for clarification, would it make sense to shift this
> to some kind of appendix?
> 

.. FB: Fine for me. How about making section 7 (so both 7.1 and 7.2)
Appendix A? The only downside I see with an appendix approach is really
that the text which some readers might still be interested in is a bit
separated from the real document - because (per formatting rules), it'll
end up at the very end of the document, behind the references.

> applied) ready for the next steps of the RFC process.

Thanks again for your detailed review.

Regards, Frank