Minutes for IDR at IETF-96
minutes-96-idr-2

IDR IETF-96
Berlin Germany
Sue Hares, John Scudder Chairs

=====================================================

: o Administrivia
:   Chairs                                                 10 minutes
: 
:   - Note Well
:   - Scribe
:   - Blue Sheets
:   - Document Status
: 
Sue: good amount of work done @ hackathon on LS, no interims planned

: 
: o Segment Routing document updates                       15 minutes
:   draft-previdi-idr-segment-routing-te-policy
:   draft-ietf-idr-te-lsp-distribution
:   draft-ietf-idr-bgpls-segment-routing-epe
:   draft-ietf-idr-bgp-prefix-sid
:   draft-gredler-idr-bgp-ls-segment-routing-ext
:   Stefano Previdi
: 
Stefano: 
draft-ietf-bgp-prefix-sid is stable implementations, WG last call
suggested
bgpls-segment-routing-epe, WG LC suggested 
draft-previdi-idr-segement-routing-te-policy - WG adoption requested,
implementation (requested on the mail list) 
draft-ietf-te-lsp-distribution - IP tunnels, SR TE policies, MPLS cross
connect state in one draft [in peofewaa] 
draft=gredler-idr-bgp-ls-segment-routing - move to WG adoption, IANA
code-point request 
draft-ietf-idr-te-pm-bgp - BGP-LS TLVs for TE metrics [WG LC] 

Sue: Question: 
Robert Raszuk: Does this work need to be redone to have its own IGP. 
Stefano: If you are going to use BGP as an IGP per new draft, isn't that
recursive (BGP-LS in BGP-LS) ...
Hannes Gredler: It is the good, the bad, and ugly (BGP..)
Stefano: I will wait the outdome for this. 
Acee: Presumably you could use the same encodings in BGPLS encodings.
Looks like non-issue anyway
Stefano: Intuitively yes, base BGPLS spec is about LS topology.
Sue: WGLC for prefix-sid, segment-route-epe, adoption for
segment-routing-te-policy, tr...sp? gredler-ls-segment-routig WG
adoption and code point allocation. (? missing one)


: 
: o Large BGP Community                                    10 minutes
:   https://datatracker.ietf.org/doc/draft-heitz-idr-large-community   
:   Jakob Heitz
: 
Discussion:
Tony Przygienda: Are we suppose to interact with extended communities? 
If it is linked to extended communities. 
Jakob: Just for the larger communities. 
Jared Mauch (NTT): Extended wide community draft will be updated to
explain this. This is _only_ fixing 1997.
Job Snijders (NTT): Cannot turn up a peering session with a 32 bit ASN
because of the current community scheme.  We should not be using private
ASNs in the global administrator field in 1997 communities due to chance
of collisions. This proposal solves these issues. 

Jeff Haas: The wide community has been updated to a type 2.  They were
looking to a more dense 
- take it into a common header document (a community container), 
- The type - and have it with 
- Add a textual representation. 

Hannes: 1997 communities are fixed length.  Extended Communities are
fixed length (longer).  
The community section here is still fixed length.  Why not make it
variable. 

Jakob: This was discussed at great length.  It is complex to have a
variable length community. 
We will have a single length community.  Well add another container
type. 

Robert: Razsuk - we could have a container type with large,
extra-larger, extra-extra life. 
I do not think there is a header.  

Jakob;  We need to have an RFC. 
David Lamperter (Quagga): Do not over-engineering this document. 

Jakob: It has changed dramaticaly since it was first put out. 

John: It does not sound you are ready for WG Adoption.  The WG is ready
for your work.  

Jeff: Already there in existing WG-adopted work. Needs Splitting.  Up to
the working group how it wants to handle adoption process for the split
documents.

: 
: o BGP-Based SPF                                          15 minutes
:   https://datatracker.ietf.org/doc/draft-keyupate-idr-bgp-spf/
:  Acee Lindem
: 
Raszuk:  Slide number 4 
(missed a section) 
Jeff: We used a replacement of IGP capabilities with a BGP transport.
(Makes sense). 
Hannes: I am a link-state guys.  Historical context for massive the IGP
could not handle the flooding code.  Now you have flow control in BGP. 
BGP guys can do flooding similarly than the IGP gusy.  It is not a good
idea to put SPF in BGP.  With BGP-LS we stopped, but 

Acee:  We realize there is an important decision to determine which
NLRI.  Yes, we were thinking about version and lifetime  

Hannes: I you mut re-implement the issue of scaling.  

Acee: Why is this worth than BGP As an IGP.  

Hannes: BGP localizes link-failures, this won't.  

Rob: We stated with BGP-LS, we stated that it should not share fate with
LSP.  We should really go back and characterize how a 
Jeff: The good thing about the back of the line.  Your comments are
made.  The flooding with version numbers causes further churn because
you bypass BGP's state suppression mechanisms.  This makes your general
problem get worse.  BGP is about damping state suppresion.   You are
going to find you cannot suppresion.   Since the IGPs require
information to be flooded in a constrained amount of time for a
consistent domain-wide SPF, you will find that you have problems due to
state delay.

Acee: We will look at these cases. 

Jeff: You are using the wrong handle.  Use the IGPs. Consider going to
the IGP WGs and using TCP there to solve the problems in writing IGP
code in the open source environment.

Randy Bush: I am channel keyur patel.  
Pro/cons - failures go everywhere including.  They simplify there are 
He disagrees with that 
He disagress that the blast radius of changes impacts. 

Acee: in the RTGWG draft, the prefixes go every where.  

Tony P:: IT is circumstancial that youa are working with BGP.  You will
re-invent the whole flooding and what you seek you can do by building a
new protocool being IGP over TCP with an element per fragment.  

Acee: This is a good point. You do have operational experience,
robustness. 

Tony: You have a hammer - BGP.   It is a fairly poor argument when it
comes to protocol design.  

Marti Djernas: 
Keyur: When you go down that road, you will implement something like
BGP.  
Tony: Nothing force you away from using BGP and BGP-LS packet formats
Keyur: We have a hammer, it is an effective Keyur. 

Stewart: When did IP Fast reroute, the problem is the update of the FIB
so how is the 'faster convergence' argument true?

Acee: The update of the FIB is still a part of the whole convergence. 

John Scudeer: Response to keyur about reinventing the packet formats;
people who've done this for a while understand that packet formats are
the easiest part of the protocol.  The "stuff for further study" are the
hard stuff.  I have a lot of respect for the stuff in the IGPs.  Scared
by "we should shove this all into bgp since we have the formats"

Acee: Transport as well.
John: We just leveraged tcp. you can do so as well.  
John: As Napoleon said,  "C'est magnifique, mais ce n'est pas BGP" 
(correction, it wasn't Napoleon being misquoted, but Pierre Bosquet)
Xiahou: The win is to traffic engineering in BGP. 
Acee: It definitely could be done. The encodings are already in bgp-ls.
Just a matter of making sure the data is consistent.  If you accept BGP
for the SPF, you should be able to do so for SPF using existing TE
encodings. You could do, but it's not part of the scope of this effort. 
TE doesn't always involve an SPF.  
X: You require MPLS.  
A: Everything is being added to BGP-LS. It's a matter of computation and
other stuff to do it.  If this was successful beyond all expectations,
then we could do TE. Coudl coexist in a controller based solution as one
example. Think it's out of scope right now.  Could use a different
algorithm if you wanted; you have the full domain topology.  Typically
TE sent in via some path computation element anyway. 
X: If TE is out of your scope, just need SPF, why not just use IGP?
A: Flooding problems everyone talking about. But also advantages we went
through.  In controller based solution, can do centralized TE on top of
SPF.
Stewart Bryant: With an IGP, there's a lot of stuff other than topology;
e.g. OAM neighbor discovery, hello state, MTU.  When using a centralized
controller, how do you discovery to centralized controller or neighbor.
A: Depends on peering model. In simplest model, you get it all via the
BGP session.
SB: ... you're directly connected. Need address of your neighbor.
A: Configuration. LLDP, CDP, etc.  Auto-configuration is another part of
the solution. 
SB: Independent of SPF solution, for interoperable solution, those
things need to be thought out, standardized. Where are we for that?
A: LLDP is a standard.
SB: LLDP doesn't provide L2 to L3 mapping.
Jeff Tantsura: You're not trying to replace IGP. Trying to focus on data
centers.  BGP in large DC, you'd export your topology directly.  ...?
A: DIdn't see TE wouldn't be done distributed.
Rob Shakir: Advantage of BGP in large DC, ops understand.  This isn't
just BGP LS, this is a series of other changes.  What's the advantages? 
BGP-LS is not a tech that we have a lot of experience with.  Would like
to see the analysis rather than the sales pitch.
A: Feels like we've been working on BGP-LS for a long time.
RS: Very long time after stuff starts shipping until we get operational
experience.



: o Carrying Geo Coordinates in BGP                        10 minutes
:   draft-chen-idr-geo-coordinates-01
:   Enke Chen 
: 
Sue: Concern with distribution of the sensitive GeoLoc information
(security privacy) 
Jeff: resolution of GPS coord should be provisioned to avoid thrash.
Acknowledged privacy consideration but this should be added as privacy
considerations section to draft.. Aggregation of path attribute, hence
we need to define that; merge, drop? 
Snijders/NTT: is that origin?  
Enke: It is where it originates. But you can add/replace information.
You can prepend the ifnromatino.  
Snijders/NTT: It might be interesting to put this under the BGP
Community Container header. 
Enke: We feel it is better to stand-alone. We think it is clearner. 

Randy: There is not enough value to take the risk of two security risk
- location of my device , 
- governments get better accuracy. 
Perhaps if it was near by coffee. 

Robert: I agree about the security issue. It should be encrypted. 
Enke:  Overlay network has no privacy issues. 

Rüdiger Volk: I got nervous about the geo-location services.  For my
work, topology is easier.  My comment is: work first on Jakob's Large
Communities. 
Job Snijders (NTT): We tag our routes with community that indicates
where the routes were received. If this exists, then the errors we have
with the system can be avoid. For me a system indicating a radius of 100
Km would be good enough.

: 
: o Extension to BGP's Route Refresh Message               10 minutes
:   https://www.ietf.org/internet-drafts/draft-idr-bgp-route-refresh-
: options-00.txt 
:   Tony Przygienda 
: 
Lucy Yang: rfc7543 already allows for subset of prefixes. 
TP: Normal ORF or one shot?
JS: CP-ORF.

Robert Raszuk: What's the interaction with RT-C? 
TP: Not better than RT-C, if you're willing to specify a RT and toggle
them on/off, you have to maintain an RT per-set.
RR: ?
TP: Keyur and I agree that RTs there are respected, this goes on top.
RR: RD based filterign.  They are locally assigned.
TP: EVPN is sitting on structure.  Agree in principle fact has overtaken
us.
Rüdiger Volk: BGP peers are supposed to have some consistency. 
Undermined here.
TP: Yes, undermined via specs.
RV: Specs doing so are ill-advised in first place. Nevertheless, last
time we saw something like this it was argued that this would be helpful
to recover broken routers.  Thought it was stupid to do so.  We are
doing away with this consistency function.
TP Consistency is warrantied for set you're interested in.  EVPN
example.  Add a multicast RT, end up 50M updates to get 20K routes.
RV: Classic case for BGP.  I'm pissed if my basic assumptions are
violated.
Jie: One time ORF idea expired.
TP: Looked at it.  Overlapping transactions.  One shot almost could do
it.
Jie: The one time ORF idea expired.
John: mic cut. please continue on list.

: 
: o Path Redirect Action                                    5 minutes
:   draft-ietf-idr-flowspec-path-redirect 
:   Gunter Vendevelde
: 
(no slides)  - 
Gunter vandeVelde: Absolutely no semantics was of concern. 
Path-redirection-03 merged with ?.  Think document is in reasonably good
shape. Mostly to clarify text.  Add a few more pieces of use-case
context. What is the meaning of some of the layers of context?  W.r.t.
the validation process, clarified and will be in -04.
Lucy Yang: TID useful for sequence purpose.  Could impact how it goes
through data plane.  No description how you do that?  
G: Will cover that use case scenario for sequencing segments in next
rev.
LY: Use case is clear, but data plane is not.

: o RFC5575bis (Flow Spec bis)                             10 minutes
:   https://datatracker.ietf.org/doc/draft-hares-idr-rfc5575bis/
:   https://datatracker.ietf.org/doc/draft-hr-idr-rfc5575bis/
:   Susan Hares, Robert Raszuk
: 
Enke Chen: Proposing to modify original doc as a bis.  Consider doing a
smaller clarifications doc?
SH: Always easier to write shorter draft, but the updates in the process
is a lot harder.  More concerned about getting the feedback.
EC: Concern is about opening things up for a bis that everything is on
the table.
SH: Think process issues in both cases.

Robert Raszuk: Spent 10 years to get 5575 in shape we have it in.  Not a
fan of opening full bis.

: 
: o BGP Flow Specification Version 2                        5 minutes
:   https://datatracker.ietf.org/doc/draft-hares-idr-flowspec-v2/
:   Susan Hares 
:          
: o BGP Flow Specification Filter Component for Time Constraints
:   https://datatracker.ietf.org/doc/draft-liang-idr-flowspec-v1-time/
: o BGP Flow Specification V2 Component for Time Constraints
:   https://datatracker.ietf.org/doc/draft-liang-idr-flowspec-v2-time/
:   Jianjie You, Qiandeng Liang                            15 minutes
:   
: Total                                             1 hour 45 minutes
: