Re: [Bier] proposed BIER charter

[Alia Atlas <[e-mail]>]

Hi Arkadiy,

First, we were all new to the IETF once.  Your feedback and opinions are
quite welcome.  WG charters are discussed to get feedback and agreement on
the details and scope.

I'm delighted to hear of your interest and that of other operators.  I did,
of course, speak with you before the BoF and know of your involvement in
the drafts.  Unfortunately, I haven't heard such support expressed in the
IETF by operators; obviously vendors' interest
can reflect such interest indirectly.

I believe that BIER is currently at the stage of a development effort.  I
have done my best to be clear that there is a path forward from
Experimental - but it really really depends on getting some experience with
the technology and being more confident of the actual demand.

I am trying to provide a WG to get rapid progress on BIER.  The other
option is to wait and do a second BoF possibly in March or in July and see
if there is stronger demand for having the technology and really clear
benefits articulated that would drive it.  Unfortunately, while the
problem-statement and use-cases have improved since the Nov BoF, they are
still not sufficiently convincing.

This is very ambitious innovative work - which is great - but I have seen
many technologies be the excitement of the year and then flounder.
If it does catch on, then there is certainly an ability to recharter to the
standards track.  As you probably noticed, in the proposed charter, there
is a item 9, in which your help could be particlarly significant.

Regards,
Alia


On Thu, Feb 12, 2015 at 6:20 PM, <[e-mail]> wrote:

>  Alia,
>
> I have been engaged with BIER technology for the last year and a half from
> its inception. It come along way and it was not driven just based on
> excitement. This work is backed up by commitment from major vendors and
> multiple operators. I have discussed BIER on multiple occasions with other
> operators, they showed a great interest and strong support with overall
> consensus that BIER will build a right foundation for efficient multicast
> delivery for operators to standardize. I promoted BIER within Thomson
> Reuters on the Business and Technology sides and feedback was overwhelming,
> with huge interest from Thomson Reuters development community. Based on my
> involvement with BIER, I struggle to define it as Experimental as per
> included definition below and I completely agree with Stewart on his
> assessment of your proposed charter. Please don't take it as a criticism, I
> am very novice in terms of IETF protocols and procedures but as per my
> findings of IETF definitions:
>
> "WG charters state the scope of work for group, and lay out goals and
> milestones that show how this work will be completed."
>
> The proposed version in the way it was written more focusing on
> conditional statements and depicts some unwillingness of IETF to
> promote/proceed with BIER as a committed work.
>
>
>
> Snapshot from IETF.org
>
> “4.2.1 Experimental
>
> The "Experimental" designation typically denotes a specification that is
> part of some research or development effort. Such a specification is
> published for the general information of the Internet technical community
> and as an archival record of the work, subject only to editorial
> considerations and to verification that there has been adequate
> coordination with the standards process (see below). An Experimental
> specification may be the output of an organized Internet research effort
> (e.g., a Research Group of the IRTF), an IETF Working Group, or it may be
> an individual contribution.”
>
>
>
> I would like to continue to promote BIER and take an active part in
> developing of new multicast technologies for my company and industry
> benefits. There are plenty of challenges in this arena, but only via active
> participation these challenges can be resolved. We need to see commitment
> from IETF to move BIER development forward.
>
>
>
> Regards,
>
> Arkadiy
>
>
>
>
>
> *From:* BIER [mailto:[e-mail]] *On Behalf Of *Alia Atlas
> *Sent:* Thursday, February 12, 2015 10:14 AM
> *To:* stbryant
> *Cc:* Adrian Farrel; [e-mail]; [e-mail]; Alvaro Retana
> *Subject:* Re: [Bier] proposed BIER charter
>
>
>
> Stewart,
>
>
>
> I certainly appreciate your taking the time to provide feedback.  I
> understand that you
>
> are excited by this technology and have urged that innovation needs time
> and space
>
> to be worked on before being evaluated by the harsh realities of the
> marketplace and
>
> interest in deployments.
>
>
>
> On Thu, Feb 12, 2015 at 8:44 AM, Stewart Bryant <[e-mail]>
> wrote:
>
> Alia
>
> I think that you are crossing far too many bridges before you get to them
> in terms of you expectation of where BIER will be deployed and how
> it will be implemented.
>
>
>
> I did read the use-cases and understand the primary motivation is for MVPN
>
> and EVPN which are deployed in the backbone of SP networks that operate at
>
> high speeds.  Even in data-centers, use of 10G links is common.
>
>
>
>  The charter should not include such specific assumptions, particularly
> given the fast moving changes that are happening in our industry
> especially in the area of packet forwarding design.
>
>
>
> What specifically are you objecting to?
>
>
>
>  I have not seen such assumptions in other charters and I don't think
> that they have a place in this one.
>
>
>
> What specific assumption are you objecting to and what reasoning do you
> have
>
> beyond historical?
>
>
>
>  In terms of choice of document stream (experimental vs PS),
> that is a decision that can be taken at the time of publication
> when more information will be available in terms of potential
> market take-up, expected/actual deployment scenarios,
> breadth of implementation and implementation experience.
>
>
>
> At this time, a sufficiently compelling case has not been made to convince
> that
>
> PS is anywhere near appropriate for this change of adding a completely new
> forwarding
>
> algorithm and a fourth  encapsulation to go with IPv4, IPv6, and MPLS to
> the Internet
>
> architecture for the next 15+ years.
>
>
>
> It is true that if that changes between now and when drafts are ready to
> progress, that can
>
> be revisited.
>
>
>
> There are WGs that have been chartered to do experimental work in the
> past.  I understand
>
> that it is disappointing that there wasn't a strong case for more than
> experimental at this time.
>
>
>
> I have been extremely clear since the last IETF that I was only
> considering Experimental for
>
> the WG for the initial chartering.
>
>
>
>  Whilst this technology may be deployed in the Internet core,
> it my also be deployed at the edge where a much lower threshold
> is applicable.
>
>
>
> The technology needs to work in both locations - given the use-cases.
> What specifically are
>
> you objecting to?
>
>
>
>  I fear that by introducing these caveats the IETF is entrenching the
> perception that it slows technology down rather than embracing
> and encouraging innovation.
>
>
>
> By creating a WG for open collaboration and defining an ambitious new
> forwarding technology,
>
> the IETF is not embracing and encouraging innovation?  I suppose it's all
> in the eye of the
>
> beholder - but to me it feels like "give an inch and get pushed for a
> mile".
>
>
>
>  I would therefore suggest removing the text on implementation
> styles and document stream constraints.
>
>
>
> IF the encapsulations are specified in a way that two independent
> interoperable implementations
>
> are not available, it both increases the risk that we might end up with
> two different versions - one
>
> Experimental and another through bitter experience that is PS later - and
> is a poor indication of
>
> the lack of industry support and interest in the technology and its use.
>
>
>
> Regards,
>
> Alia
>
>
>
>
> - Stewart
>
>
>
> On 11/02/2015 20:44, Alia Atlas wrote:
>
>   I have been working on getting a charter together for BIER with the
> intent of pushing for it to be chartered before the Dallas IETF.  This has
> not yet gone through IESG review and it may have some aspects updated.
>
>
>
> Please send comments here.
>
>
>
> The charter can be found at
> http://datatracker.ietf.org/doc/charter-ietf-bier/
>
> and is included below as well.
>
>
>
>
>
> WG Chairs:
>
>   Greg Shepherd  <[e-mail]>
>
>   Tony Przygienda <[e-mail]>
>
>
>
>
>
> In conventional IP multicast forwarding, the packets of a given
>
> multicast "flow" are forwarded along a tree that has been constructed
>
> for the specific purpose of carrying that flow.  This requires transit
>
> nodes to maintain state on a per-flow basis, and requires the transit
>
> nodes to participate in multicast-specific tree building protocols.
>
> The flow to which a packet belongs is determined by its IP source and
>
> destination address fields.
>
>
>
> BIER (Bit Index Explicit Replication) is an alternative method of
>
> multicast forwarding.  It does not require any multicast-specific
>
> trees, and hence does not require any multicast-specific tree building
>
> protocols.  Within a given "BIER domain", an ingress node encapsulates
>
> a multicast data packet in a "BIER header".  The BIER header
>
> identifies the packet's egress nodes in that domain.  Each possible
>
> egress node is represented by a a single bit within a bitstring; to
>
> send a packet to a particular set of egress nodes, the ingress node
>
> sets the bits for each of those egress nodes, and clears the other
>
> bits in the bistring.  Each packet can then be forwarded along the
>
> unicast shortest path tree from the ingress node to the egress nodes.
>
> Thus there are no per-flow forwarding entries.
>
>
>
> Due to the particular sensitivity of adding new significant
>
> functionality into the data-plane at high link speeds, the BIER work
>
> will progress as Experimental.  As described in item (9) below, the
>
> work may become Standards Track once there is sufficient experience
>
> with the benefits and downsides of the technology.
>
>
>
> BIER is initially chartered to do experimental work on this new
>
> multicast forwarding mechanism as follows:
>
>
>
>    1) BIER architecture: The WG will publish an architecture, based
>
>    upon draft-wijnands-bier-architecture-04.  It will include the
>
>    normative algorithm for how BIER packet forwarding is done.  It
>
>    will specify the information that is required by a BIER header to
>
>    support BIER forwarding.
>
>
>
>    2) BIER encapsulation: The working group should assume that the
>
>    technology will need to be embedded in the data plane and operate
>
>    at the highest packet line speeds.  The WG will publish a document
>
>    defining an MPLS-based encapsulation based upon
>
>    draft-wijnands-mpls-bier-encapsulation-02. Due to the critical need
>
>    to have a high-quality and stable RFC for a new data-plane
>
>    encapsulation, the MPLS-based encapsulation draft shall wait after
>
>    WGLC and not progress to IETF Last Call until there are two
>
>    independent interoperable implementations.
>
>
>
>    As a secondary focus, the WG may also work on one non-MPLS
>
>    data-plane encapsulation.  This draft also shall wait after WGLC
>
>    and not progress to IETF Last Call until there are two independent
>
>    interoperable implementations.  This draft must focus on and
>
>    include the following details:
>
>
>
>        a) What is the applicability of the encapsulation and for which
>
>        use-cases is this encapsulation required?
>
>
>
>        b) Does this proposed encapsulation imply any changes to the
>
>        MPLS-based encapsulation?
>
>
>
>        c) What design choices have been made for the encapsulation
>
>        type and the included fields.
>
>
>
>        d) The proposed encapsulation with considerations given to at
>
>        least OAM, Class of Service, security, fragmentation, TTL.
>
>
>
>    3) 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.  Each such mechanism must include an applicability
>
>    statement to differentiate its necessity from other proposed
>
>    mechanisms.
>
>
>
>    4) Applicability Statements: The WG will work on a document
>
>    describing 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.
>
>
>
>    5) Use Case: The WG may produce one use-case document that clearly
>
>    articulates the potential benefits of BIER for different use-cases.
>
>    This would be based upon draft-kumar-bier-use-cases-01.
>
>
>
>    6) 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.
>
>
>
>    7) Management models: The WG may work on YANG models and, if needed,
>
>    MIB modules to support common manageability.
>
>
>
>    8) 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 advertisments 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, in cooperation with the ISIS and OSPF WGs.
>
>
>
>    9) Deployment Experience: Once there is deployment experience, the
>
>    WG will produce a document describing the benefits, problems, and
>
>    trade-offs for using BIER instead of traditional multicast
>
>    forwarding mechanisms.  Ideally, this should also contain an
>
>    analysis of the impact and benefit of the new BIER data-plane to
>
>    the overall Internet architecture.  This document is intended to be
>
>    used to evaluate whether to recharter BIER to produce Standards
>
>    Track RFCs.
>
>
>
> The BIER working group 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 will coordinate
>
> with MPLS on the MPLS-based encapsulation and associated MPLS-based
>
> OAM mechanisms.  BIER will coordinate with ISIS and OSPF on extensions
>
> to flood BIER-related information.  BIER will coordinate with BESS and
>
> IDR on the applicability of existing BGP-based mechanisms for
>
> providing multicast group membership information.
>
>
>
> Regards,
>
> Alia
>
>
>
> _______________________________________________
>
> BIER mailing list
>
> [e-mail]
>
> https://www.ietf.org/mailman/listinfo/bier
>
>
>
>
>  --
>
> For corporate legal information go to:
>
>
>
> http://www.cisco.com/web/about/doing_business/legal/cri/index.html
>
>
>
>
>