Minutes for BIER at IETF-94
minutes-94-bier-1

IETF 94, Yokohama, Japan
BIER WG Agenda
Fri, November 6, 2015, 09:00 - 11:00
Room 413


GregS: meeting starting.



Welcome, Notewell, Agenda bash                        Chairs
 5 min

Note well applies.



draft-ietf-bier-isis-extensions-01                TonyP                5 min

Tony P presenting.

GregS: what is your feeling on how matyre this is, when cal LC it?
Tony: there is a minor thing to split on the architecture line.,
GregS: architecture draft likely will stay open for a long time.
Tony: no intention to rush it.
GregS: Alia mentioned not wanting to run WGs forever.
Tony: ...
GregS: it used to be a requireement.
Tony: you cannot LC it before you have an implementation.
GregS: anyone paid attention to this document in the room?



draft-wijnands-bier-mld-lan-election-00                Ice Wijnands
 10 min

Ice presenting.

GregS: this is a problem, although not convinced that this is the source
problem. It should be membership triggered. Whatever the control plane is,
it should select A or B
Ice: only if you have S,G.
GregS: how those two routers know ..... They both can start from the same
domain.
Ice: therefore the need for DF election.

GregS: this seems to be an BIER requirement and issue, what about the mLDP?
Ice: MLDP is not used that way.
Stig: We should do it in PIM because it is generic problem, and extension
to IGMP. We have experience with DR election and load balancing. We have
the expertise on working on this problem.
Jeffrey Zhang/Juniper: agree on PIM. There are also additional proposale,
PIM DR procedure, and those could be merged.
Ice: wouldn;t it then put tre requirement to run PIM?
Jeffrey: proposed PIM could be ..... just enhance this and then require
using it as generic announcements.
Stig: It is not specifically PIM but a generic problem.
GregS: is that looking at rebuilding the mechanisms fdor runnign the
interfaces?
Stig: it is about how you gracefully switch to another DR. There is also a
solution for load balancing, different DRs for different groups.
TonyP: similar is being worked on EVPN. Non-revertive bits, etc. That would
be a good place look at.
Sandy/ZTE: poer group DF election - hoiw does that work per group?
Ice:L group based election needs those procedures specifired.
Sandy: Is that IGMP hello>
IceL yes.
Weiguo/Huawei: for the access scenario, active/stby and actv/actv solution
- is it only for actv/stby, or for actv/actv too?
Ice: we haven;t specified the provcedurers yet.
GregS: have you red the drafr? This is a problem statement, not a solution
now.
Ice: we look at the procedures and will come with the solution.
GregS: and that will be a common solutins.
TonyP: this is not homenet, please do not invent protocols on the mike.
Toerless: there may be IGMP on one side and PIM on the other, will this be
adressed?
IceL yes.
Ilya Vershkov: will snooping procedures change?
Ice: snooping will be affected, yes.
GregS: anyone needs any feeling that this work needs to be placed here? Any
has objections to move it to PIM?
GregS: I like to delegate this ti PIM.
Stig: the draft can be presented in both groups, and please talk to PIM WG.
GregS: that is a good idea if it gets more people across boundaries.
Ice: who was in PIM yesterday?
GregS: there is some overlap already.
GregS: Stig - do you see this as an item to adopt?
Stig: there is little content in the document, we cannot discuss adoption
yet. There was interest in the room, I don;t see a problem adopting it
later.
GregS:....
Stig: there is one drafts that is abiout to be adopted, also load balancing
drafts too.
GregS: thiose all are the extensions.
Ice: if you modify IGMP, and make that look similar to what PIM does, we
can reuse the mechjanisms.
GegS: Do we have an AD here? Who is assigned AD for this?
Alia: Alvaro. I would like to focus on essentials.
TonyP: They need to coordinate.
Dave Allan: trill has teh same issue.
GregS: does trill have the active efforto to solve it? We need to control
this problem. We need to consolidate work.
JeffreyZ: this is different from the trill.
Alia: I can take a look at the draft and talk to Alvaro. If it has more
generic applicability than BIER it should be in PIM. This does not seem to
be that central.
Ice: does anyone feel that this should not be done in IGMP? Speak now or
stay silent forever.
GregS: no objections raised on this.




draft-mirsky-bier-path-mtu-discovery-00                Greg Mirsky
 10 min

GregM presenting.

Loa Andersson: hasn't this problem solved in IPv4 multicast?
GregM: there is no mechanisms in the ipv4 multicast a mechanism to indicate
which nodes to respond.
Toerless: that is the reason that it was recommended to use the minimum
size frames. I do not see this being very different in BIER.
GregM: using BIER bitstring we can explicitely specify the BFERs that we
are we are targetting and thus limit which nodes to respond. That reduces
the number of PMTUD responses in the given subdomain.
Toerless: is this OAM thing only, or coupled to application? Would it ever
do fragmentation?
GregM: currently BIER for MPLS does not do fragmentation, and this is for
OAM.
Toerless: I do not believe that PMTUD is defined only for OAM.
Erik Nordmark: IPv4 has noting because there are no ICMP error resturned
for errors. If I recall there is packet too big ro IPv6. The question
whether this is OAM only or application is intersting.
Loa Andersson: If you you send to E, F, and G only, will that resolve in
different MTU size ithan if you sent ot De, E, F. G?
GregM: yes.
Loa: then you need to keep state of where it was sent and who rersponded.
Greg: that is per subdomain.
Loa: the for each subdomain you need to tract MTU size?
GregM: yes. We may select the minimum of all MTU that we discovered.
Loa: I think you will be forced to do that if yiu have non-compatible BFR
in the path.
GregM: noncompatible would be the one that does not support this extention.
There should be some heuristics on decreasing the proe size.
Andrew Dolganov. You can do this per channel. This would be used either
base don discovery, or base don the channels that you distribyute.
TonyP: would we nned to standartize this?
Andrew: we would standardize the procedure, but not the mechanisms how to
do it specifically.
GregM: if we have two distribution trees, we run it per tree and the
minimum will be lowest of them.
Loa: I am fine with that.
Toerless: we havent done that for OAM in other networks, the requirements
doecument does not talk about this. Would be noce to write up the need and
use cases for it.
GregM: BIER provides instrumentation that allows to do it in a n effective
way.
GregS: this is topology MTU, not really a path MTU. All the MTU mechanisms
that I am aware they are based on the application, thisa seems to be
standalone to the network.
GregM: I do recall in some other encapsulations - VXLAN, maybe SFC - they
do path discovery.




draft-chh-bier-bier-yang-01                        Ran Chen        15 min

Ran presenting.

TonyP: would like some discipline - has this been run through the
validation tool? Alia - do you think this needs YANG doctor assigned?
Alia: yoiu can send to YANG doctors and check how mature it is, there is
also a Sunday YANG editin session, please bring it there.
TonyP: BIER is AF -independent and model will need to be aligned to that.
Ice: we associate BFR id with loopback, and you need to lookup that in
particular table.
TonyP: I was referring to the subdomain AF independence.
Ice: if you configure which AF you support.
TonyP: subdomain can carry multiple AFs.
Ice: should it be the other way around?
TonyP: we can carry MPLS frames too. this does not seem to be deeply looked
at.
?/ZTE: we defined different BFR per AF??
TonyP: but the label will be the same, and I do not see a need for
specifying that. We are inventing protocol on the mike, it does not seem
that this model has been depply reviewed.
TonyP: who wants to work on YANG models, people, this is your career. :-)
Alia: given that BIER is a new technology and how it progresses, and given
the progressing of YANG models, it is good to make shure that model
mathches the architecture. Please review it.
Toerless: it is even more important as there is a lot more conifguration
that needs to be pused.
GregS: who things this needs to be adopted. Will take to the list.



draft-chen-pce-bier-00                                Ran Chen





draft-eckert-bier-te-arch-02                        Toerless Eckert
 10 min

Toerless presenting.

Ice: in TE there is no set id, there is subdomain and bit positions.
Toerless: there is, I will explain that in later slides.

Ice: it seems that you are mixing semantich of SPF BIER and TE that are not
compatible. An example of set ids .... if you use that same BFR ID for TE,
you can reach that node if the bit position is the same on all nodes along
the path, and you need to engineer for that.
Toerless: I do not get that.
Ice: BFR ID is transalted into a bit position. Al the nodes in the path do
not need to use the same bit? You need to configure on each node a set id
for a particular next hop. But tha it is not how it is configured, it is
automatically generated. You are mixing set id and subdomain.
Toerless: the intention was to make it easy for flow overlay solution.
Ice: as it is dynamically generated and configured, you should use
subdomains for it.
ToerlessL in normal BIER, I am not getting an ideal forwarding.
TonyP/hat off: I do not see anything wrong with using different subdomains.
Mixing the semantics in the same domain - it iwll make the cost of hardware
to go exponentially.
Toerless: there would be two labels bound for the sma subdomain,
TonyP: but then you reinvent subdomains. We have discussed this before. It
is a distinguising of the servite taht you ruin in the subdomain.
Toerless: I am open to have BIER and BIER-TE in the same domain. Let's see
whether there are technical reasons that would preclude this to work.
TonyP: I do not think that you can mix TE and normal BIER semantics.
Toerless: the simple case - subdomain has BIER or BIER-TE only. Flow
overlay cannot deal with one parameter in a simple way. I am not sure there
is anythign that would break.
Ice: BRF ID is just a value, but you need to know which set id it is.
Toerless: that is an interpretation. I would like to take whatever I can
get out of IGP.
Sandy: You divide BIER domain into several areas - do they directly map to
IGP areas?
Toerless: there is no necessary relationship, they could match but that is
not required.
Sandy: usually we cannot use IGP area directly? ??
Toerless: that seems to be relaed to the management aspects. If you have an
IGP area, that would be a similar approach in the area in BIER-TE.






draft-zhang-bier-designed-routing-00                Sandy Zhang        10
min

Sandy presenting.

TonyP: it is cute but unfortunately does not work. You cannot express the
DAG via a topological sort. This will lead to packet replication. We can
keep it on the email, or you can implement and experiment with it.




draft-wang-bier-vxlan-use-case-00                Linda Wang        15 min

Linda presenting.

Toerless: I do not undesstttand teh use cases. And also uncertain about the
scalability. DC has millions of VMs and 100000s of identifiers, and some
use cases that would indicate the scale numbers would be needed. If this is
in the context on the unknown traffic, then flooding may be good enough.
Linda: thank you,.
Jeffrey Zhang/Juniper: today VXLAN can use PIM to do this functionality.
Why cannot we just BIERinstead of PIM trees, everything else stays the
same? No changes would be needed in this case neither in BIEr, nnor in PIM.
Linda: BIER could also be used for connecting other NVEs. ??? This seems to
be a discussion about PIM and BIER positioning.
Jeffrey: you do not run PIM at all, just use the groups, and use BOER for
forwarding.
TonyP: the membership discovery is overlay problem, and trying to put it in
BIER layer will make it melt, there will be changes flooded for every VM
membership change.




draft-want-bier-lite-ospf-extensions-00                Linda Wang


Linda presenting.

GregS: any comments?
TonyP: who has read the draft? Selected few.
Ice/Cisco: you need to be careful if you introduce another data plane
encapsulation for BIER as it is expensive to implement across platforms.
Not certain whether MPLS could not solve this problem. We have discussed
this before and I am not convinced that we need to work on this.
GregS: this particular deployment does not support MPLS. What is missing in
label encapsulation that could be used here? We just want an ethertype and
not using MPLS as such here.
Ice: this will likely require replicating a lot of forwarding code that is
already there.
Pat Thaler/Broadcom & IEEE 802 vice chair. Before we do this we need to
show this to IEEE 802 and see how they feel about it, I would request to
send a liaison to IEEE 802.
GregS: encourage to read the document and see whether the use case is good.
Will keep the discussion on the list, and please read and review the
document.






GregS: Encourage reading on what is there and please discuss. End of
meeting.