Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt
Hi, Fred (et al.), On 3/29/2017 3:06 PM, Joe Touch wrote: > One other comment. I agree with figures 12 and 13 but (and I think this is > a crucial point) I think they need a supporting sentence or two explaining > why the procedure is "fragment then encapsulate" and not "encapsulate > then fragment". It's actually "on-path fragment (during transit processing, if that occurs), then encapsulate then (source) fragment.". Figs 12/13 represent the last two steps; fig 11 describes the first. I've added a paragraph and clarified the pseudocode to make that clear. Joe ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt
Hi, Fred,
Circling back to this item:
On 3/29/2017 2:18 PM, Templin, Fred L wrote:
> One other comment. I agree with figures 12 and 13 but (and I think this is
> a crucial point) I think they need a supporting sentence or two explaining
> why the procedure is "fragment then encapsulate" and not "encapsulate
> then fragment".
Will do.
> This is the difference between tunnel fragmentation
> and ordinary outer fragmentation, where your document is correctly
> advocating tunnel fragmentation.
Yeah, but I was unable to find definitive and RFC citations for those
terms ("inner fragmentation" and "outer fragmentation"). 4459 mentions
fragmentation of 'inner' and 'outer', but those terms go back to 2003
and before, and I'm not sure warrant a citation.
> To the best of my knowledge, this was
> first documented in Section 3.1.7 of RFC2764 and should be cited as such.
> At least, that is what Bob B. suggested to me about 10yrs ago.
The idea of differentiating inner and outer fragmentation goes back to
RFC2003 at least, AFAICT.
That section of RFC2764 mentions that outer fragmentation avoids
fragmentation inside the tunnel, but doesn't recommend it (it just says
"alternative"). Further, it claims that none of the existing tunneling
protocols support this (even though RFC2003 does).
I'm not convinced this is worth tracking down for its origins. Let me
know if you feel otherwise, but we'd need stronger evidence AFAICT.
Joe
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt
On 5/16/2017 4:24 PM, Templin, Fred L wrote: > Interesting timing on this message, but see below: > >> -Original Message- >> From: Joe Touch [mailto:to...@isi.edu] >> Sent: Tuesday, May 16, 2017 4:13 PM >> To: Templin, Fred L <fred.l.temp...@boeing.com> >> Cc: int-area@ietf.org >> Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt >> >> HI Fred, >> >> I'm in the process of the next update, and wanted to clarify the following: >> >> >> On 3/28/2017 9:36 AM, Templin, Fred L wrote: >>> 18) Section 4.3.3, For Multipoint Tunnels, please cite AERO, as >>> well as ISATAP [RFC5214] and 6over4 [RFC2529]. They define >>> an NBMA multipoint tunnel framework that has been around a >>> lot longer than the other examples cited. >> That section doesn't list examples of multipoint tunnels per se. It >> lists systems that use multipoint tunnels (LISP, TRILL) and discusses >> mechanisms that support multipoint tunnels (LANE, etc.). > AERO embraces the tunnel as a link in the spirit of your document while > LISP does not. AERO defines "AERO interface" and "AERO link" - LISP goes > out of its way to avoid saying anything about interfaces or links. > >> I'm not sure there's a clearly good, original ref for multipoint tunnels >> - the concept has been around in some form since basically the notion of >> a tunnel. > RFC2529 is the first I am aware of. AOK - thanks. Joe ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt
HI, Fred, AOK - I can add that. The point is that *IF* you get multiple answers (regardless of how), you use the min. And the ingress needs to determine that value before sending for sure and there's always the possibility of PMTUD doing odd things if ICMPs are blackholed here - but partial delivery in that case isn't unique to tunnels. I'll mention it, though. joe On 5/16/2017 4:31 PM, Templin, Fred L wrote: > Joe, > >> -Original Message- >> From: Joe Touch [mailto:to...@isi.edu] >> Sent: Tuesday, May 16, 2017 4:17 PM >> To: Templin, Fred L <fred.l.temp...@boeing.com> >> Cc: int-area@ietf.org >> Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt >> >> Fred, >> >> Regarding the following point: >> >> >> On 3/28/2017 9:36 AM, Templin, Fred L wrote: >>> 19) Section 4.3.3, third paragraph, I thought it was said earlier >>> that all ingress/egress pairs must support the same MTU. I >>> thought we agreed earlier on that that multi-MTU subnets >>> don't work. So, I think it should say that all ingress pairs >>> MUST support a uniform MTU. >> The cited section allows for ingress/egress pairs that don't support the >> same MTU, but then says that the MTU used for that set is the minimum of >> those MTUs. >> >> There's no way (short of configuration management) to ensure that >> ingress/egress pairs MUST support the same MTU, but no real value to >> requiring that - AFAICT, we just use the min across that set (which is >> what that section says to do). > What I am trying to get at is the need for an ingress to determine the > minimum before it sends a packet that may be too big for one of the > multipoint link egresses. On IPv6 links, this could be through receipt > of an MTU option in a Router Advertisement message. Other ways > are possible (e.g., static configuration) but there needs to be some > way for all ingresses to determine the minimum. > > Thanks - Fred > >> So yes, we do not *use* different MTUs per-destination, but we don't >> need to require it AFAICT. >> >> Joe ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt
Joe, > -Original Message- > From: Joe Touch [mailto:to...@isi.edu] > Sent: Tuesday, May 16, 2017 4:17 PM > To: Templin, Fred L <fred.l.temp...@boeing.com> > Cc: int-area@ietf.org > Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt > > Fred, > > Regarding the following point: > > > On 3/28/2017 9:36 AM, Templin, Fred L wrote: > > 19) Section 4.3.3, third paragraph, I thought it was said earlier > > that all ingress/egress pairs must support the same MTU. I > > thought we agreed earlier on that that multi-MTU subnets > > don't work. So, I think it should say that all ingress pairs > > MUST support a uniform MTU. > The cited section allows for ingress/egress pairs that don't support the > same MTU, but then says that the MTU used for that set is the minimum of > those MTUs. > > There's no way (short of configuration management) to ensure that > ingress/egress pairs MUST support the same MTU, but no real value to > requiring that - AFAICT, we just use the min across that set (which is > what that section says to do). What I am trying to get at is the need for an ingress to determine the minimum before it sends a packet that may be too big for one of the multipoint link egresses. On IPv6 links, this could be through receipt of an MTU option in a Router Advertisement message. Other ways are possible (e.g., static configuration) but there needs to be some way for all ingresses to determine the minimum. Thanks - Fred > So yes, we do not *use* different MTUs per-destination, but we don't > need to require it AFAICT. > > Joe ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt
Interesting timing on this message, but see below: > -Original Message- > From: Joe Touch [mailto:to...@isi.edu] > Sent: Tuesday, May 16, 2017 4:13 PM > To: Templin, Fred L <fred.l.temp...@boeing.com> > Cc: int-area@ietf.org > Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt > > HI Fred, > > I'm in the process of the next update, and wanted to clarify the following: > > > On 3/28/2017 9:36 AM, Templin, Fred L wrote: > > 18) Section 4.3.3, For Multipoint Tunnels, please cite AERO, as > > well as ISATAP [RFC5214] and 6over4 [RFC2529]. They define > > an NBMA multipoint tunnel framework that has been around a > > lot longer than the other examples cited. > That section doesn't list examples of multipoint tunnels per se. It > lists systems that use multipoint tunnels (LISP, TRILL) and discusses > mechanisms that support multipoint tunnels (LANE, etc.). AERO embraces the tunnel as a link in the spirit of your document while LISP does not. AERO defines "AERO interface" and "AERO link" - LISP goes out of its way to avoid saying anything about interfaces or links. > I'm not sure there's a clearly good, original ref for multipoint tunnels > - the concept has been around in some form since basically the notion of > a tunnel. RFC2529 is the first I am aware of. Fred > Joe > > ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt
Fred, Regarding the following point: On 3/28/2017 9:36 AM, Templin, Fred L wrote: > 19) Section 4.3.3, third paragraph, I thought it was said earlier > that all ingress/egress pairs must support the same MTU. I > thought we agreed earlier on that that multi-MTU subnets > don't work. So, I think it should say that all ingress pairs > MUST support a uniform MTU. The cited section allows for ingress/egress pairs that don't support the same MTU, but then says that the MTU used for that set is the minimum of those MTUs. There's no way (short of configuration management) to ensure that ingress/egress pairs MUST support the same MTU, but no real value to requiring that - AFAICT, we just use the min across that set (which is what that section says to do). So yes, we do not *use* different MTUs per-destination, but we don't need to require it AFAICT. Joe ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt
HI Fred, I'm in the process of the next update, and wanted to clarify the following: On 3/28/2017 9:36 AM, Templin, Fred L wrote: > 18) Section 4.3.3, For Multipoint Tunnels, please cite AERO, as > well as ISATAP [RFC5214] and 6over4 [RFC2529]. They define > an NBMA multipoint tunnel framework that has been around a > lot longer than the other examples cited. That section doesn't list examples of multipoint tunnels per se. It lists systems that use multipoint tunnels (LISP, TRILL) and discusses mechanisms that support multipoint tunnels (LANE, etc.). I'm not sure there's a clearly good, original ref for multipoint tunnels - the concept has been around in some form since basically the notion of a tunnel. Joe ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt
Winding down to the last part: (I agree that encryption or mimicry is useful only when it works, but not much more can be said than that) On 5/3/2017 2:59 PM, Templin, Fred L wrote: > The problem is that if there are N paths in the multipath the ingress has > no way of knowing that it has probed all N of them. And, if a transit > packet arrives that would be tunneled over a path that has not been > probed, it could black hole if the MTU is too small. That's correct - PLPMTUD can fail at any time if the PMTU changes and becomes smaller (for any reason, including link reconfiguration, path changes, multipath selection). That's why it keeps retrying. Again, this isn't new or unique to tunnels. Joe ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt
Hi Joe, > -Original Message- > From: Joe Touch [mailto:to...@isi.edu] > Sent: Wednesday, May 03, 2017 2:38 PM > To: Templin, Fred L <fred.l.temp...@boeing.com> > Cc: int-area@ietf.org > Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt > > Winnowing down... I think we're converging. Let me know if not... > > Joe > > > On 5/3/2017 2:24 PM, Templin, Fred L wrote: > > ... > > I thought for multipoint tunnels all egress' had to have the same reassembly > > MTU? Or, if taking the minimum, that minimum value could be conveyed in > > the MTU option in a Router Advertisement message. > The egresses could theoretically convey different reassembly MTUs, but > the ingress would take the min. If you have a control protocol that has > all the information, you can push that operation there. Sounds OK. > >> or PLPMTUD > >> - if it uses PLPMTUD, then steps need to be taken to either > >> establish the ingress-egress as a single flow (so that ECMP would treat > >> it as such) or to somehow try to manage subsets of arriving flows as a > >> single flow > > The "pipe model", yes. The only problem is that an ECMP device could still > > do deep-packet inspection and make multipath decisions based on the > > transit packet. > See next response... > >> and any such method needs to be careful to ensure that the > >> probe packets are not distinguishable from non-probes, or could create > >> false information > >> > >> Would that be sufficient? > > I think some would still say that an ECMP device that does deep packet > > inspection could still trigger multipath based on the transit packet. > > I think I already cover that in saying "not distinguishable" (e.g., > either by encryption or mimicry) Encryption for sure, yes. But, I'm not sure about mimicry. > > > >> ... > >>>> I don't yet see any explanation as to why this would be true. > >>>> > >>>> So I'm left with the following, which I propose as the way forward: > >>>> > >>>> - the text will be clear about the potential issues for multipath > >>>> potentially taking a long time to converge > >>> It's not that it could take a long time to converge - it is that it might > >>> never converge if some paths of the multipath block ICMPs. > >> If the path can't differentiate data and probes (see above), I can't see > >> how they can be prevented from converging. > > If the transit packet is visible in-the-clear, then some deep-packet > > inspecting ECMP device could still invoke multipath. But, it just occurred > > to me that if the transit packet is encrypted then ECMP devices would > > only see the tunnel packet headers and not the transit. So, maybe the > > tunnel can implement the RFC4821 pipe model for IPsec/TLS? > Encryption is one approach. Right. > Some sort of mimicry is another - e.g., if > the ingress encapsulation includes both net and transport, with ports > assigned per "flow group" (such that a single incoming flow belongs to > only one tunneled flow). I think this depends on how deep the ECMP device could inspect. If it goes past all of the tunnel headers and inspects the transit packet then ECMP problems can occur. > >>> ... > >>> The tunnel ingress is only the source of the tunnel packets; it is not the > >>> source of the transit packets. The only way for PLPMTUD to function > >>> properly in the presence of ECMP would be for the source of the transit > >>> packets to do the RFC4821 probing - not the tunnel ingress. > >> Agreed - the only reason the ingress would want to do PLPMTUD probing is > >> to increase the size of the chunks sent to the egress. > > I think it still would have problems. For instance, if it discovered that a > > 1400byte chunk could fit over one path in the multipath, another path > > could be constrained to only 1399 bytes and ECMP could bite you again. > If that happens, PLPMTUD would learn it and adapt. Either enough packets > would get through or the ingress would adapt. The problem is that if there are N paths in the multipath the ingress has no way of knowing that it has probed all N of them. And, if a transit packet arrives that would be tunneled over a path that has not been probed, it could black hole if the MTU is too small. Thanks - Fred fred.l.temp...@boeing.com > Joe ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt
Winnowing down... I think we're converging. Let me know if not... Joe On 5/3/2017 2:24 PM, Templin, Fred L wrote: > ... > I thought for multipoint tunnels all egress' had to have the same reassembly > MTU? Or, if taking the minimum, that minimum value could be conveyed in > the MTU option in a Router Advertisement message. The egresses could theoretically convey different reassembly MTUs, but the ingress would take the min. If you have a control protocol that has all the information, you can push that operation there. > >> or PLPMTUD >> - if it uses PLPMTUD, then steps need to be taken to either >> establish the ingress-egress as a single flow (so that ECMP would treat >> it as such) or to somehow try to manage subsets of arriving flows as a >> single flow > The "pipe model", yes. The only problem is that an ECMP device could still > do deep-packet inspection and make multipath decisions based on the > transit packet. See next response... >> and any such method needs to be careful to ensure that the >> probe packets are not distinguishable from non-probes, or could create >> false information >> >> Would that be sufficient? > I think some would still say that an ECMP device that does deep packet > inspection could still trigger multipath based on the transit packet. I think I already cover that in saying "not distinguishable" (e.g., either by encryption or mimicry) > >> ... I don't yet see any explanation as to why this would be true. So I'm left with the following, which I propose as the way forward: - the text will be clear about the potential issues for multipath potentially taking a long time to converge >>> It's not that it could take a long time to converge - it is that it might >>> never converge if some paths of the multipath block ICMPs. >> If the path can't differentiate data and probes (see above), I can't see >> how they can be prevented from converging. > If the transit packet is visible in-the-clear, then some deep-packet > inspecting ECMP device could still invoke multipath. But, it just occurred > to me that if the transit packet is encrypted then ECMP devices would > only see the tunnel packet headers and not the transit. So, maybe the > tunnel can implement the RFC4821 pipe model for IPsec/TLS? Encryption is one approach. Some sort of mimicry is another - e.g., if the ingress encapsulation includes both net and transport, with ports assigned per "flow group" (such that a single incoming flow belongs to only one tunneled flow). >>> ... >>> The tunnel ingress is only the source of the tunnel packets; it is not the >>> source of the transit packets. The only way for PLPMTUD to function >>> properly in the presence of ECMP would be for the source of the transit >>> packets to do the RFC4821 probing - not the tunnel ingress. >> Agreed - the only reason the ingress would want to do PLPMTUD probing is >> to increase the size of the chunks sent to the egress. > I think it still would have problems. For instance, if it discovered that a > 1400byte chunk could fit over one path in the multipath, another path > could be constrained to only 1399 bytes and ECMP could bite you again. If that happens, PLPMTUD would learn it and adapt. Either enough packets would get through or the ingress would adapt. Joe ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt
Hi Joe, > -Original Message- > From: Joe Touch [mailto:to...@isi.edu] > Sent: Wednesday, May 03, 2017 1:38 PM > To: Templin, Fred L <fred.l.temp...@boeing.com> > Cc: int-area@ietf.org > Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt > > HI, Fred, > > On 5/3/2017 1:07 PM, Templin, Fred L wrote: > > Hi Joe, > > > >> -Original Message- > >> From: Joe Touch [mailto:to...@isi.edu] > >> Sent: Wednesday, May 03, 2017 11:47 AM > >> To: Templin, Fred L <fred.l.temp...@boeing.com> > >> Cc: int-area@ietf.org > >> Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt > >> > >> Hi, Fred, > >> > >> Your response keeps raising the same issues that I think we agree upon: > >> > >> - PMTUD always has the possibility of creating black holes (whether > >> in the presence of multipath or not) > >> > >> - PLPMTUD can generate cases where the MIN isn't actually detected > >> > >> and some claims with which I disagree: > >> > >> - that PMPMTUD probes travel different paths than the data > > I think I have already said this many times, but let me try again. The > > tunnel ingress is not the source of the transit packet; it is only the > > source of the tunnel packet. And, the ingress may have to tunnel > > a wide variety of transit packets sourced by many original sources. > > So, if ECMP somewhere within the tunnel peeks at the transit > > packet, then the packet could take a very different path within > > the tunnel than the ingress' PLPMTUD probes took. > OK, so we have to separate things out. > > PLPMTUD E2E will still work fine - or not - and isn't affected by the > presence of a tunnel per se. Agreed - E2E from transit packet source to transit packet destination is not affected by the presence of the tunnel. > The same is true for PMTUD E2E. OK. > The issue is how the tunnel itself figures out MTU values larger than > the required minimums for transit to the egress. There are two cases: > - for egress reassembly, a tunnel protocol can communicate that > reassembly MTU explicitly (and the MIN taken for multipoint tunnels, as > with multicast) I thought for multipoint tunnels all egress' had to have the same reassembly MTU? Or, if taking the minimum, that minimum value could be conveyed in the MTU option in a Router Advertisement message. > - for transit between ingress and egress, the tunnel would need to > either use PMTUD (and be susceptible to black holes) Yes. > or PLPMTUD > - if it uses PLPMTUD, then steps need to be taken to either > establish the ingress-egress as a single flow (so that ECMP would treat > it as such) or to somehow try to manage subsets of arriving flows as a > single flow The "pipe model", yes. The only problem is that an ECMP device could still do deep-packet inspection and make multipath decisions based on the transit packet. > and any such method needs to be careful to ensure that the > probe packets are not distinguishable from non-probes, or could create > false information > > Would that be sufficient? I think some would still say that an ECMP device that does deep packet inspection could still trigger multipath based on the transit packet. > >> Those probes should be used to determine an MTU only for a > >> given flow; the potential hazards of sharing that information across > >> flows is already discussed in that RFC. > > I don't think RFC4821 does enough to take ECMP into account when it > > talks about storing and sharing discovered MTUs. > While I agree, this document is not intended to update that nor to > account for its deficiencies, so I'm not sure what to add other than as > stated above. Agreed, this is an RFC4821 issue and potentially subject for an erratum for that document (not this one). > ... > > > >> I don't yet see any explanation as to why this would be true. > >> > >> So I'm left with the following, which I propose as the way forward: > >> > >> - the text will be clear about the potential issues for multipath > >> potentially taking a long time to converge > > It's not that it could take a long time to converge - it is that it might > > never converge if some paths of the multipath block ICMPs. > If the path can't differentiate data and probes (see above), I can't see > how they can be prevented from converging. If the transit packet is visible in-the-clear, then some deep-packet inspecting ECMP device could still invoke multipath. But, it just occurred to me that if the transit packet is
Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt
HI, Fred, On 5/3/2017 1:07 PM, Templin, Fred L wrote: > Hi Joe, > >> -Original Message- >> From: Joe Touch [mailto:to...@isi.edu] >> Sent: Wednesday, May 03, 2017 11:47 AM >> To: Templin, Fred L <fred.l.temp...@boeing.com> >> Cc: int-area@ietf.org >> Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt >> >> Hi, Fred, >> >> Your response keeps raising the same issues that I think we agree upon: >> >> - PMTUD always has the possibility of creating black holes (whether >> in the presence of multipath or not) >> >> - PLPMTUD can generate cases where the MIN isn't actually detected >> >> and some claims with which I disagree: >> >> - that PMPMTUD probes travel different paths than the data > I think I have already said this many times, but let me try again. The > tunnel ingress is not the source of the transit packet; it is only the > source of the tunnel packet. And, the ingress may have to tunnel > a wide variety of transit packets sourced by many original sources. > So, if ECMP somewhere within the tunnel peeks at the transit > packet, then the packet could take a very different path within > the tunnel than the ingress' PLPMTUD probes took. OK, so we have to separate things out. PLPMTUD E2E will still work fine - or not - and isn't affected by the presence of a tunnel per se. The same is true for PMTUD E2E. The issue is how the tunnel itself figures out MTU values larger than the required minimums for transit to the egress. There are two cases: - for egress reassembly, a tunnel protocol can communicate that reassembly MTU explicitly (and the MIN taken for multipoint tunnels, as with multicast) - for transit between ingress and egress, the tunnel would need to either use PMTUD (and be susceptible to black holes) or PLPMTUD - if it uses PLPMTUD, then steps need to be taken to either establish the ingress-egress as a single flow (so that ECMP would treat it as such) or to somehow try to manage subsets of arriving flows as a single flow and any such method needs to be careful to ensure that the probe packets are not distinguishable from non-probes, or could create false information Would that be sufficient? ... > >> Those probes should be used to determine an MTU only for a >> given flow; the potential hazards of sharing that information across >> flows is already discussed in that RFC. > I don't think RFC4821 does enough to take ECMP into account when it > talks about storing and sharing discovered MTUs. While I agree, this document is not intended to update that nor to account for its deficiencies, so I'm not sure what to add other than as stated above. ... > >> I don't yet see any explanation as to why this would be true. >> >> So I'm left with the following, which I propose as the way forward: >> >> - the text will be clear about the potential issues for multipath >> potentially taking a long time to converge > It's not that it could take a long time to converge - it is that it might > never converge if some paths of the multipath block ICMPs. If the path can't differentiate data and probes (see above), I can't see how they can be prevented from converging. ... > ... > The tunnel ingress is only the source of the tunnel packets; it is not the > source of the transit packets. The only way for PLPMTUD to function > properly in the presence of ECMP would be for the source of the transit > packets to do the RFC4821 probing - not the tunnel ingress. Agreed - the only reason the ingress would want to do PLPMTUD probing is to increase the size of the chunks sent to the egress. Joe ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt
Hi Joe, > -Original Message- > From: Joe Touch [mailto:to...@isi.edu] > Sent: Wednesday, May 03, 2017 11:47 AM > To: Templin, Fred L <fred.l.temp...@boeing.com> > Cc: int-area@ietf.org > Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt > > Hi, Fred, > > Your response keeps raising the same issues that I think we agree upon: > > - PMTUD always has the possibility of creating black holes (whether > in the presence of multipath or not) > > - PLPMTUD can generate cases where the MIN isn't actually detected > > and some claims with which I disagree: > > - that PMPMTUD probes travel different paths than the data I think I have already said this many times, but let me try again. The tunnel ingress is not the source of the transit packet; it is only the source of the tunnel packet. And, the ingress may have to tunnel a wide variety of transit packets sourced by many original sources. So, if ECMP somewhere within the tunnel peeks at the transit packet, then the packet could take a very different path within the tunnel than the ingress' PLPMTUD probes took. > However, PLPMTUD probes are generated by transport or higher layers, > using the same transport protocol and port pairs as the data (they ARE > the data). Maybe we are talking past each other - I thought the document was asking the tunnel ingress to act as a packetization layer and send PLMTUD probes as if it were a transport or higher layer? > Those probes should be used to determine an MTU only for a > given flow; the potential hazards of sharing that information across > flows is already discussed in that RFC. I don't think RFC4821 does enough to take ECMP into account when it talks about storing and sharing discovered MTUs. > The entire point of PMPMTUD is > that the probes travel the same path as the data - and yes, any > multipath system could give false information, but should eventually > converge on a useful minimum as long as data packets get through. If the probes look exactly like the data, then the probes will travel the same ECMP path as the data and will discover a valid MTU yes. The trouble with tunnels is that there is no way for the ingress to send a probe for each and every transit packet flow - and, if a flow arrives that has not been probed it can black hole. > - that tunnels behave differently than unicast links in this regard You won't get me to make this argument - I am convinced that tunnels are links. > I don't yet see any explanation as to why this would be true. > > So I'm left with the following, which I propose as the way forward: > > - the text will be clear about the potential issues for multipath > potentially taking a long time to converge It's not that it could take a long time to converge - it is that it might never converge if some paths of the multipath block ICMPs. > - the text will be clear about the potential issues for black-holing > > However, in both cases, I don't see a good reason to flag how a tunnel > behaves as unique. > > Does that work? > > If not, why not? The tunnel ingress is only the source of the tunnel packets; it is not the source of the transit packets. The only way for PLPMTUD to function properly in the presence of ECMP would be for the source of the transit packets to do the RFC4821 probing - not the tunnel ingress. Thanks - Fred fred.l.temp...@boeing.com > Joe > > > > On 5/3/2017 10:48 AM, Templin, Fred L wrote: > > Hi Joe, > > > > Sorry for the extended delay - see below for responses: > > > > Thanks - Fred > > > >> -Original Message- > >> From: Joe Touch [mailto:to...@isi.edu] > >> Sent: Wednesday, March 29, 2017 3:06 PM > >> To: Templin, Fred L <fred.l.temp...@boeing.com> > >> Cc: int-area@ietf.org > >> Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt > >> > >> Hi, Fred, > >> > >> I think we're agreed except for PMTUD and PLMTUD. See below about the > >> latter (AFAICT, if it black holes, then the PLMTUD would detect a > >> failure to make forward progress). Black-holing in PMTUD is known and > >> not something this (or any other doc) is fixing, but also a known standard. > >> > >> Joe > >> > >> > >> On 3/29/2017 2:18 PM, Templin, Fred L wrote: > >>> ... > >>>>> 10) Section 4.2.1, bulleted list toward bottom of section, tunnel > >>>>>"atom" is a very strange word to me. Tunnel "cell"? > >>>> The concept of an atomic packet was defined in RFC 6864. This is derived > >>>> from that. Cell would be introducing a new term, one that is o
Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt
Hi, Fred, Your response keeps raising the same issues that I think we agree upon: - PMTUD always has the possibility of creating black holes (whether in the presence of multipath or not) - PLPMTUD can generate cases where the MIN isn't actually detected and some claims with which I disagree: - that PMPMTUD probes travel different paths than the data However, PLPMTUD probes are generated by transport or higher layers, using the same transport protocol and port pairs as the data (they ARE the data). Those probes should be used to determine an MTU only for a given flow; the potential hazards of sharing that information across flows is already discussed in that RFC. The entire point of PMPMTUD is that the probes travel the same path as the data - and yes, any multipath system could give false information, but should eventually converge on a useful minimum as long as data packets get through. - that tunnels behave differently than unicast links in this regard I don't yet see any explanation as to why this would be true. So I'm left with the following, which I propose as the way forward: - the text will be clear about the potential issues for multipath potentially taking a long time to converge - the text will be clear about the potential issues for black-holing However, in both cases, I don't see a good reason to flag how a tunnel behaves as unique. Does that work? If not, why not? Joe On 5/3/2017 10:48 AM, Templin, Fred L wrote: > Hi Joe, > > Sorry for the extended delay - see below for responses: > > Thanks - Fred > >> -Original Message- >> From: Joe Touch [mailto:to...@isi.edu] >> Sent: Wednesday, March 29, 2017 3:06 PM >> To: Templin, Fred L <fred.l.temp...@boeing.com> >> Cc: int-area@ietf.org >> Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt >> >> Hi, Fred, >> >> I think we're agreed except for PMTUD and PLMTUD. See below about the >> latter (AFAICT, if it black holes, then the PLMTUD would detect a >> failure to make forward progress). Black-holing in PMTUD is known and >> not something this (or any other doc) is fixing, but also a known standard. >> >> Joe >> >> >> On 3/29/2017 2:18 PM, Templin, Fred L wrote: >>> ... >>>>> 10) Section 4.2.1, bulleted list toward bottom of section, tunnel >>>>>"atom" is a very strange word to me. Tunnel "cell"? >>>> The concept of an atomic packet was defined in RFC 6864. This is derived >>>> from that. Cell would be introducing a new term, one that is overloaded >>>> with ATM, which we want to avoid. >>> OK, but then please find a way to call it an "atomic packet". >> Agreed. > OK. > >>> ... >>>>> 13) Section 4.2.2, final sentence is incorrect. RFC4821-style MTU >>>>> probing cannot be used by tunnels due to ECMP because the probe >>>>> packets may take a different path than the data packets. That >>>>> is why AERO no longer uses RFC4821 probing. >>>> Regarding ECMP issues, I think we need to wrap this issue up. Here's >>>> what I propose: >>>> >>>> - point out that ECMP causes problems with PMTUD (and can cause problems >>>> with PLMTUD). >>>> - an interface has two choices: >>>> - keep track of PMTU based on other packet context (flowID or next >>>> header info) >>>> - merge PMTU feedback, taking the MIN of reported values >>> The problem is that some paths in the multipath may fail to deliver >>> the ICMPs. So there is no way to know whether the MIN has been >>> determined. >> That's no different from the multicast case, though. > In terms of PMTUD, you are right that in a certain sense unicast destinations > with ECMP are like multicast. In other words, a single destination with > multiple > paths - some of which may not deliver ICMPs. > > But (unlike unicast) the Internet community seems to be OK with the fact > that some multicast group members might not receive multicasts due to > an MTU black hole. For unicast destinations, it can be a real problem if > there is an MTU black hole along one or more paths of the multipath. > >>> Also the ingress may be handling transit packets sourced >>> by a very large number of original sources each of which produce >>> a very large number of distinct flows. So, there is no way for the >>> ingress to cache all of the flow information it handles. >> Min requires maintaining the same information as any interface would keep. > I was referring to PLPMTUD here. For PLPMTUD, the probes sent by the &
Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt
Hi Joe, See below: > -Original Message- > From: Joe Touch [mailto:to...@isi.edu] > Sent: Tuesday, March 28, 2017 12:38 PM > To: Templin, Fred L <fred.l.temp...@boeing.com> > Cc: int-area@ietf.org > Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt > > Hi, Fred, > > Thanks for the feedback. Let's assume I incorporate the nits/bugs and I > address any clarifications when I get to them in detail, so I'll jump > only to the deeper issues below... > > Joe > > > On 3/28/2017 9:36 AM, Templin, Fred L wrote: > > Here are my comments for this draft. Mostly editorial, but some substantial. > > I also noticed several indications that further work was needed in some > > sections. Will those sections be worked before publication? > As per Mark's presentation, it depends on whether this doc stays > informational (as was adopted) or becomes BCP (as we think it probably > should). > > If informational, much of Section 5 will be removed. If not, then that > will be fleshed out. > > > 10) Section 4.2.1, bulleted list toward bottom of section, tunnel > >"atom" is a very strange word to me. Tunnel "cell"? > > The concept of an atomic packet was defined in RFC 6864. This is derived > from that. Cell would be introducing a new term, one that is overloaded > with ATM, which we want to avoid. OK, but then please find a way to call it an "atomic packet". Calling it an "atom" would be introducing a new term here, and we could argue whether the term would have more or less baggage than the term "cell". > > 13) Section 4.2.2, final sentence is incorrect. RFC4821-style MTU > > probing cannot be used by tunnels due to ECMP because the probe > > packets may take a different path than the data packets. That > > is why AERO no longer uses RFC4821 probing. > > Regarding ECMP issues, I think we need to wrap this issue up. Here's > what I propose: > > - point out that ECMP causes problems with PMTUD (and can cause problems > with PLMTUD). > - an interface has two choices: > - keep track of PMTU based on other packet context (flowID or next > header info) > - merge PMTU feedback, taking the MIN of reported values The problem is that some paths in the multipath may fail to deliver the ICMPs. So there is no way to know whether the MIN has been determined. Also the ingress may be handling transit packets sourced by a very large number of original sources each of which produce a very large number of distinct flows. So, there is no way for the ingress to cache all of the flow information it handles. > There's no magic here. It's a lot like multicast - either keep track in > a way that you *think* correlates to the different PMTU feedback or take > the MIN. It only works if all paths on the mutlipath can be counted on to deliver the ICMPs. If any paths in the multipath fail to deliver the ICMPs, it black holes. And, this is a known problem. > The current doc does need a scrub to make this point clearly and > consistently. It doesn't work, regardless of the amount of scrubbing. > > 14) Section 4.2.2, should include discussion of how common tunnel > > specs regard EMTU_R and the tunnel atom (cell) size. Namely, > > many common specs assume larger EMTU_R and tunnel cell sizes > > than are guaranteed by RFC1122 and RFC2460. That means that > > these tunnel specs are relying on operational assurances of > > larger values than the IPv4 and IPv6 minimums. Since they are > > already published as standards, this document needs to explain > > how they are able to operate without fragmentation. > I'll see what I can do to add that point; I'm hoping to not need to cite > dozens of examples, though. OK, and I agree that you shouldn't need to cite the multitude of standards that do this. > > 17) Section 4.2.3 cites RFC4821, but PLPMTUD cannot be used by > > tunnels due to ECMP. > I disagree; it can, but the system needs to either take the MIN or have > a way to decouple discovered PMTUs in way that can be trusted to > reasonably correspond to the ECMP splitting. It doesn't work in the generalized case. The ECMP might split into a multitude of distinct paths, and there is no way for the ingress to known which of the paths have been tested. And, all it takes is one un-tested path in the multipath and there is potential for a black hole. > > 20) Section 4.3.3, fourth paragraph, "A multipoint tunnel MUST > > have support for broadcast and multicast" - I think this > > would be better as a "SHOULD". RFC2529 and AERO support > > multicast, but RFC5214 does not yet it is widely deployed. > &g
Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt
Hi, Fred, Thanks for the feedback. Let's assume I incorporate the nits/bugs and I address any clarifications when I get to them in detail, so I'll jump only to the deeper issues below... Joe On 3/28/2017 9:36 AM, Templin, Fred L wrote: > Here are my comments for this draft. Mostly editorial, but some substantial. > I also noticed several indications that further work was needed in some > sections. Will those sections be worked before publication? As per Mark's presentation, it depends on whether this doc stays informational (as was adopted) or becomes BCP (as we think it probably should). If informational, much of Section 5 will be removed. If not, then that will be fleshed out. > 10) Section 4.2.1, bulleted list toward bottom of section, tunnel >"atom" is a very strange word to me. Tunnel "cell"? The concept of an atomic packet was defined in RFC 6864. This is derived from that. Cell would be introducing a new term, one that is overloaded with ATM, which we want to avoid. > 13) Section 4.2.2, final sentence is incorrect. RFC4821-style MTU > probing cannot be used by tunnels due to ECMP because the probe > packets may take a different path than the data packets. That > is why AERO no longer uses RFC4821 probing. Regarding ECMP issues, I think we need to wrap this issue up. Here's what I propose: - point out that ECMP causes problems with PMTUD (and can cause problems with PLMTUD). - an interface has two choices: - keep track of PMTU based on other packet context (flowID or next header info) - merge PMTU feedback, taking the MIN of reported values There's no magic here. It's a lot like multicast - either keep track in a way that you *think* correlates to the different PMTU feedback or take the MIN. The current doc does need a scrub to make this point clearly and consistently. > 14) Section 4.2.2, should include discussion of how common tunnel > specs regard EMTU_R and the tunnel atom (cell) size. Namely, > many common specs assume larger EMTU_R and tunnel cell sizes > than are guaranteed by RFC1122 and RFC2460. That means that > these tunnel specs are relying on operational assurances of > larger values than the IPv4 and IPv6 minimums. Since they are > already published as standards, this document needs to explain > how they are able to operate without fragmentation. I'll see what I can do to add that point; I'm hoping to not need to cite dozens of examples, though. > 17) Section 4.2.3 cites RFC4821, but PLPMTUD cannot be used by > tunnels due to ECMP. I disagree; it can, but the system needs to either take the MIN or have a way to decouple discovered PMTUs in way that can be trusted to reasonably correspond to the ECMP splitting. > 20) Section 4.3.3, fourth paragraph, "A multipoint tunnel MUST > have support for broadcast and multicast" - I think this > would be better as a "SHOULD". RFC2529 and AERO support > multicast, but RFC5214 does not yet it is widely deployed. Multicast or its equivalent. Otherwise, you can't support IPv6 multicast, which is a required capability of IPv6. > 23) Section 5.1, first sub-bullet under "Tunnels must obey core IP > requirements", Are you meaning to talk about IPv4 DF=1? Yes, and that should be made more explicit. Also honoring the EMTU_R limits until told otherwise. - ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt
et under "Tunnel endpoints are network interfaces", change: "they not generate" to "they do not generate" 23) Section 5.1, first sub-bullet under "Tunnels must obey core IP requirements", Are you meaning to talk about IPv4 DF=1? 24) Appendix A.2 - this section should say something about implications for ECMP when a multi-encapsulation like this includes multiple packets that, if transmitted individually, would take different paths within the tunnel. Also, in the figure the insertion of the block labeled "iHa | iDa" should show up as "iHa | iDa" within the packed packet (it currently shows up as "iHa | iHa". > -Original Message- > From: Int-area [mailto:int-area-boun...@ietf.org] On Behalf Of Joe Touch > Sent: Monday, March 27, 2017 8:39 AM > Cc: int-area@ietf.org > Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt > > Hi, all, > > This update catches some typos that are important for understanding the > terminology changes. > > Joe > > > On 3/27/2017 8:34 AM, internet-dra...@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the Internet Area Working Group of the IETF. > > > > Title : IP Tunnels in the Internet Architecture > > Authors : Joe Touch > > Mark Townsley > > Filename: draft-ietf-intarea-tunnels-05.txt > > Pages : 51 > > Date: 2017-03-27 > > > > Abstract: > >This document discusses the role of IP tunnels in the Internet > >architecture. An IP tunnel transits IP datagrams as payloads in non- > >link layer protocols. This document explains the relationship of IP > >tunnels to existing protocol layers and the challenges in supporting > >IP tunneling, based on the equivalence of tunnels to links. The > >implications of this document are used to derive recommendations that > >update MTU and fragment issues in RFC 4459. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-intarea-tunnels/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-intarea-tunnels-05 > > https://datatracker.ietf.org/doc/html/draft-ietf-intarea-tunnels-05 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-tunnels-05 > > > > > > Please note that it may take a couple of minutes from the time of submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > ___ > > Int-area mailing list > > Int-area@ietf.org > > https://www.ietf.org/mailman/listinfo/int-area > > ___ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt
Hi, all, This update catches some typos that are important for understanding the terminology changes. Joe On 3/27/2017 8:34 AM, internet-dra...@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Internet Area Working Group of the IETF. > > Title : IP Tunnels in the Internet Architecture > Authors : Joe Touch > Mark Townsley > Filename: draft-ietf-intarea-tunnels-05.txt > Pages : 51 > Date: 2017-03-27 > > Abstract: >This document discusses the role of IP tunnels in the Internet >architecture. An IP tunnel transits IP datagrams as payloads in non- >link layer protocols. This document explains the relationship of IP >tunnels to existing protocol layers and the challenges in supporting >IP tunneling, based on the equivalence of tunnels to links. The >implications of this document are used to derive recommendations that >update MTU and fragment issues in RFC 4459. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-intarea-tunnels/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-intarea-tunnels-05 > https://datatracker.ietf.org/doc/html/draft-ietf-intarea-tunnels-05 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-tunnels-05 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > ___ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
