Re: [IPv6] next steps for draft-ietf-6man-ipv6-over-wireless

[Vasilenko Eduard <[e-mail]>]

Hi Pascal,
I did not expect that you would propose resolving P2MP by the additional layer of routing inside the subnet.
I am fine with it. I do not have objections to WGLC.

About nits:

I do not see a problem to insert my picture into the document.

>> Figure 2 is misleading (probably a mistake): The IP subinterface and IP subnet should have the same set of IP Links (the picture implies different, for example, A and B).
>I guess your point is that all IP links should be common, or none.
No. I was simply stating that IP subinterface==IP subnet. The picture wrongly assumed that they are not equal. Hence, may have a different set of IP links.
It is still the case after the draft update (an additional bracket does not help too much):
|   IP SubInterface a  ------------------> | IP Link A,
|      IP Subnet a::/64                    | IP Link B,


>> Moreover, the picture is double misleading because the IP subnet (and IP subinterface as a result) may have many IP links (the picture implies only one).
> You are right on the expectation.
Should be something like this:
   |   IP SubInterface a  ------------------> IP Links {A,B}
   |      IP Subnet a::/64 ------------------> The same: IP Links {A,B}
   |         IP Addresses a::1 .. a::n        IP Link A
   |         IP Addresses b::1 .. b::n        IP Link B

> This is very difficult because L2 links themselves are not well defined.
It is a poor excuse not to "document what should be done when an IP link consists of many L2 links".
In fact, it is documented when you discuss ESS or how the switch stitch "broadcast domains".
It should be more structured:

1.       ESS

2.       Proxy

3.       EVPN

4.       ...
With the clear message that it is stitching many L2 Links to one IP Link.
This stitching exists anyway. You just document it.

Ed/
From: Pascal Thubert (pthubert) [mailto:pthubert=[e-mail]]
Sent: Friday, May 26, 2023 2:12 PM
To: Vasilenko Eduard <[e-mail]>; IPv6 WG ([e-mail]) <[e-mail]>
Subject: RE: next steps for draft-ietf-6man-ipv6-over-wireless

Hello Eduard

I'd love to have a picture like the one you propose but I could not fold figures 1, 2, and 3 into one. If I try, it's going to be a graph like UML.

A SubInterface reaches a subnet, your picture is correct on that. Why do we need this concept? To allow the stack to source a packet in an address in that subnet, if more than one is available, and generally configure stuff that is specific to that subnet and applies to all the addresses that the host rotates with the same prefix. This is also the object that SNAC and prefix-to-the-host play with.

There can be multiple IP links connected to the SubInterface, you're also correct there. Why? Because a host may be multihomed, with more than one link connecting to the same subnet. The multihoming may be physical (think a cloud server with 2 physical ports on 2 leaves of the same fabric, and the same GUA(s) on both) or logical (using the P2P model on one radio interface where 2 routers are visible, and associating one P2P IP link for each over the same physical interface).

Over a P2P link, say we are a host receive an RA with 2 PIOs in it. This means that the IP Link is part of 2 SubInterfaces. This is where your picture starts to lack a bit, showing that 2 different subInterfaces use a common IP Link.

It gets worse trying to map the L3 concepts to L2 link. This is very difficult because L2 links themselves are not well defined. Think of LAG. Are they different links to different switches or a single link to a broadcast transit L2 link? IOW is the L2 link the first hop to the switch, or the whole fabric? We may be more interested in "broadcast domain" because that is something we experience with our link local addresses.

The IP stack does not see what's going on in the L2, but it is connected to the node's physical interfaces, and we may want to model those for the IP layer, e.g., to make sense of existing CLI that has intuitive (read loosely specified) concepts of interfaces and subinterfaces. This is why we want 1) to be able to continue doing things we did before, an IP interface mapping 1-to-1 to a physical interface and 2) extend that so the IP interface is whatever grouping we want so we can configure / operate IP things at that level

This is why the draft defines the concept of an "IP interface" as a logical collection of IP SubInterfaces. A stack may arbitrarily decide to map that collection on a physical interface, in which case we end up with the traditional concepts. But we would also configure it as any collection that is easy to manage.

There are still non-obvious architectural question to be solved by the group. As presented the model is very open. Are there constraints that make sense here, e.g., an IP Link is in a single IP Interface, so all the SubInterfaces that share an IP Link are in the same IP Interface?

> Could you mention that SGP (Subnet Gateway protocol) is optional and needed only for the case when the subnet consists of many IP Links?
Will do

> Figure 2 is misleading (probably a mistake): The IP subinterface and IP subnet should have the same set of IP Links (the picture implies different, for example, A and B).

I guess your point is that all IP links should be common, or none. In a classical network, yes. In a MLSN, I may have a backbone ethernet where prefix a and b are present and advertised by the same router, so I have a P2P link with that router that is present in both IP SubInterfaces a and b, and other physical interfaces where only a or only b is present in which I have P2P links with routers that advertise a or b respectively. E.g., I may have a "core" subnet a that spans buildings and edge subnets b c, d, inside the buildings. This about mesh intersection.

> Moreover, the picture is double misleading because the IP subnet (and IP subinterface as a result) may have many IP links (the picture implies only one).

You are right on the expectation. Now I thought that's what the figure represented. Fig 2 as I know it is :

   +--------------------
   |
   |   IP SubInterface a  ------------------> IP Link A
   |      IP Subnet a::/64                    IP Link B
   |         IP Addresses a::1 .. a::n           ...
   |                                          IP Link N
   |
   |   IP SubInterface b  ------------------> IP Link A
   |      IP Subnet b::/64                    IP Link D
   |         IP Addresses b::1 .. b::n           ...
   |                                          IP Link P
   |                ...
   |
   |  (Link A and B may be attached to different network ports)
   |  (Link A may belong to both subInterfaces a and b)
   |
   +--------------------


The intent is that links  A..N are connected to subif a. Would it be more clear as below?

   +--------------------
   |                                          +--
   |   IP SubInterface a  ------------------> | IP Link A
   |      IP Subnet a::/64                    | IP Link B
   |         IP Addresses a::1 .. a::n        |   ...
   |                                          | IP Link N
   |                                          +--
   |
   |                                          +--
   |   IP SubInterface b  ------------------> | IP Link A
   |      IP Subnet b::/64                    | IP Link D
   |         IP Addresses b::1 .. b::n        |   ...
   |                                          | IP Link P
   |                                          +--
   |                ...
   |
   |  (Link A and B may be attached to different network ports)
   |  (Link A may belong to both subInterfaces a and b)
   |
   +--------------------

> IMHO: you need to put a set {IP link X, IP link Y, ..} against all IP subnet/subinterface

Problem is less than 73 chars in one line, that is why I made it multiple.
Also, I'm trying to make the bracket visual as opposed to tied to one programming language. I hope the result is more intuitive?

> IMHO: P2MP is principally needed. Hence, it should be clearly discussed.

True. P2MP is a network with UNI host/router P2P links and NNI router/router links
We discuss extensively the former and say nothing much about the latter. Is that your issue?
IOW, what would you like to see in the P2MP section? Applicability?

All the best;

Pascal




From: Vasilenko Eduard <vasilenko.eduard=[e-mail]<mailto:vasilenko.eduard=[e-mail]>>
Sent: Wednesday, May 24, 2023 4:25 PM
To: Pascal Thubert (pthubert) <[e-mail]<mailto:[e-mail]>>; IPv6 WG ([e-mail]<mailto:[e-mail]>) <[e-mail]<mailto:[e-mail]>>
Subject: RE: next steps for draft-ietf-6man-ipv6-over-wireless

Hi Pascal,
You could say at the beginning of the document that only downstream multicast is the problem for wireless.
Upstream multicast is emulated by unicast anyway - typically not a problem.

I am a little worried about the additional complexity related to the new layer of abstraction (IP Link). IPv6 is already deadly complex. This step is in the opposite direction of simplification.
But it looks like needed.

Picture for possible IP subnet to IP link to L2 link relationships would help the reader. I am strongly missing it. If I understand you:


        [cid:image004.png@01D99017.D6DD3890]

Could you mention that SGP (Subnet Gateway protocol) is optional and needed only for the case when the subnet consists of many IP Links?

Figure 2 is misleading (probably a mistake): The IP subinterface and IP subnet should have the same set of IP Links (the picture implies different, for example, A and B).
IMHO: you need to delete the IP link reference against the IP subinterface or IP subnet.
Moreover, the picture is double misleading because the IP subnet (and IP subinterface as a result) may have many IP links (the picture implies only one).
IMHO: you need to put a set {IP link X, IP link Y, ..} against all IP subnet/subinterface.

The document is clear on what should be done when a subnet consists of many IP links - SGP protocol is needed.
The document is not clear on what should be done when an IP link consists of many L2 links (it is possible to guess by reading how it was resolved in different L2 technologies, but guessing is not a good option here).

All of the above was "nits".
But there is a principal problem that pushes me to vote against WGLC for this draft:
The promised solution for P2MP is just missing in the document - not discussed.
IMHO: P2MP is principally needed. Hence, it should be clearly discussed.
I guess what you would propose, but I am not 100% sure.

Ed/
From: ipv6 [mailto:[e-mail]] On Behalf Of Pascal Thubert (pthubert)
Sent: Wednesday, May 24, 2023 9:52 AM
To: IPv6 WG ([e-mail]<mailto:[e-mail]>) <[e-mail]<mailto:[e-mail]>>
Subject: [IPv6] next steps for draft-ietf-6man-ipv6-over-wireless

Dear WG:

We adopted that draft to publish it as informational; it is at the same time a state of the art, a problem statement, and an applicability statement.

The issues are clear and present, see also draft-ietf-v6ops-nd-considerations. We face customer situations where clients are not properly served because ND snooping fails to locate them all with a painful regularity. This impacts all sorts of situations, from wireless to fabrics / EVPN.

Note that This is indeed very related to the SLAAC operation and IPv4 is mostly immune. Meaning that the IPv6 experience is of more broadcasts and less reliability.

In order to progress in solving the issues raised, it makes sense to publish soon and move on. The draft has been progressing as an individual submission for a long time and it is mostly complete, IMHO. So my intent is to ask for WGLC sooner than later. To get there, reviews would be highly appreciated.

Many thanks in advance : )

Pascal