Subject: Re: [Bier] comments on draft-zhang-bier-designed-routing-00.txt

From: [email-masked]
Date: Mon, 2 Nov 2015 17:28:11 +0800

Hi Tony,

    Thank for your comments. The algorithm in BIER-TE-Arch is that 
every BIER node calculates their TE forwarding table separately. And
the TE-forwarding-table is not the same as the the forwarding table
that is defined in BIER-Arch. The matching rules that is defined
in BIER-TE-Arch is special too.
    This forwarding table which is defined in this draft(designed-
routing) is the same as BIER-Arch. And the matching rules in this 
draft is the same as BIER-Arch. So there is no additional calculation 
in BIER node rather than the calculation defined in the BIER-TE-Arch.

Best regards,
Sandy

Antoni Przygienda <[email-masked]> 
发件人:  "BIER" <[email-masked]>
2015-10-31 下午 07:49

收件人
"[email-masked]" <[email-masked]>, 
抄送

主题
[Bier] comments on draft-zhang-bier-designed-routing-00.txt

Flew over the draft and I think (I did not have time to follow the 
extensive exapmles given by the authors) that the draft as written will 
always duplicate given that a representation of hierarchical bitmasks 
given by authors is not a datastructure that can represent a DAG without 
running @ least a specialized O (N log(N)) computation over the bitmasks. 
Simple Banyan example works easily (source is @ level 1 in my enumeration) 

Trying to describe something that delivers to the set of [ Source, 
Transit1, Transit2, Sink2 ] cannot be done with 3 levels of bitmasks 
without replicating to Sink2 _UNLESS_ Source does not only compute level 2 
bitmasks but also level 3, i.e. computes that Transit2 and Transit1 
receive _different_ level3 bitmasks. The according computation is e.g. a 
Dijkstra that tie-breaks ECMPs (ONlogN is very dirty complexity measure 
for Dijkstra but sufficient for purpose of this discussion). 
 
I don’t consider running Dijkstra’s for the bitmasks (observe that set 
of receivers will modify the necessary computation) and modifying the 
whole hierarchy per node the packet is replicated to something that is 
justifiable in complexity for what it achieves, especially given the size 
of the headers we’re talking. I would consider the BIER-TE suggestion 
significantly better here. 
 
thanks 
 
--- tony
 
“Your work is to discover your work and then with all your heart to give 
yourself to it.” --- Buddha 
 _______________________________________________
BIER mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/bier

---

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

TE does not seem to define hierarchical masks and I fear you missed my
point ...

-- tony

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

> *Antoni Przygienda <[email-masked]
> <[email-masked]>>*
> always duplicate given that a representation of hierarchical bitmasks given
> by authors is not a datastructure that can represent a DAG without running
> @ least a specialized O (N log(N)) computation over the bitmasks. Simple
> Banyan example works easily (source is @ level 1 in my enumeration)
>
>
> without replicating to Sink2 _*UNLESS*_ Source does not only compute
> level 2 bitmasks but also level 3, i.e. computes that Transit2 and Transit1
> receive _*different*_ level3 bitmasks. The according computation is e.g.
> a Dijkstra that tie-breaks ECMPs (ONlogN is very dirty complexity measure
> I don’t consider running Dijkstra’s for the bitmasks (observe that set of
> receivers will modify the necessary computation) and modifying the whole
> hierarchy per node the packet is replicated to something that is
> *--- tony*
> yourself to it.” --- *Buddha*

-- 
*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

---

From: [email-masked]
Date: Tue, 3 Nov 2015 10:35:04 +0800

Hi Tony,

    Yes, the hierarchical masks is not used in BIER-TE-Arch. But the 
forwarding table that is defined in BIER-TE-Arch is different from
the table that is defined in BIER-Arch. The forwarding table that is 
used in BIER-Arch includes the egress nodes' bitmask string. If I 
don't misunderstand the BIER-TE, the forwarding table that is used in 
BIER-TE includes the links' bitmask string. Though the forwarding table 
that is used in BIER-TE is calculated by IGP too, but it's not the same 
forwarding table as the table in BIER-Arch.

Best regards,
Sandy

Tony Przygienda <[email-masked]> 
2015-11-02 下午 09:17

收件人
[email-masked], 
抄送
Antoni Przygienda <[email-masked]>, "[email-masked]" 
<[email-masked]>, BIER <[email-masked]>
主题
Re: [Bier] comments on draft-zhang-bier-designed-routing-00.txt

-- tony 

Best regards, 
Sandy 

收件人

主题

  
  
thanks 
  
--- tony 

-- 
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

---

From: Antoni Przygienda <[email-masked]>
Date: Tue, 3 Nov 2015 05:04:06 +0000

Does it ? Last time I read the draft I didn’t see any ‘outgoing bitmask’ but the bits were reset (modulo DNR bit)

With such an ‘outgoing bitmask’ I didn’t see I agree it can be made to work with significant extensions to IGP computation (you need consistent tie-breaking for _all_ nodes that compute outgoing masks + special considerations for ECMP and load-balancing)

Let’s see how much interest that creates …

thanks

--- tony
_____________________________________________
“Simple, clear purpose and principles give rise to complex and intelligent behavior. Complex rules and regulations give rise to simple and stupid behavior.”
--- Dee Hock

From: [email-masked] [mailto:[email-masked]]
Sent: Monday, November 02, 2015 6:35 PM
To: Tony Przygienda
Cc: Antoni Przygienda; [email-masked]; BIER
Subject: Re: [Bier] comments on draft-zhang-bier-designed-routing-00.txt

Hi Tony,

Best regards,
Sandy

Tony Przygienda <[email-masked]<mailto:[email-masked]>>

2015-11-02 下午 09:17

收件人

[email-masked]<mailto:[email-masked]>,

抄送

Antoni Przygienda <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, BIER <[email-masked]<mailto:[email-masked]>>

主题

TE does not seem to define hierarchical masks and I fear you missed my point ...

-- tony

On Mon, Nov 2, 2015 at 1:28 AM, <[email-masked]<mailto:[email-masked]>> wrote:
Hi Tony,

Best regards,
Sandy

Antoni Przygienda <[email-masked]<mailto:[email-masked]>>
发件人:  "BIER" <[email-masked]<mailto:[email-masked]>>

2015-10-31 下午 07:49

收件人

"[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>,

抄送

主题

Flew over the draft and I think (I did not have time to follow the extensive exapmles given by the authors) that the draft as written will always duplicate given that a representation of hierarchical bitmasks given by authors is not a datastructure that can represent a DAG without running @ least a specialized O (N log(N)) computation over the bitmasks. Simple Banyan example works easily (source is @ level 1 in my enumeration)

Trying to describe something that delivers to the set of [ Source, Transit1, Transit2, Sink2 ] cannot be done with 3 levels of bitmasks without replicating to Sink2 _UNLESS_ Source does not only compute level 2 bitmasks but also level 3, i.e. computes that Transit2 and Transit1 receive _different_ level3 bitmasks. The according computation is e.g. a Dijkstra that tie-breaks ECMPs (ONlogN is very dirty complexity measure for Dijkstra but sufficient for purpose of this discussion).

I don’t consider running Dijkstra’s for the bitmasks (observe that set of receivers will modify the necessary computation) and modifying the whole hierarchy per node the packet is replicated to something that is justifiable in complexity for what it achieves, especially given the size of the headers we’re talking. I would consider the BIER-TE suggestion significantly better here.

thanks

--- tony

“Your work is to discover your work and then with all your heart to give yourself to it.” --- Buddha
 _______________________________________________
BIER mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bier

_______________________________________________
BIER mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bier

--
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