Minutes IETF104: idr
minutes-104-idr-00

Monday Session

Chair start.

Sue Hares: need 5575BIS completion to get RFC 5575 updated. Need implementation
references. Several Flow Spec drafts are waiting on it. Need feedback on how
long to hold this. Question: how long do we wait? how about April 15. Need
implementation information

Two early Allocations are extended recently. Need implementation so could send
them to IESG.

General Concerns about BGP message size, error handling of BGP-LS and many
small BGP-LS drafts for code points/encoding. Way forward: extended messages is
passing WG last call. An update of RFC7752 is on today's agenda to improve
error handling. Propose: one document to keep the encoding in both IGP and
BGP-LS. asking LSR to handle encoding in their document set

John: there are IDR drafts which simply say this is defined in IGP, need to
bring it to BGP-LS.

Sue: we are stuck on the partial implementation reports. need help. (On
bgp-bestpath-selection-criteria) 2 from Cisco, partial from Juniper. Is it
enough? if yes, we will go forward. It has been sitting for over 6 years.

John: About tunnel encaps draft, if we go back and do it again, maybe we would
have a separate framework draft, and separate drafts about different tunneling
technologies. The current document has everything in one place, the problem is
nobody has a full implementation. In this case the implementation requirement
should be the fundamental stuff and at least one tunnel type. Need feedback on
this.

Sue: we need feedback on these partial implementation reports, need to clear
the deck based on the implementation status.

1) BGP-LS Extension for Inter-AS topology Retrivel

Aijun presenting.Defined a new NLRI
[no questions]

2) BGP extension for SRv6 SIDs allocation

https://tools.ietf.org/html/draft-chen-idr-bgp-srv6-sid-allocation/
by Huaimo Chen

One is node ID, another is adjacent ID, both Using BGP-LS
Introduce 2 TLVs: one for Node ID, another for Locator.
For adjacent ID, use the same structure.

Ketan (Cisco): BGP-LS has been used for reporting information to the consumer.
this draft is major shift of using BGP-LS as provisioning tool. have some
concerns.

Sue: can you send your concerns to the mailing list?

Robin Li (Huawei): there are some scalablility issue of existing method for
SRv6. using central control to eliminate scability issue. BGP-LS or other BGP
extensions may help to solve the issues in deployment.

Acee: We do have these things in the SR-Yang model (mpls and SRV6) for
provisioning. I do not want to lock anyone into 1 method.

Ketan: SR SIDs and locators are more like provisioning or configuration stuff,
BGP SR policies are more dynamic control plane thing, thus think YANG models
and other provisioning mechanisms are sufficient.

Huiamo:  BGP already have SR extensions for SR routing policy additions. That
one also need to use resource. This is just another extension for provisioning.
Maybe not do it via BGP-LS, but some other extensions to BGP. The BGP option
allows more scalable provisioning.

John: (As individual contributor) Just because you can do anything, doesn't
mean you should.
       (As WG chair) We have a SPRING working group to do the segment routing
       architecture. Since most of the discussion involves SR architectural
       issue, and the architectural part is appropriate for SPRING. I recommend
       that you talk to the SPRING chairs for architectural advice. If they
       recommend it, you can present at SPRING to get feedback.

3) BGP Extensions for Routing Policy Distribution (RPD) [Huaimo Chen] (10)
 https://tools.ietf.org/html/draft-li-idr-flowspec-rpd/

Huaimo presenting.

Jeff Tansura: John's comments to the previous draft are applicable here. Where
is the feedback loop? How to convey the operational states with BGP?

Huaimo: maybe more work needs to be added for that.

John: Question for Jeff, how does that work with Flowspec?

Jeff T: Same way, using CLI... It's a serious question.

Christoph Loibl (Next Layer): Don't think FlowSpec is the right vehicle for
this. There are two options, but no similarity to Flowspec.

John: Didn't intend to suggest Flowspec is the right mechanism, just to say
this isn't the first time that BGP not return feedback loop.

Jie Dong: Also want to mention that we do not have feedback loop in many
existing BGP cases, such as BGP Flowspec and BGP SR policy. Some mechanism to
provide feedback needs to be considered.

Acee: With restconf/netconf you have immediate feedback. What is the advantage
compared to netconf/restconf?

Huaimo:  This is a good question.  We need rapid changes during rapid traffic
engineering.

Acee: Today there are products doing this via proprietary CLIs to push BGP
stuff to network.

Robin: We have seen the challenges of using the CLI for interoperbility issue
and netconf/restconf for performance issue. BGP has advantage in both
interoperbility and performance.

Sue: My understanding from Robin is the improvement is due to the p2mp (single
BGP speaker to lots of BGP peers receiving the results). Robin (Huawei):
Similar case as SR-policy distribution, there is already a solution.

Jakob Heitz (Cisco): Using BGP is due to the ability of BGP to cross domains.
Is this what required in this case?

Huaimo: We provide details on how to get this data across to other ASes.

4) Subsequent Address Family Indicator for SDWAN Ports [Linda Dunbar] (10)
 https://tools.ietf.org/html/draft-dunbar-idr-sdwan-port-safi/

 Linda presenting.
 (note taker was presenter - so notes were lost]

Ali Sajassi (Cisco): We have another draft in BESS. What kind of features you
are proposing that can't be addressed by BESS's SECURE-EVPN draft?

Linda: this draft is about WAN ports property registration, about dynamically
register WAN port properties to the SDWAN controller. The SECURE-EVPN is about
managing clients routes and various ways of mapping clients routs to IPsec.

Ali: The common denominator is we need to allow for multiple ports to be
flexible to set up different IPsec tunnels among them, and map traffic flows to
IPsec tunnels.

Sue: Due to time limit, suggest to continue the discussion on mailing list.

5) BGP Diagnostic Path Attribute [Jakob Heitz] (10)
 https://tools.ietf.org/html/draft-heitz-idr-diagnostic-attr/

Jakob presenting.

Jeff Tantsura: The draft lack of motivation, need to explain why would you do
it?

Jakob:  Because of bugs. Two implementation required this information, the
checksum would be helpful to solve the bugs. Time stamps can help to find the
keys in process, or routing loops.

Jeff Haas:  There was a time-stamp draft 3 years ago.  There was problems of
incremental deployment. We stop pursuing this due to the problems. Could you
give more information about the checksum?

Jakob: You need to turn this diagnoistic on only when you need it.  You need to
be mindful of the update packing.

Jeff H:  My question is what is the use case for the checksum?

Jakob: We have some bugs in implementation.

Jeff: So the case is that the BGP stack is tightly coupled with TCP stack.

Robin Li: Why the internal process timestamp information is propagated in
network? Another question is why not using BMP to collect the information?

Jakob: It may be useful to be propagated one hop. There are multiple tools:
stream telemetry, BMP or this draft.

Keyur: BGP problems related to Queueing buildups are transient. For this to be
useful, you need to provide justification of use cases.  And need to explain
how this is better than BMP.

Jeff: Part of the motivation is where do you do the time-stamping? What you are
able to see the information flow (router to router) via data. There is
motivation for something beyond BMP.

[WG adoption requested]

6) BGP-LS Extensions for Inter-AS TE using EPE based mechanisms [Srihari
Sangli] (10)
 https://tools.ietf.org/html/draft-hegde-idr-bgp-ls-epe-inter-as/

Srihari presenting.

Sue: Is this related to the B bit described in
draft-ietf-idr-bgpls-segment-routing-epe-17?  If so, how was this problem
discovered.

Alvaro:  I'm reviewing the bgp-ls-epe draft and I asked how B set-up backup
links. The authors told me it was configured in proprietary manner. Now, we see
a signalled manner.  It cannot be both unless there is more description.

Sue: If this is something discovered in implementation, may provide more
substance to that particular section. Maybe worth conversation with the authors
of the epe draft.

Ketan: Explain the B bit, how the node determines what would be used for backup
is implementation specific.B bit says this link is protected by FRR. We don't
have the mechanism to tell which one is serving as backup, niether do we have
it in IGP today.

.... back to slides.

Ketan: (About the second problem) Agree there is a gap to address

Alvaro: It would be good to have the "B" and "F" descibed in the Spring epe
draft. It is past RFC approval, but there is time to add this one small
clarification. Please talk to the Spring chairs.

[In the slides:  Authors request this as an IDR draft].

7) BGP Link State Extensions for SRv6 [Gaurav Dawra/Ketan Talaulikar] (10)
 https://tools.ietf.org/html/draft-dawra-idr-bgpls-srv6-ext/

Gaurav presenting.

Propose the SRv6 SID NLRI and Locator TLV.

Sue: what is the improvement you found from the original version to the
deployments?

Gauray: what we learned is syn with IGP, so can keep the implementation simple.
And to address the comments about size of the BGP-LS attribute, we created a
new NLRI.

Sue: what helps by creating a new NLRI?

Gaurav: lots of information needs to be carried.

Alvaro: speaking as an individual, are you defining new MSD type?

Gaurav: It is the same concept, we are using it for functions of SRv6.

Alvaro: You said that the values are not assigned,are you define the registry
and everything else here, or is that coming from the IGP draft? (the slide
shows they are defined in IGP draft)

Jeff Tantsura: The registry has been created for SR-MPLS draft.

Jie: You mentioned that you learned a great deal to align with the IGP SR
design.In ISIS SRv6, you have Locator as top TLV, and SIDs are carried as
sub-TLVs.

Ketan: The IGP we had less SIDs, but BGP-LS had more SIDS. If carries the SIDs
in node attributes, it grows the BGP-LS message size.

Jie: With this mechanism, individual BGP Update message may be generated for
each SRv6 SID, the number of BGP Updates will increase significantly. Gaurav:
You can pack multiple SIDs into one Update message.

Jie: Only if they have the same attributes.

Gaurav: Yes.

[WG adoption requested]

8) An Update to BGP-LS Specification (RFC7752bis) [Ketan Talaulikar] (30)
 https://tools.ietf.org/html/draft-ketant-idr-rfc7752bis/

John Scudder (chair): This presentation is a bit unusual in that we had a draft
uploaded only 6 hours ago. We decided to let this presentation go forward due
to the topic is interesting enough to the group. Since we have 2 sessions, we
can have more discussion on Thursday.

Ketan presenting.

Keyur: (About message exceed 4K) If you drop it and consider it as attribute
discard, the consumer may not have a clear picture of the topology, you may
want to signal that.

Ketan: One way is BGP extended message, but it will take time to deploy.
Another option is to limit the number of TLVs. To answer Keyur's question, when
we discard the attribute, the actual link-state NLRI is still propagated to the
consumer. The consumer sees a link state NLRI without BGP-LS attribute, it is a
hint that it is not a withdrawn, this may be used for debug.

Sue: question: do you get into a loop? Where consumer doesn't know

John: Need to follow up on the mailing list

(Back to the presentation)

Keyur: Suggest to move some changes into a different draft, not include them in
the base. Existing implementations only need to fix things in the base then
still conform to the RFC.

Ketan: Need to go through which part makes sense and how to do that.

Jeff Tantsura: Checked the diff, the external type 2 for OSPF is removed, is
there a reason?

Ketan: No intention to remove. Will check.

(?) Ciena: We do have implementation of BGP-LS, find two specification bugs in
OSPF, one is very simple, another one is more complicated. Will provide details
on that.

Thursday Session:

0) Agenda bashing (5)

We have 30 minutes at the end of the session for additional conversation about
BGP-LS update.

1) BGP YANG Model for Service Provider Networks [Mahesh Jethanandani] (10)
 https://tools.ietf.org/html/draft-ietf-idr-bgp-model/

Mahesh presenting.Go through the updates and the issues.

Acee: Routing YANG is getting ready for WGLC. Need wider review.
Issues: statistics will be addressed in another draft.

Jeff Haas: About issue#1, need clear BGP neighbor, clear routes can be
controversial. About statistics, the stuff covered in MIB maybe put the the
base module. About Notifications, what it means here for route updates?

Mahesh: What it refers to is anytime that is changed to the route of entry in
the model, that might result in a notification

Sue: You have a neighbor-state change if you go from a particular state to
another state.

Jeff H: Clearning statistics is contraversial. Clearing routes is also
controversial. For the controversial things, let's protect those via feature.

Jeff H: Notifications for neighbor state change that makes sense, Notification
for route updates can ve very noisy. This should only be able to be enabled by
configuring a filter.

John: Encourage to continue this discussion after the meeting.
Robert Raszuk: Clear BGP in many cases can be based on route refresh, is this
supported?

Keyur: Yes, route refresh is supported.

2) Updates to BGP Tunnel Encapsulation Attribute [Keyur Patel] (10)
 https://tools.ietf.org/html/draft-ietf-idr-tunnel-encaps/

Keyur presenting.

Linda: If a route can traverse through multiple ports, can it be associated
with multiple tunnel attributes? should multiple "Remote End-point" SubTLVs can
be attached to one UPDATE? the draft doesn't have clear description. The error
handling says only one Remote End-point, otherwise, ignore

Keyur: The error handling section specifies how multiple same TLVs should be
handled. Please send the question again and will answer it.

John: (With chair and document shepherd hat on) Another WG last call may be
needed due to the revisions. Make sure to get your comments before or as part
of WG last call.

Linda: the RFC5512 has BGP speaker's endpoint address is specified. This
Tunnel-encap removed it. Doesn't it mean that a third entity can send update on
behalf of a router?

Keyur: The text does not prohibit what you say, but If you see any issue with
that, please highlight on mailing list.

Linda: It enable additional functionalities, but also introduce more issues.
The draft hasn't addressed any of those issues.

Keyur: Plan is to publish a new version with all comments received so far,
people can review and provide comments if any.

John: We may need another WG LC to catch all this comments.

Sue: (Chair's hat off) There is a lot in this draft to implement, are you going
to segragate a common base?

Jeff: Everyone need to double check the changes from SHOULD to MUST.

(Keyur go through the changes.)

Robert Raszuk: Historically, IPsec was not included in this draft, but now
there are use cases for that. Can this draft be updated to add new types to
cover that?

Keyur: The start of this draft was to replace 5512, which didn't cover IPsec,
it was in a separate document. Extensions can be defined in other draft.

John: Suggest to finish the WGLC, if anything need to change about the base
should be covered, new tunnel type or extension can be in a follow-up draft.
Don't want this document open forever. It's designed as a modular and
extensible framework.

Keyur: As coauthor happy to include incremental changes if WG wants.

John: (About implementation of a big draft), it would be good to define
skeleton part first then the tunnel types in follow-on ones. Now we have 6
tunnel types in this draft. I guess almost no one will implement all of those
in the beginning. Suggest to check the implementation of basic functions and at
least one tunnel type.

Keyur: As coauthor, we will get feedback and edit the document accordingly, we
have no problem splitting the document, but if we do it, better to do it now
rather than later.

Acee: Support to complete this draft. If there is anything that nobody will
implement, just take it out now.

Linda: support having a skeleton document explaining really well of the
mechanism, such as how routes can be egressed to different WAN ports, how to
handle 3rd party sending update on behalf of another node, then have different
encapsulations listed in Appendix, except IPsec because there are much more
needed for IPsec.

Srihari Sangli(Juniper): Respond to John's question, we could wait one month or
a few weeks to make a call on whether split it.

Keyur: Will publish version 12 and solicit comments.

3) BGP Signaled IPsec Tunnel Configuration [Hu Jun] (15)
 https://tools.ietf.org/html/draft-hujun-idr-bgp-ipsec/

Jun presenting. Fine with either make it a separate draft or update the
previous one.

Linda: with I2NSF chair hat on, this mechanism was discussed in, was
controversial, Suggest to align with what Security Area discussion

Jun: Think the mechanisms are different.

Linda: Traffic selection in IPsec is not purely based on destination, can use
other parameters,the current mechanism may not provide all this. BGP route
update from a node say R1 can't tell R2 the Traffic selection policy. TS is
usually specified by the policy.

Jun: Not trying to be a SDN solution. This draft is just a extension to the BGP
tunnel encapsulation draft to cover IPsec tunnel case.

Robert Raszuk: it is useful to specify additional local prefixes, this is also
applicable to other types defined in tunnel encaps draft. May consider to add
that information to the base document.

Jeff: Think this is a useful work. Need to add operational considerations
section. Do you consider inter-domain use case?

Jun: Not yet.

Jeff: There are places this can also be useful. Related to the deployment of TE
path attributes. It is difficult because of coordinating IKE across internet.

Jun: Would add text to describe that.

John: Please see email to the list to continue the discussion.

Stephane: (As BESS chair) There are several draft in IDR and BESS about IPsec
with tunnel ensaps. Suggest to find one solution to cover all the cases. And
which WG is the owner of this work?

John: We should talk after the meeting.

Sue: (As indiviual) +1 for Stephane's comments. Question to presenter: Have you
read the secure EVPN draft in BESS? Suggest to review that draft for
multi-domain. Why are the remote address prefix and local address prefix
necessary?

Jun: With IPsec, user could specify both the source and destination subnets.

Sue: The reuse of color may have conflicts with other case.

Jun: THe color sub-TLV is put under the IPsec TLV, it is specific to IPsec.

Ali Sajassi: Mention the secure EVPN draft, there are overlaps. And there is
still mech of IPsec session, you were talking about the scale.

Jun: Not trying to address the scale of IPsec session, only to scale the
configuration.

Ali: RFC 5566 defines similar mechanism, the difference is that was based on
RFC5512.

Jun: Yes.

Ali: Are these prefix sent with the attribute VPN prefixes?

Jun: They are the endpoint of the IPsec tunnel.

Ali: SECURE-EVPN draft covers both the discovery ans setup IPSec session, and
also P2MP signaling instead of mesh of P2P session. In the first part there is
overlap with this draft.

Keyur: About moving the list of prefix part into the base document, could work
on that together. Need to cover how the routes across ASs willingly or
unwillingly to be included.

4) BGP BFD Strict-Mode [Mercia Zheng] (15)
 https://tools.ietf.org/html/draft-merciaz-idr-bgp-bfd-strict-mode/

Mercia presenting. Will revise the backward compatibility section based on
5492, and add a new section to specify the BGP session state transaction.

Juliusz: Could you give an example of the problem?

Mercia: This is a common problem to control protocol, this is mentioned in
section 4 of RFC 5882.

Robert: This strict-mode has been proposed for OSPF, etc. But here it talks
about link quality. BFD is not used to monitor link quality. There are
proposals to enhance BFD, but there is gap.

Mercia: The case like BFD dampening.
Alxander: Do not understand why need to negotiate the capability. Can be just
configured locally.

Mercia: To avoid potential dead-lock.

Acee: Many venders support strict mode. Signaling can help when you don't want
to use it.

Keyur: Like the document. Don't think need the capability. Suggest to take it
out to make it simple. Himenshu: The use case about RR client is not covered.
The connection between clients can be bad, but there is no BGP session.

John: This case is addressed by draft-ietf-idr-rs-bfd.

Jeff: This is a real problem. The issue is at what point in the BGP state
machine to insist BFF either started, up and stable. There are interop
problems, and this draft is a good place to standardize the behavior.

John: several people stated they don't need the capability

Jeff: Think the capability is needed for interoperation.

Reudiger: BFD was used to tear down BGP session when something bad happens.
Here it is to control the establishment of BGP session. There may be different
approach to solve the problem. May not be necessary to delay the BGP session,
but delay the advertisement of routes and the use of the received routes. Then
the deadlock can be avoided.

John: Suggest to continue the discussion on the list. Aocording to the progress
of agenda topics, we don't have time for discussion on BGP-LS update today.

5) Route Leak Prevention using Roles in Update and Open messages [Alexander
Azimov] (5)
 https://tools.ietf.org/html/draft-ietf-idr-bgp-open-policy/

Alexander presenting.Ask for WG LC, there are 3 opensource implementations.
No questions.

John: Will add it to list of WG LC.

6) BGP Flow Specification for SRv6 [Lei Li] (10)
 https://tools.ietf.org/html/draft-li-idr-flowspec-srv6-00/

Lily presenting. Define two types to match either the whole SRv6 SID or some
fields of the SID.

Robert: Do we need to consider match of the extension header type?

Lily: This draft focuses on the new types for match of SIDs. Extension header
may be covered in other drafts.

Robin Li: SRv6 SIDs can be used in the IPv6 destination, but meaning can be
different.

Rafal Jan Szareck (Juniper): Which field in the header to compare with that? Is
this against the SRH or the IP header?

Lily: It is for the destination address in SR header.

Meeting adjourn.