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

From: Donald Eastlake <[email-masked]>
Date: Fri, 22 Jan 2021 18:18:18 -0500

I support the approval and publication of this draft as an author
notwithstanding the IPR declaration concerning it. It needs to be
referenced by Broadband Forum (BBF) documents and an appropriate
registry needs to be set up to note the assignment of the relevant
code point.

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

On Fri, Jan 22, 2021 at 9:52 AM The IESG <[email-masked]> wrote:
>
>
> 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-07.txt> as Informational RFC
>
> This requests the start of a 2nd IETF Last Call with the intent of expressly calling
> attention to the IPR claim associated with this document
> (https://datatracker.ietf.org/ipr/3663/).
>
> 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 2021-02-05. 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 method
>    specified in this document supports the multiplexing of traffic for
>    multiple PDU sessions within a VLAN delineated access circuit,
>    permits legacy equipment in the data path to inspect certain packet
>    fields, carries 5G QoS information associated with the packet data,
>    and provides efficient encoding. It achieves this by specific points
>    of similarity with the RFC 2516 PPPoE data packet encapsulation.
>
>
>
>
> 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: Abdussalam Baryun <[email-masked]>
Date: Sat, 23 Jan 2021 08:24:13 +0200

Also, I recommend referencing [RFC7042], and I expect that this draft
should be proposed standard not informational,

Best Regards
AB

On Sat, Jan 23, 2021 at 1:19 AM Donald Eastlake <[email-masked]> wrote:

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

---

From: Donald Eastlake <[email-masked]>
Date: Sat, 23 Jan 2021 18:09:20 -0500

Hi AB,

> should be proposed standard not informational,

While I don't see a need to reference RFC 7042, it wouldn't hurt.

This is targeted to Informational because (1) the original RFC specifying
PPP over Ethernet (PPPoE, RFC 2516) was Informational and (2) the
functional parts of this specification were derived in the BBF, not the
IETF, but it needs to be an IETF stream document in order to create the
registry for PPPoE version numbers. When an externally derived
specification is published by the IETF, it is normally published as
informational.

Thanks,
Donald

Best Regards

---

From: Abdussalam Baryun <[email-masked]>
Date: Sun, 24 Jan 2021 10:28:22 +0200

Hi Donald,

In my opinion, this draft is not only for PPPoE, but it can be used by
IPoE, it mentions number of protocols to be used, the draft proposes a new
encapsulation format structure for 5G.

> While I don't see a need to reference RFC 7042, it wouldn't hurt.

ok, just I thought it will be better to refer to our documents while making
this draft go through our production.

> specification is published by the IETF, it is normally published as

Yes RFC2516 is specified for PPPoE, and is not specifying IPoE. 2516 does
not propose new field-format for identifying data of the internet, or has
any equipment in its data path to identify IP packets. This draft does
propose identifying IPv4/IPv6 datagram to 5G equipments. Therefore, I still
think the draft should propose for standard, what do you reply?

Best Regards
AB

---

From: Donald Eastlake <[email-masked]>
Date: Sun, 24 Jan 2021 17:38:49 -0500

On Sun, Jan 24, 2021 at 3:29 AM Abdussalam Baryun
<[email-masked]> wrote:
> Hi Donald,
>
> In my opinion, this draft is not only for PPPoE, but it can be used by IPoE, it mentions number of protocols to be used, the draft proposes a new encapsulation format structure for 5G.

- PPPoE and IPoE have accepted meanings for broadband network access.
This draft has nothing to do with IPoE.
       It is true that PPPoE can be used to carry a variety of
protocols, including IPv4 and IPv6. This is exactly the same for RFC
2516 and this draft.
       The protocol being carried by PPPoE is specified by the
PROTOCOL_ID field whose assigned values appear in
https://www.iana.org/assignments/ppp-numbers/ppp-numbers.xhtml#ppp-numbers-2
 You may be confused because in this draft the PROTOCOL_ID field is
explicitly shown in the figure at the top of page 5 while in RFC 2516
it just says "payload" but if you read Section 6 of RFC 2516, you will
see that "The PPPoE payload contains a PPP frame.  The frame begins
with the PPP Protocol-ID." Thus, both RFC 2516 and this draft have
exactly the same Protocol-ID field in exactly the same place in the
header although with different capitalization and punctuation.

- The draft does not specify "a new encapsulation format structure".
It uses the existing "encapsulation format structure" for PPPoE data
from RFC 2516, which is why it references RFC 2516 and increments the
version number, with the relatively minor change that it redefines the
contents of the CODE field which is unused in RFC 2516 for data
packets.

>> On Sat, Jan 23, 2021 at 1:25 AM Abdussalam Baryun <[email-masked]> wrote:
>>> ...
>> ...
> ...
>> This is targeted to Informational because (1) the original RFC specifying PPP over Ethernet (PPPoE, RFC 2516) was Informational and (2) the functional parts of this specification were derived in the BBF, not the IETF, but it needs to be an IETF stream document in order to create the registry for PPPoE version numbers. When an externally derived specification is published by the IETF, it is normally published as informational.
>
> Yes RFC2516 is specified for PPPoE, and is not specifying IPoE. 2516 does not propose new field-format for identifying data of the internet, or has any equipment in its data path to identify IP packets. This draft does propose identifying IPv4/IPv6 datagram to 5G equipments. Therefore, I still think the draft should propose for standard, what do you reply?

As I explained above, this draft and RFC 2516 have exactly the same
"field-format" for identifying the protocol type of the further
content of PPPoE data frame payloads and both can carry a variety of
protocols including IPv4 and IPv6. I have already explained why it
should be Informational, not Standards Track.

Thanks,
Donald

---

From: <[email-masked]>
Date: Mon, 25 Jan 2021 12:49:44 +0000

Dear IESG colleagues,

I support the publication of this draft.

I have no concerns regarding to the IPR claim associated with this draft.

Best regards,
Manuel 

-----Ursprüngliche Nachricht-----
Von: IETF-Announce <[email-masked]> Im Auftrag von The IESG
Gesendet: Freitag, 22. Januar 2021 15:53
An: IETF-Announce <[email-masked]>
Cc: [email-masked]; [email-masked]
Betreff: Last Call: <draft-allan-5g-fmc-encapsulation-07.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-07.txt> as Informational RFC

This requests the start of a 2nd IETF Last Call with the intent of expressly calling attention to the IPR claim associated with this document (https://datatracker.ietf.org/ipr/3663/).

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 2021-02-05. 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

_______________________________________________
IETF-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf-announce

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 25 Jan 2021 10:08:38 -0600

Hi Erik,

After Int area review, Bob Hinden last year made significant comments on
this draft last year.
I am not sure his comments have been incorporated so far. As far as I could
see, no.

Regards,
Behcet

On Mon, Jan 25, 2021 at 6:50 AM <[email-masked]> wrote:

> Betreff: Last Call: <draft-allan-5g-fmc-encapsulation-07.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)'
> This requests the start of a 2nd IETF Last Call with the intent of
> expressly calling attention to the IPR claim associated with this document (
> https://datatracker.ietf.org/ipr/3663/).
>
> 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 2021-02-05. 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: David Allan I <[email-masked]>
Date: Mon, 25 Jan 2021 16:24:14 +0000

HI Behcet

Bob’s primary comment related to a potential MTU issue because of the length field in the header, and suggested more work was required.

AFAIK this not is an issue with PPPoE and this draft does not change anything about that aspect of the protocol handling whatsoever. So we have an existence proof that it works without any additional work needed.

That is why Bob’s comment was not addressed.  If I have misunderstood, I hope Bob will disabuse me

I hope this helps
Dave

From: Behcet Sarikaya <[email-masked]>
Sent: Monday, January 25, 2021 8:09 AM
To: Erik Kline <[email-masked]>
Cc: [email-masked]; [email-masked]; Bob Hinden <[email-masked]>
Subject: Re: [Last-Call] Last Call: <draft-allan-5g-fmc-encapsulation-07.txt> (5G Wireless Wireline Convergence User Plane Encapsulation (5WE)) to Informational RFC

Hi Erik,

After Int area review, Bob Hinden last year made significant comments on this draft last year.
I am not sure his comments have been incorporated so far. As far as I could see, no.

Regards,
Behcet

On Mon, Jan 25, 2021 at 6:50 AM <[email-masked]<mailto:[email-masked]>> wrote:
Dear IESG colleagues,

Best regards,
Manuel

-----Ursprüngliche Nachricht-----
Von: IETF-Announce <[email-masked]<mailto:[email-masked]>> Im Auftrag von The IESG
Gesendet: Freitag, 22. Januar 2021 15:53
An: IETF-Announce <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Betreff: Last Call: <draft-allan-5g-fmc-encapsulation-07.txt> (5G Wireless Wireline Convergence User Plane Encapsulation (5WE)) to 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]<mailto:[email-masked]> mailing lists by 2021-02-05. Exceptionally, comments may be sent to [email-masked]<mailto:[email-masked]> instead. In either case, please retain the beginning of the Subject line to allow automated sorting.

Abstract

_______________________________________________
IETF-Announce mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ietf-announce

--
last-call mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/last-call