Looks good! A couple of minor points below. On 11/30/2016 8:39 AM, Donald Sharp wrote:

During the meeting we discussed option #6 as the viable option.

Reasoning: Closely modeled the ietf way of thinking

Here it is in a broad outline:

vrf <VRFNAME1>

ip route … <---- Vrf specific Route So what happens for an RD override here? network with RD as listed below?

router bgp XXX

! (address-family ipv4)

network 1.2.3.0/24 route-map foo

neighbor ... ! CE session

redistribute ospf ! CE setup for OSPF

! no special parameters on redistribute needed; VRF name is already OK

<here> - never RD/RT

router ospf <INSTANCENUM> ! (is this under vrf config?)

redistribute bgp

...

router bgp AAA ! core instance

address-family vpnv4 | vpnv6 | evpn

Network <vpnv4> or <RT2/RT5> config [ rd <> ( could be used) ?]

neighbor ... ! PE session

vrf <VRFNAME1>

rt {import|export|both} RTLIST

rd {automatic|VALUE}

network <> [<rd>] ! <- most used hopefully

router bgp BBB ! core instance

vrf <VRFNAME2>

rt {import|export|both} RTLIST ! can have value overlap

rd {automatic|VALUE}

address-family vpnv4 | evpn

Network <vpnv4> or <RT2/RT5> config

neighbor ... ! PE session

Questions asked:

For VRF's would we extend this to MAC VRF's also? IMO yes (plus some additional EVPN info under the core instance and perhaps a new 'bridge|mac' statement at the same level as router ). Lou

donald

_______________________________________________ cmaster-next mailing list cmaster-next@lists.nox.tf https://lists.nox.tf/listinfo/cmaster-next