Re: [GROW] BGP Looking Glass Capability
Hello everyone, While quite a few drafts have been using attributes to carry weird information into BGP, this one proposes to use MP. I can see how one may think it would be helpful and reduce implementation burgen but I am not sure it is wise and I believe it goes beyond what AFI/SAFI are for. Also this reminds me very much of https://datatracker.ietf.org/doc/html/draft-ietf-idr-operational-message which I implemented but never saw traction. So while I can see why this would benefit operational matters, I do not believe the RFC as proposed should be accepted. Sorry for being such a party pooper ! Thomas On Sat, 24 Apr 2021 at 14:38, Rayhaan Jaufeerally (IETF) wrote: > Dear GROW chairs and participants, > > I would like to propose draft-jaufeerally-bgp-lg-cap-00 ( > https://datatracker.ietf.org/doc/draft-jaufeerally-bgp-lg-cap/) as a > mechanism for in-band dissemination of looking glass endpoints in BGP, > using a new OPEN message capability. > > The rationale behind this is to facilitate automation around eBGP peering, > for example to make it possible to automatically detect if the peer has > accepted some routes which are expected to be accepted. > > I'm aware that the underlying RFC8522 is an informational RFC and leaves > some details unspecified for the response format (i.e. a schema for the > queries/responses) but I believe that can be further refined in other works > independent to this proposal. > > I would like to hear what the WG thinks, if this is a reasonable proposal > which fits into the broader charter of GROW? > > Thanks, > Rayhaan > ___ > GROW mailing list > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow > ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Do you want BGP to extend the message size for all BGP messages or just UPDATES.
Hello, I would propose a draft wording change among the lines of what is here. I have not defined a name for the "extra capability buffer size", it may be advisable. So the wording is mostly to clarify the intend and not intended verbatim. Thomas -- Before The BGP Extended Message Capability is a new BGP Capability [RFC5492] defined with Capability code 6 and Capability length 0. After The BGP Extended Message Capability is a new BGP Capability [RFC5492] defined with Capability code 6 and Capability length 2. The capability value will be called "capability extra length" (encoded as 2 octets). The value of the "capability extra length" MUST be added to the OPEN "Optional Parameters Length", and the "Optional Parameters" buffer extended accordingly. For backward compatibility with speakers not aware of this capability, the data processed when only reading "Optional Parameters Length" of "Optional Parameters" MUST provide a valid capability boundary. Further drafts and RFC MUST explicitly indicate if any defined capability must be stored within the non-extended Optional Parameters buffer or SHALL be added within the extended size. Before An implementation that advertises support for BGP Extended Messages MUST be capable of receiving an UPDATE message with a length up to and including 65535 octets. After An implementation that advertises support for BGP Extended Messages MUST be capable of receiving messages with a length up to and including 65535 octets, however the OPEN message length MUST still be no greater than 4096. ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Do you want BGP to extend the message size for all BGP messages or just UPDATES.
On 2017-03-11 18:06, Thomas Mangin wrote: > https://github.com/Exa-Networks/exabgp/blob/master/lib/exabgp/bgp/message/open/capability/capabilities.py#L159 should be: https://github.com/Exa-Networks/exabgp/blob/974f97fc6be63f0b05755ffc3e1ea69a02c0505b/lib/exabgp/bgp/message/open/capability/capabilities.py#L159 As I now fixed the issue but it means that in production there is speakers which would break should multiple pairs of capabilities were used ... The "to be continued in a second OPEN" option looks very very appealing to me right now. Thomas ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Do you want BGP to extend the message size for all BGP messages or just UPDATES.
On 2017-03-10 22:32, Nick Hilliard wrote:
> This is listed as a
MUST in 4721, so heas@ is probably correct that any
> implementation
which ignores this is terminally broken.
I agree fully:
- terminally
broken from a standard and compliance POV
- working perfectly in
production from an operational one (most likely for years).
ExaBGP OPEN
with everything it implements is 173 bytes ATM.
SENDING ( 173)
00AD 0104 FFFD 00B4 7F00 9002
0601 0400 0100 0102 0601 0400 0100 0202 0601 0400 0100 0402 0601 0400
0100 8002 0601 0400 0100 8402 0601 0400 0100 8502 0601 0400 0100 8602
0601 0400 0200 0102 0601 0400 0200 0202 0601 0400 0200 0402 0601 0400
0200 8002 0601 0400 0200 8502 0601 0400 0200 8602 0601 0400 1900 4102
0601 0400 1900 4602 0601 0440 0400 4702 0601 0440 0400 4802 0641 0400
00FF FD
OPEN version=4 asn=65533 hold_time=180 router_id=127.0.0.0
capabilities=[Multiprotocol(ipv4 unicast,ipv4 multicast,ipv4
nlri-mpls,ipv4 mpls-vpn,ipv4 rtc,ipv4 flow,ipv4 flow-vpn,ipv6
unicast,ipv6 multicast,ipv6 nlri-mpls,ipv6 mpls-vpn,ipv6 flow,ipv6
flow-vpn,l2vpn vpls,l2vpn evpn,bgpls bgp-ls,bgpls bgp-ls-vpn),
ASN4(65533)]
But before caring about the 65k OPEN, we may want to
consider that the "Optional Parameters Length" which is a byte, so:
173
bytes with 19 bytes of header and 10 bytes of pre-capabilities OPEN
headers, so effectively 144 bytes are used for capabilities, so in this
OPEN there is still around 100 bytes left for the things I did not
implement .. which is not that much.
A simple solution would be to have
a capability that if present allow the pair "Optional Parameters Length"
/ "Optional Parameters" to be repeated multiple times (the "to be
continued capability" capability :p) ... It would then increase the size
from 100 to around 4k, at which point we can still extend it with
another capability allowing for another OPEN in another draft if we need
to span multiple OPEN. ATM all we have to do is forbid this capability
when we reach the 4k limit.
Quite ironically ExaBGP does not enforce
the "Optional Parameters Length", and therefore will read up to 4k in
capability in violation of the RFC ... /me starts looking in another
direction ...
But somehow it helps me with my point about the sleeping
beast, so I will not feel too bad about it
:p
https://github.com/Exa-Networks/exabgp/blob/master/lib/exabgp/bgp/message/open/capability/capabilities.py#L159
Let's
keep with the IETF "Robustness Principle" and just fix this with
4k.
Thomas
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Do you want BGP to extend the message size for all BGP messages or just UPDATES.
Hi Enke, If we are going to take a long time to reach any consensus, I would rather not change the OPEN size. The gain with large MESSAGE is within the UPDATE processing. Having large MESSAGE will drastically reduce the processing of attributes per NLRI [1]. Having a smaller OPEN is something we can decide ignore at the moment, there is no problem a larger OPEN fixes today. I would advocate to just change the draft to clarify that all MESSAGEs but OPEN are affected and be done with it. Let progress by step: this one is very easy to implement, anything more would require more code and therefore is less likely to get in production soon (it seems to be the lesson coming from RFC 8092). I would then advocate to look at extending the OPEN as another draft (that we can then argue for years until there is pressure from the operational to get consensus and another draft with happen instead :p), it does not delay the benefit of 65k UPDATEs. Thomas [1] BGP was designed in a time where CPU and memory were expensive. So it does did not disjoint ATTRIBUTE and NRLI. They were both were packed in a same message to be processed together (but if someone want to create new named attribute messages and a new attribute to use to link it to an UPDATE - I am all in favour to even reduce the CPU load on my routers). On 2017-03-09 20:09, Enke Chen wrote: > Hi, Folks: > > Let me add some specifics: > > Case 1: large OPEN only > > If the local speaker is only interested in getting the session established using a > large OPEN, then it SHOULD go ahead with the large OPEN and deal with the issue > administratively upon receiving a NOTIFICATION due to the large OPEN size. In this > case the remote speaker has to be upgraded to support the large message capability. > > Case 2: Prefer a large OPEN, but can live with a normal size, predefined OPEN > > Option 1: Start with a large OPEN. In case a NOTIFICATION is received due to the > large OPEN size, fall back to using the predefined normal size OPEN. > > Option 2: Start with the normal size OPEN. If the OPEN from the remote speaker > does not contains the large message capability, proceed with the session > establishment. Otherwise send a CEASE message (with a new subcode) and > terminate the session (before sending the KEEPALIVE), and then start a > new session with the large OPEN. > > With either Option, there should be no impact on the GR or LLGR as the session > did not reach the ESTABLISHED state with the first OPEN. > > Option 1 is more preferred when the local speaker has the knowledge that the > capability is supported by the remote speaker based on the previous OPEN or via > administrative means. It also does not require any new protocol definitions (like > a new CEASE subcode). > > In addition, I believe that the large OPEN will not be needed any time soon and > by the time it is needed the large message capability should have been widely > deployed. Thus I think Option 1 is good and there should be no need to specify > Option 2. > > Thanks. -- Enke > > On 3/9/17 6:41 AM, Randy Bush wrote: > >>> Thank you for sharing this scenario. It would indeed work at the small cost (or perhaps not so small) to require an extra round trip at setup time which is most likely un-avoideable whatever is done. >> then a double open. i.e. a 4096 open which has the extended capability exchange and then an optional extended open randy ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow [1] Links: -- [1] https://www.ietf.org/mailman/listinfo/grow ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Do you want BGP to extend the message size for all BGP messages or just UPDATES.
Hi Randy, To never have to revisit this point, I would suggest for a capability containing a char of value N, for the N extra MESSAGE to be read before the KA, the extra MESSAGEs being OPENs, which should have the Version to Identifier data zero’ed (and ignored) with then the extra capabilities to be considered as if they were present at the end of the current OPEN. The extra OPEN being themselves up to 65k in size. Happy to provide an implementation to test against if we reach consensus. Thomas > On 9 Mar 2017, at 14:41, Randy Bush wrote: > >> Thank you for sharing this scenario. It would indeed work at the small >> cost (or perhaps not so small) to require an extra round trip at setup >> time which is most likely un-avoideable whatever is done. > > then a double open. i.e. a 4096 open which has the extended capability > exchange and then an optional extended open > > randy ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Do you want BGP to extend the message size for all BGP messages or just UPDATES.
Hello Susan. Just thinking out loud here ... Thank you for sharing this scenario. It would indeed work at the small cost (or perhaps not so small) to require an extra round trip at setup time which is most likely un-avoideable whatever is done. The issue which keeps me thinking would be which capabilities/feature should dropped in order to fulfil the 4096 bytes limit when the NOTIFICATION is received. I would rather see the OPEN stay at 4096 and have an “extended OPEN capability” than the Notification trick as otherwise newer drafts/RFCs will otherwise not cover the point. If a extended OPEN feature is added, new drafts can then decide to require the implementation of this OPEN extension, making the split easy (current capabilities in OPEN, newer in extension). Modifying the state machine to include a new MESSAGE (or extra OPEN of 65k) should not be too hard (I am sure you have heard the before :p) In every case, some wording about the Connect(Retry)Timer and DelayOpenTime may also need to be considered to make sure no large delay is introduced during the BGP setup - re-sending an OPEN immediately after the NOTIFICATION or extra OPEN/Message (if doing so does not cause an issue with the state machine). For today, with all the current RFC and drafts implemented, AFAIK we are still far from filling the OPEN, but perhaps “we" should take the time to see what the sum of of the capabilities for all the families is, to see what space is definitively left in the OPEN .. It is not unreasonable to consider that a valid capability may need some large space at some point .. https://tools.ietf.org/html/draft-walton-bgp-hostname-capability-02 <https://tools.ietf.org/html/draft-walton-bgp-hostname-capability-02> made me consider the size of the OPEN back in early 2016 - as I implemented it “for fun” at the time - So in Jan 2016 and ExaBGP still had 2*255 + 2 = 512 bytes spare in the OPEN but not much more. Sincerely, Thomas > On 7 Mar 2017, at 22:25, Susan Hares wrote: > > Thomas: > > It is possible to create an option that requires implementation support > extended messages upon receiving a notification. If the sequence is: > Open-(4097 bytes) --> > <-notification (with indication message length is too long) > > > (sequence allowed RFC4271 current FSM) > The extended messages would know to back down to 4096 and negotiate forward. > This would not let your BGP speaker get stuck. It seems reasonable to make > the code take care of this problem rather than have a crisis in an > operator's day. > > Open (< 4096) bytes) ---> > > Just let us know what you want. > > Sue > > > -Original Message- > From: Thomas Mangin [mailto:thomas.man...@exa.net.uk] > Sent: Tuesday, March 7, 2017 4:39 PM > To: grow@ietf.org > Cc: Susan Hares > Subject: Re: [GROW] Do you want BGP to extend the message size for all BGP > messages or just UPDATES. > > Hello Nick, > > I can see one reason why it would become undesirable in the future: > > If a then recent speaker, with support with this draft/RFC, and with a > yet-to be defined large number of capabilities, happened to generate an OPEN > message of 4097 bytes (to match its configuration), this OPEN would most > likely be seen as invalid by current implementations not supporting the > extension. > The excessive/invalid length when checking the OPEN message size will surely > caused the session to be terminated. > > It would therefore prevent any session to come up (even if otherwise > everything is fine). Therefore should this size extension be applied, it > should be applied to all message types BUT the OPEN message. I think we are > currently not near needing 4096 bytes for OPEN (but the day will/may come). > > ExaBGP would suffer from this issue as the check is currently performed on > ALL messages as currently specified including the OPEN. > > So I would suggest to just change the wording to include all message type > but OPEN, and leave it as an exercise to the reader to write another draft > allowing to break capabilities over multiple messages. > > Sincerely, > > Thomas > >> On 7 Mar 2017, at 21:08, Nick Hilliard wrote: >> >> Susan Hares wrote: >>> This email is to make you aware of the discussion on the Extended >>> Messages draft (draft-ietf-idr-bgp-extended-messages-21). Do you >>> want the message size extended for all BGP messages or just UPDATE >>> messages? This probably is more important if you want to have a >>> larger size OPEN, ROUTE-REFESH, and UPDATES.The IDR co-chairs >>> value the operational input from GROW WG. >> >> I don't see any reason an extended message size s
Re: [GROW] Do you want BGP to extend the message size for all BGP messages or just UPDATES.
+1 - it makes lots of sense. Thomas > On 7 Mar 2017, at 21:08, Nick Hilliard wrote: > > Susan Hares wrote: >> This email is to make you aware of the discussion on the Extended >> Messages draft (draft-ietf-idr-bgp-extended-messages-21). Do you >> want the message size extended for all BGP messages or just UPDATE >> messages? This probably is more important if you want to have a >> larger size OPEN, ROUTE-REFESH, and UPDATES.The IDR co-chairs >> value the operational input from GROW WG. > > I don't see any reason an extended message size should be limited to > just UPDATEs. Enke's suggestion for handling the single anomalous case > (OPEN) looks reasonable. I'd say, go for it! > > Nick > > ___ > GROW mailing list > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Do you want BGP to extend the message size for all BGP messages or just UPDATES.
Hi Randy, To never have to revisit this point, I would suggest for a capability containing a char of value N, for the N extra MESSAGE to be read before the KA, the extra MESSAGEs being OPENs, which should have the Version to Identifier data zero'ed (and ignored) with then the extra capabilities to be considered as if they were present at the end of the current OPEN. The extra OPEN being themselves up to 65k in size. Happy to provide an implementation to test against if we reach consensus. Thomas On 2017-03-09 14:41, Randy Bush wrote: >> Thank you for sharing this scenario. It would indeed work at the small cost (or perhaps not so small) to require an extra round trip at setup time which is most likely un-avoideable whatever is done. > > then a double open. i.e. a 4096 open which has the extended capability > exchange and then an optional extended open > > randy ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Do you want BGP to extend the message size for all BGP messages or just UPDATES.
Hi Nick, Looking at Quagga, Bird, GoBGP (I took a few minutes to read their code and I am not overly familiar with any of them), they all seems to perform the 4096 bytes check and send NOTIFICATION, so I would only expect badly home brewed solution to suffer from the issue (not to say we should not care). That said, I would also assume the code path for this scenario has never been run in production (and perhaps ever) in the life of any BGP implementation so while it may look good, it may not do what is expected. I believe some "real" world testing is in order Thomas On 2017-03-09 12:20, Nick Hilliard wrote: > Sue: I'd be cautious with your approach. First, it's not guaranteed > that some badly coded bgp stack wouldn't crash with a 4097 byte OPEN > message, and secondly, you're not guaranteed that just because the stack > supports 4097 bytes on open due to e.g. unintentional coding reasons, > that it actually supports 4097 bytes by design and that it actually > works properly. ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Do you want BGP to extend the message size for all BGP messages or just UPDATES.
(Resending as I previously use an email address which is not registered on grow) Hello Susan. Just thinking out loud here ... Thank you for sharing this scenario. It would indeed work at the small cost (or perhaps not so small) to require an extra round trip at setup time which is most likely un-avoideable whatever is done. The issue which keeps me thinking would be which capabilities/feature should dropped in order to fulfil the 4096 bytes limit when the NOTIFICATION is received. I would rather see the OPEN stay at 4096 and have an "extended OPEN capability" than the Notification trick as otherwise newer drafts/RFCs will otherwise not cover the point. If a extended OPEN feature is added, new drafts can then decide to require the implementation of this OPEN extension, making the split easy (current capabilities in OPEN, newer in extension). Modifying the state machine to include a new MESSAGE (or extra OPEN of 65k) should not be too hard (I am sure you have heard the before :p) In every scenario, some wording about the Connect(Retry)Timer and DelayOpenTime may also need to be considered to make sure no large delay is introduced during the BGP setup - re-sending an OPEN immediately after the NOTIFICATION or extra OPEN/Message (if doing so does not cause an issue with the state machine). At the moment, with all the current RFC and drafts implemented, AFAIK we are still far from filling the OPEN, but perhaps "we" should take the time to see what the sum of of the capabilities for all the families is, to see what space is definitively left in the OPEN .. It is not unreasonable to consider that a valid capability may need some large space at some point .. https://tools.ietf.org/html/draft-walton-bgp-hostname-capability-02 [2] made me consider the size of the OPEN back in early 2016 - as I implemented it "for fun" at the time - So in Jan 2016 and ExaBGP still had 2*255 + 2 = 512 bytes spare in the OPEN but not much more AFAICR. Sincerely, Thomas On 2017-03-09 12:20, Nick Hilliard wrote: > Thomas: you have more experience with this and your advice sounds > reasonable. > > Sue: I'd be cautious with your approach. First, it's not guaranteed > that some badly coded bgp stack wouldn't crash with a 4097 byte OPEN > message, and secondly, you're not guaranteed that just because the stack > supports 4097 bytes on open due to e.g. unintentional coding reasons, > that it actually supports 4097 bytes by design and that it actually > works properly. > > Nick > > Susan Hares wrote: > >> Thomas: It is possible to create an option that requires implementation support extended messages upon receiving a notification. If the sequence is: Open-(4097 bytes) --> <-notification (with indication message length is too long) (sequence allowed RFC4271 current FSM) The extended messages would know to back down to 4096 and negotiate forward. This would not let your BGP speaker get stuck. It seems reasonable to make the code take care of this problem rather than have a crisis in an operator's day. Open (< 4096) bytes) ---> Just let us know what you want. Sue -Original Message- From: Thomas Mangin [mailto:thomas.man...@exa.net.uk] Sent: Tuesday, March 7, 2017 4:39 PM To: grow@ietf.orgCc: Susan Hares Subject: Re: [GROW] Do you want BGP to extend the message size for all BGP messages or just UPDATES. Hello Nick, I can see one reason why it would become undesirable in the future: If a then recent speaker, with support with this draft/RFC, and with a yet-to be defined large number of capabilities, happened to generate an OPEN message of 4097 bytes (to match its configuration), this OPEN would most likely be seen as invalid by current implementations not supporting the extension. The excessive/invalid length when checking the OPEN message size will surely caused the session to be terminated. It would therefore prevent any session to come up (even if otherwise everything is fine). Therefore should this size extension be applied, it should be applied to all message types BUT the OPEN message. I think we are currently not near needing 4096 bytes for OPEN (but the day will/may come). ExaBGP would suffer from this issue as the check is currently performed on ALL messages as currently specified including the OPEN. So I would suggest to just change the wording to include all message type but OPEN, and leave it as an exercise to the reader to write another draft allowing to break capabilities over multiple messages. Sincerely, Thomas >> >>> On 7 Mar 2017, at 21:08, Nick Hilliard wrote: Susan Hares wrote: >>> >>>> This email is to make you aware of the discussion on the Extended Messages draft (draft-ietf-idr-bgp-extended-messages-21). Do you want the message size extended for all BGP messages or just UPDATE messages? This probably is more important if yo
Re: [GROW] ietf 97 agenda
> Have you tried? Thank you John and Job. A long time ago I got one (not personal). 19092 Exa Networks Ltd I could not recall it was allowed for individuals. Thank you for correcting my misunderstanding. Still my point stands: The problem is that developers do not know what code they can use for experimentation when they see TBD in a draft. The proposed document does not prevent anyone to continue squatting and polluting the DFZ with unknown attributes when implementing new drafts. It does ask developers to go through a convoluted way to re-encode attributes to experiment and them fully re-code the feature when it needs to go to production. Thank you but no thank you: as a developer, I just want to know that I can use some attribute code safely. AS operators will know what code is run on their kit, and can make sure that there is no conflict of experimental features. (And it would be trivial for WG chairs to make sure drafts do use different codes). Also this draft may introduce a new number of new challenges: Once we have IANA defined sub-attributes, we may also see vendors “matching” some other vendors experimental feature - which IMHO would be unadvisable. What then ? What need will vendors then have to standardise their own namespace ? Just reserving a range such (let say 200-254) for experimentation and making them non eBGP transitive would match what is already done with Private ASN, preventing their propagation is MUCH simpler, and let people experiment as they want. (see included patch which would implement such draft/RFC) Thomas — diff --git a/lib/exabgp/bgp/message/update/attribute/attributes.py b/lib/exabgp/bgp/message/update/attribute/attributes.py index cedd82b..0745117 100644 --- a/lib/exabgp/bgp/message/update/attribute/attributes.py +++ b/lib/exabgp/bgp/message/update/attribute/attributes.py @@ -227,6 +227,8 @@ class Attributes (dict): alls = set(keys + default.keys() if with_default else []) for code in sorted(alls): + if code in range(200,255) and local_asn != peer_asn: + continue if code in ( Attribute.CODE.INTERNAL_SPLIT, Attribute.CODE.INTERNAL_WATCHDOG, ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] ietf 97 agenda
Jeff, As I am not pushing for an alternate draft, would you agree that there is no need to test feature on EBGP links and that this attribute should therefore be limited to iBGP to protect the innocents ? EBGP testing should be done using the right final encoding using the proper attribute code. Sincerely, Thomas > On 21 Nov 2016, at 14:40, Jeffrey Haas wrote: > > Thomas, > > On Thu, Nov 17, 2016 at 09:40:00AM +, Thomas Mangin wrote: >> Thank you for your answer. >> I would be curious to hearing your view on the possible risks the new >> un-regulated, vendor controlled, space this draft creates as your document >> is silent about it. > > This was commented somewhat further in IDR and also during my code points > presentation in IDR at IETF 97 (suggested reading). > > There is somewhat of a need for fully private space. We're starting to see > this very strongly in data center contexts wherein BGP is used as a > transport and there's significant danger of contamination of fully internal > features leaking into the public Internet. But as I mentioned in the IDR > thread, this was not my initial motivation for the draft. It does, however, > serve as a fine starting point for that discussion. > >> I can not see why I would want to implement your draft as a step toward >> implementing another draft (the end goal) which does not require it at all, >> unless it is intended to be used like like MultiProtocol as a generic >> extension mechanism and not only a test feature. >> The implementation difficulty is not the barrier: I can perfectly see how I >> could change the class inheritance of ExaBGP while keeping the attribute >> interface to implement your draft. >> >> We need to fix a human problem : laziness, lack of time or information >> leading to the squatting. > > As noted in my code point presentation, laziness is *not* the issue. As you > note in your own response, developers need something they can use when TBD > is specified. > >> In my view, asking over-worked developers / teams to add some complex code >> to test new features mean will not lead to a behavioural change. >> All that is required is to give the developer the playground they need to >> not bother network operation, as the dangers caused by transitive nature of >> attributes were already fixed with RFC7606. >> >> “Public” IANA resource such as IP and ASN have “private” ranges, among other >> reason, for experimentation. > > Private is an excellent example. If a particular path attribute code space > was marked private, this doesn't stop the issue of collisions. If your > implementation uses 240 and another uses 240, you'll run into the same > treat-as-withdraw encoding problems we've seen with other forms of > squatting. > > Essentially, private doesn't help you. Neither does a playground. > > The fundamental issue, as noted in the code point presentation, is that BGP > path attributes have a large "blast radius". It's very difficult to keep > them localized in their current form and thus there's a need to be very > strict about what is used globally. > >> I my naive view, every draft could simply cherry pick a code. The numbers of >> “in-flight documents” is not high, I would expect simple self-policing on >> list to be enough with a large enough resource pool. >> Should a clash occur, a new draft can quickly fix the issue. Happy to hear >> if others have better ideas. > > Such "cherry picking" is essentially just squatting. It's also antisocial > in global BGP. If someone has code deployed in a transit scenario wherein > they're squatting on something that was intended to be globally deployed, > the code point is outright toxic now: you can't safely use it for either > feature. This is why there's 4 code points going through IANA deprecation > in IDR right now. > > Don't make this 5+. > >> But if an operator is willing / care enough to use experimental features in >> his production network and/or with another operator, I am pretty sure they >> will have the motivation to make sure to do their due diligence to make sure >> there is no clashes. > > They don't have the tools. > >> Perhaps the solution would be to required a “disabled until explicitly >> enabled on iBGP” default behaviour for these attribute codes. > > iBGP doesn't make this safe. > >> Optional explicit configuration of the feature eBGP session is something I >> would expect vendors to add due to customer/user demand :-) > > I do comment on this even in the experimental context in my draft. However, > this doesn't work safely in a squatting context. > > -- Jeff ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] ietf 97 agenda
Hello Jeff, Thank you for your answer. I would be curious to hearing your view on the possible risks the new un-regulated, vendor controlled, space this draft creates as your document is silent about it. > As mentioned elsewhere in thread, PENs are easy to get hence suggesting that > managed code pode. I tried to make sure that was clear in the [IANA-PEN] > link, but perhaps there's text I could add to make it more explicit? It can not harm. I was clearly ill-informed. >> Also it changes the way features are coded and would require re-coding once >> the format is stable and or the code is defined and not simply a code change >> which is for me unwise and an overkill. > > I have admittedly not taken a look at your implementation […] I can not see why I would want to implement your draft as a step toward implementing another draft (the end goal) which does not require it at all, unless it is intended to be used like like MultiProtocol as a generic extension mechanism and not only a test feature. The implementation difficulty is not the barrier: I can perfectly see how I could change the class inheritance of ExaBGP while keeping the attribute interface to implement your draft. We need to fix a human problem : laziness, lack of time or information leading to the squatting. In my view, asking over-worked developers / teams to add some complex code to test new features mean will not lead to a behavioural change. All that is required is to give the developer the playground they need to not bother network operation, as the dangers caused by transitive nature of attributes were already fixed with RFC7606. “Public” IANA resource such as IP and ASN have “private” ranges, among other reason, for experimentation. I can not se any harm to extend this principle more widely to help, not the operators this time, but the developers. >> I would rather see a much simpler solution: allocate some code point for >> development and make them iBGP transitive only, (and give operators an >> option to bypass this limit on selected eBGP links if they so wish...) > > And how would you propose to deal with code point allocation for this? For > example, we already have 255 available. A simple code is not enough, but a range would allow multiple features developed in parallel (in one code base), while also allowing possible cross vendor interoperability testing. TBD is a terrible word to read in a draft when you are trying to implement it. TDB is not a valid integer value, and 255 as a single available value is not enough, so it is not used. The wording in draft need to contain the information developers needs to implement the draft as they understand it. I my naive view, every draft could simply cherry pick a code. The numbers of “in-flight documents” is not high, I would expect simple self-policing on list to be enough with a large enough resource pool. Should a clash occur, a new draft can quickly fix the issue. Happy to hear if others have better ideas. But if an operator is willing / care enough to use experimental features in his production network and/or with another operator, I am pretty sure they will have the motivation to make sure to do their due diligence to make sure there is no clashes. Perhaps the solution would be to required a “disabled until explicitly enabled on iBGP” default behaviour for these attribute codes. Optional explicit configuration of the feature eBGP session is something I would expect vendors to add due to customer/user demand :-) Sincerely, Thomas ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Last Call: (BLACKHOLE BGP Community for Blackholing) to Proposed Standard
Hello David, Given the above, and the fact that it would require 'hacks' to realise this transitive nature, to ask the authors to reduce the scope to it being non-transitive, would render the draft somewhat impotent in these regards. I can see why there is resistance from the authors to do this. […] You worded the operational case as I also see it and notice that I did not explicitly say that I had no objection with the document as it is currently worded. Thomas ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Last Call: (BLACKHOLE BGP Community for Blackholing) to Proposed Standard
On 28 Jun 2016, at 16:36, Job Snijders wrote: On Tue, Jun 28, 2016 at 11:27:52AM -0400, Christopher Morrow wrote: that seems reasonable, though I don't think it necessarily addresses Nick's issue that: "YIKES! please don't mention that IXP's can/will do this sort of function" I still question the validity of Nick's concern. Since when do LEA read RFCs/drafts like draft-ietf-grow-blackholing and then conclude "oh, this RFC says that blackholing at IXPs can't be done, alrighty then, we'll show ourselves out!". LEAs will request what LEAs will request, regardless of technical feasibility or IETF's acknowledgement/denial a facilitating mechanism exists. Job, Not putting any particular IXP’s hat on, but as an individual I _strongly_ agree with Nick. I see no reason to mention IX in the document. The IX community is trying to make sure we do not become the filtering sink of the internet (it would not do anyone any good - except perhaps transit providers :wink: :wink:) A long time ago, working for another employer, my team wrote a software called ’CleanFeed’ (it was trademarked - a trademark now owned by BT) and then demo’ed to BT, which code named a similar project with the same name. Today, the whole UK industry has to contend with ‘ISP level filtering’. You do NOT want to open any pandora’s box. Sincerely, Thomas ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Working Group Adoption Call: draft-petrie-grow-mrt-add-paths
I support the adoption of this draft. Thomas http://exa.net.uk/about/contact-us On 2 Nov 2015, at 6:48, Christopher Morrow wrote: > Howdy WG folks, > > Please consider this the start of a 3 week Adoption call for the noted > draft who's abstract is: > "This document updates the Multi-threaded Routing Toolkit (MRT) export > format for Border Gateway Protocol (BGP) routing information by > extending it to support the Advertisement of Multiple Paths in BGP > extensions." > > Please read/comment/advise by: > 11/23/2015 - Nov 23 2015 > > thanks! > -chris > grow-co-chair > > ___ > GROW mailing list > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] BMP server implementation
Hello Robert, I follow Ryu in relation with openstack where it seems there is now several effort to use BGP for service IP announcement and migration. With decentralised announcements having a way to check that expected announcement correctly propagated make sense. I have indeed not looked at its openflow side and may well have read more to your post than was. Thomas --- from my iPhone > On 7 Aug 2014, at 12:22, Robert Raszuk wrote: > > Thomas, > > I did not demoralize anyone. > > I simply question how bmp fits Ryu. If you would know what Ryu is perhaps > typu would share similar doubts. > > Thx, > R. > >> On Aug 7, 2014 11:53 AM, "Thomas Mangin" >> wrote: >> Robert, >> >> You are perfectly entitled to this opinion - however but demoralising >> Shishio I fail to see what your post achieves ... >> >> I welcome any new implementation of any RFC defined standard. I may not have >> a use for ruy's but giving others the option can not be a bad thing. >> >> Sincerely, >> >> Thomas >> --- >> from my iPhone >> >> > On 7 Aug 2014, at 11:03, Robert Raszuk wrote: >> > >> > Hello Shishio, >> > >> > Sorry to ask the messenger, but what Ryu has to do with BMP ? Or for >> > that matter OpenFlow or OpenStack ? Enhancing Ryu with BMP is like >> > attaching a flower to the elephant :). >> > >> > Is Ryu suffering from such lack of popularity that bad so it is now >> > trying to enter BGP protocol monitoring space with its overhead ? What >> > value add Ryu provides to BMP processing or for that matter any >> > routing protocols ? >> > >> > BMP server and parser is just tiny user space code. The best is to >> > keep it standalone as far as possible from such "frameworks". >> > >> > You may find an example of an open source BMP receiver code from Stephen >> > here: >> > >> > https://code.google.com/p/bmpreceiver/source/browse/#svn%2Ftags%2Frelease-1.1 >> > >> > Best regards, >> > R. >> > >> > >> >> On Thu, Aug 7, 2014 at 9:35 AM, Shishio Tsuchiya >> >> wrote: >> >> F.Y.I >> >> Ishida-san who is NTT R&D announced Ryu has implemented BMPv3 on JANOG ml >> >> . >> >> >> >> https://github.com/osrg/ryu >> >> >> >> It supports BMPv3 and we confirmed interoperability with Cisco ASR1000 >> >> and Juniper MX960. >> >> >> >> Regards, >> >> -Shishio >> >> >> >> ___ >> >> GROW mailing list >> >> GROW@ietf.org >> >> https://www.ietf.org/mailman/listinfo/grow >> > >> > ___ >> > GROW mailing list >> > GROW@ietf.org >> > https://www.ietf.org/mailman/listinfo/grow >> > >> >> ___ >> GROW mailing list >> GROW@ietf.org >> https://www.ietf.org/mailman/listinfo/grow ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] BMP server implementation
Robert, You are perfectly entitled to this opinion - however but demoralising Shishio I fail to see what your post achieves ... I welcome any new implementation of any RFC defined standard. I may not have a use for ruy's but giving others the option can not be a bad thing. Sincerely, Thomas --- from my iPhone > On 7 Aug 2014, at 11:03, Robert Raszuk wrote: > > Hello Shishio, > > Sorry to ask the messenger, but what Ryu has to do with BMP ? Or for > that matter OpenFlow or OpenStack ? Enhancing Ryu with BMP is like > attaching a flower to the elephant :). > > Is Ryu suffering from such lack of popularity that bad so it is now > trying to enter BGP protocol monitoring space with its overhead ? What > value add Ryu provides to BMP processing or for that matter any > routing protocols ? > > BMP server and parser is just tiny user space code. The best is to > keep it standalone as far as possible from such "frameworks". > > You may find an example of an open source BMP receiver code from Stephen here: > > https://code.google.com/p/bmpreceiver/source/browse/#svn%2Ftags%2Frelease-1.1 > > Best regards, > R. > > >> On Thu, Aug 7, 2014 at 9:35 AM, Shishio Tsuchiya wrote: >> F.Y.I >> Ishida-san who is NTT R&D announced Ryu has implemented BMPv3 on JANOG ml . >> >> https://github.com/osrg/ryu >> >> It supports BMPv3 and we confirmed interoperability with Cisco ASR1000 and >> Juniper MX960. >> >> Regards, >> -Shishio >> >> ___ >> GROW mailing list >> GROW@ietf.org >> https://www.ietf.org/mailman/listinfo/grow > > ___ > GROW mailing list > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow > ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Route leaks
Hello, It is from 2007 but may still be relevant to this work :-) http://thomas.mangin.com/data/pdf/LINX%2057%20-%20Mangin%20-%20BGP%20Leak.pdf IMHO, any solution should allow to implement the solutions presented but more easily. Thomas On 26 Jul 2014, at 18:14, Doug Montgomery wrote: > What seems necessary to address the set of problems we examined is the > ability to: > > 1. Tag additional semantics for an individual announcement who's meaning is > globally known. > > 2. To have these tags be transitive, remaining on the route end to end (not > just one hop). > > 3. In speaking to operators who were concerned about intentional leaks of > routes to critical infrastructure, it seems that the tags should be secured > so that a party anyone where on the net could verify which AS added the tag > on transmission to specific peer, and verify if a tag had be modified or > stripped in transit. > > It did not appear to us that this was achievable with current community > mechanisms. One could easily implement such semantics through some new > variant of community+protections, but it did not seem the current mechanism > addressed what we perceived as the requirements. > > dougm > > > > > On Fri, Jul 25, 2014 at 3:12 PM, Tony Tauber wrote: > How is this different than tagging with communities today? > In either case, the provider's correct action on the semantics is needed (and > can go awry through misconfiguration). > > Tony > > On Fri, Jul 25, 2014 at 1:40 PM, Doug Montgomery wrote: > The last point that Sriram made is important to the higher level discussion > of the problem. > > Semantically what we are proposing is that a BGP speaker can ad a semantic > tag to a route that describes restrictions on the intent of the authorization > that is implicit in sending a peer a BGP route. > > Note that the one tag we suggested was not "DOWN" or "CUSTOMER" it was the > intent that the sender expects that you will not redistribute this update to > transit providers. > > "I am sending you this route, but I do not wish it propagated to your > providers" > > So discussing the semantics of the tag: what that tag applies to (e.g., > specific route, vs peering session), what the tags attempt to signal, what > the security properties of such a tag should be, and what policies might one > build using such tags ... is the important part. > > The specific encoding proposed was the result of one attempt to think through > these issues ... but not all the thoughts made it into the draft. > > > > dougm > -- > DougM at Work > > ___ > GROW mailing list > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow > > > > > > -- > DougM at Work > ___ > GROW mailing list > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow signature.asc Description: Message signed with OpenPGP using GPGMail ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] current state of BMP implementations?
Hi Stephen, This is great news. Thank you for this work, Thomas On 3 Jun 2014, at 17:55, Stephen Stuart wrote: > Bertrand Duvivier was kind enough to refer me to someone at Cisco who > provided some BMP V3 sample data, so the monitoring station code at > https://code.google.com/p/bmpreceiver/ has been updated to understand BMP V3 > as spoken by a Cisco (thanks, Bertrand!). I'm happy to take patches to fix > assertions or expand the printing of BGP message content (especially > multi-protocol NLRI information), and it's always nice to get new files of > sample data. > > Stephen > > > On Tue, Nov 5, 2013 at 3:34 PM, Stephen Stuart wrote: > https://code.google.com/p/bmpreceiver/ > > Tested against the JUNOS draft -01 sender implementation. > > Stephen > > > On Tue, Nov 5, 2013 at 2:21 PM, John Kemp > wrote: > On 11/5/13 11:07 AM, Jeffrey Haas wrote: > > On Tue, Nov 05, 2013 at 09:32:16AM -0800, John Kemp wrote: > >> Can anyone summarize the current state > >> of the Juniper or Quagga work on BMP? > > BMPv1 support has been available in JUNOS for a while now. > > BMPv3 support will be in 13.3. > > > > -- Jeff > > Anyone publish any client station code? > > John Kemp > > ___ > GROW mailing list > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow > > > ___ > GROW mailing list > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow signature.asc Description: Message signed with OpenPGP using GPGMail ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] last call for draft-ietf-grow-ix-bgp-route-server-operations
support Thomas On 19 Mar 2014, at 13:12, p...@lugs.com wrote: > Hello all, > > This is the last call for the draft-ietf-grow-ix-bgp-route-server-operations. > This document has been discussed at multiple meetings, and on the mailing > list. > > Although this is last call, we ask for those who have reviewed the document > to voice their opinion that the draft is ready for submission, and of course > point any issues related to why the draft is not ready. > > The last call will end 2nd April 2014. > > Thanks > > peter > ___ > GROW mailing list > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow > signature.asc Description: Message signed with OpenPGP using GPGMail ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] call for adoption draft-snijders-rpsl-via-03
+1 Thomas On 19 Mar 2014, at 13:09, p...@lugs.com wrote: > Hello all, > > This past IETF job snijders presented the draft draft-snijders-rpsl-via-03. > I would like to initiate the call for adoption. There was support for this > work at the meeting in london, and we would like confirmation on the mailing > list before adopting the work. > > Please read the draft at > https://datatracker.ietf.org/doc/draft-snijders-rpsl-via > > Thanks > > peter > ___ > GROW mailing list > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow > signature.asc Description: Message signed with OpenPGP using GPGMail ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Fwd: [iab-ch...@iab.org: Call for Review of draft-iab-filtering-considerations-06.txt, "Technical Considerations for Internet Service Blocking and Filtering"]
I only read the document once but from my experience as an operator of a network based L7 filtering solution for schools ( and ICAP ), I found no issue with the definition problematic or the technical limitations described. Without getting into details about the different options and their pros and cons - I see little which could be added but perhaps adding to the reading material list Richard Clayton's excellent work on the subject : Failures in a Hybrid Content Blocking System http://www.cl.cam.ac.uk/~rnc1/cleanfeed.pdf Ignoring the Great Firewall of China www.cl.cam.ac.uk/~rnc1/ignoring.pdf Thomas Mangin Sent from my iPad > On 5 Feb 2014, at 23:21, Nick Hilliard wrote: > > should grow people consider whether to comment on this? > > Nick > > Original Message > Subject: [iab-ch...@iab.org: Call for Review of > draft-iab-filtering-considerations-06.txt, "Technical Considerations for > Internet Service Blocking and Filtering"] > Date: Wed, 5 Feb 2014 14:17:27 -0500 > From: Jeffrey Haas > To: na...@nanog.org > > It's IETF stuff. Operator sanity check would probably be appreciated. :-) > > -- Jeff > > - Forwarded message from IAB Chair - > > Date: Wed, 29 Jan 2014 11:16:56 -0500 > From: IAB Chair > To: IETF Announce > Cc: IAB , IETF > Subject: Call for Review of draft-iab-filtering-considerations-06.txt, > "Technical Considerations for Internet Service Blocking and Filtering" > > This is a call for review of "Technical Considerations for Internet > Service Blocking and Filtering" prior to potential approval as an > IAB stream RFC. > > The document is available for inspection here: > https://datatracker.ietf.org/doc/draft-iab-filtering-considerations/ > > The Call for Review will last until 26 February 2014. > Please send comments to i...@iab.org. > > On behalf of the IAB, > Russ Housley > IAB Chair > > - End forwarded message - > > > > ___ > GROW mailing list > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow > ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] current state of BMP implementations?
Hello Robert, Some people have asked for it ... I have been quite busy recently so it did not make it to the top of the list. At the moment, BMP is processed by a separate application but I intend to change this when I implement v7. Like everyone my issue is that I need more hours in my days :-) This year, I updated ExaBGP's code to be able to pass raw packets to the backend process (and not only a text or JSON representation) so serialising them on disk using the MTR container format should not be to hard to add. If many people are saying that they would use it, then I will bump the feature up the list. Thomas On 10 Dec 2013, at 09:24, Robert Raszuk wrote: > Do you have also plan to add MRT encap to ExaBGP ? > > Thx, > r. > > > On Tue, Dec 10, 2013 at 10:20 AM, Thomas Mangin > wrote: > Feel free to CC me so I can make sure the capture(s) work with ExaBGP too > when I upgrade BMP v7 :-) > > Thank you, > > Thomas > > On 9 Dec 2013, at 20:32, Stephen Stuart wrote: > >> If you can send me some output of your BMP implementation captured with >> netcat (or equivalent), I'd be happy to work on making the receiver >> implementation work against it (see https://code.google.com/p/bmpreceiver). >> >> Thanks, >> Stephen >> >> >> On Tue, Nov 5, 2013 at 12:06 PM, Bertrand Duvivier (bduvivie) >> wrote: >> Hi, >> >> FYI for Cisco, >> >> BMP development is completed for IOS-XE and IOS classic. >> >> Implementation is based on BMPv7 >> FCS target Nov 2013 (few more weeks) >> >> One small deviation from the BMPv7 draft: >> We also added few extra BMP statistics: few TCP stats, the goal is to >> monitor/detect slow peers by monitoring TCP. >> >> Current BMP (cisco) stats and values are: >> 32767 : SRTT: the Smooth Round-Trip Timer is a measurement of the average >> time that it takes a packet to be sent and acknowledged by the remote peer. >> 32768 : RTTO: the round-trip timeout in milliseconds. >> 32769 : RTV: the variance of the round-trip time in milliseconds. >> 32770 :KRTT: the new round-trip (K stands for Karn's algorithm) timeout. It >> measures the round-trip time, in milliseconds, for packets that have been >> retransmitted. >> 32771 :minRTT: the smallest round-trip timeout. >> 32772 :maxRTT: the largest round-trip timeout. >> 32773 :ACK hold: the acknowledgment delay timeout used to delay >> acknowledgements to allow time to add data to the packet. >> 32774 :Datagrams: the largest data segment in bytes >> >> Working with author to standardize these stats, will update our >> implementation as soon as standardized. >> >> BRGDS Bertrand >> Cisco BGP product manager. >> >> From: Jeffrey Haas >> Subject: Re: [GROW] current state of BMP implementations? >> Date: November 5, 2013 8:07:36 PM GMT+01:00 >> To: John Kemp >> Cc: grow@ietf.org >> >> On Tue, Nov 05, 2013 at 09:32:16AM -0800, John Kemp wrote: >> >> Can anyone summarize the current state >> of the Juniper or Quagga work on BMP? >> >> BMPv1 support has been available in JUNOS for a while now. >> BMPv3 support will be in 13.3. >> >> -- Jeff >> ___ >> GROW mailing list >> GROW@ietf.org >> https://www.ietf.org/mailman/listinfo/grow >> >> ___ >> GROW mailing list >> GROW@ietf.org >> https://www.ietf.org/mailman/listinfo/grow >> >> ___ >> GROW mailing list >> GROW@ietf.org >> https://www.ietf.org/mailman/listinfo/grow > > > ___ > GROW mailing list > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow > > signature.asc Description: Message signed with OpenPGP using GPGMail ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] current state of BMP implementations?
Feel free to CC me so I can make sure the capture(s) work with ExaBGP too when I upgrade BMP v7 :-) Thank you, Thomas On 9 Dec 2013, at 20:32, Stephen Stuart wrote: > If you can send me some output of your BMP implementation captured with > netcat (or equivalent), I'd be happy to work on making the receiver > implementation work against it (see https://code.google.com/p/bmpreceiver). > > Thanks, > Stephen > > > On Tue, Nov 5, 2013 at 12:06 PM, Bertrand Duvivier (bduvivie) > wrote: > Hi, > > FYI for Cisco, > > BMP development is completed for IOS-XE and IOS classic. > > Implementation is based on BMPv7 > FCS target Nov 2013 (few more weeks) > > One small deviation from the BMPv7 draft: > We also added few extra BMP statistics: few TCP stats, the goal is to > monitor/detect slow peers by monitoring TCP. > > Current BMP (cisco) stats and values are: > 32767 : SRTT: the Smooth Round-Trip Timer is a measurement of the average > time that it takes a packet to be sent and acknowledged by the remote peer. > 32768 : RTTO: the round-trip timeout in milliseconds. > 32769 : RTV: the variance of the round-trip time in milliseconds. > 32770 :KRTT: the new round-trip (K stands for Karn's algorithm) timeout. It > measures the round-trip time, in milliseconds, for packets that have been > retransmitted. > 32771 :minRTT: the smallest round-trip timeout. > 32772 :maxRTT: the largest round-trip timeout. > 32773 :ACK hold: the acknowledgment delay timeout used to delay > acknowledgements to allow time to add data to the packet. > 32774 :Datagrams: the largest data segment in bytes > > Working with author to standardize these stats, will update our > implementation as soon as standardized. > > BRGDS Bertrand > Cisco BGP product manager. > > From: Jeffrey Haas > Subject: Re: [GROW] current state of BMP implementations? > Date: November 5, 2013 8:07:36 PM GMT+01:00 > To: John Kemp > Cc: grow@ietf.org > > On Tue, Nov 05, 2013 at 09:32:16AM -0800, John Kemp wrote: > > Can anyone summarize the current state > of the Juniper or Quagga work on BMP? > > BMPv1 support has been available in JUNOS for a while now. > BMPv3 support will be in 13.3. > > -- Jeff > ___ > GROW mailing list > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow > > ___ > GROW mailing list > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow > > ___ > GROW mailing list > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow signature.asc Description: Message signed with OpenPGP using GPGMail ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
