[Bier] Meeting Minutes IETF 116

[Tony Przygienda <[e-mail]>]

 Thanks Mankamana for note taking ...

somehow I cannot edit the minutes in the tracker so here it goes for
posterity

-- tony

   1. WG states, WG chairs, 10 minutes


   - draft-ietf-bier-ospfv3-extensions document in IESG and
   draft-ietf-bier-evpn
   - Andrew : Question to tony about OSPF v3 drafts, and we are waiting on
   update and write up
   - Tony : it has been completed.
   - Andrew : Did not get any notification .
   - shephered needed for some of the document in WG.
   - As WG we still need to deliver the OAM work based on our charter.
   - Tony : there is lot of work needs to be produced as working group


   1. BIER OAM WG drafts, Gregory Mirsky, 10 minutes


   - we have four WG document in BIER. BIER Ping need to move forward as
   other drafts are depending on this.
      - BIER Ping document is ready and all the comment has been addressed.
      - Tony : Does BIER ping document had major change which need one more
      WGLC ?
      - Greg : No it was editorial changes
   - BIER path MTU discovery ready for next step.
      - It requires BIER PING document to make progress.
   - BIER BFD ready for WGLC.
      - Andrew: Early RTG review needs to be initiated.
      - Tony : Early review would be initiated.
      - Andrew : if we can finish early directorate review it would
      progress faster
      - Tony : is RTG review mandatory ?
      - Andrew : Yes
   - Hybrid Performance Measurement in BIER.Ready to move forward.
      - Tony : Has IPR been disclosed ?
      - Greg : Need to check on that
      - Tony : requirement and framework document are expired, are we going
      to just let it go or do last call ?
      - Greg: WG to decide. document has served it purpose already.
      - Andrew : if there is requirement document which helped to generate
      new work in WG. it would be good to revive and publish. people would have
      track record for why something was done ?
      - Tony : Greg M to revive the work. and we would do WGLC and there is
      no need to more review.
      - Toerless: if requirement document is informational then we may not
      need to publish. Is there any implementation.
      - Greg M : there is one vendor who has implemented LSP ping.


   1. BIER Prefix Redistribute, Sandy Zhang, 5 minutes


   - new update from last version
   - document is ready for WGLC
      - Siyu Chen: question about prefix whether its single address or it
      is multiple BFR.
      - Sandy : you can use both method.
      - Tony : it would be good to add section clarifying it.
      - Siyu: base RFC BIER says prefix has to be address. We can take
      discussion to list.
      - Tony : does BGP summarization violates that ?
      - Siyu : Yes
      - Tony :please take the discussion to mailing list so we have
      documentation.


   1. BIER Anycast, Jeffrey Zhang, 15 minutes


   - BIER RFC8279 did not cover anycast. so this draft is to close the gap.
      - Toerless: document is not clear whether anycast is talking about
      source or receiver.
      - Jeffery: it does cover both of the case.
      - Toerless: it would good to clear up the draft talking about
      different cases.
   - two drafts in this area
   - Toerless : will receiver anycast work ?
   - Jeffery : it need to be implemented with MoFRR
   - Tony: we would need to think of capability somehow. it will help to
   deploy multi-vendor network.
   - Siyu: for same PE multi-home to two different CE then draft says we
   can have two BFR prefix. does it mean overlay and underlay being co-related
   or tightly coupled ?
   - Jeffery: we can look at base RFC and see if things need to be changed.


   1. Update on RBS and related work, Toerless Eckert 10 minutes


   - Ice : have sent question in list and currently it has not been solved.
   it is really needed where we can have sniffer in network and being able to
   encode the packet any time.
   - Toerless: MPLS also has same analogy.
   - Ice : sniffer on wire can always decode the encoding. and it is not
   true statement for MPLS
   - Toerless : we dont need to really see the whole packet. or decode the
   packet for better forwarding.I may not agree that we really to be able to
   decode the packet . and just to add this capabilities we would not be
   efficient in forwarding. so its better to be efficient
   - Tony : does it not boils down to argument that first field which we
   decode is length indication.
   - Toerless: i do not think we should be really able to decode whole tree
   which has been encoded in packet. same way you do not decode the stack of
   protocols which you are processing and do not care about .
   - Ice : just because of its hard we can not discard the fact that
   protocol need to be reliable and something which can be troubleshooted.
   - Andrew : speaking as individual , for vendor its critical to be able
   to decode the packet. as its being used for different application in
   network. so it is going to be important for any operation.
   - Toerless : but we can not decode encrypted packet without key.not all
   has to be solved in forwarding plane.
   - Andrew: accounting really need basic information without knowing full
   semantics.
   - Tony : its good progress related to RBS work and it can be used to
   solve the use case which being discussed as part of presentation later . As
   WG we would have to see if we can work on this area.
   - Ice : it would be good to first work on foundation before spending
   time in implementation to avoid re-testing.
   - Toerless: P4 community may play without it being standard as part of
   research.
   - Ice : do we want only this to be part of research ?
   - Toerless: No, we want it to be deployed too.
   - Andrew : as AD , if WG thinks that this work needed in this WG. then
   it is ok to add in charter. and i feel it would fit in overall framework.
   we would need to find if there is enough interest to work on this.
   - Poll Who would contribute to work on RBS in BIER WG
      - Yes 8
      - No 7
      - Need more discussion in mailing list.


   1. BIER-TE PCE&IDR, Ran Chen, 10 minutes


   - Dhruv : Do we need to have adoption in PCE working group
   - Tony : need to provide some time to WG
   - Jeffery: i think it is useful work. adding BIER would be good option
   in PCE. Email discussion can happen with other relevant drafts.


   1. BIER-TE BIFT-ID advertisement, Sandy Zhang, 10 minutes


   - Siyu : The Max SI field may need to be added.
   - Sandy: The BIFT-ID allocation for BIER-TE is different with BIER, the
   BIFT-ID of BIER-TE is per SD and BSL, so the number may not be too large.
   But it can be added for alignment.


   1. BIER Multicast use cases in DC, Weiqiang Cheng, 10 minutes


   - Tony: to summarize, if BIER can be used with sub-domain and other
   options. we can accommodate. But if there is frequent join and leave , we
   need to work on addressing the gap in this working group. RBS could be one
   of the possible solution and may be some alternate solution
   - Existing multicast solution can not satisfy this requirement.
   - From china mobile : this requirement can not be served by current
   protocols because scale would keep changing. are we going to change the
   charter again and again.
   - Tony : it would be productive if authors discuss what is needed from
   working group. If mind has been made that this WG group can not solve this,
   then we have nothing to discuss.
   - Andrew : There is requirement. and may be some work needed. Its good
   to see if we could get work done in BIER WG. if there is need to modify
   charter of WG , i am ready to do that. WG group need to find way to work
   here so that it can speed up. exploring within this forum would be good
   option. It is good to see requirement has been presented. and hearing WG ,
   it looks like we have way to solve it here in this working group.
   - Weiqiang Cheng: DC requirement are totally different
   - Andrew : DC portion and multicast portion are two area we can see in
   this requirement. but for DC portion there is discussion going on. and it
   is going to take time and it is not blocker for exploring if multicast work
   can be solved in this WG.
   - Weiqiang Cheng: if we start working with legacy technologies we may
   not move fast
   - Tony : this is one of the fast WG. within 8 years we have multi-vendor
   solution. If authors think that we can have proprietary solution then WG
   can not help.
   - Hooman: it would be good to have example of application. what about
   cross Data center ? are they going to different data center using some link
   between DC. I agree to tony, if you look something quick then we have to
   use existing one.
   - Weiqiang Cheng: If we want to use BIER, we do not have silicon which
   can support it. BIER failed because of its very larg network. DC is new
   model, you can deploy new solution.
   - Hooman: if we come up with brand new silicon , it would take 10 years
   - Weiqiang Cheng : we are looking for new solution even if it takes time
   - Andrew : please keep the discussion in mailing list and keep it
   restricted to requirement.


   1. BIER-TE BP advertisement, Huaimo Chen, 10 minutes


   - Not presented because the session run out of time.