Hello Satoru,
Follow-up on a couple of details below...
On 11/29/2017 11:43 PM, Satoru Matsushima wrote:
Thank you Charlie, for your comments.
You're more than welcome!
As a general comment, I found it confusing about whether "legacy" means IPv4, or
"non-SRv6" IPv6. For instance, I am not sure about whether "D::1" is IPv4 or IPv6 in the
first paragraph of section 6.3.1. As a related matter, I think that relying solely on terminology like S::1,
D::1, A2::1, A2::B2, and so on soon becomes confusing. More diagrams would be nice.
Those represent 128bits of IPv6 source address, destination address and segment
IDs. I suppose that the reader in the IETF can understand that. If not, yes
need to improve it that introduce diagrams looks a good idea.
The addresses do indeed look like IPv6 example addresses. But somewhere
in the nearby text, there is reference to an IPv4 address as well. So I
was not really sure.
It should also be allowed that rate limiting is not done when there has not
been any such rate-limit Locator provided.
Correct. But it seems too obvious for me.
It's obvious to me also. But to 2,000 readers, it won't be obvious to
every one of them.
The document states:
...... the mobile control-plane may
assume that one user-plane entity has one IPv6 address ...
I'm pretty sure this isn't true for IPv6 nodes.
I think it is true. I haven’t seen any document of which _mobile_ control-plane
has the notion of node of user-plane in addition to just endpoint address of
tunnel in its protocol.
All IPv6 nodes have link-local and multicast addresses in addition to
their "normal" addresses. Plus, in general, it has to be allowed for
mobile nodes to have multiple addresses. I also strongly suspect that
the active forwarding nodes will often require multiple addresses,
especially if SDN is involved. Or network overlays, or NFV.
Regards,
Charlie P.
_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm
