Minutes IETF104: bier
minutes-104-bier-02

       BIER WG Minutes - Session 1

0-Welcome, Notewell, Agenda bash5minChairs

Greg(chair):
Apologies for the delay in posting the agenda. But all good now.
Tony on jabber.
Sign blue-sheets. Note well, noted.
Let's start with stig.

  PRESENTATIONS

#1: 1-draft-ietf-bier-mtud10min

Stig (Cisco): Few open issues raised during the adoption call.
Stig (cisco): Reading BIER IGP drafts, its hard to tell if ABRs advertise
prefix across area. It seems optional?

Les Ginsberg (Cisco): At least for ISIS, early drafts did't support it. But
later we added support to advertise across area. Stig (Cisco): Is this
advertisement across area optional ? Les (Cisco): subject to configuration.
Stig (Cisco): Ok, so the understanding is, as long as we advertise the bier
prefix across area, we advertise the sub tlvs as well Les (Cisco): Yes

Stig (Cisco): Is there any other issues other than whats listed here? ok, so we
will update the draft addressing the open issues in next rev.

Greg: When do you think we can call for last call
Stig (Cisco): Address all the issues and potentially in next ietf
Greg: ok, then, we will not take in to the list for now

Les (Cisco): Have we decided which way to go? PMTU vs This one. Combine or take
one path? Both are work group drafts ? Stig (Cisco): There is a difference
between these two draft. May be we can update the text in drafts to explain the
relation between these two.

Greg: Do you think we can combine ?
Tony: What exactly is your suggestion Les?
Les (Cisco): There may be some people who ask why do you do both ?
Greg as chair: Stigs suggestion is that each draft have their use cases, so
it's better we doc separately. Is that reasonable?

Greg: How many thinks we shall do individual doc ?  6-7 hands
Greg: How many thinks we should merge?  1 hand
Greg: Ok, we will take this discussion to the list

Alvaro (AD): It would be great if both drafts progress/advance together
Greg: Thank you

#2: 2-draft-ietf-bier-mld 5minStig Venaas

Stig (cisco): No slides, Nothing had changed past few ietfs.
Stig (cisco): Need help - people to review and give suggestions/comments

Greg: Who's read the draft ? - 2 to 3 hands
Greg: Who thinks it's ready lets take to list. 2 to 3 hands. Ok, same guys who
read the draft. Greg: Lets take it to the list for Vote.

#3: 3-draft-dhanaraj-bier-lsr-ethernet-extensions10minSenthil Dhanaraj

Senthil(Huawei): No doubt this is required. We need to discuss to confirm the
bift-id adv scheme. Call for adoption? Greg: How many read the draft? - 6-7
hands Greg: How many think its ready for adoption - 6-7 hands Gerg: How may
think, its not ready for adoption- No hands Greg: Room support. Let's take it
to the list.

Tony(juniper): Add a additional sentence which says that the BIFT-ids in MPLS
and this draft is completely different. Tony(juniper): Same BIFT-ids in mpls
and this, does't mean they are same. Its one sentence, but it'll prevent people
from doing crazy stuff. Senthil(Huawei): Okay

#4: 4-draft-purkayastha-bier-multicast-http-response15minPurkayastha

Purkayastha: Additional details added. Seek feedback and thinking of adding
other interesting use-cases applicable here.

Jeffrey (juniper): Im little confused. Do you use ip at all for this or not?
Purkayastha: We don't specify. Http response over bier. Overlay over bier

Greg: What's the stats of this draft, you have got use-cases to add ?
Purkayastha: We are open for comments and i have listed some of the uses-case
if interested can be taken in to draft Greg: Hands to contribute to use-cases -
no one ?

Greg as chair: So far what we've got is good use-cases. Im little hesitant to
add more. Greg: Request authors to put in list and ask feedback from list. Part
of process anyway.

#5: 5-pim-signaling-0510minHooman Bidgoli

Hooman: Good discussions with eric, stig and others.
Hooman: Added more details. If there are no other comments, we want to ask for
LC.

Greg: Who's read the draft? - many
Greg: Lots of discussion and sounds like we have converged.
Greg: Who think its ready for LC? - Many
Tony: 5 hands
Greg: Lets take to list.

#6: P2MP mLDP signalling (Hooman)

Hooman: Not going to present.
Hooman: Had a discussion with jeffrey. We will brainstorm again and come up
with alternate soln.

#7: 6-bier-ospfv3 5min Nagendra Kumar

Nagendra(cisco): Seek comments. We think it's ready. Call for adoption.

Greg: OSPFv2-Bier-Extn origniates here. Did it finished here or in LSR?
Room: Yes, it originated here and adopted here in BIER WG
Greg: Ok. It makes sense to do this here.

Greg: Who read this draft ? - 4 - 5 hands.
Greg: Who thinks its ready for adoption ? - 4-5 hands.
Greg: Same set of hands as read.
Greg: OK, lets take it to lst

#8: 7-draft-merling-bier-frr-00 10minMichael Menth

Michael: Need extensions to BIFT table. Working prototype exist based on P4.
Need inputs from WG

Jeffrey: At the top you mentioned, BIRT traffic resume after underlay converges.
Jeffrey: At the bottom you also say, with FRR we can fast re route. Whats the
difference ? Michael: In case of failures, the routing underlay need to
converge. If we have FRR, then traffic can go over backup path immediately.
Michael: After a while, normal forward entries repaired after underlay
convergence. Jeffrey: BIFT entries include backup path itself. Very advantage
of BIER is we can reuse the underlay. We don't need do anything special. No
need extensions. Jeffrey: So I'm not sure why we need this document. Jeffrey:
When you say, you need BIFT extensions, do you mean we need extension for
protocol or your internal implementation ? Michael: Additional fields to BIRT.
Some space to store. Michael: Link failure are easy, Node failures are
different Jeffrey: My understanding is, unicast node protection can be reused
here and special things are not required.

Ice: After failure, you are rewriting the bits, right? May be its required only
with BIER-TE Michael: No Ice: Why bitmask need to change for normal BIER
Michael: Use underlay FRR to not to send failed next-hop Greg as chair: That's
BIER-TE, in normal BIER, transit do not have bits

Hooman: Echo Ice comments. FRR make before break. But here, you try to go over
next next. Hooman: Why not use IGP for protection? Underlay IGP can take care
of everything? Michael: We use it to send to next next hop Hooman: Detect
failure by 2 ways.. BFD or link fail-hop. IGP takes care of it. I don't see how
you can make it any faster than IGP way Greg: you cant specify a bit to specify
the next-hop in normal bier. Thats BIER-TE.

Hooman: rsvp-te requires signaling to setup FRR. BIER uses IGP.
Hooman: As WG, we need to make the stand clear whether we need improve on BIER
failure detection time. From implementation, we see BIER is as fast as IGP

Rajiv Asati(cisco): Typical challenge with any tunneling based FRR is it
increase the traffic in the so called backup tunnel. Common problem with
RSVP-TE. Rajiv Asati(cisco): We already have BIER-TE FRR, what's different in
this ? Michael: We use IGP here.

Jeffrey(Juniper): Does it required any protocol extension ?
Michael: Im not sure. We have implemented. It's a local mechanism, so not
required. Jeffrey: Thats what i thought, this is about local implementation and
does not required standardization Michael: We may need other solution.

Jeff Tantsura (Apstra): When we talk about FRR, you rely on BFD or link
failure. We don't wait for igp-convergence. Need discuss in routing WG.

Stig: Just want to comment on MTU part. Path changes, MTU may change, so PMTU
may not work well. Thats why the other solutions for MTU is required.

Tony: Quick summary. Complete agree with Ice, Hooman, Jeffrey, Jeff.
Tony: I was thinking about controller based solution, it can directly program
the silicon. So dont see this need. Tony: We have R-LFA, TI-LFA, .. Can do this
Tony: It might just be educational

#9: 8-ietf-bier-bgp-ls-bier-ext-04

R.chen: Seek LC.

Greg: How many read the doc ? - 3 hands
Greg: Ready for LC ? - 2 hands
Greg: Lets take it to list to get opinion and last call

#10: 9-draft-chen-pce-bier-04

Jeff tantsura (Apstra): Why present here? It should be in PCE WG?
Greg: Its fine to present here, but it should also be presented in PCE
Jeff tantsura: Yes

Tony: Should be possible to program bift via controller. Discussed with sandy.
Should sync with yang closely. We need to present same model.

Greg: Is it informational here?  Are you intend to adopt in PCE WG?
Dhruv(Huawei): Yes, adopt in PCE WG

Ice(Cisco): I think its good for BIER-TE. But i think, there no underlay, no
IGP. FRR? Tony: Use pce for both bier-be and bier-te R.Chen: Now we though only
about te Tony: Thats my comment, we can do both. Benefit from the same stuff.

#11: 10-draft-ietf-bier-bier-yang-0420minRan Chen

R.Chen: Change - Added ethernet, ipv6 encap type.
R.chen: Seek WG LC

Tony: BIFT programming is very important. Its not added yet to yang model. BIFT
is only readable or can be programmable e.t.c ? Tony: We need discuss and take
it forward. Definitely, not ready for LC definitely

Senthil(huawei): You have added support for new ipv6 encap. Which type (MPLS in
ipv6 like 6PE or Bier in IPv6 or BIERv6) you are referring to ? Sandy(ZTE):
MPLS and non-MPLS Greg: Question is which ipv6 encap you are referring?
Senthil(Huawei): For example, in the model, i still see mpls label fields under
ipv6 encap ? Sandy: Okay, we will address this

Jeff(Apstra)/Dhruv(Huawei): is it NMDA compatible ? Yang must be compatible
with NMDA Sandy: Yes, We can discuss.

Greg(Chair): For the WG to discuss further.

#12: 11-draft-zhang-bier-te-yang-07 5minSandy Zhang

Sandy: Implemented in ODL and verified.  This is the 2nd time we are
presenting. We think its ready for WG adoption. Any comments ?

Greg(as chair):  How many of you read the doc ? - 5 hands
Greg(as chair):  How many for adoption ? - 5 hands
Greg(as chair):  Room supports. Take it to list

#13: 12-draft-hu-bier-bfd-03 10minQuan

Quan (ZTE): Discussed in WG several times. Updated to 03 version. Comments
addressed.

Hooman (Nokia): General question. With p2mp bfd already there, what are you
trying to solve here ? Quan (ZTE): p2mp bfd does not solve bier bfd. For bier,
it need some extensions to bootstrap bier bfd based on p2mp bfd Hooman (Nokia):
In bier, there is no deterministic root/leaf. So not sure what we solve Sandy
(ZTE): BIER bfd to enable monitoring of egress nodes, we think it can be used
for bier-mvpn failure cases. Jeffrey (Juniper): Same question as Hooman. With
bier, we think it's not needed. Jeffrey (Juniper): When you use igp to
bootstrap.. why don't use bier sub-tlv isntead of cap tlv Sandy (ZTE): Good
point, we can modify

Hooman (Nokia): This is oam over bier. Not oam over mpls over bier
Tony (Juniper): It is 2nd. It looks like an mixture btw p2mp bfd (not adopted)
and s-bfd. To me its look like s-bfd Tony (Juniper): Agree to hooman, could't
figure out

#14: 16-draft-ietf-bier-te-01 10minToerless Eckert

Toerless: All open action items closed. Ask for WG LC.
Toerless: Target is experimental.

Greg (as chair): Is experimental ok ? Or Can we do standards track ?
Alvaro (AD): I would rather do standards track

Greg (as chair): To toerless, why is it experimental, to lower bar and get it
adopted ? Toerless: Primarily because, not much experience in terms of
deployment with BIER-TE. It could be standards track as well if complies
charter. Alvaro: I do not remember anything mentioned in charter - about
deployment being required for Standards track Greg: Original charter needs
working deployments for standard docs as we set the bar higher. Greg: But as we
move ahead, with vendors going ahead with whispers of deployment Alvaro: Unless
this goes to standard track .. Greg: If we see operator/vendor whispers
support, we can go for standard tracks Toerless: Would love to see standard
track - love to get feedback in implementations

Dhruv (Huawei): Arch doc may be experimental. But pce/yang, we all aims for
standard. Dhruv: If this arch is experimental, then all the other supportive
docs also become experimental? Toerless: I don't think, thats true. Alvaro ?
Alvaro: We do have published standard yang models for protocols that are
experimental. Toerless: You tell us, what we should do? is deployment
experience must for standards track Alvaro: Requirements to publish standards
doc is based on WG interim policy Alvaro: We believe, we can't set blanket
statement for each WG or area. Alvaro: What this WG wants to do - it depends?
For example, you may say, we need at-least 2 inter-operable implementations or
just one implementation or may be no implementation. Alvaro: We want WG to
discuss

Greg: It's up to us. Our work, our decision.
Alvaro: You think this WG needs no implementation for standards doc?
Greg: No, what i meant is we need discussion in the WG.

Ice (Cisco): DETNET - Use this BIER-TE arch. Is that experimental ?
Toerless: Not sure. I think no dependancy. They like readymade rfc to use.
Tony: i don't think so, that they use BIER-TE. Not yet.
Toerless: Personally like to see standard

Jeffrey (Juniper): When first draft came out - i thought i dod't scale. I have
not followed since then. Can it scale better now ? Toerless: Not much changed
in terms of scale. We need to gain experience. Not everything is PS backbone.
Jeffrey (Juniper): Raised this because to decide exp/std track

Greg: How many read? -  8 hands
Greg: How many thinks it's ready for LC? - 7 support
Greg: We have room support. Let's take it to list. Other discussion we need to
decides - experimental or standards track.

       BIER WG Minutes - Session 2

PRESENTATIONS

#14: 13-draft-mcbride-bier-ipv6-problem-statement

Mike (Huawei): Goal is to be solution unbiased and help WG to make a decision
how to go about BIER v6

Greg: Are you saying srv6 works on bier multicast?
Mike (Huawei): No, im saying srv6 (ipv6 encap) is progressing in spring WG

Greg: What do you mean by native ?
Mike: Encapsulate within v6 header.
Greg: We are talking about both encode and encap, not only encap
Mike: That's right

Jeffrey: A comment on ipv6 native. Because bier uses its own header, no matter
how you do it, we cannot call it ipv6 native

Tony: What is this draft supposed to be as we move forward ?
Mike (Huawei): Requirements doc help deciding the solution
Rajiv(Cisco): Yes, it should really capture the requirements and any additional
use-cases that come out of ipv6.

Ice(cisco): Thanks. It's useful to see different options proposed for v6 in one
place. Ice(cisco): I think, overall problem is to use bier in ipv6. Many ways
to do that. Ice(cisco): As jeffrey mentioned, no matter how do you put it, we
would do replication based on bier forwarding. Cannot call as native.
Ice(cisco): I feel bier-eth is clean way to do it. People may say bier-eth is
not ipv6, but its just perception. Tony(Juniper): Either you use the bytes used
for v6 or just put bier after v6 header and dont use the globally significant
v6 address. Thats trouble. Ice(Cisco): DA is most native. But there are issues
with draft Mike(Huawei): Can address some issues via this draft if it proceeds.

Toerless (Huawei): We need to wait for the result in SRv6 arch and encap work
as they consider 8200 requirements during review. It applicable to hear as well.

Stig (Cisco): I agree about native or not discussions. But i do like using ipv6
tunnels connecting bier domains. Mike (Huawei): Thank u we may add this
use-case. Jeffrey(Juniper): ipv6 tunneling of bier packets is not bier
forwarding. Jeffrey: MTU issues? Tony(Juniper): Fragmentation in IPv6 is the
least of the issue Rajiv(Cisco): Lets not get in to solution mode and lets
focus on requirements and use-cases Tony (Juniper): Requirements should in fact
been the first slide.

Toerless(Huawei): I like the requirements. But what i mention is, there are
solution like adding extension header mentioned in the doc Tony: Thoses need to
be argued out, the different solutions. Thats the reason for this draft.
Toerless(Huawei): Waterfall model? Requirements first, then find solutions? so
wondering how to go about it ?

Greg: In our discussions, we know we blur encode/encap
Toerless: Not ipv6 anymore, Can say same about srv6?
Greg: I agree that each extenion header have the purpose. But in case of bier,
we do multicast

Jeffrey(Juniper): No matter what option you chose, you need new HW
Tony: link local
Jeffrey: no matter what you do, to do bier forwarding, you need bier hardware

Rajiv: From ipv6 point of view. That last 64 bits can be used in many different
ways, So use last 64 bits is not a far fetched solution

Ice(Cisco): One more point about HW support, We can't assume, if you support
BIER we can support other bier solution like ethernet we have discussed here.
Ice(Cisco): Where to put the bits? With SRv6, one of things is extention can be
put in by application, because it's L3. It something we need to check and put
in requirements list. Ice(Cisco): But for routers, its a pain as the bits are
so far inside the packet and it needs read deep inside Greg(Cisco): Apps can as
well construct BIER header no matter where it is? Ice(Cisco): Need socket
support, root access

Tony: (use link local) BIER in IPv6 - Bier can be done in control plane slowly
for low end hardware. Toerless: I was wondering, no extension headers, it will
take away the pain of 8200 stuffs Toerless: But then we may have to re-write
the source and destination address at each hop Tony: BIER in 6, will be
refreshed

Greg: Summarise
Greg: Requirements list - good, That we should do
Greg: Solution included in the draft - Add reference to the original the docs
if they are alive

Mike(Huawei): Should we be solution agnostic ? or should we put pros/cons of
each solution ? Greg (as contributor): Thats adds more value. As a WG doc, we
feel thats what exactly we should do? Toerless (Huawei): I think it's valuable.

Greg: Lets take it to list. Re-structure, may be problem statement,
requirements first and then the solutions

Mike(Huawei) : Request to chairs, To kickstart things, is this the doc that WG
wants to adopt? Greg : Who read the draft? - 8-9
       Who support for adoption? - 8 - 9

Greg: Solid support from room. Let's take it to list.

#15: 14-ietf104-slides-bier-ipv6-encapsulation 20minMike McBride

Tony(Juniper): Is the DA is link local scope?
Senthil(Huawei): Currently we did't mention about it. We say FF0X, where X
could be any scope. Tony(Juniper): Well, it makes a huge difference right.
That's ok for now, the discussion are open. Lets go on..

Toerless(Huawei): One of the interesting question is, whether you are allowed
to change the bitstrings at transit without calling the operation be
decapsulation and re-encapsulation. Toerless(Huawei): And if we call it as the
later one, should the node which re-encapsulate are required to change the
source-address? Senthil(Huawei): RFC8200 says that, options type data carried
by destination options header, the content is allowed to change.
Toerless(Huawei): Thats basically for 6man to review. Whether transit can do
that, without having to change the source-address. Senthil(Huawei): What we say
is that source address is not required to change Toerless(Huawei): Need
confirm/review by 6man Rajiv(Cisco): 8200 allow changing the content. IIPM we
have similar proposal where the OAM data change each hop, but without changing
the source-address. Rajiv(Cisco): But let's still confirm Toerless point.
Jeffrey(Juniper): How does multicast DA works in LAN env ? Senthil(Huawei):
Need think about it. Jeffrey(Juniper): If you use unicast DA, does the packet
be sent to control plane? Ice(Cisco): It has to be a well known multicast
address. Other wise igmp snooping will kill this.

Tony(Juniper): About unicast DA to bypass non-bier capable nodes, Tunnel exist
and it works. Dont do shortcuts

Greg: Lets work on problem satement first. Then will get in to these pieces.
Jeffrey(Huawei): Use unicast DA in LAN. When you use multicast DA, it's like
tunneling on each Hop.

Toerless(Huawei): Need consider presenting 6man WG to get feedback. Bier in
IPv6 draft is simillar to this. Should we merge? Tony(Juniper): If 6man allows
you to not change SA, thats cool. But i think, putting it inside options is
overruled. Next-proto = BIER is far more practical. Its kind of similar, we can
think abut merge.

#16: 15-draft-xie-bier-ipv6-mvpn-00 10minJingrong Xie

Jingrong(Huawei): Request feedback
Greg: Let's work on problem statement draft and will comeback to this.