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

[Alia Atlas <[e-mail]>]

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 <[e-mail]> wrote:

> 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.
>
>
> 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]
>
> _______________________________________________
> BIER mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bier
>
>
>
>
>