Re: [Bier] BIER rechartering

[Alia Atlas <[e-mail]>]

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
>