[{"author": "Randy Bush", "text": "

hang shi's mic is on but i hear notheing

", "time": "2023-04-24T14:03:01Z"}, {"author": "Jeffrey Haas", "text": "

https://notes.ietf.org/notes-ietf-interim-2023-idr-02-idr# - for those who can help with minutes.

", "time": "2023-04-24T14:06:38Z"}, {"author": "John Scudder", "text": "

\u201cThere are more things in heaven and earth than are dreamt of in your philosophy.\u201d (Re \u201chard to imagine\u201d)

", "time": "2023-04-24T14:24:10Z"}, {"author": "Job Snijders", "text": "

+1 to that

", "time": "2023-04-24T14:24:24Z"}, {"author": "Ignas Bagdonas", "text": "

Not only that application (=BGP) is misbehaving, for proper and efficient application (=BGP) behaviour a feedback into transport is needed. There are such feedback mechanisms and they are happily in use, it does not seem to be practical to try to define a uniform interface to the transport - for practical reasons, but defining a codepoint for indication of transport problems appears to be a right thing to do.

", "time": "2023-04-24T14:24:54Z"}, {"author": "Jeffrey Haas", "text": "

FWIW, Randy, I am not the one arguing that TCP is the thing having the main issues.

", "time": "2023-04-24T14:25:29Z"}, {"author": "John Scudder", "text": "

To be pedantic, the spec doesn\u2019t require reception of keepalives, but of messages.

", "time": "2023-04-24T14:29:06Z"}, {"author": "Jie Dong", "text": "

+1

", "time": "2023-04-24T14:31:47Z"}, {"author": "Robert Raszuk", "text": "

Can someone state what problems TCP proposal does not detect ?

", "time": "2023-04-24T14:41:39Z"}, {"author": "Jeffrey Haas", "text": "

the remote bgp peer doesn't drain its socket for a long period of time.

", "time": "2023-04-24T14:42:46Z"}, {"author": "Robert Raszuk", "text": "

The observation is that to solve the issue at BGP level both sides queues needs to be filled ... at TCP only one side, That is important and very significant difference

", "time": "2023-04-24T14:42:59Z"}, {"author": "Robert Raszuk", "text": "

@Jeff - TCP UT solution solves that

", "time": "2023-04-24T14:43:38Z"}, {"author": "John Scudder", "text": "

If you presented with that echo, Job, my hat is off.

", "time": "2023-04-24T14:43:43Z"}, {"author": "Job Snijders", "text": "

Thanks :-) it was psycho

", "time": "2023-04-24T14:44:32Z"}, {"author": "Jeffrey Haas", "text": "

no it doesn't, robert.

", "time": "2023-04-24T14:45:24Z"}, {"author": "Jeffrey Haas", "text": "

the ack segments are not lost.

", "time": "2023-04-24T14:45:33Z"}, {"author": "Robert Raszuk", "text": "

sure remote queue needs to fill up in both solutions

", "time": "2023-04-24T14:46:08Z"}, {"author": "Jeffrey Haas", "text": "

no, it can be unidirectional zero windowing.

", "time": "2023-04-24T14:46:24Z"}, {"author": "Robert Raszuk", "text": "

when it fills it will be zero window

", "time": "2023-04-24T14:46:29Z"}, {"author": "Robert Raszuk", "text": "

so TCP will kick in on the sender ... UT is triggered by zero window too

", "time": "2023-04-24T14:46:57Z"}, {"author": "Robert Raszuk", "text": "

beyond the timer

", "time": "2023-04-24T14:47:02Z"}, {"author": "Jeffrey Haas", "text": "

We'll take this to the list. Again.

", "time": "2023-04-24T14:47:22Z"}, {"author": "Robert Raszuk", "text": "

ok

", "time": "2023-04-24T14:47:38Z"}, {"author": "John Scudder", "text": "

I was just going to respond to Job\u2019s observation early on, that he would have expected that a system whose rx buffer is full and advertises 0 window, would time its peer out due to holdtime expired. My comment is that in the past I\u2019ve advocated for the opposite perspective \u2014 that if the local system has told the remote one \u201cdo not send anything\u201d it\u2019s not reasonable to then complain that the other system has not sent anything. It may be that this perspective is why some implementations work as they do. $0.02.

", "time": "2023-04-24T14:48:04Z"}, {"author": "Jeffrey Haas", "text": "

@alvaro - you've given your own example for need for capability. if you don't know that the other side can accept your local-pref, or you don't agree that the other side should send it and override your own, you need to signal agreement.

", "time": "2023-04-24T14:52:58Z"}, {"author": "Job Snijders", "text": "

@John - you also brought up the opposite-opposite perspective; that for robustness\u2019 sake it might make sense to close the connection if you observe the remote side isn\u2019t doing it :-)

", "time": "2023-04-24T14:53:19Z"}, {"author": "Jeffrey Haas", "text": "

@alvaro/authors, fwiw, a capability vector may be easiest way to exchange what levels of behavior you're willing to support. consider https://datatracker.ietf.org/doc/draft-haas-flowspec-capability-bits/ for an example of such a vector.

", "time": "2023-04-24T14:54:01Z"}, {"author": "Jeffrey Haas", "text": "

+1 to Job, at least to the extremely long case.

", "time": "2023-04-24T14:54:23Z"}, {"author": "John Scudder", "text": "

I agree. \u201cI come to bury Caesar, not to praise him\u201d, I was just offering some color as to why it might be implemented that way.

", "time": "2023-04-24T14:54:43Z"}, {"author": "John Scudder", "text": "

There is no universe in which going mute for tens of minutes is ok.

", "time": "2023-04-24T14:55:13Z"}, {"author": "Jeffrey Haas", "text": "

it's not mute, it's \"I don't hear you, and you're not allowed to shout any longer\"

", "time": "2023-04-24T14:55:34Z"}, {"author": "John Scudder", "text": "

Yes, I misspoke.

", "time": "2023-04-24T14:55:58Z"}, {"author": "Jeffrey Haas", "text": "

The angry spouse that shuts off their hearing aids.

", "time": "2023-04-24T14:55:58Z"}, {"author": "Claudio Jeker", "text": "

I think extending RFC 9234 roles for this would make sense.

", "time": "2023-04-24T14:57:27Z"}, {"author": "Jeffrey Haas", "text": "

@claudio, please consider making this comment at mic.

", "time": "2023-04-24T14:57:59Z"}, {"author": "Robert Raszuk", "text": "

it is on the slide

", "time": "2023-04-24T14:58:23Z"}, {"author": "Jeffrey Haas", "text": "

although I think you'll find great reluctance to change that as it overloads the use case.

", "time": "2023-04-24T14:58:24Z"}, {"author": "Jeffrey Haas", "text": "

Thanks, Robert.

", "time": "2023-04-24T14:58:31Z"}, {"author": "John Scudder", "text": "

Is the IANA BGP attribute registry going to need a table to indicate what contexts different attributes are usable in? (Much like OSPF has in some of their registries.)

", "time": "2023-04-24T14:59:59Z"}, {"author": "Jeffrey Haas", "text": "

That's one option, John.

", "time": "2023-04-24T15:00:18Z"}, {"author": "John Scudder", "text": "

it\u2019s a way to help people not to forget to consider it.

", "time": "2023-04-24T15:00:24Z"}, {"author": "Robert Raszuk", "text": "

@john - do you mean including all current attributes ?

", "time": "2023-04-24T15:00:41Z"}, {"author": "John Scudder", "text": "

Yes I think so.

", "time": "2023-04-24T15:01:06Z"}, {"author": "Randy Bush", "text": "

having used and survived both flavors of confederation, i am undercaffeinated so can not merge these two architectures in my head.

", "time": "2023-04-24T15:01:11Z"}, {"author": "Robert Raszuk", "text": "

so it would be sort of OAD-ELIGIBLE flag ? As each OAD may have it's own policy I presume

", "time": "2023-04-24T15:01:49Z"}, {"author": "John Scudder", "text": "

IDRP ISO 10747

", "time": "2023-04-24T15:01:57Z"}, {"author": "John Scudder", "text": "

@robert sounds right.

", "time": "2023-04-24T15:02:58Z"}, {"author": "Jeffrey Haas", "text": "

That's why I suggest mutual capabilities, Randy.

", "time": "2023-04-24T15:03:30Z"}, {"author": "Robert Raszuk", "text": "

It's significant surgery to BGP ...

", "time": "2023-04-24T15:03:53Z"}, {"author": "Randy Bush", "text": "

i understood @jeff. i did not want to be proscriptive.

", "time": "2023-04-24T15:04:14Z"}, {"author": "Robert Raszuk", "text": "

@alvaro - I am sorry if you said this and I missed - but how about just new atribute to contain stack of attributes which you want to leak ? IMO it has number of advantages - filtering being the obvious one

", "time": "2023-04-24T15:05:07Z"}, {"author": "Robert Raszuk", "text": "

of course within receiving domain you could unpack it

", "time": "2023-04-24T15:06:16Z"}, {"author": "Shyam Sethuram", "text": "

Can there be multiple OADs (somewhat ironical) i.e. different ADs that an AS is part of ?

", "time": "2023-04-24T15:06:48Z"}, {"author": "Jim Uttaro", "text": "

The intention is a set of AS Domains are all under a single OAD providing various service overlay..

", "time": "2023-04-24T15:08:34Z"}, {"author": "Alvaro Retana", "text": "

The functionality is defined per-session, so it could be possible for a specific speaker to have different policies towards/from its EBGP-OAD peers. That may be akin to \"different ADs\". To tie in with what Jim said: the various services may not extend to all EBGP-OAD peers...

\n

We'll add some text about that in the draft.

", "time": "2023-04-24T15:10:23Z"}, {"author": "Alvaro Retana", "text": "

@Jeffrey Haas ACK

", "time": "2023-04-24T15:11:01Z"}, {"author": "Alvaro Retana", "text": "

@John Scudder Good idea -- maybe this draft can update the registry.

", "time": "2023-04-24T15:11:33Z"}, {"author": "Jeffrey Haas", "text": "

I'll send additional comments on the redirect-group to the mailing list.

", "time": "2023-04-24T15:11:36Z"}, {"author": "Zhen Tan", "text": "

OK\uff0c thank you Jeff

", "time": "2023-04-24T15:12:08Z"}, {"author": "Jeffrey Haas", "text": "

The main question we'll have is FSv2 is still under-specified as to how we'll package redirect actions. Keep the existing mechanisms, or move exclusively to something new?

", "time": "2023-04-24T15:12:43Z"}, {"author": "Alvaro Retana", "text": "

@Robert Raszuk Yes, OAD-ELIGIBLE sounds like what we mean: any \"leaked\" attributed are not sent by default -- which ones will depend on the services, etc. They would be OPTIONAL.

", "time": "2023-04-24T15:13:39Z"}, {"author": "Alvaro Retana", "text": "

@Robert Raszuk An \"attribute stack\" was considered before. We need to tag this proposal as replacing that one. In my opinion, if the receiver is going to unpack the contents, why pack them in the first place. ;-)

", "time": "2023-04-24T15:16:06Z"}, {"author": "Robert Raszuk", "text": "

For the reasons of fine control

", "time": "2023-04-24T15:16:30Z"}, {"author": "Jie Dong", "text": "

@Sue yes it has been presented in the same slides deck

", "time": "2023-04-24T15:21:30Z"}, {"author": "Jeffrey Haas", "text": "

@xinxin yi - is your presentation done and contained in last one?

", "time": "2023-04-24T15:21:30Z"}, {"author": "Jeffrey Haas", "text": "

@ran chen the proposal is straight forward. thanks.

", "time": "2023-04-24T15:26:11Z"}, {"author": "Jeffrey Haas", "text": "

Is everyone still seeing Tan Zhen's slides on slide 2?

", "time": "2023-04-24T15:29:46Z"}, {"author": "Jeffrey Haas", "text": "

https://datatracker.ietf.org/doc/draft-dong-idr-node-target-ext-comm/

", "time": "2023-04-24T15:30:47Z"}, {"author": "Job Snijders", "text": "

Thanks all!

", "time": "2023-04-24T15:43:02Z"}]