Subject: [Bier] BIER rechartering

From: Alia Atlas <[email-masked]>
Date: Tue, 23 Jan 2018 18:12:11 -0500

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.
  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.
  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.
  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.

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.
  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

---

From: "Dolganow, Andrew (Nokia - SG/Singapore)" <[email-masked]>
Date: Wed, 24 Jan 2018 00:42:56 +0000

Inline prefixed with ad>

From: BIER <[email-masked]> on behalf of Alia Atlas <[email-masked]>
Date: Wednesday, January 24, 2018 at 10:12 AM
To: "[email-masked]" <[email-masked]>
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/.

Ad> I think we want to slightly change that to be less limiting. Not crazy about: can be partially deployed and still provide useful
     functionality. “ would rather say “can be introduced in existing multicast networks to shift multicast delivery either e2e or in part of a network from mechanisms like PIM, ng-MVPN, etc.”

  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.
  3) Use Case: The WG may produce one use-case document that clearly
     articulates the potential benefits of BIER for different use-cases.
Ad>quite limiting. Why not just say:
Use Case: The WG may continue to augment existing or produce new use-case document(s) that
     articulate 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.
Ad> “A strong preference will be given to extensions to
     existing protocols” – is this not a general IETF rule?

  5) Management models: The WG may work on YANG models and, if needed, MIB
     modules to support common manageability.
Ad> Why not say “The WG will work on defining management APIs to support BIER manageability.”
I think we need a management model(s) but really MIB (unless we want to be last WG that defines SNMP)

Ad> Can we say “in co-operation with IETF WGs chartered with IGP protocol ownership”  instead of “in cooperation with the LSR WG”. DO not want to re-charter in case we change/modify/merge/evolve other WGs.

Ad> I do not think we should limit unnecessarily the solution or open doors for things that are possible (anything can be done in S/W) but potentially of little value. SO if someone brings a proposal for slow-path BIER we will evaluate on usefulness to use case being solved.

  8) BIER Traffic Engineering:  An architecture for BIER-TE is defined
     in draft-ietf-bier-te-arch; associated fundamental technology is included.
  9) Extensions to support BIER in multi-area IGP Deployments
Ad> should we just merge this with 6 above?

Andrew

Thanks,
Alia

---

From: Tony Przygienda <[email-masked]>
Date: Tue, 23 Jan 2018 16:59:52 -0800

>
> Ad> Can we say “in co-operation with IETF WGs chartered with IGP protocol
> ownership”  instead of “in cooperation with the LSR WG”. DO not want to
> re-charter in case we change/modify/merge/evolve other WGs.
>
>
> Ad> I do not think we should limit unnecessarily the solution or open
> doors for things that are possible (anything can be done in S/W) but
> potentially of little value. SO if someone brings a proposal for slow-path
> BIER we will evaluate on usefulness to use case being solved.
>
>
https://tools.ietf.org/html/draft-zhang-bier-bierin6-00

---

From: "徐小虎(义先)" <[email-masked]>
Date: Wed, 24 Jan 2018 09:32:46 +0800

I'm a bit confused about the motivation of the following BIER-IN-IPV6 mechanism. If it's targeted for the hop-by-hop forwarding paradigm, wouldn't the non-MPLS -BIER encapsulation (over Ethernet) be good enough? 
Best regards,Xiaohu------------------------------------------------------------------发件人：Tony Przygienda <[email-masked]>发送时间：2018年1月24日(星期三) 09:00收件人："Dolganow, Andrew (Nokia - SG/Singapore)" <[email-masked]>抄　送：[email-masked] <[email-masked]>主　题：Re: [Bier] BIER rechartering

Ad> Can we say “in co-operation with IETF WGs chartered with IGP protocol ownership”  instead of “in cooperation
 with the LSR WG”. DO not want to re-charter in case we change/modify/merge/evolve other WGs.

     slow-path support first.Ad> I do not think we should limit unnecessarily the solution or open doors for things that are possible (anything can be done in S/W) but potentially of little value.
 SO if someone brings a proposal for slow-path BIER we will evaluate on usefulness to use case being solved.
https://tools.ietf.org/html/draft-zhang-bier-bierin6-00

---

From: Tony Przygienda <[email-masked]>
Date: Tue, 23 Jan 2018 17:45:02 -0800

I think the draft explains it. This mechanism does not precondition any
kind of specialized BIER HW support (i.e. ether chip with programmable
ether types or MPLS silicon). This may be good enough for e.g. HomeNet
deployment ...

On Tue, Jan 23, 2018 at 5:32 PM, 徐小虎(义先) <[email-masked]> wrote:

> I'm a bit confused about the motivation of the following BIER-IN-IPV6
> mechanism. If it's targeted for the hop-by-hop forwarding paradigm,
> wouldn't the non-MPLS -BIER encapsulation (over Ethernet) be good enough?
>
> Best regards,
> Xiaohu
>
> ------------------------------------------------------------------
> 发件人：Tony Przygienda <[email-masked]>
> 发送时间：2018年1月24日(星期三) 09:00
> 收件人："Dolganow, Andrew (Nokia - SG/Singapore)" <[email-masked]>
> 抄 送：[email-masked] <[email-masked]>
> 主 题：Re: [Bier] BIER rechartering
>
>
>
> _______________________________________________
> BIER mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bier
>
>

---

From: "徐小虎(义先)" <[email-masked]>
Date: Wed, 24 Jan 2018 10:02:26 +0800

Hi Tony,
Thanks for your quick reply. For the scenario as you mentioned, wouldn't the non-MPLS-BIER-over-UDP encapsulation (https://tools.ietf.org/html/draft-xu-bier-non-mpls-encap-over-udp-02.txt) be good enough? 
Best regards,Xiaohu
------------------------------------------------------------------发件人：Tony Przygienda <[email-masked]>发送时间：2018年1月24日(星期三) 09:45收件人：徐小虎(义先) <[email-masked]>抄　送："Dolganow, Andrew (Nokia - SG/Singapore)" <[email-masked]>; BIER <[email-masked]>; [email-masked] <[email-masked]>主　题：Re: [Bier] 回复： BIER rechartering
I think the draft explains it. This mechanism does not precondition any kind of specialized BIER HW support (i.e. ether chip with programmable ether types or MPLS silicon). This may be good enough for e.g. HomeNet deployment ... 

BIER mailing list
[email-masked]

---

From: Tony Przygienda <[email-masked]>
Date: Tue, 23 Jan 2018 18:04:26 -0800

yes, no, maybe ... idea is of course very good for the place it applies to
but you need to stabilize the draft first (which as I saw is making
excellent progress) and then expect a HomeNet router to implement that .vs.
today's existing v6 stacks ...

A good question is whether the charter should be really "BIER in anything
as long it's one-hop-only" ? I would say, yeah, why not but please pester
our friendly AD with it ;-)

--- tony

On Tue, Jan 23, 2018 at 6:02 PM, 徐小虎(义先) <[email-masked]> wrote:

> Hi Tony,
>
> Thanks for your quick reply. For the scenario as you mentioned, wouldn't
> the non-MPLS-BIER-over-UDP encapsulation (https://tools.ietf.org/html/
> draft-xu-bier-non-mpls-encap-over-udp-02.txt) be good enough?
>
> Best regards,
> Xiaohu
>
> 发送时间：2018年1月24日(星期三) 09:45
> 收件人：徐小虎(义先) <[email-masked]>
> 抄 送："Dolganow, Andrew (Nokia - SG/Singapore)" <[email-masked]>;
> BIER <[email-masked]>; [email-masked] <[email-masked]>
> 主 题：Re: [Bier] 回复： BIER rechartering
>

---

From: Tony Przygienda <[email-masked]>
Date: Tue, 23 Jan 2018 18:12:35 -0800

oops, sorry, confused with SR-MPLS-UDP draft ;-) Your draft is stable ;-)
Too much reading in a day ...

My comment with "BIER over anything 1 hop" still applies of course ... BIER
over tunnels should be basically a no-brainer but used of course only if
IGPs compute over the according FAs ... So my observation to the
non-MPLS-BIER-over-UDP
encapsulation is that unless it's used as a FA it's a very sharp knife
indeed given a BIER frame showing up in an arbitrary place being fwd'ed may
cause interesting effects I didn't think fully through yet but don't have a
particularly good feelling about ;-) ...

--- tony

On Tue, Jan 23, 2018 at 6:04 PM, Tony Przygienda <[email-masked]>
wrote:

>> the non-MPLS-BIER-over-UDP encapsulation (https://tools.ietf.org/html/d
>> raft-xu-bier-non-mpls-encap-over-udp-02.txt) be good enough?
>>
>> Best regards,
>> Xiaohu
>>

---

From: "Dolganow, Andrew (Nokia - SG/Singapore)" <[email-masked]>
Date: Wed, 24 Jan 2018 04:56:46 +0000

Tony,

This is discussion on charter not individual draft. We did have some good discussion on the draft below as reflected by minutes. My comment is that the charter as proposed limits potential solutions unnecessarily. I propose we remove trhe limiting condition “Such functionality may focus on assuming software or slow-path support first” from the charter.

Andrew

From: Tony Przygienda <[email-masked]>
Date: Wednesday, January 24, 2018 at 12:00 PM
To: Andrew Dolganow <[email-masked]>
Cc: Alia Atlas <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Bier] BIER rechartering

---

From: Jeff Tantsura <[email-masked]>
Date: Tue, 23 Jan 2018 21:04:10 -0800

+1

don’t see why we should limit ourselves 

Cheers,

Jeff

From: BIER <[email-masked]> on behalf of "Dolganow, Andrew (Nokia - SG/Singapore)" <[email-masked]>
Date: Tuesday, January 23, 2018 at 20:56
To: Tony Przygienda <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Bier] BIER rechartering

Tony,

Andrew

 

_______________________________________________ BIER mailing list [email-masked] https://www.ietf.org/mailman/listinfo/bier

---

From: Tony Przygienda <[email-masked]>
Date: Tue, 23 Jan 2018 21:27:53 -0800

Hey Mr A,  I see 2 separate points here

1) if we talk "let's do something for v6 no silicon BIER forwarding" that's
one charter point & I think it's fine
2) if we talk about "let's talk about BIERoANYTHING as long it's 1-hop fwd'
paradigm" then I'm fine with adding that as well albeit I admit I think
with Ether & MPLS we have practical cases I see licked for some foreseable
future (maybe the famous penultimate words ;-)

-- tony

On Tue, Jan 23, 2018 at 8:56 PM, Dolganow, Andrew (Nokia - SG/Singapore) <
[email-masked]> wrote:

> Tony,
>
>
>
> This is discussion on charter not individual draft. We did have some good
> discussion on the draft below as reflected by minutes. My comment is that
> the charter as proposed limits potential solutions unnecessarily. I propose
> we remove trhe limiting condition “Such functionality may focus on
> assuming software or slow-path support first” from the charter.
>
>
>
> Andrew
>
>
>
> *From: *Tony Przygienda <[email-masked]>
> *Date: *Wednesday, January 24, 2018 at 12:00 PM
> *To: *Andrew Dolganow <[email-masked]>
> *Cc: *Alia Atlas <[email-masked]>, "[email-masked]" <[email-masked]>
> *Subject: *Re: [Bier] BIER rechartering
>
>
>
>
>
>
>

---

From: "Dolganow, Andrew (Nokia - SG/Singapore)" <[email-masked]>
Date: Wed, 24 Jan 2018 06:16:30 +0000

Tony,

Sure, all I want to do is not to preclude or limit solutions, as long as we do that and capture the work without that I am ok.

Andrew

Date: Wednesday, January 24, 2018 at 4:28 PM

1) if we talk "let's do something for v6 no silicon BIER forwarding" that's one charter point & I think it's fine
2) if we talk about "let's talk about BIERoANYTHING as long it's 1-hop fwd' paradigm" then I'm fine with adding that as well albeit I admit I think with Ether & MPLS we have practical cases I see licked for some foreseable future (maybe the famous penultimate words ;-)
-- tony

On Tue, Jan 23, 2018 at 8:56 PM, Dolganow, Andrew (Nokia - SG/Singapore) <[email-masked]<mailto:[email-masked]>> wrote:
Tony,

Andrew

From: Tony Przygienda <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, January 24, 2018 at 12:00 PM
To: Andrew Dolganow <[email-masked]<mailto:[email-masked]>>
Cc: Alia Atlas <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Bier] BIER rechartering

---

From: Xiejingrong <[email-masked]>
Date: Wed, 24 Jan 2018 07:47:55 +0000

Saying about limit ourselves or limit solutions, I have something to express.
Although BIER itself need no tree-building, it either not limit using EXIST tree-building. Right ?

AS RFC8279 said:
"Alternatively, one could deploy a routing underlay that creates a multicast-specific tree of some sort. "
If we limit or prohibit using existing tree-building, then how should we understand the above description ?
if not, then as raised in <draft-xie-bier-mvpn-mpls-p2mp>, we WG need to coordinate with MPLS-WG on extensions to bring up BIER-related information. not only [on the associated MPLS-based OAM mechanisms].

I would appreciate for our respectable WG chairs, Area Directors, and Authors to clarify that:
Through every BIER WG draft have a description of BIER [not require a tree-building protocol] in its abstract, but it is not a limit to ourselves, to use existing tree-building protocol as BIER underlay, to build BIER info in a TREE topology.

-- XieJingrong

From: BIER [mailto:[email-masked]] On Behalf Of Dolganow, Andrew (Nokia - SG/Singapore)
Sent: Wednesday, January 24, 2018 2:17 PM
To: Tony Przygienda <[email-masked]>
Cc: [email-masked]
Subject: Re: [Bier] BIER rechartering

Tony,

Andrew

Andrew

---

From: Xiejingrong <[email-masked]>
Date: Thu, 25 Jan 2018 02:06:52 +0000

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:[email-masked]] On Behalf Of Alia Atlas
Sent: Wednesday, January 24, 2018 7:12 AM
To: [email-masked]
Subject: [Bier] BIER rechartering

[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 ?
[XJR2]: MVPN using P2MP-based BIER, is also one way of apply BIER in MVPN. Acceptable or not ?

[XJR3]: P2MP-based BIER can use exist P2MP PMTU. It will be helpful. Acceptable or not ?

[XJR4]: How about BGP extensions as BIER underlay ? and how about RSVP-TE/MLDP extensions as BIER underlay ?

[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 ?

Thanks,
Alia

---

From: Xiejingrong <[email-masked]>
Date: Fri, 26 Jan 2018 01:03:48 +0000

Anybody in ?

A cup of coffee ?

And continue re-viewing of our nice BIER T-shirt ?

From: BIER [mailto:[email-masked]] On Behalf Of Xiejingrong
Sent: Thursday, January 25, 2018 10:07 AM
To: Alia Atlas <[email-masked]>; [email-masked]
Subject: Re: [Bier] BIER rechartering

Alia, Chars :

Detail comments in-line.

Regards.
XieJingrong

---

From: "Dolganow, Andrew (Nokia - SG/Singapore)" <[email-masked]>
Date: Fri, 26 Jan 2018 01:34:09 +0000

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 <[email-masked]> on behalf of Xiejingrong <[email-masked]>
Date: Thursday, January 25, 2018 at 10:07 AM
To: Alia Atlas <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Bier] BIER rechartering

Alia, Chars :

Detail comments in-line.

Regards.
XieJingrong

Thanks,
Alia

---

From: Xiejingrong <[email-masked]>
Date: Fri, 26 Jan 2018 01:44:17 +0000

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:[email-masked]]
Sent: Friday, January 26, 2018 9:34 AM
To: Xiejingrong <[email-masked]>
Cc: Alia Atlas <[email-masked]>; [email-masked]
Subject: Re: [Bier] BIER rechartering

Andrew

From: BIER <[email-masked]<mailto:[email-masked]>> on behalf of Xiejingrong <[email-masked]<mailto:[email-masked]>>
Date: Thursday, January 25, 2018 at 10:07 AM
To: Alia Atlas <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Bier] BIER rechartering

Alia, Chars :

Detail comments in-line.

Regards.
XieJingrong

From: BIER [mailto:[email-masked]] On Behalf Of Alia Atlas
Sent: Wednesday, January 24, 2018 7:12 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [Bier] BIER rechartering

Thanks,
Alia

---

From: Alia Atlas <[email-masked]>
Date: Thu, 25 Jan 2018 20:49:38 -0500

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 <[email-masked]> wrote:

> As been mentioned in RFC8279, "Alternatively, one could deploy a routing
> underlay that creates a multicast-specific tree of some sort.".
>
> *From:* Dolganow, Andrew (Nokia - SG/Singapore) [mailto:
> [email-masked]]
> *Sent:* Friday, January 26, 2018 9:34 AM
> *To:* Xiejingrong <[email-masked]>
> *Cc:* Alia Atlas <[email-masked]>; [email-masked]
>
> *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 <[email-masked]> on behalf of Xiejingrong <
> [email-masked]>
> *Date: *Thursday, January 25, 2018 at 10:07 AM
> *To: *Alia Atlas <[email-masked]>, "[email-masked]" <[email-masked]>
> What I am most concerned about is,  weather it is acceptable or not, of
> related solutions involving tree-building protocols ?
>
>
>
> *From:* BIER [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Alia Atlas
> *Sent:* Wednesday, January 24, 2018 7:12 AM
> *To:* [email-masked]
> *Subject:* [Bier] BIER rechartering
>
>
>
> [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 ?
>
> [XJR4]: How about BGP extensions as BIER underlay ? and how about
> RSVP-TE/MLDP extensions as BIER underlay ?
>
>
> [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 ?
>

---

From: "Dolganow, Andrew (Nokia - SG/Singapore)" <[email-masked]>
Date: Fri, 26 Jan 2018 01:54:54 +0000

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 <[email-masked]>
Date: Friday, January 26, 2018 at 9:49 AM
To: Xiejingrong <[email-masked]>
Cc: Andrew Dolganow <[email-masked]>, "[email-masked]" <[email-masked]>
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 <[email-masked]<mailto:[email-masked]>> wrote:

From: Dolganow, Andrew (Nokia - SG/Singapore) [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Friday, January 26, 2018 9:34 AM
To: Xiejingrong <[email-masked]<mailto:[email-masked]>>
Cc: Alia Atlas <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

Andrew

Alia, Chars :

Detail comments in-line.

Regards.
XieJingrong

Thanks,
Alia

---

From: Tony Przygienda <[email-masked]>
Date: Thu, 25 Jan 2018 17:56:22 -0800

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) <
[email-masked]> 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 <[email-masked]>
> *Date: *Friday, January 26, 2018 at 9:49 AM
> *To: *Xiejingrong <[email-masked]>
> *Cc: *Andrew Dolganow <[email-masked]>, "[email-masked]" <
> [email-masked]>
>

---

From: Xiejingrong <[email-masked]>
Date: Fri, 26 Jan 2018 02:38:24 +0000

OK.
I appreciate for WG having flexibility and consistency with its initial words in RFC8279.
I'd like to explorer in applicability of the BIER big bang and share in the WG.

Regards,
XieJingrong

From: Alia Atlas [mailto:[email-masked]]
Sent: Friday, January 26, 2018 9:50 AM
To: Xiejingrong <[email-masked]>
Cc: Dolganow, Andrew (Nokia - SG/Singapore) <[email-masked]>; [email-masked]
Subject: Re: [Bier] BIER rechartering

Regards,
Alia

Andrew

Alia, Chars :

Detail comments in-line.

Regards.
XieJingrong

Thanks,
Alia

---

From: Xiejingrong <[email-masked]>
Date: Fri, 26 Jan 2018 03:01:17 +0000

Thanks for both of your explanations.  And I totally agree:
1) BIER was kept extremely independent of signalling involved.
2) BIER does not create underlay protocols or bind to specific underlay protocols, but re-use independent protocols to create BIFTs.

Regards,
XieJingrong

From: Tony Przygienda [mailto:[email-masked]]
Sent: Friday, January 26, 2018 9:56 AM
To: Dolganow, Andrew (Nokia - SG/Singapore) <[email-masked]>
Cc: Alia Atlas <[email-masked]>; Xiejingrong <[email-masked]>; [email-masked]
Subject: Re: [Bier] BIER rechartering

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) <[email-masked]<mailto:[email-masked]>> wrote:

Andrew

From: Alia Atlas <[email-masked]<mailto:[email-masked]>>
Date: Friday, January 26, 2018 at 9:49 AM
To: Xiejingrong <[email-masked]<mailto:[email-masked]>>
Cc: Andrew Dolganow <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

Regards,
Alia

Andrew

Alia, Chars :

Detail comments in-line.

Regards.
XieJingrong

Thanks,
Alia

_______________________________________________
BIER mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bier