IETF87 – Inter-domain Routing (IDR) Working Group
THURSDAY, August 1, 2013
1520-1650 - Thursday Afternoon Session II
Room: Potsdam 1
CHAIR(s): Susan
Hares <shares@ndzh.com>
John Scudder <jgs@juniper.net>
3:23 PM Meeting start
Chair: John Scudder
Other chair - Sue Hares injured foot, will not be able to join in person (maybe on phone?)
Note Well - read slide
No Document Status update today - will do over list
3:25 PM North-bound Distribution of Link-State and TE via BGP (aka BGP-LS) - Saikat Ray presenting
Presented at last IETF, this time only covering differences
Tried to merge IS-IS and OSPF data structures as much as possible, small differences due to their protocol design
BGP-LS not meant for routing, no information back to speaker
3:28 PM Slide 3 - BGP-LS Overview diagram
In each area you will run one speaker so that full IGP database can be presented, RR can aggregate BGP-LS speakers from multiple areas, can support inter-as as well
Slide 4 - Topology consists of nodes, links, and prefixes known to each node
Slide 5 - Format of NLRI - NLRI encodes key of node/link/prefix - has minimum information needed to keep unique in global context
Slide 6 - everything else specific to the node/link/prefix is the BGP-LS which is specific to type, data is encoded as TLV's specific to type of object
3:32 PM Slide 7 - changes since last draft
1 64 bit identifier defined to cover multiple IGP instances - very large field but this is so various types of (operator friendly) schemes can be used for encoding data such as ASN, IP, etc…
Re-ordered NLRI types to node, link
TLV's must be in specific order
IGP Router-id - IS-IS real-node 6 bytes, 7 for DIS
OSPF real node - 4 bytes, 8 for "pseudo-node like"
3:34 PM Slide 8 - Added OSPF area as NLRI key, while IS-IS is not part of key goes into attribute
Made router-id for IS-IS as a MUST to help with TE mapping even though this is not required generically for IS-IS
All TLV code-points from one space in this version - some gaps not to conflict with IS-IS TLV code points
3:36 PM Slide 9 - prototypes running, hoping to interoperate in a couple of months
Still need IANA allocation
Q&A
John Scudder - encourage everyone to read draft as this is moving along and probably going to ask for WGLC soon
Hannes Gredler - have implementation up and running based on -01, but should have -02 done by August, will run some tests in September
Andrew Lange - where do we stop (meaning overload of info into BGP)?
John Scudder - we had this debate before adoption, cut-off since we need to move along
Randy Bush - (not at mic) DNS was overloaded :-)
3:38 PM Distribution of TE LSP State using BGP draft - Mach Chen presenting
may need to export TE LSP state to external controller
better to use same protocol to advertise both IGP and TE-LSP state
3:40 PM - Slide 3 description of TLV's defined by draft, defined as sub-tlv's to not consume a large number of TLV's
Slide 4 - Added co-authors to help comply with other BGP-LS
WG adoption?
Q&A
Jeff Haas - due to code point allocation sooner rather than later better as there are typically debates on this
3:43 PM BGP attribute for North-Bound Distribution of TE performance metric - Danhua Wang presenting
Slide 2 - Add additional information related to performance info, complementary to BGP-LS
PCE needs performance related information like delay, link loss, jitter
Using IGP is not sufficient for sending information due to inter-as or diff domains
3:45 PM - slide 3 - parent PCE may change for a child, this is very hard to handle by configuration system
ALTO server can gather from multiple systems - like IS-IS, OSPF and BGP
This draft will help ALTO server build MAP service
Slide 4 - pce-pcep-service-aware draft says PCEP should satisfy network performance constraints, so we think it should support more scenarios like inter-as so it can satify user service reqs
3:47 PM - slide 5 - reuses BGP-LS, adds 7 new TLVs (read slide) - these will allow PCEP server to choose proper path on service requirements
Slide 6 - first 5 parameters borrowed semantics from ISIS-TE draft, last two are new
3:49 PM - slide 7 and 8 - new link-util TLV and channel TLV
Q&A
Jeff Haas - trying to figure out in draft how often these items are being advertised, 5 min sample
Danhua - 5 minute is suggested in some existing RFC's
Jeff Haas - should add interval to message, also if state reduction in BGP is going on
Stefano Previdi - most attributes are borrowed from IS-IS and OSPF WG (earlier) drafts - we have changed them, may want to take another look and match them up. If it can align that it's a good thing.
John Scudder - why aren't the new attributes you added being defined in the IGP drafts? either they should be covered by those drafts or they might not be needed?
Jeff Tantsura - are you taking the info from the IGP extensions to BGP extensions or take direct system measurements
Danhua - same as BGP-LS, take from IGP and send via BGP
Hannes - maybe I can answer, in base spec we have protocol origin, 95% deployments IS-IS and OSPF are source
In inter-domain or static there is a diff source protocol specified
John - cut-off questions
3:55 PM One Administrative Domain (OAD) - Saikat Ray presenting
Name is a bit mystical
assumption that autonomous systems are independently managed, and things like LOCAL_PREF should not be compared since it's meaningless across AS boundary
Slide diagram (he discusses VRF's even though not depicted), when LP goes to other side, AS 2 does not have LP value
3:58 PM - in reality large provider may have multiple AS, but customer expects same BGP to work - could use extended communities mapped to LP but very clumsy
4:00 PM - slide 4 - if it is truly under same provider, OAD tunnels attributes using ATTR_SET, something from PCE, RFC6368 defined - can't directly use
Slide 5 - create a stack of ATTR_SET, can encode multiple attributes and their sequence, rules for encoding only two, but may be useful for more later in other contexts
4:02 PM - Slide 6/7 - example is Inter-AS option C, first slide shows LP reset, on slide 7 shows works
Slide 8/9 - same thing but for option B, both supported
Slide 10 - Dual provider case - this shows attribute set for edge versus core, we need both. We can pick up both and send both core and edge attributes.
Slide 11 - summary - allows us to cover both edge/core, rules for encoding only at ingress/egress, intermediate AS do not use it
WG doc ?
Q&A
4:04 PM
Robert Raszuk - what diff is confederations and your model? Have you looked?
Saikat - cannot change AS, they exist, large deployments
Robert - this is a change too, just diff kind
Stephane Litkowski - can't use communities, this works
Saikat - you can do but only has discrete values
Jeff Haas - strongly suggest, you make use of origin AS where this is applicable, some incidents where it leaks out and another network using 128 is impacted
Rudiger Volk - we should have stopped before making BGP attribute recursive data structure
John Scudder - it already is
Rudiger - immediately bitten when that became RFC, I object to making data structure more complex, and this is, let's stop before it (BGP) becomes JSON
Zhenbin Li - can use virtual router to incorporate into one AS, or you can use multi-topology
Saikat - point is not to merge networks
Zhenbin - can use tunnel technology
4:09 PM BGP Path Marking - Saikat Ray presenting
Have add-path, best-external, we also have multipath concept in most implementations, you may want to know which path iwas the best path, for instance to avoid using backup path in inter-as vpn, or use monitor applications doing peering via iBGP wants to know what is best
Slide 3 - just mark path that would be sent, proposes extended community
Main ops concern (churn)- only advertise when otherwise advertising, not every time it changes
John Scudder - comments on list (no Q&A)
4:12 PM BGP Persistence aka Long lived GR - John Scudder
New name, new draft, same thing
Slide 3 - when control goes down, keep routes, but unlike GR, keep around longer
Motivation - in rare but important cases, multiple faults in well-engineered networks, even when ops are experienced
Want to keep routes rather than flush and provide no service to anyone
This is not intended for promiscuous deployment by all routing - only consenting adults :-)
Slide 4 - last time around - people were passionate, nowhere near consensus - quick summary of previous discussion if use this, may go out to Internet at large and this is weird/bad, fast forward to today, have added an author and tried to address that particular objection
Spec'd to make more code re-use from existing GR code
4:16 PM - slide 5 - this is a lot like GR, main difference is you tell rest of network what you're doing when you hold on to routes - assumption diff GR is short, this is long time
Slide 6 - what's new - routes can be stale for more than half a year - hopefully more than people will need/use
Propagation is strictly scoped - capability that can be applied. If not all routers support, there is a hack called out that say you can do NO_EXPORT, if peer doesn't support, you should withdraw them. Can disable that on per route basis
4:18 PM - Slide 7 - spec'd to default off, we are carrying wide stuff in BGP, the more your stuff looks like routes the more you should consider not using this, I expect normally scoped to single AS
Slide 8 - multicast needs works, will skip that slide due to time
Slide 9 - major issues from debate: multi-fault unlikely - it happens
Depref may not work, looked at all scenarios - sometimes yes, sometimes no, take simple approach
Problem too marginal to do - this is heading toward multi-implementations, would rather doc/standarize
Solution isn't perfect but we can't fix whole universe at once
Slide 10 - WG adopt?
Q&A
Robert Raszuk - LLGR and GR are not exclusive
John: correct, example in draft
4:21 PM NEXTHOP PATH ATTRIBUTE in BGP presented by Zhenbin Li
New attribute
Slide 2 - seamless mpls is reason for requirement - allows to scale network while staying one AS - describes seamless mpls in general
Slide 3 - RR will reflect route with next hop self - explanation of why best ABR may not be selected - if we want to control route selection we must configure complex policy, hard for carrier, prone to error
Back to slide 2 - we want to add more information to iBGP so that you can program more information for best router selection, this is the driver, AS_PATH normally can be used, but in this scenario, one cannot, that is why we want to add the NEXT_HOP to this solution, AIGP can also be used in this scenario, adding this as another feature you can use nexthop path to influence route selection, seeing this can also be useful for management
4:28 PM - slide 4/5 description of new attribute, only IPv4, could add IPv6
Slide 6/7
Slide 8 - decision process, modifies path calculation based on next hop
Slide 9 - feedback?
Q&A
Hannes - re-invent cluster list, we have AIGP and add-path, what else do we need?
Zhenbin Li - cluster id is diff from NH, AIGP is one option, but we want to use NH for best selection, and also network management
Rob Shakir - node making decision doesn't know anything about the NH since not in same area in Seamless MPLS
Policy more complicated in this model than in AIGP - don't think this simplifies anything
Zhenbin - possible as an option different than AIGP
Rob Shakir - do you want explicit routing if so, just say so. If you want optimal path, then AIGP should be enough, this is more complicated in general
John: cut-off questions
4:33 PM Multicast Distribution and Reachability Signaling presented by Jeff Haas
draft to solve some operational consideration in mcast networks
Slide 2 - agreement to split into 3 drafts, this covers 2 that are IDR vs 1 mboned
Slide 3 - problem 1 - allow SP to determine if mcast receiver or unicast
Slide 5 - problem 2 - can customer get specific content or not, like ACL for content, stop subverting of network by join for something not entitled to
Slide 6 - CPE filtering not solution if device hacked
Asking IDR to handle 2 submissions. Could go direct to AD but hoping IDR can help push this out. New SAFI, other doc is use case for constrained RT filter
Slide 8 - For MDR signaling would like new SAFI
No Q&A
4:36 PM BGP FlowSpec IPv6 presented by Andy Karch
Slide 2 - flowspec RFC5575 ipv4 only
Slide 4/5 - description of flowspec graphics
Slide 6 - added ipv6 flow label, mostly match criteria changes, currently we removed fragment
Slide 7 - want to gather interest in these 3 areas
Slide 8/9 - adds inverse mask don't care bits
Slide 10/11 - description of encoding and difference between what we have today
Slide 12 - can reduce down to 8 and 20 bits required
Slide 13 - with new field, affects order of rules for traffic filtering
Slide 14 - in base definition RFC 5575, if common prefix is equal, no prefix set
Slide 15 - currently don't know what order to encode
Slide 16 - we want to check offset length first, lowest offset matches most specific destination
Slide 17 - don't fragment doesn't exist in IPv6, others valid, we want to not support
Slide 18 - upper layer protocol may not be in first fragment due to EH. If you add to many EH, then you may avoid filtering rules
Slide 19 - asking for comments, Cisco well along toward implementation
John Scudder - since WGLC likely soon, please put eyes on this (no Q&A)
4:45 PM session close