Minutes IETF116: bier
minutes-116-bier-00

Meeting: IETF116, Friday 31 March 2023
Location:  Pacifico Yokohama North, G412-G413, 12:00-13:30
Chairs: Shep <gjshep@gmail.com>, Tony <tonysietf@gmail.com>
Secretary: Sandy <zhang.zheng@zte.com.cn>
Minutes: Sandy <zhang.zheng@zte.com.cn>

0. WG states, WG chairs, 10 minutes
draft-ietf-bier-ospfv3-extensions document in IESG and draft-ietf-bier-evpn
Andrew : Question to tony about OSPF v3 drafts, and we are waiting on update
and write up Tony : it has been completed. Andrew : Did not get any
notification . shephered needed for some of the document in WG. As WG we still
need to deliver the OAM work based on our charter. Tony : there is lot of work
needs to be produced as working group

1. BIER OAM WG drafts, Gregory Mirsky, 10 minutes
---we have four WG document in BIER. BIER Ping need to move forward as other
drafts are depending on this. BIER Ping document is ready and all the comment
has been addressed. Tony : Does BIER ping document had major change which need
one more WGLC ? Greg : No it was editorial changes ---BIER path MTU discovery
ready for next step. It requires BIER PING document to make progress. ---BIER
BFD ready for WGLC. Andrew: Early RTG review needs to be initiated. Tony :
Early review would be initiated. Andrew : if we can finish early directorate
review it would progress faster Tony : is RTG review mandatory ? Andrew : Yes
---Hybrid Performance Measurement in BIER.Ready to move forward. Tony : Has IPR
been disclosed ? Greg : Need to check on that Tony : requirement and framework
document are expired, are we going to just let it go or do last call ? Greg: WG
to decide. document has served it purpose already. Andrew : if there is
requirement document which helped to generate new work in WG. it would be good
to revive and publish. people would have track record for why something was
done ? Tony : Greg M to revive the work. and we would do WGLC and there is no
need to more review. Toerless: if requirement document is informational then we
may not need to publish. Is there any implementation. Greg M : there is one
vendor who has implemented LSP ping.

2. BIER Prefix Redistribute, Sandy Zhang, 5 minutes
---new update from last version
---document is ready for WGLC
Siyu Chen: question about prefix whether its single address or it is multiple
BFR. Sandy : you can use both method. Tony : it would be good to add section
clarifying it. Siyu: base RFC BIER says prefix has to be address. We can take
discussion to list. Tony : does BGP summarization violates that ? Siyu : Yes
Tony :please take the discussion to mailing list so we have documentation.

3. BIER Anycast, Jeffrey Zhang, 15 minutes
---BIER RFC8279 did not cover anycast. so this draft is to close the gap.
Toerless: document is not clear whether anycast is talking about source or
receiver. Jeffery: it does cover both of the case. Toerless: it would good to
clear up the draft talking about different cases. ---two drafts in this area
Toerless : will receiver anycast work ? Jeffery : it need to be implemented
with MoFRR Tony: we would need to think of capability somehow. it will help to
deploy multi-vendor network. Siyu: for same PE multi-home to two different CE
then draft says we can have two BFR prefix. does it mean overlay and underlay
being co-related or tightly coupled ? Jeffery: we can look at base RFC and see
if things need to be changed.

4. Update on RBS and related work, Toerless Eckert 10 minutes
Ice : have sent question in list and currently it has not been solved. it is
really needed where we can have sniffer in network and being able to encode the
packet any time. Toerless: MPLS also has same analogy. Ice : sniffer on wire
can always decode the encoding. and it is not true statement for MPLS Toerless
: we dont need to really see the whole packet. or decode the packet for better
forwarding.I may not agree that we really to be able to decode the packet . and
just to add this capabilities we would not be efficient in forwarding. so its
better to be efficient Tony : does it not boils down to argument that first
field which we decode is length indication. Toerless: i do not think we should
be really able to decode whole tree which has been encoded in packet. same way
you do not decode the stack of protocols which you are processing and do not
care about . Ice : just because of its hard we can not discard the fact that
protocol need to be reliable and something which can be troubleshooted. Andrew
: speaking as individual , for vendor its critical to be able to decode the
packet. as its being used for different application in network. so it is going
to be important for any operation. Toerless : but we can not decode encrypted
packet without key.not all has to be solved in forwarding plane. Andrew:
accounting really need basic information without knowing full semantics. Tony :
its good progress related to RBS work and it can be used to solve the use case
which being discussed as part of presentation later . As WG we would have to
see if we can work on this area. Ice : it would be good to first work on
foundation before spending time in implementation to avoid re-testing.
Toerless: P4 community may play without it being standard as part of research.
Ice : do we want only this to be part of research ? Toerless: No, we want it to
be deployed too. Andrew : as AD , if WG thinks that this work needed in this
WG. then it is ok to add in charter. and i feel it would fit in overall
framework. we would need to find if there is enough interest to work on this.
Poll Who would contribute to work on RBS in BIER WG Yes 8 No 7 Need more
discussion in mailing list.

5. BIER-TE PCE&IDR, Ran Chen, 10 minutes
Dhruv : Do we need to have adoption in PCE working group
Tony : need to provide some time to WG
Jeffery: i think it is useful work. adding BIER would be good option in PCE.
Email discussion can happen with other relevant drafts.

6. BIER-TE BIFT-ID advertisement, Sandy Zhang, 10 minutes
Siyu : The Max SI field may need to be added.
Sandy: The BIFT-ID allocation for BIER-TE is different with BIER, the BIFT-ID
of BIER-TE is per SD and BSL, so the number may not be too large. But it can be
added for alignment.

7. BIER Multicast use cases in DC, Weiqiang Cheng, 10 minutes
Tony: to summarize, if BIER can be used with sub-domain and other options. we
can accommodate. But if there is frequent join and leave , we need to work on
addressing the gap in this working group. RBS could be one of the possible
solution and may be some alternate solution Existing multicast solution can not
satisfy this requirement. From china mobile : this requirement can not be
served by current protocols because scale would keep changing. are we going to
change the charter again and again. Tony : it would be productive if authors
discuss what is needed from working group. If mind has been made that this WG
group can not solve this, then we have nothing to discuss. Andrew : There is
requirement. and may be some work needed. Its good to see if we could get work
done in BIER WG. if there is need to modify charter of WG , i am ready to do
that. WG group need to find way to work here so that it can speed up. exploring
within this forum would be good option. It is good to see requirement has been
presented. and hearing WG , it looks like we have way to solve it here in this
working group. Weiqiang Cheng: DC requirement are totally different Andrew : DC
portion and multicast portion are two area we can see in this requirement. but
for DC portion there is discussion going on. and it is going to take time and
it is not blocker for exploring if multicast work can be solved in this WG.
Weiqiang Cheng: if we start working with legacy technologies we may not move
fast Tony : this is one of the fast WG. within 8 years we have multi-vendor
solution. If authors think that we can have proprietary solution then WG can
not help. Hooman: it would be good to have example of application. what about
cross Data center ? are they going to different data center using some link
between DC. I agree to tony, if you look something quick then we have to use
existing one. Weiqiang Cheng: If we want to use BIER, we do not have silicon
which can support it. BIER failed because of its very larg network. DC is new
model, you can deploy new solution. Hooman: if we come up with brand new
silicon , it would take 10 years Weiqiang Cheng : we are looking for new
solution even if it takes time Andrew : please keep the discussion in mailing
list and keep it restricted to requirement.

8. BIER-TE BP advertisement, Huaimo Chen, 10 minutes
Not presented because the session run out of time.