Minutes IETF100: bier
minutes-100-bier-00

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.