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

[Toerless Eckert <[e-mail]>]

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

On Thu, Feb 22, 2018 at 02:54:22PM -0500, Alia Atlas wrote:
> 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
> 
> On Wed, Feb 21, 2018 at 8:08 PM, Deborah Brungard <[e-mail]> wrote:
> 
> > 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."
> >
> >
> >
> >
> > _______________________________________________
> > BIER mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/bier
> >

-- 
---
[e-mail]