Re: [bess] a question about bundled service in draft-ietf-bess-evpn-overlay-08

2017-07-20 Thread Anoop Ghanwani 
Thanks Ali.


On Wed, Jul 19, 2017 at 5:17 PM, Ali Sajassi (sajassi) 
wrote:

>
> Hi Anoop,
>
> The provided text is fine. Given that it is just a minor clarification
> text, I think it should be OK to incorporate it; however, I need to check
> with the chairs and the AD given that this draft has already gone through
> the WG LC.
>
> Cheers,
> Ali
>
> From:  on behalf of Anoop Ghanwani <
> an...@alumni.duke.edu>
> Date: Wednesday, July 19, 2017 at 9:11 AM
> To: Cisco Employee 
> Cc: "bess@ietf.org" , "n...@ietf.org" 
> Subject: Re: [bess] a question about bundled service in
> draft-ietf-bess-evpn-overlay-08
>
> Thanks Ali.
>
> May be worth modifying the sentence below to say:
> >>>
>
> 8) When a 802.1Q interface is used between a CE and a PE, each of the
>VLAN ID (VID) on that interface can be mapped onto a bridge table
>(for upto 4094 such bridge tables). More than one bridge table may be
>mapped onto a single MAC-VRF (in case of VLAN-aware bundle service).
>
> >>>
>
> Anoop
>
> On Wed, Jul 19, 2017 at 12:14 AM, Ali Sajassi (sajassi)  > wrote:
>
>>
>> From: BESS  on behalf of Anoop Ghanwani <
>> an...@alumni.duke.edu>
>> Date: Tuesday, July 18, 2017 at 10:39 PM
>> To: "bess@ietf.org" 
>> Subject: [bess] a question about bundled service in
>> draft-ietf-bess-evpn-overlay-08
>>
>>
>> This is what the draft says about bundled service:
>> https://tools.ietf.org/html/draft-ietf-bess-evpn-overlay-08#section-4
>> >>>
>>
>> 8) When a 802.1Q interface is used between a CE and a PE, each of the
>>VLAN ID (VID) on that interface can be mapped onto a bridge table
>>(for upto 4094 such bridge tables). All these bridge tables may be
>>mapped onto a single MAC-VRF (in case of VLAN-aware bundle service).
>>
>> >>>
>>
>> So it sounds like 1:1 is supported (that's the straightforward case where
>> the inner VLAD ID is stripped from the encap'ed packet) and All:1 is
>> supported (i.e. the service is blind to the incoming tag and just preserves
>> it as is, potentially with normalization if translation is required).
>>
>> What about the case for n:1 where I want some subset of VLAN IDs coming
>> in on a port to map to VNID1, and another subset map to VNID2?  Is that
>> explicitly disallowed?  If so, why?
>>
>> That’s is also supported. Refer to section 6 of RFC 7432 for different
>> service interfaces that are supported.
>>
>> Cheers,
>> Ali
>>
>> Thanks,
>> Anoop
>>
>>
>>
>>
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] My fumbled answer :-)

2017-07-20 Thread Henderickx, Wim (Nokia - BE/Antwerp) 
Adrian, the question is mainly what we are trying to achieve here with the 
draft.
If the goal is providing E2E SR-TE and utilizing all paths between the 
different DC(s) e.g. SR-TE policy does this as well.

You advertise a BGP SR-TE-policy with the different paths and you bind the 
prefix to them using the BGP-NH/colour. You can define a colour and weights and 
preferences to determine if you want to use ECMP, different weights or active 
standby, etc. A similar use case is described here: 
https://tools.ietf.org/html/draft-filsfils-spring-segment-routing-policy-01

I am mainly arguing the way we convey the different SR-TE path information. 
With SR-TE policy you get a level of indirection which means every time the 
path changes you don’t need to re-advertise the prefix, but just update the 
SR-TE policy update.

What is not part of SR-TE policy is GW discovery and you would need a 
controller to achieve the same thing. 

Hope this clarifies


On 20/07/2017, 16:29, "Adrian Farrel"  wrote:

Hi Wim,

That wasn't my most glorious moment :-)

I don't think that draft-drake-bess-datacenter-gateway and
draft-ietf-idr-segment-routing-te-policy are anything other than 
complementary.
Nor, apparently does Eric as he is a co-author of both documents :-)

I think high-level document names can sometimes lead to some confusion, but 
the
combination of "BGP", "SR", and "TE" in the same overviews only goes to show
that they are in the same general space, not that they overlap.

If you take a look at draft-farrel-spring-sr-domain-interconnect-00 you'll 
see
it references [I-D.previdi-idr-segment-routing-te-policy] (now adopted by 
the
IDR working group) as the assumed mechanism for advertising intra-AS links 
that
are SR TE policies. We also note that
[I-D.previdi-idr-segment-routing-te-policy] offers a method for label stack
compression.

I think the two mechanisms provide different functions, but functions that 
could
(or even should) be integrated into a deployable solution.

Thanks (and sorry again),

Adrian



___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

[bess] My fumbled answer :-)

2017-07-20 Thread Adrian Farrel 
Hi Wim,

That wasn't my most glorious moment :-)

I don't think that draft-drake-bess-datacenter-gateway and
draft-ietf-idr-segment-routing-te-policy are anything other than complementary.
Nor, apparently does Eric as he is a co-author of both documents :-)

I think high-level document names can sometimes lead to some confusion, but the
combination of "BGP", "SR", and "TE" in the same overviews only goes to show
that they are in the same general space, not that they overlap.

If you take a look at draft-farrel-spring-sr-domain-interconnect-00 you'll see
it references [I-D.previdi-idr-segment-routing-te-policy] (now adopted by the
IDR working group) as the assumed mechanism for advertising intra-AS links that
are SR TE policies. We also note that
[I-D.previdi-idr-segment-routing-te-policy] offers a method for label stack
compression.

I think the two mechanisms provide different functions, but functions that could
(or even should) be integrated into a deployable solution.

Thanks (and sorry again),

Adrian

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess