note taking can be collaborated at: https://notes.ietf.org/notes-ietf-interim-2022-idr-04-idr
", "time": "2022-10-13T14:01:32Z"}, {"author": "John Scudder", "text": "If you want to see chat and attendees at the same time though (and who wouldn't?) you can detach the chat, though. You probably knew that...
", "time": "2022-10-13T14:01:42Z"}, {"author": "Jie Dong", "text": "It works well, thanks John!
", "time": "2022-10-13T14:12:43Z"}, {"author": "Jeffrey Haas", "text": "https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-car
", "time": "2022-10-13T14:14:19Z"}, {"author": "Jeffrey Haas", "text": "https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct
", "time": "2022-10-13T14:14:26Z"}, {"author": "John Scudder", "text": "I couldn't agree more about keeping the NLRI as simple as humanly possible.
", "time": "2022-10-13T14:31:21Z"}, {"author": "Jeffrey Haas", "text": "+1 for nexthop dependent capabilities
", "time": "2022-10-13T14:50:16Z"}, {"author": "Keyur Patel", "text": "+1 for Next-Hop Dependent Capabilities and Next-Hop Capabilities Attribute
", "time": "2022-10-13T14:51:19Z"}, {"author": "Aijun Wang", "text": "Next-Hop Dependent Capabilities, the abbreviation should be NHDC
", "time": "2022-10-13T14:52:02Z"}, {"author": "Wim Henderickx", "text": "special thx to John and Bruno for making this happen. :+1: :tada:
", "time": "2022-10-13T14:55:11Z"}, {"author": "Susan Hares", "text": "+1 on thanks to John and Bruno
", "time": "2022-10-13T14:55:31Z"}, {"author": "Aijun Wang", "text": "Can CT and CAR act like this?
", "time": "2022-10-13T14:55:56Z"}, {"author": "Jie Dong", "text": "next-hop dependent capability sounds reasonable to me
", "time": "2022-10-13T14:56:14Z"}, {"author": "Aijun Wang", "text": "The operator are headache for the two similar solutions, and then the interoperable solution-----Is Jeffery's interoperable proposal one good base the possible merger of CT and CAR?
", "time": "2022-10-13T14:58:12Z"}, {"author": "Susan Hares", "text": "The interim runs until 12pm.
", "time": "2022-10-13T14:59:35Z"}, {"author": "Jeffrey Haas", "text": "Part of my motivation, Aijun, is to see if understanding what interop looks like shows that we have room for a merge. The NLRI is the mostly boring conversation. What to do about the forwarding is where the strong opinions will be.
", "time": "2022-10-13T14:59:57Z"}, {"author": "Bruno Decraene", "text": "@Ketan regarding anycast BGP NH, would the following text work for you? https://datatracker.ietf.org/doc/html/draft-ietf-idr-next-hop-capability-08#section-3.5
", "time": "2022-10-13T15:02:41Z"}, {"author": "Ketan Talaulikar", "text": "@Bruno, indeed that text works.
", "time": "2022-10-13T15:03:51Z"}, {"author": "Bruno Decraene", "text": "Thanks. good
", "time": "2022-10-13T15:04:36Z"}, {"author": "Bruno Decraene", "text": "That's also in the merged draft: https://datatracker.ietf.org/doc/html/draft-ietf-idr-entropy-label-01#section-2.5
", "time": "2022-10-13T15:06:01Z"}, {"author": "Ketan Talaulikar", "text": "@Bruno oops. I didn't read the merged draft closely enough :-(
", "time": "2022-10-13T15:07:24Z"}, {"author": "Bruno Decraene", "text": "no problem. That's a valid question anyhow
", "time": "2022-10-13T15:07:47Z"}, {"author": "Bruno Decraene", "text": "and specific review is most welcomed
", "time": "2022-10-13T15:08:15Z"}, {"author": "John Scudder", "text": "^ absolutely
", "time": "2022-10-13T15:08:47Z"}, {"author": "Ketan Talaulikar", "text": "Regarding my use of \"originator\" - that might not have been a good terminology. I was trying to differentiate between the \"egress\" node and \"intermediate\" nodes. Both types set the NH field. We will have some capabilities like ELC that is specific to egress nodes. But likely we will also get some others that are applicable for intermediate as well.
", "time": "2022-10-13T15:10:17Z"}, {"author": "Jeffrey Haas", "text": "I think the core need, ketan, is each time the nexthop is reset the implementation needs to evaluate if any things carried for that nh need to be altered before propagating it.
", "time": "2022-10-13T15:11:25Z"}, {"author": "Bruno Decraene", "text": "ELC is most probably dependent on both originator and intermediate. Otherwise ELCv1 would have worked just fine.
", "time": "2022-10-13T15:11:57Z"}, {"author": "Bruno Decraene", "text": "more details @https://www.rfc-editor.org/rfc/rfc6790.html#section-5.2
", "time": "2022-10-13T15:14:31Z"}, {"author": "Ketan Talaulikar", "text": "@Bruno, except for the anycast scenario, a pure transitive attribute should have worked for ELC. There were other issues with the ELCv1 proposal. But the ELI/EL is exposed only at the egress and intermediate nodes don't care. Right?
", "time": "2022-10-13T15:14:41Z"}, {"author": "Ketan Talaulikar", "text": "@Jeff agree. This is specifically needed for egress capabilities where we have an anycast-link scenarios with multiple egresses.
", "time": "2022-10-13T15:15:53Z"}, {"author": "Bruno Decraene", "text": "I would tend to agree with you. But RFC 6790 also covers the case where the ASBR changing the NH does not simply swap but pop the mpls stack
", "time": "2022-10-13T15:15:58Z"}, {"author": "Bruno Decraene", "text": "One example would may be be 6PE
", "time": "2022-10-13T15:16:53Z"}, {"author": "John Scudder", "text": "This is getting into ancient history but as I recall the problem with ELCv1 was exactly that it was transitive. Consider the case where it's added by a router that's EL-capable (of course) but eventually the route crosses the AS border and is picked up by another router that is NOT EL-capable, and which doesn't strip the attribute for whatever reason (say, becasue it doesn't implement it).
", "time": "2022-10-13T15:18:03Z"}, {"author": "Ketan Talaulikar", "text": "@Bruno, @John, agree. Which brings in question my use of the \"egress\" term as well :-) ... ok! But going back, we can have potentially two different NH capabilities that we are carrying \"egress\" and \"intermediate\" - the RCA can carry only one of them. Therefore, perhaps the need for two such attributes?
", "time": "2022-10-13T15:20:31Z"}, {"author": "Jeffrey Haas", "text": "Ketan, could I request you to take that case to the idr mail list to get broader discussion?
", "time": "2022-10-13T15:21:01Z"}, {"author": "Ketan Talaulikar", "text": "@Jeff ack
", "time": "2022-10-13T15:21:12Z"}, {"author": "Jeffrey Haas", "text": "@kaliraj \"cooperating as\" would in different times be a bgp confederation. Since this is normal ebgp, it's a federation of ebgp speakers.
", "time": "2022-10-13T15:22:46Z"}, {"author": "Jeffrey Haas", "text": "trouble is we can't push people to migrate into rfc 3065 bgp confederations for these purposes.
", "time": "2022-10-13T15:23:21Z"}, {"author": "Linda Dunbar", "text": "can't see any slides
", "time": "2022-10-13T15:46:44Z"}, {"author": "John Scudder", "text": "slides are ok here
", "time": "2022-10-13T15:47:12Z"}, {"author": "Jeffrey Haas", "text": "same. reconnect, linda.
", "time": "2022-10-13T15:47:18Z"}, {"author": "John Scudder", "text": "direct link to slides: https://datatracker.ietf.org/meeting/interim-2022-idr-04/materials/slides-interim-2022-idr-04-sessa-bgp-multinexthop-attribute-00
", "time": "2022-10-13T15:47:31Z"}, {"author": "Linda Dunbar", "text": "got it after refreshing
", "time": "2022-10-13T15:47:32Z"}]