Re: [Bier] AD review of draft-ietf-bier-architecture-06

[Antoni Przygienda <[e-mail]>]

Inline …



--- tony

    >

    > Minor:

    >

    > 1) Sec 4.1: "its BFR prefix"  Is it possible to have multiple BFR prefixes for the same BFR?  I am thinking about renumbering cases (for acquisitions) as well as migrations from IPv4 to IPv4 + IPv6 and then to IPv6.  Conceptually, I see no reason that there couldn't be multiple BFR prefixes for the same BFR as long as they really are that BFR's prefixes.



    Ice: I don’t see "its BFR prefix” in 4.1, but 4.2. Are you asking to allow a router to have say two different BFR-Prefixes for the same BFR-id? I agree if the BFR-Prefixes are on the same router it would not hurt, but it would mess up the duplicate BFR-id detection in the rest of the network. A BFR-id that is owned by multiple BFR-Prefixes indicates an inconsistency and will make the BFR-id to be removed from the BIFT.





      Prz: All procedures are written with a tactic assumption that we have a single BFR-prefix, the implied conceptual model has been spread in language but bit below it is as rough UML (it is probably easiest derived from the ISIS encoding document & the restrictions put on TLV). Having said that, BIER does NOT govern how many such prefixes can show up but reading the ISIS spec we clearly govern for subdomains in BIER Info sub-TLV that



“This sub-TLV MAY appear multiple

   times in a given prefix-reachability TLV - once for each sub-domain

   supported in the associated topology”



We could say more explicitly that “if the subdomain shows up twice ignore it” or “ignore the whole prefix” or “ignore subdomain” or “behavior unspecified”. Thinking through it however whether the domains show up in a single prefix or multiple does not even matter except for possibly BIFT computation where you may need an IP address for a next-hop but then again (and practically; when flooding you really prefer all in a single flooded packet rather than stitching the bits). BIFT construction/computation is implementation dependent so maybe the spec does not have to govern ANYTHING about BFR prefix. With that, the <: BFR-->(1)BFR prefix :> multiplicity may be left out without making the model=BIER architecture defective.



BTW, if anybody sees deviation in this picture of what BIER architecture consists off, please speak up now or hold your piece forever ;-)



[cid:image001.png@01D2E694.6117BE60]



    >

    >

    > 2) Sec 4.2: This is missing the procedures for removing the BIER header for the payload - which would presumably include potential details such as TTL inheritance and DSCP/EXP handling….



    Ice: Yes, part of the procedures should also be “Disposition” of the BIER header.



Prz: Correct, we need clear procedures for the bits in the MPLS label we’re silent about.





    >

    > 4) Sec 6.6.1:"At BFER-D, the BIFT entry (not pictured) for BFR-id 1 will specify an

    >    F-BM of 0000 and a BFR-NBR of BFR-D itself."

    > Sec 6.6.2: "At BFER-D, the BIFT entry (not pictured) for BFR-id 1 will specify an

    >    F-BM of 0000 and a BFR-NBR of BFR-D itself."  and "At BFER-E, the BIFT entry (not pictured) for BFR-id 3 will specify an F-BM of 0000 and a BFR-NBR of BFR-E itself."

    > I don't understand why the F-BM would be 0000 and not 0001 nor how the packet's BitString would end up cleared if the F-BM were 0000.   I suspect a typo, but it is repeated thrice...  I will note that in Sec 6.5 after the pseudocode, it says " It also assumes that the corresponding F-BM has only one bit set, the bit representing the BFER itself."  which appears to contradict the two examples.



    Ice: I think you’re right. The F-BM should be 0001, otherwise the procedure to clear the bit would also not work. We’ll fix it, good catch!



Prz: Looked @ it as well and yes, it needs the fix. Alia, a most impressive diving catch ;-)



[cid:image002.png@01D2E694.6117BE60]





    >

    > 6) Sec 10.2.1: "This fallback procedure will work best if the value of F is

    >    established by the architecture, rather than by provisioning."  Since this is the

    > architecture and it does specify that all BFRs must support a BitStringLength of 256 - surely this is exactly the point to establish the value of F and there isn't a better time. :-)



    Ice: Sec 6.10.1? Ok, maybe we can add that it is RECOMMENDED that the fallback disposition bit-string length is 256...





Prz: I suggest to say that F=256 simply and be done with it …



    >

    > Nit:

    >

    > a) End of Section 3:"An encapsulation for use in MPLS networks is described in

    >    [MPLS_BIER_ENCAPS]"

    > Given that encap is also now a generic encapsulation that will work for Ethernet, this statement could be expanded to be more complete.



    Ice: Ok.



    >

    > b) Sec 4.3: "Since BIER is, in effect, a new type of "tunneling

    >    technology", some extensions to the MVPN signaling are needed in

    >    order to properly interface the multicast flow overlay with the BIER

    >    layer.  These will be specified in a companion document."

    > I think that this is draft-ietf-bier-mvpn, so it'd be helpful to have an informative reference to it.



    Ice: Ack!





Prz: I suggest to refer to more generic “overlay signaling” [we just published EVPN] and refer to MPVN draft as a specific incarnation of such an “overlay signaling”



--- tony