IDR Meeting IETF 94 13:00-15:00 Monday 11/2/2015
1) Chair's slides [13:00-13:05]
Sue discussing the pink box and agenda.
Status of drafts
Focus of the curent work: YANG models, Flowspec,
Open issues: MIB.
2) draft-keyupate-idr-bgp-attribute-announcement.txt
presenter: Keyur Patel
time: 13:05-13:15
Defining the scope for announcement of optional attributes.
Current use cases of tunnel encapsulations, timestamp. Mechanism is extensible for further use cases.
Jeff Haas/Juniper: Discussion on mailing list indicated that this is potentially error prone.
Keyur: I am aware of one implementation that does that, and also aware that it is being fixed.
Rob Shakir: never underestimate the ability of the operator to keep old code.
Jeff Haas: attribute constraints should have different behaviour based on actual attribute types. Example of different types of communities. My recommendation is to analyze these use cases and try to find suitable mechanisms. Session resets are very risky if implementation does not understand the bits.
Keyur: if we want to be safe and not to reset the session because of bits and implementation issues, and if we think that more scopes are required we can look into other ways of doing this and how to define the scoping.
John Scudder: I encourage people to discuss this on the list. There are potential problems, and this needs to be clarified.
3) draft-wu-idr-bgp-segment-allocation-ext-00
https://datatracker.ietf.org/doc/draft-wu-idr-bgp-segment-allocation-ext/
presenter: Shunwan Zhuang
time: 13:15 - 13:25
Ahmed Bashandy/Cisco: Are you proposing to replace IGP with BGP-LS? What is new here?
Hhunwan: we think in the controller use case it is needed to allocate segment id for node and .... ?
Robin Zhang: This draft is not to replace the IGP, it is an enhancement. Traditional SR uses BGP-LS or IGP to collect the segment binding information from the controller. We propose uses cases that centralized allocation of segment IDs is needed, and collection of topology ? is needed for that to work? Two options proposed, one of them is to reuse BGP-LS. This is the reverse direction, from controller to the network elements.
Shunwan: we do not intend to replace the existing channel, we provide an new use case with yang central controller.
Acee Lindem: Was this draft added late, or is it presented from the consolidated list? There was an extention on the Gredler segment routing. What does this add that the draft-gredler-bgp-ls-extensions doesn't have?
Robert Raszuk: This is in a different direction.
John: this is for proisioning.
Shunwan: Controller cannot download to the network, therefore this proposal.
Flowspec Drafts:
4. Introduction to Flow Specification Discussion
presenter: Jeff Haas / Sue Hares / John Scudder
time: 13:25 - 13:35
Jeff: No questions please. :-)
5. draft-litkowski-idr-flowspec-interfaceset-01.txt
speaker: Stephane Litowski
Time: 13:35-13:40
https://datatracker.ietf.org/doc/draft-litkowski-idr-flowspec-interfaceset/
Jeff Haas presenting.
Robin Zhang/Huawei: I have concerns on the group identifier - is this just a number?
Jeff: Yes, this is just a number. The number space is very large, and the types of interfaces that need flowspec rules applied is rather small.
Wei?/Huawei: interface group id should be configured on each router beforehand. Flowspec rules should be disseminated dynamically, you cannot know beforehand on which interface the actual rule needs to be applied.
Jeff: this is a network design and planning question.
6. draft-liang-idr-bgp-flowspec-label-01.txt.
presenter: Jianjie You
time: 13:40-13:50
http://datatracker.ietf.org/doc/draft-liang-idr-bgp-flowspec-label/
no questions or comments.
7. draft-liang-idr-bgp-flowspec-time
presenter: Jianjie You
time: 13:50-14:00
http://datatracker.ietf.org/doc/draft-liang-idr-bgp-flowspec-time/
Shunwan presenting.
To address Jeff Haas' question - ?
Jeff Haas: timestamps have start and end and you can set time in future. With end time it is more of a timeout, it will eventually timeout and remove the element installed. Timestamp is not necessary useful for controller based use cases where both insertion and removan can be controlled centrally.
Jeff: Encoding granularity of milliseconds - that seems very finegrained in the context of BGP propagation.
Shunwan: In the SDN use case the controller can be in charge of this.
Keyur: How is this supposed to work in the inter0-AS scenario? What does a timestamp mean across AS boundaries.
Robin: There is still a lot of debates on use cases in the draft, I think this should be confined to controller based use cases. This is still in the early phase.
Jeff Haas: Flowspec is normally in the context of BGP, but there is work also in OSPF and IS-IS. If IGP flooding scenario is also one of the use cases, please explain it in the draft.
John Scudder: regarding the separate attribute, and possible future applications - it is alarming to me to try to apply this to general routing. This should be forever restricted to flowspec.
Shunwan: ....
Jakob: what happens when the advertiser goes down? We should remove the route. Why do you need timestamp at all? Advertise when you need and withdraw when you do not need it any more.
Jeff: there are uses of flowspec for distributing security policy rules across the network, and that requires holding the rules for undefined time.
?: you can define security policy with time ranges, but for DDoS that is not necessary helpful, it is more traffic based. Timer does not add much value there.
8. Draft Name: draft-hao-idr-flowspec-redirect-tunnel-00
Speaker: Lucy Yong
Duration: 14:05-14:15
http://datatracker.ietf.org/doc/draft-hao-idr-flowspec-redirect-tunnel/
Jeff Haas: This enables redirection for things that are not IP, VXLAN is one of them. This is applicable to the data center environment.
Gunter: If you attach attributes for flowspec routers, you assume that all the receiving PEs will be able to act on them. If scrubbing node is directly attached to one PE, how could other PEs use it? The use case would be different redirections for different PEs - IP for one, SR/any other tunneling for the other.
Lucy: that is possible to address.
Wim: some of tunneling protocols are point to point, while BGP flooding is multipoint. How does one map to the other?
Lucy: we specify tunnel type, not the actual technology?
Wim: then you need to specify on each PE what and where to redirect exactly. This is a question of redirection scope.
Robin: I will explain this in my presentation.
John Scudder: out of time, please tahe to the list.
9. Draft Name: draft-hao-idr-flowspec-nvo3-02
Speaker: Weiguo Hao
Duration: 14:00-14:05
http://datatracker.ietf.org/doc/draft-hao-idr-flowspec-nvo3/
No questions or comments.
10. Draft Name: draft-vandevelde-idr-flowspec-path-redirect
Speaker: Gunter Van De Velde
Time: 14:15-14:25
http://datatracker.ietf.org/doc/draft-vandevelde-idr-flowspec-path-redirect/
Robert Raszuk: a comment on VRF limiting the actions. The whole point was to limit the redirection to VRF and then do whatever is available in the context of that VRF.
Gunter: yes, that is possible, but not very common and simple.
Gunter complaining about wrong slides. :-) and missing animations. :-) And formatting too. :-)
Chris Morrow: Why do you need flowspec for this, why not use regular BGP?
Gunter: BGP is very good in signalling, I am not certain that it can be that general.
Wim: ...
Jeff Haas: We looked at using tunnel SAFI and communities telling where to redirect. The IP address happens to be a tunnel endpoint, and this is the mapping of addresses to tunnel endpoints. My concern with your proposal - indirection id is a magic number and relies on the table being populated, and that makes things a little less predictable - if it is not populated, what happens then?
John Scudder: out of time for further questions.
11. Draft Name: draft-li-idr-mpls-path-programming-02
Speaker: Zhenbin Li
Duration: 14:25-14:35
http://datatracker.ietf.org/doc/draft-li-idr-mpls-path-programming/
Sue Hares: Out of time, please move to next presentation. We do not have time for discussion.
12. Draft Name: draft-li-idr-flowspec-rpd-01
Speaker: Shunwan Zhuang
Duration: 14:35-14:45
http://datatracker.ietf.org/doc/draft-li-idr-flowspec-rpd/
No comments and questions.
13. JANOG Interoperability tests on Flow Specification
presenter: TBD
duration: 14:45-14:55
http://www.janog.gr.jp/en/index.php?JANOG36_Meeting%2FJANOG36_Program_Contents%2Fbgpflowspec
Shishio presenting.
Sue Hares: We would welcome you to write that implementation report.
Close 15:00
End of meeting.