I2RS interim 2/10/2016 
I2RS Interim 
Wednesday, February 10, 2016 
10:00 am  |  Eastern Standard Time (New York, GMT-05:00)  |  1 hr 20 mins 

Meeting number:         640 720 496 
Meeting password:        yang1plus1

1-877-668-4493 Call-in toll free number (US/Canada)
1-650-479-3208 Call-in toll number (US/Canada)

Minutes (TBD)
1/11/2016 minutes: (TBD)

I2RS Interim Agenda 

0) Agenda Bashing [10:00 - 10:05]
1) I2RS FB-RIB [10:05-10:30]

  Update [10:05 - 10:15] 
  Discussion: [10:15-10:25] 
  1)  Is use of policy draft reasonable? 
  2) Are we ready for WG Adoption? 
2) I2RS Service Model [10:25-10:45]
  1) Overview of Service Topology [10:25-10:35]
  2) Discussion Question: [10:35-10:45am ]
    1) Can we use the bottom's up 
    2) Is this draft a good place to start: 
[protocol dropped duet o service model]


Filter based RIB and FB- forwarding
Observation that FB-RIB and IDR flowspec work overlapped.

Linda: Compare BGP flowspec with I2RS. More for a distributed method - can come from any peers.  I2RS is more centralized.  Fewer security issues - the client/agent - sending the request.  Will I2RS be smaller scope?
Sue: Secured P2P channel that make the I2RS case easier than BGP.
Linda: In Flowspec, routes/filters are transitive.  This isn't the case in I2RS.
Sue: BGP flowspec security is different.  Existed before SIDR ROA work (RPKI).  Current model is "BGP web of trust". There are already deployments of BGP flowspec, they are in restricted environments.  In ultra-secure environments, you may want bgpsec as well.  But that makes distributing BGP far more challenging.  RFC 5575 doesn't specify when you time out the flowspecs.  Follows normal BGP procedure, therefore it's "peer ephemeral".
Sriganesh: Have you analyzed the different fields BGP flowspec vs. I2RS?
Sue: Yes, see later slides.  Also see draft-hares-idr-flowspec-combo.  This is mostly a discovery document to do the comparisons looking at flowspec from a overall policy manner and doing comparisons.
[back to slides]

Sriganesh: Need to highlight this exact difference - the common understanding of the roots of the overlapping functionality flowspec vs. I2RS.
Sue: I'll try to point out the difference of the groups.  I've factored them into a separate yang model to highlight this in the documents.
[back to slides]

[questions for discussion]
Linda: Config + i2rs + bgp. BGP is unique in that it propagates stuff.  The relationships of the other entities are different.  I2RS has other stuff.  
Sue: The matching fields are fairly good overlaps.  Is the fact that I2RS's behavior being ephemeral going to impact implementations that have static configuration state.  When we look at existing work, e.g. ACL's, we don't see good matching yet.  This is a matter of looking ahead; most nodes support something like such static config.  How does the I2RS-only behavior overlap?  We need to define the overlaps.
Jeff: The interactions of the various things such as fb-rib, flowspec, static routes, etc. in the various implementations may not be able to be standardized.  Perhaps we should just focus on the service level implementations.
Sue: I'm trying to show how this could be done in the models. Need feedback on it.
Don Fedyk: Consider even just config (static) and i2rs.  i2rs can be independent of config.  Consider config vs. flowspec policy, it may have similar relationships.
Sue: yang model for fb-rib are node-specific.
Don: Between i2rs and filter-based.  Trying to figure out case where they're interacting on the same element of topology.
Sue: Could be same node, e.g. Denial of Service.  Some of these relationships are pre-existing, doesn't matter if it's coming from yang vs. other mechanisms.
Jeff: Same issue snmp vs. static config.  And we may redistribute i2rs state into bgp.

Don: What is the domain of i2rs vs. bgp flowspec?
Sue: I believe the answer is yes.  BGP flowspec covers ipv4 and ipv6 across global table and per-VPN.  

questions from the service topology: 
 Edwin Cordeiro - why do you have the node count and the status flag? 
 Sue: Here's where I have a struggle for the following status things: 
     at topology level: the following are added for service information
     (service-id number - sequential number of topologies which 
       may be used to match top-down numbers.  For example,
        this can be used to match the L3SM vpc-id, cloud-id tuple
      node-count -this may be used to match the site count 
     composite-flag-status - is the actual set of services operating now 
      rather than provisioned. 
      Perhaps this is too confusing for now.  So I need feedback.

Sue: The same problem of mixing status is there at the:
If no one things these are beneficial, I will delete them in the next release. 
[after the talk]

Sue: Any more questions.  Next time will be I2RS protocol in 2 weeks 2/24/2016.