* 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: Alvaro Retana, Deborah Brungard, Martin Vigoureux | 2015-Mar-24 —  

IETF-103 bier minutes

Session 2018-11-07 0900-1100: Boromphimarn 3 - Audio stream - bier chatroom
Session 2018-11-08 1120-1220: Boromphimarn 1/2 - Audio stream - bier chatroom


minutes-103-bier-01 minutes

          BIER WG Minutes, Day 1
          IETF 103, Bangkok, Thailand
          Wednesday, 7 November 2018 09:00-11:00
          General comment: Please avoid scheduling with SPRING
          Chairs Comment: very tight agenda
          Stig: discussion on the PIM join draft is not on the agenda but wanted
          to have a discussion about it as some of the last call comments did not
          get addressed
          #1: mldp signaling bgp
          Presenter: Hoooman
          Draft: draft-hj-bier-ldp-signaling
          Toerless Comments: is anyone selling services over this?
          Hooman: Yes, this does exist
          Toerless: The labels need to be received and looked upon in context.
          Hooman: between PE and Root same MVPN procedures
          Toerless: Could the came label end up getting sent representing different
          trees by different EBFRs?
          Ice: :He means on the way back, There is a global label or context label
          that makes the tress/P-MP unique
          Ice: when you send out the mLDP FEC to the egress BBR.  You are saying
          this is now being sent natively into BIER.
          Hooman: New BIER pkt type "MPLS".
          Ice: how do you take care of pkt loss, retransmission, highly recommend
          not coming up with a new protocol...either use tLDP. More discussion
          Andrew D: it is a valid point that we need to figure out that the pkt
          arrives at the far end.  MVPN procedures are fundamentally wrong, as you
          add service aware on a P router.So, do we need to enhance the draft to
          pay attention to packet loss
          Tony P: please keep all the overlay signaling out of the data path
          Jeffery Zhang: based on offline discussions: if we only consider mLDP,
          RFC7060 is the best, if you want to go beyond mLDP, them BGP MVPN may
          be the best way to go, but love to continue this
          Hooman: tLDP is a great option but not generic enough, but MVPN
          procedures, I could not figure out, is how can you run those procedures
          on the P-router?
          Ice: Responding to Andrew: with MVPN we know our Egress border routers,
          Tony P: there is a good architecture, don't be pleasant, but make sure
          it is not painful or hack
          Andrew D: fundementally, if there was no MVPN, then perhaps there is a
          way to make this happen.  You may end up nesting MVPN inside an MVPN. If
          there is MVPN between PEs and then we try and use MVPN procedures would
          be cumbersome.
          Jeffery Zhang: In this case the Border Routers are not traditional
          P routers
          #2: Bier Prefix Redistribute
          Presenter: Sandy Zhang
          Stig: I see a BFIR range, would it be an option to use a set?
          Sandy: Yes, we can change it
          Stig: would need more than 16 bits
          Jingrong: RFC makes it clear that it can support inter-AREA advertisement
          Sandy: No it does not
          Jeffery Zhang: this is a lang issue.  In the use case from Sandy, there
          are different IGP domains, not areas.
          Jingrong: Does this make things more efficient when advertising the
          prefixes?  We are not advertising one by one or are we?
          Sandy: Yes, we optimize
          #3: Global vpn-id advertisement
          Presenter: Sandy Zhang
          Jingrong: I think this is a good idea only for the non-segmented
          deployments.  But for segmented, then the ABR needs to allocate the
          resource dynamically and make it confusing.
          Sandy: we welcome comments or suggestions to avoid a new protocl type
          Huwawei: Comments around protocol type.
          #4: bier-mtud
          presenter: Stig
          Draft: draft-venaas-bier-mtud-02
          Stig: Should this be adopted for WG?
          Chairs: Poll the room for adoption
          Alvaro: concerned,.needs to get transport people on board.  Make sure
          we get early transport area review as some of the mechanisms as we are
          ignoring some links.
          Chairs: what is the process?
          Alvaro: you can use the tracker to do this. And do it before we accept
          it for adoption
          #5: bier-pfm-sd
          Presenter: Stig
          Homman B: question: the routers that are between PIM and BIER, packets
          sent to all routers?
          Stig: Yes, we broadcast sources so we don’t need to do a discovery
          Toerless: Are the joins unicast?
          Stig: according to PIM over BIER draft they are unicast
          Toerless: Why not BIER casted to the upstream? What is the best LAN
          procedures for the multiple upstream and down stream
          Stig: for reliability it would be good if both BFIR1 and 2 get the
          Toerless: Cost across the BIER domain is not taken into account...BFIR1
          and 2 in US and BFER in Europe
          Stig: if you want to account for cost across the BIER domain, you could
          add the cost to get to BFIR1 or 2
          Hooman: this procedure is happing before
          Stig: main addition is a procedure at the egress BFER in the cache to
          have the S,G, and metric info
          Chair: do we adopt?
          Room: few yes
          Hooman: from procedure point of view, it is okay.  But I am not sure what
          is missing to find the BFIRs as we have already added a lot of mechanisms?
          #6:Applicability of BIER Multicast Overlay for Adaptive Streaming Services
          Presenter: Debashish Purkayastha
          Alvaro: You are documenting how it would work there?  You are not
          proposing anything?
          DP: this is an applicability document.  Just how to use BIER, use BIER
          as an overlay
          Alvaro: I think it is good, but not sure of the charter. I think the
          chairs need to look at the charter and clarify for all of us if we are
          looking at the charter appropriately
          Tony P: Loa things that it is more in his corner
          Alvaro: Charter says one use case document.
          Tony P: Charter says "how it has been done in MVPN"
          Alvaro: want to be careful what door we open...
          Toerless: This is a good documentation for how to use BIER for a use case
          Andrew D: This is an information draft.  It helps put ideas into peoples
          Tony P: Applicability makes sense here as it is about BIER
          Greg as Chair: use case helps drive other groups
          Presenter: Toerless Eckert
          Draft: draft-ietf-bier-te-arch-01
          Toerless: We do not have an API to set BFIT etc
          Tony P: Wrong, we do.  The YANG model does address that
          Toerless: what are the allowed FBMs..put a constraint.
          Tony P: BFR2/2 on slide 8 could be fabric in the router. This discussion
          belongs on the YANG draft
          Ice: BIFT1 and 2 are they the same table? Toerless: Yes, same table :
          Ice, draft says cannot be in the same table
          Sandy: FBM in the YANG is read and write
          Tony P: be careful programming the bits...it is programming in assembly!
          #8:BFR Tethering
          Presenter: Ice Wijnands
          Chairs: any comments?  Can we go to LC.
          Take this draft to last call.
          Sandy: Control plane is good.  But need more info on the data plane..want
          to know how packets are forwarded on router X
          Zhang: They are native BIER packets
          Tony P: think OS X when you do not see the the label,
          Andrew D: This will be more expensive to do at the end
          Tony P: It can be less, think about having to rum all multicast procedures
          on router X.
          #9: Multicast/BIER As A Service
          Presenter: Jeffery Zhang
          Andrew D: 256 is not a lot, we have bigger networks. My dilemma, BIER
          was supposed to be simple, the draft solves some of the problems, but
          are we doing ourselves a favor.  This is complicated.
          Greg S: so what you want to see is the actual use case to better
          understand why we need to do this?
          Andrew D: Yes, BIER is simple, but this makes it complicated
          Toerless: Is this the right time to do this?  We should know if it is
          possible to sell BIERaaS, but do we really need to do this work now.
          Good to know we could do it.  What does this give me as a network overlay
          multicast service provider ?
          Greg S: Can we discuss this on the list and understand it better.
          Day 2
          Thursday, 8 November, 2018 11:20-12:20
          Bier-resilience draft
          Discuss the resilience for bier
          Use Case 1 E2E 1+1 Protection bier p2mp BFD
          Use Case 2 E2E 1+1 Protection bier p2mp active tail BFD
          Use Case 3 Bier local protection. Bier p2p BFD
          Next steps:
          Further research direction
          Read: 9
          Adopt: 5
          BFD for Bier
          Changes from version 00 to 01
          Removes definition of bier OAM packet format
          Removes the one hop bootstap part and keeps multihop boostrap
          Stig: since BFD has to be as efficient as possible may be better to not
          use the OAM header. Doesn’t really add any value.
          Tony: how to nail the BFD path
          ZTE: goal of OAM shim is similar to well known udp port. Demultiplexing
          protocols. We propose to use ach BFD control message format without udp
          overhead. Bfir id as identifier of source. Is a tradeoff. Could use
          ip packet and follow 5884 and use destination ip address as loopback
          range and use BFD well known port. If you don’t have udp header need
          to identify as a BFD packet.
          Tony: do not remember if encaps forces you,
          ZTE: packet already has BFRID
          Tony: out of path is a problem.
          Greg ZTE: in terms of processing there is not much difference because
          you have to demultiplex anyway
          Stig: you have bier next header and then 4 bytes and says BFD packet
          and don’t see why there is the 4 bites.
          Greg ZTE: could have multiple points, could say next protocol is BFD
          next protocol is whatever.
          Reshad: would have to define something new.
          Greg: either udp or ach. Ach doesn’t have a header so only have BFD
          control message. What Stig proposes is to have it in the next protocol
          but could run out of space.
          Greg: don’t have to agree now but good to discuss.
          Bootstrapping bier BFD session
          Next steps we will add active tail solution
          Reshad: when we did LSP ping with BFD there were some issues.
          Greg: there will be other alternatives to bootstrap. Problem with
          using ping to boostrap on mcast is you might be too late. Have to do
          it periodically.
          TonY; it’s a function of the overlay whatever the overlay is.
          Greg; you have to give information what the descriminator is.
          Bier v6 encap
          Our draft proposes bierv6 encap for ipv6 networks using an ipv6
          destination option extension header. Would require a new bier destination
          option type codepoint from IANA.
          But really there are a variety of bierv6 proposed solutions, bierv6
          encap and otherwise, and we should reference these options and provide
          clear use cases.
          9 read
          7 interested in work
          Greg: its not encap when adding bier bits to v6
          Main problem mcast join latency. More efficient in mvpn explicity
          tracking draft.
          Is this problem bier specific or more generic. GTM using IR has a very
          similar option, etc.
          Jeffrey: all the discussions convince me more that this is not specific
          to bier. Except the bier mvpn draft says to not to use lirpf explcity
          tracking when doing segmentation, anything else is generic, applies to
          any tunnel. Also, he loves segmentation but everytime we bring it up the
          customer says they have to maintain states on the segmenetation points
          and we are adding more here making it less attractive.
          Jingrong: this draft only includes the bier specific part and not the
          genertic part. Do you mean this draft must add more generic context and
          move to other wgs? If bier didn’t exist this draft would still make
          sense. Whether it belongs to another wg it should because it is generic.
          Jeffrey: we have a more generic problem don’t have to limit it to
          bier. If you need to do segementation and per flow label.
          Jingrong: perhaps have another draft that’s more generic.
          Jeffrey: the benefit is not worth the cost.
          Tony: this is putting more state in the network. You still have mldp and
          bier on top. Don’t think this is something this group. Would like to
          see a strong use case and migration scenario.
          Greg: thin support.
          Jeff: the state you put in place doesn’t justify what you are trying
          to achieve.
          Other work:
          Stig: join signaling. Only look at the join from looking at the join
          header. Either you have an implementation.
          Hooman: isn’t bfir id for ibbr in bier header already
          Stig: my point is if you look at the layers you do the bier encap first
          and then punt the packet but pim doesn’t have that context for explicit
          tracking in order to know where to forward the packet.
          Hooman: that’s part of the bier implementation table.
          Stig: pim needs to add an oif to say where to add a join.
          Hooman: the bier is where the oif comes from. You can note it but to me
          this is implementation
          Ice: in bier there is also sub domains it doesn’t tell you the sub
          domain. Its encoded in the lable but no context in the lable. Its nicer
          if you can add it to the pim join.
          Hooman: that’s fine we an add the ibbr ip address as source but then
          when you removet he bier header the extraction becomes an issue.
          Stig: when pim gets it’s a pure ip packet and the easier way is to
          put it into the packet itself.
          Hooman: the implementation has been done from our point of view we’ve
          had no issues just build the oif from the info you have.
          Stig: does pim have any state related to the oif to say what bier sent
          the packet to? All pim knows is to forward the packet to bier.
          Hooman: when you grab this from the data path you just send out with
          the ibbr whatever the structure is. Pim notes this and we go to the tble
          and field the table with new oif.
          Stig: you use the source of the pim join to track the receivers.
          Jeffrey; when you send a packet up the stack you remove the headers one
          by one. When pim gets the packet you just have a pim packet. Would be
          good to have the additional info embedded in pim.
          Tony: nothing wrong with implementation of that. Architecturally however
          your bgp and pim and bier need to be collocated and do we accept that? Its
          not our mandate to determine how to implement this.
          Hooman: the first draft that we gave out was trying tosolve this by
          coming out with new bier type and putting ip address of ibbr as source id.
          Jeffrey; you just put the signaling. I do realize yes your implementation
          could figure it out in implementation but easier way would be to send
          that information in pim packet.
          Stig: when wrote igmp draft just use source of bfid. You don.’t know
          the sub domain though.

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