On Sun, Jan 24, 2021 at 3:29 AM Abdussalam Baryun
<abdussalambaryun@xxxxxxxxx> 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 Sun, Jan 24, 2021 at 1:09 AM Donald Eastlake <d3e3e3@xxxxxxxxx> wrote:
>> Hi AB,
>>
>> On Sat, Jan 23, 2021 at 1:25 AM Abdussalam Baryun <abdussalambaryun@xxxxxxxxx> 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
===============================
Donald E. Eastlake 3rd +1-508-333-2270 (cell)
2386 Panoramic Circle, Apopka, FL 32703 USA
d3e3e3@xxxxxxxxx
> Best Regards
> AB
>>
>>
>> Thanks,
>> Donald
>> ===============================
>> Donald E. Eastlake 3rd +1-508-333-2270 (cell)
>> 2386 Panoramic Circle, Apopka, FL 32703 USA
>> d3e3e3@xxxxxxxxx
>>
>>> Best Regards
>>> AB
>>>
>>> On Sat, Jan 23, 2021 at 1:19 AM Donald Eastlake <d3e3e3@xxxxxxxxx> wrote:
>>>>
>>>> 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
>>>> d3e3e3@xxxxxxxxx
>>>>
>>>>
>>>> On Fri, Jan 22, 2021 at 9:52 AM The IESG <iesg-secretary@xxxxxxxx> 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
>>>> > last-call@xxxxxxxx mailing lists by 2021-02-05. Exceptionally, comments may
>>>> > be sent to iesg@xxxxxxxx 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/
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
