Minutes for IDR at IETF-88
minutes-88-idr-1

IDR - IETF 88, Vancouver
Chair: John Scudder
Notes: Primarily Jeff Haas
Jabber Scribe: Shane Amante

Audio: http://www.ietf.org/audio/ietf88/ietf88-regencyc-20131108-0900-pm3.mp3
Slides: https://datatracker.ietf.org/meeting/88/materials.html

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

Interdomain Routing (IDR) WG

FRIDAY, November 8, 2013
0900-1100 PST    Friday Morning Session I
Regency C
=====================================================

CHAIR(s):  Susan Hares <shares@ndzh.com>
           John Scudder <jgs@juniper.net>

o Administrivia
  Chairs                                               10 minutes

  - Note Well
  - Scribe
  - Blue Sheets
  - Document Status

o draft-ietf-idr-aigp-10 last call issues              15 minutes
  http://tools.ietf.org/html/draft-ietf-idr-aigp-10
  Eric Rosen

o draft-ietf-idr-add-paths-09                          10 minutes
  http://tools.ietf.org/html/draft-ietf-idr-add-paths-09
  Jeff Haas

o draft-haas-idr-flowspec-redirect-rt-bis-00            5 minutes
  http://tools.ietf.org/html/draft-haas-idr-flowspec-redirect-rt-bis-00
  Jeff Haas

o draft-ietf-idr-sla-exchange                           5 minutes
  http://tools.ietf.org/html/draft-ietf-idr-sla-exchange
  Shitanshu Shah

o draft-wu-idr-te-pm-bgp-03                             5 minutes
  http://tools.ietf.org/html/draft-wu-idr-te-pm-bgp-03
  Qin Wu

o draft-patel-raszuk-bgp-vector-routing-00             10 minutes
  http://tools.ietf.org/html/draft-patel-raszuk-bgp-vector-routing-00
  Keyur Patel

o draft-li-idr-cc-bgp-arch-00                          10 minutes
  http://tools.ietf.org/html/draft-li-idr-cc-bgp-arch-00
  Lizhenbin (Robin)

Speaker Shuffling Time                                  5 minutes

Total                                           1 hour 15 minutes

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

The below minutes copied from Etherpad
(http://etherpad.tools.ietf.org:9000/p/notes-ietf-88-idr?useMonospaceFont=true)

IDR Meeting, John Scudder Chairing.

Note Well.

Document Status: Due to John's laptop being broken, it will go out to the list
in the next few days.

Agenda.

Presentation BGP Vector Routing, Keyur Patel for the authors.

Lucy Yang, Huawei: Is the vector node attribute new?
- KP, yes.
- LY since this is applied to VPN, how is it related to Route-Target policy?
- KP, it's an attribute. The routes in the VPN will be tagged with their own
RTs.  These addresses could be VPN or regular. - LY, Can be used ibgp, ebgp or
vpn. In VPN, with RT import/export policy? - KP, business as usual. - Robert
Raszuk - doesn't override any VPN rules we already have.  In the VPN context,
VRF context service nodes. - LY: Could be in destination routing table. - KP:
Services needed in network are tagged with this attribute.  All BGP speakers
should install it and do the necessary thing. - Steve Patrick, Google: How do
you do ECMP with this?  Anycast? - KP: yes. - Xiaohu Xu Huawei: Any node in the
vector route, BGP router or could be non-BGP router? - KP could be non-bgp
speaker. - XX: How can that router forward the packet further? - KP: Depends on
the network. Consider IPv4 network. - XX: Slide says no changes in forwarding
plane. - KP: Correct. - XX: How can you get NH info from packet. - KP: This is
a BGP based mechanism. The transit router must either be BGP, or if not, pull
it from static information.  Forwarding is separate from encapsulation. - XX:
List of nodes in packet? Otherwise non-BGP routers may need that? - KP: They
may be static routes. - LY: Need some local configuration to nail down this
behavior. - RR: No local configuration needed.  Vector nodes must be BGP
speakers.  Transit nodes don't need to be. - LY: Tunnels! - John Scudder: There
is an important speaker between vector and transit nodes.  A few comments: 1.
Re: WG adoption - there was a well attended SFC BoF.  Unclear if ADs will
charter, but seems likely.  In that charter would be service chaining
architecture. - RR: If we remove service chaining from this and leave TE, would
this fit? - JS: Probably so. - LY: But you'd need a valuable use ase. - JS: One
of the points was that "service chaining" is a misnomer.  Really service
composition - i.e. graph.  This draft only covers strictly a chain.  It may be
useful to place this in the context of that group's architecture. - KP: We deal
with paths in BGP.  We carry chain that affects that path.  Draft doesn't deal
with graph, but we can incorporate [...?] - JS: Really saying that this needs
to go into the context of the architecture. - Rudiger Volk: Not really able to
grok the content presented.  Feel uncomfortable that there's no meat in the
security considerations section.  Don't buy it. - KP: The only comment they'll
make is that this solution works with the security mechanism that the provider
implements. - RV: In particular, if attributes for controlling the traffic are
passed inter-domain, I find it hard to believe that if there is nothing to
ensure the integrity of the data... - JS: If you think you're going to get away
with the security section today, you're "charmingly optimistic". - RR: We do
check that those nexthops are inserted by that AS.  Aside from that, we're not
doing more than setting the nexthop.  In SFC, interdomain was left out of
scope. :-)  Even so, all protocol extensions will happen in respective groups. 
Think it fits in IDR. - JS: Saying "interdomain is out of scope" doesn't mean
"IDR gets to do whatever". [09:26] - JS: Not saying we can't work on this in
the group, take it to the list, ask for meeting time.  It's only the WG
adoption that's an issue. - RR: What would it take to get chairs to consider
the TE-only case. - JS: It's the WG's decision as a whole, not just the chairs.
- Jakob Heitz, Ericsson: Do all the nexthops need to be reachable at the
beginning or later on.  Cases for both. - RR: Checking the next-one.  If you
think there's need to check more, let's talk. - KP: Draft may need some sort of
long-length check, - LY: Possible use case for TE, may need to think about loop
prevention. Both in regular and VPN environment. - RR: No loops - list of
nexthops.  If you want to go through same node twice, that's allowed. - Eric
Rosen, Cisco: From what I understand from SFC BoF, decisions might be made
based on DPI.  Strugglign to see how this mechanism can be used for that. - KP:
[...]? - ER: Classification,if not based on destination address, this doesn't
seem applicable. - RR: We can use flowspec on this. - ER: Impose spec based on
DPI? - RR: Yes. - KP: That's one way of doing it.  This mechanism doesn't
impose that the chains are done op-by-hop - it's by the forwarding plane. - ER:
how would that work? - Thomas Morin, Orange: carry chain naming information in
control plane mechanisms? - LY: How do you plan to handle TTL? - KP: We don't!
- LY: How do you expect the forwarding plane to handle this? May create a loop!
- KP: List of nexthops aren't re-used.  Please post scenario. - JS: You just
told Eric that traffic could be diverted.  Our current protocols say you can't
create forwarding loop that isn't terminated by policy.

Questions to WG:
Authors say there's a SFC case and a TE case.
How many people have read? Quite a lot.
How many think the WG should work on the TE case?
- Robin, Huawei. This isn't the first time that TE in BGP has been brought up.
Adoption for TE? Authors and a small number.
Needs work before adoption: lots
SFC case: no one.
Please take this to the mailing list, but keep working on use cases.  Thanks
for very productive conversation. LY: Please throw idr into WG draft name.

[09:38]

Presentation: AIGP last call issues, Eric Rosen.
- John Scudder: Question about multiple TLV with same code point. If processing
in reverse order, have you convinced yourself that it's okay? [09:49] - ER: If
you get some garbage that happens to look like a type 1 TLV, it's hard to say
what's going to go wrong.  Didn't think that two type1 TLVs was going to be a
problem on its own.  Bigger issue would be that someone thinks of a use of two
type 1's in the future. - Bruno deCraene, Orange: This is different than what's
in draft error-handling. - ER: There will be many more people in this room with
experience in this aspect of BGP than I.  It would be good to address this
particular issue.  Clearing the transitive bit shouldn't make this worse. - JS:
As an error handling co-author. I'm inclined to agree, the WG should reconsider
thaas pect of the group. - Shane for Pratima: The draft needs to define the
behavior when the aigp value has reached its maximum. - JS: We should say
something about this in the draft even if it didn't come up during WGLC.  Would
you prefer it to come up during ietf or iesg last call? - Stewart Bryant: The
only question is best for the protocol. - ER: Is it broken? - Rob Shakir: Is it
broken or will it break? - ER: Is the spec broken?  If not, then changing the
spec will more likely make the spec more fragile. - JS: Concerned that this
might be unspecified. If the range is so large, this may never happen. - Jeff
Haas: Better to say that this going to cap at a maximum value and if they need
a larger value, then use Type 2. - ER: OK, so you're worried about wraparound. 
Can look at that.  Metric should not wrap around.

[09:57]
- Defaults.  Some controversy still on list.
- A recommendation to disable attr. on iBGP session as well, but don't think
this is really necessary, because it's unlikely operators will not go around
randomly enabling on BGP sessions. - JS: Your provisioning system required both
ends. - RV: If enabling can only happen on one side, but you can't tell, saying
I want to receive then expecting the sender to send it probably doesn't work. -
ER: Shouldn't there be a capability?  No, not for every new optional attribute.
[10:02] - Robert Raszuk: New draft posted that encapsulates aigp attribute into
cost community. Didn't discuss punching holes in best path selection, either,
in AIGP draft. - ER: That draft is 5 years too late. - JS: Are you suggesting
that something be changed in aigp spec? - RR: Ideal situation to merge drafts.
- ER: When talking about cost community, if we held up everything when someone
said we should do it a different way, nothing would advance. - JS: This is what
the UPDATES field in the RFC is for.

John Scudder:
Deck covers the open issues.
For purpose of resolving WGLC comments.  Next step would be to consider all of
these.

[10:23]
Presentation: SLA Exchange
Cisco has an implementation.
- John Scudder: Is there field experience with the feature?
- Solely internal at the moment.

[10:26]
BGP attribute for north-bound distribution of TE performance metric, presented
by Qin Wu

[10:06]

Presentation: Advancing add-path, Jeff Haas.

- Current status: well deployed by at least 3 vendors.
- Concerns about advancing add-path
  + People weren't sure about how it would behave within a hop-by-hop network.
  + Issues are much better understood nowaways & documented in
  draft-idr-add-path-guidelines.  Separate draft will carry these forward.
- An issue that we still have is: how do we deal with fast convergence?
- Have normative reference to draft-pmohapat-idr-fast-conn, which contained
Edge_Discrimintor Path Attr. - As far as Jeff knows, there are no
implementations of this feaure. - Know that operators are getting good
benefits. - People on list raised that this might be useful in Route Server
environments.  Not doing traditional BGP, doing proxy BGP, so perhaps not
critical there. - Question for WG is: we have a stable draft, it's deployed
everywhere, should we remove the Normative Reference to advance - Are you aware
of add-paths features?  Lots of hands - Should add-paths advance in absence of
Edge_Discriminator feature?  Lots of hands. - Opposite question: Should we not
advance it?  No hands.

- Robert Razsuk: If we make this feature optional, does that solve your problem?
- JH: Probably split into 2 cases.  That draft contains good guidelines on how
to make your convergence faster.  But, also muddies the waters by throwing in
eBGP.  Recommendationis to separate the two out and get rid of eBGP side. - RR:
??? - JH: Agree, but larger issue is do we hold up this draft waiting for a
feature that no one has implemented.  Need to also see 2 implementations, per
IDR tradition. - RR: Different thing to advance add-paths for iBGP vs. eBGP. -
JH: Do we need to add to add-paths that there is an outstanding issue with
eBGP? - RR: Let's put it to the list.  Add-paths draft is just encoding.  Use
cases were removed from it.  So, not a good idea to put it back.

JH: One additional issue.
Current draft just says whether you're sending or receiving add-paths.  Is the
WG interested in discussing adding a cap on the # of paths you're willing to
accept from remote peer? - RR: It was discussed in base draft.  It got really
hairy, particularly from perspective of RR. - Adam Simpsion: a number of
implementaitons already support that capability. - JH: Will take that up with
people to suggest a path forward. - Eric Rosen: Have experience with that and
would recommend to never do it. - JH: Attempting to keep progress on

[10:18]
Jeff Haas: Next Presentation
- Flow Spec Extended Community
- Allows traffic to be redirected to a VRF
- Issue is: 0x8008
- Small fix: suggest that this has same encoding as RT extended community
- Create IANA Registry

- JS: How many think WG should take this on?  Decent # of hands?
- JS: How many should not take this on?  No hands.
- Eric Rosen: Are you familiar with Ext. Community Registry draft?
- JS: Yes
- ER: Please make sure this draft aligns with organizational principles of that
draft - ER: Draft reorganizing it has been sent to IESG. - JH: Has that draft
been scheduled on IESG telechat? - Stewart Bryant: It's either on a telechat or
on a Last Call - JS: OK, let's move foward.

[10:22]
Inter-Domain SLA Exchange, Shitanshu Shah
- Concern that parameters were already defined and should re-use those.
- Re-use IPFIX for Traffic Classifier & TSpec for rate profile
- Have working implementation of the draft
- Submitted implementation report for the draft
- Looking for more implementations

[10:25]
JS: Do you have field experience?
SS: No, just implementation experience, for now.

[10:25]
BGP attribute for North-Bound Distribution of TE performance metric, Qin Wu
- Re-use BGP-LS attribute with 7 new TLV's to icnlude link delay, link
variation, packet loss, BW, etc. - Think it is better aligned with BGP-LS and
think it is ready to request WG adoption.

[10:31]
Questions?
- JS: Of those who read the draft, how many think this is ready for WG
adoption?  Yes: Decent # of people.  No, need more work before adoption:
Nobody.  We'll take it to the list.  Sense of the room is to adopt it.

[10:32]
Architecture of Central Controlled BGP, Robin @ Huawei
- Yesterday, presented similar topic in OSPF WG
- Reference Model: BGP controller controls BGP clients in its administrative
domain - Decouple BGP client and forwarding - Need protocols extensions to
connect BGP controller and BGP clients
  + Need IGP extensions to automate Auto-Discovery, Connectivity processes
  between client & controller + Need capability negotiation between Controller
  and BGP client
- Use Cases:
+ Acquire BGP Topology; BGP has been extended to disitrbute link-state and TE
info. + Simplify operations and maintenance: use I2RS API's to allow operator
to setup/control BGP policy configuration + VPN service can be more rapidly
deployed + MPLS Global Label Allocation - guarantee that all nodes understand
global label space + RR-Based Traffic Steering + Inter-Controller Applications
- svc set-up between nodes is proxied by BGP Controllers - Next Steps:
Soliciting feedback & comments.

[10:49]
- Eric Rosen: Simplicity of central control is greatly underestimated. To avoid
single point of failure, you need multiple central failures, but if you are
assigning global labels from 2 different central controllers, then you have
multiple points of failure and need to worry about things like coordination
between the central controllers.  And, finally, you have to worry about having
reliable communication path between the client and controller and ensure it's
not used for distribution of labels used in fwd'ing plane. - Robin: This has
been proposed several times in IETF.  I think this is simple, because you don't
need to adjust fwd'ing plane, just distribute label over control plane.  I
don't see the complexity.  In L3VPN, I proposed this scenario for mobile
backhaul and it can use global label. - Robert Raszuk: Saw this at OSPF, IS-IS
and now BGP into I2RS.  However, you are not providing any protocol extension
in document or in slides? - Robin: Propose draft to recognize these ideas so we
can do work on new solutions on a centralized control.  You mentioned protocol
extensions, right now this is more of a framework. - WeiWu @ Huawei: Point of
draft is to resolve problem of underlay network service.  The detail protocol
extensions may be defined later. - Luyuan Fang: Controller concept is not new. 
Don't see anything new here, but if you have specific protocol extensions then
please present them, because I'm not seeing them.  Second point, is wrt global
labels.  I think MPLS scales well because of distributed labels.  If you want
to have centralized labels, use PBB. - Robin: We presented an overview of use
cases.  Re: I agree that MPLS is working well, as is, but think there are ways
to improve MPLS with work on PCE. - Ali Sajassi: Need to decouple global label
and controller.  Already have a draft in L3VPN that already talks about central
controller, so I do not see a need for this draft.  Also, I did not hear an
answer to Eric Rosen's question. - Robin: This is just use cases for the
architecture.  Re: global label and multiple controllers ... that's a good
question. - Adrian Farrell: You can do anything with any protocol.  We have a
WG already that is chartered to inject and retrieve routing information, which
is I2RS.  If what is going on here is you want to inject global labels, then I
think the work should be taken to I2RS. - Robin: OK, will coordinate with
chairs. - Chris Liljenstople: Adrian said pretty much what I wanted to say. 
What are the problems you are actually trying to solve?  We need to know that,
before considering changing the protocol. - ???, NEC: If we don't like to use
Openflow, then we need to define a new protocol to communicate from controller
to fwd'ing plane. - JS: I would like to point out that that is probably under
the charter of I2RS.

[11:03]

 Meeting adjourned.