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

[Toerless Eckert <[e-mail]>]

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



-- 
---
[e-mail]