Minutes for IDR at IETF-91
minutes-91-idr-1

          CHAIR(s):  Susan Hares <shares@ndzh.com>
                     John Scudder <jgs@juniper.net>

          o Administrivia
            Chairs                                                 10 minutes

            - Note Well
            - Scribe
            - Blue Sheets
            - Document Status

          o YANG model for BGP                                      5 minutes
            draft-idr-shaikh-bgp-model-00
            Anees Shaikh

          o Yang Data Model for BGP                                 5 minutes
            draft-zhdankin-netmod-bgp-cfg-01
            Keyur Patel

          o Comparison of Yang Modulesfrom I2RS                    5 minutes
            draft-hares-i2rs-bgp-compare-yang-00
            Sue Hares

          o IPv6 flowspec implementation report                    10 minutes
            draft-vandevelde-idr-ipv6-flowspec-imp-00
            Andy Karch

          o Layer 2 BGP flowspec                                   10 minutes
            draft-hao-idr-flowspec-l2vpn-01
            Weiguo Hao

          o BGP extension for Extended admin Group                 10 minutes
            https://tools.ietf.org/html/draft-wang-idr-eag-distribution-00.txt
            Michael Wang

          o Segment Routing Prefix SID extensions for BGP          15 minutes
            draft-keyupate-idr-bgp-prefix-sid
            Keyur Patel

          o Segment Routing Egress Peer Engineering BGPLS Extensions 5 minutes
            draft-previdi-idr-bgpls-segment-routing-epe
            Stefano Previdi

          o Egress Peer Engineering using BGP-LU                   10 minutes
            http://datatracker.ietf.org/doc/draft-gredler-idr-bgplu-epe/
            Hannes Gredler

          o Extensions to RT-Constrain in Hierarchical Route Reflection
          Scenarios
            draft-dong-idr-rtc-hierarchical-rr                     10 minutes
            Sue Hares

          o Add-Paths implementation report                         5 minutes
            draft-retana-idr-add-paths-implementation-00
            Alvaro Retana

          o BGP Link-State Extensions for Seamless BFD             10 minutes
            draft-zhuang-idr-bgp-ls-sbfd-extensions-00
            Zhenbin Li

Discussion Notes: (Note taker is Bill Fenner).

* Document Status (chairs)

o YANG model for BGP
  Effort assembled by a set of network operators - “OpenConfig”
  Motivation is to have vendor-neutral models
  Vendors can augment the model with proprietary features

  Goal is to have operators drive the model development
  since operators are the consumers.  Will publish in relevant
  IETF WGs and work to unify IETF and OpenConfig models.

  Plan to publish in netmod yang repo.

Kireeti: what I’ve heard from operators about service models: L3VPN, across
multiple vendors, need lowest common denominator. When you’re looking at policy
models, is it driven by lowest common denominator? what you use? A: It’s based
on what we use. Trying not to go too far into service level since different
operators have different ideas of how to deploy. Kireeti: How do you avoid
devolving to lowest common denominator? A: Trying to do more of a union, but
the features that we use

Rob Shakir: Same functionality implemented in different ways on different
vendors -> we will still include it in the model,

Jeff Haas: Want this to be picked up in idr: you don’t want to put in all the
knobs. How do you see this fitting into the idr model?

A: Want it to reflect useful subset, it can grow over time to reflect all of
the features published in RFCs.

Rob Shakir: That makes work like ? has been doing for features like AS
migration able to be modeled.

o Yang Data Model for BGP

No comments at mic.

o Comparison of Yang Modules from I2RS

bgp yang models way forward: we’ll likely have interims on these models to try
to move towards a common configuration draft.  Need rapid progress, prototypes.
 Configs (and common types, etc.) are a prerequisite for the i2rs work.

Jeff Haas: comment to all: figuring out what the “core set” is will be tricky. 
OpenConfig says “this is what is in our network” and that is great; will the
base model have to work for just-RFC4271 or is it OK to have the common set.

Sue: We’ll have to do that at interims, etc.

Kireeti: If you’re discussing yang models, the room has to be twice as good!

Saikat: At the end of the day there’ll be one draft for config?

Sue: Yes.  One draft for config, another for i2rs.

o IPv6 flowspec implementation report

  Have multiple implementations, testing them out.

  No comments at mic.

Sue: asks room about flowspec adoption; I was too far forward to see the hands.

o Layer 2 BGP flowspec

Andy Card: Did you look at other L2VPN technologies?  Draft is specific to
Ethernet, but other technologies can do any kind of attachment circuit.

Weiguo: Flowspec uses BGP to distribute traffic filtering rules.

Hannes Gredler: Missing different Ethernet encapsulation formats: LLC, SNAP.
Seems there’s no support for Ethernet hierarchy, e.g., q-in-q.

Weiguo: Will add.

Andy Card: Want to consider the cases that it’s not IP, but you still have
actions like “set DSCP” or “redirect VRF”.

Weiguo: It’s not always IP traffic.

Andy Card: But you have some extended communities that are specific to IP.

John: Repeat the comment on the mailing list.

Andy: If you’re looking to keep the NLRI component types discontiguous [[does
he mean distinct?]], IPv6 has already gone up to type 13; flow-label was type
13; you’re using type 13.

Weiguo: We should unify the assignments.

Sue: Andy, follow up to the list.

?1: Something feels wrong here. For every new address family or new protocol, I
need to have a different AFI/SAFI for the flowspec.  Can we look at a flowspec
type that can combine match critera for IPv4, IPv6, Layer2, …?

Saikat from Cisco: I have the exact same feeling: we’re matching

?1: would like to look at the whole problem space and try to find a solution
for flowspec.

o BGP extension for Extended admin Group

Saikat from Cisco: People will continue to add new things.  This doesn’t have
to be added to the main draft, jgs: it’s fine to progress this as its own
document

discussion on the list says it’s fine

o Segment Routing Prefix SID extensions for BGP

Kireeti: Did you really mean that SRGB is global within an AS?
Keyur: It is unique within an AS.
Kireeti: There are DCs that use lots and lots of ASes, maybe an AS only has two
devices. Keyur: You can reuse Kireeti: make it 4 bytes? Keyur: it is 4 bytes
jgs: 50 ASes coupled Kireeti: 1000 ASes! — Hannes Gredler: In section 7, you
write that it’s both SAFI 4 and SAFI 128. I can understand why SAFI 4, but for
SAFI 128, we have more than one routing universe. What is the mapping of a SAFI
128 NLRI to the SRGB? Keyur: We can announce the label, but if you have a label
index associated, you could use that value to compute a label if you’re
configured with the SRGB on a given router. Hannes: What if you have two VPNs,
and on those two VPNs we have the same index assignment? Saikat: That’s invalid
index assignment. You cannot assign the same label index for two VPNs. jgs:
What about label collisions? How do you handle this error condition? Keyur: In
VPNv4, between two VPNs you don’t overlap the label space. Hannes: So you’re
constrained in how you allocate index values for VPNs. Keyur: yes Hannes: How
do you want to promote this draft where you’re obviously violating the MPLS
architecture? jgs: It’s obvious that we’d bring this draft up in MPLS. Hannes:
I’ll make some popcorn

?2: DC providers want to build graphs of what supports this — want to add
capability negotiation? Saikat: BGP is hop by hop. ?2: If you have devices that
don’t support it you will create black holes

Ahmed (Cisco): related to violation of MPLS architecture: this pops up in every
discussion of segment routing. Keyur: yes, this is up to spring to clarigy

?3 (Huawei): If you assume there’s only a single label block
Keyur: No
?3: Do you believe there’s no way to have multiple blocks
Saikat: For a given node you only have one block; if there’s a device
limitation you choose the range that can be supported on that device. Even if
you do that, all you need is the lowest level (out of the offset), and every
index is an offset.  Think of the whole thing being there, but you have some
holes in it, and you don’t allocate labels out of the holes. Keyur: Each
protocol can have a configuration extension for that protcol’s block.

?4: What’s this mean on 128?
Keyur: If you attach it to 128-safi, you are telling your neighbor that here’s
a label that you should attach to send to me. ?4: But you receive the 4364
update today, and the label you’re receiving is the inner label. We expect
another protocol to give us the next-hop label. Keuyr: No, this is used to
compute the inner label! [[discussion got pretty technical and fast.  Sorry,
but I couldn’t capture the back and forth.]] jgs: This is very relevant, let’s
take it and hash it out offline.

?5: Every node has to be
jgs: for those who weren’t at the spring meeting, we’re referring back to the
conversation that was in spring. ?5: The index is globally unique, right? For
all the VPN prefixes? Keyur: yes.

jgs: There was a pretty extensive discussion of this basic topic in spring;
there were a whole different set of issues

[[More discussion with Luyuan and Keyur not captured]]

o Segment Routing Egress Peer Engineering BGPLS Extensions

No discussion.

o Egress Peer Engineering using BGP-LU

Shane Amante: advice: seems like we’re rapidly converging on the idea that we
can use BGP for everything: routing, SNMP (link utilization), maybe not
delivering YANG models yet.  All the things you outline in here (e.g., using
BGP-LS to signal) - you take a hard line saying that’s required.  Can you say
that these are things that would be nice to have in case some providers want to
use it or don’t want to use it?  E.g., also, add-paths: you only need that in
some scenarios. — Keyur: 1. We would use this with 3107? Push approach if the
bandwidth changes? Is this going to affect dampening? Will this destabilize the
network with push approach? Hannes: I hope you don’t enable dampening Keyur:
Why not use a different way to distribute some of this information? Hannes:
Perfect point: what we also have lined up for version 2 of the draft; Evan from
Facebook brought up that you don’t necessarily want to have *one* iBGP mesh;
you probably want to split it into peer groups, and just do some of the
features on the “controller” peer group.  You’ll see that in version 2.

Saikat: You really want it to only go one place
Hannes: What are you suggesting? DNA community?
Saikat: If you want to do it through 3107, some scoping is required.

Rob: I think there’s space for both BGP-LS and link bandwidth community.  Give
some options as to how to deploy it. Hannes: One block for egress labels, one
block for stats, some signaling carrier, could even be IGP path extensions.

o Extensions to RT-Constrain in Hierarchical Route Reflection Scenarios

Sue’s opinion: add-path scenario (#2 in the slides) is preferable

Please send comments to the list

jgs: There could be a 3rd bullet on slide 3: propose some other solution?

Jeff Haas: Propose to adopt this as a wg item, not because the solutions are
the right ones but because it describes the problem and it gives us a place to
work on.

Saikat: The original RFC’s language is a little too restrictive.  Nobody
follows what the RFC says but does what should be done.  It may be better to
just fix the route-reflector RFC. jgs: so you have a different candidate
solution? Saikat: We don’t think you have to be so restrictive as long as you
do the right thing. Regenerate the path at each hop will solve a lot of
problems.

Sue: So there’s feedback that this is work that is worth doing.  Work amongst
yourselves.

o Add-Paths implementation report

Alvaro: We should bundle all this stuff together; last call it.
Jeff Haas: The guidelines may need a tiny bit more love. We came up with a
bunch of recommendations about how to use add-paths. Alvaro: Will send survey
on Wednesday; people can reply by Friday; then we’ll be done by Monday.

o BGP Link-State Extensions for Seamless BFD

Jeff Haas as BFD chair: This is chartered work for BFD.  OSPF and ISIS have
already accepted their extensions.  BGP-LS is the right place for it. Saikat:
Question to the chairs: this will come again and again in the future: do we
need an idr draft for every code point in BGP-LS? jgs: We should look at how to
streamline it. Hannes: Eric Osbourne(?) did OSPF and IS-IS in one draft; maybe
we can do OSPF, IS-IS and BGP-LS in one draft.