Minutes IETF106: bier
minutes-106-bier-00

IETF 108 Singapore
BIER WG Minutes
November 21, 2019

draft-zwzw-bier-prefix-redistribute-03 Sandy
This draft has been presented 3 times and would like adoption.

Jingrong: ItÕs useful. BFR-id imported from outside the area with
summary route. This should be the prefix because RFC8401 requires
that Bier info required with host prefix but bier architecture says bier
info should be advertised by ip address (host prefix).

Sandy: When the host prefix can be advertised by different areas 1 by 1
the host prefix and BFR-id can be advertised at same time. But if we
need to use default or summarized route across many areas need to
use a new method so we propose new extension point so two solutions
can be used together. If you only advertised prefix 1by1 you can use the
existing advertisement but if you want to use summarized or default
route you must use a new method otherwise you canÕt carry the BFR-
ids.

Hooman: this is an interesting problem. CanÕt understand the
summarized or default route. Are you proposing the ABR track the
BFRs? Or BFIRs? On one area? And create TLV with all BFR-ids and send
to the second area? How to propose summary route will advertise all
BFR-ids in core area into area 1 or 2. You would need to advertise an
entire list of BFR-ids.

Sandy: would like to merge all areas into one bier domain. R3 and R4
donÕt need to be the BFIR/BFER. Just BFR in the forwarding plane. We
use advertisement for prefix redistribute into core area. Just advertise
summary route into the core network. Just a control plane IGP
advertisement, an extension to IGP.

Homman: as long as summary and BFR-id in the access areas are flat. If
you have BFR-ids that are very sequential and flat in one area it will
work because you have the BFR-id range. If BFR-ids are not flat you will
have to go one by one. That would be a large packet going back and
forth.

Sandy: ItÕs just a configuration/administration requirement. If you can
configure with same range in one area it can be advertised with only a
few summaries. It depends upon your configuration of the BFR-id. Most
continuous BFR-ids is the most efficient way.

Jingrong: I assume for R3 and R4 it should support bier forwarding. R3
should advertise its own BFR-id and its own bier encapsulation, bier
label with imported BFR-ids into the area.

Sandy: if we build the whole network into one bier domain just flood
the extension in the network.

Jingrong: it has to advertise the bier encapsulation sub TLV. That sub-tlv
including the sub-tlv and sub sub tlv is the same as rfc8401. Sub tlv
should use the same host prefix as the sub sub tlv.

Sandy: if R3 would like to advertise multiple prefix you should carry the
associated ids of BFR routes. If R3 would like to advertise multiple
prefix in one advertisement such as summary you should carry the
associated BFR-ids

Ice: the summarization is only an optimization. You can flood them
through and they are 1:1. Its only 256 updates anyway. But if you do
summarized that ABR will put its own loopback as the BFR-id. ItÕs not
complicated.

Stig: do you allow sub sub tlv with the bier sub sub tlvs. Example: mtu.
If you do mtu sub sub tlv for bier prefixes it would be helpful to do so
here as well. It may be helpful to use the current sub sub tlvÕs to be
used with this.

Sandy: MTU extension is welcomed. Future version.

Jingrong: summary route may work in some cases, need to update bier
architecture because it requires ip address.

Sandy: the IGP usually uses summarized ip prefix.

Jingrong: I will point this out on the list.

Greg: majority of the room read the draft. All readers think it should be
adopted. Dozen or so.


Bier pim signaling v8 Ð Hooman
Updated text for ECMP and pim signaling join attribute AF
Next steps: solutions considered complete. Wglc? WeÕve done wglc on
this draft twice.

Greg: 10 or so people have read it and feel it is ready. Wglc will be
accelerated.

Stig: it should be good from pim perspective. Will send email to pim wg.
Will do last call together.

Mankamana: will it be two weeks last call?

Greg: no it will be accelerated.


mldp signaling over bier Ð Hooman
Trying to extend any legacy multicast protocol over a bier core w/o
affecting the access legacy multicast protocols.
Received some comments to clarify certain aspects of the draft.
Asking for wg adoption.

Greg: who has read the draft 8. Who thinks itÕs ready: 8


Draft-venaas-pim-igmp-mld-extension Ð Stig
Bier extension to igmp/mld as an overlay.
Good to identify the bier ingress routers. Who the join came from.
Extend igmp/mld messages. DonÕt want to make changes to the
protocols.
Draft probably belongs in the pim wg since it defines an igmp/mld
extension and registry.

Greg: in other examples we brought the work here and completed the
protocol work in the protocol groups. Same can be done here.

Stig: we think it is good to have an extension type in case there may be
multiple extensions for multiple purposes.

Stig: may have one extension/registry document in pimwg on why we
need to extend igmp/mld. And then a separate document on the use of
it in bierwg.

Toerless: the world pim should be removed from the title

Stig: it could be a pim wg document

Toerless: we still have this with bier, why to do the overlay vs pim.
When would this be preferable over pim. Every edge router doing pim
also supports igmp.

Greg: if you have host connected networks. You would do pim if
connecting pim domains otherwise its religion. If you are just going to
use it as signaling independent of what your edges are then not certain
why you would pick one over the other.

Toerless: more natural in pim to have the concept of RP. This one is
helpful if I want to kill of pim and simply to ssm. If there is any chance
to give guidance. pim or igmp. We are giving so many alternatives and
want to make bier successful. CanÕt implement everything at once. Give
guidance.

Stig: running bier to the edges you donÕt need a pim implementation on
the routers.


Draft-venaas-bier-pfm-sd-00 Ð Stig
We have this flooding source info for pim today and would be nice to
work with bier as well.
This could be useful for pim overlay as well.
New PFM BIER ingress TLV. Similar to BSR, no RP needed.
If you have bier in the middle between two pim domains and make use
of pfm. You need pfm messages to pass through the bier domain. The
minimum functionality is for the messages to be encap through bier.
But also add this new tlv could be used for bier routers to decide where
to send the pim joins. To help decide who is closest to the source. Could
come up with some sort of hashing.

Sandy: works for bier overlay. Used to collect the (S, G) info across the
bier domain, right?

Stig: if you have pim and have bier in the middle and deploying pim
signaling over the bier and then this extension can be used for the pim
signaling to decide where to send the joins. But also if you have
deployed pfm in pim to begin with and want bier in the middle you
need this for pfm to function. Also if you deploy pim signaling overlay
this can help you to determine where to send the joins, what the bier
ingress routers should be.

Sandy: you should send messages from BFIR nearest to the source.
What destination in the bier header?

Stig: we want the receiver side router to determine which way to send
joins. Sent all the bier routers. Set all the bits.

Alvaro: You getting the metric from IGP in the bier domain?

Stig: yes. TLVÕs are not modified as you go through the bier domain.

Alvaro: you are going through multiple areas that have multiple metrics
and routing protocols. If you were to pass that and use the metric
inside the bier domain it may be weird. ThereÕs functionality in BGP
that tries to do the same thing. Accumulated ip metric. Closest isnÕt
always going to be who gave me the route. Take a look at that.

Sandy: if metric is going to be from many ways, maybe we can add a
section in the draft.

Stig: one thing to consider just have a simple draft that describes the
pim functionality and the metric can be something addition if we feel
itÕs useful.

Stig: please read the draft and provide feedback.


draft-nainar-bier-flex-algo-00 Ð Mankamana
How to use flex algo in the bier domain.
More details at next ietf.

Hooman: this is something we definitely need to work on in the bier
wg. Need more thinking.

Tony: how the algorithms are managed are not that important.

Ice: the lable just describes the bift-id.

Sandy: bier use igp as underlay. Just can use these igp extensions to
achieve flex algo. DonÕt understand if not more should be doing bier.

Mankamana: igp extension will give.

Sandy: there will be a mapping.

Greg: 6 have read the draft and all six feels it should be adopted.


draft-ietf-bier-evpn-02 Jorge
Jeffrey has presented this a couple of times.
Request feedback
Ready for wglc

Mankamana: did you take this to bess as well? Good idea.

Sandy: we will inherit all the encapsulation types. Only see 3 tunnel
types, vxlan, geneve, gre but there are many tunnel types. Will you
expand draft to include all of the tunnels?

Jorge: we are interested in the ip destination address.

Sandy: the main idea is to use the tunnel encap for the data packet.
Want to use tunnel encap for data packet. Many tunnel encaps can be
used. If we only specify 3 types of tunnels after the bier header.

Jorge: this is mainly done work in bess. Ip overlay tunnels. These are the
3 main tunnel types specified there. This draft just focuses on those.

Alvaro: the tlv has a bunch of other stuff you donÕt care about.
Eventually please write what should happen when you receive a tlv
when a tunnel type is not support.

Greg: 5 have read. 5 support.


Bier-te-arch - Toerless
Wglc since 104
More reviews welcome so we can finish the last call.

Greg: please review. We will restart the last call.


draft-ietf-bier-ipv6-requirements Ð Mike
Update requirement section since last IETF.  During this process
pros/cons wording have been removed.
There are two draft being worked on.
All reference to SRv6 would be removed from document
Solution summary would be moved to appendix.
Review expected from WG and feedback would be helpful to make
document proper.
Currently 12 requirement discussed, more discussion in list.
Tony sent detail email about 2, 3, and 9. 4, 3, 2, 11 needs discussion. It
does not require fragmentation. It changes architecture. We would
need more discussion.
Jumping multiple hop is like tunneling technology.
BIER is layer 2.5 solution. It has not been made clear in RFC BIER. BIER
RFC allows fragmentation.

Jingrong: there are many operators where number of end host are
really in high numbers. Network is IPv6 ready, it might be good have
BIER for those network.  There are some limitation in this draft.

ItÕs not ready for WGLC yet. Requires some more work before it gets
ready.


draft-xie-bier-ipv6-encapsulation Ð Liang
Have improved the draft a lot.

Hooman Ð ipv6 is a hot topic. Sooner or later we need to have one
solution. DonÕt make unicast mistakes. Very close to bier in 6 draft that
is going on. Maybe combine drafts? Security aspect Ð that is very
interesting. For bier do we want to entertain all the v6 quirks including
security? Ipsec, etc will come into play.

Mike Ð Need to decide if we entertain the two primary solutions drafts
along with requirements draft or wait until requirements draft is wglc.
Really two drafts primarily worked on, should consider adopting both
and later submit one draft to iesg.

Ice - doing this in extension header doesnÕt add value. Bier in 6 removes
the extension header. Too early to ask for adoption, just want one
solution moving forward. We could adopt two at first but probably
better to adopt one to begin.

Greg Ð Merging beforehand would make more sense but nothing
preventing us from adopting two drafts.

Aijun Wang Ð China Telecom. Extension headers has accelerated
adoption of ipv6 so itÕs a good approach.

Liang GengÐ DA field is for bier. We could discuss oam for bier offline.

Tony Ð bier has a full oam layer. ItÕs a 2.5 layer solution. And now you
are extending to a L3 tunneling technology and extending it on the fly.
You are trying to replace it with ipv6 oam. Needs an architecture
document.

Jingrong Ð agree with Hooman. Converging two solutions is possible.
Only some differences between the two solutions.

Greg: encourage constructive comments. Show us how itÕs helpful.

Adjourn