Skip to main content

Minutes IETF98: idr
minutes-98-idr-03

Meeting Minutes Inter-Domain Routing (idr) WG
Date and time 2017-03-31 14:00
Title Minutes IETF98: idr
State Active
Other versions plain text
Last updated 2017-04-19

minutes-98-idr-03
IDR meeting at IETF 98

Chairs: Susan Hares, John Scudder
Notes: Ignas Bagdonas (additional notes John Scudder)
Jabber: Wes George

-----------------------------------------------------------------------------
Agenda 

9:00-11:30am  3/31/2017 
Room: Zurich G 

(9:00)
Chair's administrivia [9:00-9:05] 
0) Agenda bashing and Chair's slides  [5 minutes] 

Updates on Preventing Attribute Squatting  [9:05-9:15]  
Drafts related to the discussion: 

1) Additional Reviewers for BGP Registries [Sue Hares]  
https://datatracker.ietf.org/doc/draft-hares-idr-bgp-registries/

2) Should we deprecate Atomic Aggregate -is it worth it?  [Sue Hares]
https://datatracker.ietf.org/doc/draft-hares-deprecate-atomic-aggregate/


Updates on existing drafts [9:15-10:15 am] 

1) Making Route Servers Aware of Data Link Failures at IXPs [Randy Bush/Jeff Haas] (10)
https://datatracker.ietf.org/doc/draft-ietf-idr-rs-bfd/  

2) Route Leak Prevention using Roles in Update and Open messages [Alexander Azimov/Randy Bush] (10) 
https://datatracker.ietf.org/doc/draft-ymbk-idr-bgp-open-policy/

3) Route Leak Detection and Mitigation [Sriram] (10) 
https://tools.ietf.org/html/draft-ietf-idr-route-leak-detection-mitigation-06  

4) Signaling Maximum SID Depth using BGP-LS [Jeff Tantsura] (5)
 https://datatracker.ietf.org/doc/draft-tantsura-idr-bgp-ls-segment-routing-msd/

5) BGP Next-Hop Dependent Capabilities  [Bruno Decraene] (10)
 https://tools.ietf.org/html/draft-decraene-idr-next-hop-capability-03

6) BGP Route Refresh Options [Tony Przygienda] (5) 
https://tools.ietf.org/html/draft-idr-bgp-route-refresh-options-02  

7) BGP SR Updates [Acee Lindom] (7) 
https://tools.ietf.org/html/draft-ietf-idr-bgpls-segment-routing-epe-11  
https://tools.ietf.org/html/draft-ietf-idr-bgp-prefix-sid-04  
https://tools.ietf.org/html/draft-previdi-idr-segment-routing-te-policy-05  

[3 minute for switching] 


New Work [10:15-11:30] 

1) New definition of ISP Internal EBGP Border using BGP Roles [Alexander Azimov/Randy Bush] (10)
https://datatracker.ietf.org/doc/draft-ymbk-idr-isp-border/

2) BGP Logical Link Discovery Protocol (LLDP) Peer discovery [Acee Lindem] (10)
https://datatracker.ietf.org/doc/draft-acee-idr-lldp-peer-discovery/

3) BGP Signaling of IPv6-Segment-Routing-Based VPN Networks [Gaurav Dawra] (12)
https://datatracker.ietf.org/doc/draft-dawra-idr-srv6-vpn/

4) Compressed BGP Update Message [Tony Przygienda] (10) 
https://datatracker.ietf.org/doc/draft-przygienda-idr-compressed-updates/

5) Populate to FIB Action for FlowSpec [Zhengiang Li] (10)
https://datatracker.ietf.org/doc/draft-li-idr-flowspec-populate-to-fib/ 
 
6) BGP Neighbor Autodiscovery  [Xiaohu Xu] (10)
https://tools.ietf.org/html/draft-xu-idr-neighbor-autodiscovery-01
 
7) Persistent Route Oscillation in BGP Constrained Route Distribution [Jakob Heitz] (10) 
https://tools.ietf.org/html/draft-idr-bgp-rt-oscillation-01
 
[3 minutes for switching] 

11:30 am 

-----------------------------------------------------------------------------
Minutes
Times given in parentheses are approximate wall-clock times, for reference.

9:00-11:30am  3/31/2017 
Room: Zurich G 

Sue: Meeting starting. Note well applies. 
John: You have seen the note well many times but this is a reminder on
the contribution definition in the IETF. All things you say and present
here are covered. It is a boring but important stuff.

Chair's administrivia [9:00-9:05] 
0) Agenda bashing and Chair's slides  [5 minutes] 

JGS: Agenda review. 

(9:03)
Sue: Extended messages. 
Randy: As an interested party - I really don't give a damn. 
John Scudder/wg member: We can do any of them. My own preference is
option 3. It is 64K for all messages but do not try too hard for OPEN.
At this point we should say perfect is the enemy of good enough. 
Randy: I have strong opinion on OPEN. If you try to open and you cannot
negotiate what options you have to use failing is operationally is not
the way to do. 

Updates on Preventing Attribute Squatting  [9:05-9:15]  
Drafts related to the discussion: 

1) Additional Reviewers for BGP Registries [Sue Hares]  
https://datatracker.ietf.org/doc/draft-hares-idr-bgp-registries/

Sue presenting. 

(9:08)
Acee: It seems that the current allocation policy usually works, there
are some cases where it was not used then people ended up with coding
attribute code points that were not allocated. 

(9:08)
2) Should we deprecate Atomic Aggregate -is it worth it?  [Sue Hares]
https://datatracker.ietf.org/doc/draft-hares-deprecate-atomic-aggregate/

Sue presenting. 

Sue/wg member: it seems that we need to dig deeper into this problem
space. CAIDA may help with the analysis of BGP data with their tooling. 

Updates on existing drafts [9:15-10:15 am] 

1) Making Route Servers Aware of Data Link Failures at IXPs [Randy Bush/Jeff Haas] (10)
https://datatracker.ietf.org/doc/draft-ietf-idr-rs-bfd/  

(9:12)
Jeff Haas presenting. 

(9:18)
Tony Przygienda: Who is dealing with BGP here - is it a client or a
server? 
JH: This is in the IXP (exchange point) environment. 
Enke Chen: Naive question. Can this be done without changes to route
server and changes to BGP spec? The client receives the updates from Rs
and can see whether they are reachable.
JH: You can learn your next hops from the peers but the other side needs
to know that too. It may be asymmetric. Point two - BFD sessions would
need to be pre-provisioned, and hysteresis if what you have learnt is
better when RS helps you. When something becomes unreachable there may
be a backup path and BFD is needed for that path too. 
Enke: If you have routes from the other client and if you do not
advertise that you have no next hop. 
Job Snijders: If this mechanism would depend on add-path then the RS
would not need to know the reachability of the next hops. 
JH: We have discussed that. We think that route asymmetry case is a
problem here. With a RS supporting add-path is not enough - many edge
nodes do not support that. You also need to have a consistency of
add-paths between a set of RSes. 
Job: By the time this has running code it may be add-path will be
supported too, it is a question which gets deployed first. 
JH: BFD is used no matter what and we need to know next hops anyway.
There seem to be benefits of using this mechanism. 
Job: Agree.

2) Route Leak Prevention using Roles in Update and Open messages [Alexander Azimov/Randy Bush] (10) 
https://datatracker.ietf.org/doc/draft-ymbk-idr-bgp-open-policy/

(9:23)
Alexander presenting. 

Randy Bush: I would like to speak against the complex role. The complex
role is not common. For years I've argued against Gao-Rexford, Recently
Philip ___ did a study showing it only holds for 60%ish of ASes. This
doesn't mean complex is common, it means there are some who don't
up-pref customers. People doing complex rule are supposed to be smart
but they of course are not. Complicating protocols for 1% use cases - I
don't know about that. 
Doug Montgomery: Do I understand your proposal that you have multiple
sessions just to find out the role?
Alex: Yes. 
Randy: It is fairly common in cases when people give you global peering
and transit. We do two sessions for that. 
Job: We do that sometimes too. 
Jakob: What about IPv4 and IPv6 sessions? 
AL/Qrator:... 
John S: How many people have read the draft? A few. 


Sue: Introducing Jie Dong. He is a secretary for IDR. Thank you, Jie. 


3) Route Leak Detection and Mitigation [Sriram] (10) 
https://tools.ietf.org/html/draft-ietf-idr-route-leak-detection-mitigation-06  

(9:31)
Sriram presenting, 

Sriram asking the community: is it easy to change to community based? 
Job: Community would be my preferred choice as that does not depend on
software being available. Randy points out we would rely on people
typing properly. We've seen that implementors can treat communities as
they do attributes, though.
Ruediger Volk: In my setup throwing in another community works more
smoothly. But, I think that many parties do not have configuration
systems that will be easily extended for doing this and rely on manual
policy configuration and then a separate attribute comes as a more
secure and less easily messed up with. For the benefit of such parties
the attribute is a better way to deal with it. 
Randy: Job, I am a little confused. You are worried abut the attribute
that required the deployment of code. But you want a vendor to enforce
the use of community value? Doesn't that require new code?
Job: They are not mutually exclusive and they move at different
timelines. 
Randy: The goal was for the router to enforce the peer flag. For a
router to enforce it will take code change regardless the way it is
done. 
Sriram: it the intra-as... 
Randy. Not talking about that. Job, do we need to talk offline? 
Job: Sure. 
Jakob Heitz: To enforce communities does not require changing route
code, could be done in the policy. 

4) Signaling Maximum SID Depth using BGP-LS [Jeff Tantsura] (5)
 https://datatracker.ietf.org/doc/draft-tantsura-idr-bgp-ls-segment-routing-msd/

(9:43)
Jeff Tantsura presenting.
 
Jeff: We request IDR Adoption of this draft. 
JohnS: We will take the adoption request to the list. 

6) BGP Route Refresh Options [Tony Przygienda] (5) 
https://tools.ietf.org/html/draft-idr-bgp-route-refresh-options-02  
(Note, out of sequence w.r.t. agenda)

(9:47)
TonyP presenting, 

(9:48)
Enke: This looks really cute but why do we need to use that many bits?
(With respect to wraparound handling.) 
TonyP: future proofing. 
Enke: Can you use 4 bytes? (And not handle wraparound.)
TonyP: We have been there before. We can agree on 4 bytes and then
someone starts generating many refreshes, that may wrap in a couple of
years. That said, there's an example and rules in the draft to show it's
fixed.

5) BGP Next-Hop Dependent Capabilities  [Bruno Decraene] (10)
 https://tools.ietf.org/html/draft-decraene-idr-next-hop-capability-03
(Note, out of sequence w.r.t. agenda)

(9:51)
Bruno presenting. Adoption of Draft requested. 
JohnS: Curious how many people have read the draft? Good. (quite a few
hands). 


7) BGP SR Updates [Acee Lindem] (7) 
https://tools.ietf.org/html/draft-ietf-idr-bgpls-segment-routing-epe-11  
https://tools.ietf.org/html/draft-ietf-idr-bgp-prefix-sid-04  
https://tools.ietf.org/html/draft-previdi-idr-segment-routing-te-policy-05  

(9:57)
Acee presenting. 

Sue: We will keep the WGLC open until we see the last document. 
Acee: And you may need to extend it to resolve the comments. 

Sue: On the draft sr-epe, have you completed all of your updates? 
Acee: Probably yes. I do not know whether Stefano has responded to all
the comments. 
Sue: I would like to close that one. 

Acee: It would be good to get the tunnel attribute draft being
progressed. 
JohnS: If you know of the implementation that would help. I would like
to progress it. 

Sue: If you have any implementations of that it would be good to update. 
JohnS: Any questions?

Note: adoption request for: draft-previdi-idr-segment-routing-te-policy. 

New Work [10:15-11:30] 

1) New definition of ISP Internal EBGP Border using BGP Roles [Alexander Azimov/Randy Bush] (10)
https://datatracker.ietf.org/doc/draft-ymbk-idr-isp-border/

(10:05)
Alexander presenting, 

John Scudder (wg participant): I haven't yet read the draft. You
mentioned partial deployment. How can this be deployed partially between
two border ASes? 
Alexander: Both parties need to switch to internal role in the
beginning. Change of configuration is needed only on the two edge
systems. 
John Scudder:  Imagine I have 10 different places where the ASes touch.
How would that work? Do I have to do that everywhere at the same time? 
Alexander: The traffic will go only via those peering links that already
support this extension. 
John Scudder: I intend to go home and read it, it is an interesting
idea. 
Sue: Please read it and look at the routing leak stuff too. If someone
has research time please look at CAIDA data and tools. 


2) BGP Logical Link Discovery Protocol (LLDP) Peer discovery [Acee Lindem] (10)
https://datatracker.ietf.org/doc/draft-acee-idr-lldp-peer-discovery/

(10:11)
Acee presenting. 

"Currently gauging interest". 
The question for the WG - is the complexity of this mechanism acceptable?

(10:19)
TonyP: A couple of points. Generally this is cool. It can have a wider
application. The interaction between LLDP and BGP configuration is
shaky, needs more thinking through. The information will expire - do you
need to tear the session then? It needs to be thought deeper. Do we do
away with keepalive? What's the interaction with the FSM? What I see
this as being capable of over time to do more sophisticated thing. It
could describe whether OPEN message is the old size or new size, it can
be a BGP transport description mechanism. It can be applied not only in
the DC, it can be used in many more use cases but that requires very
careful thinking as it will have a very long life. 
JeffH: The neighbor discovery hack is likely not a good idea. These
things are being done but it causes race conditions. I do like LLDP, and
I like the OSPF mechanism. Whether it is LLDP or OSPF, it is not
possible to tell "should I even peer with this thing?" Security
associations or tags or communities that tell what is the role of the
device would be needed. The type of node - whether it is a reflector, or
some other function can be described in the capabilities. What to do
with the incoming sessions, what to accept? It can be done via BGP
wildcarding, but there are security aspects. 
Acee: autoconfig vs security - I am aware of this problem. 
JH: You can use roles to validate the ..
(10:24)
Nikos Triantafillis: My personal dislike - I can have cases where LLDP
is not running and I would need to configure LLDP first. I would like to
see a Hello mechanism in BGP rather than relying on LLDP. I don't want
two mechanisms to do the same thing. For automation this is something
that I would not be able to use. 
Acee: It is someones else's responsibility to provide this presentation. 
Nikos: Peering relationship provisioning - this can be a useful tool for
that. 
Acee: You would do either hellos or LLDP. 
(10:25)
Robert Raszuk: The host is connected to the switch, and therefore I have
no LLDP session and therefore I cannot use it for discovery of BGP
sessions for the reflector to host session. 
Acee: Correct. You have to be on the same L2 network.
Enke: I also prefer a BGP based solution for hellos. If we model after
LDP, it has UDP discovery followed by TCP session. It seems to be more
generic. We could use UDP port 179. Second comment - BGP is very rich in
policies, to achieve minimum or zero config policies that are needed
would be not possible to achieve. What is the goal - is it for the
minimum configuration, or just the neighbor discovery? Do we want to
achieve zero configuration? The policy can get very large. 
Acee: Rather than the volume of the configuration - you still will need
configuration for policy anyway - but it allows for a less of difference
between full and discovered configuration. You can eliminate a lot of
configuration, it's not true ZERO configuration.
Enke: This will work well in a homogeneous environment. 
(10:29)
JeffT: LLDP requires that all TLVs need to be in the same 802 frame.
Might be good to reach to IEEE for an extension.
Acee: If we decide that this is the right thing to do we would rather
extend the BGP hello mechanism. 
JT: You are limited to the size of 802 frame. 
(10:30)
Sue: Please be careful with adding in something to the BGP state
machine. In the past things like this were used in the different manner,
I would be glad to help you on this. 
Acee: I think it should be advisory and not modify the FSM -- that would
be a layering violation.
(10:31)
Nikos: If you can abstract that with scripts it is already there. 
(10:32)
Wes: comment in jabber: 
"Keyur: Ideally if LLDP packets are lost you have a much bigger problem
with response to discovery.  Having said that we could augment the text
to make it a bit more robust.  LDP like discovery mechanism is much
heavier." 
"Keyur Patel: @tony - complete agree about this comments about tweaking
the transport."
"Keyur Patel: @Enke - LDP like discovery mechanism is a lot heavier. 
The biggest advantage of LLDP is that discovery is decoupled from the
protocol (namely BGP)

3) BGP Signaling of IPv6-Segment-Routing-Based VPN Networks [Gaurav Dawra] (12)
https://datatracker.ietf.org/doc/draft-dawra-idr-srv6-vpn/

(10:33)
Gaurav presenting, 

(10:36)
Jorge Rabadan: This should be discussed in the BESS WG, it's about VPNs.
I assume you plan to use the same TLV for EVPN route?
Gaurav: yes. 
Jorge: In IPVPN, EVPN we have 20 or 24 bit VPN identifiers. Why isn't
that enough? Have you thought of restricting the SIDs to 24 bits so we
can reuse the VPN IDs we already have?
Gaurav: The end function is a function of the end node, we are not
dictating how many bits to use. 
Jorge: If you do that you do not need a TLV. 
Gaurav: For brownfield deployments (ingress PE MPLS-VPN, egress PE SRv6)
you may have a mix.
Jorge: Even in a hybrid scenario if you use 24 bit SIDs, I don't see why
you need a TLV.
Gaurav: ... 
Jorge: You can use the existing MPLS label field. Example, in EVPN we
support non-MPLS tunnels and that is good enough, we do not need extra
additional information in BGP. 
Patrice: Suggest Jorge read the programming guide, it explains in detail.
Jorge: I did.
Patrice: OK, let's sync up after.
Wes: jabber: 
     Kamran Raza: MIC:Please take a look @ "srv6 net pgm" document. 
John Scudder: Before you ask for adoption please trim your author list
to just 5 authors.  
     

4) Compressed BGP Update Message [Tony Przygienda] (10) 
https://datatracker.ietf.org/doc/draft-przygienda-idr-compressed-updates/

(1040)
TonyP presenting. 

(10:55)
Randy: Thank you, I am totally convinced now that extended messages need
to apply to all types. 
Nikos: During past Cisco involvement we profiled BGP input and output.
It has no problem on input side. Update generation and replication may
cause some load. My concern is on the load that this proposal adds. You
can have different peers, some can compress and some no, therefore you
are breaking them in different update groups and thus making it more
expensive. 
TonyP: My implementation data may contradict your implementation data.
If you write your BGP in Python you probably do not want to do that.
Nikos: Coming back to the input is the constrained I/O. 
TonyP: The weakest point in the chain is how you can put it out. 
JGS: Lines cut. Keep the comment to the point. 
Tony: It is implementation aspect. 
Nikos: I do not believe that this is a problem BGP needs to solve.
Tony: We have contradicting data. Proof-by-anecdote can go on all day. 
Keyur: We have an IDR draft for extended messages. If the messages are
extended with bigger window size how would this solution stack up
considering convergence is paramount for BGP.
TonyP: When will all the deployments of extended messages be in place?
The world will be a better place when the speed of light is increased.
RobertR: IO bottleneck in the virtualized environment applies when you
have a very badly designed system. If you are telling that 10s of Gbps
is not enough for BGP something is very wrong. 
Tony: OK, another data point. 
Jakob: Convergence is affected by FIB download and policy execution and
very little with what you are talking about. I have asked someone to do
a clear bgp on a VPN sessions with millions of routes. Thet eventually
did and took a look at the input queue - that was zero. The RIB download
was the problem. 
TonyP: we have deployments where RIB download does not matter. 
Stephane Litkowski: Not taking a position on bad/good, just trying to
understand. What I see is I have some IO issue, you say we have plenty
of cores, but frequency of each core is decreasing each year while we
get more cores. Do we need a solution to balance over more cores? 
Tony: We don't have solution for multiple TCP sessions.
Stephane: Why not?
Tony: We've tried to spec it... 3 times?... over the last 20 years? We
can do it again. 
Gaurav: Curious whether you have done any analysis of this proof of
concept? 
TonyP: When I presented the data it is of pretty high confidence that it
is worth doing. 
JGS: Thank you. 


5) Populate to FIB Action for FlowSpec [Zhengiang Li] (10)
https://datatracker.ietf.org/doc/draft-li-idr-flowspec-populate-to-fib/ 

(11:03)
Jie Dong presenting on behalf of Zhengiang. 

(11:05)
RobertR: Flowspec does not prohibit to install wherever you like. You do
not need any other bit to indicate this. Put it in whatever database
your data model supports.
Jeff Haas: I agree with Robert. What makes this a little problematic is
ordering. Flowspec has implicit ordering, 5575bis has explicit ordering
too. The difference is FIB vs ACL. If you have ordering this may change
and complicate your implementation. 
Jie: For normal flowspec rules there is a requirement for ordering, but
here it is similar to normal routes in the RIB. 
JeffH: If you're controlling your inputs that strongly the need for a
bit is not really there. 
Ruediger Volk: The semantics of F bit means that I really do not care
whether the route is used. Is that my correct understanding? Are you
expecting that insertion of such rules has an exact subset of routers
that will act on it and the other subset wil ignore it? I have problem
seeing whether this is a good thing. You either know that all of your
devices can do it or you are driving your network into dangerous
non-deterministic mode of operation. 
Jie: Maybe a new capability? 

 
6) BGP Neighbor Autodiscovery  [Xiaohu Xu] (10)
https://tools.ietf.org/html/draft-xu-idr-neighbor-autodiscovery-01

(11:09)
Xiaohu presenting. 

(11:12)
JeffH: All my earlier LLDP comments apply, about roles and so on - these
are good ideas. Differences are scoping. This one is somewhere link and
subnet scoped. It can get flooded further via another multicast scope. 
Nikos: How are you using the AS number? Is that your own AS number? In
the TLV I would like to see more data on AS numbers with which I am
willing to peer. 
Xiaohu: It contains own AS number. 
Nikos: If you receive this, does it mean that I am willing to peer with
you? 
Xiaohu: That is a local peering policy decision.
Nikos: But anyone who sees your messages will keep trying to peer with
you, even if you keep refusing. 
Keyur:  I am not sure if the hello mechanism is needed inside bgp with
keepalives there are discovery protocols, lets leverage them and not
load BGP up. 
RobertR: We have exactly the same draft proposed in 2014. I like your
transport, UDP/179 is nice to have. My suggestion is to take a look at
that draft and reuse it. 
Enke: AS number is 4 bytes and we are done with that. Get rid of this
TLV. 
Rick Taylor: I like this in principle. How are we going to secure this -
I do not want to broadcast my AS number and whom I am willing to peer
with. Security in multicast is difficult. 
JeffT: That's why original draft is link-local.
Xiahu: We will consider security considerations.
JeffT: The intention of this presentation is to extend the transport. 
Enke: If you look at LDP - it uses TTL hack (GTSM). Put TTL 254 and
check on reception. There are multiple drafts for multiple protocols
that do that. 
JeffH: We have a lot of interest doing discovery. here and for IGPs. It
seems that all the authors should be kept in the loop to synchronize. 
Sue: Should we holds an interim for BGP? Quite a few hands. Action to
chairs.


7) Persistent Route Oscillation in BGP Constrained Route Distribution [Jakob Heitz] (10) 
https://tools.ietf.org/html/draft-idr-bgp-rt-oscillation-01

(11:19)
Jakob presenting. 

JGS: You show on slide 4? that the originator is R1? 
JeffH: 4684 does kinky things for rewrites. VPN route flooding goes
along that path. 
RobertR: When we wrote RTC RFC we never considered hierarchical RRs. Two
solutions - addpaths from top level to lower level. 
Jie Dong: You can also consider the cluster ID in this scenario. The
update could be discarded based on it. 
Jakob: In this scenario there is no actual cluster. 
Jie: There is another draft related to RTC problem in the hierarchical
and maybe we can consider a common solution? 
Jakob: I remember that and we talked many years ago. Thise are two
separate problems. 
Jie: That draft suggested some modifications to path selection rules. 
Jakob: those modifications do not conflict with each other. 
Enke: If you look at RR spec, it has a text on preferring shorter
cluster list. In case of hierarchical reflection you need to follow that
recommendation. 
Jakob: Does not help. 
JeffH: Normal BGP does not do it, 4684 breaks the rules here. Would have
been worth reviewing why 4684 breaks the rules the way it does.
JGS: It is always interesting when someone identifies a bug, and that
there are a couple of possible solutions. 
Jakob: This is a solution that we have implemented, we can talk about
other solution too. 

(11:29) 
JGS: meeting ended.