From jgs@juniper.net Thu Aug 1 00:24:31 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 102E721F9BA4 for ; Thu, 1 Aug 2013 00:24:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.534 X-Spam-Level: X-Spam-Status: No, score=0.534 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cx+Ym6fl8so7 for ; Thu, 1 Aug 2013 00:24:25 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0187.outbound.messaging.microsoft.com [213.199.154.187]) by ietfa.amsl.com (Postfix) with ESMTP id 0570321F9D5C for ; Thu, 1 Aug 2013 00:24:23 -0700 (PDT) Received: from mail103-db8-R.bigfish.com (10.174.8.239) by DB8EHSOBE011.bigfish.com (10.174.4.74) with Microsoft SMTP Server id 14.1.225.22; Thu, 1 Aug 2013 07:24:22 +0000 Received: from mail103-db8 (localhost [127.0.0.1]) by mail103-db8-R.bigfish.com (Postfix) with ESMTP id 9C9AD140217 for ; Thu, 1 Aug 2013 07:24:22 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.51; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF01-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: VPS-23(zz98dI9371Ic85fh1443I1432I1453I4015Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6h1082kzz8275ch1de098h1033IL18c673h1de096h8275dh1de097hz2fh2a8h683h839hd25he5bhf0ah1288h12a5h12bdh137ah139eh1441h1504h1537h162dh1631h1662h1758h1898h18e1h1946h19b5h19ceh1ad9h1b0ah1b2bh1b2fh1bceh1fb3h1d0ch1d2eh1d3fh1dfeh1dffh1e23h1e64h1155h) Received-SPF: pass (mail103-db8: domain of juniper.net designates 66.129.224.51 as permitted sender) client-ip=66.129.224.51; envelope-from=jgs@juniper.net; helo=P-EMF01-SAC.jnpr.net ; SAC.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.242.197; KIP:(null); UIP:(null); (null); H:BL2PRD0512HT001.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail103-db8 (localhost.localdomain [127.0.0.1]) by mail103-db8 (MessageSwitch) id 1375341860445816_5498; Thu, 1 Aug 2013 07:24:20 +0000 (UTC) Received: from DB8EHSMHS032.bigfish.com (unknown [10.174.8.239]) by mail103-db8.bigfish.com (Postfix) with ESMTP id 6319E900045 for ; Thu, 1 Aug 2013 07:24:20 +0000 (UTC) Received: from P-EMF01-SAC.jnpr.net (66.129.224.51) by DB8EHSMHS032.bigfish.com (10.174.4.42) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 1 Aug 2013 07:24:20 +0000 Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMF01-SAC.jnpr.net (172.24.192.17) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 1 Aug 2013 00:24:19 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.3.146.0; Thu, 1 Aug 2013 00:24:19 -0700 Received: from db9outboundpool.messaging.microsoft.com (213.199.154.252) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 1 Aug 2013 00:28:24 -0700 Received: from mail37-db9-R.bigfish.com (10.174.16.250) by DB9EHSOBE021.bigfish.com (10.174.14.84) with Microsoft SMTP Server id 14.1.225.22; Thu, 1 Aug 2013 07:24:17 +0000 Received: from mail37-db9 (localhost [127.0.0.1]) by mail37-db9-R.bigfish.com (Postfix) with ESMTP id 8AC2D20171 for ; Thu, 1 Aug 2013 07:24:17 +0000 (UTC) Received: from mail37-db9 (localhost.localdomain [127.0.0.1]) by mail37-db9 (MessageSwitch) id 1375341855948791_10942; Thu, 1 Aug 2013 07:24:15 +0000 (UTC) Received: from DB9EHSMHS007.bigfish.com (unknown [10.174.16.236]) by mail37-db9.bigfish.com (Postfix) with ESMTP id E1FA7260047 for ; Thu, 1 Aug 2013 07:24:15 +0000 (UTC) Received: from BL2PRD0512HT001.namprd05.prod.outlook.com (157.56.242.197) by DB9EHSMHS007.bigfish.com (10.174.14.17) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 1 Aug 2013 07:24:15 +0000 Received: from [172.26.205.153] (193.110.54.36) by pod51010.outlook.com (10.255.233.34) with Microsoft SMTP Server (TLS) id 14.16.341.1; Thu, 1 Aug 2013 07:24:14 +0000 From: "John G. Scudder" Content-Type: multipart/alternative; boundary="Apple-Mail=_153BF3EA-44A1-4CB9-8E21-30DE734792C5" Message-ID: <0FF1B218-2013-4F90-B971-E81C41D85EE8@juniper.net> MIME-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Date: Thu, 1 Aug 2013 09:24:11 +0200 References: <73C5C8E0-A9EC-407F-926C-48EDA228E58F@juniper.net> To: "idr@ietf. org" In-Reply-To: <73C5C8E0-A9EC-407F-926C-48EDA228E58F@juniper.net> X-Mailer: Apple Mail (2.1508) X-Originating-IP: [193.110.54.36] X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [Idr] need volunteers for jabber and notes for idr X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 07:24:31 -0000 --Apple-Mail=_153BF3EA-44A1-4CB9-8E21-30DE734792C5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" We have a volunteer to take notes (thank you, Jon!). We still need a volunteer for jabber. Thanks, --John On Jul 31, 2013, at 6:20 PM, John Scudder wrote: > Dear IDR Folks, >=20 > Since Sue is unable to be at the meeting tomorrow, I will be chairing = single-handed. This means that unlike the last few meetings, it won't be = possible for one of the chairs to cover any of the note/jabber duties, = and we won't be able to start until we have a volunteer for each. Since = we have limited time and a lot of material to cover, it would really = help to have this sorted out before we get into the meeting room. >=20 > Will someone please volunteer as the jabber scribe? This entails = joining the jabber room (xmpp:idr@jabber.ietf.org), keeping the jabber = room up to date regarding the slide we're on, and relaying any = questions/comments from the jabber room to the mic during Q/A. Anything = more than that (such as summarizing in-room discussion to the jabber = room) is optional. (For those who are willing but unfamiliar with = jabber, if you use a GTalk account I believe that should be sufficient = for you to connect.) >=20 > Will someone please volunteer to take notes? By the way, if you do, = I'd find it useful if you inserted timestamps into the notes = periodically, as it helps with reviewing the audio recording if needed. = It would be OK to volunteer for just part of the meeting if you need to = (but we will need coverage for the whole meeting). >=20 > Assuming we have volunteers before hand, we will start the meeting at = 15:20 sharp. >=20 > Thanks in advance, >=20 > --John > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr --Apple-Mail=_153BF3EA-44A1-4CB9-8E21-30DE734792C5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii" We = have a volunteer to take notes (thank you, Jon!).

We = still need a volunteer for = jabber.

Thanks,

--John

On Jul 31, 2013, at 6:20 PM, John Scudder <jgs@juniper.net> wrote:

Dear = IDR Folks,

Since Sue is unable to be at the meeting = tomorrow, I will be chairing single-handed. This means that unlike the = last few meetings, it won't be possible for one of the chairs to cover = any of the note/jabber duties, and we won't be able to start until we = have a volunteer for each. Since we have limited time and a lot of = material to cover, it would really help to have this sorted out before = we get into the meeting room.

Will someone = please volunteer as the jabber scribe? This entails joining the jabber = room (xmpp:idr@jabber.ietf.org), = keeping the jabber room up to date regarding the slide we're on, and = relaying any questions/comments from the jabber room to the mic during = Q/A. Anything more than that (such as summarizing in-room discussion to = the jabber room) is optional. (For those who are willing but unfamiliar = with jabber, if you use a GTalk account I believe that should be = sufficient for you to connect.)

Will someone = please volunteer to take notes? By the way, if you do, I'd find it = useful if you inserted timestamps into the notes periodically, as it = helps with reviewing the audio recording if needed. It would be OK to = volunteer for just part of the meeting if you need to (but we will need = coverage for the whole meeting).

Assuming we = have volunteers before hand, we will start the meeting at 15:20 = sharp.

Thanks in = advance,

--John
______________________= _________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mail= man/listinfo/idr

= --Apple-Mail=_153BF3EA-44A1-4CB9-8E21-30DE734792C5-- From jhaas@slice.pfrc.org Thu Aug 1 07:13:53 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFEF221E8153 for ; Thu, 1 Aug 2013 07:13:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.237 X-Spam-Level: X-Spam-Status: No, score=-102.237 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i1w84wOnKKmJ for ; Thu, 1 Aug 2013 07:13:48 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 5630721E819E for ; Thu, 1 Aug 2013 07:13:43 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id F31AFC27A; Thu, 1 Aug 2013 10:13:42 -0400 (EDT) Date: Thu, 1 Aug 2013 10:13:42 -0400 From: Jeffrey Haas To: idr@ietf.org Message-ID: <20130801141342.GA23273@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [Idr] BGP Path Marking comments for IETF 87 session X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 14:13:54 -0000 The microphone comment was going to be brief: BGP churns a bunch already. This feature will add churn to routes. Why is this marking helpful enough to override churn considerations? -- Jeff From jrmitche@puck.nether.net Thu Aug 1 23:36:29 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DC6D11E824A for ; Thu, 1 Aug 2013 23:36:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PENfQ1PTeku3 for ; Thu, 1 Aug 2013 23:36:28 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id CA29E11E8249 for ; Thu, 1 Aug 2013 23:36:27 -0700 (PDT) Received: from puck.nether.net (localhost [127.0.0.1]) by puck.nether.net (8.14.7/8.14.5) with ESMTP id r725nVWD020686 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 2 Aug 2013 01:49:31 -0400 Received: (from jrmitche@localhost) by puck.nether.net (8.14.7/8.14.7/Submit) id r725nUDW020685 for idr@ietf.org; Fri, 2 Aug 2013 01:49:30 -0400 Date: Fri, 2 Aug 2013 01:49:30 -0400 From: Jon Mitchell To: idr@ietf.org Message-ID: <20130802054930.GA20099@puck.nether.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="6TrnltStXW4iwmi0" Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.1 (puck.nether.net [127.0.0.1]); Fri, 02 Aug 2013 01:49:31 -0400 (EDT) Subject: [Idr] Draft Notes from IDR@IETF87 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 06:36:29 -0000 --6TrnltStXW4iwmi0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline All - Attached are the draft notes from the meeting yesterday, please feel free to make corrections, etc... Thanks, Jon --6TrnltStXW4iwmi0 Content-Type: text/html; charset=utf-8 Content-Disposition: attachment; filename="IETF87-IDR-Notes.htm" Content-Transfer-Encoding: 8bit

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

 

 

 

 

 

--6TrnltStXW4iwmi0-- From bill.wu@huawei.com Fri Aug 2 00:11:27 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F402811E81E3 for ; Fri, 2 Aug 2013 00:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.467 X-Spam-Level: X-Spam-Status: No, score=0.467 tagged_above=-999 required=5 tests=[AWL=-2.321, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GlyJHYqu9w+F for ; Fri, 2 Aug 2013 00:11:21 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5B55A11E8276 for ; Fri, 2 Aug 2013 00:11:20 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AUA35369; Fri, 02 Aug 2013 07:11:15 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 2 Aug 2013 08:10:53 +0100 Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 2 Aug 2013 08:11:09 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.43]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.01.0323.007; Fri, 2 Aug 2013 15:11:05 +0800 From: Qin Wu To: Jon Mitchell , "idr@ietf.org" Thread-Topic: [Idr] Draft Notes from IDR@IETF87 Thread-Index: AQHOj0qmFUwVLgN58kaQSbwCm9xJwZmBf4Ow Date: Fri, 2 Aug 2013 07:11:04 +0000 Message-ID: References: <20130802054930.GA20099@puck.nether.net> In-Reply-To: <20130802054930.GA20099@puck.nether.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.157.70] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [Idr] =?gb2312?b?tPC4tDogIERyYWZ0IE5vdGVzIGZyb20gSURSQElFVEY4Nw==?= X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 07:11:27 -0000 QSBxdWljayBjb3JyZWN0aW9uLCB0aGUgcHJlc2VudGVyIHRvIHRoZSB0b3BpYyAiIFBNIEJHUCBh dHRyaWJ1dGUgZm9yIE5vcnRoLUJvdW5kIERpc3RyaWJ1dGlvbiBvZiBURSBwZXJmb3JtYW5jZSBt ZXRyaWMiIA0KSXMgbWUgKFFpbiBXdSkgcmF0aGVyIHRoYW4gbXkgY29sbGVhZ3VlIChEYW5IdWEg d2FuZykuDQpCZXNpZGVzIHRoaXMsIG90aGVyIG5vdGVzIGxvb2tzIGdvb2QuDQoNClJlZ2FyZHMh DQotUWluDQotLS0tLdPKvP7Urbz+LS0tLS0NCreivP7IyzogaWRyLWJvdW5jZXNAaWV0Zi5vcmcg W21haWx0bzppZHItYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBKb24gTWl0Y2hlbGwNCreiy83Ksbzk OiAyMDEzxOo41MIyyNUgMTM6NTANCsrVvP7IyzogaWRyQGlldGYub3JnDQrW98ziOiBbSWRyXSBE cmFmdCBOb3RlcyBmcm9tIElEUkBJRVRGODcNCg0KDQpBbGwgLSANCg0KQXR0YWNoZWQgYXJlIHRo ZSBkcmFmdCBub3RlcyBmcm9tIHRoZSBtZWV0aW5nIHllc3RlcmRheSwgcGxlYXNlIGZlZWwgZnJl ZSB0byBtYWtlIGNvcnJlY3Rpb25zLCBldGMuLi4NCg0KVGhhbmtzLA0KDQpKb24NCg0K From sairay@cisco.com Fri Aug 2 02:32:16 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1015011E8304 for ; Fri, 2 Aug 2013 02:32:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iiMospoh6CYh for ; Fri, 2 Aug 2013 02:32:11 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 25CE911E8307 for ; Fri, 2 Aug 2013 02:31:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=792; q=dns/txt; s=iport; t=1375435910; x=1376645510; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=Vcxa4t/V5fcPd+BfqEsNEK2cvtQezGZBQdLd2No50zI=; b=KfhWQpxEBLOUtvykLzA22ShQdzGqNNGg3JAOseUooFLEwOFlr6hO/Bok QeaKCnI4qqNYjIalSKgb4lCRciQ3kUJr10OylOax+ySUdSsiaHY6xFCTg q+gPBy5If/Nx71SE2hzBwfAdpTwIwk9B+ejgiUKwjxedlwX+ncLVE0D/1 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlkFAHJ7+1GtJV2d/2dsb2JhbABbgwY1UIJJvAmBGxZ0giQBAQEEAQEBNzQXBAIBCA4DBAEBCxQJBycLFAkIAgQBEgiICAy5BASPZzgGgxN0A6ktgxeCKg X-IronPort-AV: E=Sophos;i="4.89,800,1367971200"; d="scan'208";a="242686957" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-6.cisco.com with ESMTP; 02 Aug 2013 09:31:49 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r729Vn38024730 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 2 Aug 2013 09:31:49 GMT Received: from xmb-rcd-x13.cisco.com ([169.254.3.136]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Fri, 2 Aug 2013 04:31:49 -0500 From: "Saikat Ray (sairay)" To: Jeffrey Haas , "idr@ietf.org" Thread-Topic: [Idr] BGP Path Marking comments for IETF 87 session Thread-Index: AQHOjwt4AKdjjnOKNEi2p9qJnXo34ZmBp1Tg Date: Fri, 2 Aug 2013 09:31:48 +0000 Message-ID: <8ED5B0B0F5B4854A912480C1521F973A05C2CC60@xmb-rcd-x13.cisco.com> References: <20130801141342.GA23273@pfrc> In-Reply-To: <20130801141342.GA23273@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.94.115] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Idr] BGP Path Marking comments for IETF 87 session X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 09:32:16 -0000 As the draft says, no additional advertisements should be done just to send= the extcomm. I.e., the path is advertised only if the path would have been= advertised anyway (due to other reasons), and you tack on the extcomm. -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Jeffr= ey Haas Sent: Thursday, August 01, 2013 7:14 AM To: idr@ietf.org Subject: [Idr] BGP Path Marking comments for IETF 87 session The microphone comment was going to be brief: BGP churns a bunch already. This feature will add churn to routes. Why is this marking helpful enough to override churn considerations? -- Jeff _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From rraszuk@gmail.com Sat Aug 3 02:44:47 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55D7611E8165 for ; Sat, 3 Aug 2013 02:44:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.537 X-Spam-Level: X-Spam-Status: No, score=-1.537 tagged_above=-999 required=5 tests=[AWL=0.441, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IEopFgERM91Y for ; Sat, 3 Aug 2013 02:44:47 -0700 (PDT) Received: from mail-oa0-x235.google.com (mail-oa0-x235.google.com [IPv6:2607:f8b0:4003:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id DCD9A11E8162 for ; Sat, 3 Aug 2013 02:44:46 -0700 (PDT) Received: by mail-oa0-f53.google.com with SMTP id k18so3168757oag.12 for ; Sat, 03 Aug 2013 02:44:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=ODcZ89oM+MK/lnu3kzXXtPkJDvGuvLuxtaOL2HO2n+8=; b=myAQYAybc1CIwzxZDbrE7aZYW8qSzqR2YGxZP62euhvHk/PQtIuObZ1/EsMi/xVoeD 3g8mi42G+CSUKgdJ7jP62/eYvVN7gUeErL7A5DsdocCW6tyW1hKaliMJKxY6yy5XOL02 mlQtldZIbvVV+hwTb8IC8luJLdZsWuDqrh4QwOVOK+KSsw2zwrVRiyZMuVRbCDa7YJfZ aqJzF9V2VAnz2QqbG6Sd4WZfgRwVnYOibnzNLw9pKK+HngrQwtS7IU7G8+k0awJSFXfV /QBc/OzXODwOYPSoqKRreUZoV94CZP7kusgWp9444XAwfEwXjCHYHQXM+30ASgyxZdO3 zPog== MIME-Version: 1.0 X-Received: by 10.50.18.5 with SMTP id s5mr300858igd.6.1375523086346; Sat, 03 Aug 2013 02:44:46 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.28.168 with HTTP; Sat, 3 Aug 2013 02:44:46 -0700 (PDT) In-Reply-To: <8ED5B0B0F5B4854A912480C1521F973A05C2CC60@xmb-rcd-x13.cisco.com> References: <20130801141342.GA23273@pfrc> <8ED5B0B0F5B4854A912480C1521F973A05C2CC60@xmb-rcd-x13.cisco.com> Date: Sat, 3 Aug 2013 11:44:46 +0200 X-Google-Sender-Auth: _0nvaxOZorLgpwdMSVmy4xQlK20 Message-ID: From: Robert Raszuk To: "Saikat Ray (sairay)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "idr@ietf.org" Subject: Re: [Idr] BGP Path Marking comments for IETF 87 session X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Aug 2013 09:44:47 -0000 Saikat, As we have discussed after the meeting while I am not worried about churn that much - as churn may mostly be in the case of add-paths I am concerned that the consequence of this marking is intended to have direct impact on best path selection algorithm of BGP speakers. In IDR we have decided few meetings back that we should group all proposals which tent to impact best path selection under common umbrella and stop proposing point solutions which do punch more holes in the best path algorithm. That applies equally to multipath selection as well. One protocol which is designed to be universal solution for this is cost community draft. Sure additional POIs may be needed or it may need to be explicitly extended to also play active role in not only best path selection, but also multipath selection. For your application (which is for some reasons ability not to select best external as multipath candidate) it seems the pre-best path POI of cost community will work just fine today. If we add now a lot of new colors yet not clearly spell out their impact to local best path selection rules leaving this just for the configuration policy the result especially in IBGP networks may be rather poor. So I suggest we first wait for general WG consensus on how much we should continue to create more wholes in the best path selection and once we reach consensus that this is required we generalize the mechanism for it via standards track. Best regards, R. On Fri, Aug 2, 2013 at 11:31 AM, Saikat Ray (sairay) wrote: > As the draft says, no additional advertisements should be done just to send the extcomm. I.e., the path is advertised only if the path would have been advertised anyway (due to other reasons), and you tack on the extcomm. From internet-drafts@ietf.org Sat Aug 3 03:27:36 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D97AA11E8180; Sat, 3 Aug 2013 03:27:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cz8GX6qE3KYa; Sat, 3 Aug 2013 03:27:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F76E11E816B; Sat, 3 Aug 2013 03:27:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.60p1 Message-ID: <20130803102736.28734.94828.idtracker@ietfa.amsl.com> Date: Sat, 03 Aug 2013 03:27:36 -0700 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgp-extended-messages-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Aug 2013 10:27:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Inter-Domain Routing Working Group of the= IETF. Title : Extended Message support for BGP Author(s) : Keyur Patel Dave Ward Randy Bush Filename : draft-ietf-idr-bgp-extended-messages-06.txt Pages : 4 Date : 2013-08-03 Abstract: The BGP specification mandates a maximum BGP message size of 4096 octets. As BGP is extended to support newer AFI/SAFIs, there is a need to extend the maximum message size beyond 4096 octets. This document updates [RFC4271] by providing an extension to BGP to extend its current message size from 4096 octets to 65535 octets. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-extended-messages There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-bgp-extended-messages-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-bgp-extended-messages-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From randy@psg.com Sat Aug 3 03:29:08 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22FA511E816B for ; Sat, 3 Aug 2013 03:29:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MzEOWp5667yU for ; Sat, 3 Aug 2013 03:29:01 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [198.180.150.18]) by ietfa.amsl.com (Postfix) with ESMTP id A7B0F11E8163 for ; Sat, 3 Aug 2013 03:29:00 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1V5Z50-0005Xj-V6 for idr@ietf.org; Sat, 03 Aug 2013 10:28:59 +0000 Date: Sat, 03 Aug 2013 12:28:58 +0200 Message-ID: From: Randy Bush To: idr wg In-Reply-To: <20130803102736.28734.94828.idtracker@ietfa.amsl.com> References: <20130803102736.28734.94828.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Subject: Re: [Idr] I-D Action: draft-ietf-idr-bgp-extended-messages-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Aug 2013 10:29:08 -0000 just a refresh From smohanty@juniper.net Sat Aug 3 10:37:37 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5929A11E80E0; Sat, 3 Aug 2013 10:37:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.207 X-Spam-Level: X-Spam-Status: No, score=-0.207 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3teUkIsehasy; Sat, 3 Aug 2013 10:37:31 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe003.messaging.microsoft.com [216.32.180.186]) by ietfa.amsl.com (Postfix) with ESMTP id A918111E80D1; Sat, 3 Aug 2013 10:37:31 -0700 (PDT) Received: from mail100-co1-R.bigfish.com (10.243.78.248) by CO1EHSOBE029.bigfish.com (10.243.66.94) with Microsoft SMTP Server id 14.1.225.22; Sat, 3 Aug 2013 17:37:31 +0000 Received: from mail100-co1 (localhost [127.0.0.1]) by mail100-co1-R.bigfish.com (Postfix) with ESMTP id DDA629C0089; Sat, 3 Aug 2013 17:37:30 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.52; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF02-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -26 X-BigFish: VPS-26(zzbb2dI98dI9371I936eI542I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah1de096h8275dh1de097h8275chz2fh2a8h683h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1b2fh1fb3h1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail100-co1: domain of juniper.net designates 66.129.224.52 as permitted sender) client-ip=66.129.224.52; envelope-from=smohanty@juniper.net; helo=P-EMF02-SAC.jnpr.net ; SAC.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.236.101; KIP:(null); UIP:(null); (null); H:BY2PRD0510HT005.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail100-co1 (localhost.localdomain [127.0.0.1]) by mail100-co1 (MessageSwitch) id 1375551448819728_11928; Sat, 3 Aug 2013 17:37:28 +0000 (UTC) Received: from CO1EHSMHS024.bigfish.com (unknown [10.243.78.240]) by mail100-co1.bigfish.com (Postfix) with ESMTP id BA3692004A; Sat, 3 Aug 2013 17:37:28 +0000 (UTC) Received: from P-EMF02-SAC.jnpr.net (66.129.224.52) by CO1EHSMHS024.bigfish.com (10.243.66.34) with Microsoft SMTP Server (TLS) id 14.16.227.3; Sat, 3 Aug 2013 17:37:28 +0000 Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMF02-SAC.jnpr.net (172.24.192.18) with Microsoft SMTP Server (TLS) id 14.3.146.0; Sat, 3 Aug 2013 10:37:27 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.3.146.0; Sat, 3 Aug 2013 10:37:28 -0700 Received: from am1outboundpool.messaging.microsoft.com (213.199.154.208) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.3.146.0; Sat, 3 Aug 2013 10:50:22 -0700 Received: from mail100-am1-R.bigfish.com (10.3.201.240) by AM1EHSOBE014.bigfish.com (10.3.207.136) with Microsoft SMTP Server id 14.1.225.22; Sat, 3 Aug 2013 17:37:25 +0000 Received: from mail100-am1 (localhost [127.0.0.1]) by mail100-am1-R.bigfish.com (Postfix) with ESMTP id 53E0F30028F; Sat, 3 Aug 2013 17:37:25 +0000 (UTC) Received: from mail100-am1 (localhost.localdomain [127.0.0.1]) by mail100-am1 (MessageSwitch) id 1375551434816779_31397; Sat, 3 Aug 2013 17:37:14 +0000 (UTC) Received: from AM1EHSMHS015.bigfish.com (unknown [10.3.201.229]) by mail100-am1.bigfish.com (Postfix) with ESMTP id B9714220206; Sat, 3 Aug 2013 17:37:14 +0000 (UTC) Received: from BY2PRD0510HT005.namprd05.prod.outlook.com (157.56.236.101) by AM1EHSMHS015.bigfish.com (10.3.207.153) with Microsoft SMTP Server (TLS) id 14.16.227.3; Sat, 3 Aug 2013 17:37:14 +0000 Received: from BY2PRD0510MB377.namprd05.prod.outlook.com ([169.254.3.122]) by BY2PRD0510HT005.namprd05.prod.outlook.com ([10.255.84.40]) with mapi id 14.16.0341.000; Sat, 3 Aug 2013 17:37:12 +0000 From: Satya Mohanty To: "Ali Sajassi (sajassi)" , "internet-drafts@ietf.org" , "i-d-announce@ietf.org" Thread-Topic: I-D Action: draft-ietf-l2vpn-evpn-04.txt Thread-Index: AQHOgQTAqFJsTi0I20eqhl8Q1Gk415l0lFiAgAEbr4CAAALGYIAC9dSAgAhdnHA= Date: Sat, 3 Aug 2013 17:37:11 +0000 Message-ID: References: <69670F7146898C4583F56DA9AD32F77B123D28D5@xmb-aln-x13.cisco.com> In-Reply-To: <69670F7146898C4583F56DA9AD32F77B123D28D5@xmb-aln-x13.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.52] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%CISCO.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "l2vpn@ietf.org" , "idr@ietf.org" Subject: Re: [Idr] I-D Action: draft-ietf-l2vpn-evpn-04.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Aug 2013 17:37:37 -0000 Hi Ali, I was only pointing out whether the route-target semantics will hold for th= e "value" 0; i.e. whether it should be allowed. I am copying idr to see if = it will have any bearing on RT Filtering (RT Constraints functionality). In any case, the approach you are suggesting about the two level check will= work, but it makes the RT Constraint feature ineffective, it's a known pro= blem (mapping from 10 bytes to 6 bytes), we did discuss this offline. Best, Satya -----Original Message----- From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com]=20 Sent: Saturday, July 27, 2013 7:27 AM To: Satya Mohanty; internet-drafts@ietf.org; i-d-announce@ietf.org Cc: l2vpn@ietf.org Subject: Re: I-D Action: draft-ietf-l2vpn-evpn-04.txt Hi Satya, On 7/25/13 7:37 PM, "Satya Mohanty" wrote: >Hi Ali, > >Let me clarify further. > >In Section 6 Ethernet segment, three ways to generate the esi are=20 >described using (1)LACP (2)Root Bridge Mac address and priority and=20 >(3)Configured value. > >From Section 8.6 ES-Import Route Target > >"This is a new transitive Route Target extended community carried with=20 >the Ethernet Segment route. When used, it enables all the PEs connected=20 >to the same multi-homed site to import the Ethernet Segment routes. The=20 >value is derived automatically from the ESI by encoding the 6-byte MAC=20 >address portion of the ESI in the ES-Import Route" > >Interpreted above (in absence of explicit mention) I would think that=20 >regardless of how the ESI is configured, for purposes of deriving the=20 >value of the ES-Import Route Target, one always extracts the six bytes=20 >starting from the third byte (system mac placeholder). > >For instance, let's say somebody configures the esi using the third=20 >option as 1.2.0.0.0.0.0.0.0.1, the system mac placeholder is=20 >0.0.0.0.0.0 (bytes 3 till 8). This is the value which will be embedded=20 >in the route-target field. Basically a value of 0. > >Wanted to clarify if this will be allowed? Normal Route Target formats=20 >don't support value of 0, I think. This would still work since this is a new RT derived based on MAC. And if s= omeone configures MAC as 0, then the lower six bytes of this new RT will be= zero. If you have multiple ESIs, with zero MAC, then the RTs for all these= ESIs, will be zero which means the ES route messages will not be properly = filtered by their RTs. However, they will eventually be properly filtered b= ecause the ESI values for these sites are different. Cheers, Ali=20 > >Best, >Satya > > > > >-----Original Message----- >From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] >Sent: Thursday, July 25, 2013 10:05 AM >To: Satya Mohanty; internet-drafts@ietf.org; i-d-announce@ietf.org >Cc: l2vpn@ietf.org >Subject: Re: I-D Action: draft-ietf-l2vpn-evpn-04.txt > >Hi Satya, > >Section 6 doesn't talk about RT. How did you arrive at RT of zero? > >Regarding the nit. Agreed - the referenced section number is correct=20 >but not the referenced title. > >Cheers, >Ali > >On 7/25/13 2:21 AM, "Satya Mohanty" wrote: > >>Hi, >> >>With respect to sec 6.3 Ethernet Segment >> >>3. The ESI may be configured. >> >> >>The bytes that comprise the Route-Target value i.e. bytes 2 till 8 of=20 >>the configured esi, can they all be zeros? >>AFAIK regular Route-Targets in 2-byte AS (as-num >=3D 1) or ip-address=20 >>format (community-value >=3D 1), the bytes that comprise the value=20 >>fields can't all be 0. >> >>Minor Nit: In sec 8.6, the reference to section 9.1 "Redundancy Group=20 >>Discovery" is in error. >>I guess the reference name needs to be changed. >> >>Best regards, >>--Satya >> >> >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf=20 >>Of internet-drafts@ietf.org >>Sent: Sunday, July 14, 2013 7:41 PM >>To: i-d-announce@ietf.org >>Cc: l2vpn@ietf.org >>Subject: I-D Action: draft-ietf-l2vpn-evpn-04.txt >> >> >>A New Internet-Draft is available from the on-line Internet-Drafts=20 >>directories. >> This draft is a work item of the Layer 2 Virtual Private Networks=20 >>Working Group of the IETF. >> >> Title : BGP MPLS Based Ethernet VPN >> Author(s) : Ali Sajassi >> Rahul Aggarwal >> Wim Henderickx >> Florin Balus >> Aldrin Isaac >> James Uttaro >> Filename : draft-ietf-l2vpn-evpn-04.txt >> Pages : 47 >> Date : 2013-07-14 >> >>Abstract: >> This document describes procedures for BGP MPLS based Ethernet VPNs >> (EVPN). >> >> >>The IETF datatracker status page for this draft is: >>https://datatracker.ietf.org/doc/draft-ietf-l2vpn-evpn >> >>There's also a htmlized version available at: >>http://tools.ietf.org/html/draft-ietf-l2vpn-evpn-04 >> >>A diff from the previous version is available at: >>http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-l2vpn-evpn-04 >> >> >>Internet-Drafts are also available by anonymous FTP at: >>ftp://ftp.ietf.org/internet-drafts/ >> >> >> > > > > From farmer@umn.edu Sat Aug 3 12:00:47 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D26511E814D for ; Sat, 3 Aug 2013 12:00:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eBXbs+R+hbpl for ; Sat, 3 Aug 2013 12:00:40 -0700 (PDT) Received: from vs-m.tc.umn.edu (vs-m.tc.umn.edu [134.84.135.97]) by ietfa.amsl.com (Postfix) with ESMTP id 5978C11E812C for ; Sat, 3 Aug 2013 12:00:31 -0700 (PDT) Received: from mail-ye0-f174.google.com (mail-ye0-f174.google.com [209.85.213.174]) by vs-m.tc.umn.edu (UMN smtpd) with ESMTP for ; Sat, 3 Aug 2013 14:00:30 -0500 (CDT) X-Umn-Remote-Mta: [N] mail-ye0-f174.google.com [209.85.213.174] #+LO+TR X-Umn-Classification: local Received: by mail-ye0-f174.google.com with SMTP id q9so690816yen.33 for ; Sat, 03 Aug 2013 12:00:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:reply-to:organization:user-agent:mime-version :to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=goe4+xMua+1ti9EOaTileyQvBneq/GKz6wyFjCS3yDM=; b=FkseDbBXhKNZB3c8s9bpGzObJTfwJM1Yi1e2iT3RJOLZUYRNxH1bk2ma05LdSKtqWy dWYa/y0fXS8gtseZRKllVle+KppcUxeuH9ofkr3utlRnWEMYJTlGTrKzCbby8/t/QFbD BLh27GJMHS5UJgwU7FRZiS5pKLMN3Dy0NCT8UpAEcP38BNNFcm5hbOmPt11+XTzae+1a FPplCo4hT/Hvx7wPbtOPiBJPm9+pEG48DkUIPJbbGVGKXZzbvosnr6C5oVOivBQfHNew h3p6o3omJR7MDAutSE0Xy/uv/tQyTuuIS/qVvJGc5lzcMZ+BFmKx4Tdo4MMhHAqU3GMg lJYA== X-Received: by 10.236.22.39 with SMTP id s27mr7370589yhs.258.1375556430398; Sat, 03 Aug 2013 12:00:30 -0700 (PDT) X-Received: by 10.236.22.39 with SMTP id s27mr7370583yhs.258.1375556430310; Sat, 03 Aug 2013 12:00:30 -0700 (PDT) Received: from oit201651646.local ([2001:470:1f11:821:f47b:fe6a:67bc:69c3]) by mx.google.com with ESMTPSA id y70sm22060597yhe.15.2013.08.03.12.00.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 03 Aug 2013 12:00:29 -0700 (PDT) Message-ID: <51FD534B.1050002@umn.edu> Date: Sat, 03 Aug 2013 14:00:27 -0500 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Jon Mitchell References: <20130717135445.22008.42400.idtracker@ietfa.amsl.com> <51EDB95A.7070400@umn.edu> <20130724020922.GA618@puck.nether.net> In-Reply-To: <20130724020922.GA618@puck.nether.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQl9VetY/VHU3nD6ofl+xu8WO/n1zAT8cgWSnUftE51ZH6nt+ShAIOTUhLYB2pwfl06RDJXgZid9xz6ZUGjTLLKO2+jpJN1F77/MX9O0EIVD/ZTHnCIbNaodSRwBjnQI1fCrEM9u Cc: Jeffrey Haas , idr@ietf.org Subject: Re: [Idr] I-D Action: draft-ietf-idr-last-as-reservation-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Farmer List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Aug 2013 19:00:47 -0000 On 7/23/13 21:09 , Jon Mitchell wrote: > > Inline, can pick these up in next (and hopefully final) rev. Yea, collect any other comments for a while, too. > On 22/07/13 17:59 -0500, David Farmer wrote: >> This looks good to me and I support it continuing to move forward. >> >> But, I have a few relatively minor editorial Nits; >> >> - There is a Singular/Plural mismatch in the second paragraph of >> section 3, "last ASN of the 16 bit range, 65535, are reserved", >> should be "last ASN of the 16 bit range, 65535, is reserved". > > [JM] I will fix the wording to be more clear but this is not a > singular/plural mismatch, your snippet missed the subject which was > "subset of BGP communities". Ok, I see what you are saying, you are correct, I misread it. However, if you can come up with something that clarifies the intent, that would be great, as I may not be the only one to misread it. >> - There is another Singular/Plural mismatch in the first paragraph >> of section 4, "a Special Uses", should be ether be either "Special >> Uses", or "a Special Use". I think either way works fine, it just >> needs to match. (Sorry about that one, my bad, this was in the text >> I gave you) > > [JM] Will fix this wording. > >> - I think the order of the sentences in the second paragraph of >> section 4 should be reversed. I think it would be better to start >> with "These last ASNs MUST NOT be advertised ...", then "Operators >> that choose to filter Private Use ASNs ... SHOULD also filter ...". >> The "MUST NOT advertise" is the primary requirement, and the "SHOULD >> filter" is really just a recommended way of achieving it. > > [JM] Agreed. Thinking about this a little more, now that we have the "MUST NOT advertise to global Internet", the "SHOULD filter" could go back to the "MAY filter" that you had originally. Personally, I still think a recommendation of "SHOULD filter" is better from an operational perspective, but the permissive "MAY filter" is all that is absolutely required, now that we have the "MUST NOT advertise to global Internet". >> - I'm not sure, but maybe, the first use of "Private Use ASNs" in >> section 4 should include a reference to >> [I-D.ietf-idr-as-private-reservation] and eventually the RFC when > > [JM] I don't see anything in the style guide, but I have been assuming > like most technical docs only the first mention of a term requires > reference unless you are calling out specific terminology or section. > This was done in the intro. Like I said, I wasn't sure, there are a couple other repeated references in sections 4 and 5, and I though RFC 6996 might be worth a repeat as well, but do what you think is best. Thanks -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From pierre.francois@imdea.org Mon Aug 5 02:05:15 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40BC221F8EB5 for ; Mon, 5 Aug 2013 02:05:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bJhic1Uiqf1E for ; Mon, 5 Aug 2013 02:04:50 -0700 (PDT) Received: from estafeta.imdea.org (maquina46.madrimasd.org [193.145.15.46]) by ietfa.amsl.com (Postfix) with ESMTP id 8CACF21F8976 for ; Mon, 5 Aug 2013 02:01:33 -0700 (PDT) Received: from localhost (estafeta22.imdea.org [172.17.99.146]) by estafeta22.imdea.org (Postfix) with ESMTP id 61B0825D00F; Mon, 5 Aug 2013 10:59:41 +0200 (CEST) X-Virus-Scanned: by antispam-antivirus system at imdea.org Received: from estafeta.imdea.org ([172.17.99.146]) by localhost (estafeta22.imdea.org [172.17.99.146]) (amavisd-new, port 10024) with ESMTP id P0NIuE5YDXfb; Mon, 5 Aug 2013 10:59:41 +0200 (CEST) Received: from [10.61.194.193] (64-103-25-233.cisco.com [64.103.25.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: pierre.francois) by estafeta22.imdea.org (Postfix) with ESMTP id 9B7CC25D00E; Mon, 5 Aug 2013 10:59:38 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Pierre Francois In-Reply-To: Date: Mon, 5 Aug 2013 10:59:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130801141342.GA23273@pfrc> <8ED5B0B0F5B4854A912480C1521F973A05C2CC60@xmb-rcd-x13.cisco.com> To: Robert Raszuk X-Mailer: Apple Mail (2.1503) Cc: "idr@ietf.org" Subject: Re: [Idr] BGP Path Marking comments for IETF 87 session X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 09:05:17 -0000 Robert, all Thank you for your feedback.=20 I went at the mic a few IETF meetings back in order to ask the audience = about how to describe the status of paths, because making the assumption that a received path was installed is no longer = valid. I have asked if I'd tag paths or use BMP. I have been told by multiple people, notably at the mic, that BGP was = the best place to talk about BGP paths, which makes sense to me. Even if we'd delay the support of impacting the BGP decision process = based on the properties of the paths defined by these flags,=20 we need the flags for the monitoring purposes described in the doc. They = are the initial motive of the draft. Currently if you try to = cross-correlate netflow data with BGP routes that you collect by establishing iBGP = sessions with your routers, you have to run error-prone off-line = simulation in order to know who selected what and your traffic analysis = is "subject to the accuracy of your model". So what do we do, we cut the part from the draft that says the flags are = also needed to impact the decision process and we re-meet in Vancouver? Cheers, Pierre. PS: If it has been decided a few IETF meetings back to delay X in order = to have it done neatly, then maybe we should actually do X *now* :) On Aug 3, 2013, at 11:44 AM, Robert Raszuk wrote: > Saikat, >=20 > As we have discussed after the meeting while I am not worried about > churn that much - as churn may mostly be in the case of add-paths I > am concerned that the consequence of this marking is intended to have > direct impact on best path selection algorithm of BGP speakers. >=20 > In IDR we have decided few meetings back that we should group all > proposals which tent to impact best path selection under common > umbrella and stop proposing point solutions which do punch more holes > in the best path algorithm. That applies equally to multipath > selection as well. >=20 > One protocol which is designed to be universal solution for this is > cost community draft. Sure additional POIs may be needed or it may > need to be explicitly extended to also play active role in not only > best path selection, but also multipath selection. For your > application (which is for some reasons ability not to select best > external as multipath candidate) it seems the pre-best path POI of > cost community will work just fine today. >=20 > If we add now a lot of new colors yet not clearly spell out their > impact to local best path selection rules leaving this just for the > configuration policy the result especially in IBGP networks may be > rather poor. >=20 > So I suggest we first wait for general WG consensus on how much we > should continue to create more wholes in the best path selection and > once we reach consensus that this is required we generalize the > mechanism for it via standards track. >=20 > Best regards, > R. >=20 >=20 > On Fri, Aug 2, 2013 at 11:31 AM, Saikat Ray (sairay) = wrote: >> As the draft says, no additional advertisements should be done just = to send the extcomm. I.e., the path is advertised only if the path would = have been advertised anyway (due to other reasons), and you tack on the = extcomm. > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From rraszuk@gmail.com Mon Aug 5 02:48:35 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EBE421F9D71 for ; Mon, 5 Aug 2013 02:48:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[AWL=0.378, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I1LM1lH2qUgb for ; Mon, 5 Aug 2013 02:48:32 -0700 (PDT) Received: from mail-oa0-x230.google.com (mail-oa0-x230.google.com [IPv6:2607:f8b0:4003:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id 7F6D221F89EB for ; Mon, 5 Aug 2013 02:47:53 -0700 (PDT) Received: by mail-oa0-f48.google.com with SMTP id o17so5561825oag.7 for ; Mon, 05 Aug 2013 02:47:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=5NPe7ieoQi4jIDxbbKSUau1EqS7j804adWv8x7pFH3c=; b=uLOYqfiK1kaq7Gghu3bQvgWwuLX83+D46ZLlqYcvQQDrQW7BDTVbU/aJovDacfebbr Q8qljbzHiPIX1QZqufGtC++SVUYQsuR9FYhydm+5woDJ8qXKTP7Qt/mdL5X7ANAqBvPZ EKsPOoX4ke9G1dcecFBPFMumd1zJ8eEzWZCPbWW/XMLS3pItCUTh9JA3Jo3k1vluKr+K /PjugML4fRw+7c/pUBoMNS8E7hZwAMjJDHviW2ZSxSVfUVaHFyQys9xvSaBFWniF5l5V LW9yUAhBXv11K9UhMd6vZ+nKPzlrUWCTQim2ZxjG+2QB6krERYRAOlEZtzpFwdSeo1At tH8A== MIME-Version: 1.0 X-Received: by 10.43.88.3 with SMTP id ay3mr1585488icc.61.1375696072898; Mon, 05 Aug 2013 02:47:52 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.28.168 with HTTP; Mon, 5 Aug 2013 02:47:52 -0700 (PDT) In-Reply-To: References: <20130801141342.GA23273@pfrc> <8ED5B0B0F5B4854A912480C1521F973A05C2CC60@xmb-rcd-x13.cisco.com> Date: Mon, 5 Aug 2013 11:47:52 +0200 X-Google-Sender-Auth: -KEJpmCutcK2vERa1JX9CdmODRo Message-ID: From: Robert Raszuk To: Pierre Francois Content-Type: text/plain; charset=ISO-8859-1 Cc: "idr@ietf.org" Subject: Re: [Idr] BGP Path Marking comments for IETF 87 session X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 09:48:35 -0000 Hi Pierre, Well for monitoring purposes I have heard from many Internet researchers that we need not only know about current status of the path, but also we need to know why given BGP implementation and in particular which bgp best path selection algorithm step has determined such path status. Brute force way is to create your own BGP abstraction layer of a network and feed it with MRT input streams of your EBGP sessions. BMP could also be used if you are ok with all inbound drops or don't care about malformed updates etc ... But if we are to mark paths and if the objective is to influence best path or multipath selection rules I think it makes sense to try to generalize this a bit. Best regards, R. On Mon, Aug 5, 2013 at 10:59 AM, Pierre Francois wrote: > > Robert, all > > Thank you for your feedback. > > I went at the mic a few IETF meetings back in order to ask the audience about how to describe the status of paths, because > making the assumption that a received path was installed is no longer valid. I have asked if I'd tag paths or use BMP. > I have been told by multiple people, notably at the mic, that BGP was the best place to talk about BGP paths, which makes sense to me. > > Even if we'd delay the support of impacting the BGP decision process based on the properties of the paths defined by these flags, > we need the flags for the monitoring purposes described in the doc. They are the initial motive of the draft. Currently if you try to cross-correlate > netflow data with BGP routes that you collect by establishing iBGP sessions with your routers, you have to run error-prone off-line simulation in order to know who selected what and your traffic analysis is "subject to the accuracy of your model". > > So what do we do, we cut the part from the draft that says the flags are also needed to impact the decision process and we re-meet in Vancouver? > > Cheers, > > Pierre. > > PS: If it has been decided a few IETF meetings back to delay X in order to have it done neatly, then maybe we should actually do X *now* :) > > > On Aug 3, 2013, at 11:44 AM, Robert Raszuk wrote: > >> Saikat, >> >> As we have discussed after the meeting while I am not worried about >> churn that much - as churn may mostly be in the case of add-paths I >> am concerned that the consequence of this marking is intended to have >> direct impact on best path selection algorithm of BGP speakers. >> >> In IDR we have decided few meetings back that we should group all >> proposals which tent to impact best path selection under common >> umbrella and stop proposing point solutions which do punch more holes >> in the best path algorithm. That applies equally to multipath >> selection as well. >> >> One protocol which is designed to be universal solution for this is >> cost community draft. Sure additional POIs may be needed or it may >> need to be explicitly extended to also play active role in not only >> best path selection, but also multipath selection. For your >> application (which is for some reasons ability not to select best >> external as multipath candidate) it seems the pre-best path POI of >> cost community will work just fine today. >> >> If we add now a lot of new colors yet not clearly spell out their >> impact to local best path selection rules leaving this just for the >> configuration policy the result especially in IBGP networks may be >> rather poor. >> >> So I suggest we first wait for general WG consensus on how much we >> should continue to create more wholes in the best path selection and >> once we reach consensus that this is required we generalize the >> mechanism for it via standards track. >> >> Best regards, >> R. >> >> >> On Fri, Aug 2, 2013 at 11:31 AM, Saikat Ray (sairay) wrote: >>> As the draft says, no additional advertisements should be done just to send the extcomm. I.e., the path is advertised only if the path would have been advertised anyway (due to other reasons), and you tack on the extcomm. >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr > From pierre.francois@imdea.org Mon Aug 5 03:30:52 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B58121F9A13 for ; Mon, 5 Aug 2013 03:30:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tLGm15oAzZBh for ; Mon, 5 Aug 2013 03:30:46 -0700 (PDT) Received: from estafeta.imdea.org (maquina46.madrimasd.org [193.145.15.46]) by ietfa.amsl.com (Postfix) with ESMTP id D72F621F9C8E for ; Mon, 5 Aug 2013 03:30:40 -0700 (PDT) Received: from localhost (estafeta21.imdea.org [172.17.99.144]) by estafeta21.imdea.org (Postfix) with ESMTP id B8388188E0C; Mon, 5 Aug 2013 12:30:40 +0200 (CEST) X-Virus-Scanned: by antispam-antivirus system at imdea.org Received: from estafeta.imdea.org ([172.17.99.144]) by localhost (estafeta21.imdea.org [172.17.99.144]) (amavisd-new, port 10024) with ESMTP id BrIUJi7+CYaV; Mon, 5 Aug 2013 12:30:40 +0200 (CEST) Received: from [10.61.194.193] (64-103-25-233.cisco.com [64.103.25.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: pierre.francois) by estafeta21.imdea.org (Postfix) with ESMTP id D2A73188E0A; Mon, 5 Aug 2013 12:30:39 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Pierre Francois In-Reply-To: Date: Mon, 5 Aug 2013 12:30:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <743EDF80-E509-4D8D-91CB-9928AF6427C8@imdea.org> References: <20130801141342.GA23273@pfrc> <8ED5B0B0F5B4854A912480C1521F973A05C2CC60@xmb-rcd-x13.cisco.com> To: Robert Raszuk X-Mailer: Apple Mail (2.1503) Cc: "idr@ietf.org" Subject: Re: [Idr] BGP Path Marking comments for IETF 87 session X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 10:30:52 -0000 Robert,=20 On Aug 5, 2013, at 11:47 AM, Robert Raszuk wrote: > Hi Pierre, >=20 > Well for monitoring purposes I have heard from many Internet > researchers that we need not only know about current status of the > path, but also we need to know why given BGP implementation and in > particular which bgp best path selection algorithm step has determined > such path status. It was not part of what I was asked to provide, but I am obviously open = to discuss this.=20 I had been asked to keep things simple, just compensating for what we = had lost with the introduction of best-external and add-paths:=20 i.e., "is this path selected as best". I can always add complexity but = I'd like to be requested for it :) >=20 > Brute force way is to create your own BGP abstraction layer of a > network and feed it with MRT input streams of your EBGP sessions. Yes, the modelling approach. It is very complicated to make it accurate = in practice... > BMP could also be used if you are ok with all inbound drops or don't = care > about malformed updates etc =85 This I had asked at the IDR session of Atlanta, and I had been told by = two multiple BMP people it was hard to do the marking there because that would turn the code into a spaghetti, as the best path selection = process is not happening where BMP is. >=20 > But if we are to mark paths and if the objective is to influence best > path or multipath selection rules I think it makes sense to try to > generalize this a bit. Fine with me, let me check with all the co-authors.=20 Cheers, Pierre. >=20 > Best regards, > R. >=20 >=20 > On Mon, Aug 5, 2013 at 10:59 AM, Pierre Francois > wrote: >>=20 >> Robert, all >>=20 >> Thank you for your feedback. >>=20 >> I went at the mic a few IETF meetings back in order to ask the = audience about how to describe the status of paths, because >> making the assumption that a received path was installed is no longer = valid. I have asked if I'd tag paths or use BMP. >> I have been told by multiple people, notably at the mic, that BGP was = the best place to talk about BGP paths, which makes sense to me. >>=20 >> Even if we'd delay the support of impacting the BGP decision process = based on the properties of the paths defined by these flags, >> we need the flags for the monitoring purposes described in the doc. = They are the initial motive of the draft. Currently if you try to = cross-correlate >> netflow data with BGP routes that you collect by establishing iBGP = sessions with your routers, you have to run error-prone off-line = simulation in order to know who selected what and your traffic analysis = is "subject to the accuracy of your model". >>=20 >> So what do we do, we cut the part from the draft that says the flags = are also needed to impact the decision process and we re-meet in = Vancouver? >>=20 >> Cheers, >>=20 >> Pierre. >>=20 >> PS: If it has been decided a few IETF meetings back to delay X in = order to have it done neatly, then maybe we should actually do X *now* = :) >>=20 >>=20 >> On Aug 3, 2013, at 11:44 AM, Robert Raszuk wrote: >>=20 >>> Saikat, >>>=20 >>> As we have discussed after the meeting while I am not worried about >>> churn that much - as churn may mostly be in the case of add-paths I >>> am concerned that the consequence of this marking is intended to = have >>> direct impact on best path selection algorithm of BGP speakers. >>>=20 >>> In IDR we have decided few meetings back that we should group all >>> proposals which tent to impact best path selection under common >>> umbrella and stop proposing point solutions which do punch more = holes >>> in the best path algorithm. That applies equally to multipath >>> selection as well. >>>=20 >>> One protocol which is designed to be universal solution for this is >>> cost community draft. Sure additional POIs may be needed or it may >>> need to be explicitly extended to also play active role in not only >>> best path selection, but also multipath selection. For your >>> application (which is for some reasons ability not to select best >>> external as multipath candidate) it seems the pre-best path POI of >>> cost community will work just fine today. >>>=20 >>> If we add now a lot of new colors yet not clearly spell out their >>> impact to local best path selection rules leaving this just for the >>> configuration policy the result especially in IBGP networks may be >>> rather poor. >>>=20 >>> So I suggest we first wait for general WG consensus on how much we >>> should continue to create more wholes in the best path selection and >>> once we reach consensus that this is required we generalize the >>> mechanism for it via standards track. >>>=20 >>> Best regards, >>> R. >>>=20 >>>=20 >>> On Fri, Aug 2, 2013 at 11:31 AM, Saikat Ray (sairay) = wrote: >>>> As the draft says, no additional advertisements should be done just = to send the extcomm. I.e., the path is advertised only if the path would = have been advertised anyway (due to other reasons), and you tack on the = extcomm. >>> _______________________________________________ >>> Idr mailing list >>> Idr@ietf.org >>> https://www.ietf.org/mailman/listinfo/idr >>=20 From Jan.Henke@taujhe.de Mon Aug 5 09:53:52 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B76801F0C87 for ; Mon, 5 Aug 2013 09:53:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8nYyNqcV6Jvi for ; Mon, 5 Aug 2013 09:53:52 -0700 (PDT) Received: from taujhe.de (loadmaster.taujhe.de [IPv6:2001:6f8:900:8eb2:62:112:43:237]) by ietfa.amsl.com (Postfix) with ESMTP id 753C91F0D4E for ; Mon, 5 Aug 2013 09:53:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by taujhe.de (Postfix) with ESMTP id 9BB1DE18A for ; Mon, 5 Aug 2013 18:53:37 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at taujhe.de Received: from taujhe.de ([127.0.0.1]) by localhost (taujhe.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nGcZc9xG+H6X for ; Mon, 5 Aug 2013 18:53:31 +0200 (CEST) Received: from [192.168.1.50] (x2f1469d.dyn.telefonica.de [2.241.70.157]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jan) by taujhe.de (Postfix) with ESMTPSA id 6A917E189 for ; Mon, 5 Aug 2013 18:53:31 +0200 (CEST) Message-ID: <51FFD8A6.4070700@taujhe.de> Date: Mon, 05 Aug 2013 18:53:58 +0200 From: Jan Henke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: idr@ietf.org X-Enigmail-Version: 1.5.2 OpenPGP: id=20C88DFB Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="QfpDkcuqlfovVCrSl41uaGOVDPksLB2pq" Subject: [Idr] Review for draft-ietf-idr-bgp-gr-notification-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 16:53:52 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --QfpDkcuqlfovVCrSl41uaGOVDPksLB2pq Content-Type: multipart/mixed; boundary="------------040907010408070007050508" This is a multi-part message in MIME format. --------------040907010408070007050508 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, below you find my review of draft-ietf-idr-bgp-gr-notification-01. It is my first review for an IETF draft, therefore I am happy to receive feedback on the review itself in a separate message. The draft is overall well written and understandable, however I suggest the following improvements. 1. Introduction --------------- The introduction states that NOTIFICATION messages were excluded from the= graceful restart defined in RFC4724. It does not mention why these message class was excluded in RFC4724. It would be nice for the reader to get a summary of the rationale for the original exclusion and the motivation to change that with this document. 2. Modification BGP Graceful Restart Capability ----------------------------------------------- While reading this section I was irritated by the "Flags for Address Fami= ly" paragraph. I found out that the "N" bit was defined in the -00 revision o= f the draft, but I did not find any RFC modifying it. Therefore I suggest t= o remove the paragraph from the document, as there is no change to RFC4724.= 3. BGP Hard Reset Subcode -------------------------- While reading this section I was hoping to get some information about the= appropriate usage of the Hard Reset Subcode. Providing some typical use cases would improve this section and make it easier for futur= e implementations to have a similar semantics in respect to this code. --=20 Best regards Jan Henke --------------040907010408070007050508 Content-Type: application/pgp-keys; name="0x20C88DFB.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x20C88DFB.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2.0.20 (MingW32) mQINBE6LCbMBEADfGWCubIpWBZWC0zyw51Poz+Rg743v89qhlEaGmXDbFhPDIxA8 BCohMHm2+SCh7fRfj635HncbI8E7Ck6gcIBpw9GpMEP8nNo5UIeug0xE2jnp5uFe bd1tavvG4PNtfSd7zhC5zKDc6qy4ANskJqIvSAQo0SdsXVuS7CRealV3X1QuNQaM n0UcVscWwZIcZsKH5eEBb8f0hygBv5rndkNlgY5Wb/Mvsss08vOjdVk/WlGea7f5 I+fbveaViU2+ADrkgHbAX3U3O10NdBu/BOqOiRXnJZzGUTxrto7caZVOy8eOMhfp +zDf+Tcp65G7hLsyp6G4osLuhn/heKC/W5hlnh8QM1TgaIJ7+uz4yvxFx7rQlCTw lys2rXI5VcNNbrRToL6fADDacy4+zSzORp6LTU/Qox8kcJk0P3Jjl3KjQPYpwE57 y61N7xwK0q6WVYw613xxf+eAMbAVHsUZCSOPT15T1J8QOJ47LR/vu86gYkBDh6md fAz+KJAEGPE1rU6KpH++g74KW/hV/2C9FTKHZcJUK9pMZ0821CZnQfA+DUGFj0mw 0FVRpC+5qfk/tGYXBlbo160/a4BbhAtINlA2DERlsvwyh5mh/lGDmMWs91XHzeVm rBtLzPHwYIj2I9fKD6Cev5vb8nQRDlqCV9jptav6OJtAmbCPQBVQ1pDC0QARAQAB tBpKYW4gSGVua2UgPG1haWxAdGF1amhlLmRlPokCOAQTAQIAIgUCTosJswIbAwYL CQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQMsGZrSDIjfv4TxAAkbMsftvoZg22 mB+fEH+GZ58qFgBxyGRVz3CNAgglnh9qlqvH8bf0YadsxZ49lXfJMHB1hUClRRT8 0W4RL95Uiru3l79hngZmUSy4k5m23s68+7Zwc/L72Ekpl86rOcKnJBZQvrQ/wYO2 gIIPlgNEl7KOhVXpRkY5CEvcxTBxTVaFXE6j2OJcmTMKtEc8sRh7Z7OrtANzIGPn c6FMoQSkiJBxE9BoXgTZV8b3O5Emg/4vXMDr6LrEMtS8ukdyqMrStNBxusINUDbR wfgVsXGrfs8cSDoo0dN9LEsb+ZJkqon4Sg7kcDTXytH4VQHzHyQtkNc9Mspdc4AL goYLi3/rGbuS43zu0duqnYFJL0/QF8m8veOZEBJuprZbuVkD+FtojHtLoS4KHPOV r7vTEufffJ0/rV6ZnFWcUEOfROndbwmIwWX/U/mebz9NtLzVRCLT30ul8GP9oD1x wn3xmc+wRLFRiYMjffgkrbe8QImJYytHZodks1fN2N6TOY7shP8THsSoIrpzjbmA MbUflLxcomJSYauUy85MjFtsIiW82Wi4PhHr10ZzBEuxYEq9iqQzleVZnjjdCXaq ZqJBWQalCUXYs2e8RIEyRYcaMQgH7hnKf5Z+ec/VUqIbZyMmAhaVQpB+I6eTpTn/ DN0FeY64MX0XIcLtoN0+8gbvakqqU3CJAhwEEAECAAYFAk7satMACgkQn0Sy6DGj tPRwWhAAnjoAatnuTPH7bAh6vAEs9WWbf5BCtopRImwMHn2jEx9J/BoNWUuS3D5B 1TeLty9NBLeUhoC4V+dcajy+jh9xtf4HRC6md21ZmmjdrQQTm2aS9ToEwmDvA9Vh +s+lCt0JXpe5YZ/F74O+eFSl/yEFRN8FLIu8O/S51yfIX09wNyS4oohSMjGg1YqL 1CiSVtbQxbTk0AepxYathvJOai62ZuPuEzGzanZ7Z85NG3i3ewt2GSbav3dBFJRG MbGfBjrgfkB4SAxCedFq9kMf52RLYokL6Uzmd4V6FD4n3VaTmGjQH4nUFfOBxqwC h8GTr4GoUEtriKAkZpAUA5Vk/lHOi6qUXDzZoeiX5rCFZDTfKt/SJcBFgaQZiYAt K55hcOdMKPjq5QXPsRpvooANfhPG4Gv9od9sbUAGrMZpbh8E5TuqhOQ8CPBc813V nAvgpxcJwPjXht0Besn2FJZ3dEPiKNPU4OkXxZR+8E1voPpUpgNgZVUjq5FoENsE uak85lSgkevQgIx94RMbZ4kJ6RNpW7QqlmUtSIwtlSinar3vnJqMZKcnLqfwBy26 vL/a6XbRTgcvJxOXJy6Ul+kARw5Zo0D3MLQpQ28na/DVMdg/gZgmrVSmS6wD5426 PEzx9+dmggdFaXrF5VfgQXGBAZPG5s/s+U4LQtBCaYVJa1czXha0HkphbiBIZW5r ZSA8bm8tcmVwbHlAdGF1amhlLmRlPokCOAQTAQIAIgUCTosNUQIbAwYLCQgHAwIG FQgCCQoLBBYCAwECHgECF4AACgkQMsGZrSDIjft+9hAArwuL/B0A8kFiKUtX9Zcy ti8KuIPgGwy37mdemVcQr93TrAfi+30lKybs0AmVDg+4PWOtX9NHnugc9gIMl0gk nZ6sFnDlqWFVAkd7tgD4XdaDgXFGKdynL2YEE9G7cYdwiXCtpGIwcec206uKezf0 6/6iAti65axv5GBV0Y2gbrn6TLIE/muNxh9j6eN4eqaMfL7Kpvg/ApLJduOwBPOa 2NJU0yPoRIENOdn8MWRSBImF4IVc+8MXG5TawJEdh5odFzo4vUvJ/oyvG8uhkp9T fA+PoCNEHROcBhxdav/zxQxPEhLtFrGqrVE7Wo8+UdHnN7ObXFSphf/D6lvaRhg8 K3p/CSmrClP1pOk/xLmiknwrTTG5i0ccoDklCZ4lQ7yWEbzMb2BywMcLo7x4mq5n L0P4prwPuGX4AxQhP0jzChvWqkdIMdiPgUq3EFG01J9GyWUGvXbKIEk2+tBCGYn+ gDg7DQvxAkRz1qHLlDMD3T2lZzFS4QQvPHlPr1QZjar3/Iy6qGLinvWXI3Hsv2nn wiJYKPrjtrHRpm3qHJxR0+ocjD8cmiVmEgRupmNc123Rz+MCZGTUptoIvi1/J4+J cxFPCvRSswg7pdPgTdgfcJ1VsfCr29/sWyoTTSxDkjXeWOs+xszn2wyWa5qDVaQ/ RlG70xvI/gehYa+im+TgDsqJAhwEEAECAAYFAk7satMACgkQn0Sy6DGjtPT5sg// bk1NFiticXLjvppn2xCRmOVjupXv3Mc26BGysngYaiBWSc+uiM2bce4TZEgkdvll 2IJR+2psoaTyO83ZFECE5JeuNG5QNNXlTGjUur4ObFEsqdPWyShg0i37sKExZlMM hWsinFyhBVG7+bdxLpH7sK2/FEckiLfAhgEVC38aKdxtpoVFUeDfjUZay9/GZDcE tKlL9BCsI1hamL+M1G4C4ObtTmjeXxZzkeVVL9OMZX3OFXZ7lAJY05DS3mhXv0P0 iF7S2XXbSrrh9oXETopwNZTCjmcE9JsVciWjpAvwf6nPgXfHXAl3JQpGbJ4Wfy6F TiEs2QSTSDTJYyVIMkeFI4TSTskmftjkNURjf3buxC2a8sFChJlsjKrTVuKa7YlS u53sQF//lAzON/hCPAL9XooSBUWppZBvUaGWzDAwSUrd0wf2jvtkynBq5a2+p7DP WAC+ko26zlec2IKFg8CnComb4hU6CkGZuG4mwz8UCNkoBcmveEwosaCjYXqJWkw3 ID2UQAS2qWsGkGr09zeRUPefhaW/Z+SXZJHMkT5+oK8exJX5j8gTu9jvwAoDVID2 Y99Bg5ZaBlntNBRZ74f8XPFdiRJuyOAD6VZxS6GBbkPSmQq1OXNmb1CttQMMCP3r KAuKfTGvlnnDhoiONutyM5IgD6amBnjBIwPoX2NvWMW0H0phbiBIZW5rZSA8SmFu LkhlbmtlQGdtYWlsLmNvbT6JAjgEEwECACIFAk6LDYoCGwMGCwkIBwMCBhUIAgkK CwQWAgMBAh4BAheAAAoJEDLBma0gyI371cgP/1SBLc6qqfNewyy8pHAyiHGCYlk9 y6As0pYy29dhk1WBSX9ulFlu8IczyfoKnipBtU5ZZeQDSGbKYWsOi9IPvz/jZOeA UFotU6C3UUEEoU5FSss338GROT7bRU8i8ZAE37wWPYsWnkFJcLwbzksFBUzObCQX cAepsL0I0GdfJhNm9jm6tCu9FsbcrDr5tFu6k6J5XuoHi4y+BkD/a4JYFHoFCVjs XSuEHzgDZVmfXa2kJvQHhd1+CMtL+m0jGwd5EqF/TX2eheBxuKJQYqwQsL+fIofn WVac9kbDimv/RL3bo9AjZazHYFjGMgzzMEIm64muReznHiJJXeJzx3b9+d06agbK cE1Arq3YrgURy36l9Wz7tpznrQ//9XLruHg0yFqovhYKwyL9xT1pMdAB4AuXM2hB oJJ/gQiLWWmGWBKns+h/mRH3j4r+1uHBcXWpAi4Q7rYlzofM5BhSOrKKruWhN7tL vZV0P4pMpwakn2nFxuuLDNNA7Rqw1e9d20cC+dxthyOpSQW+40qvCkuPZIdZTjpR d49uYA0V32OMYPHnQLi7vVZl0hCR05pcRv789Fx6kXGNcV8+X5eHLuvdfF3qxzH8 BOxf/OB+ethDq2rlnsobH9ehCY5lo2JUTPAQ8Wimi1OM4OHGundgcjAz7ScQjuum VuXG9Iy0eU+EMH1niQI7BBMBAgAlAhsDBgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIX gAUCTt/YTgIZAQAKCRAywZmtIMiN+1hPD/9HKU5bUfFRqiW2ul+7caSz0XRRf4If Zm1Zp1wspAvW+mR61CIJ9eWRu2EcHmH/W3HBA7hzQEWuvI6uT5HmjK9w69YkOaHg F5075tlJiHm78k+m40SJagUCNGXuJm1C4OKwYJgMZoy+xfvNsnDw7pxUtMbC38Y8 JnFZxrbAqKg/ThSWh9Kc9QqsFJoRdioa8nHtAouGYVCx076jYJq8fnDIIOhxFnQG H/sQg/sbYGJqQTPGckSmUidR8YozcrsvE7M7LQwgoxLgvzyl2W2iu8e4ASVGhrsx 04YsTDL+NT8lLkM14y/8JlGPtj0j24XF9srROtyo5+ygbzyCdJFd39ptFIVu//7m cklucTBesyG0FX2wsv7uCsOnwgQKNpQ20MDYjPb3SV+rGML5nIGN29HtsbXwyk9u i7aDTn6xzmU4yXx8zYD37VUa+eo+jw0VshN1nOCuyIMhEd1amDp2v16CUpui1kEu oglAhB8RIlUwvvZXx5XOczL5eoA0outmGnA6LWrqygAmJSrA7GhIsVbGmCN0ohU/ p+NRXuIuQXDDnsYp34eyMvOEhs+gtiZNW6C/B8BGbtWmvtLJ1qeaKYwkDWc5WYsd dKYFvl8SXTAjXaIBbfuRqbUq8QhijF+UndVv4uaKCgLZloTs277NPolffpbctpey m2mKuWZIPzqR3IkCHAQQAQIABgUCTuxq0wAKCRCfRLLoMaO09KDkEACgyL9sqjCI AzqJ16fJa76bnejOtXpLiQ/LDUSaeFrmxOqw7ime+8uKYU3qbspclwLwS7swBjUX Xv5xLDoxZs4Vaax0ia05Oxx9CVIwRBQNiJZH8zzb6V9KPJ+7E8hvqAreEsqHNUru c6MmUPdTC6FUVJ/K9nGFWc/ZDIPbG7A19iS9C2Cz2hEUe1i5gqGq6cRHFN1z1RHc tMHn9wZmuf1SQGlt95SCszTuD4UVNlzxoI2lqGPSzMUQOYDuKpDPQMsFw5nn8dXS oiy4VAD5b7a8iT1jVyybosE8Q+FSBu7VoQC+xmdZyYXyqV/GzOeEHCB11OU53YCb K6ssbGJtE0/slHr9FQu3Fari1kye2zp/oz/nY7nL2ionW2bbjau1/kVQ3XZXMIo0 FFsqbn8zgPPMwJnoJE6oYShvwKx7u738yNkeNijA9gyE5UHud1dq4bQofip5LGzJ FNsvnS+HNWft5zRfIsS0Wr+VnlxqyYGjEXILRhPqAAq6upcSS5E0iZyDToosXvWq OyBp9mLnDOJ1xuAsh47kp3RsZzptQuo2w0tFeOmdLrr78QGGl77+SYTzEoNSiIFC eNmpt35QT5+cKKPuJI7/Wkq/j2RA/XQZkcbNgdE9xmld3oaGdEyq7r49s8/2Bse3 nvNGY/N5vLI3tR+JLCBuzRYMnTOqTu6rZrQfSmFuIEhlbmtlIDxKYW4uSGVua2VA dGF1amhlLmRlPokCOAQTAQIAIgUCTt/YQgIbAwYLCQgHAwIGFQgCCQoLBBYCAwEC HgECF4AACgkQMsGZrSDIjfsQ+w//QT1bt9vYDWsExxViHeXFO0ilGQIximB/3b98 ddC6TCMouEtinZCHIcEsDESrLzILdS/+0hOJHL7nTxqeRGQxa4Z4COrdGnCPH4gJ Md6ewej5QBFuI9eapKVyyuWLqJIfSFBxycIkV5+E5VAnj5qGtENHsI64rL5a6Bap P+VtAQ6neKO5LlDnQycD5IMfEgmJ2pmnKvrXLX5Kpdl9+77ccPuNkLI3DntWDKcL rs8JJ2MKUR3T4+2rCeRMUFd8+raCGSunrf6XTyAVsoAyds6Xf9TNmaKUcP4B3Zgx J1nqzNasAjJp6ApoPtaReMBIRTzJlepOZH4FQ796dPA3q5RUkitEQUyXrBVKatG4 W8Jx7jfhqC+1E/QGQ9SWdry5iU8LJgHzVgnANvXKpOaltsXrs8JeutbSu5Btodr4 DC7xeMK2w+3GrUVo6sbAsSO5Ye1B8bJn66YVEO7LS8escAlpifZZm+qFpbPjXFea Wd3zpphIV7zMDFrh7A+14rTaNDyP3GWVpmQQCrffzaeCjJbCl82IhtVCb0bbqaAs M5zVGlJ6BnX6YVeyNBg8XZHyIIqN+/Hxz0rhgKTWVRRdFymGb0UYAoyBuTIa+XLw Zq35p4nY7Pnoo5YVs4dY9Vrzj8ho3PJOGfqlZDKj6TeZ61IURTRklANnYUXvOsq/ B9mYUayJAhwEEAECAAYFAk7satMACgkQn0Sy6DGjtPRHAA/9G0FD3/4yw67h8yug rBTedPWv7nh13O7Kzt1YZfMPFsZncT3CyuRkZvSPiaAZE7otWMBwP/G56uQO5Obx 2X5EwjnlYE7f12/VeBh0QrJV+P/Ig9iRnw3eMONpODv5650vtPzfuAZntK0gDi9S 30EVpgSCfLNMx9A0DjGiaZvV7frMULSfEWQ8Q9YkwrpvqQ8POzkbj8ShfGKhdGcs 23zTeYCT9p9OYf/Y7QyNzGjizrJ3dDBtbVYhLW8rysRklGL43QI28DRnLudOJXOu yRjaz+LbThSadD8m/zBhcduKRCZhoEE6zBizCbRi/q19KM1NPB5akms94XYADZJ6 GZ8KYO+yTL5dYjSMfDYNN3EckaGuD+Wrru4MOyKnh8D3A5rIX7DRE/FF+sDeNQKm Et0O1Zvy7CNECcHfc3YMTlMvh1F38F3CjeD9rgttC2a4XpgbG8GLq1v5pPnDNstH tpWf1/xjmRypZE6b+HVM/F1m9xSeZK8TO+yssUYAqXd9zRVre+XaWsO6Drq8EBds NNM98MJqmSunL3n8nKSRDhUmcOCM/+1kyTCbEaZ09WfPbYfT5tnr76opJSBhjqWJ HnxOFL3oRm3qu/ciY/xujEodFJvU/bNBBpoHhO4FjHsLmlRfNqX18p6XM3NPnusT L0k/42JFnmLXVfmeV3HFfv5oOju5Ag0ETosJswEQALEezAVqLsNfLTuzn2D0pFjB YsB6HP6MN3eRv99Kmg445yF21Uy77sl2WsErA3YHvSWrZANnT2XYS5guEd82WMkS hXRR4/Hky1+QrfvHfVugcCIxyByU+9PkPn0FQgdinMfuB7/0Wq7vDol9aoWjWqys EDPID+s+wuAHzl5j45pCkLli5bK3loUwibgAIoRyUxa/2AqPbhpcBUaZwsp609yr yZT9GVVQK4/KI9NKel3Ft1dySpkILm0xW9GuQLpf8g2xtDWipZgS74nZAO7QjVsM rp6SCmKcwgoU56zvk1FWVXkpdGGUIit+c4mD1fQgsb/hvb+ocsIvezWZQgC1gR8f zNWP3Bp8XpQ5u7DhQy1+vFHbto7aEXjqYdHKY+4hkav2AE2xmmSYJXaiNYyLRseC ffQN82fVjsq8HYp/RUCgeeSi3SRcPNp51jGWyuAoPJHyXk8+hZWoN8MK1KB802r7 k/0jRS4y4cNRLDkvCk8Sc0oPlOzLVosmSti78TTKsfHC1p20wRSzbbDk16n2lFph CksduXGGBR4j98eVlDRDUHodJ9xzJztYwPg5rjW1gK+3uD9vNb0um5gg8RWqfg1p gBtwe/uyNzq1rC+RmYC8mDsl21jU7MaafNPtHzSftOkvdMyunQr7IiaxHSFQLDWG mgEffV8bp2+0W2uWzXeHABEBAAGJAh8EGAECAAkFAk6LCbMCGwwACgkQMsGZrSDI jfvjThAAxlMeG5mgOPyJZc585RFyQ5+VgoRc4FbwEGDtm/I+v3Z5haozvSYpw6qr +8N6dhWFU97f3+EJDEN/MLyapWGDP58wg8lBqegc2y6jZiyvdulv5QEzSaGvB3zk Ue18aUfHKkb4uvmfmZDcItyeavcqkl7eTw23HOpNy4L3xSj7A8suqSqLXBxxdBbu iz4vv627hN8RSiTAp8CWgfTQerm+RL8m6g5cjz26GVUrRHTX7RkiFiMIpFJcZVl5 dM+UwnxNtBO+v4olDAGj1k6W0GdNOtU358KPPe86/lTFH1XOoh3wz3eUwF0JUFtM ZnXkAVjKO8IotzvaFBbYQzhJki4TM8O9NKJzUQj/BWBIitL/zY66+Zbd6ds7kBEB ObOTahcQn5cJPALycsel4cPqci9F0tfvp9m/ZN3qJSKxT2pXL67RO9a7VRrknNK1 IwhScHf9K43gSSfR6dYkrszJzTYrgl4GuFE7plhHjRMIo2/LXODRzo8X4RY7IHzl lozwDLCwvUnhkHg1q3BydeltZ/nM2J0tr/aINudtro7yRvZPpCn6Jc0MorwERNxG QLYssDdAqLPB9DD5lfloWYK4RWt2TKCRlZQ13E8SfgrwIotGgDk2/rpDVbXBxa0I 2RySYvbCg4izHIW7EvZF26Gw+QWyX9Lck5SzUKEjpQcvgmsp6jw=3D =3DXi9S -----END PGP PUBLIC KEY BLOCK----- --------------040907010408070007050508-- --QfpDkcuqlfovVCrSl41uaGOVDPksLB2pq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJR/9imAAoJEDLBma0gyI372asQANqUQO4gqDXIkphtiu/mcIQn B+ENg3srv3NCmpLLVX1DhjmrTCfW2fbzWYF89Bcly/XBN5e1worYWj+dcLxSgHG/ ORLmz8zsnsIsfDAVqI9n/22kB3CJGfc+fr8qGjQgWTa724/jRkVJRP4pKd3xYgb8 /T13wKpez6XEDLelu1YZfjqk3od1dcMCmDwQqn/7Y1rzN8QMXwRXeIHdO9Nmea0+ oM3rI4eR2Fw8DhXayxdHmWP6W9rYZIgORbEV3TwbJAKmMCZG85DQ05M+5GZKz7Aa 1suliOltNBjmazMJ2ie/XuxUSqC40LzhjilKgRUFLBEW35UkBrk/vw8qCEHdWLxt 5CW+9YjZrM/dJfEJ3EK8SqpXldG9WR8weab5xXA2cahM/PzrWdCmdtLDAg/SelsO aJt2JVmoozJQxGsz+n+MRy0hIk4iKiHi8g9xcub27T/748gJ7GrGzpmfadOZdwga hghlnudtJC1BHAukq0JLKbN/tAtf0gdva0bRL9RHTu7TeVEUnna2B6tfk6pT4OJW tE0ELkzorf+7GhZvK2z0qBGp1q4JTrxdC019mt8E998//ms7RGqAnrBwROJzGlz+ pxO5TcwOqOhy93njK8yLwA88LTwGzn/PfGrdzAybLPdbPLkHDHECVzNJuuirVbvM HDvBaWd8fvD0Sh3fJLOo =ktyY -----END PGP SIGNATURE----- --QfpDkcuqlfovVCrSl41uaGOVDPksLB2pq-- From chris.hall@highwayman.com Tue Aug 6 04:37:37 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B5E421F9DA1 for ; Tue, 6 Aug 2013 04:37:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.539 X-Spam-Level: X-Spam-Status: No, score=-0.539 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_UK=1.749, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id URUvGRO5VzIs for ; Tue, 6 Aug 2013 04:37:30 -0700 (PDT) Received: from smtp.demon.co.uk (mdfmta004.mxout.tch.inty.net [91.221.169.45]) by ietfa.amsl.com (Postfix) with ESMTP id 923B821F9D30 for ; Tue, 6 Aug 2013 04:37:30 -0700 (PDT) Received: from mdfmta004.tch.inty.net (unknown [127.0.0.1]) by mdfmta004.tch.inty.net (Postfix) with ESMTP id 2D62DAC42BB for ; Tue, 6 Aug 2013 12:37:29 +0100 (BST) Received: from mdfmta004.tch.inty.net (unknown [127.0.0.1]) by mdfmta004.tch.inty.net (Postfix) with ESMTP id 02609AC42BA for ; Tue, 6 Aug 2013 12:37:29 +0100 (BST) Received: from hestia.halldom.com (unknown [80.177.246.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mdfmta004.tch.inty.net (Postfix) with ESMTP for ; Tue, 6 Aug 2013 12:37:28 +0100 (BST) Received: from hyperion.halldom.com ([80.177.246.170] helo=HYPERION) by hestia.halldom.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1V6fZu-0003bj-N4 for idr@ietf.org; Tue, 06 Aug 2013 11:37:26 +0000 From: "Chris Hall" To: References: <51FFD8A6.4070700@taujhe.de> In-Reply-To: <51FFD8A6.4070700@taujhe.de> Date: Tue, 6 Aug 2013 12:37:20 +0100 Organization: Highwayman Message-ID: <06af01ce9299$5365b8b0$fa312a10$@highwayman.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQHgv7XC6QNdsTevWFFg+zGOAiU5EZliitJQ Content-Language: en-gb X-MDF-HostID: 17 Subject: Re: [Idr] Review for draft-ietf-idr-bgp-gr-notification-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 11:37:37 -0000 Jan Henke wrote (on Mon 05-Aug-2013 at 17:54 +0100): .... > 1. Introduction > --------------- > The introduction states that NOTIFICATION messages were excluded > from the graceful restart defined in RFC4724. It does not mention > why these message class was excluded in RFC4724. It would be nice > for the reader to get a summary of the rationale for the original > exclusion and the motivation to change that with this document. Amen to that... it is considerable puzzle to me that to (say) add a new = address family to a session and exploit Graceful Restart, it is = necessary to (somehow) *avoid* sending a NOTIFICATION message :-( > 2. Modification BGP Graceful Restart Capability > ----------------------------------------------- > While reading this section I was irritated by the "Flags for > Address Family" paragraph. I found out that the "N" bit was > defined in the -00 revision of the draft, but I did not find > any RFC modifying it. Therefore I suggest to remove the > paragraph from the document, as there is no change to RFC4724. Having the 'N' qualification per AFI/SAFI does seem de trop. It seems there are two cases of session termination: (1) with Graceful Restart, as previously advertised (2) without Graceful Restart, previous advertisement notwithstanding And RFC4724 says: * without NOTIFICATION =3D> (1), * with NOTIFICATION =3D> (2). And the problem is: to arrange a Graceful Restart the restarting end has = to *avoid* sending a NOTIFICATION, and any information that a = NOTIFICATION might have carried is lost. This draft seems to say:=20 * without NOTIFICATION =3D> (1) * with any NOTIFICATION (except "Hard Reset") =3D> (1),=20 * "Hard Reset" =3D> (2). Now, the logic is inverted: if the sender does want to inhibit Graceful = Restart, it needs to send a "Hard Reset", and any information that a = more specific NOTIFICATION might have carried is lost. The key paragraph of the draft is: When a BGP Speaker receives a BGP NOTIFICATION message, it SHOULD follow the standard rules of the receiving speaker mentioned in [RFC4724] for all AFI/SAFIs for which it has announced the BGP Graceful Notification flag. The BGP speaker generating a BGP NOTIFICATION message SHOULD follow the standard rules of the receiving Speaker in [RFC4724] for all AFI/SAFIs that were announced with the BGP Graceful Notification flag. By "standard rules", we mean section 4.2 of RFC4724... or all the rules = of RFC4724 excluding the one which says that NOTIFICATION <=3D> inhibit = Graceful Restart. The first sentence seems to say that the receiving speak will, = unilaterally, no longer follow RFC4724, but will do Graceful Restart = even if the sender sends a NOTIFICATION. I suppose this tells the = sender that if it does want case (2), they had better send a "Hard = Reset" -- which may be a bit of a blow if the sender doesn't understand = the 'N' bit. I assume the second sentence is s/receiving/restarting/ ? I assume = "were announced" means announced by the speaker to whom the NOTIFICATION = is being sent ? If there is no significant need for (2) then the receiver doesn't really = need permission to not inhibit Graceful Restart on receipt of a = NOTIFICATION. So the real meaning of the 'N' qualification is: having = received 'N', a restarting speaker: (a) if it wants Graceful Restart, it = can still send a (helpful) NOTIFICATION (which would currently have to = be suppressed); (b) must send a "Hard Reset" if Graceful Restart needs = to be suppressed; (c) must carry out the restarting speaker procedure if = it does not send "Hard Reset". The draft also says: A BGP speaker MAY continue to operate in the Graceful Restart mode even if it receives a Graceful Restart capability without a Graceful Notification Flag.=20 When receiving a NOTIFICATION the BGP speaker is not required to take = any notice of the incoming 'N' qualification. This seems to reiterate = that... which suggests that the need for (2) is discounted. If the = other end does not announce 'N', then sending a NOTIFICATION and = expecting it to do Graceful Restart would be to assume that the other = end is not, in fact, RFC4724 compliant ? If there is a significant need for both cases of session termination, = then it seems to me that the NOTIFICATION itself needs to carry that = extra bit of information, somewhere. Perhaps, a new = "NOTIFICATION_GRACEFUL" message could be implemented, exactly as the = current but meaning "please *do* Graceful Restart, as previously = advertised". It's possible that such a message could be sent even if = the far end does not understand it -- *provided* it logs the event and = then does a Graceful Restart ! Of course, if the sender wants to inhibit Graceful Restart, it can = always send the 'F' bit as zero when the session comes back up... but = that is not guaranteed to happen immediately, so perhaps that's not good = enough ? As it stands, the draft lumps all "crash" NOTIFICATIONs into one. I'm = not sure of the utility of doing a Graceful Restart on receiving a = "Cease/Administrative Shutdown" or "Cease/Peer De-configured". For many = other NOTIFICATIONs Graceful Restart seems entirely the right thing to = do. I'm not sure about the OPEN Message errors. > 3. BGP Hard Reset Subcode > -------------------------- > While reading this section I was hoping to get some information > about the appropriate usage of the Hard Reset Subcode. Providing > some typical use cases would improve this section and make it > easier for future implementations to have a similar semantics=20 > in respect to this code. Indeed. Chris From adam.simpson@alcatel-lucent.com Tue Aug 6 18:46:34 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66F5A21E80E1 for ; Tue, 6 Aug 2013 18:46:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KMBbGI4a0vec for ; Tue, 6 Aug 2013 18:46:28 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id F028221E80D8 for ; Tue, 6 Aug 2013 18:46:25 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (h135-5-2-64.lucent.com [135.5.2.64]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id r771kOu7010826 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 6 Aug 2013 20:46:24 -0500 (CDT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id r771kNFp021341 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 6 Aug 2013 21:46:24 -0400 Received: from US70TWXCHMBA09.zam.alcatel-lucent.com ([169.254.3.100]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.02.0247.003; Tue, 6 Aug 2013 21:46:23 -0400 From: "Simpson, Adam (Adam)" To: Jeffrey Haas , "idr@ietf.org" Thread-Topic: [Idr] Question on forwarding behavior in draft-ietf-idr-flowspec-redirect Thread-Index: AQHOkw/rsyskjzThXUug20EOJBhXQg== Date: Wed, 7 Aug 2013 01:46:22 +0000 Message-ID: In-Reply-To: <20130618195114.GE3241@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [135.5.27.18] Content-Type: text/plain; charset="us-ascii" Content-ID: <52631AD3EB100C44989FB9642BFA65F6@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Subject: Re: [Idr] Question on forwarding behavior in draft-ietf-idr-flowspec-redirect X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 01:46:34 -0000 Hi Jeff, Somehow your email escaped our notice and we neglected to respond. Apologies for that.. Your observation is valid. The way we have chosen to encode the redirect destination means that if we want to send IPv6 traffic over an IPv4 tunnel we need to express the IPv4 tunnel destination in a special way (e.g. an IPv4-mapped IPv6 address) and vice versa; if that is our intent it should of course be defined in the draft and we will certainly look into that for the next revision. The alternative is to encode the tunnel destination (and possibly associated tunnel parameters) using an entirely new path attribute but we thought that was overkill for the main use cases we were targeting. Regards, Adam On 2013-06-18 3:51 PM, "Jeffrey Haas" wrote: >Authors, > >: When a BGP speaker receives an UPDATE message with the redirect-to- >: IP extended community it is expected to create a traffic filtering >: rule for every flow-spec NLRI in the message that has this path as >: its best path. The filter entry matches the IP packets described in >: the NLRI field and redirects them (C=3D0) or copies them (C=3D1) towar= ds >: the IPv4 or IPv6 address specified in the 'Network Address of Next- >: Hop' field of the associated MP_REACH_NLRI. More specifically: if an >: IPv4 [or IPv6] packet with destination address D that is normally >: forwarded to a next-hop A matches a filter entry of the type >: described above it MUST instead be redirected (C=3D0) or mirrored >: (C=3D1) to next-hop B, where B is found by FIB lookup of the IPv4 [or >: IPv6] address contained in the MP_REACH_NLRI next-hop field (i.e. a >: longest-prefix-match lookup). Signaling and applying constraints >: beyond longest-prefix-match on the types of interfaces or tunnels >: that can be used as the redirection next-hop B are not precluded by >: this specification but are nevertheless outside its scope. > >The text above raises some question with regard to mixed-address family >behavior. To illustrate, we have four examples of IP-based forwarding: > >*IPv4 traffic over IPv4 forwarding > IPv6 traffic over IPv4 forwarding > IPv4 traffic over IPv6 forwarding >*IPv6 traffic over IPv6 forwarding > >The cases noted with an asterisk aren't exciting - you'd expect them to >just >work regardless of whether the nexthop sent in the flowspec route is >either >an adjacent IP system or a tunnel covering the same address family. > >The other two cases are the interesting ones. > >One normally wouldn't expect IPv6 traffic to be IP forwarded to an IPv4 >nexthop, or vice-versa. When the nexthop actually maps to a tunnel (e.g. >MPLS), the case is perhaps a bit more ambiguous: Does the egress of the >tunnel inspect the traffic to determine the proper ethertype for the >traffic? > >This is admittedly not an immediate problem today. 5575 and the matching >extension to do IPv6 currently expect the address family of the flowspec >route to have an appropriate same-family MP-NEXTHOP. > >Put a somewhat different way, if the expected behavior is that you'll >always >have a nexthop for redirect that is of the same address family as the >flowspec route, we're perhaps done. > >Until we decide we want to do flowspec for something besides plain IP. > >But that is perhaps a different problem to worry about later. > >-- Jeff >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www.ietf.org/mailman/listinfo/idr From rraszuk@gmail.com Wed Aug 7 07:54:54 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A54F521F8E1F for ; Wed, 7 Aug 2013 07:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.684 X-Spam-Level: X-Spam-Status: No, score=-1.684 tagged_above=-999 required=5 tests=[AWL=0.294, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hzWAlYPyKGFV for ; Wed, 7 Aug 2013 07:54:53 -0700 (PDT) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id B55FD21F93B9 for ; Wed, 7 Aug 2013 07:54:53 -0700 (PDT) Received: by mail-ob0-f176.google.com with SMTP id uz19so3751639obc.7 for ; Wed, 07 Aug 2013 07:54:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=OY7l+fcsKQPOWICMroZWbcj0v0P80VajvJx65z3MDDU=; b=ZucDoUidsUW8K/14Eu3qvrrEzyVSvftsun7+f/NJ54IwWbvPOwzEQzmJvHxX7ivxzS OsPEVJr0IJH7dQhj5vHFWyChxtfDugnB1Nfh30jgc/RcWWiF8PGHSD+g65EmWWm4x7XX J5L179x3u9gTW5SruO2iPFrvR8rZTNLQ1xKYU4jtpCdSvqmcm8ZOcZUhr/9WuB7RXvuP Q2H1JQwXQfugx+MAI/n+38D0luvTrauZb5kLU3lIotjXIp6Cr+pIsCBvRUSR2rQlgtV/ dZv5dOb7dXu0WZj6dqAYTrtabv0yfTn0y6jRn0/1bWbkU+SrzO6tJz7CBBpQPES4iGaR sjQg== MIME-Version: 1.0 X-Received: by 10.50.23.16 with SMTP id i16mr85518igf.50.1375887293084; Wed, 07 Aug 2013 07:54:53 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.28.168 with HTTP; Wed, 7 Aug 2013 07:54:53 -0700 (PDT) In-Reply-To: References: <20130618195114.GE3241@pfrc> Date: Wed, 7 Aug 2013 16:54:53 +0200 X-Google-Sender-Auth: D9LXAg3hG0H8dSh1meJjgPuIYpQ Message-ID: From: Robert Raszuk To: "Simpson, Adam (Adam)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "idr@ietf.org" Subject: Re: [Idr] Question on forwarding behavior in draft-ietf-idr-flowspec-redirect X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 14:54:54 -0000 Hi Jeff & Adam, Reading via your mails I am a bit confused if you are talking about "match" or "actions". "Redirect" is an action and 5575 just specifies redirect to a VRF based on the RT. Such VRF can have any AFI/SAFI enabled and in particular can be a start of encap (of any form) to some external device (very often traffic deep inspection/screening). While we are discussing some other forms of actions but so far this is out of scope of proposed documents. Reg "match" the MP_REACH next hop field is of the length zero. Rgs, R. > On Wed, Aug 7, 2013 at 3:46 AM, Simpson, Adam (Adam) lucent.com> wrote: > Hi Jeff, > > Somehow your email escaped our notice and we neglected to respond. > Apologies for that.. > > Your observation is valid. The way we have chosen to encode the redirect > destination means that if we want to send IPv6 traffic over an IPv4 tunnel > we need to express the IPv4 tunnel destination in a special way (e.g. an > IPv4-mapped IPv6 address) and vice versa; if that is our intent it should > of course be defined in the draft and we will certainly look into that for > the next revision. The alternative is to encode the tunnel destination > (and possibly associated tunnel parameters) using an entirely new path > attribute but we thought that was overkill for the main use cases we were > targeting. > > Regards, > Adam > > > On 2013-06-18 3:51 PM, "Jeffrey Haas" wrote: > >>Authors, >> >>: When a BGP speaker receives an UPDATE message with the redirect-to- >>: IP extended community it is expected to create a traffic filtering >>: rule for every flow-spec NLRI in the message that has this path as >>: its best path. The filter entry matches the IP packets described in >>: the NLRI field and redirects them (C=0) or copies them (C=1) towards >>: the IPv4 or IPv6 address specified in the 'Network Address of Next- >>: Hop' field of the associated MP_REACH_NLRI. More specifically: if an >>: IPv4 [or IPv6] packet with destination address D that is normally >>: forwarded to a next-hop A matches a filter entry of the type >>: described above it MUST instead be redirected (C=0) or mirrored >>: (C=1) to next-hop B, where B is found by FIB lookup of the IPv4 [or >>: IPv6] address contained in the MP_REACH_NLRI next-hop field (i.e. a >>: longest-prefix-match lookup). Signaling and applying constraints >>: beyond longest-prefix-match on the types of interfaces or tunnels >>: that can be used as the redirection next-hop B are not precluded by >>: this specification but are nevertheless outside its scope. >> >>The text above raises some question with regard to mixed-address family >>behavior. To illustrate, we have four examples of IP-based forwarding: >> >>*IPv4 traffic over IPv4 forwarding >> IPv6 traffic over IPv4 forwarding >> IPv4 traffic over IPv6 forwarding >>*IPv6 traffic over IPv6 forwarding >> >>The cases noted with an asterisk aren't exciting - you'd expect them to >>just >>work regardless of whether the nexthop sent in the flowspec route is >>either >>an adjacent IP system or a tunnel covering the same address family. >> >>The other two cases are the interesting ones. >> >>One normally wouldn't expect IPv6 traffic to be IP forwarded to an IPv4 >>nexthop, or vice-versa. When the nexthop actually maps to a tunnel (e.g. >>MPLS), the case is perhaps a bit more ambiguous: Does the egress of the >>tunnel inspect the traffic to determine the proper ethertype for the >>traffic? >> >>This is admittedly not an immediate problem today. 5575 and the matching >>extension to do IPv6 currently expect the address family of the flowspec >>route to have an appropriate same-family MP-NEXTHOP. >> >>Put a somewhat different way, if the expected behavior is that you'll >>always >>have a nexthop for redirect that is of the same address family as the >>flowspec route, we're perhaps done. >> >>Until we decide we want to do flowspec for something besides plain IP. >> >>But that is perhaps a different problem to worry about later. >> >>-- Jeff >>_______________________________________________ >>Idr mailing list >>Idr@ietf.org >>https://www.ietf.org/mailman/listinfo/idr > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From rraszuk@gmail.com Wed Aug 7 08:02:50 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31F5D11E8151 for ; Wed, 7 Aug 2013 08:02:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.713 X-Spam-Level: X-Spam-Status: No, score=-1.713 tagged_above=-999 required=5 tests=[AWL=0.265, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z4kDfIBltdcf for ; Wed, 7 Aug 2013 08:02:49 -0700 (PDT) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id DDD8211E813D for ; Wed, 7 Aug 2013 08:02:43 -0700 (PDT) Received: by mail-ob0-f178.google.com with SMTP id ef5so3860339obb.37 for ; Wed, 07 Aug 2013 08:02:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=+jbKgUbI7z7r547NMXE5zrmBMSUeXUgBowtU0yhRke0=; b=MpXBxTta9Gq44LkOC1d+bewFjsmowGeBZyKoMdOf8ZgHr+BxDC2MfqN6Y+qchG2n/r IiSSYX5N0KHQI5xJhsbf2UK+8D2cVrHwIDL2fADbn1bAm4pb2hmYp2yTGJbFjjC0AngR vS5o9LXznwsWeKBQz/tWBXHJmtQEklNlpFjndsQbTTVg2EMWrgqM9s14bzHOVqz6osUK O0Wt7LiMZQbF309ufB4pY3T8CNOiIHPpEX3LzLOeI/ccCmtQXiMmpo9uPKTFECZ2C9x/ j+89Dtc6up87RMPUeJvAVv39HRtj7LuORHWzGF7bXqrZS++bsi+M313GZd4bewuPvdd/ 0ayA== MIME-Version: 1.0 X-Received: by 10.50.73.74 with SMTP id j10mr87897igv.50.1375887763101; Wed, 07 Aug 2013 08:02:43 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.28.168 with HTTP; Wed, 7 Aug 2013 08:02:43 -0700 (PDT) In-Reply-To: References: <20130618195114.GE3241@pfrc> Date: Wed, 7 Aug 2013 17:02:43 +0200 X-Google-Sender-Auth: RT4t9hrjqgbJuvWQGRPk-eK2EeA Message-ID: From: Robert Raszuk To: "Simpson, Adam (Adam)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "idr@ietf.org" Subject: Re: [Idr] Question on forwarding behavior in draft-ietf-idr-flowspec-redirect X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 15:02:50 -0000 And for the draft-simpson-idr-flowspec-redirect during last IETF there were number of corridor discussions that there are scenarios where flowspec could highly benefit if we would attach BGP Vector Node Path Attribute as described in draft-patel-raszuk-bgp-vector-routing-00. Hence it would be perhaps beneficial to talk to authors of draft-simpson-idr-flowspec-redirect in consideration of using more general solution to the problem they expressed and replaced proposed ext community with BGP Vector Node attribute. Best regards, R. > On Wed, Aug 7, 2013 at 4:54 PM, Robert Raszuk wrote: > Hi Jeff & Adam, > > Reading via your mails I am a bit confused if you are talking about > "match" or "actions". > > "Redirect" is an action and 5575 just specifies redirect to a VRF > based on the RT. Such VRF can have any AFI/SAFI enabled and in > particular can be a start of encap (of any form) to some external > device (very often traffic deep inspection/screening). > > While we are discussing some other forms of actions but so far this is > out of scope of proposed documents. > > Reg "match" the MP_REACH next hop field is of the length zero. > > Rgs, > R. > >> On Wed, Aug 7, 2013 at 3:46 AM, Simpson, Adam (Adam) > lucent.com> wrote: >> Hi Jeff, >> >> Somehow your email escaped our notice and we neglected to respond. >> Apologies for that.. >> >> Your observation is valid. The way we have chosen to encode the redirect >> destination means that if we want to send IPv6 traffic over an IPv4 tunnel >> we need to express the IPv4 tunnel destination in a special way (e.g. an >> IPv4-mapped IPv6 address) and vice versa; if that is our intent it should >> of course be defined in the draft and we will certainly look into that for >> the next revision. The alternative is to encode the tunnel destination >> (and possibly associated tunnel parameters) using an entirely new path >> attribute but we thought that was overkill for the main use cases we were >> targeting. >> >> Regards, >> Adam >> >> >> On 2013-06-18 3:51 PM, "Jeffrey Haas" wrote: >> >>>Authors, >>> >>>: When a BGP speaker receives an UPDATE message with the redirect-to- >>>: IP extended community it is expected to create a traffic filtering >>>: rule for every flow-spec NLRI in the message that has this path as >>>: its best path. The filter entry matches the IP packets described in >>>: the NLRI field and redirects them (C=0) or copies them (C=1) towards >>>: the IPv4 or IPv6 address specified in the 'Network Address of Next- >>>: Hop' field of the associated MP_REACH_NLRI. More specifically: if an >>>: IPv4 [or IPv6] packet with destination address D that is normally >>>: forwarded to a next-hop A matches a filter entry of the type >>>: described above it MUST instead be redirected (C=0) or mirrored >>>: (C=1) to next-hop B, where B is found by FIB lookup of the IPv4 [or >>>: IPv6] address contained in the MP_REACH_NLRI next-hop field (i.e. a >>>: longest-prefix-match lookup). Signaling and applying constraints >>>: beyond longest-prefix-match on the types of interfaces or tunnels >>>: that can be used as the redirection next-hop B are not precluded by >>>: this specification but are nevertheless outside its scope. >>> >>>The text above raises some question with regard to mixed-address family >>>behavior. To illustrate, we have four examples of IP-based forwarding: >>> >>>*IPv4 traffic over IPv4 forwarding >>> IPv6 traffic over IPv4 forwarding >>> IPv4 traffic over IPv6 forwarding >>>*IPv6 traffic over IPv6 forwarding >>> >>>The cases noted with an asterisk aren't exciting - you'd expect them to >>>just >>>work regardless of whether the nexthop sent in the flowspec route is >>>either >>>an adjacent IP system or a tunnel covering the same address family. >>> >>>The other two cases are the interesting ones. >>> >>>One normally wouldn't expect IPv6 traffic to be IP forwarded to an IPv4 >>>nexthop, or vice-versa. When the nexthop actually maps to a tunnel (e.g. >>>MPLS), the case is perhaps a bit more ambiguous: Does the egress of the >>>tunnel inspect the traffic to determine the proper ethertype for the >>>traffic? >>> >>>This is admittedly not an immediate problem today. 5575 and the matching >>>extension to do IPv6 currently expect the address family of the flowspec >>>route to have an appropriate same-family MP-NEXTHOP. >>> >>>Put a somewhat different way, if the expected behavior is that you'll >>>always >>>have a nexthop for redirect that is of the same address family as the >>>flowspec route, we're perhaps done. >>> >>>Until we decide we want to do flowspec for something besides plain IP. >>> >>>But that is perhaps a different problem to worry about later. >>> >>>-- Jeff >>>_______________________________________________ >>>Idr mailing list >>>Idr@ietf.org >>>https://www.ietf.org/mailman/listinfo/idr >> >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr From internet-drafts@ietf.org Wed Aug 7 23:39:48 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8361311E8112; Wed, 7 Aug 2013 23:39:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Qvd0r-uUjiu; Wed, 7 Aug 2013 23:39:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3760E21F9E28; Wed, 7 Aug 2013 23:39:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130808063918.27745.22097.idtracker@ietfa.amsl.com> Date: Wed, 07 Aug 2013 23:39:18 -0700 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgp-ipv6-rt-constrain-04.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 06:39:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Inter-Domain Routing Working Group of the= IETF. Title : IPv6 Extensions for Route Target Distribution Author(s) : Keyur Patel Robert Raszuk Martin Djernaes Jie Dong Mach(Guoyi) Chen Filename : draft-ietf-idr-bgp-ipv6-rt-constrain-04.txt Pages : 5 Date : 2013-08-07 Abstract: The current route target distribution specification described in RFC4684 defines Route Target NLRIs of maximum length of 12 bytes. The IPv6 specific Route Target extended community is defined in [RFC5701] as length of 20 bytes. Since the current specification only supports prefixes of maximum length of 12 bytes, the lack of an IPv6 specific Route Target reachability information may be a problem when an operator wants to use this application in a pure IPv6 environment. This document defines an extension that allows BGP to exchange longer length IPv6 Route Target prefixes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ipv6-rt-constrain There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-bgp-ipv6-rt-constrain-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-bgp-ipv6-rt-constrain-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From adam.simpson@alcatel-lucent.com Thu Aug 8 11:45:39 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2B0D11E8214 for ; Thu, 8 Aug 2013 11:45:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zJdfK1vZgljb for ; Thu, 8 Aug 2013 11:45:34 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id B7FBC11E8150 for ; Thu, 8 Aug 2013 11:45:32 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id r78IjV4F013495 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 8 Aug 2013 13:45:31 -0500 (CDT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id r78IjUrv004662 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 8 Aug 2013 14:45:31 -0400 Received: from US70TWXCHMBA09.zam.alcatel-lucent.com ([169.254.3.100]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.02.0247.003; Thu, 8 Aug 2013 14:45:31 -0400 From: "Simpson, Adam (Adam)" To: Robert Raszuk Thread-Topic: [Idr] Question on forwarding behavior in draft-ietf-idr-flowspec-redirect Thread-Index: AQHOlGd1cAe6HDXXbUqplfVCm2LmAw== Date: Thu, 8 Aug 2013 18:45:30 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: "idr@ietf.org" Subject: Re: [Idr] Question on forwarding behavior in draft-ietf-idr-flowspec-redirect X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 18:45:39 -0000 Hi Robert, Thanks for the pointer to the BGP vector routing draft. I agree it could be complementary (but not a complete alternative) to the solution we are proposing. Let me discuss this with the other authors. -Adam On 2013-08-07 11:02 AM, "Robert Raszuk" wrote: >And for the draft-simpson-idr-flowspec-redirect during last IETF there >were number of corridor discussions that there are scenarios where >flowspec could highly benefit if we would attach BGP Vector Node Path >Attribute as described in draft-patel-raszuk-bgp-vector-routing-00. > >Hence it would be perhaps beneficial to talk to authors of >draft-simpson-idr-flowspec-redirect in consideration of using more >general solution to the problem they expressed and replaced proposed >ext community with BGP Vector Node attribute. > >Best regards, >R. > > >> On Wed, Aug 7, 2013 at 4:54 PM, Robert Raszuk wrote: >> Hi Jeff & Adam, >> >> Reading via your mails I am a bit confused if you are talking about >> "match" or "actions". >> >> "Redirect" is an action and 5575 just specifies redirect to a VRF >> based on the RT. Such VRF can have any AFI/SAFI enabled and in >> particular can be a start of encap (of any form) to some external >> device (very often traffic deep inspection/screening). >> >> While we are discussing some other forms of actions but so far this is >> out of scope of proposed documents. >> >> Reg "match" the MP_REACH next hop field is of the length zero. >> >> Rgs, >> R. >> >>> On Wed, Aug 7, 2013 at 3:46 AM, Simpson, Adam (Adam) >>>>> lucent.com> wrote: >>> Hi Jeff, >>> >>> Somehow your email escaped our notice and we neglected to respond. >>> Apologies for that.. >>> >>> Your observation is valid. The way we have chosen to encode the >>>redirect >>> destination means that if we want to send IPv6 traffic over an IPv4 >>>tunnel >>> we need to express the IPv4 tunnel destination in a special way (e.g. >>>an >>> IPv4-mapped IPv6 address) and vice versa; if that is our intent it >>>should >>> of course be defined in the draft and we will certainly look into that >>>for >>> the next revision. The alternative is to encode the tunnel destination >>> (and possibly associated tunnel parameters) using an entirely new path >>> attribute but we thought that was overkill for the main use cases we >>>were >>> targeting. >>> >>> Regards, >>> Adam >>> >>> >>> On 2013-06-18 3:51 PM, "Jeffrey Haas" wrote: >>> >>>>Authors, >>>> >>>>: When a BGP speaker receives an UPDATE message with the redirect-to- >>>>: IP extended community it is expected to create a traffic filtering >>>>: rule for every flow-spec NLRI in the message that has this path as >>>>: its best path. The filter entry matches the IP packets described in >>>>: the NLRI field and redirects them (C=3D0) or copies them (C=3D1) >>>>towards >>>>: the IPv4 or IPv6 address specified in the 'Network Address of Next- >>>>: Hop' field of the associated MP_REACH_NLRI. More specifically: if >>>>an >>>>: IPv4 [or IPv6] packet with destination address D that is normally >>>>: forwarded to a next-hop A matches a filter entry of the type >>>>: described above it MUST instead be redirected (C=3D0) or mirrored >>>>: (C=3D1) to next-hop B, where B is found by FIB lookup of the IPv4 [= or >>>>: IPv6] address contained in the MP_REACH_NLRI next-hop field (i.e. a >>>>: longest-prefix-match lookup). Signaling and applying constraints >>>>: beyond longest-prefix-match on the types of interfaces or tunnels >>>>: that can be used as the redirection next-hop B are not precluded by >>>>: this specification but are nevertheless outside its scope. >>>> >>>>The text above raises some question with regard to mixed-address family >>>>behavior. To illustrate, we have four examples of IP-based forwarding: >>>> >>>>*IPv4 traffic over IPv4 forwarding >>>> IPv6 traffic over IPv4 forwarding >>>> IPv4 traffic over IPv6 forwarding >>>>*IPv6 traffic over IPv6 forwarding >>>> >>>>The cases noted with an asterisk aren't exciting - you'd expect them to >>>>just >>>>work regardless of whether the nexthop sent in the flowspec route is >>>>either >>>>an adjacent IP system or a tunnel covering the same address family. >>>> >>>>The other two cases are the interesting ones. >>>> >>>>One normally wouldn't expect IPv6 traffic to be IP forwarded to an IPv4 >>>>nexthop, or vice-versa. When the nexthop actually maps to a tunnel >>>>(e.g. >>>>MPLS), the case is perhaps a bit more ambiguous: Does the egress of the >>>>tunnel inspect the traffic to determine the proper ethertype for the >>>>traffic? >>>> >>>>This is admittedly not an immediate problem today. 5575 and the >>>>matching >>>>extension to do IPv6 currently expect the address family of the >>>>flowspec >>>>route to have an appropriate same-family MP-NEXTHOP. >>>> >>>>Put a somewhat different way, if the expected behavior is that you'll >>>>always >>>>have a nexthop for redirect that is of the same address family as the >>>>flowspec route, we're perhaps done. >>>> >>>>Until we decide we want to do flowspec for something besides plain IP. >>>> >>>>But that is perhaps a different problem to worry about later. >>>> >>>>-- Jeff >>>>_______________________________________________ >>>>Idr mailing list >>>>Idr@ietf.org >>>>https://www.ietf.org/mailman/listinfo/idr >>> >>> _______________________________________________ >>> Idr mailing list >>> Idr@ietf.org >>> https://www.ietf.org/mailman/listinfo/idr From ju1738@att.com Sat Aug 10 17:43:22 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 609CA21F9E7C for ; Sat, 10 Aug 2013 17:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[AWL=2.400, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bcBkuX-08ggV for ; Sat, 10 Aug 2013 17:43:17 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id 0AD8721F999D for ; Sat, 10 Aug 2013 17:36:16 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo06.seg.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 18cd6025.68a5a940.2186665.00-502.6084826.nbfkord-smmo06.seg.att.com (envelope-from ); Sun, 11 Aug 2013 00:36:17 +0000 (UTC) X-MXL-Hash: 5206dc817056eac0-de6c6cafceaf95b5ecee1e119a964f7dce242c50 Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id c7cd6025.0.2186661.00-386.6084795.nbfkord-smmo06.seg.att.com (envelope-from ); Sun, 11 Aug 2013 00:36:13 +0000 (UTC) X-MXL-Hash: 5206dc7d6abbf440-4e3752b4acf6b1632084cc7c3c362f3c676028c7 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r7B0aCWv025205; Sat, 10 Aug 2013 20:36:12 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r7B0a4Kk025000 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 10 Aug 2013 20:36:09 -0400 Received: from MISOUT7MSGHUB9A.ITServices.sbc.com (misout7msghub9a.itservices.sbc.com [144.151.223.62]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Sun, 11 Aug 2013 00:35:56 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9A.ITServices.sbc.com ([169.254.21.136]) with mapi id 14.02.0342.003; Sat, 10 Aug 2013 20:35:55 -0400 From: "UTTARO, JAMES" To: "Simpson, Adam (Adam)" , Robert Raszuk Thread-Topic: [Idr] Question on forwarding behavior in draft-ietf-idr-flowspec-redirect Thread-Index: AQHOlGd1cAe6HDXXbUqplfVCm2LmA5mPKq4w Date: Sun, 11 Aug 2013 00:35:54 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.64.168] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.146] X-AnalysisOut: [v=2.0 cv=b8MFFK6x c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=FcycQDp7aCwA:10 a=EyzBdUSTQP0A:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=cPZeZ7BBfQAA:10 a=48vgC7mUAAAA:8 a=2clOPd4PAAAA:8] X-AnalysisOut: [ a=Rg5jOeRUAAAA:8 a=Tg0nUI2_AAAA:8 a=7Y3Ohh8JPXofbt1jDAMA:] X-AnalysisOut: [9 a=CjuIK1q_8ugA:10 a=IcfWiavFb3IA:10 a=lZB815dzVvQA:10 a=] X-AnalysisOut: [bDUki_mJ7DgA:10 a=3ODoesluOjEA:10 a=YvXJW7wbCmQjCFm8:21 a=] X-AnalysisOut: [2x6HyCuZJW6LfK3z:21] Cc: "idr@ietf.org" Subject: Re: [Idr] Question on forwarding behavior in draft-ietf-idr-flowspec-redirect X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Aug 2013 00:43:22 -0000 I briefly looked over the draft. I have some general concerns about its use= i.e=20 - Single AS scope. We envision a world where DCs use different ASes from ea= ch other and from the WAN.. - Inconsistent routing due to incorrect programming of the vector attr by a= n SDN controller - SDN control across admin boundaries i.e 3rd party provides DC services an= d partners with a WAN provider.. How would the WAN SDN controller no about = the interior addr scheme of the DC? A number of variations on this theme..= =20 - How does the reprogramming of the FIB to be in line with the vector attr = behave in various fast re-route scenarios - Consistent view from an edge perspective.. This is sort of OpenFlowish in= that all participants need to get and program the same behavior..i.e Micro= Looping, inconsistent forwarding etc... Jim Uttaro -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Simps= on, Adam (Adam) Sent: Thursday, August 08, 2013 2:46 PM To: Robert Raszuk Cc: idr@ietf.org Subject: Re: [Idr] Question on forwarding behavior in draft-ietf-idr-flowsp= ec-redirect Hi Robert, Thanks for the pointer to the BGP vector routing draft. I agree it could be complementary (but not a complete alternative) to the solution we are proposing. Let me discuss this with the other authors. -Adam On 2013-08-07 11:02 AM, "Robert Raszuk" wrote: >And for the draft-simpson-idr-flowspec-redirect during last IETF there >were number of corridor discussions that there are scenarios where >flowspec could highly benefit if we would attach BGP Vector Node Path >Attribute as described in draft-patel-raszuk-bgp-vector-routing-00. > >Hence it would be perhaps beneficial to talk to authors of >draft-simpson-idr-flowspec-redirect in consideration of using more >general solution to the problem they expressed and replaced proposed >ext community with BGP Vector Node attribute. > >Best regards, >R. > > >> On Wed, Aug 7, 2013 at 4:54 PM, Robert Raszuk wrote: >> Hi Jeff & Adam, >> >> Reading via your mails I am a bit confused if you are talking about >> "match" or "actions". >> >> "Redirect" is an action and 5575 just specifies redirect to a VRF >> based on the RT. Such VRF can have any AFI/SAFI enabled and in >> particular can be a start of encap (of any form) to some external >> device (very often traffic deep inspection/screening). >> >> While we are discussing some other forms of actions but so far this is >> out of scope of proposed documents. >> >> Reg "match" the MP_REACH next hop field is of the length zero. >> >> Rgs, >> R. >> >>> On Wed, Aug 7, 2013 at 3:46 AM, Simpson, Adam (Adam) >>>>> lucent.com> wrote: >>> Hi Jeff, >>> >>> Somehow your email escaped our notice and we neglected to respond. >>> Apologies for that.. >>> >>> Your observation is valid. The way we have chosen to encode the >>>redirect >>> destination means that if we want to send IPv6 traffic over an IPv4 >>>tunnel >>> we need to express the IPv4 tunnel destination in a special way (e.g. >>>an >>> IPv4-mapped IPv6 address) and vice versa; if that is our intent it >>>should >>> of course be defined in the draft and we will certainly look into that >>>for >>> the next revision. The alternative is to encode the tunnel destination >>> (and possibly associated tunnel parameters) using an entirely new path >>> attribute but we thought that was overkill for the main use cases we >>>were >>> targeting. >>> >>> Regards, >>> Adam >>> >>> >>> On 2013-06-18 3:51 PM, "Jeffrey Haas" wrote: >>> >>>>Authors, >>>> >>>>: When a BGP speaker receives an UPDATE message with the redirect-to- >>>>: IP extended community it is expected to create a traffic filtering >>>>: rule for every flow-spec NLRI in the message that has this path as >>>>: its best path. The filter entry matches the IP packets described in >>>>: the NLRI field and redirects them (C=3D0) or copies them (C=3D1) >>>>towards >>>>: the IPv4 or IPv6 address specified in the 'Network Address of Next- >>>>: Hop' field of the associated MP_REACH_NLRI. More specifically: if >>>>an >>>>: IPv4 [or IPv6] packet with destination address D that is normally >>>>: forwarded to a next-hop A matches a filter entry of the type >>>>: described above it MUST instead be redirected (C=3D0) or mirrored >>>>: (C=3D1) to next-hop B, where B is found by FIB lookup of the IPv4 [= or >>>>: IPv6] address contained in the MP_REACH_NLRI next-hop field (i.e. a >>>>: longest-prefix-match lookup). Signaling and applying constraints >>>>: beyond longest-prefix-match on the types of interfaces or tunnels >>>>: that can be used as the redirection next-hop B are not precluded by >>>>: this specification but are nevertheless outside its scope. >>>> >>>>The text above raises some question with regard to mixed-address family >>>>behavior. To illustrate, we have four examples of IP-based forwarding: >>>> >>>>*IPv4 traffic over IPv4 forwarding >>>> IPv6 traffic over IPv4 forwarding >>>> IPv4 traffic over IPv6 forwarding >>>>*IPv6 traffic over IPv6 forwarding >>>> >>>>The cases noted with an asterisk aren't exciting - you'd expect them to >>>>just >>>>work regardless of whether the nexthop sent in the flowspec route is >>>>either >>>>an adjacent IP system or a tunnel covering the same address family. >>>> >>>>The other two cases are the interesting ones. >>>> >>>>One normally wouldn't expect IPv6 traffic to be IP forwarded to an IPv4 >>>>nexthop, or vice-versa. When the nexthop actually maps to a tunnel >>>>(e.g. >>>>MPLS), the case is perhaps a bit more ambiguous: Does the egress of the >>>>tunnel inspect the traffic to determine the proper ethertype for the >>>>traffic? >>>> >>>>This is admittedly not an immediate problem today. 5575 and the >>>>matching >>>>extension to do IPv6 currently expect the address family of the >>>>flowspec >>>>route to have an appropriate same-family MP-NEXTHOP. >>>> >>>>Put a somewhat different way, if the expected behavior is that you'll >>>>always >>>>have a nexthop for redirect that is of the same address family as the >>>>flowspec route, we're perhaps done. >>>> >>>>Until we decide we want to do flowspec for something besides plain IP. >>>> >>>>But that is perhaps a different problem to worry about later. >>>> >>>>-- Jeff >>>>_______________________________________________ >>>>Idr mailing list >>>>Idr@ietf.org >>>>https://www.ietf.org/mailman/listinfo/idr >>> >>> _______________________________________________ >>> Idr mailing list >>> Idr@ietf.org >>> https://www.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From shares@ndzh.com Tue Aug 13 09:53:25 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3C0011E81A4 for ; Tue, 13 Aug 2013 09:53:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.002 X-Spam-Level: * X-Spam-Status: No, score=1.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DOS_OUTLOOK_TO_MX=1, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QSRnNWJSG6+j for ; Tue, 13 Aug 2013 09:53:18 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 57A1C21E80F0 for ; Tue, 13 Aug 2013 09:53:16 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.177.50; From: "Susan Hares" To: "idr wg" Date: Tue, 13 Aug 2013 12:53:04 -0400 Message-ID: <01b701ce9845$94758c20$bd60a460$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01B8_01CE9824.0D64D680" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac6YRV/YzWFlZ04vQBiaiy3Gci358g== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: 'Yakov Rekhter' , erosen@cisco.com, "'John G. Scudder'" Subject: Re: [Idr] draft-rosen-idr-extcomm-iana-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 16:53:26 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01B8_01CE9824.0D64D680 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Eric and Yakov: The document draft-rosen-idr-excomm-iana-00.txt has been accepted as a WG document. Please submit this draft as: draft-ietf-idr-excomm-iana-00.txt Sue Hares ------=_NextPart_000_01B8_01CE9824.0D64D680 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Eric and = Yakov:

&nbs= p;

The = document draft-rosen-idr-excomm-iana-00.txt has been accepted as a WG = document.

Please = submit this draft as:

&nbs= p;

draft-iet= f-idr-excomm-iana-00.txt

&nbs= p;

Sue = Hares

 

------=_NextPart_000_01B8_01CE9824.0D64D680-- From internet-drafts@ietf.org Wed Aug 21 10:14:02 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79F5211E80C5; Wed, 21 Aug 2013 10:14:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AnfqxIRJVqtg; Wed, 21 Aug 2013 10:14:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AA1F921F9CE9; Wed, 21 Aug 2013 10:13:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130821171336.13496.7262.idtracker@ietfa.amsl.com> Date: Wed, 21 Aug 2013 10:13:36 -0700 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-rfd-usable-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2013 17:14:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Inter-Domain Routing Working Group of the= IETF. Title : Making Route Flap Damping Usable Author(s) : Cristel Pelsser Randy Bush Keyur Patel Pradosh Mohapatra Olaf Maennel Filename : draft-ietf-idr-rfd-usable-03.txt Pages : 7 Date : 2013-08-21 Abstract: Route Flap Damping (RFD) was first proposed to reduce BGP churn in routers. Unfortunately, RFD was found to severely penalize sites for being well-connected because topological richness amplifies the number of update messages exchanged. Many operators have turned RFD off. Based on experimental measurement, this document recommends adjusting a few RFD algorithmic constants and limits, to reduce the high risks with RFD, with the result being damping a non-trivial amount of long term churn without penalizing well-behaved prefixes' normal convergence process. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-rfd-usable There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-rfd-usable-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-rfd-usable-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From shtsuchi@cisco.com Wed Aug 21 23:23:38 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B835A21F9F5B for ; Wed, 21 Aug 2013 23:23:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gGs-IjTjRKXR for ; Wed, 21 Aug 2013 23:23:34 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 64A0F21F9EEE for ; Wed, 21 Aug 2013 23:23:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=419; q=dns/txt; s=iport; t=1377152614; x=1378362214; h=message-id:date:from:mime-version:to:cc:subject: content-transfer-encoding; bh=+d4zk4YiBEfcxSqV92t6aGQaIdp4sL/gUCIHMubmjj4=; b=LNc4GrMEtOr2MMzAhnG0fON5PtTsMWAR7eFCvGQ5+5TYd0mHJ4Q3tr3K L5/k4yEEQg7MqwFS1atUQW7TeDfYDUQ3kahwX6eOx+/Y+QPIqKC0CYSQg EPQSE43BGKRi0QV9g4suSzXX0Kc/DFspa/m3MR/JQ9IjfTdF574VU0sqt g=; X-IronPort-AV: E=Sophos;i="4.89,932,1367971200"; d="scan'208";a="89787685" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 22 Aug 2013 06:23:33 +0000 Received: from dhcp-10-141-43-156.cisco.com (dhcp-10-141-43-156.cisco.com [10.141.43.156]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r7M6NVlk008347; Thu, 22 Aug 2013 06:23:32 GMT Message-ID: <5215AE63.2080102@cisco.com> Date: Thu, 22 Aug 2013 15:23:31 +0900 From: Shishio Tsuchiya User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: idr@ietf.org, draft-ietf-idr-add-paths@tools.ietf.org, draft-ietf-idr-best-external@tools.ietf.org Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: [Idr] "Advertisement of Multiple Paths in BGP" and "BGP Best External" Status X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 06:23:38 -0000 draft-ietf-idr-add-paths already expired. https://datatracker.ietf.org/doc/draft-ietf-idr-add-paths/ Is there any reason fot this status? I checked implementation of this feature. Cisco IOS-XE,IOS-XR,NX-OS and Juniper JUNOS already supported it. https://datatracker.ietf.org/doc/draft-ietf-idr-best-external/ BGP Best External also same. Some OSs already implemented it,but ietf draft already expired.. From internet-drafts@ietf.org Thu Aug 22 13:28:58 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D6D211E8242; Thu, 22 Aug 2013 13:28:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kjcVoiJTFxVP; Thu, 22 Aug 2013 13:28:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D0F921F9FD6; Thu, 22 Aug 2013 13:28:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130822202853.4072.7498.idtracker@ietfa.amsl.com> Date: Thu, 22 Aug 2013 13:28:53 -0700 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-extcomm-iana-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 20:28:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Inter-Domain Routing Working Group of the= IETF. Title : IANA Registries for BGP Extended Communities Author(s) : Eric C. Rosen Yakov Rekhter Filename : draft-ietf-idr-extcomm-iana-00.txt Pages : 18 Date : 2013-08-22 Abstract: This document reorganizes the IANA Registries for the type values and sub-type values of BGP Extended Communities attribute and the BGP IPv6-Address-Specific Extended Communities attribute. This is done in order to remove inter-dependencies among the registries, thus making it easier for IANA to determine which codepoints are available for assignment in which registries. This document also clarifies the information that must be provided to IANA when requesting an allocation from one or more of these registries. These changes are compatible with the existing allocations, and thus do not affect protocol implementations. The changes will however impact the "IANA Considerations" sections of future protocol specifications. This document updates RFCs 4360 and 5701. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-extcomm-iana There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-extcomm-iana-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From shares@ndzh.com Fri Aug 23 07:57:15 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79E9C11E82FA for ; Fri, 23 Aug 2013 07:57:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[AWL=0.758, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g6I9aiUxipCY for ; Fri, 23 Aug 2013 07:57:11 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 46B5011E81B2 for ; Fri, 23 Aug 2013 07:57:11 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.177.50; From: "Susan Hares" To: "idr wg" Date: Fri, 23 Aug 2013 10:57:07 -0400 Message-ID: <00da01cea011$09c50c80$1d4f2580$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00DB_01CE9FEF.82B5DD80" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: Ac6gEPa63w1J/Q70T2a37AKQev3sBw== X-Authenticated-User: skh@ndzh.com Cc: 'Yakov Rekhter' , erosen@cisco.com Subject: [Idr] WG LC for draft-ietf-idr-extcomm-iana-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2013 14:57:15 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00DB_01CE9FEF.82B5DD80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This messages starts a 2 week WG Last call for: IANA Registries for BGP Extended Communities draft-ietf-idr-extcomm-iana-00.txt https://datatracker.ietf.org/doc/draft-ietf-idr-extcomm-iana/ What this document does: This document reorganizes the IANA Registries for the type values and sub-type values of BGP Extended Communities attribute and the BGP IPv6-Address-Specific Extended Communities attribute. Comment early, frequently and often. Sue and John Idr-co-chairs ------=_NextPart_000_00DB_01CE9FEF.82B5DD80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

This messages = starts a 2 week WG Last call for:

 

IANA Registries for = BGP Extended Communities

draft-ietf-idr-extcomm-iana-00.txt

ht= tps://datatracker.ietf.org/doc/draft-ietf-idr-extcomm-iana/

 

What this document = does:

 

   This = document reorganizes the IANA Registries for the type values = and

   = sub-type values of BGP Extended Communities attribute and the = BGP

   = IPv6-Address-Specific Extended Communities = attribute.

 

Comment early, = frequently and often.

 

Sue and John =  

Idr-co-chairs

------=_NextPart_000_00DB_01CE9FEF.82B5DD80-- From shares@ndzh.com Fri Aug 23 08:12:29 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBC5111E8308 for ; Fri, 23 Aug 2013 08:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.898 X-Spam-Level: X-Spam-Status: No, score=-0.898 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YmwVxOJTJIXG for ; Fri, 23 Aug 2013 08:12:26 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id CCA5B11E81B8 for ; Fri, 23 Aug 2013 08:12:25 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.177.50; From: "Susan Hares" To: "idr wg" Date: Fri, 23 Aug 2013 11:12:21 -0400 Message-ID: <00ed01cea013$2b0ba7d0$8122f770$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00EE_01CE9FF1.A3FBDC90" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: Ac6gEcGK8AmeRQfXQ3icD7WWhrWtFg== X-Authenticated-User: skh@ndzh.com X-IsFriend: Cc: shares@ndzh.com Subject: [Idr] 2 Week LC for: Early Code point allocation for draft-ietf-idr-ls-distribution X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2013 15:12:29 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00EE_01CE9FF1.A3FBDC90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit idr wg: The authors of draft-ietf-idr-ls-distribution have asked for an early code point allocation. https://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution/ As the IETF 87 WG meeting discussion showed, there is good support by many implementers for this early code allocation. Please see the IETF 87 WG meeting notes (sent to list) for discussion. Per RFC4020, we are asking the WG for 2 week consensus call for these early code points. The 2 week WG last call starts today and it will end on September 6th. For those curious about the BGP parameter assignments http://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml Please comment early and often about allowing the early code point allocation. Comments on the draft are welcome in the exchange as this draft is rapidly moving toward WG LC, but please clearly state if you want to allocate early allocation. Sue Hares and John Scudder WG co-chairs ------=_NextPart_000_00EE_01CE9FF1.A3FBDC90 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

idr wg: =

 

The authors of draft-ietf-idr-ls-distribution have = asked for an early code point allocation.

https://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution/ =

 

As the IETF 87 WG meeting discussion showed, there is = good support by many implementers for this early code allocation. =  Please see the IETF 87 WG meeting notes (sent to list) for = discussion.  Per RFC4020, we are asking the WG for 2 week consensus = call for these early code points.

 

The 2 week = WG last call starts today and it will end on September = 6th. 

 

For those = curious about the BGP parameter assignments

http://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml

 

Please comment early and often about allowing the = early code point allocation. 

 

Comments on = the draft are welcome in the exchange as this draft is rapidly moving = toward WG LC, but please clearly state if you want to allocate early = allocation.

 

Sue Hares and John Scudder

WG co-chairs

------=_NextPart_000_00EE_01CE9FF1.A3FBDC90-- From shares@ndzh.com Fri Aug 23 08:13:52 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FE6C11E8170 for ; Fri, 23 Aug 2013 08:13:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.948 X-Spam-Level: X-Spam-Status: No, score=-0.948 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YNUeO6XeDmQf for ; Fri, 23 Aug 2013 08:13:48 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id CF1C411E8105 for ; Fri, 23 Aug 2013 08:13:47 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.177.50; From: "Susan Hares" To: "'idr wg'" Date: Fri, 23 Aug 2013 11:13:43 -0400 Message-ID: <010001cea013$5bba1e70$132e5b50$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0101_01CE9FF1.D4AA0510" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: Ac6gE1ss2l9iWZjYSDOSEa4Cwes9kA== X-Authenticated-User: skh@ndzh.com Cc: 'Yakov Rekhter' , erosen@cisco.com Subject: Re: [Idr] WG LC for draft-ietf-idr-extcomm-iana-00.txt - 2nd message with end date X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2013 15:13:52 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0101_01CE9FF1.D4AA0510 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This messages starts a 2 week WG Last call (ending 9/6/2013): IANA Registries for BGP Extended Communities draft-ietf-idr-extcomm-iana-00.txt https://datatracker.ietf.org/doc/draft-ietf-idr-extcomm-iana/ What this document does: This document reorganizes the IANA Registries for the type values and sub-type values of BGP Extended Communities attribute and the BGP IPv6-Address-Specific Extended Communities attribute. Comment early, frequently and often. Sue and John Idr-co-chairs ------=_NextPart_000_0101_01CE9FF1.D4AA0510 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

This messages = starts a 2 week WG Last call (ending = 9/6/2013):

 

IANA Registries for = BGP Extended Communities

draft-ietf-idr-extcomm-iana-00.txt

ht= tps://datatracker.ietf.org/doc/draft-ietf-idr-extcomm-iana/

 

What this document = does:

 

   This = document reorganizes the IANA Registries for the type values = and

   = sub-type values of BGP Extended Communities attribute and the = BGP

   = IPv6-Address-Specific Extended Communities = attribute.

 

Comment early, = frequently and often.

 

Sue and John =  

Idr-co-chairs

------=_NextPart_000_0101_01CE9FF1.D4AA0510-- From fenner@fenron.com Fri Aug 23 10:45:03 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D302911E8307 for ; Fri, 23 Aug 2013 10:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JAhyh0Va1San for ; Fri, 23 Aug 2013 10:44:58 -0700 (PDT) Received: from mail-qc0-f171.google.com (mail-qc0-f171.google.com [209.85.216.171]) by ietfa.amsl.com (Postfix) with ESMTP id A9A4711E8306 for ; Fri, 23 Aug 2013 10:44:58 -0700 (PDT) Received: by mail-qc0-f171.google.com with SMTP id n1so500652qcw.30 for ; Fri, 23 Aug 2013 10:44:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=D6njZH9KuPiZxOOhOv2ljYVwG4e//Ouc/sXQSsFAL7A=; b=M+WmoKy6DeiSQ4Ou+YhdVqt/fDZDI0MEtsD+prEsgpjF3tQ1tjfEpVsYFKt+rVl5jg gOabr/QavnBGJA7CCzPQy8uwZjHCwDjuAEBa1WFwH+X/Q4bCSP6fheTvrwxgJBRe/eU2 r6fizkJYUSe7cE61i8SMyemybaervTIAptJ0ArXgpvvXmeV8TbnoL96sDfp3WiL6dx+G anft0yfqaIMfIN+O+2I5SL6LRS1tqfwXN1CqmQ32mOVxmAJPD2kbt/D477JDy2cb10+K B1r8HUE0C0wZMle6kFE4F1o7Z7ne9hL1Z8RMv3NXdPlc/JWQNMteHQjR7pheI3t+2VjR 3uAg== X-Gm-Message-State: ALoCoQlYUxfT4YaExLehPjx57FHDgUXkuIEQEpfPwTJgL7VM1e5QKruBGEwRsZhArS9rF6Jmrx+u MIME-Version: 1.0 X-Received: by 10.49.71.41 with SMTP id r9mr1092609qeu.49.1377279897068; Fri, 23 Aug 2013 10:44:57 -0700 (PDT) Received: by 10.224.127.132 with HTTP; Fri, 23 Aug 2013 10:44:57 -0700 (PDT) Date: Fri, 23 Aug 2013 13:44:57 -0400 Message-ID: From: Bill Fenner To: idr@ietf.org Content-Type: multipart/alternative; boundary=047d7b677c7e0577b104e4a0f712 X-Mailman-Approved-At: Fri, 23 Aug 2013 11:03:11 -0700 Subject: [Idr] Backwards Transition in BGP4V2-MIB X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2013 17:45:03 -0000 --047d7b677c7e0577b104e4a0f712 Content-Type: text/plain; charset=ISO-8859-1 The backwards transition trap includes the last received notification. There are cases when interesting backwards transitions occur and the last sent notification provides more info about why (e.g., "cease/max prefixes reached", "cease/admin reset"). Is it reasonable to include the last sent notification too? What about also including the timestamps so that the trap receiver can tell whether a given notification happened recently or a long time ago? Bill --047d7b677c7e0577b104e4a0f712 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The backwards transition trap includes the last received n= otification. =A0There are cases when interesting backwards transitions occu= r and the last sent notification provides more info about why (e.g., "= cease/max prefixes reached", "cease/admin reset"). =A0Is it = reasonable to include the last sent notification too? =A0What about also in= cluding the timestamps so that the trap receiver can tell whether a given n= otification happened recently or a long time ago?

=A0 Bill

--047d7b677c7e0577b104e4a0f712-- From aretana@cisco.com Fri Aug 23 13:01:27 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DEC611E811A for ; Fri, 23 Aug 2013 13:01:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XpR4xAuF4gC8 for ; Fri, 23 Aug 2013 13:01:22 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 4A43F11E8106 for ; Fri, 23 Aug 2013 13:01:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=858; q=dns/txt; s=iport; t=1377288082; x=1378497682; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=acCdy1i9PEhZ3c8J6aqedAnB/hh4h489m9J7NEug7NU=; b=LED/+vpefXJ6E0OGPxt4+KYdZleyWWMS1nxB8AyNWwCaT6rdouKOj+aS a2tZbFZcaON8O2VDx8W8InCDl15etmt+7PZf9KuP180MBWLshyZn/l1vG PMMhLlqi3ae9K/x9KqRkTn3IdrZzuCKZEoTX+ILwdAkNaPZxXHqdJmHDr c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtMFAE2/F1KtJV2d/2dsb2JhbABagwc1UYJXvSCBIBZ0giYBBAEBATc0HQEIIhQ3CyUCBAESCId5DLZvBJA/OIMcfAOpSIFjgTuCKg X-IronPort-AV: E=Sophos;i="4.89,944,1367971200"; d="scan'208";a="251047136" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-2.cisco.com with ESMTP; 23 Aug 2013 20:01:22 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r7NK1L5f017594 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 23 Aug 2013 20:01:21 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.182]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Fri, 23 Aug 2013 15:01:21 -0500 From: "Alvaro Retana (aretana)" To: "Shishio Tsuchiya (shtsuchi)" , "idr@ietf.org" , "draft-ietf-idr-add-paths@tools.ietf.org" , "draft-ietf-idr-best-external@tools.ietf.org" Thread-Topic: [Idr] "Advertisement of Multiple Paths in BGP" and "BGP Best External" Status Thread-Index: AQHOnwApaKcKnWa/N0q6YgisP83J5pmjSdIA Date: Fri, 23 Aug 2013 20:01:20 +0000 Message-ID: In-Reply-To: <5215AE63.2080102@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.15.7] Content-Type: text/plain; charset="us-ascii" Content-ID: <0676C95C017D51499A76CDE975B81168@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Idr] "Advertisement of Multiple Paths in BGP" and "BGP Best External" Status X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2013 20:01:27 -0000 On 8/22/13 2:23 AM, "Shishio Tsuchiya (shtsuchi)" wrote: Hi! >draft-ietf-idr-add-paths already expired. >https://datatracker.ietf.org/doc/draft-ietf-idr-add-paths/ > >Is there any reason fot this status? Simple: we haven't put the time aside to refresh the draft: lots of other things going on. I suspect that's the same reason the best external draft hasn't been refreshed. > >I checked implementation of this feature. >Cisco IOS-XE,IOS-XR,NX-OS and Juniper JUNOS already supported it. :-) Alvaro. > >https://datatracker.ietf.org/doc/draft-ietf-idr-best-external/ > >BGP Best External also same. >Some OSs already implemented it,but ietf draft already expired.. > > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www.ietf.org/mailman/listinfo/idr From shtsuchi@cisco.com Fri Aug 23 19:25:12 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AA8A21F9E6A for ; Fri, 23 Aug 2013 19:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_55=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HtrYKU5iqudP for ; Fri, 23 Aug 2013 19:25:08 -0700 (PDT) Received: from bgl-iport-4.cisco.com (bgl-iport-4.cisco.com [72.163.197.28]) by ietfa.amsl.com (Postfix) with ESMTP id D3D2E21F9E40 for ; Fri, 23 Aug 2013 19:25:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1416; q=dns/txt; s=iport; t=1377311108; x=1378520708; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=6NcO8mFTiI3UCxCvZixhXox/hZO0eDREU8PfA49h/Bo=; b=DlEciTAHZRVqizDFigkNARHdeeyYrbDyM7vI7Ya8hRJTddmpI5B4SMNe UXrDuot/whkHKjUWhoeycFK+v5DfOfD3vjKewj3uo0I8u2k/q3FVZ8Y/W APXvvQioeIX+gHBz5wI3aEwESIjq/70HFeNqd6BXyB/BgOMWyGJwl2Pqj g=; X-IronPort-AV: E=Sophos;i="4.89,946,1367971200"; d="scan'208";a="804171" Received: from vla196-nat.cisco.com (HELO bgl-core-3.cisco.com) ([72.163.197.24]) by bgl-iport-4.cisco.com with ESMTP; 24 Aug 2013 02:25:06 +0000 Received: from Shishio-no-MacBook-Air.local ([10.70.233.71]) by bgl-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r7O2P10V015220; Sat, 24 Aug 2013 02:25:02 GMT Message-ID: <5218197D.9060508@cisco.com> Date: Sat, 24 Aug 2013 11:25:01 +0900 From: Shishio Tsuchiya User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: aretana@cisco.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: idr@ietf.org, draft-ietf-idr-best-external@tools.ietf.org, draft-ietf-idr-add-paths@tools.ietf.org Subject: Re: [Idr] "Advertisement of Multiple Paths in BGP" and "BGP Best External" Status X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Aug 2013 02:25:12 -0000 Alvaro (2013/08/24 5:01), Alvaro Retana (aretana) wrote: > On 8/22/13 2:23 AM, "Shishio Tsuchiya (shtsuchi)" > wrote: > > Hi! > > >> draft-ietf-idr-add-paths already expired. >> https://datatracker.ietf.org/doc/draft-ietf-idr-add-paths/ >> >> Is there any reason fot this status? > > Simple: we haven't put the time aside to refresh the draft: lots of other > things going on. > > I suspect that's the same reason the best external draft hasn't been > refreshed. Ok. Running code exists. And both of feature must be interested for operator's. At least in Japan,these topics often are being talked and discussed in JANOG and Interop Events. In interop2013,they tested interoperability of add-path within cisco, juniper and non-supported vendors. http://www.interop.jp/2013/shownet/point.html(*Japanese) We are expecting update and proceed to rfc :-) Regards, -Shishio > >> >> I checked implementation of this feature. >> Cisco IOS-XE,IOS-XR,NX-OS and Juniper JUNOS already supported it. > > :-) > > Alvaro. > >> >> https://datatracker.ietf.org/doc/draft-ietf-idr-best-external/ >> >> BGP Best External also same. >> Some OSs already implemented it,but ietf draft already expired.. >> >> >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr > > . > From kaliraj@juniper.net Sat Aug 24 22:14:07 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B86011E820B for ; Sat, 24 Aug 2013 22:14:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BBOb7deHLoIc for ; Sat, 24 Aug 2013 22:14:02 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0186.outbound.messaging.microsoft.com [213.199.154.186]) by ietfa.amsl.com (Postfix) with ESMTP id CF2DE11E8203 for ; Sat, 24 Aug 2013 22:14:01 -0700 (PDT) Received: from mail40-db8-R.bigfish.com (10.174.8.238) by DB8EHSOBE007.bigfish.com (10.174.4.70) with Microsoft SMTP Server id 14.1.225.22; Sun, 25 Aug 2013 05:14:00 +0000 Received: from mail40-db8 (localhost [127.0.0.1]) by mail40-db8-R.bigfish.com (Postfix) with ESMTP id 387951C0339; Sun, 25 Aug 2013 05:14:00 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -18 X-BigFish: VPS-18(zzzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah186068h8275dh1de097hz2fh2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail40-db8: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=kaliraj@juniper.net; helo=BL2PRD0510HT001.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(199002)(189002)(74706001)(51856001)(74502001)(74366001)(81542001)(65816001)(76786001)(50986001)(47446002)(79102001)(76796001)(47976001)(69226001)(83322001)(15975445006)(56776001)(76482001)(54316002)(81816001)(15202345003)(81342001)(53806001)(19580395003)(31966008)(54356001)(74662001)(77982001)(59766001)(81686001)(74316001)(80976001)(46102001)(80022001)(63696002)(74876001)(76176001)(83072001)(4396001)(56816003)(33646001)(49866001)(76576001)(66066001)(47736001)(77096001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB151; H:BLUPR05MB040.namprd05.prod.outlook.com; CLIP:66.129.224.36; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail40-db8 (localhost.localdomain [127.0.0.1]) by mail40-db8 (MessageSwitch) id 1377407636791594_26305; Sun, 25 Aug 2013 05:13:56 +0000 (UTC) Received: from DB8EHSMHS030.bigfish.com (unknown [10.174.8.245]) by mail40-db8.bigfish.com (Postfix) with ESMTP id BB68F2E0041; Sun, 25 Aug 2013 05:13:56 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by DB8EHSMHS030.bigfish.com (10.174.4.40) with Microsoft SMTP Server (TLS) id 14.16.227.3; Sun, 25 Aug 2013 05:13:56 +0000 Received: from BLUPR05MB151.namprd05.prod.outlook.com (10.255.190.148) by BL2PRD0510HT001.namprd05.prod.outlook.com (10.255.100.36) with Microsoft SMTP Server (TLS) id 14.16.347.3; Sun, 25 Aug 2013 05:13:54 +0000 Received: from BLUPR05MB040.namprd05.prod.outlook.com (10.255.210.156) by BLUPR05MB151.namprd05.prod.outlook.com (10.255.190.148) with Microsoft SMTP Server (TLS) id 15.0.745.25; Sun, 25 Aug 2013 05:13:53 +0000 Received: from BLUPR05MB040.namprd05.prod.outlook.com ([169.254.1.192]) by BLUPR05MB040.namprd05.prod.outlook.com ([169.254.1.192]) with mapi id 15.00.0745.000; Sun, 25 Aug 2013 05:13:52 +0000 From: Kaliraj Vairavakkalai To: "ju1738@att.com" , "pmohapat@cisco.com" , "djsmith@cisco.com" , "wim.henderickx@alcatel-lucent.be" , "adam.simpson@alcatel-lucent.com" , "mtexier@arbor.net" Thread-Topic: Flowspec, coexistance of redirect and mirror actions Thread-Index: Ac6hUeKlWmhESTd+R3uwPlXU/S+k1A== Date: Sun, 25 Aug 2013 05:13:52 +0000 Message-ID: <1f2e4342dc3c4f15ace416939ed06a02@BLUPR05MB040.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.36] x-forefront-prvs: 09497C15EB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: Jeff Haas , "idr@ietf.org" Subject: [Idr] Flowspec, coexistance of redirect and mirror actions X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2013 05:14:07 -0000 Hi authors,=20 Ref: http://tools.ietf.org/html/draft-simpson-idr-flowspec-redirect-02 If it is desired to perform both "redirect-action" to a nexthop X, and "mir= ror-action" to a different nexthop Y simultaneously for the same flow, how = is it achieved?=20 It appears the signaling for such a scenario may not be handled by the mech= anisms specified in this draft, unless I am missing something. Could you pl= s clarify.=20 Thanks Kaliraj From dave@twitter.com Sat Aug 24 23:36:17 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C7BA11E821A for ; Sat, 24 Aug 2013 23:36:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FFHcLWKZaPIq for ; Sat, 24 Aug 2013 23:36:16 -0700 (PDT) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD2811E8216 for ; Sat, 24 Aug 2013 23:36:16 -0700 (PDT) Received: by mail-ie0-f170.google.com with SMTP id 17so3315300iea.1 for ; Sat, 24 Aug 2013 23:36:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=twitter.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=zk0LZqyH+/0T5oJjjv8aCcL5qS7CZ+6pojJRbsZ1YeM=; b=nEa9zQFR+9HsUk1xImmiusb2fF45qk9TcpeBjc3KGbEa3huH/iYKl5s2SUraxU36l/ AhqOV30rMjEhNSSWHgTTrRg0vdzs0hhLPCc16j/abSH+rMfPrUX49eQOU/XYKr2XxjS7 O6lqrm9q8Dc9V4XcYWFuvz9E1WvTSz2b0JIvE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=zk0LZqyH+/0T5oJjjv8aCcL5qS7CZ+6pojJRbsZ1YeM=; b=ZXLWWkQ0TFn49g6dK2EasE9Un2mhQu75V8wdG8CXtcOxyvHVZ01lzQhd/dWYyq+xlp hDkqPlqh93y5PZCAkE0S90Jv6hIDJXM9ZYzRw+sRQxShkCDD9RIB4Pi7FtxQIj3KzfX5 Lsrr6Jkxk+G1dF4u43Loz2ifwVsnHWX/8wx1ORl9IyXPIdEq72Kk2IfXwVLawWOJFQrw 7eDO0N3KxXpmHp8afHxmlS3puZezuGMG979wdnFevs158zuCXXAKdrNFa2/TJqbF3io1 YczaMrjIkez+pQtH9pbgWSmUMtJhjOta3ShFr98gHcDbqxaTv0xjxtigsAyA7/63d1v1 n6nQ== X-Gm-Message-State: ALoCoQmfRSnw8uOfby3yPtoMu7Fip6QA3qWU5QM8FsXkhblUIq5inRpnW8G4qqiOABNtYXmI2Dnr X-Received: by 10.50.3.3 with SMTP id 3mr2919671igy.54.1377412575668; Sat, 24 Aug 2013 23:36:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.182.202 with HTTP; Sat, 24 Aug 2013 23:35:55 -0700 (PDT) In-Reply-To: <1f2e4342dc3c4f15ace416939ed06a02@BLUPR05MB040.namprd05.prod.outlook.com> References: <1f2e4342dc3c4f15ace416939ed06a02@BLUPR05MB040.namprd05.prod.outlook.com> From: Dave Mitchell Date: Sat, 24 Aug 2013 23:35:55 -0700 Message-ID: To: idr@ietf.org Content-Type: multipart/alternative; boundary=089e013cbd3248405f04e4bfdb54 Subject: Re: [Idr] Flowspec, coexistance of redirect and mirror actions X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2013 06:36:17 -0000 --089e013cbd3248405f04e4bfdb54 Content-Type: text/plain; charset=ISO-8859-1 Hello, I think the above to options (port mirroring vs NH change) are completely different and should be used in different terms based on the actions required within the PFE. Since port-mirroring can sometimes need tunneling due to an indirect next-hop, using a single community to do both seems less than ideal, nor something operators would use very often. (just my $0.02) I most definitely agree that there needs to be a "then next-hop" option in flow-spec and a "match community", considering these exist in normal BGP NLRI policy statement. I'd also like to see the ability to take multiple prefixes (prefix-list) in a single statement and have them distributed in the FIB accordingly, as opposed to the single src/dest match options, per flow-route, that currently exist. I also think the inflexibility of differing prefix-length matching between src/dst in flow-spec should be investigated. I've had to work around this issue for years and it's not ideal. Community example for changing next-hop in flow-spec for a particular dest: route MODIFY_NH_FOO { match { community $foobar; } then { next-hop NH_SLASH_32; accept; } } Example of prefix list (src and dst) option that I feel would be useful for flow-spec in general. If for instance you are trying to deal with nasty source traffic to multiple datacenters on a backbone, the below route currently has to be $x numbers of datacenters as the dest, potentially bloating the RIB when in all reality, one statement should be able to be disseminated into the FIB correctly. route FS_PREFIX_LIST_FOO { match { source-prefix-list $foo; dest-prefix-list $bar; community $foobar; } then { next-hop NH_SLASH_32; accept; } } Thanks! On Sat, Aug 24, 2013 at 10:13 PM, Kaliraj Vairavakkalai wrote: > Hi authors, > > Ref: http://tools.ietf.org/html/draft-simpson-idr-flowspec-redirect-02 > > If it is desired to perform both "redirect-action" to a nexthop X, and > "mirror-action" to a different nexthop Y simultaneously for the same flow, > how is it achieved? > > It appears the signaling for such a scenario may not be handled by the > mechanisms specified in this draft, unless I am missing something. Could > you pls clarify. > > Thanks > Kaliraj > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --089e013cbd3248405f04e4bfdb54 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello,
=A0 I think the above to op= tions (port=20 mirroring vs NH change) are completely different and should be used in=20 different terms based on the actions
required within the PFE. Since=20 port-mirroring can sometimes need tunneling due to an indirect next-hop, using a single community to do both
seems less than ideal, nor something operators would use very often. (just = my $0.02)

I most definitely agree that there needs to be a "then next-hop" o= ption in=20 flow-spec and a "match community", considering=20 these
exist in normal BGP NLRI policy statement. I'd also like to see the=20 ability to take multiple prefixes (prefix-list) in a single statement=20 and have them
distributed in the FIB accordingly, as opposed to the=20 single src/dest match options, per flow-route, that currently exist. I=20 also think the inflexibility of
differing prefix-length matching between src/dst in flow-spec should be=20 investigated. I've had to work around this issue for years and it's= not=20 ideal.

Community example for changing next-hop in = flow-spec for a particular dest:

route MODIFY_NH_FOO {
=A0=A0=A0 match {
=A0=A0= =A0=A0=A0=A0=A0 community $foobar;
=A0=A0=A0 }
=A0=A0=A0 then {<= br>
=A0=A0=A0=A0=A0=A0=A0 next-hop NH_SLASH_32;
=A0= =A0=A0=A0=A0=A0=A0 accept;
=A0=A0=A0 }
}
=A0
Example of prefix list (src and dst) option that I feel would be useful=20 for flow-spec in general. If for instance you are trying to deal with=20 nasty
source traffic to multiple datacenters on a backbone, the below route currently has to be $x numbers of datacenters as the dest,=20 potentially
bloating the RIB when in all reality, one statement should be able to be di= sseminated into the FIB correctly.

route FS_PREFIX_LIST_FOO {
= =A0=A0=A0 match {
=A0=A0=A0=A0=A0=A0=A0 source-prefix-list $foo;
=A0=A0=A0=A0=A0=A0=A0 dest-prefix-list $bar;
=A0=A0=A0=A0=A0=A0=A0 community $foobar;
=A0=A0=A0 }
= =A0=A0=A0 then {
=A0=A0=A0=A0=A0=A0=A0 next-hop NH_SLASH_32;<= br>
=A0=A0=A0=A0=A0=A0=A0 accept;
=A0=A0=A0 }
}

Tha= nks!


On Sat, Aug 24, 2013 at 10:13 PM, Kaliraj Vairavakkalai <kaliraj@= juniper.net> wrote:
Hi authors,

Ref: http://tools.ietf.org/html/draft-simpson-idr-flow= spec-redirect-02

If it is desired to perform both "redirect-action" to a nexthop X= , and "mirror-action" to a different nexthop Y simultaneously for= the same flow, how is it achieved?

It appears the signaling for such a scenario may not be handled by the mech= anisms specified in this draft, unless I am missing something. Could you pl= s clarify.

Thanks
Kaliraj

_______________________________________________
Idr mailing list
Idr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr

--089e013cbd3248405f04e4bfdb54-- From dave@twitter.com Sat Aug 24 23:32:27 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACD1711E8218 for ; Sat, 24 Aug 2013 23:32:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tEfyoWnKOrPd for ; Sat, 24 Aug 2013 23:32:26 -0700 (PDT) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id B2F2811E8216 for ; Sat, 24 Aug 2013 23:32:18 -0700 (PDT) Received: by mail-ie0-f180.google.com with SMTP id x14so3078720ief.25 for ; Sat, 24 Aug 2013 23:32:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=twitter.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=w7cqXVhB3IvmVkO+fOEpp3XEEieVRI/AuU6rynsN/bE=; b=ewBrlAIranM+JX1r5OWJ3fltszdEA8UQKbUxXZcLYWszUOMwGWchNHbS+pbj+q0SW6 CUPhzQelP7WjcbhmOd9voZD0SPPQMUOBvvP9plGTZ6f+cPJU0etyA24Vg5xGjAR8tkKz FQsHfbJnE13Yk9O28UgLTeQy8H+7ZC8iRhysM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=w7cqXVhB3IvmVkO+fOEpp3XEEieVRI/AuU6rynsN/bE=; b=fuJE7Io5U3NZfJouxnOGKflsRfhAQ4swtmC1ABpNDj81qM98wpe31o46tTSkCLZi+1 BNM3K5k73er7Ga1h0Da24VpWmj7Eh8JXqCVICa0/xTJuINJ5qccL1L4zX9f4OBcLMjdh QLNEue5lZV0dpmVyA3s0qmBlMHxl8u2pNJiG5OeWuHmpv2p8vumKsERWa4kyxuoYeu88 XYrbSHLzRtJEa6dgVuLaCylcy7jKSycSnOjs7BjBPPwlfF6c5OzWyizT6c6sluSWIGFj cmHfDVP5jslep0HP9V4MeYmHxUGRdK7N5fKXXwYnoAKovkm5ZsuU2yTRrKVxpGBMpTho PvNQ== X-Gm-Message-State: ALoCoQlu7yjfk0h46vegtfMaek8V8mU2S3z1eg/gzHOqWN0/N5gEvsmROxGLd5nDfwMZS0qs6lHs X-Received: by 10.50.62.211 with SMTP id a19mr3049485igs.18.1377412336301; Sat, 24 Aug 2013 23:32:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.182.202 with HTTP; Sat, 24 Aug 2013 23:31:55 -0700 (PDT) In-Reply-To: <1f2e4342dc3c4f15ace416939ed06a02@BLUPR05MB040.namprd05.prod.outlook.com> References: <1f2e4342dc3c4f15ace416939ed06a02@BLUPR05MB040.namprd05.prod.outlook.com> From: Dave Mitchell Date: Sat, 24 Aug 2013 23:31:55 -0700 Message-ID: To: Kaliraj Vairavakkalai Content-Type: multipart/alternative; boundary=047d7bd7592004292304e4bfcdd4 X-Mailman-Approved-At: Sun, 25 Aug 2013 08:36:27 -0700 Cc: "mtexier@arbor.net" , "idr@ietf.org" , Jeff Haas , "djsmith@cisco.com" , "pmohapat@cisco.com" , Danny McPherson , "ju1738@att.com" , "wim.henderickx@alcatel-lucent.be" Subject: Re: [Idr] Flowspec, coexistance of redirect and mirror actions X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2013 06:32:28 -0000 --047d7bd7592004292304e4bfcdd4 Content-Type: text/plain; charset=ISO-8859-1 Hello, I think the above to options (port mirroring vs NH change) are completely different and should be used in different terms based on the actions required within the PFE. Since port-mirroring can sometimes need tunneling due to an indirect next-hop, using a single community to do both seems less than ideal nor something operators would use often. (just my $0.02) I most definitely agree there needs to be a "then next-hop" option in flow-spec and a "match community" to make things easier, considering these exist in normal BGP NLRI policy statement. I'd also like to see the ability to take multiple prefixes (prefix-list) in a single statement and have them distributed in the FIB accordingly, as opposed to the single src/dest match options, per flow-route, that currently exist. I also think the inflexibility of differing prefix-length matching between src/dst in flow-spec should be investigated. I've had to work around this issue for years and it's not ideal. Community example for changing next-hop in flow-spec for a particular dest: route MODIFY_NH_FOO { match { community $foobar; } then { next-hop NH_SLASH_32; accept; } } Example of prefix list (src and dst) option that I feel would be useful for flow-spec in general. If for instance you are trying to deal with nasty source traffic to multiple datacenters on a backbone, the below route currently has to be $x numbers of datacenters as the dest, potentially bloating the RIB when in all reality, one statement should be able to be disseminated into the FIB correctly. route FS_PREFIX_LIST_FOO { match { source-prefix-list $foo; dest-prefix-list $bar; community $foobar; } then { next-hop NH_SLASH_32; accept; } } Thanks! -dave On Sat, Aug 24, 2013 at 10:13 PM, Kaliraj Vairavakkalai wrote: > Hi authors, > > Ref: http://tools.ietf.org/html/draft-simpson-idr-flowspec-redirect-02 > > If it is desired to perform both "redirect-action" to a nexthop X, and > "mirror-action" to a different nexthop Y simultaneously for the same flow, > how is it achieved? > > It appears the signaling for such a scenario may not be handled by the > mechanisms specified in this draft, unless I am missing something. Could > you pls clarify. > > Thanks > Kaliraj > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --047d7bd7592004292304e4bfcdd4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello,
=A0 I think the above to op= tions (port mirroring vs NH change) are completely different and should be = used in different terms based on the actions
required within the PFE. S= ince port-mirroring can sometimes need tunneling due to an indirect next-ho= p, using a single community to do both
seems less than ideal nor something operators would use often. (just my $0.= 02)

I most definitely agree there needs to be a "then next-hop&= quot; option in flow-spec and a "match community" to make things = easier, considering these
exist in normal BGP NLRI policy statement. I'd also like to see the abi= lity to take multiple prefixes (prefix-list) in a single statement and have= them
distributed in the FIB accordingly, as opposed to the single src/= dest match options, per flow-route, that currently exist. I also think the = inflexibility of
differing prefix-length matching between src/dst in flow-spec should be inv= estigated. I've had to work around this issue for years and it's no= t ideal.

Community example for changing next-hop i= n flow-spec for a particular dest:

route MODIFY_NH_FOO {
=A0=A0=A0 match {
=A0=A0= =A0=A0=A0=A0=A0 community $foobar;
=A0=A0=A0 }
=A0=A0=A0 then {<= br>
=A0=A0=A0=A0=A0=A0=A0 next-hop NH_SLASH_32;
=A0= =A0=A0=A0=A0=A0=A0 accept;
=A0=A0=A0 }
}
=A0
Example of prefix list (src and dst) option that I feel would be useful for= flow-spec in general. If for instance you are trying to deal with nastysource traffic to multiple datacenters on a backbone, the below route curr= ently has to be $x numbers of datacenters as the dest, potentially
bloating the RIB when in all reality, one statement should be able to be di= sseminated into the FIB correctly.

route FS_PREFIX_LIST_FOO {
= =A0=A0=A0 match {
=A0=A0=A0=A0=A0=A0=A0 source-prefix-list $foo;
=A0=A0=A0=A0=A0=A0=A0 dest-prefix-list $bar;
=A0=A0=A0=A0=A0=A0=A0 community $foobar;
=A0=A0=A0 }
= =A0=A0=A0 then {
=A0=A0=A0=A0=A0=A0=A0 next-hop NH_SLASH_32;<= br>
=A0=A0=A0=A0=A0=A0=A0 accept;
=A0=A0=A0 }
}

Thanks!

-dave





On Sat, Aug 24, 2013 at 10:13 PM, Kaliraj Vairavakkalai <kaliraj@juni= per.net> wrote:
Hi authors,

Ref: http://tools.ietf.org/html/draft-simpson-idr-flow= spec-redirect-02

If it is desired to perform both "redirect-action" to a nexthop X= , and "mirror-action" to a different nexthop Y simultaneously for= the same flow, how is it achieved?

It appears the signaling for such a scenario may not be handled by the mech= anisms specified in this draft, unless I am missing something. Could you pl= s clarify.

Thanks
Kaliraj

_______________________________________________
Idr mailing list
Idr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr

--047d7bd7592004292304e4bfcdd4-- From thomas.mangin@exa-networks.co.uk Mon Aug 26 10:10:14 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61C0A11E81D5 for ; Mon, 26 Aug 2013 10:10:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CJAue44ue2yz for ; Mon, 26 Aug 2013 10:10:08 -0700 (PDT) Received: from out-5.mail.exa.net.uk (out-9.mail.exa.net.uk [82.219.4.137]) by ietfa.amsl.com (Postfix) with ESMTP id D048511E81C8 for ; Mon, 26 Aug 2013 10:09:54 -0700 (PDT) Received: from smtp-3.mail.exa.net.uk (smtp-3.mail.exa.net.uk [82.219.5.3]) by out-5.mail.exa.net.uk (ExaSMTPD) with ESMTP id 2971EA0058; Mon, 26 Aug 2013 18:09:50 +0100 (BST) Received: from ptr-34.212.219.82.rev.exa.net.uk (ptr-34.212.219.82.rev.exa.net.uk [82.219.212.34]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: thomas@mangin.com) by smtp-3.mail.exa.net.uk (ExaSMTPD) with ESMTPSA id ED4616C0047; Mon, 26 Aug 2013 18:09:49 +0100 (BST) From: Thomas Mangin Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Aug 2013 18:09:49 +0100 Message-Id: <891D6F02-B937-4BBB-9802-E1EE61B830D7@exa-networks.co.uk> To: draft-ietf-idr-flow-spec-v6@tools.ietf.org Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) X-Virus-Scanned: clamav-milter 0.97.8 at out-2-2.mail.exa.net.uk X-Virus-Status: Clean Cc: idr@ietf.org Subject: [Idr] draft-raszuk-idr-flow-spec-v6-03 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 17:12:48 -0000 Hello, I never posted to any IETF list of contributed to it, so please excuse = me if I do anything out of order. I would like to comment and propose a change to = draft-raszuk-idr-flow-spec-v6-03. I have implemented the draft in the head/trunk version of ExaBGP which = can be found at http://code.google.com/p/exabgp/ Implementing it I noticed the following : The IPv6 flows are encoded as : When the IPv4 flows are encoded : IMHO the draft should be changed to read : prefix length, prefix offset is the "classical BGP encoding", so every = IPv4/IPv6 address is stored as NLRI and encoded this way, extending the = encoding by prepending the offset is clean and easy, having to redefine = the encoding is not as nice. It is obvious as well when you look at some decoding code, in my case in = python: IPv4: _,rd,mask,size,prefix,left =3D _nlrifactory(afi,safi,bgp) IPv6: byte,bgp =3D bgp[1],bgp[0]+bgp[2:] offset =3D ord(byte) _,rd,mask,size,prefix,left =3D _nlrifactory(afi,safi,bgp) It would have been cleaner to write: offset =3D ord(bgp[0]) _,rd,mask,size,prefix,left =3D _nlrifactory(afi,safi,bgp[1:]) Thank you for reading, Thomas Mangin From rraszuk@gmail.com Mon Aug 26 18:26:56 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2970511E8126 for ; Mon, 26 Aug 2013 18:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Su8cPDt2gCBd for ; Mon, 26 Aug 2013 18:26:55 -0700 (PDT) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) by ietfa.amsl.com (Postfix) with ESMTP id 6F9BC11E80EC for ; Mon, 26 Aug 2013 18:26:54 -0700 (PDT) Received: by mail-lb0-f176.google.com with SMTP id y6so2003937lbh.7 for ; Mon, 26 Aug 2013 18:26:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=3gBttNjzTHvezXR6CXEJOrRyBB3E+RkRIcRJY5NogcY=; b=Wx8fdepOmHJR0lHxQ8TlKm93s12KAUmgpamq3z4Bgw45mLahvgLG2B8GQmnGc9tv0E utIWJvlUbpbo1/u/6adqLVTaZ5p01rHMkRHw7daK6Qfe+gSg5rcSQyPB/VrmQeVHah08 gEhVqJDrNuB65ICfFpuGRTZb95eQ39nr466Z2lDDmpNZvlWoW3FtNghGPly4cD8+X0/Q vgEtEd9XMSXB+26UQuJlhvwm10erDCwRoYBRjRvTWp++46/dENx/SoWyrnBl0xVZzmzB SJgmso/6ysgmDmZpx8HT5D8kzr/TFmShxwXNRYqpD3qnjQa2fwQq/Fn56U9UPEdcKe1y dMHg== MIME-Version: 1.0 X-Received: by 10.152.3.42 with SMTP id 10mr16549393laz.22.1377566813315; Mon, 26 Aug 2013 18:26:53 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.112.219.1 with HTTP; Mon, 26 Aug 2013 18:26:53 -0700 (PDT) In-Reply-To: <891D6F02-B937-4BBB-9802-E1EE61B830D7@exa-networks.co.uk> References: <891D6F02-B937-4BBB-9802-E1EE61B830D7@exa-networks.co.uk> Date: Tue, 27 Aug 2013 03:26:53 +0200 X-Google-Sender-Auth: MRHuhyLvSpW803DDBHaB_Ij5E_A Message-ID: From: Robert Raszuk To: Thomas Mangin Content-Type: multipart/alternative; boundary=089e013d14b28fe86304e4e3c454 Cc: draft-ietf-idr-flow-spec-v6@tools.ietf.org, idr wg Subject: Re: [Idr] draft-raszuk-idr-flow-spec-v6-03 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 01:26:56 -0000 --089e013d14b28fe86304e4e3c454 Content-Type: text/plain; charset=ISO-8859-1 Hi Thomas, Thank you very much for both the comment as well as implementation of the draft in ExaBGP. I agree with your suggestion and there was no particular reason why the order in the draft of the offset field was placed after the length field. As we are actually updating the draft now we will use your suggestion. Many thx for the contribution, R. On Mon, Aug 26, 2013 at 7:09 PM, Thomas Mangin < thomas.mangin@exa-networks.co.uk> wrote: > Hello, > > I never posted to any IETF list of contributed to it, so please excuse me > if I do anything out of order. > > I would like to comment and propose a change to > draft-raszuk-idr-flow-spec-v6-03. > I have implemented the draft in the head/trunk version of ExaBGP which can > be found at http://code.google.com/p/exabgp/ > > Implementing it I noticed the following : > > The IPv6 flows are encoded as : > > > When the IPv4 flows are encoded : > > > IMHO the draft should be changed to read : > > > prefix length, prefix offset is the "classical BGP encoding", so every > IPv4/IPv6 address is stored as NLRI and encoded this way, extending the > encoding by prepending the offset is clean and easy, having to redefine the > encoding is not as nice. > > It is obvious as well when you look at some decoding code, in my case in > python: > > IPv4: > _,rd,mask,size,prefix,left = _nlrifactory(afi,safi,bgp) > > IPv6: > byte,bgp = bgp[1],bgp[0]+bgp[2:] > offset = ord(byte) > _,rd,mask,size,prefix,left = _nlrifactory(afi,safi,bgp) > > It would have been cleaner to write: > offset = ord(bgp[0]) > _,rd,mask,size,prefix,left = _nlrifactory(afi,safi,bgp[1:]) > > Thank you for reading, > > Thomas Mangin > > > --089e013d14b28fe86304e4e3c454 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Thomas,

Thank you very much for both the comment= as well as implementation of the draft in ExaBGP.

I agree with your= suggestion and there was no particular reason why the order in the draft o= f the offset field was placed after the length field.

As we are actually updating the draft now we will use your suggestion. =

Many thx for the contribution,
R.



On Mon, Aug 26, 201= 3 at 7:09 PM, Thomas Mangin <thomas.mangin@exa-networks.co.= uk> wrote:
Hello,

I never posted to any IETF list of contributed to it, so please excuse me i= f I do anything out of order.

I would like to comment and propose a change to draft-raszuk-idr-flow-spec-= v6-03.
I have implemented the draft in the head/trunk version of ExaBGP which can = be found at = http://code.google.com/p/exabgp/

Implementing it I noticed the following :

The IPv6 flows are encoded as :
<type (1 octet), prefix length (1 octet), prefix offset (1 octet), prefi= x>

When the IPv4 flows are encoded :
<type (1 octet), prefix length (1 octet), prefix>

IMHO the draft should be changed to read :
<type (1 octet), prefix offset (1 octet), prefix length (1 octet), prefi= x>

prefix length, prefix offset is the "classical BGP encoding", so = every IPv4/IPv6 address is stored as NLRI and encoded this way, extending t= he encoding by prepending the offset is clean and easy, having to redefine = the encoding is not as nice.

It is obvious as well when you look at some decoding code, in my case in py= thon:

IPv4:
_,rd,mask,size,prefix,left =3D _nlrifactory(afi,safi,bgp)

IPv6:
byte,bgp =3D bgp[1],bgp[0]+bgp[2:]
offset =3D ord(byte)
_,rd,mask,size,prefix,left =3D _nlrifactory(afi,safi,bgp)

It would have been cleaner to write:
offset =3D ord(bgp[0])
_,rd,mask,size,prefix,left =3D _nlrifactory(afi,safi,bgp[1:])

Thank you for reading,

Thomas Mangin



--089e013d14b28fe86304e4e3c454-- From thomas.mangin@exa-networks.co.uk Tue Aug 27 01:06:51 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8F1811E8176 for ; Tue, 27 Aug 2013 01:06:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.008 X-Spam-Level: X-Spam-Status: No, score=-2.008 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sN+01QPWpq30 for ; Tue, 27 Aug 2013 01:06:42 -0700 (PDT) Received: from out-5.mail.exa.net.uk (out-9.mail.exa.net.uk [82.219.4.137]) by ietfa.amsl.com (Postfix) with ESMTP id BF96A11E8173 for ; Tue, 27 Aug 2013 01:06:32 -0700 (PDT) Received: from smtp-4.mail.exa.net.uk (smtp-4.mail.exa.net.uk [82.219.5.4]) by out-5.mail.exa.net.uk (ExaSMTPD) with ESMTP id 166D0A006C; Tue, 27 Aug 2013 09:06:20 +0100 (BST) Received: from ptr-34.212.219.82.rev.exa.net.uk (ptr-34.212.219.82.rev.exa.net.uk [82.219.212.34]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: thomas@mangin.com) by smtp-4.mail.exa.net.uk (ExaSMTPD) with ESMTPSA id CA1F44005D; Tue, 27 Aug 2013 09:06:19 +0100 (BST) Content-Type: multipart/alternative; boundary="Apple-Mail=_FE751748-DE4D-437A-B234-A74E1A04920F" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Thomas Mangin In-Reply-To: Date: Tue, 27 Aug 2013 09:06:21 +0100 Message-Id: <4F88DD46-2EB3-492F-B1AB-FFD207F71ADF@exa-networks.co.uk> References: <891D6F02-B937-4BBB-9802-E1EE61B830D7@exa-networks.co.uk> To: rraszuk@gmail.com X-Mailer: Apple Mail (2.1508) X-Virus-Scanned: clamav-milter 0.97.8 at out-2-2.mail.exa.net.uk X-Virus-Status: Clean Cc: draft-ietf-idr-flow-spec-v6@tools.ietf.org, idr wg Subject: Re: [Idr] draft-raszuk-idr-flow-spec-v6-03 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 08:06:51 -0000 X-List-Received-Date: Tue, 27 Aug 2013 08:06:51 -0000 --Apple-Mail=_FE751748-DE4D-437A-B234-A74E1A04920F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hello Robert, I am very pleased to hear that you agree and that you are still working = on the draft. I will keep an eye on your work and I will update ExaBGP as soon as the = next version is out. Sincerely, Thomas On 27 Aug 2013, at 02:26, Robert Raszuk wrote: > Hi Thomas, >=20 > Thank you very much for both the comment as well as implementation of = the draft in ExaBGP. >=20 > I agree with your suggestion and there was no particular reason why = the order in the draft of the offset field was placed after the length = field. >=20 > As we are actually updating the draft now we will use your suggestion.=20= >=20 > Many thx for the contribution, > R. >=20 >=20 >=20 > On Mon, Aug 26, 2013 at 7:09 PM, Thomas Mangin = wrote: > Hello, >=20 > I never posted to any IETF list of contributed to it, so please excuse = me if I do anything out of order. >=20 > I would like to comment and propose a change to = draft-raszuk-idr-flow-spec-v6-03. > I have implemented the draft in the head/trunk version of ExaBGP which = can be found at http://code.google.com/p/exabgp/ >=20 > Implementing it I noticed the following : >=20 > The IPv6 flows are encoded as : > >=20 > When the IPv4 flows are encoded : > >=20 > IMHO the draft should be changed to read : > >=20 > prefix length, prefix offset is the "classical BGP encoding", so every = IPv4/IPv6 address is stored as NLRI and encoded this way, extending the = encoding by prepending the offset is clean and easy, having to redefine = the encoding is not as nice. >=20 > It is obvious as well when you look at some decoding code, in my case = in python: >=20 > IPv4: > _,rd,mask,size,prefix,left =3D _nlrifactory(afi,safi,bgp) >=20 > IPv6: > byte,bgp =3D bgp[1],bgp[0]+bgp[2:] > offset =3D ord(byte) > _,rd,mask,size,prefix,left =3D _nlrifactory(afi,safi,bgp) >=20 > It would have been cleaner to write: > offset =3D ord(bgp[0]) > _,rd,mask,size,prefix,left =3D _nlrifactory(afi,safi,bgp[1:]) >=20 > Thank you for reading, >=20 > Thomas Mangin >=20 >=20 >=20 --Apple-Mail=_FE751748-DE4D-437A-B234-A74E1A04920F Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1 Hello Robert,

I am very pleased to hear that you agree and that you are still working on the draft.
I will keep an eye on your work and I will update ExaBGP as soon as the next version is out.

Sincerely,

Thomas

On 27 Aug 2013, at 02:26, Robert Raszuk <robert@raszuk.net> wrote:

Hi Thomas,

Thank you very much for both the comment as well as implementation of the draft in ExaBGP.

I agree with your suggestion and there was no particular reason why the order in the draft of the offset field was placed after the length field.

As we are actually updating the draft now we will use your suggestion.

Many thx for the contribution,
R.



On Mon, Aug 26, 2013 at 7:09 PM, Thomas Mangin <thomas.mangin@exa-networks.co.uk> wrote:
Hello,

I never posted to any IETF list of contributed to it, so please excuse me if I do anything out of order.

I would like to comment and propose a change to draft-raszuk-idr-flow-spec-v6-03.
I have implemented the draft in the head/trunk version of ExaBGP which can be found at http://code.google.com/p/exabgp/

Implementing it I noticed the following :

The IPv6 flows are encoded as :
<type (1 octet), prefix length (1 octet), prefix offset (1 octet), prefix>

When the IPv4 flows are encoded :
<type (1 octet), prefix length (1 octet), prefix>

IMHO the draft should be changed to read :
<type (1 octet), prefix offset (1 octet), prefix length (1 octet), prefix>

prefix length, prefix offset is the "classical BGP encoding", so every IPv4/IPv6 address is stored as NLRI and encoded this way, extending the encoding by prepending the offset is clean and easy, having to redefine the encoding is not as nice.

It is obvious as well when you look at some decoding code, in my case in python:

IPv4:
_,rd,mask,size,prefix,left = _nlrifactory(afi,safi,bgp)

IPv6:
byte,bgp = bgp[1],bgp[0]+bgp[2:]
offset = ord(byte)
_,rd,mask,size,prefix,left = _nlrifactory(afi,safi,bgp)

It would have been cleaner to write:
offset = ord(bgp[0])
_,rd,mask,size,prefix,left = _nlrifactory(afi,safi,bgp[1:])

Thank you for reading,

Thomas Mangin




--Apple-Mail=_FE751748-DE4D-437A-B234-A74E1A04920F-- From adam.simpson@alcatel-lucent.com Tue Aug 27 10:18:40 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C30B21E80BB for ; Tue, 27 Aug 2013 10:18:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GnK7ds-8O7-e for ; Tue, 27 Aug 2013 10:18:34 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 97CAE21E809A for ; Tue, 27 Aug 2013 10:18:34 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (h135-5-2-64.lucent.com [135.5.2.64]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id r7RHIVFh029752 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 27 Aug 2013 12:18:32 -0500 (CDT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id r7RHIQL8030419 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 27 Aug 2013 13:18:31 -0400 Received: from US70TWXCHMBA09.zam.alcatel-lucent.com ([169.254.3.100]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.02.0247.003; Tue, 27 Aug 2013 13:18:31 -0400 From: "Simpson, Adam (Adam)" To: Kaliraj Vairavakkalai , "ju1738@att.com" , "pmohapat@cisco.com" , "djsmith@cisco.com" , "Henderickx, Wim (Wim)" , "mtexier@arbor.net" Thread-Topic: Flowspec, coexistance of redirect and mirror actions Thread-Index: Ac6hUeKlWmhESTd+R3uwPlXU/S+k1AB94zoA Date: Tue, 27 Aug 2013 17:18:30 +0000 Message-ID: In-Reply-To: <1f2e4342dc3c4f15ace416939ed06a02@BLUPR05MB040.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: Jeff Haas , "idr@ietf.org" Subject: Re: [Idr] Flowspec, coexistance of redirect and mirror actions X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 17:18:40 -0000 Hi Kaliraj, You are correct; these actions are mutually exclusive according to the current encoding. What does it mean for you to have a flow both moved (redirected) and copied (mirrored)? Do you mean the original flow with destination A is steered/moved to new destination B while at the same time a copy of this flow is sent to a new destination C? I personally have not seen a requirement for this type of compound action but I will leave the other authors to comment as well. -Adam On 2013-08-25 1:13 AM, "Kaliraj Vairavakkalai" wrote: >Hi authors,=20 > >Ref: http://tools.ietf.org/html/draft-simpson-idr-flowspec-redirect-02 > >If it is desired to perform both "redirect-action" to a nexthop X, and >"mirror-action" to a different nexthop Y simultaneously for the same >flow, how is it achieved? > >It appears the signaling for such a scenario may not be handled by the >mechanisms specified in this draft, unless I am missing something. Could >you pls clarify.=20 > >Thanks >Kaliraj > From kaliraj@juniper.net Tue Aug 27 10:55:48 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD05011E81D0 for ; Tue, 27 Aug 2013 10:55:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gNx7sfKE1g01 for ; Tue, 27 Aug 2013 10:55:39 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe005.messaging.microsoft.com [216.32.181.185]) by ietfa.amsl.com (Postfix) with ESMTP id 6BD0321F9D3B for ; Tue, 27 Aug 2013 10:55:31 -0700 (PDT) Received: from mail83-ch1-R.bigfish.com (10.43.68.247) by CH1EHSOBE009.bigfish.com (10.43.70.59) with Microsoft SMTP Server id 14.1.225.22; Tue, 27 Aug 2013 17:55:30 +0000 Received: from mail83-ch1 (localhost [127.0.0.1]) by mail83-ch1-R.bigfish.com (Postfix) with ESMTP id D4453160103; Tue, 27 Aug 2013 17:55:30 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: VPS-24(zz98dI9371I936eI542I1432I4015Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz8275ch1de098h1033IL17326ah186068h8275dh1de097hz2fh2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail83-ch1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=kaliraj@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(13464003)(199002)(189002)(24454002)(377424004)(377454003)(51704005)(164054003)(51856001)(65816001)(77982001)(59766001)(74366001)(19580395003)(76786001)(83072001)(19580405001)(76796001)(83322001)(81816001)(15975445006)(81686001)(33646001)(49866001)(50986001)(47976001)(76576001)(63696002)(46102001)(47736001)(79102001)(15202345003)(4396001)(81542001)(74316001)(74876001)(69226001)(53806001)(54316002)(77096001)(56776001)(66066001)(80022001)(80976001)(54356001)(56816003)(74502001)(74662001)(47446002)(81342001)(76482001)(31966008)(74706001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR05MB155; H:BN1PR05MB041.namprd05.prod.outlook.com; CLIP:66.129.224.36; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail83-ch1 (localhost.localdomain [127.0.0.1]) by mail83-ch1 (MessageSwitch) id 1377626129971418_12557; Tue, 27 Aug 2013 17:55:29 +0000 (UTC) Received: from CH1EHSMHS005.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.228]) by mail83-ch1.bigfish.com (Postfix) with ESMTP id E8E3C480040; Tue, 27 Aug 2013 17:55:29 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS005.bigfish.com (10.43.70.5) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 27 Aug 2013 17:55:29 +0000 Received: from BN1PR05MB155.namprd05.prod.outlook.com (10.255.205.17) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.347.3; Tue, 27 Aug 2013 17:55:28 +0000 Received: from BN1PR05MB041.namprd05.prod.outlook.com (10.255.202.140) by BN1PR05MB155.namprd05.prod.outlook.com (10.255.205.17) with Microsoft SMTP Server (TLS) id 15.0.745.25; Tue, 27 Aug 2013 17:55:26 +0000 Received: from BN1PR05MB041.namprd05.prod.outlook.com ([169.254.13.164]) by BN1PR05MB041.namprd05.prod.outlook.com ([169.254.13.164]) with mapi id 15.00.0745.000; Tue, 27 Aug 2013 17:55:26 +0000 From: Kaliraj Vairavakkalai To: "Simpson, Adam (Adam)" , "ju1738@att.com" , "pmohapat@cisco.com" , "djsmith@cisco.com" , "Henderickx, Wim (Wim)" , "mtexier@arbor.net" Thread-Topic: Flowspec, coexistance of redirect and mirror actions Thread-Index: Ac6hUeKlWmhESTd+R3uwPlXU/S+k1AB94zoAAAEMbiA= Date: Tue, 27 Aug 2013 17:55:25 +0000 Message-ID: <6fda04eda11d46d5ab7885f25131a0f7@BN1PR05MB041.namprd05.prod.outlook.com> References: <1f2e4342dc3c4f15ace416939ed06a02@BLUPR05MB040.namprd05.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.36] x-forefront-prvs: 0951AB0A30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: Jeff Haas , "idr@ietf.org" Subject: Re: [Idr] Flowspec, coexistance of redirect and mirror actions X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 17:55:49 -0000 Yes Adam, the original flow with destination A is steered/moved to new dest= ination B (e.g. scrubber device) while simultaneously copy of this flow sen= t to a new destination C (e.g. for LI)=20 The devices doing the scrubbing and LI may be different (based on devices' = capability, load-balancing requirement etc), was the thought behind my ques= tion.=20 Thanks,=20 Kaliraj=20 > -----Original Message----- > From: Simpson, Adam (Adam) [mailto:adam.simpson@alcatel-lucent.com] > Sent: Tuesday, August 27, 2013 10:19 AM > To: Kaliraj Vairavakkalai; ju1738@att.com; pmohapat@cisco.com; > djsmith@cisco.com; Henderickx, Wim (Wim); mtexier@arbor.net > Cc: Jeff Haas; idr@ietf.org > Subject: Re: Flowspec, coexistance of redirect and mirror actions >=20 > Hi Kaliraj, >=20 > You are correct; these actions are mutually exclusive according to the cu= rrent > encoding. What does it mean for you to have a flow both moved > (redirected) and copied (mirrored)? Do you mean the original flow with > destination A is steered/moved to new destination B while at the same tim= e a > copy of this flow is sent to a new destination C? I personally have not s= een a > requirement for this type of compound action but I will leave the other > authors to comment as well. >=20 > -Adam >=20 >=20 > On 2013-08-25 1:13 AM, "Kaliraj Vairavakkalai" wrot= e: >=20 > >Hi authors, > > > >Ref: http://tools.ietf.org/html/draft-simpson-idr-flowspec-redirect-02 > > > >If it is desired to perform both "redirect-action" to a nexthop X, and > >"mirror-action" to a different nexthop Y simultaneously for the same > >flow, how is it achieved? > > > >It appears the signaling for such a scenario may not be handled by the > >mechanisms specified in this draft, unless I am missing something. > >Could you pls clarify. > > > >Thanks > >Kaliraj > > >=20 >=20 From mpradosh@yahoo.com Tue Aug 27 14:40:33 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6323F11E822F for ; Tue, 27 Aug 2013 14:40:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YNBzJndOMV2k for ; Tue, 27 Aug 2013 14:40:27 -0700 (PDT) Received: from nm42.bullet.mail.ne1.yahoo.com (nm42.bullet.mail.ne1.yahoo.com [98.138.120.49]) by ietfa.amsl.com (Postfix) with ESMTP id 7D39211E8221 for ; Tue, 27 Aug 2013 14:40:27 -0700 (PDT) Received: from [127.0.0.1] by nm42.bullet.mail.ne1.yahoo.com with NNFMP; 27 Aug 2013 21:40:26 -0000 Received: from [98.138.101.132] by nm42.bullet.mail.ne1.yahoo.com with NNFMP; 27 Aug 2013 21:37:26 -0000 Received: from [66.196.81.173] by tm20.bullet.mail.ne1.yahoo.com with NNFMP; 27 Aug 2013 21:37:26 -0000 Received: from [98.139.212.201] by tm19.bullet.mail.bf1.yahoo.com with NNFMP; 27 Aug 2013 21:37:25 -0000 Received: from [127.0.0.1] by omp1010.mail.bf1.yahoo.com with NNFMP; 27 Aug 2013 21:37:25 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 884017.94482.bm@omp1010.mail.bf1.yahoo.com Received: (qmail 10088 invoked by uid 60001); 27 Aug 2013 21:37:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1377639445; bh=FzJMdgb81Hqda6OaXq45BuHU17Ec3eR9cfBf2klaNec=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=dw9rIkI9CHl1xEXB/nB7muIsu9Lx8jvr3b6PgCn4VhSZzuYAPIjDONQ2uHyHaOBOqNZ6Id5lUnMHpHHRGDu8QB62xSnry2vC8QVHqCp3G9BIn7wv2+aADcODd2/oQJySljaewSP1HXLJhg7y8XYgCeZDemnHrlabaU+RhndBQWM= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=JYHTSxyo2q02VQ9RHe2ZOQN0/+K3V3jY5EErXtgQvoqWUW3u+a7QBREd5BxSbuaK+FoWsOrfLhhkKiVmfv0/xecFPylYYBb+Rb8seFhmd4e9JNq8OiVHwv8DmUss6iabt3JzUpepCaVEGxdMpAsp4bW/iYAttWOucyIidQQMsjU=; X-YMail-OSG: fwXLARIVM1mgGERyAffW4zhYqJ2WeJOvLUU0iIdZwvSQD5j 06GVtEe60M62fn2Mi_sBWmvUKU7ygOvgMKi8f0Gnsg7i6HcSycaWGJzgvP4k TRyULectrw4vjTNxnNWn46LaQDRu90V._KtaN3ZfT9zZZ7KNNgqUlkyCBvaw LzipBiQKNxSFe29GzxzSwXi1ogWjcTxJB_tZqzeMNnQjhIe28x74aLqHQlRg U0v0pHt3pkrqdFhJjjSKm0o93EJXtfiFt5KWfNnXwvkt3LuXD2.RM8el0suN jSmePTHQPDV93N8NUlRNJcerS7bGc6V_sCa3FojKgCsAgO5c8Me1Mwe34_QO qjZR9HnNuXldgApvn79rawKC8iFyMUUcb3c26UKsozsFLFw5_ij_NYxYT_ZE .iiZqXasDQxu8hsoU071M5pZcJj9STPwuRZddil7J8TJtE99sin.DOSDb6lM yjwd1Swafc6emBpPZx09bi_UesZBJbdQh.Ax99Zoa6ZxeEka7nLUVkvqBchb A2NzIUm_VS7t6_r4a_WKH0zQucXGSA4Qro2qRhpi6NGjWjl1MxWF9IPMoiy6 XWgObg3pHwmagmT_fAQ-- Received: from [157.22.42.200] by web164906.mail.bf1.yahoo.com via HTTP; Tue, 27 Aug 2013 14:37:25 PDT X-Rocket-MIMEInfo: 002.001, SGkgS2FsaXJhaiwKClN1Z2dlc3QgeW91IHVzZSBhZGQtcGF0aDogc2VuZCB0d28gcGF0aHMgZm9yIHRoZSBmbG93LCBvbmUgd2l0aCBuZXh0LWhvcCBYwqAKYW5kIHJlZGlyZWN0IGFjdGlvbiwgdGhlIG90aGVyIHdpdGggbmV4dC1ob3AgWSBhbmQgbWlycm9yIGFjdGlvbi4KCi0gUHJhZG9zaAoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCiBGcm9tOiBLYWxpcmFqIFZhaXJhdmFra2FsYWkgPGthbGlyYWpAanVuaXBlci5uZXQ.ClRvOiAiU2ltcHNvbiwgQWRhbSAoQWRhbSkiIDxhZGFtLnNpbXABMAEBAQE- X-Mailer: YahooMailWebService/0.8.155.576 References: <1f2e4342dc3c4f15ace416939ed06a02@BLUPR05MB040.namprd05.prod.outlook.com> <6fda04eda11d46d5ab7885f25131a0f7@BN1PR05MB041.namprd05.prod.outlook.com> Message-ID: <1377639445.8844.YahooMailNeo@web164906.mail.bf1.yahoo.com> Date: Tue, 27 Aug 2013 14:37:25 -0700 (PDT) From: Pradosh Mohapatra To: Kaliraj Vairavakkalai , "Simpson, Adam \(Adam\)" , "ju1738@att.com" , "djsmith@cisco.com" , "Henderickx, Wim \(Wim\)" , "mtexier@arbor.net" In-Reply-To: <6fda04eda11d46d5ab7885f25131a0f7@BN1PR05MB041.namprd05.prod.outlook.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-498039042-1801288622-1377639445=:8844" Cc: Jeff Haas , "idr@ietf.org" Subject: Re: [Idr] Flowspec, coexistance of redirect and mirror actions X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Pradosh Mohapatra List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 21:40:33 -0000 ---498039042-1801288622-1377639445=:8844 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi Kaliraj,=0A=0ASuggest you use add-path: send two paths for the flow, one= with next-hop X=A0=0Aand redirect action, the other with next-hop Y and mi= rror action.=0A=0A- Pradosh=0A=0A=0A________________________________=0A Fro= m: Kaliraj Vairavakkalai =0ATo: "Simpson, Adam (Adam)"= ; "ju1738@att.com" ; "pmo= hapat@cisco.com" ; "djsmith@cisco.com" ; "Henderickx, Wim (Wim)" ; "mtexier@= arbor.net" =0ACc: Jeff Haas ; "idr@i= etf.org" =0ASent: Tuesday, August 27, 2013 10:55 AM=0ASubjec= t: Re: [Idr] Flowspec, coexistance of redirect and mirror actions=0A =0A=0A= Yes Adam, the original flow with destination A is steered/moved to new dest= ination B (e.g. scrubber device) while simultaneously copy of this flow sen= t to a new destination C (e.g. for LI) =0A=0AThe devices doing the scrubbin= g and LI may be different (based on devices' capability, load-balancing req= uirement etc), was the thought behind my question. =0A=0AThanks, =0AKaliraj= =0A> -----Original Message-----=0A> From: Simpson, Adam (Adam) [mailto:ada= m.simpson@alcatel-lucent.com]=0A> Sent: Tuesday, August 27, 2013 10:19 AM= =0A> To: Kaliraj Vairavakkalai; ju1738@att.com; pmohapat@cisco.com;=0A> djs= mith@cisco.com; Henderickx, Wim (Wim); mtexier@arbor.net=0A> Cc: Jeff Haas;= idr@ietf.org=0A> Subject: Re: Flowspec, coexistance of redirect and mirror= actions=0A> =0A> Hi Kaliraj,=0A> =0A> You are correct; these actions are m= utually exclusive according to the current=0A> encoding. What does it mean = for you to have a flow both moved=0A> (redirected) and copied (mirrored)? D= o you mean the original flow with=0A> destination A is steered/moved to new= destination B while at the same time a=0A> copy of this flow is sent to a = new destination C? I personally have not seen a=0A> requirement for this ty= pe of compound action but I will leave the other=0A> authors to comment as = well.=0A> =0A> -Adam=0A> =0A> =0A> On 2013-08-25 1:13 AM, "Kaliraj Vairavak= kalai" wrote:=0A> =0A> >Hi authors,=0A> >=0A> >Ref: h= ttp://tools.ietf.org/html/draft-simpson-idr-flowspec-redirect-02=0A> >=0A> = >If it is desired to perform both "redirect-action" to a nexthop X, and=0A>= >"mirror-action" to a different nexthop Y simultaneously for the same=0A> = >flow, how is it achieved?=0A> >=0A> >It appears the signaling for such a s= cenario may not be handled by the=0A> >mechanisms specified in this draft, = unless I am missing something.=0A> >Could you pls clarify.=0A> >=0A> >Thank= s=0A> >Kaliraj=0A> >=0A> =0A> =0A=0A=0A____________________________________= ___________=0AIdr mailing list=0AIdr@ietf.org=0Ahttps://www.ietf.org/mailma= n/listinfo/idr ---498039042-1801288622-1377639445=:8844 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Kaliraj,

Suggest you use add-path: send two paths for t= he flow, one with next-hop X 
and redirect action= , the other with next-hop Y and mirror action.

- P= radosh

From: Kaliraj Vairavakkalai <kaliraj@junipe= r.net>
To: "Simpson= , Adam (Adam)" <adam.simpson@alcatel-lucent.com>; "ju1738@att.com" <ju17= 38@att.com>; "pmohapat@cisco.com" <pmohapat@cisco.com>; "djsmith@c= isco.com" <djsmith@cisco.com>; "Henderickx, Wim (Wim)" <wim.hender= ickx@alcatel-lucent.com>; "mtexier@arbor.net" <mtexier@arbor.net> =
Cc: Jeff Haas <jhaa= s@juniper.net>; "idr@ietf.org" <idr@ietf.org>
Sent: Tuesday, August 27, 2013 10:55 AM<= br> Subject: Re: [Idr] Flo= wspec, coexistance of redirect and mirror actions

Yes Adam, the original flow with destination A= is steered/moved to new destination B (e.g. scrubber device) while simulta= neously copy of this flow sent to a new destination C (e.g. for LI)
The devices doing the scrubbing and LI may be different (based on devices' capability, load-balancing requirement etc), was the thought behind my que= stion.

Thanks,
Kaliraj
> -----Original Message-----
&= gt; From: Simpson, Adam (Adam) [mailto:adam.simp= son@alcatel-lucent.com]
> Sent: Tuesday, August 27, 2013 10:19 AM=
> To: Kaliraj Vairavakkalai; ju1738@att.com; pmohapat@cisco.com;> djsmith@cisco.com; Henderickx, Wim (Wim); mtexier@arbor.net> Cc: Jeff Haas; idr@ietf.org
> Subject: Re: Flowspec, coexistance of re= direct and mirror actions
>
> Hi Kaliraj,
>
> You are correct; the= se actions are mutually exclusive according to the current
> encoding= . What does it mean for you to have a flow both moved
> (redirected) = and copied (mirrored)? Do you mean the original flow with
> destinati= on A is steered/moved to new destination B while at the same time a
>= copy of this flow is sent to a new destination C? I personally have not se= en a
> requirement for this type of compound action but I will leave = the other
> authors to comment as well.
>
> -Adam
>= ;
>
> On 2013-08-25 1:13 AM, "Kaliraj Vairavakkalai" <k= aliraj@juniper.net> wrote:
>
> >Hi authors,
> = >
> >Ref: http://tools.ietf.org/html/draft-simpson-idr-flowspec-re= direct-02
> >
> >If it is desired to perform both "re= direct-action" to a nexthop X, and
> >"mirror-action" to a differe= nt nexthop Y simultaneously for the same
> >flow, how is it achiev= ed?
> >
> >It appears the signaling for such a scenario m= ay not be handled by the
> >mechanisms specified in this draft, un= less I am missing something.
> >Could you pls clarify.
> >= ;
> >Thanks
> >Kaliraj
> >
>
>
=

_______________________________________________
Idr mailing list=
Idr@iet= f.org
https://www.ietf.org/mailman/listinfo/idr


=
---498039042-1801288622-1377639445=:8844-- From rraszuk@gmail.com Wed Aug 28 07:52:18 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73D5211E811F for ; Wed, 28 Aug 2013 07:52:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LqSMpaoXKtds for ; Wed, 28 Aug 2013 07:52:17 -0700 (PDT) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 1697E21F85B2 for ; Wed, 28 Aug 2013 07:52:16 -0700 (PDT) Received: by mail-la0-f45.google.com with SMTP id eh20so4783101lab.4 for ; Wed, 28 Aug 2013 07:52:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=zl65r1IrZUyH2vS5mzf1bCrb0GebaEhvTGUQy+gdKMw=; b=yONkBT8i6mHCaB67LdJNKfayPxpRNTL3m31OWeENNJHP4sJLA8ZOz9qfm0gGx63kpE XZJOKeKm/E/98x+hLeQverIFOeaa3QSbZjhYeewpIb9UViM6yGFYGY3pB1nfUMSjofrE dC4bgcJYliB7TrYdIsc1DzHYBGMZU+k575WquhuPmJsBbPxVIHlBH6hsi0qTyphV27Av juwzn6U/ndjJ64n/MQ+Rczi1LRw7Gy+gdavAC+g6NmmwyxJ5u3iyRt8Gx0ltCDBwUrk3 XjjeGCYQdh3RQt5pK9J9E432a83epNpZPg7tMtKF8HXPxUAWWZegWQIlOd26xCVG/Lm1 tY6A== MIME-Version: 1.0 X-Received: by 10.112.167.3 with SMTP id zk3mr9610221lbb.23.1377701535060; Wed, 28 Aug 2013 07:52:15 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.112.219.1 with HTTP; Wed, 28 Aug 2013 07:52:14 -0700 (PDT) In-Reply-To: <1377639445.8844.YahooMailNeo@web164906.mail.bf1.yahoo.com> References: <1f2e4342dc3c4f15ace416939ed06a02@BLUPR05MB040.namprd05.prod.outlook.com> <6fda04eda11d46d5ab7885f25131a0f7@BN1PR05MB041.namprd05.prod.outlook.com> <1377639445.8844.YahooMailNeo@web164906.mail.bf1.yahoo.com> Date: Wed, 28 Aug 2013 16:52:14 +0200 X-Google-Sender-Auth: VmhlyjZ3v-7V1rj93f9nWeqhRCw Message-ID: From: Robert Raszuk To: Pradosh Mohapatra Content-Type: multipart/alternative; boundary=001a11c264a49a98f804e5032233 Cc: "mtexier@arbor.net" , "idr@ietf.org" , Jeff Haas , "djsmith@cisco.com" , "ju1738@att.com" Subject: Re: [Idr] Flowspec, coexistance of redirect and mirror actions X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 14:52:18 -0000 --001a11c264a49a98f804e5032233 Content-Type: text/plain; charset=ISO-8859-1 Hi Pradosh, 5575 still requires you to run BGP best path selection even if you have multiple paths. This is both for the onward advertisement as well as for the local installation. You are proposing to install more then "best" path locally which may actually require substantial changes to the BGP operation. How do you control which paths are to be installed let's say which 2 out of N ? The multipath checks are not really helpful here. It's an interesting question if we in general agree to install multiple paths in flowspec SAFI for the exact same NLRI ? Regards, R. On Tue, Aug 27, 2013 at 11:37 PM, Pradosh Mohapatra wrote: > Hi Kaliraj, > > Suggest you use add-path: send two paths for the flow, one with next-hop X > and redirect action, the other with next-hop Y and mirror action. > > - Pradosh > > ------------------------------ > *From:* Kaliraj Vairavakkalai > *To:* "Simpson, Adam (Adam)" ; " > ju1738@att.com" ; "pmohapat@cisco.com" ; > "djsmith@cisco.com" ; "Henderickx, Wim (Wim)" < > wim.henderickx@alcatel-lucent.com>; "mtexier@arbor.net" > > *Cc:* Jeff Haas ; "idr@ietf.org" > *Sent:* Tuesday, August 27, 2013 10:55 AM > *Subject:* Re: [Idr] Flowspec, coexistance of redirect and mirror actions > > Yes Adam, the original flow with destination A is steered/moved to new > destination B (e.g. scrubber device) while simultaneously copy of this flow > sent to a new destination C (e.g. for LI) > > The devices doing the scrubbing and LI may be different (based on devices' > capability, load-balancing requirement etc), was the thought behind my > question. > > Thanks, > Kaliraj > > -----Original Message----- > > From: Simpson, Adam (Adam) [mailto:adam.simpson@alcatel-lucent.com] > > Sent: Tuesday, August 27, 2013 10:19 AM > > To: Kaliraj Vairavakkalai; ju1738@att.com; pmohapat@cisco.com; > > djsmith@cisco.com; Henderickx, Wim (Wim); mtexier@arbor.net > > Cc: Jeff Haas; idr@ietf.org > > Subject: Re: Flowspec, coexistance of redirect and mirror actions > > > > Hi Kaliraj, > > > > You are correct; these actions are mutually exclusive according to the > current > > encoding. What does it mean for you to have a flow both moved > > (redirected) and copied (mirrored)? Do you mean the original flow with > > destination A is steered/moved to new destination B while at the same > time a > > copy of this flow is sent to a new destination C? I personally have not > seen a > > requirement for this type of compound action but I will leave the other > > authors to comment as well. > > > > -Adam > > > > > > On 2013-08-25 1:13 AM, "Kaliraj Vairavakkalai" > wrote: > > > > >Hi authors, > > > > > >Ref: http://tools.ietf.org/html/draft-simpson-idr-flowspec-redirect-02 > > > > > >If it is desired to perform both "redirect-action" to a nexthop X, and > > >"mirror-action" to a different nexthop Y simultaneously for the same > > >flow, how is it achieved? > > > > > >It appears the signaling for such a scenario may not be handled by the > > >mechanisms specified in this draft, unless I am missing something. > > >Could you pls clarify. > > > > > >Thanks > > >Kaliraj > > > > > > > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > --001a11c264a49a98f804e5032233 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Pradosh,

5575 still requires you to run BGP best path selection even if you have mul= tiple paths. This is both for the onward advertisement as well as for the l= ocal installation.=A0

You are proposing to install more then "best&q= uot; path locally which may actually require substantial changes to the BGP= operation.=A0

How do you control which paths are to= be installed let's say which 2 out of N ? The multipath checks are not= really helpful here.=A0

It's an interesting question if w= e in general agree to install multiple paths in flowspec SAFI for the exact= same NLRI ?=A0

Regards,
R.








On Tue, Aug 27, 2013 at 11:37 PM, Pradosh Mohapatra &l= t;mpradosh@yahoo.co= m> wrote:
Hi Kaliraj,

Sugg= est you use add-path: send two paths for the flow, one with next-hop X=A0
and redirect action, the other with next-hop Y and mirror a= ction.

- Pradosh

From: Kaliraj Vairav= akkalai <kalira= j@juniper.net>
To: "Simpson, Adam (Adam)" <adam.simpson@alcatel-lucent.com>; "ju1738@att.com" <ju1738@att.com>; "pmohapat@cisco.com= " <pmohapat= @cisco.com>; "djsmith@cisco.com" <djsmith@cisco.com>; "Henderickx, Wim (Wim)&qu= ot; <wim.henderickx@alcatel-lucent.com>; "mtexier@arbor.net" <mtexier@arbor.net>
Cc: Jeff Haas <jhaas@juniper.net>; &qu= ot;idr@ietf.org"= <idr@ietf.org>=
Sent: Tuesday, August 27, 2= 013 10:55 AM
Subject: Re= : [Idr] Flowspec, coexistance of redirect and mirror actions

Yes Adam, the original flow with destinati= on A is steered/moved to new destination B (e.g. scrubber device) while sim= ultaneously copy of this flow sent to a new destination C (e.g. for LI)
The devices doing the scrubbing and LI may be different (based on devic= es' capability, load-balancing requirement etc), was the thought behind my que= stion.

Thanks,
Kaliraj
> -----Original Message-----
&= gt; From: Simpson, Adam (Adam) [mailto:adam.simpson@alcatel-lucent.com]
> Sent: Tuesday, August 27, 2013 10:19 AM
> To: Kaliraj Vairavakka= lai; ju1738@att.com= ; pmohapat@cisco.co= m;
> djsmith@cisco.c= om; Henderickx, Wim (Wim); mtexier@arbor.net
> Cc: Jeff Haas; idr@ietf.org
> Subject: Re: Flowspec, coexistance of redirect and mirror actions
>
> Hi Kaliraj,
>
> You are correct; the= se actions are mutually exclusive according to the current
> encoding= . What does it mean for you to have a flow both moved
> (redirected) = and copied (mirrored)? Do you mean the original flow with
> destination A is steered/moved to new destination B while at the same = time a
> copy of this flow is sent to a new destination C? I personal= ly have not seen a
> requirement for this type of compound action but= I will leave the other
> authors to comment as well.
>
> -Adam
>
> > On 2013-08-25 1:13 AM, "Kaliraj Vairavakkalai" <kaliraj@juniper.net&g= t; wrote:
>
> >Hi authors,
> >
> >Ref: http://tools.ietf.org/html/draft-simpson-idr-flowspec-redirect-02=
> >
> >If it is desired to perform both "redirect-actio= n" to a nexthop X, and
> >"mirror-action" to a diff= erent nexthop Y simultaneously for the same
> >flow, how is it ach= ieved?
> >
> >It appears the signaling for such a scenario may not = be handled by the
> >mechanisms specified in this draft, unless I = am missing something.
> >Could you pls clarify.
> >
> >Thanks
> >Kaliraj
> >
>
>

<= br>_______________________________________________
Idr mailing list
<= a href=3D"mailto:Idr@ietf.org" target=3D"_blank">Idr@ietf.org
https://w= ww.ietf.org/mailman/listinfo/idr



_________________= ______________________________
Idr mailing list
Idr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr


--001a11c264a49a98f804e5032233-- From kaliraj@juniper.net Tue Aug 27 00:23:46 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10A0211E8130 for ; Tue, 27 Aug 2013 00:23:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W7W799cajM9n for ; Tue, 27 Aug 2013 00:23:34 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0188.outbound.messaging.microsoft.com [213.199.154.188]) by ietfa.amsl.com (Postfix) with ESMTP id 99BEF21F9E9A for ; Tue, 27 Aug 2013 00:23:33 -0700 (PDT) Received: from mail13-db8-R.bigfish.com (10.174.8.254) by DB8EHSOBE027.bigfish.com (10.174.4.90) with Microsoft SMTP Server id 14.1.225.22; Tue, 27 Aug 2013 07:23:32 +0000 Received: from mail13-db8 (localhost [127.0.0.1]) by mail13-db8-R.bigfish.com (Postfix) with ESMTP id 47D0D160167; Tue, 27 Aug 2013 07:23:32 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: VPS-24(zz98dI9371I103dK148cIzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz8275ch1de098h1033IL17326ah186068h8275dh1de097hz2fh2a8h839h947hd24hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail13-db8: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=kaliraj@juniper.net; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(199002)(41574002)(24454002)(377454003)(52604005)(189002)(69226001)(74876001)(53806001)(56776001)(76482001)(77096001)(80976001)(4396001)(15202345003)(79102001)(81542001)(74316001)(74502001)(74662001)(47446002)(81342001)(31966008)(54356001)(66066001)(74706001)(54316002)(56816003)(65816001)(77982001)(59766001)(74366001)(51856001)(46102001)(63696002)(47736001)(80022001)(49866001)(50986001)(47976001)(19580405001)(19580395003)(76796001)(81816001)(33646001)(83072001)(76576001)(83322001)(76786001)(81686001)(15975445006)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR05MB153; H:BN1PR05MB041.namprd05.prod.outlook.com; CLIP:66.129.224.53; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail13-db8 (localhost.localdomain [127.0.0.1]) by mail13-db8 (MessageSwitch) id 1377588209784760_5552; Tue, 27 Aug 2013 07:23:29 +0000 (UTC) Received: from DB8EHSMHS013.bigfish.com (unknown [10.174.8.226]) by mail13-db8.bigfish.com (Postfix) with ESMTP id B96A860041; Tue, 27 Aug 2013 07:23:29 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by DB8EHSMHS013.bigfish.com (10.174.4.23) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 27 Aug 2013 07:23:29 +0000 Received: from BN1PR05MB153.namprd05.prod.outlook.com (10.255.205.18) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.347.3; Tue, 27 Aug 2013 07:23:25 +0000 Received: from BN1PR05MB041.namprd05.prod.outlook.com (10.255.202.140) by BN1PR05MB153.namprd05.prod.outlook.com (10.255.205.18) with Microsoft SMTP Server (TLS) id 15.0.745.25; Tue, 27 Aug 2013 07:23:23 +0000 Received: from BN1PR05MB041.namprd05.prod.outlook.com ([169.254.13.164]) by BN1PR05MB041.namprd05.prod.outlook.com ([169.254.13.164]) with mapi id 15.00.0745.000; Tue, 27 Aug 2013 07:23:23 +0000 From: Kaliraj Vairavakkalai To: Dave Mitchell Thread-Topic: [Idr] Flowspec, coexistance of redirect and mirror actions Thread-Index: Ac6hUeKlWmhESTd+R3uwPlXU/S+k1AACugOAAGKm/ZA= Date: Tue, 27 Aug 2013 07:23:22 +0000 Message-ID: References: <1f2e4342dc3c4f15ace416939ed06a02@BLUPR05MB040.namprd05.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.53] x-forefront-prvs: 0951AB0A30 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-Mailman-Approved-At: Wed, 28 Aug 2013 08:33:29 -0700 Cc: "mtexier@arbor.net" , "idr@ietf.org" , Jeff Haas , "djsmith@cisco.com" , "pmohapat@cisco.com" , Danny McPherson , "ju1738@att.com" , "wim.henderickx@alcatel-lucent.be" Subject: Re: [Idr] Flowspec, coexistance of redirect and mirror actions X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 07:23:46 -0000 Hi Dave,=20 Thanks for sharing experience from the field, and confirming that mirroring= and redirect to different NHs can be used simultaneously. Let's wait for t= he authors' input. Btw, I think as-per this draft both redirect and mirroring options can use = a tunneled-nexthop.=20 I don't fully understand/agree your flow-route community-matching requireme= nt, are you suggesting this as a new flowspec-NLRI-format or just a local-s= yntactic-sugar? The prefix-list suggestion is a good syntactic-sugar, but it may not alter = the size of flowspec-RIB/num-filters. Perhaps we can take discussion of the= se points offline, if you agree that these are implementation matter and no= t standards-related. Thanks Kaliraj=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D From: Dave Mitchell [mailto:dave@twitter.com]=20 Sent: Saturday, August 24, 2013 11:32 PM To: Kaliraj Vairavakkalai Cc: ju1738@att.com; pmohapat@cisco.com; djsmith@cisco.com; wim.henderickx@a= lcatel-lucent.be; adam.simpson@alcatel-lucent.com; mtexier@arbor.net; Jeff = Haas; idr@ietf.org; Danny McPherson Subject: Re: [Idr] Flowspec, coexistance of redirect and mirror actions Hello, =A0 I think the above to options (port mirroring vs NH change) are complete= ly different and should be used in different terms based on the actions=20 required within the PFE. Since port-mirroring can sometimes need tunneling = due to an indirect next-hop, using a single community to do both=20 seems less than ideal nor something operators would use often. (just my $0.= 02) I most definitely agree there needs to be a "then next-hop" option in flow-= spec and a "match community" to make things easier, considering these=20 exist in normal BGP NLRI policy statement. I'd also like to see the ability= to take multiple prefixes (prefix-list) in a single statement and have the= m=20 distributed in the FIB accordingly, as opposed to the single src/dest match= options, per flow-route, that currently exist. I also think the inflexibil= ity of differing prefix-length matching between src/dst in flow-spec should be inv= estigated. I've had to work around this issue for years and it's not ideal.= =20 Community example for changing next-hop in flow-spec for a particular dest: route MODIFY_NH_FOO { =A0=A0=A0 match { =A0=A0=A0=A0=A0=A0=A0 community $foobar; =A0=A0=A0 } =A0=A0=A0 then { =A0=A0=A0=A0=A0=A0=A0 next-hop NH_SLASH_32; =A0=A0=A0=A0=A0=A0=A0 accept; =A0=A0=A0 } } =A0 Example of prefix list (src and dst) option that I feel would be useful for= flow-spec in general. If for instance you are trying to deal with nasty source traffic to multiple datacenters on a backbone, the below route curre= ntly has to be $x numbers of datacenters as the dest, potentially bloating the RIB when in all reality, one statement should be able to be di= sseminated into the FIB correctly.=20 route FS_PREFIX_LIST_FOO { =A0=A0=A0 match { =A0=A0=A0=A0=A0=A0=A0 source-prefix-list $foo; =A0=A0=A0=A0=A0=A0=A0 dest-prefix-list $bar; =A0=A0=A0=A0=A0=A0=A0 community $foobar; =A0=A0=A0 } =A0=A0=A0 then { =A0=A0=A0=A0=A0=A0=A0 next-hop NH_SLASH_32; =A0=A0=A0=A0=A0=A0=A0 accept; =A0=A0=A0 } } Thanks! -dave On Sat, Aug 24, 2013 at 10:13 PM, Kaliraj Vairavakkalai wrote: Hi authors, Ref: http://tools.ietf.org/html/draft-simpson-idr-flowspec-redirect-02 If it is desired to perform both "redirect-action" to a nexthop X, and "mir= ror-action" to a different nexthop Y simultaneously for the same flow, how = is it achieved? It appears the signaling for such a scenario may not be handled by the mech= anisms specified in this draft, unless I am missing something. Could you pl= s clarify. Thanks Kaliraj _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From internet-drafts@ietf.org Thu Aug 29 05:12:59 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0875221F9FB6; Thu, 29 Aug 2013 05:12:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.546 X-Spam-Level: X-Spam-Status: No, score=-102.546 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id utymVYk6nIYR; Thu, 29 Aug 2013 05:12:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A89321F9EFE; Thu, 29 Aug 2013 05:12:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130829121258.7189.28090.idtracker@ietfa.amsl.com> Date: Thu, 29 Aug 2013 05:12:58 -0700 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-ix-bgp-route-server-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2013 12:12:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Inter-Domain Routing Working Group of the= IETF. Title : Internet Exchange Route Server Author(s) : Elisa Jasinska Nick Hilliard Robert Raszuk Niels Bakker Filename : draft-ietf-idr-ix-bgp-route-server-03.txt Pages : 10 Date : 2013-08-29 Abstract: This document outlines a specification for multilateral interconnections at Internet exchange points (IXPs). Multilateral interconnection is a method of exchanging routing information between three or more exterior BGP speakers using a single intermediate broker system, referred to as a route server. Route servers are typically used on shared access media networks, such as Internet exchange points (IXPs), to facilitate simplified interconnection between multiple Internet routers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-ix-bgp-route-server There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-ix-bgp-route-server-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-ix-bgp-route-server-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From shares@ndzh.com Thu Aug 29 07:59:59 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02A3511E8122 for ; Thu, 29 Aug 2013 07:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.263 X-Spam-Level: X-Spam-Status: No, score=0.263 tagged_above=-999 required=5 tests=[AWL=-0.739, BAYES_50=0.001, DOS_OUTLOOK_TO_MX=1, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WmLEJ3SiPRQl for ; Thu, 29 Aug 2013 07:59:51 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id AD7DA11E811D for ; Thu, 29 Aug 2013 07:59:38 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.160.99; From: "Susan Hares" To: "idr wg" Date: Thu, 29 Aug 2013 10:59:30 -0400 Message-ID: <015501cea4c8$5e418610$1ac49230$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0156_01CEA4A6.D730D070" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac6kyD5NB4GK9LcnREi6si00auGmAg== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Subject: [Idr] mail lost to IETF mail list X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2013 14:59:59 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0156_01CEA4A6.D730D070 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Just in case any of you send in mail to idr@ietf.org - Mail was lost yesterday to all mail lists between 15:30 and 20:55 Pacific Time yesterday. Sue Hares ------=_NextPart_000_0156_01CEA4A6.D730D070 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Just in = case any of you send in mail to idr@ietf.org -  Mail was lost = yesterday to all mail lists between 15:30 and 20:55 Pacific Time = yesterday.

 

Sue Hares

------=_NextPart_000_0156_01CEA4A6.D730D070-- From jgs@juniper.net Thu Aug 29 09:09:10 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0884621F8887 for ; Thu, 29 Aug 2013 09:09:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[AWL=-0.249, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rZHiqT+4SuPL for ; Thu, 29 Aug 2013 09:08:32 -0700 (PDT) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0248.outbound.messaging.microsoft.com [213.199.154.248]) by ietfa.amsl.com (Postfix) with ESMTP id 8422B21F8846 for ; Thu, 29 Aug 2013 09:06:04 -0700 (PDT) Received: from mail44-db9-R.bigfish.com (10.174.16.235) by DB9EHSOBE003.bigfish.com (10.174.14.66) with Microsoft SMTP Server id 14.1.225.22; Thu, 29 Aug 2013 16:05:48 +0000 Received: from mail44-db9 (localhost [127.0.0.1]) by mail44-db9-R.bigfish.com (Postfix) with ESMTP id 188B71002D8 for ; Thu, 29 Aug 2013 16:05:48 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT005.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -21 X-BigFish: VPS-21(zf7Iz9371I1b0bI1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6h1082kzz1de098h1033IL8275dh1de097hz2fh2a8h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah139eh13b6h1441h14ddh1504h1537h162dh1631h1662h1758h1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h1fe8h1ff5h2052h1155h) Received-SPF: pass (mail44-db9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jgs@juniper.net; helo=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(377454003)(2473001)(51704005)(69234005)(199002)(189002)(65816001)(80022001)(66066001)(51856001)(53416003)(23726002)(46102001)(62966002)(36756003)(33656001)(74366001)(81816001)(74706001)(81686001)(83072001)(80976001)(76786001)(82746002)(50466002)(74876001)(76796001)(54316002)(46406003)(47776003)(69226001)(59766001)(77982001)(79102001)(56776001)(57306001)(42186004)(53806001)(74502001)(31966008)(63696002)(47446002)(74662001)(4396001)(50226001)(56816003)(77096001)(47736001)(49866001)(81542001)(81342001)(76482001)(47976001)(77156001)(50986001)(19580395003)(83322001)(19580405001)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB120; H:jgs-sslvpn-nc.jnpr.net; CLIP:66.129.232.2; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail44-db9 (localhost.localdomain [127.0.0.1]) by mail44-db9 (MessageSwitch) id 1377792346195691_17880; Thu, 29 Aug 2013 16:05:46 +0000 (UTC) Received: from DB9EHSMHS017.bigfish.com (unknown [10.174.16.235]) by mail44-db9.bigfish.com (Postfix) with ESMTP id 2CA3D60048 for ; Thu, 29 Aug 2013 16:05:46 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by DB9EHSMHS017.bigfish.com (10.174.14.27) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 29 Aug 2013 16:05:45 +0000 Received: from BLUPR05MB120.namprd05.prod.outlook.com (10.255.214.28) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.353.4; Thu, 29 Aug 2013 16:05:44 +0000 Received: from jgs-sslvpn-nc.jnpr.net (66.129.232.2) by BLUPR05MB120.namprd05.prod.outlook.com (10.255.214.28) with Microsoft SMTP Server (TLS) id 15.0.745.25; Thu, 29 Aug 2013 16:05:44 +0000 From: "John G. Scudder" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Date: Thu, 29 Aug 2013 12:05:40 -0400 References: <074601cea4c6$8189ba90$849d2fb0$@olddog.co.uk> To: "idr@ietf. org" Message-ID: <7CBCBA22-2D00-432E-A1C7-7F63E0BA3FE8@juniper.net> MIME-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) X-Originating-IP: [66.129.232.2] X-ClientProxiedBy: BN1PR06CA015.namprd06.prod.outlook.com (10.141.56.35) To BLUPR05MB120.namprd05.prod.outlook.com (10.255.214.28) X-Forefront-PRVS: 09538D3531 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: [Idr] Fwd: Mail lost yesterday X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2013 16:09:11 -0000 FYI. --John Begin forwarded message: > From: Adrian Farrel > Subject: FW: Mail lost yesterday > Date: August 29, 2013 10:46:09 AM EDT > To: > > For those of you who haven't noticed the message from Steve Young in > your In box, mail to all IETF lists between 15:30 and and 20:55 Pacific > Time yesterday seems to have been lost. Aside from needing to re-send > all mail you personally sent during that time period, you also need to > inform your working groups.