Subject: Re: [Softwires] GI-DS-lite Review

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

Hi Yiu,

thanks a lot for your detailed review, and sorry for the delay in
responding. 

Please see inline..

From: Lee, Yiu [mailto:[email-masked]] 
Sent: Friday, February 25, 2011 9:52 PM
To: Softwires; Frank Brockners (fbrockne); Sri Gundavelli (sgundave);
[email-masked]; [email-masked]
Subject: GI-DS-lite Review

Hi authors,

I was asked to do a review on the GI-DS-lite draft, this is my review.

The draft is well written and is ready to publish.

P.3:  If e.g., a GRE based

   encapsulation mechanisms is chosen, it allows the network between the

   access gateway and the "NAT" to be either IPv4 or IPv6

Suggest to change NAT to AFTR.

...FB: Thanks. Good catch.

P.4:       AFTR: Address Family Transition Router (also known as "Large
Scale

      NAT (LSN)" or "Dual-Stack lite Tunnel Concentrator", or "Carrier

      Grade NAT").  An AFTR combines IP-in-IP tunnel termination and

      IPv4-IPv4 NAT.

Suggest to remove "(also known as "Large Scale

      NAT (LSN)" or "Dual-Stack lite Tunnel Concentrator", or "Carrier

      Grade NAT"). "

...FB: OK.

P.4: TID: Access Tunnel Identifier.  The interface identifier of the

      point-to-point access tunnel.

In the GI-DS-lite context, my understanding is the GW is a L3 device,
the TID (e.g. SID of the PPPoE) could be used to map to a CID. The two
usages I can think of in the draft is mapping the SID to the GRE-key and
SID to the IPv6-Flow-Label. But since MPLS-VPN and IP-in-IP are using
AD's source IP address for the CID, the TID won't be used. In case of
WiMAX, no TID will be assigned to the AD. This isn't discussed clearly
in the draft. Do you think we should write a session to capture this?

...FB: Agreed. Let's look at things again: Right now the draft states
that "Local policies at the Gateway determine which part of the traffic
received from an access device is tunneled over the softwire to the
AFTR." As you note, a tunnel identifier could be one way to identify
traffic from an AD for some deployments, the source IP address could be
another way for another type of deployment. How about adding another
sentence: "Deployment dependent, ADs can be identified by either the
source IP-address or an access tunnel identifier" - and then removing
the verbiage on "TID" in all the other places?

P.4: The combination of CID and SWID

   (potentially along with other traffic identifiers such as e.g.
interface, VLAN, port, etc.) serves as common context between Gateway

   and AFTR to uniquely identify flows associated with an access device.

Suggest to rewrite to: "The combination of CID and SWID must be unique
between gateway and AFTR to identify the flows associated with an AD." 

...FB: We can make this change, but should be cognizant of the fact that
we change the meaning here. The original sentence would allow for
deployments where CID and SWID are insufficient to identify the flows
associated with an AD - in which case another identifier would be needed
(like a VLAN). That said, I think this is a bit orthogonal to the draft,
so I'm fine with the suggestion to change the text.

P.5: The outer/

   external IPv4 address of a NAT-binding at the AFTR is either assigned

   autonomously by the AFTR from a local address pool.....

Suggest to rewrite to: "The NAT binding of the AD's address could be
assigned autonomously by the AFTR from a local address pool....."

..FB: ok

P.8:  Softwire identification is supplied

      by the endpoints of the GRE tunnel.  The GRE-key serves as CID.

Suggest to rewrite to "SWID is the source address of the GRE tunnel from
the GW.  The CID is the GRE-key assigned to the AD.

..FB: ok

P.7: MPLS VPN: Softwire identification is supplied by the VPN

      Identifier of the MPLS VPN.  The IPv4-address serves as CID.  The

      IPv4-address within a VPN has to be unique.

Suggest to rewrite to "SWID is the MPLS VPN label. The AD's IPv4-address
is the CID.  Give a MPLS VPN label, the AD's IPv4 address must be
unique.

..FB: ok

P.7:  Softwire identification is supplied by the

      endpoints of the IP-in-IP tunnel.  Either the inner IPv4-address

      serves as CID (in which case the IPv4-address has to be unique) or

      the IPv6-Flow-Label serves as CID (which obviously only applies to

      cases where IPv6 transport is used).  Note that when using the IP-

      Flow-Label as CID additional scaling considerations might apply

      given that the CID is to only 20 bits wide in this case.  Also one

      should ensure sufficient randomization in this case to for example

      avoid interference with other uses of the IP-Flow-Label, such as

      ECMP.

I think it would be more clear to separate the discussion for
IPv4-in-IPv4 and IPv4-in-IPv6.

Suggest to rewrite to:

"IPv4-in-IPv4: SWID is the outer IPv4 source address. The AD's IPv4
address is the CID. Given an outer IPv4 source address, the AD's IPv4
address must be unique.

IPv4-in-IPv6: SWID is the outer IPv6 source address. If the AD's IPv4
address is the CID, the AD's IPv4 address must be unique. If the
IPv6-Flow-Label [RFC3697] is the CID, the AD's IPv4 address may be
overlapped. IPv6-Flow-Label is 20-bit wide which is shorter than the
recommended 32-bit CID. In addition,  one should ensure sufficient
randomization to avoid possible interference with other uses of the
IP-Flow-Label, such as ECMP."

P.9: May want to update Figure 3 to separate the two IP-in-IP cases.

..FB: ok.

Thanks for all your suggestions. We're working on updating the draft -
and will have a revised version (also including Olaf's and Paco's
changes) out shortly. 

Regards, Frank

Regards,

Yiu