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 protected] [mailto:[email protected]] On
Behalf Of Lee, Yiu
Sent: Tuesday, March 08, 2011 5:32 PM
To: Paco Cortes; [email protected]
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 protected]>
Date: Tue, 8 Mar 2011 12:26:36 +0100
To: <[email protected]>
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 protected]>
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
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
_______________________________________________ Softwires mailing list
[email protected] https://www.ietf.org/mailman/listinfo/softwires
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
