IETF87 – Inter-domain Routing (IDR) Working Group

THURSDAY, August 1, 2013

1520-1650 - Thursday Afternoon Session II

Room: Potsdam 1

CHAIR(s):             Susan Hares <>
John Scudder <>


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


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?


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


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 ?


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?


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?


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