* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Bess Status Pages

BGP Enabled ServiceS (Active WG)
Rtg Area: Alvaro Retana, Deborah Brungard, Martin Vigoureux | 2014-Oct-17 —  

IETF-101 bess minutes

Session 2018-03-20 1550-1820: Buckingham - Audio stream - bess chatroom


minutes-101-bess-00 minutes

          BESS WG notes 
          Author: John Scudder 
          Chairs: Stephane Litkoski and Matthew Bocci 
          15:50 meeting start
          Chairs presenting, welcome new chairs!  
          Working group status
          John Scudder: tunnel-encap status is fairly close to being advanced.
          [context lost due to etherpad hang :-( ]
          How many think it should be adopted? 
          (around 3) 
          How many think it shouldn't be adopted? 
          (status update 3 slide)
          Ali Sajassi: Mea culpa, I was supposed to update it, haven't yet,
          it's important.
          Ali Sajassi: draft-ietf-bess-evpn-trill -- did it around 5 years ago,
          interest seems to
          have dwindled, not going to revise.
          draft-ietf-bess-mvpn-pe-ce -- park? progress? 
          ... it will be parked
          draft-ietf-bess-virtual-pe -- park? progress?
          ... it will be parked
          Adrian Farrel: are you making the decisions in the room? on the list?
          Matthew Bocci: we'll confirm on the list, think of what we say in the
          room as a proposal
          to be taken to the list
          Status for:
          Himanshu Shah: L2VPN update. (see slides, requests WGLC)
          Jeff Haas: problem with policy draft and l3vpn is there is so much
          variability between
          vendors. Punted out of module.
          Stephane Litkowski: can't you put in some very basic functionality?
          Jeff Haas: isn't not just VRF properties it's policy algebra.
          Himanshu Shah: we don't want to predicate our drafts on the policy doc.
          Jeffrey Zhang: draft-ietf-bess-evpn-bum-procedure-updates progress has
          been made.
          Adrian Farrel: draft-ietf-bess-datacenter-gateway is in implementation
          stage. Linked to
          SPRING draft that explains how pieces fit together. "Getting there".
          Adrian Farrel: draft-ietf-bess-nsh-bgp-control-plane is fairly stable,
          dependent on mpls
          sfc, at implementing/getting stability stage.
          Adrian Farrel:  draft-ietf-bess-service-chaining (not an author,
          but have read) --
          "I think it's in the field" and should be moved to some form of
          closure. Maybe get
          some of the people who are using it to speak up?
          Andy Malis on "MPLS/PALS WG update on TCP MD5 deprecation for LDP":
          (see slides, come to
          MPLS meeting on Thursday)
          Alvaro, AD: At today's Routing Area chairs' lunch, we discussed this
          topic. We believe
          many times we don't implement because of operational issues. We are
          starting an initiative
          to create templates for Security Considerations, so we can have common
          language agreed
          w/in the area and w/ the Sec ADs. For example, agreed understanding of
          "a domain". You
          are invited to participate. These templates don't remove responsibility
          for writing a
          good Security Considerations, but are intended to help. 
          draft-zzhang-bess-mvpn-evpn-aggregation-label-00:  Jeffrey Zhang, 10min
          Ali Sajassi: inter-as option b -- global labels need to be translated,
          right? how to
          Jeffrey: they either get coordinated across your entire network, or you
          can do it at
          the border routers. 
          Ali: do you expect the controller to do that? 
          Jeffrey: you could have a controller for each provider. Not much different
          from assignment
           of route targets. Ali: if you have the common pool capability, you
           could extend the
           concept to underlay as well, right? But that's for a different
          Jeffrey: yes, they're different issues. 
          Stephane: do you have customers with these scaling issues? Jeffrey:
          no. (anticipate it
          could happen, for reasons) 
          Ali: one other thing, typically customers use non-aggregated, even though
          it increases
          state in core, number of s-pmsi or i-pmsi tunnels are not that large. Have
          you actually
          seen a scaling issue that makes customers do aggregation? Jeffrey:
          no. probably because
          they don't have that scale yet, or can tolerate. but bier is an
          aggregation tunnel, so
          it will drive the issue. Stephane: BIER should try to solve scaling
          issues we have. But
          you're saying it introduces new scaling issues. So why should we move
          to BIER? 
          Jeffrey: the issue isn't caused by BIER, it's *exposed* by BIER. 
          Ice: aggregation over single tree gives you less state. BIER lets you
          cut state but have
          no flooding.
          Ali: with BIER you don't need aggregation because you don't have state
          in core.
          Jeffrey: I don't think that's what Ice was saying.
          Ali: that was my own perspective.
          Stephane/chair: cutting the discussion.
          draft-ietf-bess-mvpn-expl-track-08:   Jeffrey Zhang, 15min
          (?) from Huawei: benefit of less routes and less signaling overhead,
          I'm more concerned
          about join latency it brings to BIER. My main concern is if it can be
          useful when two
          segmented areas both use BIER, can this mechanism also [be] useful? 
          (?): Segmented MVPN, two areas, both with BIER.
          Jeffrey: I'm not sure if it's relevant, but this solution does work
          with BIER.
          (?): Mentioned in BIER MVPN draft that it doesn't work with segmented
          Jeffrey: we'll need to discuss that in more detail. It *should* work. That
          should have
          been covered. At the mic we don't have time to get to the bottom, let's
          talk offline.
          Stephane/chair: already passed WGLC, shepherd review done. I'd like to
          do a 1 week WGLC
          on the changes. Jeffrey mentioned the normative dependence of BIER MVPN
          on this. As far
          as we know there's no implementation. Unfortunately based on BESS policy
          we can't progress
          the doc. But, that'll block the BIER doc. 
          Ali: are you making this call per draft? 
          Stephane: it's case-by-case. We've discussed multiple options. This
          solution seems to be
          the simplest one.
          Martin V (Incoming AD): for clarification, the policy allows the WG to
          decide, so this
          isn't exactly a special case.
          Stephane: we'll take it to the list.
          draft-ietf-bess-evpn-yang-05: Patrice Brissette, 5min
          (done, ready for WGLC)
          No discussion.
          draft-ietf-bess-evpn-igmp-mld-proxy-01: Ali Sajassi, 5min
          (done, ready for WGLC)
          Jorge Rabadan: Inconsistency in draft. (something) is sent always by PE
          even for local
          Ali: for local source we'll use s-pmsi. (?) will be used only for join.
          Jorge: If you have a PE that has rcvr and src in same bcast domain,
          do you still send
          the (?) rt?
          Ali: no.
          Jorge: you have one section that says yes and one that says no.
          Ali: send text.
          Jorge: I will
          Stephane/chair: please fix before WGLC starts.
          Jorge: second comment, I sent a list of comments to the list a long time
          ago. One of my
          comments that wasn't addressed was to simplify IGMP sync procedure. Lots
          of cases where
          you don't need whole leaf procedure, esp if you have receivers directly
          attached to PE,
          or if CE supports proxy. You can remove S,G from the MFIB. Makes leaf
          sync route optional
          for those cases.
          Ali: when rcvs and srcs and confined to multihoming PE?
          Jorge: in some cases the leaf sync route is not needed.
          Ali: please send text.
          Jorge: I will re-send.
          Mankamana from Cisco: will it not be difficult to have selective
          procedures when and when
          not to sync? Maybe we should discuss offline.
          Ali: let's look at the cases and evaluate whether we get valuable
          simplification from it.
          Stephane/chair: please discuss offline.
          draft-ietf-bess-evpn-vpls-seamless-integ-01:  Ali Sajassi, 5min
          No discussion.
          draft-ietf-bess-evpn-df-election-framework-00:  Satya Mohanty and Jorge
          Rabadan, 10min
          (done, merges two existing docs, request WGLC)
          Stephane/chair: we would like to proceed to WGLC ASAP, many other drafts
          depend on it,
          we need to finalize. Thanks for the work.
          Ali Sajassi and Mankamana Mishra, 10min
          Stephane/individual: why pick a new type and not a new capability w/in
          the existing type?  
          Ali: It modifies the hash, so it's a new DF type.  
          Stephane: related to DF election framework draft, I read it quickly,
          don't see we have a
          clear definition what's a type, what's a capability.  
          Ali: true. DF capability works across DF types, DF type is XOR -- either
          this or that.
          Do we want to add that to the draft?  
          Jorge: yeah, we can clarify that. Other aspect is DF type defines the
          algorithm to choose
          the DF. Capability on its own is not enough.  
          Ali: capability works in conjunction with type, type can work w/o
          capability. Capability
          improves type.  
          draft-sajassi-bess-evpn-fast-df-recovery-01:  Ali Sajassi, 5min
          (done, request WGLC)
          draft-sajassi-bess-evpn-fxc-03:  Ali Sajassi, 5min
          (done, request WGLC)
          draft-sajassi-bess-evpn-virtual-eth-segment-03:  Ali Sajassi, 5min
          (done, request WGLC)
          Stephane/individual: useful work
          Stephane/chair: you're requesting a lot of WG adoptions. Do you have a
          priority order?
          Ali: yes, I'll send it to you.
          draft-boutros-bess-evpn-geneve-02:  Jorge Rabadan, 10min
          Jorge presenting on Sami's behalf
          slide 4
          Ali: clarification, BUM bit purpose is described in EVPN-overlay, in
          RFC Ed queue. We can
          reference that. 
          Jorge: fair enough.
          draft-brissette-bess-evpn-mh-pa-01:  Patrice Brissette, 5min
          Jorge: are you saying that you only need ES routes, and not the EAD
          routes, or is that
          just my interpretation?
          Patrice: can work just for L3 as well.
          Jorge: but for L2 you do need EAD routes?
          Patrice: yes
          Jorge: it's confusing.
          Jorge: don't we need a new ____ type?
          Patrice: IMO it's just a new load-balancing mode.
          Jorge: ...
          Patrice: ...
          Jorje: it should work. What about hRW and DF election framework presented
          Patrice: if your q is to add a new type to that framework, I'll take
          a look
          Ali: between capability and type, I think in this situation it's a bit
          of a wash. I'd
          lean toward the capability. The functionality requires is pretty minor,
          not a new algorithm,
          can work w/ VLAN carving, HRW, preference, we just want to do it on a
          per-link basis.
          Jorge: I agree. On a PE basis, no change. ACDF capability must not be
          turned on.
          Patrice: want me to clarify?
          Jorje: yes, read the framework draft
          Patrice: Let me go through the DF framework 
          Jorge: you have a section on the IRB, right? 
          Patrice: should we take it offline?
          Stephane: go ahead and discuss
          Jorge: You want to drive IRB based on ES? Seems weird if not wrong.
          Patrice: Yes
          Ali: I see where you're going. Multiple ESes for a single BD. Let's take
          it offline.
          Patrice: ok
          Ali: did you say that we need to have the DF AC off? Or preference?
          Jorge: if you have the AC DF on, you can't rerun the election.
          Ali: It's AND of both. You configure the VLAN on both. This is on a port
          basis. Whenever
          the port becomes active and the VLAN is active, that VLAN is on.
          Jorge: If one is active, and the other goes down, we don't want to switch.
          Ali: we can take it offline
          draft-mohanty-bess-evpn-bum-opt-00:  Satya Mohanty and Sandy Breeze, 8min
          Sandy presenting
          Ali: I'm concerned regarding bang/buck with this proposal. In the final
          solution, for vast
          majority of deployment, multihoming is dual-homing. No gain with
          Sandy: correct
          Ali: if we have multihoming, if we have more than one CE multihomed for
          a given bcast
          domain, the number of CEs is 1-2 order of magnitude higher than PEs
          Sandy: this slide is my requirements
          Ali: if you have many CEs, DF election tries to be fair, spread election
          across CEs.
          You'll end up with all PEs becoming DF.
          Sandy: my specific problem isn't well-described by this diagram. My PE
          topo is NVE
          [...missed...]. Attachment circuit is VXLAN, one Ethernet segment :
          1 ESI. So I'd get
          good load-balancing. Between CEs, connected to a ToR.
          Ali: your PEs are NVE running VXLAN, your CEs connect to them. How many
          CEs for a given VNI?
          Sandy: Segment tied to one L2 VNI in each case.
          Ali: only one?
          Sandy: what you don't see is [...missed...]
          Ali: there many be many CEs. If for the same segment there are many CEs,
          all your PEs will
          become DF. 
          Sandy: the diagram doesn't represent my problem.
          Ali: we can take it offline. I'm struggling to understand the problem. I'd
          love for you to
          go over it with me.
          Sandy: we know hashing is per Ethernet segment. In our VXLAN deployment
          we have
          [...missed...]. We will never have more than one ethernet segment
          per ESI. 
          Ali: if you have 1:1 mapping, no MAC lookup needed. Why not use VPWS?
          Sandy: for tunnel endpoints downstream of PE, we have many:1 per segment.
          Ali: in that case it boils down to 1 CE per bcast domain. Because VNI
          is bcast domain.
          1 segment per bcast domain.
          Sandy: 1 segment per ESI.
          Ali: ESI or VNI.
          Sandy: same thing in my world.
          Ali: seems like limited applicability, we can talk about your
          situation. If there's
          single-homing, that PE's going to drop traffic, period. All the
          optimization will go out
          the door.
          Sandy: I know.
          Satya: I want to clarify the figure isn't wrong, even if you take another
          CE and that CE
          is mulithomed to the same PEs.
          Ali: for the baseline I agree, for 7432 it's the same. For the new DF
          framework it'll be
          [back and forth between Satya, Ali, Wen, some not into mic, not captured]
          Wen: Even the DF election algorithms, 7432 won't end up with the same
          PE as the DF, because
          if we have two different ESI ethernet segments, DF election is based on
          VLAN/BD so for
          different BDs...
          Ali: it's based on a single BD. that's the context.
          Jorge: seems more informational than standards track.
          Robin: four years ago in London we proposed another draft, in L2VPN WG
          multicst state
          advertisement, similar use cases.
          Stephane: which draft?
          Robin: I'll send it to the mailing list. [...missed...]
          Ali: There are some similarities, but they're different things. The
          proposal Robin is
          talking about is for optimizing on ingress. v0 of EVPN draft (the
          individual draft) it
          was mentioned there and removed. Sandy is talking about doing it on the
          egress. It's
          different things for different scenarios.
          draft-mohanty-bess-ebgp-dmz-00:  Satya Mohanty,  12min
          Jeff T: I don't think you need to create knobs. You need to update the
          draft. We brought
          up that the attribute needs to be non-transitive. Let's update, take it
          to IDR, be done.
          Satya: that doesn't talk about cumulative.
          Jeff T: Yes it does, and it's in IDR anyway.
          Jeff H: the link bandwidth draft this started from, you guys revived,
          great. It's
          permissible for nontransitive extended communities for you to re-originate
          it. The
          interesting caveat is that we (Juniper) deployed transitive version and
          we don't use the
          nontransitive version. We wouldn't interoperate properly. We were planning
          to approach the
          authors. Furthermore we implement this and will release it soon. From
          our perspective it's
          a local behavior, but offer the caveat link-bandwidth is like many
          "magic" communities this
          group tends to spit out, you expect to have just one of them. What do
          you do if you have
          multiple link bandwidth communities in a received route?
          Satya: point I take is don't do away with knobs, make link bandwidth
          Satya: how will we distinguish. I receive an attribute, modify and
          send. Now I don't know
          if it came that way or if I modified it.
          Jeff: it's an internal detail.
          Satya: the receiving guy won't know who changed it.
          Jeff: how would you NOT know?
          Ali: this is a small increment to link-bandwidth. the middle hop that
          gets the link
          bandwidth sums them, in the transitive case. that wasn't mentioned in
          the previous draft,
          we had two choices, add a section to the prev draft on have a new
          one. this was the easier
          Jeff: nothing stopping you with the core link bandwidth draft with
          treating it as a
          re-origination, which makes it effectively transitive. This is similar
          to bgp no_export,
          it's the expected behavior. For procedure, nothing new needed. For
          wanting transitive
          behavior, we already implemented, accumulation behavior is reasonable
          to document and
          we'd be happy to join you on the draft since we already implement.
          Stephane/chair: end of session, will get on with WGLC, WG adoption ASAP

Generated from PyHt script /wg/bess/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -