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 protected] [mailto:[email protected]] Im
Auftrag von Paco Cortes
Gesendet: Dienstag, 8. März 2011 12:27
An: [email protected]
Betreff: Re: [Softwires] Review of
I-Ddraft-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
