Bier Status PagesBit Indexed Explicit Replication (Active WG)
Rtg Area: Alia Atlas, Alvaro Retana, Deborah Brungard | 2015-Mar-24 —Chairs:
IETF-100 bier minutes
Session 2017-11-14 1550-1750: Olivia - Audio stream - bier chatroom
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 Encapsulation ---------------------------------------------------------------------------- draft-wijnandsxu-bier-non-mpls-bift-encoding-00 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 ------------------ draft-hfa-bier-pim-tunneling-00 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 complex. 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 issue. 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 ------------ draft-hu-bier-bfd-00 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 ------------ draft-ietf-bier-bierin6-00 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 informational. 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 ------------- draft-zhang-bier-flooding-00 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 --------------------- draft-xiong-bier-te-encapsulation-00 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 ------------------ draft-zcxh-bier-te-forwarding-00 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 ----------------------------------- draft-huang-bier-te-encapsulation-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 ------------------------- draft-xie-bier-mvpn-mpls-p2mp-00 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 ------------------------- draft-purkayastha-multicast-http-using-bier-00 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 continue.