Subject: [bcause] Discussing the Charter

From: Donald Eastlake <[email-masked]>
Date: Thu, 21 Mar 2019 19:46:03 -0400

Hi,

I think that what we should be discussing on the list now is the
Charter (see https://mailarchive.ietf.org/arch/msg/bcause/WpXD6jUlEql8Xqzud7pNo-9-Jww).
It seems premature to try making decisions the WG should be making
after it has been Chartered.

I think the draft Charter is reasonably short, simple, and clear, all
of which are good things and that it has about the right scope.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 1424 Pro Shop Court, Davenport, FL 33896 USA
 [email-masked]

---

From: Mach Chen <[email-masked]>
Date: Fri, 22 Mar 2019 06:07:37 +0000

Hi, 

Overall, the current charter text looks good to me.

I have one comment regarding the last sentence of the first paragraph:

"CUPS requires protocols for communication between CP and UP instances: from the CP to the UP to create and manage subscriber state instances and from the UP to the CP to handle relevant solicited or unsolicited events."

The latter part of the sentence says "... from the UP to the CP to handle relevant solicited or unsolicited events.", the events should be handled by the CP, not the CUPS, CUPS is just used to transport the events. At the same time, besides the events, there may be more information to be transported from UP to CP, for example, UP states (e.g., interface/slot states), statistics, etc.

Thus, I may suggest to change this sentence to:

"CUPS requires protocols for communication between CP and UP instances: from the CP to the UP to create and manage subscriber state instances and from the UP to the CP to report relevant solicited or unsolicited events, states, and statistics. "

Best regards,
Mach

> -----Original Message-----
> From: bcause [mailto:[email-masked]] On Behalf Of Donald Eastlake
> Sent: Friday, March 22, 2019 7:46 AM
> To: [email-masked]
> Subject: [bcause] Discussing the Charter
> 
> Hi,
> 
> I think that what we should be discussing on the list now is the Charter (see
> https://mailarchive.ietf.org/arch/msg/bcause/WpXD6jUlEql8Xqzud7pNo-9-Jww
> ).
> It seems premature to try making decisions the WG should be making after it
> has been Chartered.
> 
> I think the draft Charter is reasonably short, simple, and clear, all of which are
> good things and that it has about the right scope.
> 
> Thanks,
> Donald
>  1424 Pro Shop Court, Davenport, FL 33896 USA  [email-masked]
> 
> --
> bcause mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bcause

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 22 Mar 2019 08:04:07 +0100

The charter as written simply assumes that there is a need for a new 
protocol, and that we know what the constraints are the protocol should 
meet.
The former is very important.

As the problem description is written, for example, it sounds like 
almsot exactly the problem ANCP was designed for.
If you spin it slightly differently, as has been discussed on the list, 
it is almost exactly what 3GPP's PFCP is designed for.

It is not at all clear that a new protocol is needed, mush less a new 
working group to design a new protocol.

Yours,
Joel

---

From: Mach Chen <[email-masked]>
Date: Fri, 22 Mar 2019 08:08:56 +0000

Hi Joel,

My reading of the charter may be a bit different from yours.

The current charter just says: "...specify communication protocol(s) between the CP and UP of a BNG...", my interpretation on this is that: it can be either new protocol (s) or protocol extensions on existing protocol(s). May be we could make this more explicit.

How about:
"... specify new protocol(s) or extensions on existing protocol(s) between the CP and UP of a BNG..."

How do you think?

Best regards,
Mach

> From: bcause [mailto:[email-masked]] On Behalf Of Joel M. Halpern
> Sent: Friday, March 22, 2019 3:04 PM
> To: Donald Eastlake <[email-masked]>; [email-masked]
> Subject: Re: [bcause] Discussing the Charter
> 
> The charter as written simply assumes that there is a need for a new protocol,
> and that we know what the constraints are the protocol should meet.
> As the problem description is written, for example, it sounds like almsot exactly
> the problem ANCP was designed for.
> If you spin it slightly differently, as has been discussed on the list, it is almost
> exactly what 3GPP's PFCP is designed for.
> 
> It is not at all clear that a new protocol is needed, mush less a new working
> group to design a new protocol.
> 
> Yours,
> Joel
> 
> > Charter (see

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 22 Mar 2019 09:34:53 +0100

There are several different dimensions hidden under here.

First, there seems to be an assumption taht the IETF needs to do 
something here.  That is not at all obvious.  It is a chartering 
question, and usually the charter does deal with aspects of this question.

Second off, there are a number of different implicit assumptions about 
what problem needs to be solved.  In the discusions this week at the BBF 
starting the work on this topic, we realized that which functions needed 
to be supported depended not only on what offerings the BNG was trying 
to deliver, but also on what kinds of deployments one assumed (for 
example, is routing colocated with the control function or is it 
colocated with the forwarding function.)  Lack of clarity on this makes 
it very hard to agree on what kinds of behaviors one needs.  Another 
example assumption is about what kinds of coexistence matter.  I found 
it quite distressing when folks on this list told an operator that their 
needed deployment was not something they need.  Sorry, they need the 
hybrid access.

Thirdly, I would prefer to see an explicit s
priority for using existing protocol work, ratherfor developing new 
work.  Given that there are existing drafts taht have been promoted for 
some time that simply assume that a new protocol is needed, I think it 
is important to recognize that we as a community have not agreed to that.

So no, your simple rephrasing does not go far enough to address my 
concerns.

Yours,
Joel

---

From: Mach Chen <[email-masked]>
Date: Fri, 22 Mar 2019 09:04:23 +0000

Hi Joel,

Regarding BNG disaggregation, BBF TR-384 defines two options, my understanding of the current charter is that it only covers the option 1, this is the one that has common agreement and urgent requirement IMHO. As option 2, there were some discussions about whether it should be included. I personally think more research and analysis needed. My personal suggestion is to charter this as a two-phase work. The first phase focuses on option 1, and leave option 2 for further study. If we (here, the "we" refers to all the bcausers) could make an agreement on think, some text can be added to the charter to clarify this.

Best regards,
Mach

> From: Joel M. Halpern [mailto:[email-masked]]
> Sent: Friday, March 22, 2019 4:35 PM
> To: Mach Chen <[email-masked]>; [email-masked]
> First, there seems to be an assumption taht the IETF needs to do something
> here.  That is not at all obvious.  It is a chartering question, and usually the
> charter does deal with aspects of this question.
> 
> Second off, there are a number of different implicit assumptions about what
> problem needs to be solved.  In the discusions this week at the BBF starting
> the work on this topic, we realized that which functions needed to be
> supported depended not only on what offerings the BNG was trying to deliver,
> but also on what kinds of deployments one assumed (for example, is routing
> colocated with the control function or is it colocated with the forwarding
> function.)  Lack of clarity on this makes it very hard to agree on what kinds of
> behaviors one needs.  Another example assumption is about what kinds of
> coexistence matter.  I found it quite distressing when folks on this list told an
> operator that their needed deployment was not something they need.  Sorry,
> they need the hybrid access.
> 
> Thirdly, I would prefer to see an explicit s priority for using existing protocol
> work, ratherfor developing new work.  Given that there are existing drafts
> taht have been promoted for some time that simply assume that a new
> protocol is needed, I think it is important to recognize that we as a community
> have not agreed to that.
> 
> So no, your simple rephrasing does not go far enough to address my concerns.
> 
> Yours,
> Joel
> 
> > The current charter just says: "...specify communication protocol(s) between
> the CP and UP of a BNG...", my interpretation on this is that: it can be either
> new protocol (s) or protocol extensions on existing protocol(s). May be we
> could make this more explicit.
> >
> > How about:
> >> If you spin it slightly differently, as has been discussed on the
> >> list, it is almost exactly what 3GPP's PFCP is designed for.
> >>
> >>> I think the draft Charter is reasonably short, simple, and clear,
> >>> all of which are good things and that it has about the right scope.
> >>>
> >>> Thanks,
> >>> Donald

---

From: Yu Tianpeng <[email-masked]>
Date: Fri, 22 Mar 2019 09:12:47 +0000

Hi Joel,
"for
example, is routing colocated with the control function or is it
colocated with the forwarding function"

Good point. Glad to see more people starting realize/thinking of that.
Now the BNG devices also need to handle  to routing and it actually still
need to maintain fib of both subscribers/ip pools and internet. And these
fib still need to be maintained in UP. Also potential requirement also need
to consider:
1. the recursive of such rib/fib to different segment routing policies or
network slices that working on other WGs.
2. Service chaining e.g. NAT DPI (refer to Bess WG)

I want to emphasize that we should not develop just an "openflow" UP
without considering important concepts that already deployed widely in
existing BNG even.

And also be aware that BNG is not a dedicated device in current live now.
It has been fused with POP, PE of business services (leased lines), mobile
backhul, CDN edge, also having DC closing by. I would ask: is an open flow
like protocol ideal to cover or coexisting with other protocols e.g. MPBGP?
Are we simplifying network or making network more complicated by
introducing more protocols.

I would say if we starting defining (or reuse) protocol without a full
understanding of requirement, it then will be real dead-end.  I haven't
seen an existing protocol covers the routing requirement of UP not just
definition on tables of subscribers.

Thanks,
Tim

On Fri, 22 Mar 2019, 08:35 Joel M. Halpern, <[email-masked]> wrote:

> > The current charter just says: "...specify communication protocol(s)
> between the CP and UP of a BNG...", my interpretation on this is that: it
> can be either new protocol (s) or protocol extensions on existing
> protocol(s). May be we could make this more explicit.
> >
> > How about:
> protocol,
> it is almost

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 22 Mar 2019 11:26:24 +0100

If we intend to use the TR-384 distinctions, and to only deal with 
certain cases from that set, then we need to say so.  The charter 
currently does not say that.

Yours,
Joel