Re: [Rtg-dt-encap-considerations] [sfc] Encapsulation considerations

> On Mar 25, 2015, at 6:19 PM, Erik Nordmark <nordmark@acm.org> wrote:
> 
>> On 3/25/15 5:13 PM, Sharon wrote:
>> This is very nice work!
> 
> Credits goes to the whole DT (cc'ed). I also took the liberty to cc Alia in case there result is a call for additional design teams.

Thanks. Actually I guess there is.
A general problem space for overlays, which are applicable to strong trends - cloud & mobile compute, too many drafts, not enough thought.

>> I wonder if the same type of analysis should be done for the mapping requirements between overlay and underlay - before diving straight to protocol bits. Things like:
>> 
>> - underlay accessibility
>> - performance metrics
>> - protections & authentication
>> - Schema extendibility
>> - Pull/Push Publish-Subscribe
>> - consistency, locking, ownership
>> - NAT traversal ..
>> 
>> It would be a shame not to leverage the by definition existence of an underlay to base global mappings on a proper feature rich distributed database.
>> 
>> Proper requirements can weed out Irrelevant link-state protocols (there's already a network established, and overlay addresses have no topological meanings), it will also open off the shelf product options beyond very limited directories.
> 
> Sharon,
> 
> we tried to keep the charter for the DT quite focused.
> 
> I'm not sure I understand the aspects about the mapping between overlay and underlay - perhaps we can talk off-line?
> We did discuss the QoS/DSCP mapping, and ability to support OAM is part to be able to measure performance.

The heart of the problem is that there are two networks here. The overlay network does not terminate in the NVE, it continues elsewhere but it's addressing has no inherit topological meaning.
This means global knowledge, something IP tries to stay away from, and what makes IP scale so well. 

> 
> Do you think there are general aspects of the control plane (general across different encapsulations?) If there is it might be an argument for a separate narrowly focused design team; I suspect the set of expertize would be somewhat different than for the encapsulation format aspects that we discussed.
> I know that NVO3 needs to determine how to do a centralized control plane, but that is something that the NVO3 WG needs to handle.

Centralization is jumping to conclusion, it's only one way to achieve global knowledge. Logically centralized is more appropriate.
We all sense that there's a scalable database under the covers for this task that leverages the underlay (IP) network to function. We just haven't defined it's features and what are the requirements and rules of the NVEs to engage it.

So rather then throwing 3-4 letter words BGP ISIS LISP XMPP LDAP DNS ... Let's just define these first.
The protocol wrappers and the Schema for that "underlying" database will follow.

The good news is that distributed eg scalable databases are centric for multiple industries, so once NVE-NVA requirements are clear we can all fast forward to implementations.

The wrapper protocol is a strong suite of this forum, not the thing to warty about once the above is well defined. The usual Darwinism will work.

> 
> Thanks,
>   Erik
> 
> 
> 
>> 
>> --szb
>> 
>> On Mar 24, 2015, at 11:41 PM, Erik Nordmark <nordmark@acm.org> wrote:
>> 
>> 
>> I don't know to what extent folks are paying attention to RTGWG but I presented the report from the encapsulation design team this afternoon.
>> The draft is
>> http://datatracker.ietf.org/doc/draft-rtg-dt-encap/
>> and the slides are at
>> http://www.ietf.org/proceedings/92/slides/slides-92-rtgwg-8.pdf
>> 
>> There is probably things in there to consider for SFC, and things that can be reused to make it easier to move SFC forward.
>> 
>> Sorry for not sending things out to the WG earlier.
>>   Erik
>> 
>> _______________________________________________
>> sfc mailing list
>> sfc@ietf.org
>> https://www.ietf.org/mailman/listinfo/sfc
> 