Re: [Bier] AD Review of draft-ietf-bier-te-arch-09

[Toerless Eckert <[e-mail]>]

On Tue, Jul 27, 2021 at 12:04:17AM +0200, Tony Przygienda wrote:
> given it's IETF weeks and I'm staying up to 3am every day it's a good
> possibility to catch up on lots ietf threads/drafts ;-)

>From similar experience when i was doing it, i can just warn
that it is quite difficult to get off the caffeine addiction
incurred by too much coffee to stay awake ;-))

> yes, it's crucial to define the "separation" boundary in the architecture
> document here.
> "ships in the night" is too loose a term IMO, we need clear delineation, I
> think
> subdomain is a natural one (which Alvaro seems to have divined from the
> document ;-).
> So a BIER domain can mix TE and vanilla and
> I don't see anything wrong with that, such things were one of the reasons
> to do sub-domain, so we can do MT or flex-algo per sub-domain or completely
> change the
> semantics of the bitmask (well, as long it does packet replication in some
> form ;-). I think we're in sync here.

We have multiple options here, and without a lot of operational
experience pointing into one direction, i tried not to close doors.

The operator interface will be crucial to get more opinions.
To that end, in the IETF i hope the work on the yang models will help,
and i'll certainly help with that.

Personally, i do like the simplicity of saying SD-range A: BIER, SD-range B: BIER-TE.

> and as you know the wall you have to climb to justify a new encapsulation
> in BIER or even bend bits
> is famously high ;-)

Lets see. 30 years ago i would have asked Tony Li how long it
would take him to do a small change in forwarding code. Nowadays it might be
Michael Menth and team ;-))

Aka: The difficulty of bit bending is not a matter of code IMHO but platform
development and deployment processes. But there are networks other than big SP
core with processes competing with continental drift speeds.

Think about someone building a media switch for a broadcast house as a BIER network
wih P4 switches.  They would just do whatever they want in their P4 code if our IETF
BIER headers don't suit them and just maybe would they come back later to us and discuss
standardization (when being forced by customers). Benefit of limited domains...

Wrt to completely new headers:

If you have seen a draft i put into intarea and other drafts from Adrian
et.al., you know i would like IETF to think about an evolution of
the network layer from IPv6 (backward compatible) that allows 
for variable long addresses. If we had that, then it
would be a no-brainer to also put BIER into that address space as
we did put IP Multicast into IPv4 address space. Remember how we
discussed Pierre et.al.'s proposal to use IPv6 for BIER, and it just
was doomed because with so few bits it was just not good enough for BIER.

Aka: why go for your "famously high", when i can even try to go higher ;-))

If we had a common network layer where other use-cases beside BIER
could also use different size addresses, such as CCN, paths or others, it would
also help BIER because long addresses would be much less of a
surprise and concern by operators. And if one wouldn't need to invent
new headers for longer addresses, like we had to do for BIER, i am sure
more innovation will happen allowing to continue draw more value from
programmable hardware forwarders.

And of course, none of this is short term, and should start experimental,
and beyond what i said above also better discussed on intarea mailing list.

> So unless a use case is presented that cannot be met by the MPLS or
> non-MPLS encaps the WG
> has proven considerably prudent so far in this respect ;-)

Remember that there is life beyond IPv6, think for example also
about the never finished work we started with ROLL/IoT...

> nothing precludes BIER-TE from inventing a distributed protocol for TE IMO
> or do things like multicast RSVP-TE for BIER-TE AFAIS. At least
> architecturally it's all fair game.

good 8279bis discussion given how the orignal very much focussed on
what we know would work well (IGP). 

If we can make progress on YANG and BIFT for it, i hink that would help
most to figure out what architectural text we may want to improve.

> Given we're starting on adjournment to  8279 I think it would be a nice
> example to show how BIER-TE fits nicely into BIER architecture that properly decouples
> L2 & L3 abstractions it relies on from the semantics of BIER (*sub)-domain
> and its behavior as abstract replication capable  L2.5 substrate.

A chapter summarizing that relationship into 8279bis would be nice.
Otherwise if you have specific suggestions for BIER-TE draft, pls. le me know.

Cheers
    Toerless

> -- tony

-- 
---
[e-mail]