Subject: [Bier] Deborah Brungard's Block on charter-ietf-bier-01-06: (with BLOCK)

From: Deborah Brungard <[email-masked]>
Date: Wed, 21 Feb 2018 17:08:32 -0800

Deborah Brungard has entered the following ballot position for
charter-ietf-bier-01-06: Block

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-bier/

----------------------------------------------------------------------
BLOCK:
----------------------------------------------------------------------

While a Discuss, this should be simple to address as I think it's a bit of a misnomer
which Alvaro has already noted.
About:
"8) BIER Traffic Engineering: Definition of an architecture, and
   specification of the associated technology, for a BIER-based
   mechanism to support traffic engineering."

Looking at the wg draft (which it seems this new charter item is based on),
the draft says:
"It does support traffic engineering by explicit hop-by-hop forwarding"
and "it is more similar to SR than RSVP-TE".

So it is not TE, it is explicit forwarding. As Alvaro noted, this should not
be identified in the charter as TE. I don't see any need for this new item to
be in the charter (as Alvaro noted).

This is a Discuss because if this is not a simple misnomer, then this work
clashes with TEAS. TEAS is chartered and responsible for "Traffic-engineering
architectures for generic applicability across packet and non-packet networks.
This includes both networks that include the use of PCE and those that do not."

---

From: Alia Atlas <[email-masked]>
Date: Wed, 21 Feb 2018 20:39:50 -0500

Deborah,

This is just the forwarding plane aspects of how to reuse the BIFT
construct.  Toerless has already reached out to TEAS for talking about it
and looking at control plane.

I agree that this clarification is needed in the charter!

Any suggestions for text?

Thanks,
Alia

On Feb 21, 2018 8:08 PM, "Deborah Brungard" <[email-masked]> wrote:

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

---

From: Antoni Przygienda <[email-masked]>
Date: Thu, 22 Feb 2018 01:33:44 +0000

In fact, quite interesting observation and thanks for putting the finger on it, Deborah. 

To throw a further related observation in, I just quote something recently put out that came from discussions with people looking @ applicability of BIER in new service planning roadmaps. 

“
   Suggested traffic engineering architecture for BIER
   [I-D.ietf-bier-te-arch] offers a very limited scalability only.  It
   would be desirable to subject BIER to proper TE point-to-multipoint
   computation.  Albeit BIER results can be shaped with multi topology
   again, a computation including TE metrics and constraints and maybe
   even multicast specific metrics like node fanouts could introduce a
   distributed, scalable TE for BIER.  Such a computation could be
   performed in a centralized fashion of course and resulting BIFTs
   downloaded to routers as well but such an approach is outside the
   scope of this document.
“

I am agnostic whether this really means something like RSVP-TE computation albeit I observe that BIER being inherently bi-directional mp2mp technology may seem to precondition something different computation-wise @ first look. 

I don’t even say it is practically achievable and I surely don’t say who/which group should/may be chartered to do anything like that or even be chartered to do it at all. 

It is just that BIER as great it is right now awakens desires to TE it ;-) which in a sense goes counter its minimum-state-in-network possibly and it may merit discussing it out. 

As long it was an experimental duckling things weren’t that important, if it moves STD now I think contemplating where it should and is allowed to go if it’s able to is worth doing …  

Thanks

--- tony

<[email-masked]> spake:

    
    The document, along with other ballot positions, can be found here:
    https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_charter-2Dietf-2Dbier_&d=DwICaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=maKXfKzgRTpiLitqHnJiww&m=a2Y6gmdaqrJECBifS1ZwCJhkY3fp1vEOFkB28zxrrjI&s=m-IDoUf3yXpmLJJQSMRR8c_rg8lxBCcI96ZaC-mVO6E&e=

---

From: Alia Atlas <[email-masked]>
Date: Thu, 22 Feb 2018 14:54:22 -0500

Hi Deborah,

How about instead of:

OLD
  8) BIER Traffic Engineering: Definition of an architecture, and
       specification of the associated technology, for a BIER-based
       mechanism to support traffic engineering."

NEW
  9) Forwarding Plane Mechanisms for BIER Traffic Engineering: definition of
      how the new BIER forwarding plane structures (e.g. BIFT) can be used
to
      support engineered multicast trees.  No control-plane work will be
done in BIER-WG.

and the WGs to coordinate with will have added:

 * teas on control-plane mechnisms to use BIER-TE forwarding mechanisms.

Regards,
Alia

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 22 Feb 2018 22:51:35 +0100

Thanks, Alia, Deborah:

Yes, BIER-TE is about the explicit traffic steering in the forwarding plane,
Using TE in the name was just the easiest marketing name to make
readers understand it, even if some other variation of the name
might have been more precise.

Wrt to the proposed "No control-plane work will be done in BIER-WG"

What is the logic of selecting a working group for e.g.: IGP extensions
that we may want to have for BIER-TE ? I see ISIS/OSPF extensions for
BIER which have been done in BIER, not in those IGPs WGs (or LSR upcoming).

I had already reached out to PCE WG to explain BIER-TE, will
also reach out to TEAS, so definitely interested to figure out what
the best WG for each part of the solution. I am only worried that
the charter statement would preclude decisions e.g.: in TEAS like
"this part of signaling, please do it in BIER WG".

Just paranoid we're not going to be out of options if TEAS
decides something like that.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Alia Atlas <[email-masked]>
Date: Thu, 22 Feb 2018 17:35:09 -0500

Hi Toerless,

TEAS can also do OSPF/ISIS signaling work for TE, just like BIER can for
BIER.

We can revisit if necessary - but this seems like the cleanest split at
this time.

Regards,
Alia

On Thu, Feb 22, 2018 at 4:51 PM, Toerless Eckert <[email-masked]> wrote:

> > > While a Discuss, this should be simple to address as I think it's a
> bit of
> > > a misnomer
> > > So it is not TE, it is explicit forwarding. As Alvaro noted, this
> should
> > > not
> > > be identified in the charter as TE. I don't see any need for this new
> item
> > > to
> > > This includes both networks that include the use of PCE and those that
> do
> > > not."
> > >
> > >
> > >
> > >

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Fri, 23 Feb 2018 00:20:40 +0000

Hi Alia,

This looks good- just slight tweak:
 * teas on control-plane mechnisms to use BIER-TE forwarding mechanisms.
/s/
 * teas on architecture and control-plane mechanisms to use BIER-TE forwarding mechanisms.

Thanks-
Deborah

From: Alia Atlas [mailto:[email-masked]]
Sent: Thursday, February 22, 2018 2:54 PM
To: BRUNGARD, DEBORAH A <[email-masked]>; Toerless Eckert <[email-masked]>
Cc: The IESG <[email-masked]>; BIER WG <[email-masked]>; [email-masked]
Subject: Re: [Bier] Deborah Brungard's Block on charter-ietf-bier-01-06: (with BLOCK)

Hi Deborah,

How about instead of:

OLD

NEW
  9) Forwarding Plane Mechanisms for BIER Traffic Engineering: definition of
      how the new BIER forwarding plane structures (e.g. BIFT) can be used to
      support engineered multicast trees.  No control-plane work will be done in BIER-WG.

Regards,
Alia

On Wed, Feb 21, 2018 at 8:08 PM, Deborah Brungard <[email-masked]<mailto:[email-masked]>> wrote:
Deborah Brungard has entered the following ballot position for
charter-ietf-bier-01-06: Block

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-bier/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_charter-2Dietf-2Dbier_&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=SooQxG2cIgm-ictCU8wcQwGTx3k2rpMjyGxaHo_1c8Q&s=kSYF29AsPrYX28KSEy12rHimJJC6ACzJyRTtMzjdEs4&e=>

_______________________________________________
BIER mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bier<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=SooQxG2cIgm-ictCU8wcQwGTx3k2rpMjyGxaHo_1c8Q&s=MB4vhOEnedbfqsLsX6vVSCxkIAXrFHi-fF-mYJyT4ZU&e=>

---

From: Alia Atlas <[email-masked]>
Date: Thu, 22 Feb 2018 19:39:20 -0500

Hi Deborah,

Sure - that may end up making Toerless split his draft, but if TEAS is
interested
and willing, that's fine.

I don't know if it's so much traffic-engineering as
centralized/controller-based, but
that falls closer to TEAS or PCE anyway.

I'll update the charter and send you a ping.

Thanks,
Alia

On Thu, Feb 22, 2018 at 7:20 PM, BRUNGARD, DEBORAH A <[email-masked]> wrote:

> *From:* Alia Atlas [mailto:[email-masked]]
> *Sent:* Thursday, February 22, 2018 2:54 PM
> *To:* BRUNGARD, DEBORAH A <[email-masked]>; Toerless Eckert <[email-masked]
> >
> *Cc:* The IESG <[email-masked]>; BIER WG <[email-masked]>;
> [email-masked]
> *Subject:* Re: [Bier] Deborah Brungard's Block on
> charter-ietf-bier-01-06: (with BLOCK)
>
>
>
> Hi Deborah,
>
>
>
> How about instead of:
>
>
>
> OLD
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_charter-2Dietf-2Dbier_&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=SooQxG2cIgm-ictCU8wcQwGTx3k2rpMjyGxaHo_1c8Q&s=kSYF29AsPrYX28KSEy12rHimJJC6ACzJyRTtMzjdEs4&e=>
>
>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=SooQxG2cIgm-ictCU8wcQwGTx3k2rpMjyGxaHo_1c8Q&s=MB4vhOEnedbfqsLsX6vVSCxkIAXrFHi-fF-mYJyT4ZU&e=>
>
>
>

---

From: Xiejingrong <[email-masked]>
Date: Fri, 23 Feb 2018 01:19:04 +0000

Hi folks,

I still have two minor questions (for re-charter rev 01-10):

1.       pce on extensions to program BIER forwarding on the BFIRs
Q: BFIRs or BFRs ? IMO, BIER forwarding exist in every BFR, while BIER overlay exist in BFIR.  I would like @Andrew to clarify.

2.       teas on architecture and control-plane mechanisms to use BIER-TE forwarding mechanisms.
Q: IMO, control-plane rarely use a forwarding mechanisms, but support to build a forwarding table for data-plane.
     So how about this: teas on architecture and control-plane mechanisms to build/support BIER-TE forwarding mechanisms.

Thanks,
XieJingrong

From: BIER [mailto:[email-masked]] On Behalf Of Alia Atlas
Sent: Friday, February 23, 2018 8:39 AM
To: BRUNGARD, DEBORAH A <[email-masked]>
Cc: BIER WG <[email-masked]>; Toerless Eckert <[email-masked]>; The IESG <[email-masked]>; [email-masked]
Subject: Re: [Bier] Deborah Brungard's Block on charter-ietf-bier-01-06: (with BLOCK)

Hi Deborah,

Sure - that may end up making Toerless split his draft, but if TEAS is interested
and willing, that's fine.

I don't know if it's so much traffic-engineering as centralized/controller-based, but
that falls closer to TEAS or PCE anyway.

Thanks,
Alia

On Thu, Feb 22, 2018 at 7:20 PM, BRUNGARD, DEBORAH A <[email-masked]<mailto:[email-masked]>> wrote:
Hi Alia,

Thanks-
Deborah

From: Alia Atlas [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, February 22, 2018 2:54 PM
To: BRUNGARD, DEBORAH A <[email-masked]<mailto:[email-masked]>>; Toerless Eckert <[email-masked]<mailto:[email-masked]>>
Cc: The IESG <[email-masked]<mailto:[email-masked]>>; BIER WG <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Bier] Deborah Brungard's Block on charter-ietf-bier-01-06: (with BLOCK)

Hi Deborah,

How about instead of:

OLD

NEW

Regards,
Alia

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 23 Feb 2018 03:03:38 +0100

The BIER-TE draft does not mention anything about routing, it is all based
on some entity such as an SDN/PCN controller programming the forwarding
plane entries. So no need to split up, any distributed routing protocol
based approach would equally be using the same interface. Just
wondering if we can let the WGs make a technical decision about where new
routing protocol draft extensions for BIER-TE would be worked on - instead
of making this as a charter decision.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: IJsbrand Wijnands <[email-masked]>
Date: Fri, 23 Feb 2018 10:32:50 +0100

Toerless,

> Wrt to the proposed "No control-plane work will be done in BIER-WG”

We probably should be a little more specific on what is meant with control plane. With BIER-TE there are two different levels of it. There is the Controller (PCE) control plane and (potentially) the underlay signalling. It is completely valid to use the IGP’s to distribute the BIER-TE MPLS Labels, and let the PCE calculate the paths. The current IGP drafts don’t distribute labels for BIER-TE, so similar drafts would have to be written. These are in scope of the BIER WG IMO.

Thx,

Ice.

---

From: Alia Atlas <[email-masked]>
Date: Fri, 23 Feb 2018 12:22:56 -0500

Ice & Toerless,

I do understand the desire to keep the OSPF & IS-IS extensions in BIER, but
if you think this is really
traffic-engineering, then the architecture and signaling fall under TEAS.
That WG can also do the
signaling work as easily if necessaray.

I'd strongly prefer not to delay the recharter for this aspect.

I know that the draft talks about this as directed forwarding, but from
what I read, I do see it as the
forwarding plane for BIER-TE.

Regards,
Alia

On Fri, Feb 23, 2018 at 4:32 AM, IJsbrand Wijnands <[email-masked]> wrote:

> We probably should be a little more specific on what is meant with control
> plane. With BIER-TE there are two different levels of it. There is the
> Controller (PCE) control plane and (potentially) the underlay signalling.
> It is completely valid to use the IGP’s to distribute the BIER-TE MPLS
> Labels, and let the PCE calculate the paths. The current IGP drafts don’t
> distribute labels for BIER-TE, so similar drafts would have to be written.
> These are in scope of the BIER WG IMO.
>
> Thx,
>
> Ice.
>
>

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 23 Feb 2018 19:59:36 +0100

Please go forward with your text, i think it is technically the most sound charter.

I was just trying to guess at possible non-technical issues between WGs and
keeping all the options open to find the best & most willing WG to do the work,
but its time to move on and get the charter out which is overall great.

Cheers & thanks for all the detailled work, Alia!

Toerless

On Fri, Feb 23, 2018 at 12:22:56PM -0500, Alia Atlas wrote:
> > Wrt to the proposed "No control-plane work will be done in BIER-WG???
> >
> >
> > It is completely valid to use the IGP???s to distribute the BIER-TE MPLS
> > Labels, and let the PCE calculate the paths. The current IGP drafts don???t

-- 
---
[email-masked]

---

From: Lou Berger <[email-masked]>
Date: Sat, 24 Feb 2018 09:29:08 -0500

Alia,

On 2/23/2018 12:22 PM, Alia Atlas wrote:
> Ice & Toerless,
>
> I do understand the desire to keep the OSPF & IS-IS extensions in BIER,
WRT isis and ospf extensions - in the past we worked hard to ensure that 
we weren't fragmenting the industry by developing overlapping solutions 
in different WGs.  Generally this meant doing the protocol work in OSPF 
and ISIS - we moved the TE extensions to TEAS(actually its predecessor) 
as the protocol WGs basically saw their job as transport and we had so 
many different technologies with overlapping needs that they didn't 
really want to spend their time working the details to developing  
unified / single mechanisms. (For ISIS, we basically did the definition 
in TEAS and ran the doc process in ISIS.)

I think the principle of having one place own the extensions to a 
protocol to ensure there are no overlapping extensions are defined still 
makes sense.  Perhaps rather than looking to TEAS, we should leverage 
the formation of LSR and say that *all* OSPF and ISIS extensions must go 
through that group.  Certainly other groups like BIER will identify 
required extensions and TEAS will continue to be the central clearing 
house for TE architecture and identification of switching technology 
generic extensions -- but LSR could run the process on all extensions 
and ensure we're not defining different mechanisms for distribution of 
the same information.

Lou

> but
>> distribute labels for BIER-TE, so similar drafts would have to be written