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

Hi Abdussalm

Thanks for the feedback.

A few questions with respect to your comments. In line prefaced with DA>

<snipped>

- I still think it needs to be proposed standard (even after receiving explanation from authors) because it includes a different field than RFC2516 which is the QoS field, this field is used in 5WE (5G wireline user plane encapsulation), furthermore the format-TYPE used in this encapsulation is 0x01 for upstream (while in the daft it mentions that this is for downstream, please explain how?), This encapsulation will be used in both PPPoE handling and in 5WE handling.
DA> I’m a bit confused.  The type field imported from RFC 2516 is set to 1 as it is in RFC 2516 irrespective of direction, and there is no reference to upstream or downstream associated with the field.  Could you clarify?

- For this VER=2, ....I suggest two encapsulation TYPE, one for UL and one for DL as mentioned in [TS38.415], the TYPE=0x00 is downstream with RQI and PPI, and the TYPE=0x01 is the upstream without, so the Session ID field replaces the field of spare in [TS38.415]. The PPI field is important for IPv4/IPv6 services as mentioned in [TS23501 ] for DL encapsulations.
DA> Actually paging is out of scope for wireline access as the RG is assumed to be either always on or failed/powered off and therefore unreachable by a page  (and we have not defined a wireline paging mechanism as a result).  So I’m a at a bit of a loss as to why we would require PPI in the downstream direction.  

- The document needs to give information on the session stage (ethertype=0x8864) related to DL 5WE (or downstream) and UL 5WE (upstream). It SHOULD  not be similar to the RFC2516 section 6.
DA> The document does not refer to section 6. And section 6 of RFC 2516  only refers to once the PPPoE session has been established and prior to any PPP procedures.  Our application does not use PPPoE or PPP procedures or respective state machines for session lifecycle maintenance. Perhaps if you proposed an edit to address where you think the similarity is inferred?

- The R bit and o bit should be changed for the UL encapsulations TO, RQI and PPI bit and adding PPP field.

sorry, the DL encapsulation need to add RQI, PPI, PPP filed, (TYPE=0x00).
DA> Well at the moment, the only difference between downstream and upstream handling is whether or not the RQI bit is ignored.  Explicitly identifying downstream and upstream packets protocol components would IMO add a lot of error cases that just would not happen.  As in what to do if a system thinks it is downstream and receives an upstream packet. On that basis I for one would prefer to go with the status quo.

This document should mention the sending method per fields in the format, as mentioned in page9  [TS38.415]. The handling of sending and receiving bits, in 5WE may be different than PPPoE, but if the same needs to be mentioned in this document.
DA> It was not our intention to duplicate QMP functionality, and in the context of what we are trying to do the header space simply does not exist, nor is a variable length header an option.  We can add text to suggest it is not supported.

Regarding to security consideration I don't think the protocol ID field is needed to be in the format, 
DA>  If I understand your comment correctly you are referring bytes 6&7 of the 5WE encap . I’m not sure about the relation to security considerations, I can only reiterate the rationale for adding it to the 5WE header. Any legacy device that snoops for DSCP or other IP fields needs to find the protocol ID field in the same location as for RFC 2516, the IDs used need to be from the PPP registry and subsequent IP information needs to be in the same place it would be for RFC 2516.  I understand this PID is an addition to the header that is not present in 2516, but 2516 explicitly encapsulated PPP and only PPP, and so imported all of the associated session management and configuration; LCP, NCPs etc.. We simply want the PID in the same place and using the same registry without an obligation to fully conform to RFC 1661 etc. so explicitly included it as part of the encap.

also the security section should mention the security architecture for 5WE, which may be by referencing TS33.501.
DA> I will add the reference.

I hope this helps

Cheers
Dave

On Fri, Jan 22, 2021 at 4:53 PM The IESG <mailto:iesg-secretary@ietf.org> 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
mailto:last-call@ietf.org mailing lists by 2021-02-05. Exceptionally, comments may
be sent to mailto:iesg@ietf.org 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/

_______________________________________________
IETF-Announce mailing list
mailto:IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce