Hi,
* Supported Alternate Tunnel Encapsulations
The Num_Tunnels field is redundant. This value can be derived from the IEs
length since the Tunnel-Type is a fixed length value.
* Alternate Tunnel Encapsulations Type
Is differencing between GRE-IPv4 and GRE-IPv6 really needed?
The transport protocol can be derived from the type of the address IE. On the
other hand, we might want to support GRE tunnels with
fall back to the other transport protocol (i.e. prefer IPv6 endpoint but fall
back to IPv4).
I would suggest to simply calling it GRE and derive the transport protocol from the address IE and/or the resolved IP in case a FQDN was
specified.
* Alternate Tunnel Encapsulations Type Information Element
The IE format is quite different from the other IE's used in CAPWAP.
The content of any other CAPWAP IE only depends on the IE type. For this IE the
content depends on the IE type *and* the tunnel type. I
would much prefer to keep this IE in line with the others and have one IE for the alternate tunnel type and additional IE's to specify the
tunnel parameters. This would also better suite tunnel protocols where you have optional arguments.
* AR FQDN List Element
No other CAPWAP IE does use FQDN's to specify IP endpoints. I don't see why we need to start here, the AC can always resolve FQDN's to IP's
and provision those.
* Alternate Tunnel Encapsulation Type
Reserving encapsulation types without specifying them completely seems a bit strange. But as long we do that, could we also reserve a type
for GTPv1-U (3GPP TS 29.281: http://www.3gpp.org/DynaReport/29281.htm)
Mobile networks use GTP already and 3GPP already defines mobile network to WiFi handover procedures. Supporting GTP alternate tunnels on
CAPWAP based WiFi AP would fit nicely into that.
Regards,
Andreas
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
