Agenda for IDR 7/20/2015 17:40 - 18:40 Prague Time Admin Trivia ============ Agenda Bashing and Status Q&A 3 minutes Due to the short IDR meetings. The status is online. http://trac.tools.ietf.org/wg/idr/trac/wiki/idr-draft-status The chairs will answer questions on status on Monday. Existing Work: [30 minutes ] ============== draft-ietf-idr-bgpls-segment-routing-epe. 3 minutes (Stefano Previdi) [17:40-17:45] Discussion: None draft-ietf-idr-te-lsp-distribution 7 minutes (Jie Dong) [17:45-17:52] Discussion: None draft-ietf-idr-bgp-optimal-route-reflection 5 minutes (Bruno Decraene) [17:55-18:00] Discussion: none ietf-rs-bfd [18:00-18:10] 5 minutes [Discussion: None ] draft-jdurand-auto-bfd-00 3 minutes [not attending] Update on proposed drafts [30 minutes] ======================== [18:20-18:50] draft-keyupate-idr-bgp-prefix-sid 5 minutes (Stefano Previdi)[18:10-18:15] Discussion: Stefano: We want to have WG adoption call? John: How many have read the draft? [~25 people] John: How many think this is ready for adoption [~20 draft] Sue: We will do a WG adoptioin call. draft-walton-bgp-hostname-capability-00 10 minutes (Daniel Walton) [18:15-18:25] Discussion: 1) Joe Sideck: I provided feedback that this is not the best idea. Daniel: Some people liked it. Joe: We did reverse DNS. Daniel: We cannot do reverse DNS. xxx: (problem with the draft ) Daniel: Please detail this on the mailer. Jared: You should not use link-local address for the BGP. Using this provides a non-discriminate address. You can make one mistake and you will get into difficulties with the. Setting up the reverse DNS is not hard. You can get help with it. A lot of these routes are linux basis may sent out email. Having the DNS can help you with the transmission of the log files. I do know have experience you have with networks. Daniel: We have many customers. They do not type out the link-local address. John: Is the router exposed to the Internet network. Most of these are in the DC. Jared: Is the Data Center connected to the INternet. Rudieger: Add a column for summary, and instead of what you are putting out - add another one. Put the router-id out. Your identifier should be very clear. Jeff: The IESG wants to have interoperable situations. You do not want to use DNS. Expanded into the ____. John: Any further comments or fun. draft-fang-idr-bgplu-for-hsdn 20 minutes [Luyuan Fang] [18:20-18:40] Lucy: Is this allocation for any type of package? Is there multicast? Luyuan: We are just using the pipeline? Friday: 7/25/2015 11:50-13:20 [90 minutes] Agenda Bashing and status [5 minutes ] IDR Drafts ------------- draft-ietf-idr-flowspec-l2vpn-01 Weiguo Hao] Discussion: none BGP LS Distribution drafts ============================== draft-hao-ls-trill-01 [Donald Eastlake] Discussion: John: A show of hands for those who read the draft? (5 hands) John: Who wants to approve the draft? (5 hands) John: Please request adoption on the draft on the list. Flow Specification Changes [50 minutes] ========================== draft-hao-idr-flowspec-nv03-00 (Weiguo Hao) Discussion: None draft-li-idr-flowspec-rpd [15 minutes] Rudieger Volk: You had a customer with two ASes. Which one did your customer AS? - Eric: ISP 100 is your customer? Acee Linden: The situation is the same a segment routing. You are talking about putting the information on the policy on flow specification? Could you just just control this with MED? Eric: (missed) John (WG member): Flow specification has been about effecting the forwarding plane you are proposing to effect it for the forwarding plane. You are arguing this is the only way to impact my forwarding plane. Why you discuss it, it is hard. Policy has is hard to do. I2RS has taken on the approach with the policy. I think you should take this to policy to the I2RS container which is based on this point. We've had a hard time to do even one. Eric: I2RS is doing the policy. Robin: We have done a policy work done in lot of IETF work. The policy work has been done in the IETF. The dynamic protocol will provide the policy is difficult to deploy at this point. We discuss with the customer on the policy work. Acee: I think you need to do is to document your assumptions. I think you want the policy control to get the route as well. You have to be co-resident with the routing so you can set policy. The policy is controller must handle the policy. Eric: I lost some of your words. Can we do this on the list? I will respond. Acee: You can only set these flow specifications for reachable information. Jeff: I shared John's opinion that this is the wrong place. I think that flow specification. I have concerns that BGP is being used to transmit between routers. I am concerned that if you distributed with the RR of BGP, then the BGP peers will distribute to peers that do not care. Please join I2RS to discuss this within I2RS. I believe the modelling work in yang. Robin: We also proposed other yang models in the rtc model. draft-liang-idr-bgp-flowspec-label [Jianjie You] Jeff Haas: I apologize that have not read your draft. These comments are based on your presentation. The draft-ietf-idr-flowspec-redirect-ip-02 has covered the redirecting of next hop. I think there is a link between this and your request to link flow-spec to RFC3107? Do you think this would satisfy the requirements you wish to specify? I will copy my response to the list. draft-wu-idr-flowspec-yang-cfg [Aseem Choudary] Discussion: Jeff: You did a nice job on separating this. I will be sending comments regarding this model to the list. For the operational state, you may not have the state you have. It may have difficulty mapping to it. Aseem: Many times we have to map things to the yang models. This yang model may have to come from all the vendors. Jeff: It is case for the vendors, packets will be counted in buckets that do not match your work. Aseem: We have firewall rules and (other)rules. Jeff: It is a nice model for flow specification. #1 - It distributes firewall rules via BGP. #2 - As we our model this is a good model for the adjRib In. This may be needed in other models. The firewall rules may be useful for other WGs. Sue: Let me take this in reverse order to make sure I understand your comments. We have not included in the BGP model the AdjRIB in. This model would be a good template for this addition. On the second point, I understand that other working groups (such as I2NSF) are adopting firewall filters, and we should let them know about this point. Aseem Choudary: The drafts for the distribution were used for firewall rules. Jeff: This may be useful. This is associated with IDR, but it can be used for both. IGP are doing flow specification within IGPs. While this may seem a little weird, it shows the flowspec is valuable to other drafts. Robin: According to my draft is the configure and operational state. Aseem: (missed) Robin: Did you modify this from your original draft. Assem: We did. draft-liang-idr-flowspec-orf-00 [Weiguo Hao] Discussion: None Label assignment [10 minutes] ====================== draft-zhang-idr-upstream-assigned-label-solution-00 [Sandy Zhang] [zzz]: Why not use router-id and have simple record? You need a simply deterministic manner? [Robin, Huawei]: You are using a tunnel from PE2 to PE3. [Sandy]: The tunnels from PE1-PE3 and PE2-PE3 are two different tunnels. [Robin]: These have two sets of label space, and these are different labels. [Sandy]: The tunnels (missed the comments) [John]: Eric Rosen made the same point. Did you reply to his email. [Sandy]: I answer this point. [George]: The multiple point mpls being worked on. [John]: This is work is best done in MPLS. [George]: I think that the BESS WG is already commented on it.