notes-interim-2016-idr-5

Agenda for IDR Virtual Interim Meeting

May 16, 2016
22:00 - 23:00 EDT

WebEx: https://ietf.webex.com/ietf/j.php?MTID=m9be481d19988dd1b545be6759aee267b
Meeting number:        649 235 411
Meeting password:        Jg66d2pm

Join by phone
1-877-668-4493 Call-in toll free number (US/Canada)
1-650-479-3208 Call-in toll number (US/Canada)
Access code: 649 235 411

Recording: (1 hour 1 minute)

Streaming recording link:
https://ietf.webex.com/ietf/ldr.php?RCID=18809569d575428db56252b203bb1058
Download recording link:
https://ietf.webex.com/ietf/lsr.php?RCID=0d29b7628bb39b1b2a3904df09daf369
Play Recorded Meeting Now
Play Now

John: Thank you to Eric and Gunter for creating the slides at a short notice.
      Does anyone have additional questions?

Questions for meeting:

Submitted by (Eric Wu)
1. Redirect-to-Specific-Tunnel with BGP Path Attribute [TUNNELENCAPS][MPP] and
Redirect-to-IID/GSID, Required by different use cases, can we have two docs in IDR In parallel?
[Comparison to Redirect-to-IID/GSID , draft-hao will have little modification
to existing mechanisms, No need to do Mapping /Recursive Lookup.]

Discussion:

John: What I saw from the mailing list discussion, is that the group did not appetite for pursuing 2 or more solutions. If we have consensus on this topic, it is that we pursue one solutions.
Lucy: We should have one solution to handle the tunnels. If we think one solution is not enough, then we can go forward.
Sue: +1 on one solution.

2. For IID/GSID, one mapping table for
all kinds of segments/forwarding-entities vs. one mapping table
per segments/forwarding-entities type, should we support both?

Discussion:

John: Does anyone thing we should support both?
Jeff: I will repeat the comment on these drafts. Things that are driven by things which are abstract. Someone will need to provision the redirection ID. This is still not handled in Gunter's draft. The SIDs do provide. I am not sure what the TIDs.
John: I am not sure what the TID is either.
John: Gunter's comment from

This is an interesting discussion.
draft-vandevelde has the capability to optionally couple semantics to a mapping table.
This capability is a powerful tool. Because of this capability currently both (1) and (2) are possible with draft-vandevelde.
in addition alternate creative categories could be i.e. : (3) a mapping table per flowspec controller or (4) a table per tunnel configuration method/controller.
draft-vandevelde can enforce semantic coupling or can permit freedom to an operational user… There are pro's and con’s for each, and i welcome the WG to provide guidance on the operational implications to complement draft-vandevelde…

Eric:

per my understanding, when multiple extended communities carried, the TID field is used to identify what is the usecase.
From the slides, nested tunnels, multi-path, push SR segments

* Gunter (voice issue): the TID is to allow more than one indirection community to be attached to the flowspec route.

It allows to first idirect to the first identfier and then the 2th indirection followed with the 3rd one can be done.
It was to allow for example first to indirect to a next hop and then indirect to a next interface... a bit like EPE. (end)
Lucy:

3 use cases are talked about on the draft.

Flowspec over IP tunnel
Flowspec over the TE Tunnel

My question is how can the draft show how to guarantee going over a tunnel.
This is why we suggest the service type and field is better.
We want to have the segment type that types the indirection point.

John: The two drafts have converged into a selector field and type.
Sue: This is my understanding as well.
Jeff: Is this an ADD-Path function for this comm unity? (Referring to Gunter's comment above.)

* Gunter: not really.. in AddPath the routes are equal and the best one is selected. In this case it the intent is to use all four section.
Jeff: This is a behaviorial chain.
Gunter: It would be a chain:

first community: To send to a egress router,
second community: to allow TE.

Jeff: I will repeat an earlier observation I made.

These are extended communities and different systems add different extended communities.
Due to this the specifications must be very clear, so it can be work.
In this specification, if you have a TID=0 present multiple times, it must be clear what that means.

Lucy: You can define what type of tunnel you use as a default.
Jeff: This puts us back into the same problem with mapping that are inconsistent.

The biggest problems is that the service providers are not fond of configuring VRFs to configure their networks. This took us into redirect IP. The problem of the draft-vandevelde-idr-flowspec-path-direct and draft-li-idr-flowspec-redirect-generalized-sid is that both allow locally identified tunnels.
Both drafts have a value for SID values - SIDs have mechanisms to permit routing-system-wide consistency.

Lucy: Both of the SID/SR and other types of tunnels are useful.

The protocol should allow SID/SR or locally identified tunnels.

Chair Questions:

1) Does the WG feel we need the following for RFC5575bis (DDoS)
a) Redirection to VRF (RFC5575)
b) Redirection to Indirection to IP
c) Redirection to Service?

Lucy: Redirect to Service can cover VRF and Indirect to IP.
Jeff: If I were going to take to make this general:

1) One option for SID/service. SID is globally distributed
2) Idea for completely router-local mapping of Service ID

Is this a correct observation Lucy and Gunter?

Gunter: There is a global binding to a number (via IDR)
     and a locally configured tunnel. (So, yes -- to Jeff's question)

Lucy: This is indirection to IP tunnel
Jeff: Can I restate what you just said - the mapping distribution
       mechanism is alway global, but the encapsulation is locally selected.

Lucy: Yes - both.
Gunter: This is the same thing as you mention.
Jeff: The SID maps to a well-known distribution.
        The completely local mapping (IDR ID to local mapping).
        It is a number and has no meaning.
        Is your point that a number and an address have no difference?

Gunter: In the global ID field, one of things is that
            we can signal some portion of semantics that
            each of these values will be linked to a encapsulation
            type on the local router. This is the way it is being
            used in the SID/Segement - that maps SID/local Segement.
            We can extend our current idea to the other global IDs.

Jeff: A personal observation is that Gunter's mechanism is
       extremely opaque. In contrast the other draft is exposing the
       details in a less opaque fashion - to IP and Specific opaque.

Gunter: This is correct. We could

1 - Segment routing
2 - for IP and context
3 - for redirect Next Hop

    There are pros/cons for both.

Jeff: Coming at this use cases, the fact that the two things
       contrast is the level of opaqueness. The WG
       should be asked where the level of opaqueness.

Lucy: I agree that we need to discuss the level of opaqueness.
         We need to know what the local machine wants.

John: To thrown in my individual contributor hat,
        draft-vandevelde threw in the B bit and stated
        they could extend it further. You see in Computer Science,
        it is easy to make it general, but it is harder to make it
        just structured enough. (Assembler vs. Higher-level language).
        The working group is trying to determine what the most structured
        thing we can do is, that still provides the needed flexibility.

Jakob: The Flow specification runs will go to many different routers
       in many different places. The tunnels will look different to
       others. To statisfy that consideration it is important to have an
       abstract ID that goes to different routers.

John: That is a good point.

Jeff: What is an anycast look-like for redirect-IP.
        This draft-vandevelde opaque would look like this
        for an anycast report.

Jakob: I can agree with this point.

Lucy: I do think we have two clear use cases:

SID/Segment
opaque/redirect that is locally defined.

Sue: Redirect for IP or anything?

Lucy: I think it should be Redirect to anything?

Jeff: By analogy it could be a redirect to a L2TP tunnel? Which on most
systems is seen as an L2 interface.

Sue: Are we agreeing for all 3 use cases?

Jeff: Both drafts do something the redirect-IP

encapsulation (opaque ID/value)
Resource is non-IP (SR SID)
If these are two key properties are missing?
Do we need to go for new drafts or missing functionality or is this a BIS on redirect-ip.

Lucy: This is your redirect-ip flow specification draft?

Jeff: This is redirect-ip for flow?

The fundamental behavior redirect-ip for flow spec is to redirect something to
an end-point for redirected draft (the packet may also be copied).
The address may not be directly connected or sent across a tunnel.
Just as your drafts, the BGP next-hop may not be directly attached -- The BGP resolver.

Lucy: Your point is that the redirect-ip can be recursively

Jeff: You allow for one end-point to be identified by multiple service.
- The thing that is missing from redirect-ip is the tunnel type.

Lucy: The point is the redirect IP needs to be recursive.
- the hao-redirect-tunnel - was to a specific tunnel,
- The binding also need to be SID/Segment or type/tunnel.

Jeff: One of the deficits of the redirect-ip is that the tunnel
must be pre-provisioned. If you are running LDP, it is easy.
If you are running RSVP-TE, it must be set-up ahead of time.

Lucy: Since our draft has a mechanism to set multiple types.

Gunter draft is for a more generic tunnel - so they have a logical ID.
We may need both specific types and generic tunnel to provide the mapping necessary for the points.

2) If the WG desires redirection to Service routing, Does the WG desire
a) Next-Hop tunnel support? -
b) Next-Hop TE Tunnel support?
c) Nested Tunnel support?
d) Next-Next Hop Tunnel Support?
e) Router localized Tunnel recursion?
f) Tunnel Encap Recursion:

(skipped)

3) What pieces of the proposed solutions have been implemented
   and/or deployed?

John: I would love to hear about deployed solutions or working in lab.
Of course, we can have something

Lucy: We have something implemented on this draft. I do not know the details as I am in the US.
Weiquo: We also have some cooperation with China Mobile on a redirection

Lucy: Please ask for vendor implementation on the list.
John: Yes, I will. Of course, this will go the mailing list wel.

John: This brings us to the end of the meeting or times.
          I want to thank people for preparing for the presentation ahead of time.
Lucy: We should work on a better phone system for China
Sue/John: We are working on it.

John: Thank you for hanging in late at night.

Presentations (prerecorded, please review prior to meeting):

- draft-vandevelde-idr-flowspec-path-redirect
Gunter Van De Velde
21 minutes
https://ietf.webex.com/ietf/ldr.php?RCID=e01d62661085f660f470feddd9bf266f

presentation at:
https://www.ietf.org/proceedings/interim/2016/05/16/idr/slides/slides-interim-2016-idr-5-0.pdf

draft-li-idr-flowspec-redirect-generalized-sid
20 minutes

Streaming recording link:
https://ietf.webex.com/ietf/ldr.php?RCID=c8615aa845801a1e4b79cb1708a04484
Download recording link:
https://ietf.webex.com/ietf/lsr.php?RCID=4bd504329727d2a811c9cb0c9bc713d8

presentation at:
https://www.ietf.org/proceedings/interim/2016/05/16/idr/slides/slides-interim-2016-idr-5-1.pdf