Re: [Bier] draft-ietf-bier-ipv6-requirements-09

["Jeffrey (Zhaohui) Zhang" <[e-mail]>]

Hi Adrian,

Please see zzh> below.

From: Adrian Farrel <[e-mail]>
Sent: Friday, November 27, 2020 9:14 AM
To: 'Tony Przygienda' <[e-mail]>
Cc: Jeffrey (Zhaohui) Zhang <[e-mail]>; 'Greg Shepherd' <[e-mail]>; 'BIER WG' <[e-mail]>
Subject: RE: [Bier] draft-ietf-bier-ipv6-requirements-09

[External Email. Be cautious of content]

Summarising…

  1.  You wish we didn’t have to support tunneling over multiple IPv6 hops, but you think it’s going to happen so be better factor it.
We should capture that explicitly in the requirements doc.
  2.  Given 1, we have no control over what happens in the IPv6 network. We should probably try not to do anything that encumbers “normal” IPv6 operation. That includes ECMP (but probably other things).

I’m *really* trying to stay away from discussing the solutions and the consequences. But..  :-Z
We can take two approaches to ECMP…

  1.  Flow label and other primary fields are enough. Any attempt to look deeper into the packet is not necessary and if the router doesn’t understand the next header type it doesn’t matter.
  2.  Where the payload is IP, Ethernet, or an IETF transport protocol, the router should be able to access it to improve the ECMP hashing.

Now, that leads me to a solution-oriented conclusion, but I’m not going to voice it. Let’s stick to the requirements.

Zzh> The requirements draft will not discuss/evaluate solutions, but outside the draft, I won’t be shy to voice my opinion 😊
Zzh> Going forward, flow label based ECMP should be the norm. If an existing solution1 can do b), great but it’s not too bad if it can’t do b). If we’re designing a new solution2 that can do b) but introduces other complexities while the existing solution1 does not have those complexities, then I would still prefer solution1.
Zzh> Jeffrey

Cheers,
Adrian

From: Tony Przygienda <[e-mail]<mailto:[e-mail]>>
Sent: 27 November 2020 01:11
To: Adrian Farrel <[e-mail]<mailto:[e-mail]>>
Cc: Jeffrey (Zhaohui) Zhang <[e-mail]<mailto:[e-mail]>>; Greg Shepherd <[e-mail]<mailto:[e-mail]>>; BIER WG <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Bier] draft-ietf-bier-ipv6-requirements-09

<as individual>

On Thu, Nov 26, 2020 at 3:53 PM Adrian Farrel <[e-mail]<mailto:[e-mail]>> wrote:
Thanks Jeffery,

I think our discussion forks.
In one direction Tony says (possibly) don’t worry about legacy transit routers because we shouldn’t be tunneling through them anyway.
In the other direction we worry about legacy routers, and here you are suggesting we should hope that they are legacy-but-modern 😉 That doesn’t seem to work out for us because *if* we need to tunnel through non-BIER routers we should probably assume that they might be old enough to not be considered modern.

I do like your answer that if the BIER header is encountered as payload it will not be hashed because of the first nibble. I’d missed that and it handles the case of native encapsulation.

But I think that even legacy IPv6 routers that do ECMP are capable of walking the extension headers until they find a header that is a known protocol or until they find one they can’t parse. (But I may be wrong here.)

Now, we have got diverted (again) into discussions of what we can and can’t do with different solutions. We need to come back to the requirement:

Do we need to be able to tunnel through legacy routers? I am sure I hear Tony saying “no, that is explicitly excluded”.

I wish we couldn't but reality will be, people will throw tunnels multiple hops (and architecture allows that to deal with non-BIER HW inbetween)

If the answer is “no”, let’s capture that in the requirements doc.
If the answer is “yes” then we have a second question…
Do we need to provide ECMP in that tunnel?

well, it's IPv6 ECMP so who are we to argue how they do it. We should od the best we can to support v6 ECMP AFAIS but we don't have in BIER anything predictable but entropy field.

If the answer to that is “no”, we’re done.
But if the answer here is “yes”, we have to ask…
Is it enough to rely on the flow label (and src/dst), or do other fields need to be available.

right, so what's your take here? BIER doesn't offer anything except an entropy field and that's what we can provide. encaps'ing it in UDP just oget 5 tuple sounds desperate and pretty dirty (think vxlan) and what happens if we carry native ETHER or MPLS inside, parsing into the BIER paylod to figure out WHAT protocol is carried (v4, mpls or so) and then into that is possible but sounds like a really, really, really deep silicon lookup

what you're aiming at, Adrian?

-=-- tony


Juniper Business Use Only