Re: Mail regarding draft-zzhang-tsvwg-generic-transport-functions
Stewart Bryant <[email protected]>
| Newsgroups | gmane.ietf.pwe3,gmane.ietf.mpls |
|---|---|
| Message-ID | <[email protected]> |
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 <[email protected]> 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 <[email protected] <mailto:[email protected]>>
> Sent: Tuesday, November 10, 2020 10:33 AM
> To: Stewart Bryant <[email protected] <mailto:[email protected]>>
> Cc: [email protected] <mailto:[email protected]>; mpls <[email protected] <mailto:[email protected]>>; [email protected] <mailto:[email protected]>
> 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 <[email protected] <mailto:[email protected]>> 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
> [email protected] <mailto:[email protected]>
> 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
>
_______________________________________________
Pals mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pals