Re: [Tsv-art] Tsvart last call review of draft-allan-5g-fmc-encapsulation-04

[Donald Eastlake <[e-mail]>]

Fine with me.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   [phone] (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [e-mail]

On Tue, Jun 30, 2020 at 5:34 PM David Allan I
<[e-mail]> wrote:
>
> Hi Dave:
>
>
>
> I’m quite happy to incorporate your text into the next version along with my proposed change. I am presuming my co-authors have no issue with the change either.
>
>
>
> Rgds
>
> Dave
>
>
>
> From: Black, David <[e-mail]>
> Sent: Tuesday, June 30, 2020 1:38 PM
> To: David Allan I <[e-mail]>; [e-mail]
> Cc: [e-mail]; [e-mail]; Black, David <[e-mail]>
> Subject: RE: Tsvart last call review of draft-allan-5g-fmc-encapsulation-04
>
>
>
> Hi Dave,
>
>
>
> That’s headed in the right direction with a positive “glass half full” perspective – I’d also like to see some complementary “glass half empty” gentle discouragement.
>
>
>
> "This 5G specific repurposing of fields results in an encapsulation uniquely applicable to the requirements for the communication of PDU session traffic between the subscriber premises and the 5G system over wireline networks.  The 8 byte RFC 2516 data packet header is also the most frugal of the encapsulations that are currently supported by legacy access equipment that can also meet all the could be adapted to meet these requirements. "  This encapsulation is not suitable for other network environments, e.g., general use over the public Internet.
>
>
>
> Thanks, --David
>
>
>
> From: David Allan I <[e-mail]>
> Sent: Tuesday, June 30, 2020 4:12 PM
> To: Black, David; [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: RE: Tsvart last call review of draft-allan-5g-fmc-encapsulation-04
>
>
>
> [EXTERNAL EMAIL]
>
> HI Dave:
>
>
>
> I'm wondering if inserting a sentence at the start of the last paragraph in the introduction section would go far enough address your concern?
>
>
>
> "This 5G specific repurposing of fields results in an encapsulation uniquely applicable to the requirements for the communication of PDU session traffic between the subscriber premises and the 5G system over wireline networks.  The 8 byte RFC 2516 data packet header is also the most frugal of the encapsulations that are currently supported by legacy access equipment that can also meet all the could be adapted to meet these requirements. "
>
>
>
> That does not say it cannot be repurposed for other nefarious ends…. Nor is it a health warning. Just a narrower scoping.
>
>
>
> Thoughts?
>
> Dave
>
>
>
> -----Original Message-----
> From: David Black via Datatracker <[e-mail]>
> Sent: Tuesday, June 30, 2020 11:07 AM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: Tsvart last call review of draft-allan-5g-fmc-encapsulation-04
>
>
>
> Reviewer: David Black
>
> Review result: Ready with Issues
>
>
>
> This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information.
>
>
>
> When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC [e-mail] if you reply to or forward this review.
>
>
>
> This is well-written concise draft that defines a PPPoE encapsulation for carrying data between a 5G residential gateway and the associated 5G Access Gateway Function (AGF).  For reasons described in the draft, it addresses that scenario well.
>
>
>
> I have one minor concern with this draft, which is almost a nit.  The draft should have a stronger statement of applicability to indicate that the encapsulation applies only to the specific 5G usage envisioned, as that usage relies upon the network operator provisioning sufficient bandwidth and managing the network accordingly.  This encapsulation is not suitable for deployment over the public Internet in general or any network in which congestion is an important operational consideration.  This is because the encapsulation may carry non-congestion-responsive traffic, as further indicated by specific QFI values.  A detailed discussion of congestion is not necessary - clarification and focus of applicability of the encapsulation should suffice.
>
>
>
>
>
>