* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Bier Status Pages

Bit Indexed Explicit Replication (Active WG)
Rtg Area: Alia Atlas, Alvaro Retana, Deborah Brungard | 2015-Mar-24 —  

IETF-100 bier minutes

Session 2017-11-14 1550-1750: Olivia - Audio stream - bier chatroom


minutes-100-bier-00 minutes

          IETF 100, Singapore
          Tuesday, 14 November 2017
          BIER WG Agenda
           15:50-17:50 Olivia Room
            Chairs: Greg Shepherd
                    Tony Przygienda
             Notes by Donald Eastlake (Huawei)
           5 mins  Welcome, Notewell, Agenda bash          Chairs
          10 mins  draft-wijnandsxu-bier-non-mpls-bift-encoding  Wijnands
          10 mins  draft-bier-pim-signaling                H. Bidgoli
          10 mins  draft-hu-bier-bfd                       Fangwei Hu
          10 mins  draft-zhang-bier-bierin6-00
                   draft-zhang-bier-flooding-00            Sandy Zhang
          10 mins  draft-xiong-bier-te-encapsulation
                   draft-zcxh-bier-te-forwarding           Quan Xiong
          10 mins  draft-huang-bier-te-encapsulation-extension  Rache Huang
          10 mins  draft-xie-bier-mvpn-mpls-p2mp-00        LiuYisong
          10 mins  draft-purkayastha-multicast-http-using-bier  Purkayastha
          Remainder  (Re)Charter discussion                WG
          Chair: Shut the door. Release the hounds.
          Chair: We need a minute taker... Someone please help out here... All
          right, we got a minute take [Donald Eastlake] ... Note Well noted
          ...  We got a Jabber scribe ... Welcome to BIER ...
          Chair: Here is the agenda. [see slides] At the end we will have some
          Charter discussion going forward. Hopefully we will get some good
          dialog. Anything missing from this list? Any further names I can
          misspell? Welcome to PIM -- that was a joke.
          An Optional Encoding of the BIFT-id Field in the non-MPLS BIER
          IJsbrand Wijnands (Cisco)
          [See slides] ... Encapsulation discussion. Code sharing between MPLS
          and non-MPLS ... Xiaohu has epxressed the desire to have static
          allocated BIFT-id's. In this draft we define a way to create a static
          BIFT without the data-plane being aware.
             BIFT encoding = 20 bits
                For data plane must remain a 20 bit field but not parsed!
                  Globally unique.
          Greg Mirsky: Globally unique or domain unique?
          Answer: BIER domain unique.
          Document encoding so vendors are interoperable but no IANA action
          required. This is an informational draft.
          Tom Zekert: If this is just informational with no IANA actions, how
            does a router know that this encoding is being used?
          Greg Mirsky: By configuration or designate a range of 20-bit values,
            the same size as MPLS labels.
          Answer: Not a problem if you statically configure it all.
          Chair: Who has read the draft? Adoption poll. There is consensus in
          the room to adopt. Confirm on the list.
          BIER PIM Signaling
          Hooman Bigdoli (Nokia)
          Have changed name of draft from "tunneling" to "signaling" but were
          not able to upload draft in time. This draft name change will be
          made. [see slides]
          Questions keep coming up from service providers of how to connect BIER
          to legacy PIM services if it is not a green field deployment. This
          draft tries to solve that problem. Carriers want to update their core
          to a single IGP protocol. Works well in the core but access may be a
          problem – needs to be stitched to the core.
          PIM in access terminates at BIER Boundary Routers.
          All changes are to control plane. No change to data plane.
          Need to find the BIER Boundary Routers (BBRs).
          Jeffrey Zhang (Juniper): So you are using PIM instead of BGP.
          Answer: Yes.
          IJs (Cisco): For the record, discovering the BBR is the key to the
          solution. Minor concern about unicast: use the originator of the LSA
          as the BBR; ... summarize routes. I have not seen this used before.
          Information has been used for trouble shooting, not routing.
          Hooman Bigdoli: Will clarify this in next version of the draft.
          Andrew Dolganow (Nokia): Originally intended to keep locate the BBR out
          of scope since we did not want to mandate a way. We will add a section
          describing mechanisms, not mandating a mechanism. Anyone who wants a
          way can propose text.
          Steve ?: BIER DF election. Don’t know who that is. Send PIM join
          based on closest. Say two different routers on edge towards source,
          say A and B. May want to control which is used so PIM join is more
          Andrew Dolganow (Nokia): Yes but I disagree where we should be
          documenting that. This is a general BIER problem. We have left this to
          the protocols that do the selection.
          Steve: Yes, there are differnet ways to do it and you might not want
          to put too much in this document but you should at least mention the
          Toerless Eckert: Maybe Core and Access are different BUs. 256
          replication may not be enough. For example, Mobile backhaul may be
          100,000. Mobile backhaul multicast is called EVMS.
          Chair: I assume the goal is adoption. Who has read the draft? Who
          thinks it should be adopted? There is consensus in the room, take to
          the list.
          BFD for BIER
          Fangwei Hu (ZTE)
          (see slides) Based on draft-ietf-bfd-multipoint but uses demand mode
          (RFC 5880), has no no 3-way handshake.
          BIER BFD Encapsulation as in draft-ietf-bier-mpls-encapsulation
          Boostrapping BIER BFD session.
                  One-Hop use IS-IS BFD-enable TLV (RFC 6213)...
                  Multi-hop use BIER OAM ping (draft-ietf-bier-ping)
          Jeffrey Zhang (Juniper): OAM packet header being defined. Source
          address field – BIER ID.
          Greg Mirsky: Yes, is a bit redundant.
          Jeffrey: Seems more bullet proof to put it in the OAM header. BFR ID
          identifies the source now. But might be used for something else later.
          Chair: how is this used? Demux per subdomain ... How is this different
          from BIER ping?
          Greg Mirsky: Ping is for troubleshooting, not for pro-active
          monitoring. This is for pro-active monitoring. BFD was in software but
          now in hardware, scaling is enormous. ... Point to multi-point BFD
          does not permit the root to monitor the end points, it is vice versa.
          BFD with active tails, to be published as informational, enables tail
          to tell head...
          Jeffrey: This sort of thing becomes standard and then implement for
          the sake of implementing and then enhance because it is there so we
          get pushed into doing it for every multicast group and then you have
          scaling problems.
          Chair: From the customer side, BIER OAM considered very interesting.
          Greg: With this mode can only monitor ingress. 1+1 protection can
          switch to another ingress if you want.
          IJs (Cisco): Today you have to do it per tree. With BIER, there are no
          trees and it is per ingress. So it will scale better.
          Andrew Dolganow (Nokia): Scaling better but still have a choke point
          becasue we are attacking the ingress.
          Stig Vanas: Imagine doing this in an underlay. If any BIER router
          might be an ingress end up with every router monitoring every other.
          Greg Mirsky (ZTE): Then just monitor your neighbor over one-hop and
          provide some alarm indication signalling.
          Chair: Adoption. Who has read this draft? Who want to adopt?
          Consensus for adoption, take to list.
          Andrew Dolganow (Nokia): We are talking about extending BIER to the
          edge. As soon as you do that you are subject to DDOS attacks. So I
          think we need a security section.
          Tony P: Need an operational model.
          BIER in IPv6
          Sandy Zhang (ZTE)
          (see slides) Process BIER in slow path... BIER is next
          protocol. Useful in Homenet. Very simple. TTL=1 ...
          Aligned with format defined in ietf-bier-mpls-encapsulation
          Jeffrey ?: 2 questions: If you could do BIER in slow path, could
          you just do ingress replication?
          Sandy: Yes, but efficiency may be the same or may be different
          depending on the situation. Ingress replication uses unicast, this
          uses multicast. The operator can choose.
          Jeff: Next question. It seems like there is nothing special about
          IPv6. It's BIER in X.
          Sandy: Yes.
          From Jabber: Juliusz Chrobocek: Why is this restricted to link local?
          What happens if you extend to multi-hop IPv6.
          Answer: Yes. Shouldn't be used as a poor man's tunneling. Otherwise
          you may have loops.
          IJs: Just because you put an IPv6 header there, it's not IPv6 because
          forwarding is control by BIER bits. Since this has nothing to do with
          IPv6, maybe you should just get an EtherType and reverse the order.
          Chair: Yes. We don't have an EtherType yet. This is an easy way to get
          this going but it is not IPv6.
          X: I would call it slow path processing. There are other ways in IPv6
          and IPv4 to punt to software. As soon as it is in software, you can
          look for BIER.
          Tony P: I looked into router option, alerts, and header bits and this
          is significantly simpler.
          X: Should be re-named as slowpath BIER. This will never be as fast as
          ingress replication.
          (Greg) Chair: This seems transitional. This could just be
          Adoption depends on Homenet interest.
          Chair: This is quick to implement.
          Chair: Babel is just a control plane. This could be the data plane
          until we get an Ethertype.
          IJs (Cisco): Homenet fanout is small. We have another draft to echo
          the BIER bits in the IPv6 address itself. That might be even simpler.
          Andrew Dolganow (Nokia): This is just transitional/informational. It
          would take less time to implement than we have spent talking about
          it. This does not need interoperability... Not going to be installed
          across multiple vendors. It's hop-by-hop.
          BIER Flooding
          Sndy Zhang (ZTE)
          (see slides) Hybrid network with different routing protocol in
          different regions.  Maybe only one hop forwarding in some
          regions. Border router must convert BIER encapsulation.  Merge several
          regions into one.
          Use PIM flooding mechanism to flood BIER node information across
          multiple regions. (draft-ietf-pim-source-discovery-bsr)
          Does not replace OSPF/IS-IS/BGP BIER extension. Uses PIM to flood BIER
          node information, not to build multicast trees.
          Toerless Eckert: No example of this hybrid routing. What would be the
          most interesting example?
          Sandy: Network shown in slides is very common in China.
          Toerless: Would be good to have pointers to such cases. If there is
          re-distribuiton between the IGPs for unicast, why can't I just use
          that for BIER?
          Andrew Dolganow (Nokia): I would also like to understand the use
          case. .. Feels
          Hooman Bidgoli (Nokia): What are BIER edge routers?
          Sandy: There are tens of routers in the domains. B* are BIER edge
          routers along with MR1 and MR2.
          Hooman: Make them be separate BIER domains.
          Sandy: One BIER network.
          Chair: Take discussion to the list.
          BIER-TE Encapsulation
          Quan Xiong (ZTE)
          (see slides) Extensions to BIER encapsulation to handle more than one
          bit stream. ... Add BitString Sub-TLV...
          Toerless Eckert: Instead of two shorter bit strings you can have one
          long bit string? Would each bit string be the maximum size?
          IJs (Cisco): The limit of 256 bits is because there is a maximum size
          you can read into memory and process. ...
          Chair: That is part of the architecture. Take discussion on adoption
          to the list.
          Torless Eckert: I would be happy with a single bits string.
          BIER-TE Forwarding
          Quan Xiong (ZTE)
          (see slides) ... Problem with Multiple SI. ... Assignment of bit
          positions ...
          Chair: We have very little time, anyone have a quick question?
          SDN ...
          BIER-TE Encapsulation and Extension
          Rachel Huang (Huawei)
          (see slides) Similar to previous. Fix problems TE currently has. ...
          Toerless Eckert: Are there changes in anything that needs to be
          standardized? Or can it just be informational? Obviously want minimum
          per flow state. Should optimize across as many flows as
          possible. These are the crucial goals.
          Rachel Huang (Huawei): You have two drafts. Do they solve the same
          problem of different problems?
          Rachel: Yes, they solve the same problem. We think the TE draft has
          scalability issue ... each packet may be limited to a small area. You
          can have multiple packets. But here we want to change SI from set
          identifier to a segment index. ... Packet can travel to multiple
          segment areas with different SI. ...
          Greg: Isn’t the challenge that this is multi-point and you don’t know
          which to use until you enter the next area... Have you
          talked with the groups working on scaling. Stacking is not
          necessarily a viable solution. We have some groups working on this. I
          encourage grops to get together to work on this.
          Toerless Eckert: Problem may be easier in TE than in BIER proper.
          Chair: Collaborate.
          Rachel: OK
          Chair: Solutions are not the hard part. What problems are worth while
          to solve is hard.
          MVPN using BIER over P2MP
          Jingrong Xie (Huawei)
          (see slides) Use the benefit of BIER for existing p2mp technology.
          ... Pre-built p2mp tunnel. ...
          Andrew Dolganow (Nokia): Did you read the architecture draft? With
          BIER we are trying to simplify. The last thing we want to do is more
          mLDP, RSVP, ... extensions. I don’t understand the use case. Why would
          we add stuff to things we want to eliminate?
          Jingrong: Want just want to use existing technology. And make minor
          change to use BIET.
          Hooman Bidoli (Nokia): I read the draft a couple of times. Is it BIER
          over MPLS or MPLS over BIER?? What is the packet going to look like?
          Jingrong: In MPLS encapsulation...
          Chair: Challenge to figure this out and what you are trying to
          solve. Look at the architecture document. Take discussion to the list.
          Multicast HTTP using BIER
          Debashish Purkayastha (InterDigitial)
          (see slides) HTTP level multicast. ... BIER multicast overlay
          requirements. ... Changes to NAP-to-NAP, HTTP to BIER message
          exchange, NAP to PCE, Overlay transport protocol, registration
          protocol, content certificate distribution protocol.
          Andrew Dolganow (Nokia): Thanks to the Chair for scheduling something
          sane at the end so we end on a good note. How does this work without
          BIER? Can you add pointers?
          Chair: This should be discussed off-line on the list.
          Q: Is this for the video ABR case?
          Debashish: Yes, a use case already in the use case document.
          Q: This is completely in the overlay. It’s already done. Why don't you
          just ship it?
          IJs (Cisco): Trouble understanding bigger picture. ... PCE elements
          would only work with TE BIER? Is this just for BIER TE.
          Chair: We need to know about existing solution without BIER.
          Status: 2 drafts in the RFC queue. Three years fro BoF to RFC in the
          fowarding plane!!
          (Re)Charter Discussion
          Chair: TE not in initial charter. ADs support adding it.  IETF
          forwarding plane, IP , MPLS, BIER. Should it go to standards. OAM work
          to do. ... Lots of work to do.
          X: Yes. Move it to standards.
          Toerless Eckert: Did I overlook some implementation experience drafts?
          Chair: That’s the justification draft... Want to get this moving
          before the end of the year.
          Chair: Get the word out. How should we evangelize? Throw a big party?
          X: I think the standard move is done - we have proven we are not
          taking it lightly. We brought in operators and vndors. Now pusing it
          into real networks. We need to recharter ...
          Alia Atlas (AD, Juniper): Would like to reCharter well before next
          IETF. This will take serious work. ... Get document done – I will try
          to push it through quickly. ... Once we recharter, we can do some
          status update. We need to move.
          "Our team rocks"
          Chair: Setting BIER bits from the application layer.
          Chair: That's not prohibited by the archicture.
          X: We haven't gotten to the point of saying "APIs".
          X: Does this have to do with routing in the datacetner or distributed
          applications in the datacenter.
          Chair: All are invited to contributing to the Charter. Consensus to

Generated from PyHt script /wg/bier/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -