IDR minutes, IETF 105 July 24 2019.
Session I: Wednesday, 13:30-15:30, 7/24/2019
Room: Duluth
Sue is chairing the IPsec discussion.
1. IPsec related work (75 min)
1) Agenda bashing and Introduction to BGP IPsec work (15 min)
Sue is presenting.
Multiple overlapping proposals on IPSec related work in BESS, IDR and I2NSF. Need input from security people, thanks.
Acee: are the meeting material uploaded?
Chair: the material are in Friday session.
2) BGP Signaled IPsec Tunnel Configuration [Hu Jun remote] (15 min)
https://tools.ietf.org/html/draft-hujun-idr-bgp-ipsec/
Jun is presenting remotely.
Using BGP to propogate IPsec attributes within the domain among BGP peers.
No questions or comments.
3) Subsequent Address Family Indicator for SDWAN Ports [Linda Dunbar] (15 min)
https://tools.ietf.org/html/draft-dunbar-idr-sdwan-port-safi/
Keyur Patel: What is the need of signaling for WAN ports?
Linda: You may want to send traffic over different ports.
Keyur: This will increase the chatter in BGP.
Linda: This is for the zero touch provisioning required by SDWAN.
Keyur: Will continue the discussion on the list.
4) Secure EVPN [Ali Sajassi] (15 min)
https://tools.ietf.org/html/draft-sajassi-bess-secure-evpn/
Paul Wonters from IPsec: Page 7: IKE should only send 4 messages not 6 messages
David Carrel: 10K peers will need 400M messages
Keyur: With RR it is possible the forwarding plane is preserved when control plane goes down. Will the IDs and key parameters be preserved and for how long? The second is edge nodes could leak information out. Should address those potential leak. Draft should discuss what happens when routes leaks from the edges.
5) General Discussion (15 min)
Ben [SEC director]: the message from controller to each node needs to include NONCE and the public key from all 10000 nodes, the message size can be huge.
Ali Sajassi: you can do a lot of aggregation, to reduce the message size.
John Scudder: Could explain using N square for BGP full-mesh.
Stephie [Orange]: controller can have many tasks, just want to make sure you don't break the RR functionality. What happens when the control plane fails.
Ali: when the control plane fails, the rekey can be delayed.
Paul Wouters: Do we have many more routes than nodes?
Paul Wonters: Depends on the number of routes and node, may have many routes but only a few nodes.
Ali: Some details about that are described in the draft.
Paul Wouters: is IPsec mandetary, optional£¿
Ali: depending on the policies: some needs IPsec, some don't. Linda's scenarios have some WAN ports need encryption.
Paul: next is MTU. as long as you add IPsec, packet size increases. MTU needs to be addressed.
Paul: RTT: Need to consider the Child IPsec.
Sue: it might be helpful to have scenarios
Paul: multicast negotiation. IPsecME is working on the multicast. It will be helpful to bring some input to IPsecme.
Paul: If you have IPsec tunnel, and one of the end point fails. Is it IPsec protocol, or controller takes the node off.
Ali: Controller will take out the node and notify
Paul: I'm talking about a IPsec failure. IPsec keepalve is really slow. shouldn't depend on it.
Jun: My draft does not change the IPsec procedure.
Valery Smyslov: the comparison on page 7 of Ali's slides is not complete. every node has a singel value, if compromised, other 9 thousands can be compromised.
David: shared DH among all nodes has this limitation.
Ben: need to consider how much you trust the information from Controller (for Controller managed IKE). Need to address why use IPsec. Just need to think about it.
David: there is need for certification between edge and controller
Keyur: there is head of line blocking issue. Make sure those messages don't impact actual routes distribution. Need to address when control channel is broken, what would you do.
Enke Chen: Question about the number.
Stephane: we all say Tunnel-encap, but IPsec tunnel can carry everything. Should we consider something more general Today use RFC 5566.
Ali: The current thinking: the TLV carried by Tunnel-encap can specify what kind of IPsec is supported.
Sue: Need to close the line for this discussion.
Stephane: SDWAN tunnel type is not in the Tunnel-encap
Linda: in the detailed encoding, a new type needs to be added to identify Long Reach Overlay path, which is different from other encapsulation
Jeff T: Is EBGP supported£¿ May consider route servers.
2. Other topics (30 min)
Alvaro talks about IDR re-chartering.
Alvero: There are many items on the IDR that have been completed, doesn¡¯t reflect what we are doing now. There has been discussion on the list. We want to produce a general charter, the collaboration with other WGs. The discussion will happen on Friday.
1) BGP BFD Strict-Mode [Mercia Zheng] (10 min)
https://tools.ietf.org/html/draft-merciaz-idr-bgp-bfd-strict-mode/
BGP FSM is updated for BFD strict mode.
Due to time limit discussion will go to the list.
2) Route Leak Prevention using Roles in Update and Open messages [Alexander Azimov] (10 min)
https://tools.ietf.org/html/draft-ietf-idr-bgp-open-policy/
[5 minutes for switching]
Session II: Friday, 10:00-12:00, 7/26/2019
Room: Viger
0) Agenda bashing (5 min)
Will do the charter discussion in the end.
1) An Update to BGP-LS Specification (RFC7752bis) [Ketan Talaulikar] (15 min)
https://tools.ietf.org/html/draft-ketant-idr-rfc7752bis/
Ketan presenting.
recap from Prague...
BIS draft out before Prague, includes lessons learned/etc.
changes noted in the appendix, will obsolete 7752
IPR from 7752 now applied to the -BIS as disclosed by Adrian.
Issues with TLV ordering in BGP-LS attribute, need feedback on a new proposal.
Issues with handling unreachable IGP Nodes: certain configurations MAY cause incomplete topology views, because propagation follows best-path selection.
Proposed solution shown in slides, alternate proposal also in slides (add-paths required).
Acee: Don¡¯t understand this. The node originating this in BGP will do the computation internally. Ospf/IS-IS knows what's reachable. This doesn¡¯t have to be in the draft.
Ketan: That is the proposal in solution A.
Acee: Don't know why we need other mechanism.
John Scudder: Clarification question, in both solutions the consumer may get multiple copies of the same NLRI, isn¡¯t it?
Ketan: Yes, if the consumer is at the locator of R0. It is an implementation aspect.
David Lamparter: When you mean add-path, you also mean you need everything in add-path.
Aijun Wang: Solution A is more preferable. BGP-LS should provide the real status of the underlying topology, which more useful than the complete LSDB.
Jie Dong: This is about who would be responsible for the information validation, both has pros and cons, need to consider the impact to both device and controller side.
John: One more thing that may be relevant as con on Solution-A, it removes info if only get the feed from one side of the topology, while Solution-B remains this info. Solution B can let the consumer know that there used to be a link which is now not reachable. May tailor this to some particular use cases. Thus kind of prefer solution B.
Ketan: Yes it depends on which consumer application.
Srihari: BGP-LS is just a topology propagator. Solution B is more generic.
Andrew Stone: Consumer are expecting BGP-LS to provide connectivity information, not LSDB. BGP-LS missing sequence number today. The costs may not meet the needs.
Jeff T: Solution B add additional complexity, don't see a justification. Should keep it simple.
Acee: Less is more. The stale information does not time out for a long time.
Jie: One more comment, in -bis document, the description about link local/remote ID in link descriptors maybe is inconsistent with BGP-LS EPE draft, will share the details on mail list.
Ketan: Could you share the details on the list?
Jie: Sure.
2) BGP SR Path Segment [Cheng Li] (15 min)
https://tools.ietf.org/html/draft-li-idr-bgp-ls-sr-policy-path-segment/
https://tools.ietf.org/html/draft-li-idr-sr-policy-path-segment/
Cheng Li presenting.
Spring has one document here, IPv6 has another one.
The collection/distribution of these requires some BGP/BGP-LS extensions.
(notes about renaming for shorter names - tooling problems)
<ChangeLog coverage> - please review draft for details.
- New authors
- Comments covered
- IANA Allocations added
- Path segment tlv additions as well.
Updates to next document - Looking for Adoption + accepting more comments
John: Please send the adoption call request to mail list.
3) BGP Path MTU [Yongqing Zhu] (15 min)
https://tools.ietf.org/html/draft-zhu-idr-bgp-ls-path-mtu/
https://tools.ietf.org/html/draft-li-idr-sr-policy-path-mtu/
Yongqing Zhu presenting.
Path MTU can be signaled in MPLS.
SR does not include this, however.
for v6 there is no such fragment capability, so packets will be dropped.
Jeff: Who is the consumer of this information? For what purpose?
Cheng: The controller and the ingress node.
Jeff: We already distribute the MSD information for PCE to consider in path computation. Need to consider how this interact with MSD. Compute number of SIDs vs number of bytes. The information may be redundant.
Jie: They represent different capabilities along the path. Both MSD and Link MTU need to be considered when computing and encapsulating the packet on ingress.
Jeff Tantsura: It is OK if the complexity of interaction could be addressed.
Jeff Hass: There is a problem for RSVP as well. For the LAGs, the MTU provisioning on some components may be wrong, can your mechanism help to show that? Will discuss on the list
4) BGP based VPN Services over SRv6+ enabled IPv6 networks [Srihari Sangli] (10 min)
https://tools.ietf.org/html/draft-ssangli-idr-bgp-vpn-srv6-plus/
Srihari presenting. Presenting also from BESS - BGP VPN on SRv6-Plus
John: First need to see what SPRING wants to do with SRv6+.
5) SR Path Ingress Protection [Huaimo Chen] (10 min)
https://tools.ietf.org/html/draft-chen-idr-sr-ingress-protection/
Huaimo presenting.
Critical/Real-time traffic may be passed over SR
Fast Protection is needed.
E2E path protection exists in other places, but not in SR Path.
Tunnel/Path protection exists, but not for Ingress Protection¡£
Information required for backup Ingress:
info about primary/backup ingress nodes
service labels
Traffic description(s)
Discussion of SR Policy Encodings
Necessary new sub-tlvs - and discussion of this.
No comments or discussion.
6) Inter-Domain Traffic Steering with BGP Labeled Colored Unicast (BGP-LCU) [Jeff Haas] (10min)
https://tools.ietf.org/html/draft-szarecki-idr-bgp-lcu-traffic-steering/
Jeff Haas presenting on behalf of authors. Trivial mechanism for passing along colored labeled routes using BGP
Adrian: Do the different domains need to agree on the colors?
Jeff Haas: will cover this shortly.
Jie: Network slicing is mentioned in the slides, is it relevant?
Jeff H: It is simply labeled color unicast inter-domain LSPs to meet specific requirement. Use-cases are high in this draft, probably will get trimmed.
Adrian: Maybe you are not sure about how hard the problem is. It is not just a name space, it is about policy.
Jeff: Need to talk about this in WG. The signaling is hop-by-hop, the colors can be mapped and reset on ASBRs.
Adrian: Note that colors mean different things here at multi carrier entries.
Jeff: Yes.
Ben Maddison: It is a fairy tale with mapping agreement. It will becomes a name space size problem. Why not create 'large colors' and add ASN into the color? This smells a bunch like standard communities.
Jeff: Yes, the size can be very large, maybe you need more than single AS? maybe this really means route-distinguisher instead? Something with global allocation mapping.
Ben: Pair-wise seems saner to me. Name-space per peer seems more sane? Per AS Adjacency? You may need a name space per AS topology graph.
Jeff: Route Distinguisher still seems to fit though? :)
T H?: Making the boundary mapping workable would be good.
Adam Simpson: People are using SR policy for slicing, and the binding SID can be used at the boundaries. The problem with inter-domain is mapping.
Jeff Haas: This still is a standard mapping problem. Making more than one address vs label stacks. But label is not a key. You need one additional thing, color is common and makes SR people and TE people happy. The next step is to bring the next version with things we had discussed.
7) BGP Request for Advertising Candidate Path of SR-TE Policies [Lei Li] (10 min)
https://tools.ietf.org/html/draft-li-ldr-bgp-request-cp-sr-te-policy/
Lei Li presenting.
Aijun Wang: Think the scenario can be covered by PCEP. Why extend BGP for this?
Lei: SR policy can be provisioned by BGP. For small box it is easier for operator to use single protocol for request and distribution.
Stephane: Please use PCEP. BGP is not for request.
Lei: Why we define the mechanism of using BGP for SR policy provisioning in the beginning?
Andrew: Why not use GRPC for this? Why not use any protocol other than BGP?
Lei: We just follow the architecture of SR policy, and this extension would be straightforward.
Robin Li: In some scenarios we have to use BGP instead of PCEP, like in Data Centers.
8) Charter discussion (20 min)
John: Hum for whether we need WG status update regularly?
There is many.
Jeff Haas: The status is helpful. single questions/thread against a single message
is harder to deal with?
John: You want to make a new thread per problem?
Jeff: Yes.
Stephane (as BESS co-chair): Why do you add more text about the relationship with other WGs in the charter. IDR is to define the basic architecture and guidelines. With the guidelines, we may not need so many reviews, and that may slow down some simple work
John: Heck yes! (if the charter seems overly heavyweight, please let us know)
Sue/John: Our intention was lightweight unless someone's trying to drastically change BGP. If we got this wrong, speak up!
Stephane: For each code point allocation, do we need review from IDR?
John: For example, new path attribute may need review from IDR. For a well-known extended community, just send a mail to IDR.
Stephane: Just need to define the boundary.
John: Not intend to be hard scoped.
Sue: When define the tunnel encapsulation attribute, there's a lot of play back and forth.
Alvaro: There are many WGs working on BGP. Don't want to slow down the work. What we need is just the information.
Sue: Show the issue list.
Alvaro: Make general charter, make the charter great again, with less yearly change required. Which issues (from above list) are important? Which should be deprioritzed? Put important work into milestones.
John: Could have a real discussion on the mail list after this week
Acee: Over last month/etc significant uptick on addressing what needs to be addressed. Good job!
John talks about fast registry handling.
Earlly allocaton policy, the fourth criteria, judge from WG chairs and AD on the interest for early implementation.
Suggest not to do additional 2-week poll on early allocation in future.
Sue: will be tracking all the early allocation request. Please send a mail.
John: Adrian wrote a short draft on BGP-LS registry.
Rudiger Volk: Wondering how much impact of 2-week early allocation poll on the waste?
Sue: Give an example.
Rudiger Volk: There may be case that missed the opportunity of objection in WG adoption.
Ketan: For BGP-LS, don't like the fall back from specification required to expert review. RFC 8126 - IANA is planning an update here as well. The ref that specs the registry requirements can require most anything?
Alvaro: IANA is working on an update to RFC. Expert review
Adrian: There is a direction to the expert. An internet draft is not stable.
Loa: In some cases WG chair can tell there is WG consensus, while in some case you may need to evaluate the consensus via WG. The way you use to judge consensus can be flexible and chairs can decide.
Meeting ajorn.
[5 minutes for switching]