5:10 welcome: Stan Ratliff - chair Justin Dean - co chair not here apology no agenda slide or notewell No Agenda items at all until a couple of days ago Start with discussion concerning multicast DLEP support Ronald in 't Velt also has slides proceed w/o ad Document status: multihop forwarding ext - published as RFC 8629 - congrats Remaining documents mostly in last call - DLEP LID extension - updated id needed - pause ext - in RFC editor queue DLEP flow control, diff, traffic class - been in last call for sometime, should close out - adv toward pub on mailing list - one more round potentional comments Rick Taylor: - credit ext stuff, debate on authorship, dnap, resolved? Stan Ratliff: - it has been resolved - others nod in agreement notewell ietf in effect mass confusion on finding materials ??? AD (Alvaro Retana) now present DLEP multicast discussion: Lou Berger - based on discussion w/ start with dave wiggins - open source on github implementation - came up with answer - rfc8175 authors opinion was wanted, didnt wait bias - same answers! - Dave point: strict reading of doc, doesnt support everything that is being presented - intent is there, for first two - last is not clear and beyond doc, but doesnt take change in proto to do it - might as well do in small doc Rick Taylor: DLEP (RFC 8175) needs an errata: points out incconsistency, two sections condtradict eachother Lou Berger: If we give doc clarification then we might as well do in one excerpts from 8175: interesting - behaviors clearly defined - some things need interpretation - where do you carry multicast address? just say logical dst, and can be treated as such - ip addresses carried in ip packets Rick Taylor: - DLEP lisp exists, dst is defined by its mac address - multicast mac - specific Lou Berger: expected that real multicast address is going to be carried? - intent can be read, but better to be explicit - qualifies as errata Alvaro Retana: errata out of order/misspelled things Lou Berger: end results - c is not errata, d IS - we do small doc that clarifies all these points and updatres 8175 - not an Rfc 8175 bis document. Stan Ratliff: cant do it with word but with a sentence Lou Berger: we will end up here, might as well put it all in there for clarification and acts as update point 2: - modem needs/expects multicast address in DLEP Destination Up message - Dest Up *NOT* Dest Announce - in info text, but need to infer Rick Taylor: historical - Dest Announce came into the 8175 specification late - renamed and got missed in search and replace Stan's answer from email some offline dicussion - how does reciever id itself? - same conclusion: - join dest announce - leave dest down Rick Taylor may have pull req. to fix everyone agrees on dest announce do believe we need multicast address list when you update list - list that is complete list of all groups - like old soft state protos - will send complete understanding modem infer delta Stu: if you put in words may be obsfcated, its semantically its a join/leave and leave is a leave all Lou: is on slide Rick: dont know: if you send announce with small mac/ip and then mac/diff ip, does the modem - how do you retract? - add remove indicator on address already - not explicitly called out Lou: send one message that add/drop "I'm a listener, you request info with announce with ip address, sometime later with different ip that collides not clear that you can just send incremental ?" Lou: something we need to describe and need definition Since only mac in leave (Destination Down message), you do it on final leave when you have no more listeners how does a sender know there is multicast group out there with any listeners? - what are service params - spec is clear - talks about logic dest - dest up has dest address which is logical - in our case mulitcast mac - associated ip addresses - dest update for add/drop case - right with flag (Rick) - dest down - only when final listener leaves on far side - we think this was intent - questioned authors and it is indeed the intent - dest may be a broadcast address how do you know what endpoints are mutual? - want to know - on an rf channel that they move and cant get the packet - cant assume its a lan - just cant assume when someone joins they can hear you - ip addreess list unqualified - add that it was multicast - no reason that it can be first multi, then unicastr - feels hacky - changed for unintented semantic change - stan: unelegant, not hack - win for not changing encodings, but change in code - most significant Stu: - assume, dest up/dest update concept clear, not specific - multicast address Lou: - that is what is in doc - it was assumed, now explicit Stan: - if we do that, need to be careful of dest up. Inclusion of list(s) of IP addresses for MCAST listeners could introduce ordering issues that we want to stay away from - Other alternative is to restrict to a single MCAST address per Dest Up/Dest Update Lou: - does not see - if we can id multi from uni - doesnt matter order - now if group has different sets of listeners is an issue - intentionally does not want to imply that you didnt get that info - which listeners were listening to which ip multicast address - persepective wrong? Rick: what? Lou: do you want to understand if this is a list of listeners for a specific MCAST address or who is the union of multicast Rick: former, needs clarifying Roman: may be very confused, never knows. Lou: on subnet level routers know who the listeners are in many routing protocols Stu: one hop listeners Alvaro: similar - dlep routers, not behind them - translate joins Lou: - pid behavior Alvaro: - what happens when I get icmp join? Lou: - you have to go to router Alvaro: - doing it for dlep subnet Stu: - can I infer that the dst up/dst update may propgate to different grps of listeners based on group we are talking about Lou: - back 2 slides - trace on subnet - listeners: hey im listeners, magic happens to notify that there are listeners, that info propogates - goes to other radios/modems - they want to tell attached routers that there is a possible mac dst they can send to - that is this mechanism - when ip addres and mac address are avalible - does not send endpoints - everyone on network subbed - how does a sender router knows someone is too far away to get to everyone who is Stu: - focusing on multicast group and time - need to know arg both scale and privacy - number of nodes need to know - they dont need to know all multicast grps I am listening on Lou: - operating in single routing/op domain - privacy nothing different - scale - has different than on traditional lan - but you are not on traditional lan so protocols are making assumptions - need to accomodate Stan: - as sender how do you cope Lou: - cant see for multicast but can see unicast Stan: - seems like a problem - hidden terminal problem - propgate foward Rick: - privacy side step - single l2 domains - not propgating Lou: - side step inside single admin domain Ricks comment slide - Lou's takeaway - when we say multicast we must include broadcast toying with extra tlv - Lou: not sure he cares - there are uses - not a fan of rps that are unaware of subnet level power distrubtion Stan: - sat systems - network controller mode - l2 super important box - vague notion trying to comm that from l2 that modem is special - it has cap that arent on network - for net control is obvious - you are guarnteed connectivity downstream Lou: - capability of other nodes being shared - this becomes PAR, the higher level can inject info into lower level and provide dist. and disc. function Rick: - wasn't where we were going - leader in protocol - pick node with lowest id - problem: mesh radio, the guy with lowest might be in tunnel - way to let radio know this is bad idea in this case - the root being suggestion modem that they can be leader - l3-l1 interactions Lou: - why not resource param? Rick: - complex meshes building trees Stan: - ask group: getting close on time Lou: - wants to hear other guy - we need to work on 4 topics - Rick/Stan wants to - Stan volenteers Ronald in 't Velt: inter-manet routing - DLEP, straying away from what wg was about - wants to work on connecting manets together - how to connect multi-manets? - internally can be using 1 more types of radios - form collation/federation of manets - exchange routing info - large scale disaster recovery Lou: - key question: exactly what pascal trying to get at - with raw and paw activity (bof material / sidemeeting) - really wants this Rick: - really cares - this is important Ronny: - also agree - things move - gateway nodes - can run two or more manet rt protocols - flat - overlay - egp for manet - typically bgp, but not suit for this - need something new - literature has been explored but no implementations - most are sketchy on how to do it Question - is there interest to do this work? - start with problem statement - see what is out there - write protocol spec Rick: - straight to standard if we do this - enough stuff out there - wary of experimental rfcs Ron: - fine with this - but not in charter Alvaro: - I love your work BUT - you can tweak to do anything you want - before we start a new routing proto, lets see what we have - yes we need to recharter - incredibley happy - biggest attendance last 2 years - need to energy in room - like to see discussion in group in this direction - then as we get closer recharter - dont want to recharter before we see thrust Ron: - should of done on ml sooner Rick: - non-wg bof thrus morning - attempt to combine? Lou: - sidemeeting - think ideas are interesting - focused on ??? usecase - not general, service based - role for dlep and all these things togther - show up and listen, try to help - big question: where does that work end up? - new wg energy cool, but maybe hijack? - bof in singapor - listen and align to their interests? Stan: - comments/questions? - closing remarks