Minutes IETF106: grow
minutes-106-grow-00

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

Agenda:
    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
    draft-ietf-grow-bmp-tlv

    re-Charter Discussion
    Please discuss on-list

Presentations:
    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.

    draft-lucente-grow-bmp-tlv-ebit

    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
    https://tools.ietf.org/html/draft-haas-idr-extended-experimental, 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.

    Questions:

    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

    next-up

    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:

        draft-chen-grow-enhanced-as-loop-detection

    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 guidance.

    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 unhappy

        • 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