Skip to main content

Minutes IETF101: idr
minutes-101-idr-01

Meeting Minutes Inter-Domain Routing (idr) WG
Date and time 2018-03-19 15:50
Title Minutes IETF101: idr
State Active
Other versions plain text
Last updated 2018-04-10

minutes-101-idr-01
IDR meeting at IETF 101

Monday,  15:50-17:20 pm,  3/19/2018
Room: Buckingham

John is chairing, Sue is not here due to health issues.
Jie is taking notes. Acee is on the Jabber room.

0) Agenda bashing and Chair's slides

New note well. Please read it.

John Scudder: MD5 "flag out" for LDP. MD5 is deprecated and considered
insecure. This makes the security section of drafts more difficult. MPLS chairs
bringing attention to their deprecating MD5 efforts.  Will be presented in
MPLS.  Suggests that people in IDR may care.

Alvaro Retana: MPLS group deprecating MD5, there will be presentation also in
SAAG.We got a lot of pushback from security guys. Security wants everything
protected. There are also other operational realities to deal with. RTG ADs are
trying to have better communication with security ADs. TCP-AO has been
specified for many years. It¡¯s the matter of implementation and deployment. We
agreed to document scenarios and use cases for security considerations in
routing. We could have some templates for the security section. We should at
least mention security considerations in documents.

John Scudder: Clarification. This draft will be discussed on Thursday MPLS
session, and we can talk to Deborah about the bigger effort.

Jeff Haas: Please see presentation I did in IEPG about this. (Mail will be sent
to idr mailing list.) http://www.iepg.org/2018-03-18-ietf101/haas-iepg-101.pdf

Code Point Allocations:
FCFS is great, early allocation is also great. But requesting a specific
out-of-sequence code point will take longer time. Please read RFC8126:
guidelines for writing IANA section, section 1.3 has the checklist. Please be
clear in your IANA request.

Early Allocations: bgp-ls-eag, IANA section needs update.
3 drafts in WGLC.
BGP-prefix-sid: one change needs discussion.
Post-WGLC documents: mostly wait for shepherds¡¯ work.

1) Methods for Detection and Mitigation of BGP Route Leaks

Kotikalapudi Sriram presenting.

New version focus on RLP solution for inter-AS, draft-bgp-open-policy provides
the solutions for intra-AS. Many sections moved to Appendix. Introduce the RLP
attribute.

Alex Azimov: Glad to see you link your draft to open policy draft. There is
another draft you haven¡¯t mentioned (eOTC). Disclosing of ISP AS relationships
may be a concern. Suggest to merge the drafts to create some joint solution.

Sriram: This draft have been here for 3 years, the disclosing of ISP AS
relationship has been discussed and captured in appendix. We welcome the
merging of the two drafts. The chairs can guide this.

John: At what point do we think this is ready for implementation?

Sriram: Per hop values.  Other draft only has single flag.  Basic idea is same.
 Need to figure out which to do.

John: Please authors of both try to get this deal with.  [Poll of who has read
or willing to implement].  Please let's just get this recnciled so we can
implement

Acee: We'll implement the solution that gives us traction. 3 ways to do it. 
Sriram's proposal is currently most well discussed.

Jared Mauch: Asking Acee about implementation that floods routes out all
sessions as well.  (RFC ? )

Acee: Path to backward compatibility, there'd be an easier way to do this.
"Default default."

2) BGP Link State Extensions for IPv6 Segment Routing(SRv6)

Gaurava Dawra presenting.

The new version merged with another draft from Huawei.
Introduce the TLVs, all function codes now in SRv6 Network Programming draft.

John: Please fix the authors list.

3) BGP Signaling of IPv6-Segment-Routing-based VPN Networks

Gaurava Dawra presenting.

Will fix the authors list.

Ali Sajassi: This draft is about BGP enabled VPN services, should be renamed
and presented in BESS.

John: Good point.

Ali:This draft introduces a new encapsulation, what is the motivation? What is
the benefit, why cannot be done with existing encapsulations (e.g. VxLAN). What
about IPv4?

Gaurav: The motivation is in SR architecture and the SRv6 NP draft.

Ali: Can you summarize it in 2 sentences?

Gaurav: Integrate vpn with TE services.

Ali: Still don¡¯t see the benefit compared to existing EVPNs over SRv6.  Why do
it?  Performance improvement? Need discussion.

Stephane Litkowski: Speaking as BESS chair, it needs to be presented in BESS
but no time slot available this time, need to be presented on next IETF
(Montreal).

Jorge Rabadan: This needs to be presented in BESS. Do you mandate the
advertisement of this VPN SID TLV?

Gaurav: Not mandated. Depends on whether the originator supports SRv6.

Jorge: I can re-use the existing label field.

Gaurav: No. Originating router can be srv6 or vpn router. If you want to use
srv6, then you need to attach it.

Jorge: So it¡¯s for all the EVPN routes except route-type 4? The SRv6 network
programming draft talks about encoding the ESI label in the existing extended
community, which I agree, but that is inconsistent with this draft.

Gaurav: We are actually using the argument field.

Jorge: If you make this the function and argument, and limit the length to 3
bytes each, you don¡¯t need new TLV, can actually make the existing EVPN
compatible with SRv6. In EVPN, we use BGP encapsulation attribute or
encapsulation ext. comm to signal from the egress PE the tunnel and the length
of VPN label identifier. Here defines another way to do this. Why not use the
existing approach?

Gaurav: Implicitly signaling the SRv6 (based on the local policy) tells whether
you want to use SRv6 or VxLAN¡­

Jorge: need info in the route to make this decision, right? You're saying we
don't need that. Need a way to signal ingress PE  Why not signal encaps
community/tunnel type?

John: You will be presenting this at future bess.  Out of time.

Ali: Jorge says why use existing feature?  It'll impact route packing.  Why not
use existing evpn?  Then could use 20/24 bit.

Gaurav: How is packing different? It's same attribute; packing should be same.

Ali: If same, that's fine. If decide to use the new encapsulation, why not use
the existing mechanism, convey the SID as part of the EVPN route? Etree, leaf
indication bit etc. are not covered yet.

Keyur: IDR is finalizing the tunnel encapsulation attribute draft, please
don¡¯t define a third mechanism.

4) BGP-LS Extension for Inter-AS Topology Retrieval Under Different Scenario
Aijun Wang presenting

Acee: I haven't read the draft.  You redistributing route originator, RFC7752
prefix has both node and prefix descriptors. The node descriptor can just be
the router-ID of the route originator, and I don¡¯t think you need the new
identifier.

Aijun: In current BGP-LS, there is no prefix originator.

Acee: It would be the node descriptor. It is used for the route originator, not
the BGP speaker.

Aijun: BGP-LS only reports the information it has in the local routing table.
Acee: It can also from the OSPF AS external LSAs. AS-external routes are
flooded throughout the entire routing domain.  BGP-LS can use the originator ID
of the AS external route.

Ketan: As Acee said you already have it in OSPF, and you have source router ID
in IS-IS for the same purpose. So I think (the new identifier) is not required.
But the inter-AS part is necessary.

Aijun: When the router run BGP-LS is not the originator, it does not report the
originator of the external prefix to controller, so we cannot build the
inter-AS topology automatically.

5) BGP Extended Community for Identifying the Target Node

Jie Dong presenting

Ali: Are you sending this extended community with the route target or in lieu
of the route target?

Jie: This extended community is independent from RT, they are for different
purpose.

Ali: How do you ensure the receivers with the target address will receive it?
In BGP how to ensure the routes will be pushed to the specific target PE? Jie:
Before reaching the target node, the BGP nodes will keep advertising the routes
in the network.

Jeff: Router-ID makes sense for intra-AS scenario, there is no guarantee that
the collection of all addresses may not be unique. It does not work for
inter-AS scenario, need some discussion. The current procedure describes the RR
case, does not cover the confederation case. The inter-AS case may further
complicate the procedure. Don¡¯t think the flowspec use case is a good fit, in
that case you may want to numerate the set of interfaces to receive the filter,
so you may consider to use the interface set draft, or maybe consider to use a
group ID to address a set of routers.

Stephane: How is it different from the use of RT for MVPN or EVPN procedures?
For example, currently use the IPv4 RTs in the explicit tracking for MVPN.

Ruediger: In current BGP you have a mechanism for this, you can use BGP policy
configuration to implement any kinds of filtering.

Jie: But you need to do the configuration on each node.

Ruediger: There is a trade-off. Whether rely on the vendors to implement it, or
you use your signaling system and code the policy to the router configurations
yourself.

6) BGP Link-State Extensions for BGP-only Fabric

Ketan presenting.

Keyur: I've not read this draft. There is no new TLVs defined. Is this a
informational document, or is it doing something which requires
interoperability or standardization?

Ketan: This is proposed standard track because it describes the procedures for
BGP only network, specify which descriptors are needed to ensure
interoperability.

Keyur: I may not choose to honor those procedures, just send everything in
BGP-LS and should still work.

Ketan: Links and nodes are described with right descriptors for two way.  If
they are done differently by implementation there's issues. The procedures are
in this version, new TLVs may be introduced in future.