Subject: [Detnet] some reminders on charter

From: Lou Berger <[email-masked]>
Date: Wed, 17 Jan 2018 14:53:50 -0500

Some of the discussion leads me to want to remind the WG of a few things 
from our charter:

1) network size/scope.  We are not trying to solve the "Internet" or 
even the general multi-domain problem, but rather solutions for networks 
that are under a single administrative control or within a closed group 
of  administrative control.

2) encapsulation: We are chartered to define the encapsulation used by 
DetNet flows.   We are not expected to come up with new encapsulations, 
but rather how DetNet uses what exists today.  As a group, while we once 
discussed documenting this in terms of existing RFCs (e.g., PW, PWE3, 
EVPN), we have decided to define the encapsulation in a more independent 
form. This is fine, but doesn't change that we are expected to reuse 
encapsulations that exist today.

Note that use of MPLS (in any flavor including TE,  SR, and perhaps even 
SR-TE) and other L3 technologies such as PW and GRE by DetNet is in scope.

3) IP version: Our charter talks about using IP.  It doesn't include or 
preclude any specific version.  Certainly support IPv6 is required.  
Support for IPv4 (service or transport) is not out of scope per charter.

4) Topics that are out of scope: As a reminder, control plane is 
currently out of scope of our charter.  We certainly are expected to 
identify the information needed for flow establishment and control and 
be used by reservation protocols and YANG data models (which are in 
charter). This may include, for example, how one or more DetNet flows 
are mapped to MPLS (TE) LSPs, but does not include any LDP, RSVP-TE or 
SR-related control plane changes.  As a group, we may want to ask the 
IESG to revisit this, but I suggest that not consider or discuss this 
until we have a Data Plane defined and, perhaps, the rest of our 
deliverables largely completed.

While it is often constructive to brainstorm and consider what *might* 
be done, please consider our charter scope to help focus your proposals 
and discussions on what *should* be done in detnet.

Cheers,
Lou

---

From: "Andrew G. Malis" <[email-masked]>
Date: Wed, 17 Jan 2018 17:29:14 -0500

Lou,

> DetNet flows.   We are not expected to come up with new encapsulations, but
> rather how DetNet uses what exists today.  As a group, while we once

Given that PWs are in charter, Stewart and I as PALS chairs agree that
DETNET should be able to define a PW control word to optimize the solution
to the problem space, especially since it would still conform to figure 1
of RFC 4385.

Cheers,
Andy

---

From: Lou Berger <[email-masked]>
Date: Wed, 17 Jan 2018 18:02:22 -0500

Andy,

Just to be clear , pseudo wires are in Charter as an example. An equally 
valid example would have been evpn's encapsulation...

Lou

Liu

On January 17, 2018 5:30:13 PM "Andrew G. Malis" <[email-masked]> wrote:

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

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 18 Jan 2018 12:07:18 +0000

> deliverables largely completed.

If we develop a type of PW to carry DN, this restriction is ridiculous. 
PWs have control planes already and I would assume that we would try to 
reuse them via minor extensions.

If we sequence the work as suggested we simply delay the point where we 
have provided all the tools needed for deployment.

I would suggest that a more pragmatic contingency approach in which we 
focus on delivering what is right for the network operator given the 
knowledge we currently have is more appropriate.

- Stewart

---

From: Lou Berger <[email-masked]>
Date: Thu, 18 Jan 2018 09:29:00 -0500

> If we develop a type of PW to carry DN, this restriction is ridiculous.

Stewart,
	Part of the reason for a charter is to ensure that a WG doesn't try to
"boil the ocean" or in other words constrain the problem or solution
space to what can be achieved in a reasonable time.  In this case, the
WG will defer the discussion of control plane until we're ready to have
a recharter discussion. This does not stop the work from being proposed,
perhaps even in other WGs, which may even motivate a recharter discussion.

> reuse them via minor extensions.

Yes, and having a debate right now on LDP vs BGP/EVPN vs SR vs RSVP-TE
vs whatever won't help us close on our current set of deliverables.
Having discussion on reuse of encapsulation formats, forwarding
mechanisms (e.g., encap over IP/TSN, TE-LSPs, SR-TE, etc.), and YANG
models will.

> have provided all the tools needed for deployment.

individuals are welcome to sequence their work as they see fit, we are a
volunteer / contribution driven organization after all.   From a process
standpoint, it's a chairs job to help focus discussion on chartered
items and charter discussions. (Hence my message ;-)

> knowledge we currently have is more appropriate.

I'm not sure how our current work plan deviates from this, but if you
really want to bring control plane in as deliverable, please propose
specific charter changes and then we can discuss it in the WG and, if
there is adequate support, raise it with our AD and the IESG for
proposal.  Given where we are *right now* on meeting our milestones, I'd
be surprised if a charter change would be approved.  Once we have
resolved our major open issues and are just polishing our data plane and
yang model(s), my bet is we'd have a much easier time with getting our
scope widened -- if still appropriate.

Lou