Re: [Bier] BIER rechartering

[Tony Przygienda <[e-mail]>]

yepp, Andrew is right. BIER was on purpose kept extremely independent of
the signalling involved. One can use any protocol that by some means
produces BIFTs (not even BIRTs really). Could be static, can be a
controller, can be the protocol you love most ;-)


On Thu, Jan 25, 2018 at 5:54 PM, Dolganow, Andrew (Nokia - SG/Singapore) <
[e-mail]> wrote:

>
>
>
>
> To me BIER is not about creating underlay protocols. The quote you have
> points to that. BIER re-uses, for example, IGP for underlay and if other
> things defined by other WGs would create alternative to that, then someone
> could bring that and propose as underlay for BIER (and now read again
> Alia’s comment).
>
>
>
> Andrew
>
>
>
> *From: *Alia Atlas <[e-mail]>
> *Date: *Friday, January 26, 2018 at 9:49 AM
> *To: *Xiejingrong <[e-mail]>
> *Cc: *Andrew Dolganow <[e-mail]>, "[e-mail]" <
> [e-mail]>
>
> *Subject: *Re: [Bier] BIER rechartering
>
>
>
> I haven't personally heard or seen applicability or demand.  There's a
> large amount of areas to explore in.
>
> If this fell into the applicability for applications and the WG had clear
> interest and agreement,
>
> I agree with Greg that there's flexibility there - though nothing to be
> Standards Track without
>
> a milestone agreed to by the responsible AD.
>
>
>
> Regards,
>
> Alia
>
>
>
> On Thu, Jan 25, 2018 at 8:44 PM, Xiejingrong <[e-mail]>
> wrote:
>
>
>
> Well, "involving" mean, to use a tree-building protocol to build BIER
> underlay info while building the tree.
>
> As been mentioned in RFC8279, "Alternatively, one could deploy a routing
> underlay that creates a multicast-specific tree of some sort.".
>
> More detail in draft-xie-bier-mvpn-mpls-p2mp.
>
>
>
> *From:* Dolganow, Andrew (Nokia - SG/Singapore) [mailto:
> [e-mail]]
> *Sent:* Friday, January 26, 2018 9:34 AM
> *To:* Xiejingrong <[e-mail]>
> *Cc:* Alia Atlas <[e-mail]>; [e-mail]
>
>
> *Subject:* Re: [Bier] BIER rechartering
>
>
>
> Not sure what the word “involving” means to you but architecture RFC and
> use case draft clearly state what we want to achieve with BIER. Re-charter
> is all about extending BIER solution so I do not see this necessary.
>
>
>
> Andrew
>
>
>
> *From: *BIER <[e-mail]> on behalf of Xiejingrong <
> [e-mail]>
> *Date: *Thursday, January 25, 2018 at 10:07 AM
> *To: *Alia Atlas <[e-mail]>, "[e-mail]" <[e-mail]>
> *Subject: *Re: [Bier] BIER rechartering
>
>
>
> Alia, Chars :
>
>
>
> Yesterday I went to wrong place. And today I raise it here again.
>
>
>
> What I am most concerned about is,  weather it is acceptable or not, of
> related solutions involving tree-building protocols ?
>
>
>
> I think it is necessary to be clarified explicitly, in this re-charter.
>
>
>
> Detail comments in-line.
>
>
>
> Regards.
>
> XieJingrong
>
>
>
>
>
> *From:* BIER [mailto:[e-mail] <[e-mail]>] *On
> Behalf Of *Alia Atlas
> *Sent:* Wednesday, January 24, 2018 7:12 AM
> *To:* [e-mail]
> *Subject:* [Bier] BIER rechartering
>
>
>
> As discussed, I have been working with Tony and Greg on the planned
> rechartering for the
>
> BIER WG.
>
>
>
> You can find this version at:  https://datatracker.ietf.
> org/doc/charter-ietf-bier/.
>
>
>
> Please send comments.  I want this to make the February 8 IESG telechat.
>
>
>
> ================================
> The BIER (Bit Index Explicit Replication) Working Group has defined
> an architecture [RFC 8279] for  multicast forwarding that uses an
> encapsulation [RFC 8296] that can be used on MPLS or Ethernet transport.
> The BIER-WG is now chartered to produce Standards Track RFCs and to
> update or do a Status Change for those RFCs previously published as
> Experimental (RFC 8279, RFC 8296, etc.).
>
> First and primarily, the BIER-WG will complete its work on:
>   1) Transition Mechanisms: The WG will describe how BIER
>      can be partially deployed and still provide useful
>      functionality. A minimum of the necessary mechanisms
>      to support incremental deployment and/or managing
>      different BIER mask-length compatibility may be defined.
>      Operation of BIER in non-congruent topologies, i.e.
>      topologies where not all routers are BIER capable can
>      also be addressed. In addition to tunneling solutions, other
>      approaches to make BIER deployable in such environments
>      can be worked on. Each such mechanism must include an
>      applicability statement to differentiate its necessity from
>      other proposed mechanisms.
> [XJR1]: I think P2MP based BIER can naturally work as an alternative
> partially deploy solution also. But unfortunately it involve tree-building
> protocol. Acceptable or not ?
>
>   2) Applicability Statements: The WG will describe how BIER can
>      be applied to multicast L3VPN and to EVPN. This draft will
>      describe what mechanism is used to communicate the group
>      membership between the ingress router and the egress routers,
>      what scalability considerations may arise, and any deployment
>      considerations. The WG will work on additional applicability
>      statements, as needed, describing how BIER can be applied.
>
> [XJR2]: MVPN using P2MP-based BIER, is also one way of apply BIER in MVPN.
> Acceptable or not ?
>
>
>   3) Use Case: The WG may produce one use-case document that clearly
>      articulates the potential benefits of BIER for different use-cases.
>   4) Manageability and OAM: The WG will describe how OAM will work in
>      a BIER domain and what simplifications BIER offers for managing the
>      multicast traffic. A strong preference will be given to extensions to
>      existing protocols.
>
> [XJR3]: P2MP-based BIER can use exist P2MP PMTU. It will be helpful.
> Acceptable or not ?
>
>   5) Management models: The WG may work on YANG models and, if needed, MIB
>      modules to support common manageability.
>
>
>   6) IGP extensions. When a BIER domain falls within a "link state IGP"
>      network, the information needed to set up the BIER forwarding tables
>      (e.g., the mapping between a given bit position and a given egress
>      router) may be carried in the link state advertisements of the IGP.
>      The link state advertisements may also carry other information related
>      to forwarding (e.g., the IGP may support multiple topologies, in which
>      case it may be necessary to advertise which topologies are to be used
>      for BIER forwarding). Any necessary extensions to the IGP will be
>      specified by the WG as Standards Track, in cooperation with the LSR
> WG.
> [XJR4]: How about BGP extensions as BIER underlay ? and how about
> RSVP-TE/MLDP extensions as BIER underlay ?
>
>
> The BIER-WG is additionally chartered to start Standards Track work on:
>   7) BIER in IPv6 :  A mechanism to use BIER natively in IPv6 may be
>      standardized if coordinated with the 6MAN WG and with understood
>      applicability.  Such functionality may focus on assuming software or
>      slow-path support first.
>   8) BIER Traffic Engineering:  An architecture for BIER-TE is defined
>      in draft-ietf-bier-te-arch; associated fundamental technology is
> included.
>
> [XJR5] Thanks for acceptance of this topic in the re-charter. I think it
> is a necessary puzzle, and P2MP-based BIER can also provide an alternative
> TE through transport mechanism. Acceptable or not ?
>
>   9) Extensions to support BIER in multi-area IGP Deployments
>
> The BIER-WG is chartered to investigate the following topics. The adoption
> of any Standards Track drafts will require a milestone approved by the
> responsible Area Director.
>   10) Novel uses of the BIER bitmap: There are a variety of proposals for
>       additional algorithms and other uses of the BIER bitmap and
>       encapsulation beyond BIER and BIER-TE.
>   11) BIER between Autonomous Domains:   With understood applicability,
>       these scenarios may be investigated.
>   12) Use of BIER in Controller-based Architectures:  How might controllers
>       be used to provide calculated BIRTs and/or BIFTs tables to BFRs?
>   13) Applicability of BIER to Applications: The WG may advise on the
>       applicability of BIER to various applications.
>
> The BIER-WG will coordinate with several different working groups and
> must include the relevant other working groups during working group
> last call on the relevant drafts. BIER-WG will coordinate with MPLS-WG
> on the associated MPLS-based OAM mechanisms. BIER-WG will coordinate with
> LSR-WG on extensions to flood BIER-related information. BIER-WG will
> advise BABEL-WG on Babel extensions to support BIER. BIER-WG will
> coordinate with BESS-WG and IDR-WG on the applicability of existing
> BGP-based mechanisms for providing multicast group membership information.
> BIER-WG will coordinate with PIM-WG on the applicability of and extensions
> to PIM, IGMP, and MLD to support BIER operations and transition; BIER-WG
> will work directly on the applicability statements, as needed.
>
> =================================
>
>
>
> Thanks,
>
> Alia
>
>
>
> _______________________________________________
> BIER mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bier
>
>