* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Grow Status Pages

Global Routing Operations (Active WG)
Ops Area: Ignas Bagdonas, Warren Kumari | 2003-May-02 —  

IETF-106 grow minutes

Session 2019-11-22 1220-1350: Canning - Audio stream - grow chatroom


minutes-106-grow-00 minutes

          Welcome to Etherpad!
          This pad text is synchronized as you type, so that everyone viewing
          this page sees the same text. This allows you to collaborate seamlessly
          on documents!
          Get involved with Etherpad at http://etherpad.org
              Existing Drafts (10 mins)
              draft-ietf-grow-bmp-adj-rib-out - RFC8671
              draft-ietf-grow-wkc-behavior - RFC8642
              draft-sa-grow-maxprefix - Adopt?
                  •     Will not happen in GROW
              draft-ietf-grow-bmp-registries-change IESG bound
              draft-ietf-grow-bmp-peer-up Adopted
              re-Charter Discussion
              Please discuss on-list
              Camillo Cardona
              BMP Marking Extensions
              Draft overview: tries to communinicate the path status via BMP,
              be it best-path or otherwise
              Open Questions:
              Today the path-status is a different field, we might become very
              successful so maybe we want to have the path status be a variable
              length field
              Defintiitons of path status outside the BMP path marking draft -
              we might not have it defined in the draft, perhaps it will be
              somewhere else
              No Questions
          Next up:
              BMP loc-RIB - Paolo Lucente - NTT presenting
              No questions
              BMP-TLV support
              Adding TLV support to peer-down and route monitoring messages,
              update version number to support backward compatability
              Next steps: no open questions, we should wrap-up (last call?)
              Job/Chairs: Looking at implementors in room, are we good to go
              Jeff Haas/Juniper: I think there's a desire to make this done
              soon, and I think what you're going to find is this is a plug-in
              architecture for the rest of the group.  If you try to finish this
              now, we will have to do it again.
              Supporting of enterprise-specific TLVs in BMP
              Borrowing from idea in IPFIX for using PEN/IANA assigned private
              enterprise number.
              John Scudder/Juniper: We have seen at least one proposal of this kind
              in IDR also.  I think it's a fine solution for the problem, but the
              push back we heard - when I use this playground to experiment in,
              I have to change my packet format when it is standardized.  We have
              to try it to find out how it plays out. I don't believe this will
              get rid of squatting, but we might as well try.
              You could be lazy in two directions, you could define a code point
              in enterprise space, and may never migrate to IANA assigned space.
              Everyone has to put enterprise data into code base, or it ends up
              in RFC.  4 bytes of enterprise space, and 2 bytes of IANA space
              Jeff Haas/Juniper: John is likely referring to
              and since people seldom get features right the first time, do people
              break their deployments by re-using the code points or use one from
              a larger range.
              The majority of comments I have on BMP - I'm wondering if the chairs
              would entertain 5 minutes at the end?  (chairs: yes)
              Job Snjiders/NTT: The goal here is to have specifications that promote
              interoperability, what I worry about is that if we allow enterprise
              type TLVs we do not meed the objective of standardizing protocols.
              I also am very concerned about squatting in the space.
              Jared Mauch/Akamai: I think the point here is sometimes you need a
              standardized place to put your unique innovations to avoid squatting.
              Job/NTT: What you said here reminded me of the 'MAC Address Local
              Administrator bit' and how you can flip a single bit to achieve local
              significance. Perhaps a single bit is all that is needed rather than
              using PEN addresses.
              Ruediger Volk/DT: Jareds comment about making the metadata explicity
              managed, TLV makes it eaiser to parse and interpret
              BMP in MRT : Colin Petrie/NTT
              I put this together as an intitial idea to use MRT which is explicitly
              for this purpose.  It supports type codes, so they can be added to
              and archived.
              MRT files are usually stateless, split by various time intervals
              and need to be parsed independently from the previous file.
              RV/DT: What you are talking about it essentially information from the
              presentation layer, it's incredibly hard to transition to something
              more future proof
              Jeff Haas/Juniper: This presentation is worth doing
              Thank you Colin
              Yunan Gu
              BGP route policy trace with BMP
              We have been working with the team at Swisscom and they are interested
              in this draft.
              We have restructured the format, the data around the prefixes,
              attributes are not together.  We have moved it into a TLV format.
              I'm looking for feedback on the future direction of this draft
              RV/DT: I'm really surprised I did not forsee this, you are mentioning
              that the policies are complex.  The actual content and intent and use
              has complexity, I'm not sure if I am happy to include this complexity
              - which is related to the presentation layer.
              Job/NTT: I think it's an interesting discussion about what it means.
              I'm planning on looking at the work in the CBOR WG, there may be
              some appliciability here.
              Jeff Haas/Juniper: This is the exact comment, there's many binary
              protocols - the presentation of the binary may be unclear, but using
              a yang model would allow us to decode the message
              Next presentation:
              BMP for route leak detection
              I am looking for feedback on this proposal
              Alexander Asimov/Yandex:
                  Since this draft depends on ASPA roles, that data isn't there
                  on a per-prefix basis.
              Jared Mauch/Akamai:
                  Much of this depends on the business logic, and while BMP is a
                  great way to monitor the routes they may be unique based on the
                  provider relationship and there's no good way to understand the
                  intent behind the routing announcement.
              Next Presentation:
              Routes with a AS_PATH loop in them may need to be detected for hijack
              cases, but the detection can be used to find configuration errors.
              Please send feedback to the mailing list for discussion
              Alexander Asimov/Yandex: My message is - the way it's stated in the
              draft, where you take updates is not limited to the scope of what's
              causing the route hijack or leak.  It may have some prefixes captured
              by the upstream provider - these prefixes are seen from the outside.
              Also, it may highlight there may be a policy issue.
              Spealing of hijacks: BMP has a lot of options to be used, but getting
              experience in how it can be used, what information can be easily
              revealed in the monitoring.  It would be very interesting for the
              industry to take up.
              Thomas Graf/Swiscomm: Maybe a use-case, perhaps use the signed origin
              for example
              Improv part of session - 5 minute update on their hackings
              We identified issues with the draft-ietf-grow-bmp-local-rib -
              it doesn't define what should happen when the route is locally
              originated, should provide some recommendations around the next-hop
              The peer-up message isn't consistent between vendors, should we make
              them consistent
              Chairs: Thank you for the report!
              Presenter: Paolo Lucente/NTT
              Compression of BMP route monitoring messages
              It's beleived that BMP may generate a lot of data, flag compressor
              info in a TLV in the init message
              John Scudder/Juniper: I hadn't heard of this work prior to this
              meeting, it's a very short draft.  I like this work.  The one warning
              is that tonys draft is an individual submission
              Ignas Bodonis/Equinix: Yes this is needed, this addressses a real
              problem on the processing side of the received BMP messages
                  •     What you are proposing a single message compression,
                  is that valuable vs a larger set of data?
                  •     removing the marker will deserialize the message, this
                  may take out some of that message
                  •     having a mechanisim to signal when compression starts
                  may be of value to avoid replaying the entire stream if it's
                  written to disk
                  • Job/NTT: the topic of compression has come up in idr, if it
                  were to become a wg item, it would concern me as an operator.
                  often times when it comes to routing, it can be of importance to
                  understand what happened on the wire and what's flowing through
                  the system.  I have concerns about debugging this.
                  • Jared Mauch/Akamai: I may be bandwidth blessed, so I'd like
                  to understand from other operators (in private) what they see
                  as the issue, i'm concerned about any delays in the data flow
                  due to batching.
                  • Paolo: I've heard this from multiple sources since Chicago,
                  I share the same concerns
                  • Presentation/Jeff Haas:
                  • The architectural implications of PDU formats - they have
                  limitations - things that slow down the data flow make networks
                  • 1) BMP is basically BGP - anything that happens in one
                  impacts the other
                  • 2) the majority of this is tagging the data on top of the
                  attributes, if you are doing anything else with it, it forces
                  the unpacking of the message.
                  • The other general problem is that BMP has loc-rib and rib-out
                  have strong correlation with existing data structures directly
                  available, if the data that needs to be encoded isn't directly
                  available, it may cause either memory or cpu impact to find or
                  store that information more readily.
                  • What we are doing in each of these BMP presentations is
                  adding some level of annotation to the BGP messages
                  • Recommendations: stick to core uses cases.  For telemetry
                  try to stick with the same data format.  Several things involve
                  attaching a string or parsing a string, we know this is very
                  expensive to parse things with scanf()
                  • John Heasley/NTT: YOu mentioned dictionaries, would a registry
                  of the meanings make sense?
                  • Jeff: many of these deserve a registry, there will always
                  be something proprietary about where in the policy it's rejected
                  may not be standard
                  • Paolo/NTT: If you remember the packing isn't optimal, should
                  we restructure these to make more sense?
                  • Job/NTT: you are offering us foundational insights to help
                  us better design protocols

Generated from PyHt script /wg/grow/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -