Minutes IETF110: rift
minutes-110-rift-00

Base Spec Update
----------------
no comments

Applicability Statement draft
-----------------------------

Jeff: please confirm with those who provided comments
      that they are satisfied.

Yang Model
----------

Jeff: Do we need an update based on -13 revision of base spec?
Tony: No, as -13 is only for editorial changes.
Jeff: Please get Yang doctor review
Jeffrey: Does this work with known RIFT implementations?
Sandy: Known RIFT implementors (Tony, Bruno, ZTE) have closely
       reviewed the model and provided comments
Tony:  Did closely review earlier revision and will review the latest again.
Jeff: Would be good to report implementation experience (if there is
      already a YANG implmentation)

K-V Registry
------------

Jeffrey: What is exactly the "key identifier"? For example, for SR,
         when we distribute (system-id/loopback, SRGB, SID) info,
		 is system-id/loopback part of the key identifier or the value?
Tony: I don't think we should introduce structure in the key identifier.
      From the registry you will get 1, 2, 3, ... as key identifiers,
	  and the system-id/loopback would be part of the value.

SR RIFT
-------

Tony: What you suggest should work fine in principle.
      Make sure you keep very precise account what is north vs. south
      bound in terms of values you want to distribute, because first
	  mechanism starts different (tie-breaking) and second it has all
	  the implications in terms of scalability.
Tony: The system-id vs. loopback address - that's kind of implementation
      specific. When you start using loopback address it is no longer
	  ZTP - you better start talking about how to automatically
	  derive loopback addresses from system-id.
Jeffrey: In a RIFT network if you don't have loopback addresses,
         how do you manage a node?
Tony: How do you SSH into an Ethernet Switch - you don't.
      If things works well enough, why bother.
	  Well if you need to, then you do need a loopback.
Jeff: There is a larger picture if you're planning to traffic engineering
      to explicit stuff probably you will want to be able to address a
	  node specifically.
	  But practically Tony to your comment about scalability, if you
	  look at non-RIFT network the process of provisioning is orthogonal
	  to the process of discovery so you would go through you orchestration
	  and provision SRGBs, SIDs, IP address and something else then you
	  would use a dynamic part of your network to actually do auto-discovery
	  - BGP-LS up - to the controller and report SRGB/SIDs and addresses.
	  Here you already know what they are so there's no process of auto
	  discovery - everything has been discovered before and you don't need
	  discovery so it address much higher scales.
Tony: Yes bigger discussion in the mailing list but arguably you could build
      the SR thing fully ZTP. If you have system-id you could derive all
	  these blocks and everything and just distribute them and you don't
	  need to configure everything. But this is too large for the mic now.
Jeff: I mean non-planar topology with single links absolutely there's nothing
      you just need to reach next node. In more complex topologies probably
	  something more would be needed. This is definitely something to be
	  addressed in the draft.

Auto-EVPN
---------

Sandy: Is this to be used between PE and CE? or is it to replace BGP
       control plane at all?
Tony: This is strictly aimed at EVPN. What we're seeing is people are
      deploying IP fabrics and very very often they are deploying EVPN on
	  top of that to get L2 and they're deploying to the leaf or slowly
	  to the servers because of the multi-homing issues.
	  So the fabric starts to look like one big Ethernet switch to them
	  with vlans in a sense. That's what we're addressing.
	  That's something being deployed a lot, and you know preconditions
	  have a significantly complex configuration and there are controller
	  solutions but there's something where you could buy just three or
	  four switches and literally stick them together like Ethernet
	  switches and you get EVPN with the same simplicity as deploying L2.
	  I mean it will scale to much bigger scale but at certain point
	  of time I think the manageability of such a thing will become iffy
	  but RIFT will support it at any scale so will EVPN so you know
	  sky's the limit really. It addresses a specific deployment use case
	  which however we see a lot really a lot.
Alvaro: If this progresses it would be good to keep BESS informed.
Tony: Yes. Got a presentation slot in bess. Right now it is to invoke
      interest and discussion, to see who is willing to jump in to help.
Jeff: Personaly I am very happy to see EVPN coming to RIFT I mean it leverages
      RIFT's unique capability and it's great stuff and auto discovery
	  capability is aboslutely unique and that's really great next step
	  development.