Subject: Re: [Bier] comments on draft-xu-bier-encapsulation-03

From: Xuxiaohu <[email-masked]>
Date: Mon, 2 Nov 2015 01:03:01 +0000

Hi Tony,

Thanks a lot for your good suggestions. Please see my reply inline.

________________________________
发件人: BIER [[email-masked]] 代表 Antoni Przygienda [[email-masked]]
发送时间: 2015年10月31日 19:49
收件人: [email-masked]
主题: [Bier] comments on draft-xu-bier-encapsulation-03

Re-read and rethought. The key lookup will be pretty wide but if one can afford the TCAMs and would want to build something like this I guess it’s feasible.

Architecturally the information carried in this encapsulation is more than necessary (which is NOT good). The architecture clearly indicates that a sub-domain MUST match onto one MT-ID and with that carrying both is superfluous, carrying subdomain is good enough. This also resolves the issue of e.g. driving this encapsulation with idr-extensions which doesn’t even carry a multi-topology concept.

[Xiaohu] OK,  we will remove the MT-ID field from the BIER header so as to keep it consistent with the current BIER architecture.

As well, why does the encaps carry BFR-id ? is that source/destination/originator ? None of those seem necessary to me ?

[Xiaohu] BFR-id indicates the ingress BFR. It may be neccessary in some use cases such as performance measurement.

I think the suggestion towards the authors has been already extended to read the excellent  dataplane  design draft put out by the according design team recently. I support that. Occam’s razor in data plane goes a long way ;-)

[Xiaohu] Thanks again for your valuable suggestions.
Best regards,
Xiaohu

thanks

--- tony

“Your work is to discover your work and then with all your heart to give yourself to it.” --- Buddha

---

From: Tony Przygienda <[email-masked]>
Date: Sun, 1 Nov 2015 18:24:13 -0800

Architecturally the information carried in this encapsulation is more than
> necessary (which is NOT good). The architecture clearly indicates that a
> sub-domain MUST match onto one MT-ID and with that carrying both is
> superfluous, carrying subdomain is good enough. This also resolves the
> issue of e.g. driving this encapsulation with idr-extensions which doesn’t
> even carry a multi-topology concept.
>
>
>
> [Xiaohu] OK,  we will remove the MT-ID field from the BIER header so as
> to keep it consistent with the current BIER architecture.
>

ack

>
>
> As well, why does the encaps carry BFR-id ? is that
> source/destination/originator ? None of those seem necessary to me ?
>
>
>
> [Xiaohu] BFR-id indicates the ingress BFR. It may be neccessary in some
> use cases such as performance measurement.
>

ok, if it's not used for the forwarding decision not much I can say about
it. We have however OAM drafts which provide for precisely this kind of
stuff so I suggest reading those. Putting OAM fields into forwarding header
is maybe not the best decision here  ..

---

From: IJsbrand Wijnands <[email-masked]>
Date: Mon, 2 Nov 2015 18:38:31 +0900

Hi Guys,

> ok, if it's not used for the forwarding decision not much I can say about it. We have however OAM drafts which provide for precisely this kind of stuff so I suggest reading those. Putting OAM fields into forwarding header is maybe not the best decision here  .. 

In MPLS encapsulation, the BFR-id is used as the Context to do the upstream label lookup. So it is part of the disposition decision, which is related to forwarding on the egress. Is VPN context supported in this encapsulation?

Thx,

Ice.

---

From: Tony Przygienda <[email-masked]>
Date: Mon, 2 Nov 2015 05:21:41 -0800

true, forgot that it may be needed in p2mp & mp2mp cases for correct
disposition of the frame inside. I stand corrected. tony

On Mon, Nov 2, 2015 at 1:38 AM, IJsbrand Wijnands <[email-masked]> wrote:

> > ok, if it's not used for the forwarding decision not much I can say
> about it. We have however OAM drafts which provide for precisely this kind
> of stuff so I suggest reading those. Putting OAM fields into forwarding
> header is maybe not the best decision here  ..
>
> In MPLS encapsulation, the BFR-id is used as the Context to do the
> upstream label lookup. So it is part of the disposition decision, which is
> related to forwarding on the egress. Is VPN context supported in this
> encapsulation?
>
> Thx,
>
> Ice.

-- 
*We’ve heard that a million monkeys at a million keyboards could produce
the complete works of Shakespeare; now, thanks to the Internet, we know
that is not true.*
—Robert Wilensky