Tuesday, March 24, 2015< ^ >
Room Configuration
Room Occupants

[22:28:22] Victor Kuarsingh joins the room
[22:28:32] Randy Bush joins the room
[22:36:07] William Atwood joins the room
[22:38:02] <William Atwood> No audio
[22:38:24] joins the room
[22:39:33] david.sinicrope joins the room
[22:39:49] <david.sinicrope> Hi All, I’ll be doing my best to jabber scribe
[22:40:13] <david.sinicrope> Jeff just opened the meeting and went through the notable
[22:40:32] William Atwood leaves the room
[22:41:05] <david.sinicrope> There were no comments on the agenda
[22:41:26] <david.sinicrope> RTGWG will take small items that are not fitting into other WGs in the Rtg Area
[22:41:52] <david.sinicrope> Jeff is going through the milestones in the WG Chair slides
[22:41:52] William Atwood joins the room
[22:42:12] <david.sinicrope> Stewart noted that remove LFA is in AUTH48
[22:42:44] <david.sinicrope> cl-use-cases will be discontinued due to lack of interest
[22:42:44] <William Atwood> I have no audio, in spite of closing all windows in Firefox and starting again.
[22:43:04] <david.sinicrope> (I’ll notify the secretariat)
[22:43:26] <Victor Kuarsingh> confirm, no audio
[22:46:55] <david.sinicrope> going through MRT part of agenda,
[22:47:20] <david.sinicrope> Chris Bowers going through presentation
[22:48:06] leaves the room
[22:48:17] joins the room
[22:49:09] <david.sinicrope> 802.1qca directly references the MRT algorithm draft
[22:49:23] joins the room
[22:49:43] <david.sinicrope> IEEE wants to reference the work.  see draft farkas-isis-pcr
[22:50:02] <david.sinicrope> Uses MRT explicit trees
[22:50:18] leaves the room
[22:51:35] <david.sinicrope> see the Special Considerations in using the MRT algorithm for 802.1QCA
[22:52:12] <david.sinicrope>  slide 4 l
[22:52:42] <david.sinicrope> slide 6
[22:52:57] <david.sinicrope> sorry, slide 5
[22:53:13] Don OConnor joins the room
[22:53:34] <david.sinicrope> this table was added to algorithm draft
[22:54:08] <david.sinicrope> slide 6
[22:54:22] <david.sinicrope> shows the relationship between the documents
[22:54:30] <david.sinicrope> questions?
[22:55:13] <david.sinicrope> Stewart Bryant: if you are going to use Mrt for a bridge environment where sensitive to loops, how are you going to do loop recovery?
[22:55:46] <david.sinicrope> Chris: addressed in 802.1qca  - not IETF’s place to dictate mechanism
[22:55:47] Don OConnor leaves the room
[22:56:18] <david.sinicrope> Janos Farkas: The most used case will be similar to how MRT is used in IP only with MAC address
[22:56:54] Don OConnor joins the room
[22:57:22] <david.sinicrope> Stewart: no sense doing fast reroute, and then taking a hit waiting for convergence
[22:57:38] <david.sinicrope> Janos: loop free will be used
[22:57:42] Don OConnor leaves the room
[22:58:01] <david.sinicrope> Stewart: what is policy for not generating inconsistency or loop moving to new topology
[22:58:14] <david.sinicrope> Chris: there is a method in the 802.1 documents
[22:58:46] <david.sinicrope> Janos: the qc document doesn’t specify which solution to take, wait or new path
[22:59:12] akatlas joins the room
[22:59:43] <david.sinicrope> Chris: an optional qca solution is when you receive new PDUs with a digest value, you only move back to the topology once everyone has converged.
[23:00:08] <david.sinicrope> Chris: the MRT forwarding state was established.
[23:00:36] <david.sinicrope> Chris: when topology changes the PLR sends traffic onto red and  blue trees and it stays on there until all nodes agree on digest
[23:00:53] <david.sinicrope> Stewart: some traffic is on base and some on MRT or is it all on MRT?
[23:01:10] <david.sinicrope> which topo is unaffected traffic going on base or MRT
[23:01:18] <david.sinicrope> Janos: depends on scenario
[23:01:26] <david.sinicrope> unaffected goes on shortest paths
[23:01:46] <david.sinicrope> Chris: suggest to take discussion offline with 802.1 documents
[23:02:16] <david.sinicrope> moved onto the Design Team report Encap considerations
[23:02:34] <david.sinicrope>
[23:02:39] <david.sinicrope> is the presentation
[23:02:55] <david.sinicrope> slide 3
[23:04:08] <david.sinicrope> slide 4
[23:05:44] <david.sinicrope> slide 5
[23:06:06] <david.sinicrope> slide 6
[23:06:52] <david.sinicrope> slide 7
[23:07:29] <david.sinicrope> slide 8
[23:08:14] <david.sinicrope> Need to make packets bigger with out starting fragmentation
[23:08:47] <david.sinicrope> <is audio still out?>
[23:09:05] <david.sinicrope> <they were working on it>
[23:09:15] <david.sinicrope> <can anyone see what I’m scribing>
[23:09:59] <david.sinicrope> David Black: a well policed underlay attacked by malicious traffic needs to be considered
[23:10:18] <david.sinicrope> slide 9
[23:11:21] <david.sinicrope> <ack?>
[23:14:29] <david.sinicrope> name? : if you are going to use the source port for entropy isn’t this impacted by NATs?
[23:14:42] <david.sinicrope> Erik: yes you would need to consider NATs
[23:14:58] <david.sinicrope> David Black: if you do this you need to punch pin holes and NATS already do this
[23:15:04] <david.sinicrope> sldie 10
[23:16:28] <david.sinicrope> folks should think about encamps to see if it makes sense to do things in a common way
[23:17:13] <david.sinicrope> Stewart: should have an encap with instruction or we miss opportunity.  instruction  should say what we want to do with payload carried
[23:17:25] <david.sinicrope> Black: Playing HRM Opposition
[23:17:36] <david.sinicrope> generality can be dangerous.  
[23:17:48] <david.sinicrope> We did this with the MPLS encap
[23:18:08] <david.sinicrope> stewart: do you want self describing packets or packets behavior determined by control plane
[23:18:09] <david.sinicrope> ?
[23:18:20] <david.sinicrope> David: I recognized the bottomless pit
[23:18:38] <david.sinicrope> < 4 people, came up with 4 interpretations just now.
[23:18:53] <david.sinicrope> Stewart said instruction based protocols, David holds to his comment.
[23:18:58] <david.sinicrope> <lots of laughing>
[23:19:18] <david.sinicrope> slide 11
[23:19:24] <david.sinicrope> fragmentation
[23:19:46] <david.sinicrope> hard to tel if something when wrong e.g., perhaps underlay didn’t have enough MTU
[23:20:25] ida leung joins the room
[23:20:57] <david.sinicrope> Fred Templin?: look at arrow draft to see how fragmentation can be used.
[23:21:06] ida leung leaves the room
[23:21:19] <david.sinicrope> slide 12
[23:21:24] <david.sinicrope> (OAM)
[23:21:39] ida Leung joins the room
[23:22:29] <david.sinicrope> tie into ECMP if you want to ensure you are measuring the same thing
[23:22:52] <david.sinicrope> slide 13
[23:24:11] <david.sinicrope> For OAM one big thing is having sufficient extensibility
[23:24:53] <david.sinicrope> what happens when something goes wrong?  Error reporting is needed.
[23:25:16] <david.sinicrope> David Black: couple points from last sesstion in TCWG
[23:25:31] <david.sinicrope> Need to do gross checks on traffic going into the tunnel
[23:25:45] <david.sinicrope> error reporting protocols buried levels down often stay buried
[23:26:11] <david.sinicrope> needs to be given consideration to the levels of encapsulation and unwinding everything
[23:26:22] <david.sinicrope> Stewart: OAM scope should be the layer it is instrumenting
[23:26:34] <david.sinicrope> entities above and below have no business knowing its there
[23:26:41] <david.sinicrope> layer violations being discussed here?
[23:26:52] <david.sinicrope> Nothing here advocating layer violations.
[23:27:12] <david.sinicrope> if you see it here let Erik  know
[23:27:40] <david.sinicrope> David: strongly agrees with Stewart. strong answer to not mess up ICMP packet too big
[23:27:49] <david.sinicrope> Stewart: every uncap is a layer
[23:27:56] <david.sinicrope> C/uncap/encap
[23:28:14] <david.sinicrope> every layer needs an oak and scope of oam is the layer
[23:28:27] <david.sinicrope> <being killed by autocorrect, sorry>
[23:28:33] <david.sinicrope> c/oak/oam
[23:29:05] <david.sinicrope> George Swallow: all ITU protocols have mechanism for ais to push notification up a layer  and then out
[23:29:17] <david.sinicrope> these types of bindings in connectionless networks is difficult
[23:29:37] <david.sinicrope> next slide
[23:30:23] <david.sinicrope> varying degrees of implementation complexity for anti spoofing
[23:30:49] <david.sinicrope> things modified in transit can’t be covered by hash in sensible way
[23:30:58] <david.sinicrope> next slide QoS
[23:31:18] <david.sinicrope> congestion considerations
[23:31:23] <david.sinicrope> next slide
[23:32:18] <david.sinicrope> There is a good deal of congestion consideration work going on illustrated on the slide
[23:32:32] <david.sinicrope> next slide header protection
[23:32:41] <david.sinicrope> largely solved
[23:32:49] <david.sinicrope> but more needed
[23:35:06] <david.sinicrope> Stewart: given most taffic that spends most of life unprotected don’t need checksum for uncap
[23:35:59] <david.sinicrope> david black: the encaps don’t sufficiently protect need checksum to keep traffic from going to wrong place.
[23:36:09] leaves the room
[23:36:12] <david.sinicrope> Stewart: we have MPLS which does just fine
[23:36:18] <david.sinicrope> David: MPLS is well behaved
[23:37:46] <david.sinicrope> Tom H: this type of network, not sure it is a true statement, applicable to not just header control.  If I can say underlay handles, OK, but if assumptions don’t hold true and we can’t design to cases where always true
[23:38:19] <david.sinicrope> Erik: some things might be optional, but if we don’t address these things we are doing ourselves a disservice
[23:39:11] <david.sinicrope> ???: may be some cases where we can get by, but even in cases were we have a check sum.. are all implementations using ECC memory and can protect all data
[23:39:36] <david.sinicrope> Tom H: we checked this in our network, checksum protects a lot but not everything.
[23:39:45] <david.sinicrope> next slide Extensibility
[23:42:05] <david.sinicrope> TLVs, unrestrictive TLVs are hard to deal with esp in hardware
[23:42:15] <david.sinicrope> next slide- layering
[23:44:26] <david.sinicrope> next slide - service model
[23:46:04] <david.sinicrope> next slide
[23:46:09] <david.sinicrope> hardware friendly
[23:47:53] Victor Kuarsingh leaves the room
[23:48:39] <david.sinicrope> next slide - middle boxes
[23:49:19] <david.sinicrope> middle boxes will come
[23:49:37] <david.sinicrope> but try to get them to not cause more harm than needed
[23:49:39] <david.sinicrope> next slide
[23:49:41] <david.sinicrope> Open issues
[23:49:49] <david.sinicrope> touch on all of these
[23:49:53] <david.sinicrope> next steps
[23:49:55] <david.sinicrope> next slide
[23:50:14] <david.sinicrope> doesn’t say do that, don’t do this, just many things to think about
[23:50:27] <david.sinicrope> what form should this guidance take?
[23:50:47] <david.sinicrope> Not sure folks that go to Bier go here so present in other WGs
[23:50:53] <david.sinicrope> send comments to the list
[23:51:18] <david.sinicrope> Acer lined: scanned doc but good presentation
[23:51:24] <david.sinicrope> Acee lindem
[23:51:30] <david.sinicrope> Tony P: agree excellent
[23:51:44] <david.sinicrope> should not’s are almost important that shoulds
[23:52:02] <david.sinicrope> e.g. data plane should go to all groups dealing with encaps not just Bier
[23:52:23] <david.sinicrope> work done by whole design team, <loud applause>
[23:52:45] <david.sinicrope> presented at NVo3 interim, sfc and Bier
[23:52:56] <david.sinicrope> not sfc and bier
[23:53:05] <david.sinicrope> Loa: what mailing list should this go on?
[23:53:41] <david.sinicrope> the issues should be done on the rtgwg, but should be considered in other groups.
[23:53:58] <david.sinicrope> AD assumption would be it would be a draft here. Not appropriate for separate coord list
[23:54:14] <david.sinicrope> Jeff closed the meeting
[23:55:20] ida Leung leaves the room
[23:55:38] akatlas leaves the room
[23:56:10] david.sinicrope leaves the room
[23:59:29] William Atwood leaves the room
Powered by ejabberd Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!