we have a charter, we're a WG now IETF hack-a-thon got some good work done for BIER thanks to Markus Stenberg WG call for items - none so far problem statement - hands for read, hands for adoption - some, none against bier arch - hands for read, hands for adoption, none against mpls bier encap - Loa - this is intended for MPLS WG eric rosen - doesn't propose changes to MPLS Loa - change name? Ross C - shoud this be a WG doc in some WG? Should it be in this one? Yes this should be a WG doc we can tell MPLS that this is happening Greg - understand for confusion, what should we call it? Swap MPLS and BIER in the name, then it shows the right intended WG ross - make sure the WG chairs know Loa - we are picky about naming docs correctly. MPLS was in agreement that this was an MPLS WG item use cases draft - hands for read, hands for adoption, some, none against l3vpn-mvpn-bier hands for read, hands for adopotion some discussion about which WG ospf-bier-extensions does this go to OSPF? checked with ALIA, this goes here, and we inform the OSPF WG bier-isis-ranges read, adopted - some hands, no hands against Ginsberg - seems a change in policy for these routing drafts Alia - we decided that these would be here, with cross-area review, multiple group LC. similar to CCAMP model for cross-review. This way it's easy to make sure it combines with arch. Part of my role is to ensure that interaction happens. Ginsberg - not concerned about integrity of the process, just seemed surprising Alia - there's precedent, I can show you Eric Rosen now discussing Bier MPLS encaps and ARchitecture xaohu xu huawei - you need another routing computation instance for BIER to work, right? Eric - in the left case (slide 7) ... how the packet destined for G will traverse F? ERic - you do the spf one time, get the complete set of paths anyone to anyone xu - spf should take BIER requirements into account? eric - yes you have to save next-next hopts xu - only applicable when link state protocol used eric - could probably figure out solution for BGP not sure about RIP [I'm sitting right next to eric and can barely hear him, so there are going to be some gaps in the notes.] xu- each node advertise bitstream lenght label? eric - yes different for each xu - if you want to allocate bier labels, youd' need to consider any combination of set domain ids, set id and bitstream lengths ? xu - discussion of bitlenghts rosen - you realize there's more than a million combinations,right? We don't think that's going to be anywhere near that size in deployment IJ Wijnands- only care about combinations in use Was explaining to customer - asking why "set" wasn't called "crates" and that seems like a great idea. greg - set came before bier eric - work in 6-pack wijnands - lengths chunks of 64, 128, 256 - maybe do 256, but backward compatible for 128, or 512 and 256, etc. Eric - if you support a given length, you support all the smaller ones? you wouldn't need to do that unless you actually are sending to one of the smaller ones ------------ IJ Wijands presenting psenak-ospf-bier-extensions xu - if you move bitstream length into mpls bier tlv, ij - you are allowed to encode multiple tlvs xu - bitstream length is usable zhaohui zhang - we agreed to move bistream length out of MPLS TLV xu - bitsream lengths can be determiend by mpls bier label. seems unnecessary to contain length field in header? ij - someone needs to announce BL you support in a given encaps. in mpls, 256 in order to tell rest of world, you put that in the encoding if you use different encoding, a new size xu - question related to MPLS eric - for the processing, bitstream length would be derived... [missed some stuff] -------------- Andrew Dolganow now discussing BIER-use-cases Lenny Guilano - internet multicast as a use case? Andrew - not yet, but we're happy to add others. A number of cases aren't really broken today, until you get to higher scale, and that's where bier starts making sense lenny - the real benefit of bier is that you eliminate per-flow state. place where that is needed the most is internet multicast greg- each network has different considerations for flow state. if you're using mvpn to transit, that's one consideration. maybe we need to break up those elements from DC to desktop lenny - how it iteracts with AMT. some of these use cases, state is the least of your problems, don't want to polish the shiniest apple greg - send text Dino F - connecting Bier domains with existing overlay? faster deployment of non directly connected BFRs andrew - not spelled out. not sure if we want to add every single solution dino - part of the transition ij - part of this in architecture draft Tom Okeefe - multicast in financials. another requirement for physical diversity between redundant feeds. A feed, b feed out of different lcoations. A feed, best latency, b feed physical diverse andrew - not discussed due to time. Tom - looking forward to reading new TE Tony - subdomains allows you to provide separation, QoS, Topology, etc. I think we have a tool for it. zhaohui - you don't really need a redundant path anymore. put packet in network with destinations, it will get there... andrew - two sources, total georedundancy, two streams, no default behavior to guarantee that both take two separate paths Tom - same application data, but out of one site it's 1 s,g, the other is a different s,g. Both streams are delivered. ------------ Tony now discussing BIER ISIS Tony now discussing auto-BFRid ij - bfrid seen more as ip address for egress router. nothing prevents applying other things on top of that. treat it as an IP address you configure (if you want to do it centralized) - sdn controller, etc having another mechanism in the network adds unnecessary complexity to network Tony - this is sort of like dhcp - ij - not sure that DHCP is the right comparison - example where dynamic BFIDs are used? Tony - only applies to BFERs large admin domain, services for customers. provisioning has possibility for misconifig ij - BFRID is onyl local to router, not the service. not necessarily something you hand out on pers-ervice basis tony - per subdomain, how you handle subdomain is matter of choice - will it grow big enough, will people care enough about auto config ij - arch doc says you can detect misconfig tony - optional complexity to scale things higher xu - subdomain is mapped to given topology? tony - you don't control topology, but multitopolgy allows oyu to prune, subdomain gives different labels xu - will WG consider "rich man's" multitopology tony - if your implementation supports multitopoloy, you can use it with a single subdomain xu - usage of MT routing is moving between topology - switch packet from one topo to another tony - never saw this for failover, but rather for topo disjoint. well-specified piece of network xu - mvpn growth, assign a particular subdomain, for all traffic within that instance, if I want to use different topo for different types, you need to allocate different subdomain for different traffic types tony - different traffic types are different services, differ subdomain. service separation - whether temporal, physical, etc. xu - combo of subdomain ID and BFR ID can determine a given IP address? IF you map subdomain to particular topo, you use a topo specific IP address, why not Tony - are you speaking against coupling with topo and subdomain? xu - mt domain shoudl be contained in separate failoer tony - if you now ISIS and encoding it is xu - for bier encaps, one subdomain determining topo also determines... don't need to use subdomain as poormains MT instance... tony - mailing list?? ij - subdomain has 2 use cases. can tie to topology or to igp instance. service separation or different topo -------- Toerless Eckert BIER-TE Eric - you need to clear the bit Toerless - yes, that makes it simpler -------- Greg Mirsky presenting bier-ping eric - would be great to have an oam requirements doc, gap analysis of other oam tools. otherwise we'll keep coming back to the same questions tony - adopt? hands in favor, none against Nobo Bigswitch - ping traceroute, operators have certain ways taht they want to operate BIER. would be nice to have something like XYZ Greg - planning to support active and passive perf measurement ---------- Xiaohu Xu now presenting BIER encapsulation Ij - statically carve out fields like setid, subdomain, etc in your encoding. what happens if later we come up with a use case that needs new value? We have to change the encoding - donwside of hardcoding. MPLS is an indirection. More flexible. Tony - let's not compare MPLS encaps draft to IP draft here, let's focus on IP draft Erik - not sure I agree, use for carrying in MPLS, use for carrying in IP. ARe you trying to make the otheres happen, what problem does it solve? Looking at specifics like DSCP, do you really need this in this layer? If you say this is a new network layer header, yes, but if you use transport, you have places to store this info. Does this solve a problem in terms of need to carry differing behavior? typical packet will have 3, inner, transport, bier. maybe an additional one isn't needed - don't assume we need to replicate everything. Andrew Duncan - if you can't come up with something general, you'll end up with "god" headers. tony - job of control plane is to run architecure thats allows convergence, job of network is to move things around tony- job of control plane is to converge network so it has many fields and concepts, concept of encapsulation is to get things from one node to next. Control plane has a "wide" range of things, encapsulation has simple fields to get stuff done fast. your header implies archintectural things like MTID to subdomain mapping which are unnecessary at best, will introduce defects at worst (MT-ID is too short, subdomain-id may not match MT-ID) xu - similar to todays usage. ---------- Xu now presnting BGP extensions for BIER ---------- Dino now presenting Signal-free BIER multicast Erik - who allocated BFRIDs? Dino - whatever does it today Tony - since this was last night, did you already implement it? Dino - sorta have an implementation ---------- Erik Nordmark - presented encaps considerations at routing design team meeting yesterday. Securty, congestion control, etc. so that you don't have to start from scratch. Should we look for more commonality between BIER, NVO3 and SFC? can we reuse OAMs, reuse existing stuff? Have to figure out how to coordinate across WGs. Food for thought. Session ends 3:01