Minutes IETF117: bier
minutes-117-bier-00

Meeting: IETF117, Friday 28 July 2023
Location: Hilton Union Sq, Plaza B, 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>, Hooman <hooman.bidgoli@nokia.com>

0       WG status
      no comments.

1       BIER MLD
       Tony Przygienda: there are six authors in the draft.
  
Stig Venaas: we may explain or move some authors to the contributors.
  Tony
Przygienda: not for holding the process of this draft. but in case there are
multiple DF candidates, DF may be selected for this. Stig Venaas: it may be
solved by configuration to make sure you only enable one DF, or run PIM to use
PIM DF election. Ice has a draft to discuss the election may years ago. We
think to move this draft to publish with restriction and then work on the
election of non-PIM DF election.
     Tony Przygienda: we can publish this
draft, push the problem and let people know that there is any other solution
except PIM DR election.
Chairs: start the polling for “should we wait for the
general election draft?”
The poll result of raise_hand: do_not_raise_hand is
8:1.
      Greg Shepherd: since we have a draft talking about the general
election function years ago, when you’re going to work with Ice or take it
over.
Stig Venaas: will talk with Ice.

2       BIER OAM
        • BIER Ping
    Tony Przygienda: please check the number of author list
        according to the author number limitation.
     Greg Mirsky: already
        done.
     Tony Przygienda: BIER ping is the very important OAM draft.
        more people review is better.
      Greg Mirsky: implementations
        sharing welcomed.
 Hooman Bidgoli: Nokia has implementation. but needs
        to check the TLV changes.
  Greg Mirsky: core message is still the
        same. may send you questionnaires for the implementation information
        collection.

        • BIER BFD
     no comments.

        • BIER performance measurement
 Tony Przygienda: about the individual
        draft you mentioned in IPPM WG, did you call for WG adoption for it?
  
          Greg Mirsky: during our presentation in IPPM WG, IPPM WG chairs
        raised some technical issues but they are not object to the adoption
        call if we want before IETF118 meeting.
   Tony Przygienda: what’s the
        relationship of the two drafts? if BIER BFD applies automatically?

        Greg Mirsky: the individual draft in IPPM WG defines the function and
        is underlay agnostic. it can work with IP, MPLS or BIER.
 Tony
        Przygienda: applicability deployment consideration or something else
        may be considered to see if there is any special to BIER.
    Greg
        Mirsky: Yes. so we solicit BIER WG to provoke the thinking.
       Tony
        Przygienda: so the bitmap mapping in BIER has been defined, right?
    
           Greg Mirsky: Yes. definitely

        • BIER OAM requirements
        Greg Mirsky: would like to know how the
        draft going.
   Tony Przygienda: preserve it.
  Greg Mirsky: wants WGLC
        for it. Alvaro raised the question of consistency between performance
        measurement and OAM requirements. it may apply to all the BIER OAM
        documents.
    Tony Przygienda: at least BIER ping should be considered.

3       BIERin6
        The co-author request WGLC.
    Chairs start the
polling for it, 10 positive and 0 negative.

4       BIER-TE
        • IS-IS/ OSPF/ OSPFv3 extensions for BIER-TE
   Jeffrey Zhang: suggest
        combine all the BP and BIFT-ID signaling of the three IGP extensions
        (IS-IS, OSPF and OSPFv3) into one draft.
   Huaimo Chen: we follow the
        older style of BIER IGP extensions.
 Jeffrey Zhang: I think it’s in
        early BIER developing process. Now BIER is already in premature and the
        BP and BIFT-ID advertisements are just incremental additions to the
        existing protocols. And IS-IS, OSPF and OSPFv3 has been covered by the
        same LSR working group. So I think it makes sense to combine all the
        BIER-TE IGP underlay signaling such as BPs and BIFT-ID into one draft.

         Huaimo Chen: Maybe we can merge them into two drafts, one for IS-IS,
        one for OSPF including OSPFv2 and OSPFv3.
 Greg Shepherd: I see there
        is few information in each of the BIER-TE extensions drafts. It may not
        always make sense if we’re defining the same extension for different
        protocols in different drafts. A clear document is better.

        • BIER-TE LAN
  Sandy Zhang: IMO this situation may not existed because
        this can be avoided by configuration or controller. The controller
        knows all the network details and can find the way to avoid wrong
        encoding.
 Huaimo Chen: for the example I listed there is duplicated
        packet existed even if we use the controller. the existed BIER-TE RFC
        (9262) indicates that all the nodes only know the local and adjacent BP
        in the network and don’t know the remote BP.
   Sandy Zhang: if you
        read RFC9262 carefully you will know if you want to build a multicast
        tree in this scenario you must make some necessary pieces. The
        controller is intelligent and will know the duplication and try to
        avoid it.
  Andrew Alston (AD): good discussion and please continue in
        the mailing list.

5       BIER extension header
  Greg Mirsky: we may consider the discussion of
MNA.
    Andrew Alston (AD): if you want to make alignment with MNA you should
be careful.
      Tony Przygienda: it’s interesting topic and we should pay
attention to MNA because BIER is 2.5 layer.
  Greg Mirsky: as Andrew said, MNA
has adopted framework, requirements, use cases and ISD encapsulation documents.
But we are still looking for if there is any use case that cannot be solved by
using ISD. Now all the use cases listed in use cases document can be solved by
using ISD solution. So for BIER use case if it’s real that it cannot be solved
by ISD. it’s good to join the MPLS discussion and give the feedback from BIER
perspective.
       Jeffrey Zhang: we will consider if it’s urgent if PSD will
not make progress in MPLS. The reason we want to go with the PSD solution is
that the ISD bit set is not aligning with IPv6 encoding. The extension is not
only for MPLS, but also for IPv6 and Ethernet. So mostly we are considering the
applicability of IPv6.
   Greg Mirsky: it’s valid concerns. but for BIER use
case we need to find that if there is anything cannot be solved by ISD.
    
Sandy Zhang: Whatever PSD will be adopted by MPLS or not, we should consider
the extension header from BIER perspective.
       Jeffrey Zhang: originally we
try to do it for next header concept, we may no longer say that we are trying
to align with MPLS and take it more for IPv6 next header.
   Tony Przygienda:
we should look at the requirements document to see if it applies to BIER.
    
Tony Przygienda: for the details of extension header, it’s confused that there
may have similar encoding and different semantics. you may have a common block
for silicon stuff but the op code at the end is different semantics.
    
Jeffrey Zhang: yes, it may be more complicated for the assignments. we may talk
more about it.
 Tony Przygienda: encourage somebody to take the requirements
document and see whether we have more requirements and which of the
requirements apply to BIER.
   Jeffery Zhang: now a concrete use case for BIER
is IOAM. Fragmentation and security are things we could do but may not be
mandatory.
   Tony Przygienda: for freedom in design so it doesn’t have to be
done now but if it’s architecturally important, that’s already a requirement as
far as I see.
  Greg Mirsky: Since MPLS is still discussing the IOAM topic,
it’s good for BIER to provide the points from BIER perspective to see the
difference between ISD-based solution and PSD-based solution.

6       Discussion of BIER interop events
      Jeffrey Zhang: there are some
off-line discussion about BIER interop events as part of hackathon in Prague. I
will send the email to public BIER mailing list.
 Greg Shepherd: who do we have
confirmed so far?
        Jeffrey Zhang: Nokia, Juniper, Huawei and ZTE have
the indication but that’s just unofficial. I forgot to send email to Cisco.

Greg Shepherd: don’t forget B4 implementation.
 Hooman Bidgoli: we may need to
make sure how do we make the devices connection., because some implementations
using simulator and some implementations like Nokia using the actual hardware.

  Jeffrey Zhang: even in simulator there may need hardware though the
connection by simulator may be easier. They all are the details we need to
figure out. we should have the discussion ahead.
        Greg Shepherd (without
chair’s hat): let me know if you need an independent third party to sit in the
middle. ----end of the session----