Re: [mpls] [Pals] Mail regarding draft-zzhang-tsvwg-generic-transport-functions

[Stewart Bryant <[e-mail]>]

First some comments on the draft itself.

SB> The draft needs to discuss RFC4623 and explain when this draft would be used in place of RFC4623

   Some functionalities (e.g. fragmentation/reassembly and Encapsulating
   Security Payload) provided by IPv6 can be viewed as independent of
   IPv6 or even IP entirely.  
SB> Specifically IPv6 does not support network fragmentation because it provides PMTUD and devolves the problem to host.
This document proposes to provide those
   functionalities at different layers (e.g., MPLS, BIER or even
   Ethernet) independent of IP.

SB> I think we need to understand why after all these years this is now needed.
SB> Although we have this in PW, I am not sure it is widely used.

1.  Introduction

   Consider an operator providing Ethernet services such as pseudowires,
SB> It is already provided for PWs. Now you can build a case for why you need something better, but you must build the case.

   VPLS or EVPN.  The Ethernet frames that a Provider Edge (PE) device
   receives from a Customer Edge (CE) device may have a larger size than
   the PE-PE path MTU (pMTU) in the provider network.  
SB> I think you need to build a more complete case that the following because correctly implemented IPv6 will not send a frame that is too large because PMTUD and host fragmentation or transport fragmantation will prevent that.  IPv4 supports fragmentation.
SB> So that begs the question of what these packets are?

   This could be
   because

   1.  the provider network is built upon virtual connections (e.g.
       pseudowires) provided by another infrastructure provider, or

   2.  the customer network uses jumbo frames while the provider network
       does not, or

   3.  the provider-side overhead for transporting customers packets
       across the network pushes past the pMTU.

   In any case, the provider simply cannot require its customers to
   change their MTU.
SB> Don’t they change it automatically for most protocols?

   To get those large frames across the provider network, currently the
   only workaround is to encapsulate the frames in IP (with or without
   GRE) and then fragment the IP packets.  
SB> Again I think we need a bigger discussion of what those packets are.

   Even if MPLS is used for
   service delimiting, IP is used for transporation (MPLS over IP/GRE).
   This may not be desirable in certain deployment scenarios, where MPLS
   is the preferred transport or IP encapsulation overhead is deemed
   excessive.

SB> Again, I think we need more detail to justify this.


Zhang, et al.              Expires May 5, 2021                  [Page 2]

Internet-Draft         Generic Transport Functions         November 2020


   IPv6 fragmentation and reassembly are based on the IPv6 Fragmentation
   header below [RFC8200]:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Next Header  |   Reserved    |      Fragment Offset    |Res|M|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Identification                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 1: IPv6 Fragmentation Header

   This document proposes reusing this header in non-IP contexts, since
   the fragmentation/reassembly function is actually independent of IPv6
   except the following aspects:

   o  The fragment header is identified as such by the "previous"
      header.

   o  The "Next Header" value is from the "Internet Protocol Numbers"
      registry.

   o  The "Identification" value is unique in the (source, destination)
      context provided by the IPv6 header
SB> Which of course MPLS does not provide.

   The "Identification" field, in conjunction with the IPv6 source and
   destination identifies fragments of the original packet, for the
   purpose of reassembly.

   Therefore, the fragmentation/reassembly function can be applied at
   other layers as long as a) the fragment header is identified as such;
   and b) the context for packet identification is provided.  Examples
   of such layers include MPLS, BIER, and Ethernet (if IEEE determines
   it is so desired).
SB> Presumable we will liaise this to IEEE?

   For the layers where the IETF is concerned, the "Next Header" value
   will still be from the "Internet Protocol Numbers" registry when the
   function is applied at non-IP layers.
SB> IPv6 has next headers because Frag is an option and that is the way IPv6 works. It is unclear why a transport network fragmantation method as described here would need it.

   For the same consideration, the IP Encapsulating Security Payload
   (ESP) [RFC4303] could also be applied at other layers if ESP is
   desired there.  For example, if for whatever reason the Ethernet
   service provider wants to provide ESP between its PEs, it could do so
   without requiring IP encapsulation if ESP is applied at non-IP
   layers.
SB> I think we should get to the mechanics before discussing the options.

   The possibility of applying some other IP functions (e.g.
   Authentication Header [RFC4302]) is for further study.




Zhang, et al.              Expires May 5, 2021                  [Page 3]

Internet-Draft         Generic Transport Functions         November 2020


2.  Specifications

2.1.  Generic Fragmentation Header

   For generic fragmentation/reassembly functionality independent of IP,
   the following Generic Fragmentation Header (GFH) is defined:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Next Header  | Header Length |      Fragment Offset    |R|S|M|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Identification                        |
   |                           (variable)                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 2: Generic Fragmentation Header

   The "Next Header", "Fragment Offset" and "M" flag bit fields are as
   in the IPv6 Fragmentation Header.
SB> I am really not sure why a transport network frag needs to worry about NH. It should not care about what it is carrying. Its job is to simply glue the packet back together and let something that understands the glued together packet interpret it.
SB> IN any case NH could, at least in theory, alias IP and cause ECMP problems unless this sits behind a CW, which I don’t think we have discussed yet.

   Header Length:  the number of octets of the entire header.

   R: The "R" flag bit is reserved.  It MUST be 0 on transmitting and
      ignored on receiving.

   Identification:  at least 4-octet long.
SB> Four seems dangerously short given that IPv4 uses Eight. Also we need some discussion about how the ID is generated such that a misdelivered packet cannot get fragmented.
SB> BTW since later in your discussion you talk about multi-path delivery, you need to discuss reassembly timeout. That is not a problem with a PW since it is single path.

   S: If the "S" flag bit is clear, the context for the Identification
      field is provided by the outer header, and only the source-
      identifying information in the outer header is used.  If the "S"
      flag bit is set, the variable Identification field encodes both
      source-identifying information (e.g. the IP address of the node
      adding the GFH) and an identification number unique within that
      source.
SB> We need to be clearer that the ID must be unique per flow for the lifetime of any packet from that flow in the network, including “stuck” packets.

   The outer header MUST identify that a Generic Fragmentation Header
   follows and MAY carry source-identifying information.

   If the outer header is BIER, a TBD value for the "proto" field in the
   BIER header identifies that a GFH follows.  If the "S" flag bit is
   clear, the "BFIR-id" field in the BIER header provides the context
   for the "Identification" field.
SB> It is not yet clear why we need the protocol type at the MPLS layer.

   If the outer header is MPLS, the "S" flag bit MAY be clear if the the
   label preceeding the GFH identifies the sending BFR in addition to
   indicating that a GFH follows (see Section 2.2).


> On 10 Nov 2020, at 23:13, Jeffrey (Zhaohui) Zhang <[e-mail]> wrote:
> 
> Hi Andy, Stewart,
>  
> If I understand it correctly, RFC4623 is specifically for PWs (p2p) and cannot be used for EVPN/VPLS.

It was certainly intended for use in P2P PWs, I am not sure anyone has thought about its application to EVPN/VPLS.


>  
> The reason is that the sequence number in the control word is specific to the PW and the fragmentation/reassembly is performed in the context of the PW.

That is correct.

> In case of EVPN/VPLS, an egress PE could receive fragments from different ingress PEs and reassembly must be done in the right context. 

We need to be quite clear here, you mean that it could be concurrently reassembling fragments from different ingress PEs to the same egress PE on the same EVPN label. Yes, that is a problem that needs to be addressed and there are a number of ways that it could be addressed. We need t think about whether the FO method is better than the BE method. 

Now the questions is where we start from scratch or provide that identity to RFC4623, and how we provide that identity. One method is SFL, another is to provide identity of the type that you describe as an extended CW. Whatever happens you are going to need a CW to desire that you defeat ECMP inspection of the payload in legacy routers.

>  
> In addition, RFC 7432 (EVPN) specifically calls out that control word is either not used or only with all-0:
>  
>    - If a network uses deep packet inspection for its ECMP, then the
>      "Preferred PW MPLS Control Word" [RFC4385 <https://tools.ietf.org/html/rfc4385>] SHOULD be used with the
>      value 0 (e.g., a 4-octet field with a value of zero) when sending
>      EVPN-encapsulated packets over an MP2P LSP.

So it has a CW.

What method does it use to do OAM, presumable GAL at BOS?

>  
>    - If a network uses entropy labels [RFC6790 <https://tools.ietf.org/html/rfc6790>], then the control word
>      SHOULD NOT be used when sending EVPN-encapsulated packets over an
>      MP2P LSP.

That will only work if you have no legacy nodes on the path. A legacy node is entitled to ignore the EL and do DPI ECMP.

>  
>    - When sending EVPN-encapsulated packets over a P2MP LSP or P2P LSP,
>      then the control word SHOULD NOT be used.

Given the f/b we got in PALS from the operator community about ECMP on PWs without CW, I wonder what is happening on these networks?

>  
> This draft-zzhang allows the context to be determined from the extended “identification” field or from the outer header.

So you have added Identification, and I agree that with unsolicited packets as opposed to the P2P PW case it is needed.

I am not sure about the rest of the design, and in particular I am not sure how you deal with reassembly lockup. That was a problem that could occur in the case of PWs because the reassembly buffer could be considered part of the PW which was something we provisioned. If we had a corruption in the network, then it would all work itself out. With an arbitrary fan in and no preprovisioning, I am not sure what the error behaviour will be. This is something that you certainly need to discuss in the text.

> In addition, it is “generic” such that it can be used for any situations where fragmentation is needed at any layer for any solution.

I am not convinced that the situations are real. I think there needs to be some more context on the deployments. Should be just fine.

BTW I note that this is a TSVWG draft. I am not sure it belongs there. I would have though that it belonged in the PALS/MPLS WGs or at least somewhere in RTG which is where EVPN was developed.

Hopefully the chairs have allowed enough time to discuss next Friday.

Best regards

Stewart

>  
> Thanks.
>  
> Jeffrey
>  
> From: Andrew G. Malis <[e-mail] <mailto:[e-mail]>> 
> Sent: Tuesday, November 10, 2020 10:33 AM
> To: Stewart Bryant <[e-mail] <mailto:[e-mail]>>
> Cc: [e-mail] <mailto:[e-mail]>; mpls <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>
> Subject: Re: [Pals] Mail regarding draft-zzhang-tsvwg-generic-transport-functions
>  
> [External Email. Be cautious of content]
>  
> Indeed, this is an already-solved problem. 
>  
> Cheers,
> Andy
>  
>  
> On Tue, Nov 10, 2020 at 9:57 AM Stewart Bryant <[e-mail] <mailto:[e-mail]>> wrote:
> Please can I draw the attention of the authors to https://tools.ietf.org/html/rfc4623 <https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc4623__;!!NEt6yMaO-gk!WnDW7J-i0YOpcV5sF1KDAfZnAaxHY5z-pG0oiSXKdSXdg9o9pRoRlJeq1ENEdsSd$>
>  
> This standards track RFC  specifies how you can sent a fragmented Ethernet frame over a PW in an MPLS network and would seem applicable to the problem that you address in your draft.
>  
> BR 
>  
> Stewart
> _______________________________________________
> Pals mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/pals <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/pals__;!!NEt6yMaO-gk!WnDW7J-i0YOpcV5sF1KDAfZnAaxHY5z-pG0oiSXKdSXdg9o9pRoRlJeq1KRQDg8M$>
> Juniper Business Use Only
>