Skip to main content

Minutes IETF103: bier
minutes-103-bier-01

Meeting Minutes Bit Indexed Explicit Replication (bier) WG
Title Minutes IETF103: bier
State Active
Other versions plain text
Last updated 2018-11-29

minutes-103-bier-01
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

PRESENTATIONS:

#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 needed

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

Draft:
draft-venaas-bier-pfm-sd-00

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 messages.

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

Draft:
https://www.ietf.org/id/draft-purkayastha-bier-multicast-http-response-01.txt

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
heads...innovation

Tony P: Applicability makes sense here as it is about BIER

Greg as Chair: use case helps drive other groups

#7:BIER-TE-ARCH

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

Draft:
draft-zzhang-bier-tether-00

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

Draft:
draft-zzhang-bier-multicast-as-a-service-00

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
Draft-hu-bier-BFD-02
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.

Mike
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

Jingrong
Segmented
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.