Subject: Re: [Last-Call] Last Call: <draft-allan-5g-fmc-encapsulation-04.txt> (5G Wireless Wireline Convergence User Plane Encapsulation (5WE)) to Informational RFC

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 12 Aug 2020 13:15:25 +0000

As someone who observed the discussion on this topic in Broadband Forum (BBF), I support IETF publication. The BBF work area spent significant time discussing and assessing multiple options to solve the problem. That led to selection of this solution. After selection, they spent time refining this solution before submitting to IETF. This draft documents a strong-consensus and well-vetted solution from the ISPs, equipment vendors, and others participating in architecting 5G Wireless-Wireline convergence.
Barbara

-----Original Message-----
From: [email-masked] <[email-masked]> 
Sent: Tuesday, 30 June 2020 12:18 AM
To: IETF-Announce <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Last Call: <draft-allan-5g-fmc-encapsulation-04.txt> (5G Wireless Wireline Convergence User Plane Encapsulation (5WE)) to Informational RFC

The IESG has received a request from an individual submitter to consider the following document: - '5G Wireless Wireline Convergence User Plane Encapsulation (5WE)'
  <draft-allan-5g-fmc-encapsulation-04.txt> as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the [email-masked] mailing lists by 2020-07-27. Exceptionally, comments may be sent to [email-masked] instead. In either case, please retain the beginning of the Subject line to allow automated sorting.

Abstract

   As part of providing wireline access to the 5G Core (5GC), deployed
   wireline networks carry user data between 5G residential gateways
   and the 5G Access Gateway Function (AGF). The encapsulation used
   needs to meet a variety of requirements including being able to
   multiplex the traffic of multiple PDU sessions within a VLAN
   delineated access circuit, to permit legacy equipment in the data
   path to snoop certain packet fields, to carry 5G QoS information
   associated with the data, and to be efficiently encoded. This memo
   specifies an encapsulation that meets these requirements.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-allan-5g-fmc-encapsulation/

The following IPR Declarations may be related to this I-D:

   https://datatracker.ietf.org/ipr/3663/

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 12 Aug 2020 10:14:34 -0400

The problem described in this draft is real.  The solution seems to me 
to be the best compromise available for how to address the issue.  I 
support publication of this document as an Informational RFC.

Yours,
Joel

---

From: Ron Bonica <[email-masked]>
Date: Wed, 12 Aug 2020 15:58:33 +0000

+1

Juniper Business Use Only

-----Original Message-----
From: last-call <[email-masked]> On Behalf Of Joel M. Halpern
Sent: Wednesday, August 12, 2020 10:15 AM
To: [email-masked]' <[email-masked]>; [email-masked]' <[email-masked]>
Cc: [email-masked]' <[email-masked]>
Subject: Re: [Last-Call] Last Call: <draft-allan-5g-fmc-encapsulation-04.txt> (5G Wireless Wireline Convergence User Plane Encapsulation (5WE)) to Informational RFC

[External Email. Be cautious of content]

The problem described in this draft is real.  The solution seems to me to be the best compromise available for how to address the issue.  I support publication of this document as an Informational RFC.

Yours,
Joel

> Subject: Last Call: <draft-allan-5g-fmc-encapsulation-04.txt> (5G 
> Wireless Wireline Convergence User Plane Encapsulation (5WE)) to 
> Informational RFC
>

--
last-call mailing list
[email-masked]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/last-call__;!!NEt6yMaO-gk!V57aUA3TZXAcWjihH_iStbx8WKtbVk6zS3K71BbhWuI6qk-126R0VCAHbQR1wluO$

---

From: Bob Hinden <[email-masked]>
Date: Wed, 12 Aug 2020 10:08:26 -0700

Doing a quick read I wonder if this document is missing some discussion of MTUs for each of the carried protocols?   It supports IPv4, Ethernet, and IPv6.   All of these have some MTU limitations that are different.

Also the way the length field is defined, I don’t think this supports a full IPv6 packet.   The IPv6 Payload Length field (16-bits) is the length of data after the IPv6 header.

Bob

> On Aug 12, 2020, at 8:58 AM, Ron Bonica <rbonica=[email-masked]> wrote:
> 
> +1
> 
> 
> 
> https://www.ietf.org/mailman/listinfo/last-call

---

From: John C Klensin <[email-masked]>
Date: Wed, 12 Aug 2020 14:04:10 -0400

--On Wednesday, 12 August, 2020 13:15 +0000 "STARK, BARBARA H"
<[email-masked]> wrote:

> As someone who observed the discussion on this topic in
> Broadband Forum (BBF), I support IETF publication. The BBF
> work area spent significant time discussing and assessing
> multiple options to solve the problem. That led to selection
> of this solution. After selection, they spent time refining
> this solution before submitting to IETF. This draft documents
> a strong-consensus and well-vetted solution from the ISPs,
> equipment vendors, and others participating in architecting 5G
> Wireless-Wireline convergence.

If this really represents the work and consensus of another body
(BBF -- and I have no reason to doubt that it does-- four
questions:

(1) Why not just publish it as the conclusions of the BBF for
the information of the community, e.g., via the ISE and not the
IETF?

(2) As a corollary, is the IETF being asked if it would be a
good idea to publish this or is technical endorsement (even if
not standards track handling) being sought?

(3) Or, if Bob Hinden is correct that the specification is still
in need of technical work, why isn't this document going through
some WG process to consider that work?  If the answer is that
publication is being sought without or despite technical
evaluations within the IETF, doesn't that bring us back to ISE
publication being more appropriate?

(4) Do any of the answers above change when the IPR disclosure
is read?   That IPR disclosure claims fairly clearly that this
is, at least in part, a proprietary technology dependent on
licensing and that such licensing, while promised to be
reasonable and non-discriminatory, may involve a licensing fee.

thanks,
    john

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 12 Aug 2020 15:28:06 -0400

Hi John,

> the information of the community, e.g., via the ISE and not the

There are various reasons for and against various different possible
paths for this document. Among the reasons for the path that has thus
far been chosen are the following: (1) It needs an IANA registry to be
created. An Independent submission cannot create a new IANA registry
(see https://datatracker.ietf.org/doc/draft-ise-iana-policy/ currently
in the AUTH48 state). (2) This is based on RFC 2516 which was an
AD-sponsored Informational draft so, as a default, it seemed to me
like a reasonable way to go. (3) I believe there is a clear consensus
in favor of publishing this document as an Informational RFC among the
interested members of the IETF community.

> not standards track handling) being sought?

Well, I suppose the IETF is being asked if it is good enough to get a
code point. But other than that, I don't think publication as
Informational constitutes a technical endorsement of the type you are
asking about. Presumably there is supposed to be a difference between
Informational, that to the first approximation just provides
Information, and BCP or Standard which clearly endorse something.

> publication being more appropriate?

Bob Hinden's suggestion that some discussion of MTU be added seems
reasonable and is the normal sort of thing that might come up during
an extended IETF Last Call on an AD-sponsored draft but, due to the
design constraints, I do not think technical "work" or technical
change is needed. As far as I can recall, I was not directly involved
in discussions with the sponsoring AD concerning their decision to go
the AD-sponsored route as opposed to some other path.

> reasonable and non-discriminatory, may involve a licensing fee.

The way people think about IPR differs in different areas of
technology. In the area in question, IPR is common so I don't think it
changes the above answers.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 33896 USA
 [email-masked]

---

From: John C Klensin <[email-masked]>
Date: Wed, 12 Aug 2020 18:00:32 -0400

Donald,

As I said, just questions, slightly reinforced by the IESG's
recent decision that, as I understand it, anything published in
the IETF stream requires evidence of IETF consensus - a stronger
condition, IMO, than "some people think this is a good idea and
no one else objects".  So the questions seemed worth asking.

  john

--On Wednesday, 12 August, 2020 15:28 -0400 Donald Eastlake
<[email-masked]> wrote:

>> > this solution before submitting to IETF. This draft
>> > documents a strong-consensus and well-vetted solution from
>> > the ISPs, equipment vendors, and others participating in
>> > architecting 5G Wireless-Wireline convergence.
>> 
>> If this really represents the work and consensus of another
>> body (BBF -- and I have no reason to doubt that it does-- four
>> questions:
>> 
>> the information of the community, e.g., via the ISE and not
>> the IETF?
> 
> There are various reasons for and against various different
> possible paths for this document. Among the reasons for the
> path that has thus far been chosen are the following: (1) It
> needs an IANA registry to be created. An Independent
> submission cannot create a new IANA registry (see
> https://datatracker.ietf.org/doc/draft-ise-iana-policy/
> currently in the AUTH48 state). (2) This is based on RFC 2516
> which was an AD-sponsored Informational draft so, as a
> default, it seemed to me like a reasonable way to go. (3) I
> believe there is a clear consensus in favor of publishing this
> document as an Informational RFC among the interested members
> of the IETF community.
> 
> Well, I suppose the IETF is being asked if it is good enough
> to get a code point. But other than that, I don't think
> publication as Informational constitutes a technical
> endorsement of the type you are asking about. Presumably there
> is supposed to be a difference between Informational, that to
> the first approximation just provides Information, and BCP or
> Standard which clearly endorse something.
> 
>> (3) Or, if Bob Hinden is correct that the specification is
>> still in need of technical work, why isn't this document
>> going through some WG process to consider that work?  If the
>> answer is that publication is being sought without or despite
>> technical evaluations within the IETF, doesn't that bring us
>> back to ISE publication being more appropriate?
> 
> Bob Hinden's suggestion that some discussion of MTU be added
> seems reasonable and is the normal sort of thing that might
> come up during an extended IETF Last Call on an AD-sponsored
> draft but, due to the design constraints, I do not think
> technical "work" or technical change is needed. As far as I
> can recall, I was not directly involved in discussions with
> the sponsoring AD concerning their decision to go the
> AD-sponsored route as opposed to some other path.
> 
> technology. In the area in question, IPR is common so I don't
> think it changes the above answers.
> 
> Thanks,
> Donald

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 14 Aug 2020 09:41:13 -0500

Hi all,

I read the document.

On Wed, Aug 12, 2020 at 12:08 PM Bob Hinden <[email-masked]> wrote:

> Doing a quick read I wonder if this document is missing some discussion of
> MTUs for each of the carried protocols?   It supports IPv4, Ethernet, and
> IPv6.   All of these have some MTU limitations that are different.
>
> Also the way the length field is defined, I don’t think this supports a
> full IPv6 packet.   The IPv6 Payload Length field (16-bits) is the length
> of data after the IPv6 header.
>
> Bob
>
>
I support Bob's comments, I think that such minor modifications are needed.

The document is a good read for those who want to get familiar with 5G
acronyms and what they mean from IETF point of view.
Support publication after this modification.

Behcet

> > To: [email-masked]' <[email-masked]>; '
> [email-masked]' <
> [email-masked]>
> > Subject: Re: [Last-Call] Last Call:
> <draft-allan-5g-fmc-encapsulation-04.txt> (5G Wireless Wireline Convergence
> User Plane Encapsulation (5WE)) to Informational RFC
> >
> >> The IESG has received a request from an individual submitter to
> consider the following document: - '5G Wireless Wireline Convergence User
> Plane Encapsulation (5WE)'
> >> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2020-07-27. Exceptionally, comments
> may be sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
> >>
> >> Abstract
> >>

---

From: Jeff Tantsura <[email-masked]>
Date: Fri, 14 Aug 2020 11:57:38 -0700

Support publication with the modification proposed.

Cheers,
Jeff
On Aug 14, 2020, 7:42 AM -0700, Behcet Sarikaya <[email-masked]>, wrote:
> > The document is a good read for those who want to get familiar with 5G acronyms and what they mean from IETF point of view.
> > > > last-call@ietf..org
> > > > last-call@ietf..org