IntArea WG * Area status update (Ads) - BOF situation - Major WG news - "area drafts" and their status * Multi-MTU subnets, Iljitsch van Beijnum http://tools.ietf.org/html/draft-van-beijnum-multi-mtu Iljitsch presents slides Dave> the real problem is not ICMP filtering but that bridged/switches some times do not send ICMP at all, which adds up to the same thing …a bit later Tim S> IP does not have CRC32 Iljitsch> But this refers to Ethernet Tim S> But Ethernet is hop by hop and IP is end to end. 16bit CRC in IP header is weaker …a bit later Dave> your "What we need" list does not include anything about the issue of incorrectly setting large MTUs Someone> what level of completeness you thing the "what we need" slide has? Iljitsch> slide is not complete, draft is better Someone> if you make the parameter (MTU) of the protocol is variable the peers need to be able to coordinate Iljitsch> Yes, see rest of presentation: sendRA with MAXMTU, SAFEMTU, SLOWMTU Dave> is MACMTU the existing MTU? Jari> it should be the same Iljitsch> but the MAXMTU may go higher Tim> there is an MTU in RA, you propose to add a new one, why? Dave> It is designed to be different for when more than 1500 size can be used George> could you repeat what the SLOWMTU is all about Iljitsch>It is to limit the MTU for nodes with <600Mb links Templin> SlOWMTU only talks about the links at the edge not in the middle Iljitsch> yes Templin> but is it useful then? Iljitsch> you can do this correctly for some case and it might be incorrect in some others Dave> use of the term SAFEMTU...not sure this is the right term. It makes no guaranty that you know the total number of hosts on the same link, if hosts come in/out. So is this safe with other nodes known that are ok with MTU, and how do you know which ones are which Matt M> SafeMTU is a strong word Iljitsch> the meaning is that if it is set this higher than 1500 then you do not need to do PMTU, ut you should only do this in very controlled environment Matt M> the handling is ok, the name is not appropriate Gerald L> there are link technologies that do less than 600M but can use larger MTUs, how did you pick the number Iljitsch> the delay goes up Gerald L> would like to see some math instead of just your opinion Iljitsch> the last version of the draft had some of that Matt M> About JumboARP, there was an old draft describing this, someone knows Gabriel> There is a proposal in IEEE to increase the MTU Iljitsch> But only up to 2K Jari> This is interesting but I want to see much more detail Iljitsch> Please give me comments on the draft RAO IANA Considerations, Jukka Manner http://tools.ietf.org/html/draft-manner-router-alert-iana Jukka> Trying to fix allocation issues with router alert NSIS chair> how do we proceed with this draft? Jari> AD sponsored and goes to IETF LC if no one raises issues Bob> at this point it was changing assignments Jukka> we are removing some values. You had a concern about aligning repositories but this was removed Jari> number 3 was a mistake in IANA allocation Jukka> actually both RFC and IANA are wrong on this Bob> this needs a bit more review. Concerned that changing this for little value may create options. There is discussion in v6ops to remove ho by ho options completely. Thomas N> this is scaled back version Pekka S>IETF LC provides a month for review ICMP extension for unnumbered, Alia Atlas (Ron Bonica) http://tools.ietf.org/html/draft-atlas-icmp-unnumbered Ron> proposal to add an extension that identifies the interface over which was the ICMP message arrived Dave> There is probably is some value for this but maybe the problem is not characterized correctly. Language needs to be cleaned up Mark> This is to allow TraceRoute to report more info, anything else? Dave> could be used in Packet too big in PMTUD. It is still a diagnostic, helping with identifying which interface has the problem etc Someone> NATs will not do anything…and you can probably can not do anything. Ron> probably NATs should just ignore this Joseph> all devices acting as transit nodes should ignore this, not just NATs Ron> if you are not producer/consumer of this then just pass it as normal is a better wording. Jari> yes, let's discuss more on the list Operations requirements, Shane Amante http://tools.ietf.org/html/draft-amante-oam-ng-requirements-01 Shane> This is about how you troubleshoot networks with LAGs and ECMP Hesham S> how do you put normal port numbers in ping packets? Shane> probably do something embed something in the payload, not spoofing Erik N> so then you are sending the packet to different place than the original, since the packet may go different ways depending on the outer header. Have you looked at spoofing in more detail? Shane> We have not looked into this in much detail yet Someone> ASCII strings are better for this kind of this Shane> yes Dave> some comment from Jabber Shane> We considered router vendors building in a inter AS OOEM code point… Pekka S> many of the requirements are interest but it is hard to see how we are going to solve some of these without changing hardware Shane> but unless we do it now then next time people spin asics we will still have no solutions. But we can also discuss shorter term solutions that we can put in existing protocols Pekka S> some idea of timeline for solution would be useful Someone> care about performance parameters? Shane> yes, for ping we want it to follow the original path. Someone> how about IEEE timestamps? Shane> we have not thought about it Jari> presenting this in ops area too? Shane> yes Mark> Shane you operate really beg nets, right? so your requirements for this may be different than for smaller nets. This creates some divergence…and is that ok? SEAL, Templin Someone> there is ICMP rate limiting so the flooding is limited Fred T> yes but still some ICMP messages must be sent Dave> this is similar to the multi-MTU subnet solutions. Can they be combined? Fred T> They are complementary from what I can tell Some discussion on how they complement each other TBC on the list Tunneling MTU issues, Touch/Townsley - Overview of issues from Joe Touch and Mark Townsley Matt M> We are not having a good foundation for this discussion resulting in circular discussion Thomas> Based on history, tunnels are everywhere and no one wants to touch them. Another issue is tunnel set-up Mark> dozens of protocols do tunnel set-up Jari> in terms of making progress documenting the issues will be valuable because then WGs can use this as reference Matt M> 791 is not clear. If this is fixed and some explanation is given then a lot of things will be fixed Thomas> what is wrong with 791 Matt M> If you follow the letter of the IP-ID definition you can not go over 6Mbps Joe> and this is just one of the issues. We need to fix these things because people try to fix this in different places creating different solutions. If we had one place where we do this then people would use it and refer to it Pekka S> three things to do here: Revise frag/MTUD and other specs, write BCP kind of doc, and then document the problem. 4459 already describes most of the problems so we should concentrate on the first 2. Thoms> documenting is good because until you figure out how bad things are you can not fix problems Fred T> Agree with Pekka. We also want to grow to accept larger MTUs Jari> Volunteers to fix 791? Mark> documentation may be interesting but maybe we have such descriptions already. Maybe we can improve on that? Then from what Pekka said can we write a BCP? Consensus decision on what is the best way using existing solutions. This would help Jari (and other WGs) to know what to do. Then we need to thing if we go back and fix things? Matt M> is there a problem with a BCP updating a protocol standard? Jari> this is not what we normally do but we need to look at the details. There is no way to go back and update all tunneling RFCs. We need to look and choose the most important schemes and everything new we do Pekka> Agree with Jari, the most helpful thing would be to fix existing or build something new Joe> what needs to be fixed in 791, could be done in a constrained way and should not be only for the benefit of tunneling. But we need to document what is happening in a BCP and maybe include what is wrong currently; which we can then use that as input for further work. Matt M> there is already a doc on frag/reas hazards but the doc does not provide solutions Pekka> fail to see how new documentation helps. We need to do something...not just new docs. Mark> "something" is a BCP which is more than documenting the problems and then going back and fixing 791 as fundamental block and then go to key tunnel encap standards and fixing those. Jari> I like the idea of BCP and the idea of fixing some things…but not everything. We need to start thinking about the BCP End of meeting