notes-ietf-107-idr-1

IDR Virtual meeting 1: 9-12pm EDT on March 30, 2020

Note: These are rough minutes without editing.
Due to IETF 107 Virtual IDR sessions (3/30 and 4/8)
These are going to be refined as we go.

WebEx: https://ietf.webex.com/ietf/j.php?MTID=m826dbbaa863e1be3da21760e550c06dd

Etherpad for note-taking: https://etherpad.ietf.org:9009/p/notes-ietf-107-idr-1?useMonospaceFont=true

Etherpad for virtual blue sheet: https://etherpad.ietf.org:9009/p/notes-ietf-107-idr-1-bluesheet

Topics:

    1. Chairs’ slides – 2020 in IDR     10 mins
    Two meetings (3/30 and 4/8) --- another one pending if we miss one
    Plea for minute taker
    Authors of BGP open policy ask for WG last call. Will do it soon.

    2. What’s next in Flow Specification    20 mins
    Review:
    Discussion:
    Question 1: What do operators need from FlowSpec now
Jeff: flowspecv6 is relatively easy. v6 parity. Changing the NLRI is difficult with existing RFC 5575. Introducing TLV is important. The ordering is tricky. Flowspec is about firewall rules.
    Some things we can do with a flowspec v2. Incremental deployment considerations will be hard.
Sue: Some discussion on the list about OID. People say it can be done with existing features such as:
Jeff: 5575bis could be shipped. Believes consensus to not fold in OID
Sue: 5575bis is in IETF last call. It would be interesting discussion.
Jim Utaro: OID is one of the widest uses of FlowSpec and it should be folded in to the base spec
John: (relay from Robert in Jabber) Changing the format of NLRI without introducing new AFI/SAFI would be challenging (not only for flowspec).
Jeff H:
John: The 5575bis was intended to be quick and backward compatible.
Sue: Is flowspec path redirect need ordering?
Jeff H:
Sue: flowspec nvo3 and l2vpn,
Jeff H: It is about matching criteria. flowspec interface may be used for inter-AS.
Sue: Summarize the discussion with Jeff.Do we need to go to the V2 with new format of NLRI?
Jeff H:
Sue: Asking the operators for feedbacks.
Sue: Do we have dependencies on other IDR work?
Jeff: About large community, there was no distinguisher number field in the LC.
John: relay the comments on webex chat between Job Snijders, Jeff and Randy.
Job: question: what does flowspec have to do with large communities?
Jeff: job, people want to encode actions inthem

Acee: There is an individual draft for well-known large communitities
Jakob: I can present that next week

Randy: Will post a link to a paper ... which shows that encoding *actions* in communities is a serious attack vector
https://archive.psg.com/181101.imc-communities.pdf

    3. Progress report from Auto-Configuration Design team     20 mins

    Jie Dong (presenting for design team) -
    requirements: agreed (short list) + collected (under discussion)
                  Not agreed to (collected from presentations)

    Design principles: Under discussion

    Sue Hares: Do you want discussions now or on the list or both?
    Jie Dong: Both

    Design principles: (needs discussion) - current
         1) independent from BGP session
         2) not affect/change BGP session establishent

    Robin LI: What ports are used on each of these work?
    Jie Dong:

a) first one - LLDP + (?) UDP port
b) second one - use Open BGP + L3DL, less changes
- c) Third one has new BGP format
Jeff: Where are the attributes for the protocols
a) interface address configuration - address link locals
b) global addresses (AS, IEEE addresses)
c) Data center may require other things
Robin Li: (comment on page 8)
a) Provide layer 2 keep-alive message for session continuity
Jie: This is provided from L3DL draft, and one of the
L3DL draft. This feature is not fully discussed by the
design team.
Robin Li: This is not adopted yet. This may be a little complex.
Randy: Slides 8 and 9 - are specifically not requirements.

     We are still looking at them out of the corner of our eye.
   Warren: Layer 2 - like BMP; should this be used in BMP (?)
   Jakob Heitz: Like Robin, Iquestion the layer 2 requirements.

   Toerless Eckert: Are we going to use Building blocks
      Like CBOR CDDL for message encoding ? This would uplevel the
      discussion. Also GRASP as a simple message framework
    supporting simple L3 and L3 discovery.
   Jie Dong: We can discuss the encoding later.
     Right now we are discussing design principles.
     (The example encodings are for design discussion).
      We'll follow up on this later.

   Randy: The group is very much tryin to: a) be as simple possible,
     b) to do as little as possible to let be possible to let
        BGP open do its work.
    Jeff: +1 to Randy's comments.
    We are trying not to be intrusive.
    The features with LDP is to leverage switch concepts.
    Most of our analysis to bring BGP up.
    The encapsulation and transport is flexible.
    Elements have role based on where they are plugged into in th DC network.
    For example: leaf nodes,
    Helping with debug mis-connectivity is useful,
    but not necessary. Another example is determining the
    BGP role.

Randy: The complementary view is that the types of
roles and numbers of role are dependent on what
operators is doing. A mechanism that provides
operator configured roles may be better than the

Jeff: I agree with Randy. This is why the draft(?)
was left very generic.

Adam Vitkovsky: I would like to have less features
in my BGP run in the end.

John: Anyone else making comment?

Next steps:
a) confirm minimal set of common requirements
b) reach consensus on the design priniciples,
c) put these into a requirements discussion
d) solution discussion to WG
John: When can we get these steps completed?
Can we get the proposed requirements by summer?
Jie: The requirements by summer will work.
We will need feedback on the design principles.
John: It would be good to create requirements draft.
Design principle.
Randy: We are heading toward the tough discussion
of the transport and key point.
- We need time in the year of the "plague"
- to complete this work?

   Susan: Is this a month or 2 months?

   Jeff: We need to do further work prior to discussion.
          (+1 Randy)

   John: We do not want "jiggle" your elbow.
         Let us know when you are ready.
         If you need the WG's feedback, a
         WG draft is what is needed.


    4. Presentations – new drafts or status updates         60 mins

    1) draft-li-ldr-bgp-request-cp-sr-te-policy-01
    Draft: https://tools.ietf.org/html/draft-li-ldr-bgp-request-cp-sr-te-policy-01
    Presenter: Huaimo Chen
    Time period: 10 minutes [10:29-10:40]
    Comments:
    Ketan Talaulikar: This draft proposes an extension for BGP to support
    a request/response mechanism for SR Policy. We know that
     BGP does not natively support such transaction
    mechanism unlike PCEP. Can the authors please
    describe how this mechanism is supposed to work
    and how such SR Policie are going to be maintaine?

    Huaimo: We use a special flag in request to controller.
    When it is a request, the flag is set and when the controller respond. Do you have any other suggestions.

    John Scudder (WG member): Concern that BGP uses state compression.
    PCEP already has this feature?
    Jeff Tantsura: +1 to John Scudder
    Jeff Haas: Bess keeps trying to do things like this. and it fails in unhappy ways
    Jakob Heitz (from chat room): BGP is not a request/response. Why not use PCEP?
    Huiamo: Good question. PCEP is used on controller, while BGP is also supported on controller.

    Ketan: It is not just request/reply but also need to main the
    SR Policy through it's lifetme. It would help the WG if the authors
    It is not just request/reply but also need to maintain the SR Policy through it's entire lifetime. It would help the WG if the authors could describe the entire proposal in sufficient details - i.e. the entire lifecycle of the SR Policy.
    Could describe the entire proposal in sufficient deatils.
    - i.e. the entire life cycle
    Huaimo: In the next version, more details will be offered.
John: Suggest to solve the comments offline.

    2) draft-chen-idr-ctr-availability-00
    Draft: https://tools.ietf.org/html/draft-chen-idr-ctr-availability-00
    Presenter: Huaimo Chen
    Time period: 10 minutes   [10:40-10:50]

     Discussino:
     Linda: Why not use virtual IP to represent a cluster of controllers?
     Then the applications can use the virtual IP
     Huiamo: To the outside, it is one controller. Within the controller,
     it is a single controller.   Within the controller, the controllers
     will be out of sync. If the controllers are out of sync, the controllers
     will incorrectly set-up the network.

     Huimao: You are talking about multiple controllers.

     Linda: Take the PE out of the design. Hand off between the controller.

     Jeff Tantsura: What are the changes that controllers get particitioned
     but still maintain connectivity to the network?
     If a NE can reach both = perhaps it can also route between controllers
     We have been doing database synchronization

    Acee: These clusters have to talk to each other. Doing the high-availabilty
    outside the clusters into BGP does not make any sense? We are not
    to the point where we have two controllers so standardized that you can take
    it off the s

    Huiamo: Can you provide the

     Tony P. (Moderator): Inventing PASOX over BGP is
     John Scudder(participant): You might look at zoo-keeper.
    Agree with Acee, there are ways to do this,
Jakob: the only case you have partition is the PEs also have a partition.
Robert: I said the same comment on zookeeper a few weeks to the IDR list.,
Huiamo: I think this has a simplier. The information exchange is minimum.

    3) draft-qin-idr-sr-policy-ifit-00
    Draft: https://tools.ietf.org/html/draft-qin-idr-sr-policy-ifit-00
    Presenter: Giuseppe Fioccola
    Time period: 10 minutes   [10:50-11:00]

    Rakesh: Is this for end-to-end case, or it is also for hop-by-hop case?
    Giuseppe： Yes it can do both.
    Rakesh: So it will be done in BGP and PCEP?
    Giuseppe: Yes.
    avitkovsky:
    Giuseppe:
    Jeff: What kind of dynamicity you expect this for a path?
    Giuseppe: (Flexible) you set different options to set the level of
    dynamic features. [missed full details]. The active probing
    is a dynamic approach.

    Jeff: BGP does best with passive or stable. If you are looking at dynamic,
    you may have route churn.

    Giuseppe: We are investigating PCEP and BGP. There may cases where BGP
    is a better usage and others with PCEP.

    Jeff: Your motivation is a path analysis. My gut assumption is PCE is better.


    4) draft-wang-lsr-ifit-node-capability-advertisement-00
    Draft: https://tools.ietf.org/html/draft-wang-lsr-ifit-node-capability-advertisement-00
    Presenter: Yali Wang
    Time period: 10 minutes   [11:00-11:10]

    Rakesh: I understand the requirement for encap/decap at the end notes.
    I do not understand the encap/decap at the intermediate notes.

    Yali: We extended the protocol to signaling to ____

    Robin: For the intermediate node, the OAM will use the IPv6 will
    use the hop-by-hop header. The routers will send ththe packet to CPU, and will cause packet drop.

    Rakesh: Two questions: a) capability and b) use by the intermediate notes.

   Robin: the capability is advertised by egress and intermediate nodes. The rule of enabling IFIT for a path is advertised using SR policy.

   Rakesh: Thank you Robin.

    5) draft-liu-idr-flowspec-ifit-04
    Draft: https://tools.ietf.org/html/draft-liu-idr-flowspec-ifit-04
    Presenter: Yali Wang
    Time period: 10 minutes   [11:10-11:20]

    Acee: I sorta see the community (to turn on/off).
    Why do you want this in the flow specification. I think you just need a tag in the packet for IOAM.
    Are you trying to prevent attacks that are coming in via OAM?

    [Question will be responding in the mail list]

    Jeff: Use case 1: Flow specification injected route
     will need OAM to provide DDOS.

    Acee: The community provides the Use Case 1.

    Jeff: Use Case 2: The type of OAM information for a specific flows.
    Two types for flow-specificaion (BGP Flow specification,
    and PCEP flow specification), I would like to get OAM
    information for a route flow-specification this is use.
        For Example, a TCP flow using this port/address.
    Netflow triggers information. It could useful to send
    this informatino.

    Robin: Jeff's discussion is the purpose for these
    two drafts (5 tuples flow and handling). You can see
    how the OAM can be aggregated and focused.



    6) draft-dunbar-idr-sdwan-port-safi-06
    Draft: https://datatracker.ietf.org/doc/draft-dunbar-idr-sdwan-port-safi
    Presenter: Linda Dunbar
    Time period:    [moved to 4/8/2020]

   Feedback on the IDR WG:
    In the deployement use different instances to present difference instances,
    should we use something like a Route Target with a different name?
    SDWAN Target:

    John Scudder (WG member): You can call it what you want as long as it clear.

    Linda: Similar, we would use the same purpose as SAFI 128, but use a different
    SAFI for SDWAN.

    Robert: Maybe take AFI (v4/v6). No different safi as far as RFC.
    The different AFI/SAFI is an implementation

   Linda: That is a good. Depending on different egress you need encryption.
   It is much simplier in implementation

   Robert: It is a feature to keep isolation.

   Donald Eastlake: There are more AFIs/SAFI.

   Jeff Haas: Address is the address type, and SAFI sub-types.
   Jeff: It is unfortunate we split into 2 spaces, since it turns out to be

   Robert: At some point we wante dto really combine into 3 octets.
   John: The 3 bytes are just code point.