Skip to main content

Minutes IETF102: idr
minutes-102-idr-00

Meeting Minutes Inter-Domain Routing (idr) WG
Title Minutes IETF102: idr
State Active
Other versions plain text
Last updated 2018-07-31

minutes-102-idr-00
IDR meeting at IETF 102 (version 3)

Session I:  Thursday,  18:10-19:10,  7/19/2018

Room: Viger

0) Agenda bashing (5)
Keyur: Presentation #4 is not adopted according email list message, so why is
on the agenda? John: There is quite some discussion going around on
requirements and neighbor and liveliness dicussions. Many proposals emerged,
and chairs didn't expect that this particluar topic would be on the agenda
right now. Randy was asked to redeliver the talk from LSVR on requirements at
at IDR WG Keyur: If solutions that are not adopted, we should removed it from
speaking about on the agenda John: No, request noted, but it remains on the
agenda

Jeff Tantsura: The BGP model depends on the policy in the rtgwg model
(draft-ietf-rtgwg-policy-model-03), and it is not done. Sue Hares: How quickly
can you get it done. Jeff Tantsura: It is only 60% done. Sue Hares: Perhaps you
should put it on high priority to get it done.

1) Update on merger of RLP and eOTC drafts for route leaks solution
[Kotikalapudi Sriram] (8)
 https://tools.ietf.org/html/draft-ietf-idr-route-leak-detection-mitigation
 (solution)/
 https://tools.ietf.org/html/draft-sriram-idr-route-leak-solution-discussion-00
 (design discussion)
Sriram presents the draft to WG
Jacob H: Abouta year ago i put in a draft on another solution for this. So that
neighbor can check this type of aspects. Did you see that? Sriram: Maybe
Alexander can comment Sue: The chairs want a specific answer to Sriram
questions and we need to focus on that and be specific if you discuss around
something else Alexander: I would like to understand why we go from attribute
to community. Attribute is better, but will take years and years. We know the
limites of the communities, there  may be issues, so please comment Randy Bush:
Locally community communities are very strongly authenticated and integrity
verified John Scudder: So that was a joke, go ahead please. Job Snijders: It's
no difference for attributes like this. This doesn't need to propagate very
far, so in the limited radius there is already benefits. John Scudder:
<intercept to keep timing on track>

2) BGP Model for Service Provider Networks [Keyur Patel] (8)
 https://tools.ietf.org/html/draft-ietf-idr-bgp-model/
Keyur presents on YANG model updates
Acee Lindem: We talked about this offline. You are going to change it to
augment IETF routing protocol model instead of being at the top. Keyur:The
model compiles, we'll make the change suggested. Would like to take it to WG
LC. Dhanendra (Cisco): Do you plan to define BGP RIB structure in the base one?
Keyur: Yes. Dhanendra (Cisco): And need to add support for clear RPC. Keyur:
The clear should be taken on a separate track. Dhanendra (Cisco): The policy
extensions, if policy extensions are required, then it looks like extensions
for policy may need to be thought about also in the model Keyur: this model has
only base extensions, and would like to reference these features to the
extensions draft track Sue: What needs to change in the base model? Keyur: RIB
Himanhsu: What extension will be needed for the BGP EVPN and L2VPN? Keyur: The
AFI/SAFI support and the related BGP parameters. Himanhsu: Will it overlap with
the BESS EVPN L2VPN model? Keyur: It should not overlap with the BESS EVPN
L2VPN model

3) BGP Extra Extended Community [Jakob Heitz] (8)
https://tools.ietf.org/html/draft-heitz-idr-extra-extended-community/
Jakob Heitz Cisco presents the draft
Keyur: What if the WG thinks we need 30 byte communities 6 months later. Will
we define a new AFI/SAFI for another RTC? Jakob: Yes. Keyur: I suggest based on
that I suggest we stay with the wide community. Jeff Haas: We already did
refactoring. Let's do the transitivity.  Yeah!  Let's do that. I do not like
the 6 bytes.  It may work for your code, but it does not work for mine. If put
the field in the beginning we can have variable-size and do parsing based on
the type. Jakob: (comment regarding length of time to be deployed) --- John:
Both "unreasonable positions" have been noted - go on. Sue: +1. Jorge Rabadan:
I am confused about your slide. The new RT are to be used in addition, and not
as replacement. I assume that all your EVPN PEs need to support this community.
That needs migration. Jakob: There will be no conversion between old and new.
It could be done, but I would not do that Jorge: If you send both to all the
leafs, then there is no gain as you still have to configure the other RT. Job
Snijder: I want to comment on the transitivity aspect. Jeff Hass and keyur
created some drafts on this. Maybe using common headers/container. From a
marketing perspective saying that it is just like large communities, but then
bigger, but transitivity should be the considered. How we solve this as WG it
should be considered. Per attribute, per community or per color etc. may not be
ideal. We need to think how to push to market Jakob: We need to look into
scoping the solution.
 Chairs: <intercept in the sake to keep time on track>

4) BGP Neighbor Autodiscovery [Ketan Talaulikar] (8)
 https://tools.ietf.org/html/draft-xu-idr-neighbor-autodiscovery/
Ketan presents the draft
Chairs: we are 10 minutes in overtime, it would be appreciated if time can be
respected Chairs: Due to the current status of the draft, lets not dig into
further details at this time for the interest of time

5) Requirements for BGP Neighbor Autodiscovery (15)
LSVR Hello Neighbor Requirements [Randy Bush] (8)
  Discussion (7)
Randy Bush: Presents requirements summary
Sue: The only thing I mentioned in the LSVR was the ES-IS protocol.
John: Probes WG to understand if this a topic of interest to the WG: Mostly
HUMS say yes John: Probes if we understand the requirements for IDR: Mostly hum
that we don't know exactly the requirement

Jeff Haas: LSVR has the liveness requirement, we don't, that may bias the
solution. The solutions offered have significant overlap. I do not think we are
far from the actual requirements. Keyur: +1 to Jeff Haas. We should think about
this work to apply to IDR, LSVR, and to other points. John: The AD has asked us
to work with the LSVR to have a unified solution instead of 2 proposals. Rajiv:
Most of the MDSC are going to be IPv6.  We should leverage IPv6 neighbor
discovery or at least add it to analysis. Acee: The requirements have a lot
more then that as the capability of IPv6 neighbor discovery Rajiv:I would like
to ask if this list is expanded with IPv6 ND. John: Lets take the requirements
as they are Acee: Lets make clear that the liveness requirement is not BGP
liveness, but Ether liveliness Randy: I would like IDR to not take this up.
LSVR has a constrained problem. IDR can expand to known universe. Ali
Sajasi:With respect to the LLDP option, I would consider if Jumbo frame can be
considered. John: Let's take of time have this address with the people that
know more about LLDP Keyur: Jumbo frames is good to have, but not necessary. 
You do not want to go beyond one hop. John: Almost certain we will schedule an
interim to talk about this.

[Total 52 minutes]

Session II:  Friday,  11:50-13:20,  7/20/2018

Room: Place du Canada

0) Agenda bashing and Chair's slides (10)
Sue and John Go over the Chair slides
- Chairs ask for volunteers to be shepherds.
- Chairs ask to know about implementations

1) LOCAL_PREF Overloaded = Overwritten [Alexander Azimov] (5)
Alexander presents the slides
Ruediger Volk: I do not like the idea that the router is setting attributes
outside of the policy configuration. It is unlikely that there is any use-case
related that should need such a solution. I prefer locally controlled policies
as that is under operator control, with maybe vendor support for simple well
known standard policies to insert if needed Alex: DT is fully capable, and so
is NTT and so are the other 50k ISPs. In FRR (Open source router) and in there
the local policy is already overwritten. John Scudder (as contributor): If you
have a complicated set of criteria of policies, then you still have to come to
conclusion. What about BGP custom decision, a WG document that is potentially
applicable. I wonder if this is a problem that really needs to be solved, but
it has been there for 2 decades Alvaro: Echo what John said. The custom
decision draft addresses some of this. Alexander: The default policies that
overwrite route-maps give me uncomfortable feeling. Ruediger: the concept of
providing a library of standard policies would be a good thing. Alexander:
People may copy it without understanding what they are doing. Templates going
in the wild not really working. Jeff Haas: We are running into two things.
Number space is gigantic. Another location of consideration that is messy is
the tie breaking process, and the influence of extensions that have impact upon
these preference tie breaking concepts. It may be worthwhile to have a draft to
discuss these aspects

2) Updates to BGP Signaled SR Policies [Dhanendra Jain] (8)
 https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy/
Dhanendhra provides draft update
Andrew Stone (Nokia): No a comment on this draft, wider scope. Consider
advertise the range of Binding SID? Dhanendhra: we have plan to add deriving
the binding SID from SRLB. Jeff Tantsura: Would be interesting to describe how
the feedback mechanism works as the machinery is spread over different drafts
Sue(Chair): Please put in a security section before WG LC. Ehsan Rezaaifar
(Nokia): Signaling policy using BGP is OK, What about feedback mechanisms. If
controller is peering with a RR, then there is no way for a controller to know
if this is something that router can support this? Chair: this discussion go to
deep, let have the discussion after the WG meeting Ehsan Rezaaifar(Nokia); The
problem is router should advertise the capability using the same mechanisms
(AFI/SAFI). Ketan: Fact that router support the capability and is peering with
RR, whether that's sufficient indication of the capability. Keyur: I would like
to see sections added to describe the RR in forwarding path, vs. the RR off
forwarding path.

3) YANG data model for BGP Segment Routing Extensions [Dhanendra Jain] (8)
 https://tools.ietf.org/html/draft-dhjain-spring-bgp-sr-yang/
Dhanendra presenting draft
John:  let's keep the comments brief.
Sue Hares (contributer hat): Work with RTGWG on policy. Please look at Keyur
extension draft and harmonize/restructure the work. Is this based upon any
other traffic studies outside of SPRING use-cases? Dhanendra: Yes, ther eare SR
extensions in BGP. The approach is take the minto BGP and augmenting the
structure. I will look at the BGPextension model, especially the BRIB model.
Yes, it is in the context of SPRING and this related to it. Jeff Tantsura: We
are trying to align all policies in single document. Naming of the document is
policy , but is not doing BGP policy is unfortunate naming. Dhanendra: ack
Jeff: there are some comon types in routing and they should be used in this
document also

4) BGP-LS Extend for Inter-AS Topology Retrieval [Aijun Wang] (10)
 https://tools.ietf.org/html/draft-wang-idr-bgpls-inter-as-topology-ext/
Aijun presents draft
John (Chair): Adoption discussion on list
Ketan: It would be good to describe the new TLVs in the document
Jeff Tantsura: The address space used on the interconnection address space is
uncommon to be imported into the IGP. The adres space frm other operator does
not belong in your IGP address space.

5) Distribution of Traffic Engineering (TE) Policies and State using BGP-LS
[Ketan Talaulikar] (10)
 https://tools.ietf.org/html/draft-ietf-idr-te-lsp-distribution/
Ketan presenting draft
Jeff Tantsura: Anytime you signal something then you should be telling also how
it is retrieved as this is distribution of operationalstate

6) Flexible Algorithm Definition Advertisement with BGP Link-State [Ketan
Talaulikar] (5)
 https://tools.ietf.org/html/draft-ketant-idr-bgp-ls-flex-algo/
Ketan deliver presentation

  BGP Link-State Extensions for Seamless BFD [Ketan Talaulikar]
 https://tools.ietf.org/html/draft-li-idr-bgp-ls-sbfd-extensions/
Ketan deliver presentation
John (Chair):We have little time. WG adoption request noted and request will be
taken to the list

7) Applying BGP flowspec rules on a specific interface set [Jeff Haas] (5)
 https://tools.ietf.org/html/draft-ietf-idr-flowspec-interfaceset/
Jeff presents draft
No comments or questions

8) Segment Routing Policies for Path Segment and Bi-directional Path [Cheng Li]
(15)
 https://tools.ietf.org/html/draft-li-idr-sr-policy-path-segment-distribution/

  SR Policies for Path Segment and Bi-directional Path in BGP-LS [Cheng Li]
 https://tools.ietf.org/html/draft-li-idr-bgp-ls-sr-policy-path-segment/
Cheng Li presents drafts
No comments and questions

9) BGP-LS Extensions for Advertising Path MTU [Fenghua Zhao/Zhibo Hu] (10)
 https://tools.ietf.org/html/draft-zhu-idr-bgp-ls-path-mtu/
Fenghua presents draft
Jeff Tansura : There are multiple MTU's in play. Which one do you want to
advertise? Fenghua: Let me come back Victor: Is there operator input that this
likely a problem or something that will happen in real live? Fenghua: I will
get back through email list

[Total 86 minutes]