Minutes IETF101: idr
minutes-101-idr-00

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.