Re: [Bier] Warren Kumari's No Objection on draft-ietf-bier-architecture-07: (with COMMENT)

[Antoni Przygienda <[e-mail]>]

The IGP signaling has a hook to allow things like Steiner trees in the future already today. Currently, only the absence of a “tree type” TLV is specified to mean “use normal SPF” and the presence implying “do not participate, it’s some different tree”. 

Rest of the points raised have been addressed by Eric in satisfactory fashion IMO … 

thanks 

--- tony
 

<[e-mail]> spake:

    On Wed, Jul 5, 2017 at 4:08 PM, Eric C Rosen <[e-mail]> wrote:
    > On 7/5/2017 3:22 PM, Warren Kumari wrote:
    >>
    >> Notes:
    >> Section 1:
    >> "If the packet also needs to be sent to a BFER whose BFR-id is 257, the
    >> BFIR
    >> would have to create a second copy of the packet, and the BIER
    >> encapsulation
    >> would specify an SI of 1, and a BitString with bit 1 set and all the other
    >> bits
    >> clear." - while reading this it seemed to me that it would be much simpler
    >> to
    >> do away with the SI completely and just make the BitString N bits longer
    >
    >
    > The size of the BitString is really determined by the capabilities of the
    > forwarding hardware.
    
    Oh. Yeah, that is obvious (now :-)).
    
    >  And the encapsulations (at least, those specified in
    > draft-ietf-bier-mpls-encapsulation) support only certain sizes.  If your
    > hardware supports only a BitStringLength of 256, and you have 257 BFERs, you
    > can't just say, "hey let's use a longer BitString".  Even if your hardware
    > supports the next larger BitStringLength, 512, you might not want to use a
    > BitStringLength of 512 when you only have 257 BFERs.
    >
    >> (instead of having e.g a one octet SI and 2 octet BitString, concatenate
    >> this
    >> and have a 3 octet BitString).
    >
    >
    > A 3-octet BitString would allow you to identify 24 BFERs (3*8), whereas a
    > 1-octet SI and a 2-octet BitString allow you to identify 4096 BFERs
    > (256*16).  BTW, the BitStringLengths that are envisioned are all larger than
    > two octets.  I wouldn't expect to see less than 64 bits, and 256 is more
    > likely.
    >
    >> It was only when I got down to Section 3 that I
    >> discovered that this is (kinda) discussed, and that each SI can have a
    >> different BitString length.
    >
    >
    > Sub-domains can have different BitStringLengths, the SI is relative to a
    > single sub-domain.  The fact that sub-domains can have different
    > BitStringLengths may be useful if you have hardware that supports multiple
    > BitStringLengths, but that's really orthogonal to whether the SI is needed.
    >
    >> "Alternatively, one could deploy a routing underlay that creates a
    >> multicast-specific tree of some sort, perhaps a Steiner tree." A reference
    >> for
    >> Steiner trees would be nice -- best I could find was probably the WA page
    >> at:
    >> Weisstein, Eric W. "Steiner Tree." From MathWorld--A Wolfram Web Resource.
    >> http://mathworld.wolfram.com/SteinerTree.html
    >
    >
    > I think it is probably best to remove the mention of Steiner trees and
    > instead just say that the routing underlay could be some sort of multicast
    > tree.
    
    Awww. I really wanted a router with a big bucket of water and some
    soap, but your solutiuon works too.
    
    Thanks,
    W
    
    
    
    -- 
    I don't think the execution is relevant when it was obviously a bad
    idea in the first place.
    This is like putting rabid weasels in your pants, and later expressing
    regret at having chosen those particular rabid weasels and that pair
    of pants.
       ---maf