Gunter,

=E2=80=8BSee inlin= e ...=E2=80=8B

1) assumed is that g= lobal labels are used, however it is=20 nowhere mentioned explicitely in the draft

=E2=80=8BSince there is no formal definition of "global label= "=E2=80=8B in any IETF RFC such statement can not be added as normativ= e to the new specification. Sorry.

2) with global labels come applicability area being on= ly=20 SPRING based networks, please add this to the technology usability=20 section

=E2=80=8BThat is incorrect = technically. The draft is equally applicable to basic L3VPNs to match on VP= N label either as second in the stack or first (case of Inter-as option B a= t ASBRs).=C2=A0

The dr= aft already provides text on the above applicability in section 1.

=C2=A0

3) Traditional best path selection is used to find best NLRI= ,=20 however a different to IGP label is pushed ... The draft does not describe= =20 measures to guaranty that the pushed label represents the same destination= =20 node.

=C2=A0

=E2=80=8BSor= ry but this extension does not distribute labels to be pushed on the packet= s as the IGP or bottom label on the stack. =E2=80=8BIt does however provide= means to apply demux label for application layer (the example in the draft= is EPE). I personnaly see nothing wrong with such approach.

4) why is this solution bett= er as using traditional flowspec=20 redirect to VRF (with exact one route in VRF)? In this case telemetry for= =20 flowspec redirect can be done with existing technology ... Nothing new is= =20 required...

=E2=80=8BThat's comparing apples to oranges ... =E2=80=8BThe vrf = redirection is a local action. Imagine that packets have been redirected to= local vrf. Now within such local VRF you have entered static route to send= packets say to some collector or exit ASBR.=C2=A0

But if you would like to further add a demux v= alue which such collector or exit ASBR would use to switch packets to prope= r context this is where this extension can be used.=C2=A0

=E2=80=8BBest,

R.=E2=80=8B

<= /div>

Understanding the above considerationd i do not feel the=20 current draft is ready for adoption.

Ciao,,
G/

Sent using CloudMagic=20 Email
On Tue, Dec=20 01, 2015 at 11:16 AM, Wesley Eddy <wes@mti-systems.com>=20 wrote:

=20 =20 =20 =20 On 11/24/2015 6:29 AM, Susan Hares wrote:

=20 =20 =20

This begins a 2 week adoption call for draft-liang-idr-bgp-flowspec-label-01.txt which can be found at:

http://datatracker.i= etf.org/doc/draft-liang-idr-bgp-flowspec-label/

I agree with other comments that this is a useful extension.

It would be good in the draft to clarify the assumptions about global (or at least mutual) significance of the labels, but this is more about clearly describing its use and operation than any impact to the protocol spec.

=20

________________________________________= _______
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

--047d7b15b1177a173e0525d2b3b6-- From nobody Tue Dec 1 01:23:19 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 331251B39BB; Tue, 1 Dec 2015 01:23:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7bU80Q-jpLPH; Tue, 1 Dec 2015 01:23:15 -0800 (PST) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 087721B39BA; Tue, 1 Dec 2015 01:23:15 -0800 (PST) Received: by ioir85 with SMTP id r85so2886390ioi.1; Tue, 01 Dec 2015 01:23:10 -0800 (PST) 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=r7hnps9zwXH7IS+yXnsAQFSZHlL4x+nuDHYssgg3fPs=; b=QKpOf+LVDFu0N7aEOVL4WJYBmP0mmvSIKkLag3yETU70YzhXypJn5LS6vXM+XYyjJZ YbzL9QkYKGuT+fRMnkaALPSfXeeZ7XwUqJc8xhI7gjLcMp0mvp1Icz8xuAavwPfp7z69 b6C0vgqmqZar94tPxclmXnWdS/Ts2rkI2VQ8GQjDOTZkd8KGDD6u22MzBcm9SDxtNfAw QP7xYl8OtzGVjY5W06a+ekDgu0RjAIQshw2sK63DrFYgoaREayI1ugbJUmcVOzNe/jpo eKS+anC9ZPuhN1YIzbxGJ6AHgMu0LT3ZSR4w81vOgoC3rVVpNFog+aCmp667xBCARsPW LUNA== MIME-Version: 1.0 X-Received: by 10.107.134.166 with SMTP id q38mr63347497ioi.25.1448961790543; Tue, 01 Dec 2015 01:23:10 -0800 (PST) Sender: rraszuk@gmail.com Received: by 10.36.58.78 with HTTP; Tue, 1 Dec 2015 01:23:10 -0800 (PST) In-Reply-To: <056c01d126ab$61421980$23c64c80$@ndzh.com> References: <056c01d126ab$61421980$23c64c80$@ndzh.com> Date: Tue, 1 Dec 2015 10:23:10 +0100 X-Google-Sender-Auth: IihZbzrK8vweIYYDGGAekt3iJhI Message-ID: From: Robert Raszuk To: Susan Hares Content-Type: multipart/alternative; boundary=001a113f9c88d18dc00525d2b4cf Archived-At: Cc: idr wg , draft-liang-idr-bgp-flowspec-label@ietf.org Subject: Re: [Idr] WG Call for adoption on draft-liang-idr-bgp-flowspec-label-01 (11/24 to 12/8) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 09:23:16 -0000 --001a113f9c88d18dc00525d2b4cf Content-Type: text/plain; charset=UTF-8 Support. Not aware about any IPR. Thx, r. On Tue, Nov 24, 2015 at 12:29 PM, Susan Hares wrote: > This begins a 2 week adoption call for > draft-liang-idr-bgp-flowspec-label-01.txt which can be found at: > > > > http://datatracker.ietf.org/doc/draft-liang-idr-bgp-flowspec-label/ > > > > All authors should respond to this email whether the know of any IPR > relating to this draft. Please note that unless all authors respond to > this email, the draft cannot be adopted as a WG draft. > > > > This draft is part of the flow specification drafts considered at IETF 94, > and on the mail list. Out of that discussion, an inter-working draft will > be create between the flow specification drafts. If you are interested in > this draft, but would like to see the inter-working draft, please indicate > this in your comment. > > > > Sue Hares > > > > --001a113f9c88d18dc00525d2b4cf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Support. Not aware about any IPR.=C2=A0=

Thx,

On Tue, Nov 24, 2015 at 12:29 PM, Susan Hares <<= a href=3D"mailto:shares@ndzh.com" target=3D"_blank">shares@ndzh.com>= wrote:

This begins a 2 week= adoption call for draft-liang-idr-bgp-flowspec-label-01.txt=C2=A0 which ca= n be found at:
=C2=A0
http://datatracker.ietf.= org/doc/draft-liang-idr-bgp-flowspec-label/
=C2=A0
All authors s= hould respond to this email whether the know of any IPR relating to this dr= aft.=C2=A0 =C2=A0Please note that unless all authors respond to this email,= the draft cannot be adopted as a WG draft. =C2=A0
=C2=A0
This draft i= s part of the flow specification drafts considered at IETF 94, and on the m= ail list.=C2=A0 Out of that discussion, an inter-working draft will be crea= te between the flow specification drafts.=C2=A0=C2=A0 If you are interested= in this draft, but would like to see the inter-working draft, please indic= ate this in your comment.
= =C2=A0
Sue Hares
=C2=A0
<= /u>

--001a113f9c88d18dc00525d2b4cf-- From nobody Tue Dec 1 01:46:24 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B9171B3A03 for ; Tue, 1 Dec 2015 01:46:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LvnpDvcYDXfI for ; Tue, 1 Dec 2015 01:46:20 -0800 (PST) Received: from st13p11im-asmtp004.me.com (st13p11im-asmtp004.me.com [17.164.40.219]) (using TLSv1.2 with cipher DHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BBB11B3A02 for ; Tue, 1 Dec 2015 01:46:20 -0800 (PST) Received: from [10.186.163.86] (unknown [203.116.99.164]) by st13p11im-asmtp004.me.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Mar 31 2015)) with ESMTPSA id <0NYO00KUHB4H1R10@st13p11im-asmtp004.me.com> for idr@ietf.org; Tue, 01 Dec 2015 09:45:58 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2015-12-01_03:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=0 kscore.compositescore=1 compositescore=0.9 suspectscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0 spamscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1510090000 definitions=main-1512010162 Content-type: multipart/alternative; boundary="Apple-Mail=_E875E64F-D1DE-4B0C-B4AF-0AE60BED8E10" MIME-version: 1.0 (Mac OS X Mail 9.1 $3096.5$) From: Gunter Van De Velde In-reply-to: Date: Tue, 01 Dec 2015 17:45:52 +0800 Message-id: <07FD3721-CBAC-4EA8-8651-8DB0EE037F76@icloud.com> References: <056c01d126ab$61421980$23c64c80$@ndzh.com> <565D1005.2090603@mti-systems.com> <1448944019080-c58149c9-7bb3859e-57355fa2@icloud.com> To: Robert Raszuk X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: idr wg Subject: Re: [Idr] WG Call for adoption on draft-liang-idr-bgp-flowspec-label-01 (11/24 to 12/8) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 09:46:23 -0000 --Apple-Mail=_E875E64F-D1DE-4B0C-B4AF-0AE60BED8E10 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Well=E2=80=A6. > On 01 Dec 2015, at 17:22, Robert Raszuk wrote: >=20 > Gunter, >=20 > =E2=80=8BSee inline ...=E2=80=8B >=20 > 1) assumed is that global labels are used, however it is nowhere = mentioned explicitely in the draft >=20 > =E2=80=8BSince there is no formal definition of "global label"=E2=80=8B = in any IETF RFC such statement can not be added as normative to the new = specification. Sorry. >=20 GV> Really =E2=80=A6 what about this section in = http://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing/ 3.2. IGP-Prefix Segment, Prefix-SID An IGP-Prefix Segment is an IGP segment attached to an IGP prefix. An IGP-Prefix Segment is global (unless explicitly advertised otherwise) within the SR/IGP domain. The required IGP protocol extensions are defined in IGP SR extensions documents. > 2) with global labels come applicability area being only SPRING based = networks, please add this to the technology usability section >=20 > =E2=80=8BThat is incorrect technically. The draft is equally = applicable to basic L3VPNs to match on VPN label either as second in the = stack or first (case of Inter-as option B at ASBRs).=20 >=20 > The draft already provides text on the above applicability in section = 1. GV> Yes indeed using the service label gives you telemetry capability. = Hence why not simply use the RT trigger to push a label by flowspec. The = description on how this would work is unclear and confusing. It is the trigger for a lot of misunderstandings (where are the labels = coming form, how is the stitching happening, how to check if the label = pushed is going to the original destination , etc=E2=80=A6) . It is to = me totally with the current write-up. > =20 > 3) Traditional best path selection is used to find best NLRI, however = a different to IGP label is pushed ... The draft does not describe = measures to guaranty that the pushed label represents the same = destination node. >=20 > =20 > =E2=80=8BSorry but this extension does not distribute labels to be = pushed on the packets as the IGP or bottom label on the stack. =E2=80=8BIt= does however provide means to apply demux label for application layer = (the example in the draft is EPE). I personnaly see nothing wrong with = such approach. >=20 GV> again, why not use a VPN service label to achieve this? its the same = result if each RT is unique and is announce by the correct egress = device=E2=80=A6 nothing new is needed when using this > 4) why is this solution better as using traditional flowspec redirect = to VRF (with exact one route in VRF)? In this case telemetry for = flowspec redirect can be done with existing technology ... Nothing new = is required... >=20 >=20 > =E2=80=8BThat's comparing apples to oranges ... =E2=80=8BThe vrf = redirection is a local action. Imagine that packets have been redirected = to local vrf. Now within such local VRF you have entered static route to = send packets say to some collector or exit ASBR.=20 >=20 GV> It is not comparing apples with oranges. Redirection is local = action, however technically the label pushed can be a service label = which can be used for telemetry. This service label is announced by the = remote egress device by attaching the RT for each particular telemetry = instance =E2=80=A6 in that case you have the IGP label + flow telemetry = service label. The service label can be used for telemetry=E2=80=A6 It = is even better as in this case it is 100% certain that the flow ends up = at the right router and has the right label attached to avoid looping = etc=E2=80=A6 Ciao, G/ > But if you would like to further add a demux value which such = collector or exit ASBR would use to switch packets to proper context = this is where this extension can be used.=20 >=20 > =E2=80=8BBest, > R.=E2=80=8B >=20 >=20 > Understanding the above considerationd i do not feel the current draft = is ready for adoption. >=20 > Ciao,, > G/ >=20 >=20 >=20 > Sent using CloudMagic Email = > On Tue, Dec 01, 2015 at 11:16 AM, Wesley Eddy > wrote: >=20 > On 11/24/2015 6:29 AM, Susan Hares wrote: > This begins a 2 week adoption call for = draft-liang-idr-bgp-flowspec-label-01.txt which can be found at: >=20 >=20 > http://datatracker.ietf.org/doc/draft-liang-idr-bgp-flowspec-label/ = >=20 >=20 >=20 >=20 > I agree with other comments that this is a useful extension. >=20 > It would be good in the draft to clarify the assumptions about global = (or at least mutual) significance of the labels, but this is more about = clearly describing its use and operation than any impact to the protocol = spec. >=20 >=20 >=20 >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr = >=20 >=20 --Apple-Mail=_E875E64F-D1DE-4B0C-B4AF-0AE60BED8E10 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Well=E2=80=A6.

On 01 Dec 2015, at 17:22, Robert Raszuk <robert@raszuk.net> = wrote:

Gunter,

=E2=80=8B= See inline ...=E2=80=8B

1) assumed is that = global labels are used, however it is=20 nowhere mentioned explicitely in the draft
=E2=80=8B= Since there is no formal definition of "global label"=E2=80=8B in any = IETF RFC such statement can not be added as normative to the new = specification. Sorry.

GV> Really =E2=80=A6 = what about this section in http://datatracker.ietf.org/doc/draft-ietf-spring-segment-routi= ng/

3.2.  =
IGP-Prefix Segment, Prefix-SID

   An IGP-Prefix Segment is an IGP segment attached to an IGP prefix.
   An IGP-Prefix Segment is global (unless explicitly advertised
   otherwise) within the SR/IGP domain.

   The required IGP protocol extensions are defined in IGP SR extensions
   documents.

2) with global labels come applicability area being only=20 SPRING based networks, please add this to the technology usability=20 section
=E2=80=8B= That is incorrect technically. The draft is equally applicable to basic = L3VPNs to match on VPN label either as second in the stack or first = (case of Inter-as option B at ASBRs).

The = draft already provides text on the above applicability in section = 1.

GV> Yes indeed using the service label gives = you telemetry capability. Hence why not simply use the RT trigger to = push a label by flowspec. The description on how this would work is = unclear and confusing.

It is the trigger for a lot of = misunderstandings (where are the labels coming form, how is the = stitching happening, how to check if the label pushed is going to the = original destination , etc=E2=80=A6) . It is to me totally with the = current write-up.

3) Traditional best path selection is used to find best NLRI,=20= however a different to IGP label is pushed ... The draft does not = describe=20 measures to guaranty that the pushed label represents the same = destination=20 node.

=E2=80=8B= Sorry but this extension does not distribute labels to be pushed on the = packets as the IGP or bottom label on the stack. =E2=80=8BIt does = however provide means to apply demux label for application layer (the = example in the draft is EPE). I personnaly see nothing wrong with such = approach.

GV> again, why not use a VPN service label to = achieve this? its the same result if each RT is unique and is announce = by the correct egress device=E2=80=A6 nothing new is needed when using = this

4) why is this solution better as using traditional flowspec=20= redirect to VRF (with exact one route in VRF)? In this case telemetry = for=20 flowspec redirect can be done with existing technology ... Nothing new = is=20 required...

=E2=80=8B= That's comparing apples to oranges ... =E2=80=8BThe vrf redirection is a = local action. Imagine that packets have been redirected to local vrf. = Now within such local VRF you have entered static route to send packets = say to some collector or exit ASBR.

GV> It is not comparing apples with oranges. = Redirection is local action, however technically the label pushed can be = a service label which can be used for telemetry. This service label is = announced by the remote egress device by attaching the RT for each = particular telemetry instance =E2=80=A6 in that case you have the IGP = label + flow telemetry service label. The service label can be used for = telemetry=E2=80=A6 It is even better as in this case it is 100% certain = that the flow ends up at the right router and has the right label = attached to avoid looping etc=E2=80=A6

Ciao,

But if = you would like to further add a demux value which such collector or exit = ASBR would use to switch packets to proper context this is where this = extension can be used.

=E2=80=8BBest,
R.=E2=80=8B=

Understanding the above considerationd i do not feel the=20 current draft is ready for adoption.
Ciao,,
G/

Sent using CloudMagic=20= Email
On Tue, Dec=20 01, 2015 at 11:16 AM, Wesley Eddy <wes@mti-systems.com>=20 wrote:

=20 =20 =20 =20 On 11/24/2015 6:29 AM, Susan Hares wrote:

=20 =20 =20
This begins a 2 week = adoption call for draft-liang-idr-bgp-flowspec-label-01.txt which can be found at:

http://datatracker.ietf.org/doc/draft-liang-idr-bgp-flowspec-la= bel/

=

I agree with other comments that this is a useful extension.

It would be good in the draft to clarify the assumptions about global (or at least mutual) significance of the labels, but this is more about clearly describing its use and operation than any impact to the protocol spec.

=20

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

= --Apple-Mail=_E875E64F-D1DE-4B0C-B4AF-0AE60BED8E10-- From nobody Tue Dec 1 01:51:38 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A2661B3A12; Tue, 1 Dec 2015 01:51:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GurHFp22sTG5; Tue, 1 Dec 2015 01:51:34 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27E7B1B2D44; Tue, 1 Dec 2015 01:51:33 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CBA74214; Tue, 01 Dec 2015 09:51:30 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 1 Dec 2015 09:51:29 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.64]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Tue, 1 Dec 2015 17:51:25 +0800 From: Xuxiaohu To: Susan Hares , "idr@ietf.org" Thread-Topic: [Idr] WG Call for adoption on draft-liang-idr-bgp-flowspec-label-01 (11/24 to 12/8) Thread-Index: AdEmqozrKWUgt33uRi+lznC9GoulVwFcx6PA Date: Tue, 1 Dec 2015 09:51:25 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0CB53286@NKGEML512-MBS.china.huawei.com> References: <056c01d126ab$61421980$23c64c80$@ndzh.com> In-Reply-To: <056c01d126ab$61421980$23c64c80$@ndzh.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.55] Content-Type: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0CB53286NKGEML512MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.565D6DA2.0162, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.8.64, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: b370e970bf8326ffa543116ceac433aa Archived-At: Cc: "draft-liang-idr-bgp-flowspec-label@ietf.org" Subject: Re: [Idr] WG Call for adoption on draft-liang-idr-bgp-flowspec-label-01 (11/24 to 12/8) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 09:51:36 -0000 --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0CB53286NKGEML512MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support the adoption of this draft. Xiaohu From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Tuesday, November 24, 2015 7:29 PM To: idr@ietf.org Cc: draft-liang-idr-bgp-flowspec-label@ietf.org Subject: [Idr] WG Call for adoption on draft-liang-idr-bgp-flowspec-label-0= 1 (11/24 to 12/8) This begins a 2 week adoption call for draft-liang-idr-bgp-flowspec-label-0= 1.txt which can be found at: http://datatracker.ietf.org/doc/draft-liang-idr-bgp-flowspec-label/ All authors should respond to this email whether the know of any IPR relati= ng to this draft. Please note that unless all authors respond to this ema= il, the draft cannot be adopted as a WG draft. This draft is part of the flow specification drafts considered at IETF 94, = and on the mail list. Out of that discussion, an inter-working draft will = be create between the flow specification drafts. If you are interested in= this draft, but would like to see the inter-working draft, please indicate= this in your comment. Sue Hares --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0CB53286NKGEML512MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support the adoption of this draft.

Xiaohu

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Tuesday, November 24, 2015 7:29 PM
To: idr@ietf.org
Cc: draft-liang-idr-bgp-flowspec-label@ietf.org
Subject: [Idr] WG Call for adoption on draft-liang-idr-bgp-flowspec-= label-01 (11/24 to 12/8)

This begins a 2 week adoption c= all for draft-liang-idr-bgp-flowspec-label-01.txt which can be found = at:

http://datatracker.ietf.or= g/doc/draft-liang-idr-bgp-flowspec-label/

All authors should respond to t= his email whether the know of any IPR relating to this draft. P= lease note that unless all authors respond to this email, the draft cannot = be adopted as a WG draft.

This draft is part of the flow = specification drafts considered at IETF 94, and on the mail list. Out= of that discussion, an inter-working draft will be create between the flow= specification drafts. If you are interested in this draft, but would like to see the inter-working draft, please indic= ate this in your comment.

Sue Hares

--_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0CB53286NKGEML512MBSchi_-- From nobody Tue Dec 1 02:20:05 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C535A1B3A83 for ; Tue, 1 Dec 2015 02:20:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yZqtaH7MuLn9 for ; Tue, 1 Dec 2015 02:20:02 -0800 (PST) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 025DC1B3A64 for ; Tue, 1 Dec 2015 02:20:02 -0800 (PST) Received: by igvg19 with SMTP id g19so90942409igv.1 for ; Tue, 01 Dec 2015 02:20:01 -0800 (PST) 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=+e7GET8tDMTG4h2D/Af1/RshgH6EZsIOItkGAhRlidM=; b=sCe9OHgcgm+6y2aNGhK+0YQ0VlbcAZM7PuDvYzG4nn5SK0NBbq8c3dJlJ8tv/NrIOv QXLaJGWDQGICoaTKZ3ldQHGSTjNG9bFQY/FxFwm/mOew7nhe+uhti2HKEoPwjCSLgxEU +4QI1/tRCYkTK89Xy52Fs+AfVbIB2FwatujKw9GtQTRjp/ilcfYPNWv4+oAO/6Uhsd1n JADGdRjpiDBYHOZri/I83559gYy02zX+INMeD9o1w41XFejElkwC/4EnuP1U8wp2pm2V 3O09WuwxahaTgJ5lvAv++MM9LfufNX3uBGX+dsTPoEDEkFO7XG+7v5WrP5ZCukYnaLIB xwaA== MIME-Version: 1.0 X-Received: by 10.50.182.7 with SMTP id ea7mr26179654igc.2.1448965201277; Tue, 01 Dec 2015 02:20:01 -0800 (PST) Sender: rraszuk@gmail.com Received: by 10.36.58.78 with HTTP; Tue, 1 Dec 2015 02:20:01 -0800 (PST) In-Reply-To: <07FD3721-CBAC-4EA8-8651-8DB0EE037F76@icloud.com> References: <056c01d126ab$61421980$23c64c80$@ndzh.com> <565D1005.2090603@mti-systems.com> <1448944019080-c58149c9-7bb3859e-57355fa2@icloud.com> <07FD3721-CBAC-4EA8-8651-8DB0EE037F76@icloud.com> Date: Tue, 1 Dec 2015 11:20:01 +0100 X-Google-Sender-Auth: C-Wf3LhA81kEk-lWPlZu5vpe2AQ Message-ID: From: Robert Raszuk To: Gunter Van De Velde Content-Type: multipart/alternative; boundary=001a1136b07a1d3a630525d38033 Archived-At: Cc: idr wg Subject: Re: [Idr] WG Call for adoption on draft-liang-idr-bgp-flowspec-label-01 (11/24 to 12/8) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 10:20:04 -0000 --001a1136b07a1d3a630525d38033 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > > GV> Really =E2=80=A6 what about this section in > http://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing/ > =E2=80=8BWhat you are quoting is a reference to IGP-Prefix Segment =E2=80= =8Bwhich is global .... it is not reference to mpls "global label" =E2=80=8BBesides this is SPRING draft not an MPLS=E2=80=8B WG RFC. GV> Yes indeed using the service label gives you telemetry capability. > Hence why not simply use the RT trigger to push a label by flowspec. The > description on how this would work is unclear and confusing. > =E2=80=8BBut who is saying that RT would not be used for import. RFC5575 is explicit in stating that Route Target extended community can be attached to FlowSpec routes for import. =E2=80=8B =E2=80=8B Propagation of this NLRI is controlled by matching Route Target extended communities associated with the BGP path advertisement with the VRF import policy, using the same mechanism as described in "BGP/ MPLS IP VPNs" [RFC4364 ] .=E2=80= =8B =E2=80=8BThis spec is just adding new information which can be used after i= mporting to a VRF. =E2=80=8B GV> again, why not use a VPN service label to achieve this? its the same > result if each RT is unique and is announce by the correct egress device= =E2=80=A6 > nothing new is needed when using this > =E2=80=8BYou are mixing things I am afraid. "VPN service" is used to distri= bute reachability. FlowSpec is used to distribute a set of defined filters for such reachability. Q: How do you encode match on port number in SAFI 128 ? GV> It is not comparing apples with oranges. Redirection is local action, > however technically the label pushed can be a service label which can be > used for telemetry. This service label is announced by the remote egress > device by attaching the RT for each particular telemetry instance =E2=80= =A6 in that > case you have the IGP label + flow telemetry service label. The service > label can be used for telemetry=E2=80=A6 It is even better as in this cas= e it is > 100% certain that the flow ends up at the right router and has the right > label attached to avoid looping etc=E2=80=A6 > =E2=80=8BSame comments as above :) Cheers, R. --001a1136b07a1d3a630525d38033 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

GV> Really = =E2=80=A6 what about this section in=C2=A0http://data= tracker.ietf.org/doc/draft-ietf-spring-segment-routing/

=E2=80= =8BWhat you are quoting is a reference to IGP-Prefix Segment =E2=80=8Bwhich= is global .... it is not reference to mpls "global label"

<= br>

=E2=80=8BBesides this is SPRING draft not = an MPLS=E2=80=8B WG RFC.

GV>= ; Yes indeed using the service label gives you telemetry capability. Hence = why not simply use the RT trigger to push a label by flowspec. The descript= ion on how this would work is unclear and confusing.

= =E2=80=8BBut who is saying that RT would not be used for import. RFC5575 is= explicit in stating that Route Target extended community can be attached t= o FlowSpec routes for import.=C2=A0

=E2=80=8B      =E2=80=8B<=
/div>Propagation of this NLRI is controlled by matching Route Target
   extended communities associated with the BGP path advertisement with
   the VRF import policy, using the same mechanism as described in "BG=
P/=C2=A0

=C2=A0 =C2=A0 =C2=A0 MPLS IP VPNs&q= uot; [RFC4364] .=E2=80=8B

= =E2=80=8BThis spec is just adding new information which can be used after i= mporting to a VRF. =E2=80=8B

GV> again, why= not use a VPN service label to achieve this? its the same result if each R= T is unique and is announce by the correct egress device=E2=80=A6 nothing n= ew is needed when using this

=E2=80=8BYou are mixing things I am afraid. "VPN serv= ice" is used to distribute reachability. FlowSpec is used to distribut= e a set of defined filters for such reachability.=C2=A0

Q: How do you encode match on port number= in SAFI 128 ?=C2=A0

GV> It is not comparing apples wi= th oranges. Redirection is local action, however technically the label push= ed can be a service label which can be used for telemetry. This service lab= el is announced by the remote egress device by attaching the RT for each pa= rticular telemetry instance =E2=80=A6 in that case you have the IGP label += flow telemetry service label. The service label can be used for telemetry= =E2=80=A6 It is even better as in this case it is 100% certain that the flo= w ends up at the right router and has the right label attached to avoid loo= ping etc=E2=80=A6

=E2=80=8BSame comments as above :)

Cheers,
R.

--001a1136b07a1d3a630525d38033-- From nobody Tue Dec 1 04:45:24 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC7811B2C41; Tue, 1 Dec 2015 04:45:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.454 X-Spam-Level: X-Spam-Status: No, score=-98.454 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ujk3xaiTfgW5; Tue, 1 Dec 2015 04:45:15 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2661C1B2C32; Tue, 1 Dec 2015 04:45:14 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=74.43.47.177; From: "Susan Hares" To: "'Benoit Claise'" , , References: <565824EA.6070805@cisco.com> <565D6264.2020208@cisco.com> In-Reply-To: <565D6264.2020208@cisco.com> Date: Tue, 1 Dec 2015 07:45:16 -0500 Message-ID: <016a01d12c36$21bdd480$65397d80$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_016B_01D12C0C.38EAD9C0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFw2cB4VwH9hhdVFSIyiDRRayOBswGSTqJRn2oladA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] YANG data models in IDR: extraction and compilation feedback X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 12:45:17 -0000 This is a multipart message in MIME format. ------=_NextPart_000_016B_01D12C0C.38EAD9C0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Benoit:=20 =20 Thank you for this notification. I will work on updating this yang data = model.=20 =20 Sue=20 =20 From: Benoit Claise [mailto:bclaise@cisco.com]=20 Sent: Tuesday, December 01, 2015 4:04 AM To: idr@ietf.org; yang-coord@ietf.org Subject: YANG data models in IDR: extraction and compilation feedback =20 Dear all, I looked at the YANG models in the IDR WG documents, from a compilation = point of view (NOT from a YANG design point of view): http://datatracker.ietf.org/doc/draft-ietf-idr-bgp-model/ See the compilation results, updated daily, at = http://www.claise.be/IETFYANGPageCompilation.html For the 5 data models, you 're missing double quotes for the file names. = As an example: OLD: =20

 file bgp.yang
   module bgp {

NEW:

    file "bgp.yang"
   module bgp {

Now that this document is an IETF WG document, you must correct this one =
error type (for the 5 data models), given by pyang --ietf

bgp-types.yang:1: warning: RFC 6087: 4.1: the module name should start =
with one of the strings "ietf-" or "iana-"
bgp-types.yang:3: warning: RFC 6087: 4.8: namespace value should be =
"urn:ietf:params:xml:ns:yang:bgp-types"

As an example:
OLD:

module bgp-types {
    yang-version "1";
    namespace   =
"http://openconfig.net/yang/bgp-types";
    prefix "bgp-types";

NEW:

module ietf-bgp-types {
    yang-version "1";
    namespace "urn:ietf:params:xml:ns:yang:ietf-bgp-types";
    prefix "bgp-types";

Please update your draft accordingly.

Regards, Benoit

=20

------=_NextPart_000_016B_01D12C0C.38EAD9C0
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Benoit: 

Thank you for this notification.=C2=A0 I will work on updating this =
yang data model. 

Sue 

From: Benoit Claise [mailto:bclaise@cisco.com] 
Sent: Tuesday, =
December 01, 2015 4:04 AM
To: idr@ietf.org; =
yang-coord@ietf.org
Subject: YANG data models in IDR: =
extraction and compilation feedback

Dear all,

I looked at the YANG =
models in the IDR WG documents, from a compilation point of view (NOT =
from a YANG design point of view):
http:/=
/datatracker.ietf.org/doc/draft-ietf-idr-bgp-model/

See the =
compilation results, updated daily, at http://www.cla=
ise.be/IETFYANGPageCompilation.html
For the 5 data models, you 're missing double quotes =
for the file names. As an example:

OLD:
    =
=C2=A0=C2=A0=C2=A0<CODE BEGINS> file =
bgp.yang
=C2=A0=C2=A0 module bgp =
{
NEW:
=C2=A0=C2=A0 <CODE =
BEGINS> file "bgp.yang"
=C2=A0=C2=A0 =
module bgp {

Now that this =
document is an IETF WG document, you must correct this one error type =
(for the 5 data models), given by pyang --ietf
bgp-types.yang:1: warning: RFC 6087: 4.1: the module =
name should start with one of the strings "ietf-" or =
"iana-"
bgp-types.yang:3: warning: RFC 6087: 4.8: namespace =
value should be =
"urn:ietf:params:xml:ns:yang:bgp-types"
As an example:
OLD:
module bgp-types {
    yang-version =
"1";
    namespace "http://openconfig.net=
/yang/bgp-types";
    prefix =
"bgp-types";
NEW:
module =
ietf-bgp-types {
    yang-version =
"1";
    namespace =
"urn:ietf:params:xml:ns:yang:ietf-bgp-types";
  &n=
bsp; prefix "bgp-types";

Please update your draft =
accordingly.

Regards, Benoit

------=_NextPart_000_016B_01D12C0C.38EAD9C0--

From nobody Tue Dec  1 05:31:17 2015
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 176241B2D72 for ; Tue,  1 Dec 2015 05:29:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level: 
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aw4cVatbN50V for ; Tue,  1 Dec 2015 05:29:08 -0800 (PST)
Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FE1D1B2D71 for ; Tue,  1 Dec 2015 05:29:08 -0800 (PST)
Received: by pabfh17 with SMTP id fh17so5837165pab.0 for ; Tue, 01 Dec 2015 05:29:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:content-type:mime-version:subject:in-reply-to:date:cc :message-id:references:to; bh=qkB7TAPSD1s+VzbDkFLhz3inTjCTtTcI5VGCFEFfhKM=; b=b7lEEOUblo6wvVuPj3VhienEWgOfJ9jTInojDqg3DqkczTy9OHqE0rd7sTDfUQWXvn dJIV5Ll9XyJVeqRtTPw5rXUHoaKeY872rHBAuP711K0qk1oE5lv0cmm62IH63ZcmaN3M H2e9uzK6jCCXvhs5l32CZHbawRGxzyqW3DrsXObwrpoH62E5EB8VjGgREwS5J+x2jhad 4j47+sIpDZm3+PPJ8bVlUJMVPEfnNQOfQLL1mmliIXfdMNmV2jYxcAkoEhd+gIlvNobx TesRy1Id73ik9KcxH4s1Jxh5vvSiAxa/rwT4yaAzZO5ScgnvMS6c5dhiZW6eur2AfPw8 vVkQ==
X-Received: by 10.66.235.40 with SMTP id uj8mr101018725pac.151.1448976547674;  Tue, 01 Dec 2015 05:29:07 -0800 (PST)
Received: from [192.168.66.254] ([203.118.14.76]) by smtp.gmail.com with ESMTPSA id qy7sm58783843pab.37.2015.12.01.05.29.03 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 01 Dec 2015 05:29:06 -0800 (PST)
From: Gunter Van De Velde 
X-Google-Original-From: Gunter Van De Velde 
Content-Type: multipart/alternative; boundary="Apple-Mail=_162481DD-4F0E-47E8-B7AE-CA21DDC8984C"
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
In-Reply-To: 
Date: Tue, 1 Dec 2015 21:29:00 +0800
Message-Id: <76FCD388-F325-4FBC-AC9B-AE117ADDCE4B@icloud.com>
References: <056c01d126ab$61421980$23c64c80$@ndzh.com> <565D1005.2090603@mti-systems.com> <1448944019080-c58149c9-7bb3859e-57355fa2@icloud.com>  <07FD3721-CBAC-4EA8-8651-8DB0EE037F76@icloud.com> 
To: Robert Raszuk 
X-Mailer: Apple Mail (2.3096.5)
Archived-At: 
X-Mailman-Approved-At: Tue, 01 Dec 2015 05:31:08 -0800
Cc: idr wg 
Subject: Re: [Idr] WG Call for adoption on draft-liang-idr-bgp-flowspec-label-01 (11/24 to 12/8)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 01 Dec 2015 13:29:11 -0000

--Apple-Mail=_162481DD-4F0E-47E8-B7AE-CA21DDC8984C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

The mud is starting to become more clear=E2=80=A6 Currently my =
understanding of the draft is that proposal is pushing an additional =
service label aka a Telemetry Label.=20
This telemetry label is label used to indicate that the packet matched a =
particular flowspec rule.

The operational behaviour is as follows:

at an SP ingress router which is implementing the flowspec rule and =
under the condition that the ingress packet matches the flowspec rule, =
then this label is pushed.

Example1: if the packet is just following Global routing table, then the =
packet will have an exterior IGP label L1 AND a label L2 to indicate =
that the packet was matched by this flowspec rule.
Assumption is that the egress router can correlate the L2 to be a =
telemetry service label. (How is that correlation being done exactly? In =
the draft i see mentioned that it is allocated by the=20
egress PE, but then how can the Flowspec controller figure this out? )

Example2: If the ingress packet is received through a VPN, the the =
packet will have exterior IGP label L1, VPN service label L2 AND the =
label L3 to indicate the the packet was matched=20
by the flowpsec rule. Assumption is again that the egress router can =
correlate L3 with being a Telemetry label.

A new question:=20
* What would happen if PIC re-route would happen for multi-homed =
connections, how are the labels to be sync=E2=80=99d between egress =
PE=E2=80=99s?
* Where would the label be inserted in the label stack? as far as =
possible to the top of the label stack or more towards the bottom of the =
label stack?=20

Please see inline for further thoughts:

> On 01 Dec 2015, at 18:20, Robert Raszuk > wrote:
>=20
> GV> Really =E2=80=A6 what about this section in =
http://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing/ =

>=20
>=20
> =E2=80=8BWhat you are quoting is a reference to IGP-Prefix Segment =
=E2=80=8Bwhich is global .... it is not reference to mpls "global label"
>=20

GV> It describes a a global identifier for a prefix that gets correlated =
to a label that is used for this prefix in the MPLS realm. However, if =
the above operational description is correct, then it does not really =
matter too much as the relevance is between ingress and egress Router. =
However, if you want to have probes inside the network consuming this =
label and using it for Telemetry then the label needs to be unique in =
the network though for easiest operation.

> =E2=80=8BBesides this is SPRING draft not an MPLS=E2=80=8B WG RFC.
>=20

GV> so you say: not invented by MPLS WG and because it is not even a =
standard in MPLS we authors do not care? It deserves imo some text to =
explain that the label is either network unique or has only local =
significance. It should not be very hard to explain and makes it better =
document for the person reading the draft.=20

> GV> Yes indeed using the service label gives you telemetry capability. =
Hence why not simply use the RT trigger to push a label by flowspec. The =
description on how this would work is unclear and confusing.
>=20
>=20
> =E2=80=8BBut who is saying that RT would not be used for import. =
RFC5575 is explicit in stating that Route Target extended community can =
be attached to FlowSpec routes for import.=20
>=20
> =E2=80=8B      =E2=80=8BPropagation of this NLRI is controlled by =
matching Route Target
>    extended communities associated with the BGP path advertisement =
with
>    the VRF import policy, using the same mechanism as described in =
"BGP/=20
>       MPLS IP VPNs" [RFC4364 ] =
.=E2=80=8B
>=20
> =E2=80=8BThis spec is just adding new information which can be used =
after importing to a VRF. =E2=80=8B
>=20

GV> I did not understand that its =E2=80=9Ca Telemetry Service Label=E2=80=
=9D. Nevertheless, what i am proposing is that by overloading the VRF =
with Telemetry context, you have the same thing. No need to add a new =
label.

>=20
> GV> again, why not use a VPN service label to achieve this? its the =
same result if each RT is unique and is announce by the correct egress =
device=E2=80=A6 nothing new is needed when using this
>=20
> =E2=80=8BYou are mixing things I am afraid. "VPN service" is used to =
distribute reachability. FlowSpec is used to distribute a set of defined =
filters for such reachability.=20
>=20
> Q: How do you encode match on port number in SAFI 128 ?=20
>=20
>=20

GV> Good question actually=E2=80=A6 it made me think a little on how to =
overload the VRF with the Telemetry context. However, can it not be =
done?.

Lets take the following example:=20
Closeby-End =E2=80=94=E2=80=94 PE1 =E2=80=94=E2=80=94 ISP network =E2=80=94=
=E2=80=94 PE2 =E2=80=94=E2=80=94 Far-end

On PE2 we have VPN11 which has all the Far-end routes and they will all =
be exported with RT1:1, and imports RT1:1, RT1:2, RT1:3 and RT1:4 =
towards PE1
In addition we have:=20
  VPN12 which injects 0/0 and exports with RT1:2 to PE1
  VPN13 which injects 0/0 and exports with RT1:3 to PE1
  VPN14 which injects 0/0 and exports with RT1:4 to PE1
  ...

Lets assume we have three flowspec rules: FlowSpec1, FlowSpec2 and =
FlowSpec3

In this case FlowSpec1 for example can match on port numbers and as =
consequence may redirect matching traffic to VPN12 and hence all matched =
traffic will enjoy the service label for 0/0 in VPN12.
This provides context information that the packet is matched by =
Flowspec1, while still routed to the Far-end.
FlowSpec2 could match upon other parameters and then redirect to VPN13 =
and start using its correlated service label as Telemetry label.

This would be a way to overload the VPN service label with additional =
context for Telemetry. I know it is not very friendly and neither clean, =
but it can be done technically with existing technology.
No need for a new solution which can already be done with existing =
technologies.

> GV> It is not comparing apples with oranges. Redirection is local =
action, however technically the label pushed can be a service label =
which can be used for telemetry. This service label is announced by the =
remote egress device by attaching the RT for each particular telemetry =
instance =E2=80=A6 in that case you have the IGP label + flow telemetry =
service label. The service label can be used for telemetry=E2=80=A6 It =
is even better as in this case it is 100% certain that the flow ends up =
at the right router and has the right label attached to avoid looping =
etc=E2=80=A6
>=20
>=20
> =E2=80=8BSame comments as above :)
>=20

GV> see above=E2=80=A6 Service label can be overloaded with context if =
need to be.

GV> btw, where i do see potential use for pushing a Label by using =
Flowspec is for Entropy-Label/ELI through Flowspec=E2=80=A6 that way a =
controller can use selective matching to manipulate load distribution =
trough the network. However this is different from the use-case =
described in this draft. Maybe draft can be extended for that purpose?

Ciao,
G/

--Apple-Mail=_162481DD-4F0E-47E8-B7AE-CA21DDC8984C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

The mud is starting to become more clear=E2=80=A6=
 Currently my understanding of the draft is that proposal is pushing an =
additional service label aka a Telemetry Label. 
This telemetry label is label used to indicate that the =
packet matched a particular flowspec rule.

The operational behaviour is as =
follows:

at an =
SP ingress router which is implementing the flowspec rule and under the =
condition that the ingress packet matches the flowspec rule, then this =
label is pushed.

Example1: if the packet is just following Global routing =
table, then the packet will have an exterior IGP label L1 AND a label L2 =
to indicate that the packet was matched by this flowspec rule.
Assumption is that the egress router can correlate the L2 to =
be a telemetry service label. (How is that correlation being done =
exactly? In the draft i see mentioned that it is allocated by =
the 
egress PE, but then how can the Flowspec =
controller figure this out? )

Example2: If the ingress packet is =
received through a VPN, the the packet will have exterior IGP label L1, =
VPN service label L2 AND the label L3 to indicate the the packet was =
matched 
by the flowpsec rule. Assumption is =
again that the egress router can correlate L3 with being a Telemetry =
label.

A new =
question: 
* What would happen if PIC re-route =
would happen for multi-homed connections, how are the labels to be =
sync=E2=80=99d between egress PE=E2=80=99s?
* Where =
would the label be inserted in the label stack? as far as possible to =
the top of the label stack or more towards the bottom of the label =
stack? 

Please see inline for further thoughts:

On 01 Dec 2015, at 18:20, Robert Raszuk <robert@raszuk.net> =
wrote:

GV> Really =E2=80=A6 what =
about this section in http://datatracker.ietf.org/doc/draft-ietf-spring-segment-routi=
ng/

=E2=80=8B=
What you are quoting is a reference to IGP-Prefix Segment =E2=80=8Bwhich =
is global .... it is not reference to mpls "global label"

GV> It describes a a global =
identifier for a prefix that gets correlated to a label that is used for =
this prefix in the MPLS realm. However, if the above operational =
description is correct, then it does not really matter too much as the =
relevance is between ingress and egress Router. However, if you want to =
have probes inside the network consuming this label and using it for =
Telemetry then the label needs to be unique in the network though for =
easiest operation.

=E2=80=8B=
Besides this is SPRING draft not an MPLS=E2=80=8B WG RFC.

GV> so you say: not =
invented by MPLS WG and because it is not even a standard in MPLS we =
authors do not care? It deserves imo some text to explain that the label =
is either network unique or has only local significance. It should not =
be very hard to explain and makes it better document for the person =
reading the draft. 

GV> Yes =
indeed using the service label gives you telemetry capability. Hence why =
not simply use the RT trigger to push a label by flowspec. The =
description on how this would work is unclear and confusing.

=E2=80=8B=
But who is saying that RT would not be used for import. RFC5575 is =
explicit in stating that Route Target extended community can be attached =
to FlowSpec routes for import. 

=E2=80=8B      =E2=80=8BPropagation of this NLRI is =
controlled by matching Route Target
   extended communities associated with the BGP path advertisement with
   the VRF import policy, using the same mechanism as described in =
"BGP/ 
      MPLS IP VPNs" [RFC4364] .=E2=80=8B

=E2=80=8BThis =
spec is just adding new information which can be used after importing to =
a VRF. =E2=80=8B

GV> I did not understand that its =
=E2=80=9Ca Telemetry Service Label=E2=80=9D. Nevertheless, what i am =
proposing is that by overloading the VRF with Telemetry context, you =
have the same thing. No need to add a new label.



GV> again, why not use a VPN service label =
to achieve this? its the same result if each RT is unique and is =
announce by the correct egress device=E2=80=A6 nothing new is needed =
when using this

=E2=80=8B=
You are mixing things I am afraid. "VPN service" is used to distribute =
reachability. FlowSpec is used to distribute a set of defined filters =
for such reachability. 

Q: How =
do you encode match on port number in SAFI 128 ? 



GV> Good question actually=E2=80=A6 =
it made me think a little on how to overload the VRF with the Telemetry =
context. However, can it not be done?.

Lets take the following =
example: 
Closeby-End =E2=80=94=E2=80=94 PE1 =
=E2=80=94=E2=80=94 ISP network =E2=80=94=E2=80=94 PE2 =E2=80=94=E2=80=94 =
Far-end

On PE2 =
we have VPN11 which has all the Far-end routes and they will all be =
exported with RT1:1, and imports RT1:1, RT1:2, RT1:3 and RT1:4 towards =
PE1
In addition we have: 
  VPN12 which injects 0/0 and exports with RT1:2 to =
PE1
  VPN13 which injects 0/0 and exports with =
RT1:3 to PE1
  VPN14 which injects 0/0 and =
exports with RT1:4 to PE1
  ...

Lets assume we have =
three flowspec rules: FlowSpec1, FlowSpec2 and FlowSpec3

In this case FlowSpec1 =
for example can match on port numbers and as consequence may redirect =
matching traffic to VPN12 and hence all matched traffic will enjoy the =
service label for 0/0 in VPN12.
This provides =
context information that the packet is matched by Flowspec1, while still =
routed to the Far-end.
FlowSpec2 could match upon =
other parameters and then redirect to VPN13 and start using its =
correlated service label as Telemetry label.

This would be a way to overload the VPN =
service label with additional context for Telemetry. I know it is not =
very friendly and neither clean, but it can be done technically with =
existing technology.
No need for a new solution =
which can already be done with existing technologies.

GV> It is not comparing =
apples with oranges. Redirection is local action, however technically =
the label pushed can be a service label which can be used for telemetry. =
This service label is announced by the remote egress device by attaching =
the RT for each particular telemetry instance =E2=80=A6 in that case you =
have the IGP label + flow telemetry service label. The service label can =
be used for telemetry=E2=80=A6 It is even better as in this case it is =
100% certain that the flow ends up at the right router and has the right =
label attached to avoid looping =
etc=E2=80=A6


=E2=80=8B=
Same comments as above :)

GV> see above=E2=80=A6 =
Service label can be overloaded with context if need to be.

GV> btw, where i do =
see potential use for pushing a Label by using Flowspec is for =
Entropy-Label/ELI through Flowspec=E2=80=A6 that way a controller can =
use selective matching to manipulate load distribution trough the =
network. However this is different from the use-case described in this =
draft. Maybe draft can be extended for that purpose?

Ciao,

G/

=

--Apple-Mail=_162481DD-4F0E-47E8-B7AE-CA21DDC8984C--

From nobody Tue Dec  1 05:31:18 2015
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3DEE1B2D75 for ; Tue,  1 Dec 2015 05:30:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level: 
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y2Jy-79o-f6X for ; Tue,  1 Dec 2015 05:30:07 -0800 (PST)
Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D182C1B2D19 for ; Tue,  1 Dec 2015 05:30:06 -0800 (PST)
Received: by padhx2 with SMTP id hx2so5641267pad.1 for ; Tue, 01 Dec 2015 05:30:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:content-type:mime-version:subject:in-reply-to:date:cc :message-id:references:to; bh=mbiKWp+HqG1oOMk64XvpoPJxht/w/ppO5jRaXKjZYpk=; b=ubNtv0GWr259UitdlqAwH6P9jH0dANfnqIiZE3XQ7dG8FwbQTllOzRmVRPz8TyriII lWDG+SIkOe/Xi/32r8kyeRflIkQLWuR78wUXKq1aKMJsW8peULcAWHqrNsfOG+tr10aa f6ITncVRLxUQxLD2/JnlvbWsKLf+b4gTNBHjg9s0JFEkWTmL+qZElJUCy5Wc2jOmLemW Tlg7/wCLK5fRCSC/W6pOpIyU0DpsMQZv1jTnMLX3o7DvxnU9soFVd4eNXZF5ksBr0/y9 Ao0IKnLMH84cKyaPzaXNR1B8/kxXDasqrnm1oo+JnK6qXnZgiIwgppvzwedz/x9KDaqO pZiw==
X-Received: by 10.66.219.39 with SMTP id pl7mr100366180pac.88.1448976605886; Tue, 01 Dec 2015 05:30:05 -0800 (PST)
Received: from [192.168.66.254] ([203.118.14.76]) by smtp.gmail.com with ESMTPSA id qy7sm58783843pab.37.2015.12.01.05.30.02 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 01 Dec 2015 05:30:04 -0800 (PST)
From: Gunter Van De Velde 
X-Google-Original-From: Gunter Van De Velde 
Content-Type: multipart/alternative; boundary="Apple-Mail=_1477A82B-ECE3-4C16-858D-91D2D8474922"
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
In-Reply-To: <76FCD388-F325-4FBC-AC9B-AE117ADDCE4B@icloud.com>
Date: Tue, 1 Dec 2015 21:30:02 +0800
Message-Id: 
References: <056c01d126ab$61421980$23c64c80$@ndzh.com> <565D1005.2090603@mti-systems.com> <1448944019080-c58149c9-7bb3859e-57355fa2@icloud.com>  <07FD3721-CBAC-4EA8-8651-8DB0EE037F76@icloud.com>  <76FCD388-F325-4FBC-AC9B-AE117ADDCE4B@icloud.com>
To: Robert Raszuk 
X-Mailer: Apple Mail (2.3096.5)
Archived-At: 
X-Mailman-Approved-At: Tue, 01 Dec 2015 05:31:08 -0800
Cc: idr wg 
Subject: [Idr] WG Call for adoption on draft-liang-idr-bgp-flowspec-label-01 (11/24 to 12/8)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 01 Dec 2015 13:30:09 -0000

--Apple-Mail=_1477A82B-ECE3-4C16-858D-91D2D8474922
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

> On 01 Dec 2015, at 21:29, Gunter Van De Velde  =
wrote:
>=20
> The mud is starting to become more clear=E2=80=A6 Currently my =
understanding of the draft is that proposal is pushing an additional =
service label aka a Telemetry Label.=20
> This telemetry label is label used to indicate that the packet matched =
a particular flowspec rule.
>=20
> The operational behaviour is as follows:
>=20
> at an SP ingress router which is implementing the flowspec rule and =
under the condition that the ingress packet matches the flowspec rule, =
then this label is pushed.
>=20
> Example1: if the packet is just following Global routing table, then =
the packet will have an exterior IGP label L1 AND a label L2 to indicate =
that the packet was matched by this flowspec rule.
> Assumption is that the egress router can correlate the L2 to be a =
telemetry service label. (How is that correlation being done exactly? In =
the draft i see mentioned that it is allocated by the=20
> egress PE, but then how can the Flowspec controller figure this out? )
>=20
> Example2: If the ingress packet is received through a VPN, the the =
packet will have exterior IGP label L1, VPN service label L2 AND the =
label L3 to indicate the the packet was matched=20
> by the flowpsec rule. Assumption is again that the egress router can =
correlate L3 with being a Telemetry label.
>=20
> A new question:=20
> * What would happen if PIC re-route would happen for multi-homed =
connections, how are the labels to be sync=E2=80=99d between egress =
PE=E2=80=99s?
> * Where would the label be inserted in the label stack? as far as =
possible to the top of the label stack or more towards the bottom of the =
label stack?=20
>=20
> Please see inline for further thoughts:
>=20
>> On 01 Dec 2015, at 18:20, Robert Raszuk > wrote:
>>=20
>> GV> Really =E2=80=A6 what about this section in =
http://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing/ =

>>=20
>>=20
>> =E2=80=8BWhat you are quoting is a reference to IGP-Prefix Segment =
=E2=80=8Bwhich is global .... it is not reference to mpls "global label"
>>=20
>=20
> GV> It describes a a global identifier for a prefix that gets =
correlated to a label that is used for this prefix in the MPLS realm. =
However, if the above operational description is correct, then it does =
not really matter too much as the relevance is between ingress and =
egress Router. However, if you want to have probes inside the network =
consuming this label and using it for Telemetry then the label needs to =
be unique in the network though for easiest operation.
>=20
>> =E2=80=8BBesides this is SPRING draft not an MPLS=E2=80=8B WG RFC.
>>=20
>=20
> GV> so you say: not invented by MPLS WG and because it is not even a =
standard in MPLS we authors do not care? It deserves imo some text to =
explain that the label is either network unique or has only local =
significance. It should not be very hard to explain and makes it better =
document for the person reading the draft.=20
>=20
>> GV> Yes indeed using the service label gives you telemetry =
capability. Hence why not simply use the RT trigger to push a label by =
flowspec. The description on how this would work is unclear and =
confusing.
>>=20
>>=20
>> =E2=80=8BBut who is saying that RT would not be used for import. =
RFC5575 is explicit in stating that Route Target extended community can =
be attached to FlowSpec routes for import.=20
>>=20
>> =E2=80=8B      =E2=80=8BPropagation of this NLRI is controlled by =
matching Route Target
>>    extended communities associated with the BGP path advertisement =
with
>>    the VRF import policy, using the same mechanism as described in =
"BGP/=20
>>       MPLS IP VPNs" [RFC4364 ] =
.=E2=80=8B
>>=20
>> =E2=80=8BThis spec is just adding new information which can be used =
after importing to a VRF. =E2=80=8B
>>=20
>=20
> GV> I did not understand that its =E2=80=9Ca Telemetry Service =
Label=E2=80=9D. Nevertheless, what i am proposing is that by overloading =
the VRF with Telemetry context, you have the same thing. No need to add =
a new label.
>=20
>=20
>>=20
>> GV> again, why not use a VPN service label to achieve this? its the =
same result if each RT is unique and is announce by the correct egress =
device=E2=80=A6 nothing new is needed when using this
>>=20
>> =E2=80=8BYou are mixing things I am afraid. "VPN service" is used to =
distribute reachability. FlowSpec is used to distribute a set of defined =
filters for such reachability.=20
>>=20
>> Q: How do you encode match on port number in SAFI 128 ?=20
>>=20
>>=20
>=20
> GV> Good question actually=E2=80=A6 it made me think a little on how =
to overload the VRF with the Telemetry context. However, can it not be =
done?.
>=20
> Lets take the following example:=20
> Closeby-End =E2=80=94=E2=80=94 PE1 =E2=80=94=E2=80=94 ISP network =
=E2=80=94=E2=80=94 PE2 =E2=80=94=E2=80=94 Far-end
>=20
> On PE2 we have VPN11 which has all the Far-end routes and they will =
all be exported with RT1:1, and imports RT1:1, RT1:2, RT1:3 and RT1:4 =
towards PE1
> In addition we have:=20
>   VPN12 which injects 0/0 and exports with RT1:2 to PE1
>   VPN13 which injects 0/0 and exports with RT1:3 to PE1
>   VPN14 which injects 0/0 and exports with RT1:4 to PE1
>   ...
>=20
> Lets assume we have three flowspec rules: FlowSpec1, FlowSpec2 and =
FlowSpec3
>=20
> In this case FlowSpec1 for example can match on port numbers and as =
consequence may redirect matching traffic to VPN12 and hence all matched =
traffic will enjoy the service label for 0/0 in VPN12.
> This provides context information that the packet is matched by =
Flowspec1, while still routed to the Far-end.
> FlowSpec2 could match upon other parameters and then redirect to VPN13 =
and start using its correlated service label as Telemetry label.
>=20
> This would be a way to overload the VPN service label with additional =
context for Telemetry. I know it is not very friendly and neither clean, =
but it can be done technically with existing technology.
> No need for a new solution which can already be done with existing =
technologies.
>=20
>> GV> It is not comparing apples with oranges. Redirection is local =
action, however technically the label pushed can be a service label =
which can be used for telemetry. This service label is announced by the =
remote egress device by attaching the RT for each particular telemetry =
instance =E2=80=A6 in that case you have the IGP label + flow telemetry =
service label. The service label can be used for telemetry=E2=80=A6 It =
is even better as in this case it is 100% certain that the flow ends up =
at the right router and has the right label attached to avoid looping =
etc=E2=80=A6
>>=20
>>=20
>> =E2=80=8BSame comments as above :)
>>=20
>=20
> GV> see above=E2=80=A6 Service label can be overloaded with context if =
need to be.
>=20
> GV> btw, where i do see potential use for pushing a Label by using =
Flowspec is for Entropy-Label/ELI through Flowspec=E2=80=A6 that way a =
controller can use selective matching to manipulate load distribution =
trough the network. However this is different from the use-case =
described in this draft. Maybe draft can be extended for that purpose?
>=20
> Ciao,
> G/
>=20
>=20
>=20

--Apple-Mail=_1477A82B-ECE3-4C16-858D-91D2D8474922
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

On 01 Dec 2015, at 21:29, Gunter Van De Velde <gvandeve69@gmail.com> wrote:

The mud is starting to become more clear=E2=80=A6=
 Currently my understanding of the draft is that proposal is pushing an =
additional service label aka a Telemetry Label. 
This telemetry label is label used to indicate that the =
packet matched a particular flowspec rule.

The operational behaviour is as =
follows:

at an =
SP ingress router which is implementing the flowspec rule and under the =
condition that the ingress packet matches the flowspec rule, then this =
label is pushed.

Example1: if the packet is just following Global routing =
table, then the packet will have an exterior IGP label L1 AND a label L2 =
to indicate that the packet was matched by this flowspec rule.
Assumption is that the egress router can correlate the L2 to =
be a telemetry service label. (How is that correlation being done =
exactly? In the draft i see mentioned that it is allocated by =
the 
egress PE, but then how can the Flowspec =
controller figure this out? )

Example2: If the ingress packet is =
received through a VPN, the the packet will have exterior IGP label L1, =
VPN service label L2 AND the label L3 to indicate the the packet was =
matched 
by the flowpsec rule. Assumption is =
again that the egress router can correlate L3 with being a Telemetry =
label.

A new =
question: 
* What would happen if PIC re-route =
would happen for multi-homed connections, how are the labels to be =
sync=E2=80=99d between egress PE=E2=80=99s?
* Where =
would the label be inserted in the label stack? as far as possible to =
the top of the label stack or more towards the bottom of the label =
stack? 

Please see inline for further thoughts:

On 01 Dec 2015, at 18:20, Robert Raszuk <robert@raszuk.net> =
wrote:

GV> Really =E2=80=A6 what =
about this section in http://datatracker.ietf.org/doc/draft-ietf-spring-segment-routi=
ng/

=E2=80=8B=
What you are quoting is a reference to IGP-Prefix Segment =E2=80=8Bwhich =
is global .... it is not reference to mpls "global label"

GV> It describes a a global =
identifier for a prefix that gets correlated to a label that is used for =
this prefix in the MPLS realm. However, if the above operational =
description is correct, then it does not really matter too much as the =
relevance is between ingress and egress Router. However, if you want to =
have probes inside the network consuming this label and using it for =
Telemetry then the label needs to be unique in the network though for =
easiest operation.

=E2=80=8B=
Besides this is SPRING draft not an MPLS=E2=80=8B WG RFC.

GV> so you say: not =
invented by MPLS WG and because it is not even a standard in MPLS we =
authors do not care? It deserves imo some text to explain that the label =
is either network unique or has only local significance. It should not =
be very hard to explain and makes it better document for the person =
reading the draft. 

GV> Yes =
indeed using the service label gives you telemetry capability. Hence why =
not simply use the RT trigger to push a label by flowspec. The =
description on how this would work is unclear and confusing.

=E2=80=8B=
But who is saying that RT would not be used for import. RFC5575 is =
explicit in stating that Route Target extended community can be attached =
to FlowSpec routes for import. 

=E2=80=8B      =E2=80=8BPropagation of this NLRI is =
controlled by matching Route Target
   extended communities associated with the BGP path advertisement with
   the VRF import policy, using the same mechanism as described in =
"BGP/ 
      MPLS IP VPNs" [RFC4364] .=E2=80=8B

=E2=80=8BThis =
spec is just adding new information which can be used after importing to =
a VRF. =E2=80=8B

GV> I did not understand that its =
=E2=80=9Ca Telemetry Service Label=E2=80=9D. Nevertheless, what i am =
proposing is that by overloading the VRF with Telemetry context, you =
have the same thing. No need to add a new label.

GV> again, why not use a VPN service label =
to achieve this? its the same result if each RT is unique and is =
announce by the correct egress device=E2=80=A6 nothing new is needed =
when using this

=E2=80=8B=
You are mixing things I am afraid. "VPN service" is used to distribute =
reachability. FlowSpec is used to distribute a set of defined filters =
for such reachability. 

Q: How =
do you encode match on port number in SAFI 128 ? 

GV> Good question actually=E2=80=A6 =
it made me think a little on how to overload the VRF with the Telemetry =
context. However, can it not be done?.

Lets take the following =
example: 
Closeby-End =E2=80=94=E2=80=94 PE1 =
=E2=80=94=E2=80=94 ISP network =E2=80=94=E2=80=94 PE2 =E2=80=94=E2=80=94 =
Far-end

On PE2 =
we have VPN11 which has all the Far-end routes and they will all be =
exported with RT1:1, and imports RT1:1, RT1:2, RT1:3 and RT1:4 towards =
PE1
In addition we have: 
  VPN12 which injects 0/0 and exports with RT1:2 to =
PE1
  VPN13 which injects 0/0 and exports with =
RT1:3 to PE1
  VPN14 which injects 0/0 and =
exports with RT1:4 to PE1
  ...

Lets assume we have =
three flowspec rules: FlowSpec1, FlowSpec2 and FlowSpec3

In this case FlowSpec1 =
for example can match on port numbers and as consequence may redirect =
matching traffic to VPN12 and hence all matched traffic will enjoy the =
service label for 0/0 in VPN12.
This provides =
context information that the packet is matched by Flowspec1, while still =
routed to the Far-end.
FlowSpec2 could match upon =
other parameters and then redirect to VPN13 and start using its =
correlated service label as Telemetry label.

This would be a way to overload the VPN =
service label with additional context for Telemetry. I know it is not =
very friendly and neither clean, but it can be done technically with =
existing technology.
No need for a new solution =
which can already be done with existing technologies.

GV> It is not comparing =
apples with oranges. Redirection is local action, however technically =
the label pushed can be a service label which can be used for telemetry. =
This service label is announced by the remote egress device by attaching =
the RT for each particular telemetry instance =E2=80=A6 in that case you =
have the IGP label + flow telemetry service label. The service label can =
be used for telemetry=E2=80=A6 It is even better as in this case it is =
100% certain that the flow ends up at the right router and has the right =
label attached to avoid looping =
etc=E2=80=A6

=E2=80=8B=
Same comments as above :)

GV> see above=E2=80=A6 =
Service label can be overloaded with context if need to be.

GV> btw, where i do =
see potential use for pushing a Label by using Flowspec is for =
Entropy-Label/ELI through Flowspec=E2=80=A6 that way a controller can =
use selective matching to manipulate load distribution trough the =
network. However this is different from the use-case described in this =
draft. Maybe draft can be extended for that purpose?

Ciao,

G/

Wesley,

The only reason to use floating notation as I recall was to express various= traffic rates with single 4 octets. IEEE.754 was just as good format as an= y other with an advantge of being implemented by some vendors already.

Otherwise if we would take say integer we would likely need 4 octets for by= tes/s, 4 octets for kbytes/s, 4 octets for Mbytes/s and 4 octets in Gbytes/= s etc.. And who knows what traffic rates will be tomorrow ....

Best,

On Wed, Dec 2, 2015 at 8:25 PM, Wesley Eddy <wes@mti-system= s.com> wrote:

On 12/2/2015 1:51 PM, Jeffrey Haas wrote:

Wes,

On Wed, Dec 02, 2015 at 12:18:00PM -0500, Wesley Eddy wrote:

You're correct that us initially proposing to use floating-point was
done only really for consistency with existing use of floating-point
in traffic-rate per RFC 5575. I do not know the rationale for why
it was chosen there, but assume it's because of the wider range of
values that can be encoded compared to using a simple 32-bit
unsigned integer.

One general headache of 4-byte floating point numbers is that when you star= t
losing precision, you can have weird discrepancies between what you
configure, vs. what value can be encoded. This is one of the reasons = why
floating point on the wire is annoying.

Can anyone who was around at the time help to understand why floatin= g-point was specified in RFC 5575 for traffic-rate?

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

--_000_D284A85DF8566asechoudciscocom_-- From nobody Wed Dec 2 14:22:12 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3580F1B2E51 for ; Wed, 2 Dec 2015 14:22:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.889 X-Spam-Level: X-Spam-Status: No, score=0.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FF_IHOPE_YOU_SINK=2.166, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bVEM0AtauwuG for ; Wed, 2 Dec 2015 14:22:06 -0800 (PST) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C367D1B2E47 for ; Wed, 2 Dec 2015 14:22:05 -0800 (PST) Received: by wmvv187 with SMTP id v187so470542wmv.1 for ; Wed, 02 Dec 2015 14:22:04 -0800 (PST) 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=diDaGFahQg9ICR2/6NfPHaAdvKj976gmoWpxr68XETQ=; b=v74Fhub4ociwfXkskT4wO1YpSg5RpBnuFHf4uIP4nS70A4Pazikvpt5gA3WIwO2K1K STd+/KO3Bt4IAVKh6r2vG5VkT9HNRIaycbRjeChiO5RLbYqeolibSGoZTplVAT8/Ug4u 4FCVw0VCcMtWsTEWALta1BTG5ToYFeWO41T5XI1u1RQsnc86587f4QtBYk9saMtJQIhF ce14BHpoCI/6QEMjlYEistbAVBwNvrqkuEWPl3CpUzegeNq1RYUVsjAodcmjrzvjAdlp 3tdvYz+6hzyylapes/8575XvWIzTOGFzdGYPjXVn60yq+kdYeeOZ3ja3rF2V2GUWI+Zn aP4Q== MIME-Version: 1.0 X-Received: by 10.194.7.69 with SMTP id h5mr7347149wja.117.1449094924393; Wed, 02 Dec 2015 14:22:04 -0800 (PST) Sender: rraszuk@gmail.com Received: by 10.194.204.195 with HTTP; Wed, 2 Dec 2015 14:22:04 -0800 (PST) In-Reply-To: References: Date: Wed, 2 Dec 2015 23:22:04 +0100 X-Google-Sender-Auth: Upf0UD0LZtn_gXz510_nKjhdZC0 Message-ID: From: Robert Raszuk To: "Aseem Choudhary (asechoud)" Content-Type: multipart/alternative; boundary=047d7b450a6836e4060525f1b4d4 Archived-At: Cc: idr wg Subject: Re: [Idr] packet-rate action for flowspec X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2015 22:22:08 -0000 --047d7b450a6836e4060525f1b4d4 Content-Type: text/plain; charset=UTF-8 Aseem, If I understand your point you are suggesting to change the unit from bytes per sec to packets per sec. If so this is IMHO pretty bad idea for the shipping RFC in number of implementations as the proposed change is not backwards compatible and will just cause significant deployment mess in those cases where traffic-rate ext community is actually being used. However you/WG may suggest and standardize new extended community with pps unit of measurement if there would be rough consensu to do so though. But the time for comments on existing specification seems a bit too late. Cheers, R. On Wed, Dec 2, 2015 at 11:02 PM, Aseem Choudhary (asechoud) < asechoud@cisco.com> wrote: > IMHO, this is not the case with PPS (packets per sec). Assuming all > packets of 64 bytes, this translates to 512 bits per packet. We have 9 bits > to save and hence 4-byte integer will be fine without floating-point. It > saves much more as we consider higher average packet size. Besides, > typically pps will not count till billions of packets, especially for > flowspec, as it is counter-productive. I suggest a 4-bytes integer is just > fine for pps. > > -thanks, > Aseem > > From: Robert Raszuk > Date: Wednesday, December 2, 2015 at 1:16 PM > To: Wesley Eddy > Cc: idr wg > Subject: Re: [Idr] packet-rate action for flowspec > > Wesley, > > The only reason to use floating notation as I recall was to express > various traffic rates with single 4 octets. IEEE.754 was just as good > format as any other with an advantge of being implemented by some vendors > already. > > Otherwise if we would take say integer we would likely need 4 octets for > bytes/s, 4 octets for kbytes/s, 4 octets for Mbytes/s and 4 octets in > Gbytes/s etc.. And who knows what traffic rates will be tomorrow .... > > Best, > r. > > > On Wed, Dec 2, 2015 at 8:25 PM, Wesley Eddy wrote: > >> On 12/2/2015 1:51 PM, Jeffrey Haas wrote: >> >>> Wes, >>> >>> On Wed, Dec 02, 2015 at 12:18:00PM -0500, Wesley Eddy wrote: >>> >>>> You're correct that us initially proposing to use floating-point was >>>> done only really for consistency with existing use of floating-point >>>> in traffic-rate per RFC 5575. I do not know the rationale for why >>>> it was chosen there, but assume it's because of the wider range of >>>> values that can be encoded compared to using a simple 32-bit >>>> unsigned integer. >>>> >>> One general headache of 4-byte floating point numbers is that when you >>> start >>> losing precision, you can have weird discrepancies between what you >>> configure, vs. what value can be encoded. This is one of the reasons why >>> floating point on the wire is annoying. >>> >> >> >> Can anyone who was around at the time help to understand why >> floating-point was specified in RFC 5575 for traffic-rate? >> >> >> >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >> > > --047d7b450a6836e4060525f1b4d4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Aseem,

If I understand your point you are suggesting to chang= e the unit from bytes per sec to packets per sec. If so this is IMHO pretty= bad idea for the shipping RFC in number of implementations as the proposed= change is not backwards compatible and will just cause significant deploym= ent mess in those cases where traffic-rate ext community is actually being = used.=C2=A0

However yo= u/WG may suggest and standardize new extended community with pps unit of me= asurement if there would be rough consensu to do so though. But the time fo= r comments on existing specification seems a bit too late.

Cheers,
R.

On Wed, Dec 2, 2015 at 11:02 PM, Aseem Choudha= ry (asechoud) <asechoud@cisco.com> wrote:

IMHO, this is not the case with PPS (packets per sec). Assuming all pa= ckets of 64 bytes, this translates to 512 bits per packet. We have 9 bits t= o save and hence 4-byte integer will be fine without floating-point. It sav= es much more as we consider higher average packet size. Besides, typically pps will not count till billions o= f packets, especially for flowspec, as it is counter-productive. I suggest = a 4-bytes integer is just fine for pps.

-thanks,

Aseem

From: Robert Raszuk <robert@raszuk.net>
Date: Wednesday, December 2, 2015 a= t 1:16 PM
To: Wesley Eddy <wes@mti-systems.com>
Cc: idr wg <idr@ietf.org>
Subject: Re: [Idr] packet-rate acti= on for flowspec

Wesley,

The only reason to use floating notation as I recall was to express various= traffic rates with single 4 octets. IEEE.754 was just as good format as an= y other with an advantge of being implemented by some vendors already.

Otherwise if we would take say integer we would likely need 4 octets for by= tes/s, 4 octets for kbytes/s, 4 octets for Mbytes/s and 4 octets in Gbytes/= s etc.. And who knows what traffic rates will be tomorrow ....=C2=A0

Best,

r.

On Wed, Dec 2, 2015 at 8:25 PM, Wesley Eddy <wes@mti-system= s.com> wrote:

On 12/2/2015 1:51 PM, Jeffrey Haas wrote:

Wes,

On Wed, Dec 02, 2015 at 12:18:00PM -0500, Wesley Eddy wrote:

You're correct that us initially proposing to use floating-point was done only really for consistency with existing use of floating-point
in traffic-rate per RFC 5575.=C2=A0 I do not know the rationale for why
it was chosen there, but assume it's because of the wider range of
values that can be encoded compared to using a simple 32-bit
unsigned integer.

One general headache of 4-byte floating point numbers is that when you star= t
losing precision, you can have weird discrepancies between what you
configure, vs. what value can be encoded.=C2=A0 This is one of the reasons = why
floating point on the wire is annoying.

Can anyone who was around at the time help to understand why floatin= g-point was specified in RFC 5575 for traffic-rate?

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

--047d7b450a6836e4060525f1b4d4-- From nobody Wed Dec 2 15:23:09 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B8ED1A1A6A for ; Wed, 2 Dec 2015 15:23:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rQUw-MBV0Rkk for ; Wed, 2 Dec 2015 15:23:06 -0800 (PST) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 462931A9037 for ; Wed, 2 Dec 2015 15:23:06 -0800 (PST) Received: by oige206 with SMTP id e206so36110177oig.2 for ; Wed, 02 Dec 2015 15:23:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=flowtools-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type; bh=pT6S1kG6H61ER2Fw1iza5VV56G61QWv9TRHLybFW0y0=; b=ZCuV+KW+xuo2TKhGBYxwi8ljCinKyVYMtJVWDqJEF6YExL3IvjA/NXR22/2c4XBdME 421xqSUBZ0uFu6cCqu41jJPPgOLXnkIVGDL1RJ3wlvMyHtVDC1IKwVwZvOuhsoPweC0a XxjE741zaSVgjJng1B7nb789HS4gbZlNyT60OdZCATZOjteiv5LkVXucaxSWY+dh581n gvTLSqZnrwUQ/I515T4eH8LO5YOk8CXlEKRGxS1sUe8lqZG6rRj1DEzF7vKgVW9qfURL NPVxdcIKYsU6MJ1pSkH/DjxCQgTImiS2ABOGl1Kx2thGCWqTl7yrCMO8vv4nHfZ19w2p D2CA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type; bh=pT6S1kG6H61ER2Fw1iza5VV56G61QWv9TRHLybFW0y0=; b=J5ML3hM9Ezv2bsUuoNwTRJplAA++EB98Kj1XhsthPYPROrsW2Bnv4JpW0IgH+k++fS 5szESTD7dLEMt9lxS1WCPWAVxgXg8aagq2OvHXrT/NjblsolwPyAF5rqjWOugrPWcvJw fmqeZMGwQDY3s31y3eNikkJ9CBz8AIQAl6VnqIEfreD/ANVzrUGjfzZOAjZCorNtAJ1d YuodMEvLnn7+339vUo8s5RTIduoGfcjbHDhgK0C8F2P3oGb8gQXE+7L/iIAiJwX56pDa V5wAaATwqEUmuFTKXgsTHUTehY36Z+LQ7KTYq1MaWCJIXMUoB7uh+CAEk8g3vwvt16Ug HN5A== X-Gm-Message-State: ALoCoQncGdxrtvfKSa21pnzzYkTfwzYLZ1/lMwoi5aWhWGAf6A2150vOjHZZt/sgCpo5Nb9W8nCp X-Received: by 10.202.51.138 with SMTP id z132mr5133862oiz.39.1449098585309; Wed, 02 Dec 2015 15:23:05 -0800 (PST) Received: from [205.169.63.165] ([205.169.63.165]) by smtp.googlemail.com with ESMTPSA id i8sm2319607obt.3.2015.12.02.15.23.04 for (version=TLSv1/SSLv3 cipher=OTHER); Wed, 02 Dec 2015 15:23:04 -0800 (PST) To: idr@ietf.org References:

From: John Schiel Message-ID: <565F7D58.1000700@flowtools.net> Date: Wed, 2 Dec 2015 16:23:04 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------010106040608050107050501" Archived-At: Subject: Re: [Idr] packet-rate action for flowspec X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2015 23:23:08 -0000 This is a multi-part message in MIME format. --------------010106040608050107050501 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 12/02/2015 03:22 PM, Robert Raszuk wrote: > Aseem, > > If I understand your point you are suggesting to change the unit from > bytes per sec to packets per sec. If so this is IMHO pretty bad idea > for the shipping RFC in number of implementations as the proposed > change is not backwards compatible and will just cause significant > deployment mess in those cases where traffic-rate ext community is > actually being used. > > However you/WG may suggest and standardize new extended community with > pps unit of measurement if there would be rough consensu to do so > though. But the time for comments on existing specification seems a > bit too late. Robert, Wes has submitted a new draft to handle a new extended community for pps, https://tools.ietf.org/html/draft-eddy-idr-flowspec-packet-rate-00, thus the discussion on the data type. > Cheers, > R. > > > > On Wed, Dec 2, 2015 at 11:02 PM, Aseem Choudhary (asechoud) > > wrote: > > IMHO, this is not the case with PPS (packets per sec). Assuming > all packets of 64 bytes, this translates to 512 bits per packet. > We have 9 bits to save and hence 4-byte integer will be fine > without floating-point. It saves much more as we consider higher > average packet size. Besides, typically pps will not count till > billions of packets, especially for flowspec, as it is > counter-productive. I suggest a 4-bytes integer is just fine for pps. > I agree with this statement. --John --------------010106040608050107050501 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

On 12/02/2015 03:22 PM, Robert Raszuk wrote:

Aseem,

If I understand your point you are suggesting to change the unit from bytes per sec to packets per sec. If so this is IMHO pretty bad idea for the shipping RFC in number of implementations as the proposed change is not backwards compatible and will just cause significant deployment mess in those cases where traffic-rate ext community is actually being used.�

However you/WG may suggest and standardize new extended community with pps unit of measurement if there would be rough consensu to do so though. But the time for comments on existing specification seems a bit too late.

Robert,

�� Wes has submitted a new draft to handle a new extended community for pps,� https://tools.ietf.org/html/draft-eddy-idr-flowspec-packet-rate-00, thus the discussion on the data type.

Cheers,
R.

On Wed, Dec 2, 2015 at 11:02 PM, Aseem Choudhary (asechoud) <asechoud@cisco.com> wrote:

IMHO, this is not the case with PPS (packets per sec). Assuming all packets of 64 bytes, this translates to 512 bits per packet. We have 9 bits to save and hence 4-byte integer will be fine without floating-point. It saves much more as we consider higher average packet size. Besides, typically pps will not count till billions of packets, especially for flowspec, as it is counter-productive. I suggest a 4-bytes integer is just fine for pps.

I agree with this statement.

--John

--------------010106040608050107050501-- From nobody Wed Dec 2 15:34:08 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 773C71ACE13 for ; Wed, 2 Dec 2015 15:34:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id stAh1m8FkAIW for ; Wed, 2 Dec 2015 15:34:06 -0800 (PST) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C5601ACDE0 for ; Wed, 2 Dec 2015 15:34:06 -0800 (PST) Received: by wmww144 with SMTP id w144so235896245wmw.1 for ; Wed, 02 Dec 2015 15:34:04 -0800 (PST) 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=BbTfhtGSjJQ2koBld19MsRSaPzubEDJAI36wuhYFF0s=; b=BwvddonTKPGbtJrxK7ENWsoATnLhAnDnVClGIOA4tjR2JBoV44lSi6UAmUKn4TiboH s2LC/bD9pbtyNOBacC/DWQcZkzCXJEmJeD1bDUL4OeyajE64eH5C69YeAz3no5PuR6Sm m83hgBQI0xAfpdi7NPaaFkIEXOaELB5Rgw2t3KYaru+ZYeuI1TZB2l73+tyG1DgsNIsb usURWYIjjmqdLyX323pcMe8mORANLka2WnRRlVoYUEzigFAEOrc60Mp5vUoWRu5R5Ylx 76Sx3Yeo5djDIQr+dloNi+IIoQvrK6uxuYuJJEEWIeRi9uIjHqtwnDMP1SPkuDEf2gtN DNog== MIME-Version: 1.0 X-Received: by 10.194.236.6 with SMTP id uq6mr7605168wjc.126.1449099244583; Wed, 02 Dec 2015 15:34:04 -0800 (PST) Sender: rraszuk@gmail.com Received: by 10.194.204.195 with HTTP; Wed, 2 Dec 2015 15:34:04 -0800 (PST) In-Reply-To: <565F7D58.1000700@flowtools.net> References:

<565F7D58.1000700@flowtools.net> Date: Thu, 3 Dec 2015 00:34:04 +0100 X-Google-Sender-Auth: u9jFkPd12U2npdh1mV9OB153Euc Message-ID: From: Robert Raszuk To: John Schiel Content-Type: multipart/alternative; boundary=089e01493e2cb7c55b0525f2b536 Archived-At: Cc: idr wg Subject: Re: [Idr] packet-rate action for flowspec X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2015 23:34:07 -0000 --089e01493e2cb7c55b0525f2b536 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable John, Robert, > > Wes has submitted a new draft to handle a new extended community for > pps, https://tools.ietf.org/html/draft-eddy-idr-flowspec-packet-rate-00, > thus > the discussion on the data type. > =E2=80=8BYes I am aware of that hence my second paragraph. Aseem however sounded like new proposal defining "packet-rate" should be a replacement of existing "traffic-rate". On the other hand if the new packet rate is added as new ext comm type then Jeff's point stands what actions should be done when both are present in the update message. The above draft should clearly define it but as far as I can tell it does not. R. =E2=80=8B --089e01493e2cb7c55b0525f2b536 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

John,

Robert,

=C2=A0=C2=A0=C2=A0 Wes has submitted a new draft to handle a new extend= ed community for pps,=C2=A0 https://tools.ietf.org/html/draft-= eddy-idr-flowspec-packet-rate-00, thus the discussion on the data type.

=E2=80=8BYes I am aware of that hence my second= paragraph.=C2=A0

Asee= m however sounded like new proposal defining "packet-rate" should= be a replacement of existing "traffic-rate".

On the other hand if the new packet rate = is added as new ext comm type then Jeff's point stands what actions sho= uld be done when both are present in the update message. The above draft sh= ould clearly define it but as far as I can tell it does not.=C2=A0

=E2=80=8B

<= /div>

--089e01493e2cb7c55b0525f2b536-- From nobody Wed Dec 2 15:50:59 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 035211B2B74 for ; Wed, 2 Dec 2015 15:50:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RMvy_raQ4Stg for ; Wed, 2 Dec 2015 15:50:56 -0800 (PST) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F1C71B2A74 for ; Wed, 2 Dec 2015 15:50:56 -0800 (PST) Received: by oies6 with SMTP id s6so36846289oie.1 for ; Wed, 02 Dec 2015 15:50:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=flowtools-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type; bh=nBWqhJJ6f9L75rlDeEUQOLI+ksakkj1AoE/havel0CA=; b=p87Lm8ZWmUDPRn7hJsZ2HUYdnqxqsCQl1AU+bz/ZpyqsxF0KnVRZZB6F+Ay3kfV95m lIOtR0VUoukiJ8lCLwO2CFmW7HS5WkNwKPFwe/OnuTNygPJgOzVqQuUFVvxdw3zpeFia UFVHlAZxOVoWzQwQFll9JaaaQMt4rILpmJNLQiVuVG/dkqL+78KKBNstEFhq+CevBu0T 0/JCcr/LAs/EG8uk7IyWu4Vb5tDoCo/M23yrtB3PJst7lVEQ9NtRrWhkq5jtAgbExTu5 15QGgVZc1H+OViHonFFIjyuVPzmw34bfCt07Gq83LdfaTpIOyjhs/TnaDS4/ZY519KGE 21YA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type; bh=nBWqhJJ6f9L75rlDeEUQOLI+ksakkj1AoE/havel0CA=; b=M341JD3/iQ2O0LrimeSa+Q+oVTgtwJ8xps68yQdLzVox8EmoWZ84G+Z8OAibbV9zo/ eY1tJEyNXoKQovDSJotCNTVyBuq4aXGC9PuLQxdgaDd1KNr1fG6+2W6+MReXuE3lReV9 Nznxstz894tMvG8D31TvF8oBAwo0qeAf20TW6TfePHnHFFBjhCZhtGEyadwYXADujhrc uICsHpSBJNiNoTWTPNKVELsg8R5FjDvggTyBz+gTropaNBCQqITWDss0ZGFAyzEbsRsw 74jM2YgsISg6S5gnp8PdgiWiPPVY+hJWl5nSWiVPHKbmMfJIJI/PNVBTRR4uamkxElnc U7/Q== X-Gm-Message-State: ALoCoQnzwofDf3VCkuFDYIMhdGesbFfZaJFjDmnvtZ5kbc7U60PbJf/XC5qDVtnPi5fOXEcDmFpE X-Received: by 10.202.89.84 with SMTP id n81mr5309760oib.64.1449100255744; Wed, 02 Dec 2015 15:50:55 -0800 (PST) Received: from [205.169.63.165] ([205.169.63.165]) by smtp.googlemail.com with ESMTPSA id wr6sm2336395obb.21.2015.12.02.15.50.55 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 02 Dec 2015 15:50:55 -0800 (PST) To: Robert Raszuk References:

<565F7D58.1000700@flowtools.net> From: John Schiel Message-ID: <565F83DE.4040009@flowtools.net> Date: Wed, 2 Dec 2015 16:50:54 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------050605020005020601010305" Archived-At: Cc: idr wg Subject: Re: [Idr] packet-rate action for flowspec X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2015 23:50:58 -0000 This is a multi-part message in MIME format. --------------050605020005020601010305 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 12/02/2015 04:34 PM, Robert Raszuk wrote: > John, > > Robert, > > Wes has submitted a new draft to handle a new extended > community for pps, > https://tools.ietf.org/html/draft-eddy-idr-flowspec-packet-rate-00, thus > the discussion on the data type. > > > Yes I am aware of that hence my second paragraph. My apologies. > > Aseem however sounded like new proposal defining "packet-rate" should > be a replacement of existing "traffic-rate". Understand. > > On the other hand if the new packet rate is added as new ext comm type > then Jeff's point stands what actions should be done when both are > present in the update message. The above draft should clearly define > it but as far as I can tell it does not. I missed where that was mentioned but regardless, I agree this should be defined. I propose traffic-rate and packet-rate be mutually exclusive. If both are allowed at the same time, then you have to be concerned with which one takes priority, error handling, resource contention and a whole host of other issues I could probably name. Remove all doubt and don't allow both traffic-rate and packet-rate to come across at the same time. --John > > R. > > > > --------------050605020005020601010305 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 12/02/2015 04:34 PM, Robert Raszuk wrote:

John,

Robert,

Wes has submitted a new draft to handle a new extended community for pps, https://tools.ietf.org/html/draft-eddy-idr-flowspec-packet-rate-00, thus the discussion on the data type.

Yes I am aware of that hence my second paragraph.

My apologies.

Aseem however sounded like new proposal defining "packet-rate" should be a replacement of existing "traffic-rate".

Understand.

On the other hand if the new packet rate is added as new ext comm type then Jeff's point stands what actions should be done when both are present in the update message. The above draft should clearly define it but as far as I can tell it does not.

I missed where that was mentioned but regardless, I agree this should be defined.

I propose traffic-rate and packet-rate be mutually exclusive. If both are allowed at the same time, then you have to be concerned with which one takes priority, error handling, resource contention and a whole host of other issues I could probably name. Remove all doubt and don't allow both traffic-rate and packet-rate to come across at the same time.

--John

R.

--------------050605020005020601010305-- From nobody Wed Dec 2 16:59:53 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 458081AD368 for ; Wed, 2 Dec 2015 16:59:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PokjLmuF2EgE for ; Wed, 2 Dec 2015 16:59:50 -0800 (PST) Received: from atl4mhob11.myregisteredsite.com (atl4mhob11.myregisteredsite.com [209.17.115.49]) by ietfa.amsl.com (Postfix) with ESMTP id B56FD1AD366 for ; Wed, 2 Dec 2015 16:59:49 -0800 (PST) Received: from mailpod.hostingplatform.com ([10.30.71.208]) by atl4mhob11.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id tB30xmOe016374 for ; Wed, 2 Dec 2015 19:59:48 -0500 Received: (qmail 4929 invoked by uid 0); 3 Dec 2015 00:59:48 -0000 X-TCPREMOTEIP: 69.81.157.131 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?192.168.1.105?) (wes@mti-systems.com@69.81.157.131) by 0 with ESMTPA; 3 Dec 2015 00:59:48 -0000 To: idr@ietf.org References:

<565F7D58.1000700@flowtools.net> <565F83DE.4040009@flowtools.net> From: Wesley Eddy Message-ID: <565F9400.6060003@mti-systems.com> Date: Wed, 2 Dec 2015 19:59:44 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <565F83DE.4040009@flowtools.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Idr] packet-rate action for flowspec X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2015 00:59:51 -0000 On 12/2/2015 6:50 PM, John Schiel wrote: > > I propose traffic-rate and packet-rate be mutually exclusive. If both > are allowed at the same time, then you have to be concerned with which > one takes priority, error handling, resource contention and a whole > host of other issues I could probably name. Remove all doubt and > don't allow both traffic-rate and packet-rate to come across at the > same time. > In RFC-speak, we can probably just say that they SHOULD NOT be used together due to unclear semantics. Implementations will need to be robust to receiving both at the same time (i.e. not crash, break the session, etc), and they can choose to do something reasonable but implementation-specific (e.g. pick one or the other). In this sense, I think it is similar to other strange combinations of actions that could be sent. From nobody Wed Dec 2 17:47:57 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27BB41B2B20 for ; Wed, 2 Dec 2015 17:47:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.344 X-Spam-Level: X-Spam-Status: No, score=-12.344 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FF_IHOPE_YOU_SINK=2.166, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QuBHecZofuBk for ; Wed, 2 Dec 2015 17:47:53 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0D001B2B19 for ; Wed, 2 Dec 2015 17:47:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13348; q=dns/txt; s=iport; t=1449107272; x=1450316872; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=2OXSagXMpo6lWNst9//CE72FikpW7bfr0a0PUXFt+Bs=; b=A3HRKvrBXVOQhRHrAZSyCZFkvpM6XdRIVimNG+kf3N54nYjzxON/2nZI IYcEOiRwrgs+gT8Qrg4OGS0K1ymLc/cZDcIhb3VS0fVHIgtEhOQGCP5Wg UO0ELAGaLIeqOrsqS6yqvcm7iyQGT4gjsSiSyW6YtW3ZtbYEa65DJoL4K Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DzAQCJnl9W/40NJK1eGQEBAQEPAQEBA?= =?us-ascii?q?YI+TFNuBr4PAQ2BWwcXAQmFbQKBRjgUAQEBAQEBAYEKhDQBAQEBAwEBAWsLEgE?= =?us-ascii?q?IEQMBAiguCxQJCAIEDgUUiBsNwCQBAQEBAQEBAQEBAQEBAQEBAQEBARUEhlSEf?= =?us-ascii?q?YR7DYQzBYdRjw4BhSuIDoFblyCDcQEfAQFCgg4ggVZyhGWBBwEBAQ?= X-IronPort-AV: E=Sophos; i="5.20,375,1444694400"; d="scan'208,217"; a="52143146" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Dec 2015 01:47:51 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id tB31lp2R030503 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 3 Dec 2015 01:47:51 GMT Received: from xch-rcd-004.cisco.com (173.37.102.14) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 2 Dec 2015 19:47:51 -0600 Received: from xch-rcd-004.cisco.com ([173.37.102.14]) by XCH-RCD-004.cisco.com ([173.37.102.14]) with mapi id 15.00.1104.000; Wed, 2 Dec 2015 19:47:51 -0600 From: "Aseem Choudhary (asechoud)" To: Robert Raszuk Thread-Topic: [Idr] packet-rate action for flowspec Thread-Index: AQHRJmEsvphvqx+c7keAIR9OGHnREJ6re4qAgAs+KgD//4OHAIACHOmAgAAIeACAABozAIAACXqAgAAfCQD//4aJAIAAi7YA//+zXYA= Date: Thu, 3 Dec 2015 01:47:51 +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.2.3.120616 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.60.133] Content-Type: multipart/alternative; boundary="_000_D284DE7DF85CAasechoudciscocom_" MIME-Version: 1.0 Archived-At: Cc: idr wg Subject: Re: [Idr] packet-rate action for flowspec X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2015 01:47:55 -0000 --_000_D284DE7DF85CAasechoudciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Robert, My comments were regarding discussion on the draft (original thread): https://tools.ietf.org/html/draft-eddy-idr-flowspec-packet-rate-00 -thanks, Aseem From: Robert Raszuk > Date: Wednesday, December 2, 2015 at 2:22 PM To: Cisco Employee > Cc: Wesley Eddy >, idr wg <= idr@ietf.org> Subject: Re: [Idr] packet-rate action for flowspec Aseem, If I understand your point you are suggesting to change the unit from bytes= per sec to packets per sec. If so this is IMHO pretty bad idea for the shi= pping RFC in number of implementations as the proposed change is not backwa= rds compatible and will just cause significant deployment mess in those cas= es where traffic-rate ext community is actually being used. However you/WG may suggest and standardize new extended community with pps = unit of measurement if there would be rough consensu to do so though. But t= he time for comments on existing specification seems a bit too late. Cheers, R. On Wed, Dec 2, 2015 at 11:02 PM, Aseem Choudhary (asechoud) > wrote: IMHO, this is not the case with PPS (packets per sec). Assuming all packets= of 64 bytes, this translates to 512 bits per packet. We have 9 bits to sav= e and hence 4-byte integer will be fine without floating-point. It saves mu= ch more as we consider higher average packet size. Besides, typically pps w= ill not count till billions of packets, especially for flowspec, as it is c= ounter-productive. I suggest a 4-bytes integer is just fine for pps. -thanks, Aseem From: Robert Raszuk > Date: Wednesday, December 2, 2015 at 1:16 PM To: Wesley Eddy > Cc: idr wg > Subject: Re: [Idr] packet-rate action for flowspec Wesley, The only reason to use floating notation as I recall was to express various= traffic rates with single 4 octets. IEEE.754 was just as good format as an= y other with an advantge of being implemented by some vendors already. Otherwise if we would take say integer we would likely need 4 octets for by= tes/s, 4 octets for kbytes/s, 4 octets for Mbytes/s and 4 octets in Gbytes/= s etc.. And who knows what traffic rates will be tomorrow .... Best, r. On Wed, Dec 2, 2015 at 8:25 PM, Wesley Eddy > wrote: On 12/2/2015 1:51 PM, Jeffrey Haas wrote: Wes, On Wed, Dec 02, 2015 at 12:18:00PM -0500, Wesley Eddy wrote: You're correct that us initially proposing to use floating-point was done only really for consistency with existing use of floating-point in traffic-rate per RFC 5575. I do not know the rationale for why it was chosen there, but assume it's because of the wider range of values that can be encoded compared to using a simple 32-bit unsigned integer. One general headache of 4-byte floating point numbers is that when you star= t losing precision, you can have weird discrepancies between what you configure, vs. what value can be encoded. This is one of the reasons why floating point on the wire is annoying. Can anyone who was around at the time help to understand why floating-point= was specified in RFC 5575 for traffic-rate? _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr --_000_D284DE7DF85CAasechoudciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable

Hi Robert,

My comments were regarding= discussion on the draft (original thread):

https://tools.ietf.org/html/draft-eddy-idr-fl= owspec-packet-rate-00

-thanks,

Aseem

From: Robert Raszuk <robert@raszuk.net>
Date: Wednesday, December 2, 2015 a= t 2:22 PM
To: Cisco Employee <asechoud@cisco.com>
Cc: Wesley Eddy <wes@mti-systems.com>, idr wg <idr@ietf.org>
Subject: Re: [Idr] packet-rate acti= on for flowspec

Aseem,

If I understand your point you are suggesting to change the unit from bytes= per sec to packets per sec. If so this is IMHO pretty bad idea for the shi= pping RFC in number of implementations as the proposed change is not backwa= rds compatible and will just cause significant deployment mess in those cases where traffic-rate ext communit= y is actually being used.

However you/WG may suggest and standardize new extended community with pps = unit of measurement if there would be rough consensu to do so though. But t= he time for comments on existing specification seems a bit too late.

Cheers,
R.

On Wed, Dec 2, 2015 at 11:02 PM, Aseem Choudhary= (asechoud) <asechoud@cisco.com> wrote:

IMHO, this is not the case with PPS (packets per sec). Assuming all pa= ckets of 64 bytes, this translates to 512 bits per packet. We have 9 bits t= o save and hence 4-byte integer will be fine without floating-point. It sav= es much more as we consider higher average packet size. Besides, typically pps will not count till billions o= f packets, especially for flowspec, as it is counter-productive. I suggest = a 4-bytes integer is just fine for pps.

-thanks,

Aseem

From: Robert Raszuk <robert@raszuk.net>
Date: Wednesday, December 2, 2015 a= t 1:16 PM
To: Wesley Eddy <wes@mti-systems.com>
Cc: idr wg <idr@ietf.org>
Subject: Re: [Idr] packet-rate acti= on for flowspec

Wesley,

The only reason to use floating notation as I recall was to express various= traffic rates with single 4 octets. IEEE.754 was just as good format as an= y other with an advantge of being implemented by some vendors already.

Otherwise if we would take say integer we would likely need 4 octets for by= tes/s, 4 octets for kbytes/s, 4 octets for Mbytes/s and 4 octets in Gbytes/= s etc.. And who knows what traffic rates will be tomorrow ....

Best,

r.

On Wed, Dec 2, 2015 at 8:25 PM, Wesley Eddy <wes@mti-system= s.com> wrote:

On 12/2/2015 1:51 PM, Jeffrey Haas wrote:

Wes,

On Wed, Dec 02, 2015 at 12:18:00PM -0500, Wesley Eddy wrote:

You're correct that us initially proposing to use floating-point was
done only really for consistency with existing use of floating-point
in traffic-rate per RFC 5575. I do not know the rationale for why
it was chosen there, but assume it's because of the wider range of
values that can be encoded compared to using a simple 32-bit
unsigned integer.

One general headache of 4-byte floating point numbers is that when you star= t
losing precision, you can have weird discrepancies between what you
configure, vs. what value can be encoded. This is one of the reasons = why
floating point on the wire is annoying.

Can anyone who was around at the time help to understand why floatin= g-point was specified in RFC 5575 for traffic-rate?

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

--_000_D284DE7DF85CAasechoudciscocom_-- From nobody Wed Dec 2 17:59:15 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 595161B2B87 for ; Wed, 2 Dec 2015 17:59:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xh6DrX--rfVH for ; Wed, 2 Dec 2015 17:59:12 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8FCC1B2B86 for ; Wed, 2 Dec 2015 17:59:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7147; q=dns/txt; s=iport; t=1449107952; x=1450317552; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=Usc82OuVh7+9MtN/tT3Sq8Eob6Xs9EIsR330KPcUix0=; b=DAKAxw/i4zBvDsfksQuj/UuHY/sAD5rDguxOFP0XkUL3b4FK/Ex1i66M 0HerrLRtzdgJuAJ7pRdY+07z65HDcOFlbT2CVYklo9uNMhsnay3lTIJtX +rglH4RSkUmZ9rrD7vmmVNDnQrzw9g77j57Swn0jRzidGbGdDFoxtHUKB g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DyAQB+oV9W/4UNJK1eGQEBAQEPAQEBA?= =?us-ascii?q?YI+TFNuBr4PAQ2BYiGFbQIcgSo4FAEBAQEBAQGBCoQ0AQIBAyNWEgEIEQMBAig?= =?us-ascii?q?DAgQwFAkIAgQBDQUUiBsNryaRHQEBAQEBAQEBAQEBAQEBAQEBAQEBARQEhlSEf?= =?us-ascii?q?YR7DYJvgUQFll8BhSuIDoFbkjaIWwEfAQFChARyhGWBBwEBAQ?= X-IronPort-AV: E=Sophos; i="5.20,375,1444694400"; d="scan'208,217"; a="54967281" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Dec 2015 01:59:11 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id tB31xBTt001648 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 3 Dec 2015 01:59:11 GMT Received: from xch-rcd-004.cisco.com (173.37.102.14) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 2 Dec 2015 19:59:10 -0600 Received: from xch-rcd-004.cisco.com ([173.37.102.14]) by XCH-RCD-004.cisco.com ([173.37.102.14]) with mapi id 15.00.1104.000; Wed, 2 Dec 2015 19:59:11 -0600 From: "Aseem Choudhary (asechoud)" To: Robert Raszuk , John Schiel Thread-Topic: [Idr] packet-rate action for flowspec Thread-Index: AQHRJmEsvphvqx+c7keAIR9OGHnREJ6re4qAgAs+KgD//4OHAIACHOmAgAAIeACAABozAIAACXqAgAAfCQD//4aJAIAAi7YAgAARCwCAAAMTAP//om4A Date: Thu, 3 Dec 2015 01:59:10 +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.2.3.120616 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.60.133] Content-Type: multipart/alternative; boundary="_000_D284E151F85DCasechoudciscocom_" MIME-Version: 1.0 Archived-At: Cc: idr wg Subject: Re: [Idr] packet-rate action for flowspec X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2015 01:59:14 -0000 --_000_D284E151F85DCasechoudciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUm9iZXJ0LA0KDQpBcG9sb2dpZXMgaWYgSSBzb3VuZGVkIGxpa2UgdGhhdC4gRXZlbnRob3Vn aCwgaXQgd2lsbCBzaW1wbGlmeSB0byBoYXZlIHVuaXQsIGJ1dCBJIGFncmVlIGl0IGlzIHRvbyBs YXRlLg0KDQotdGhhbmtzLA0KQXNlZW0NCg0KRnJvbTogUm9iZXJ0IFJhc3p1ayA8cm9iZXJ0QHJh c3p1ay5uZXQ8bWFpbHRvOnJvYmVydEByYXN6dWsubmV0Pj4NCkRhdGU6IFdlZG5lc2RheSwgRGVj ZW1iZXIgMiwgMjAxNSBhdCAzOjM0IFBNDQpUbzogSm9obiBTY2hpZWwgPGpzY2hpZWxAZmxvd3Rv b2xzLm5ldDxtYWlsdG86anNjaGllbEBmbG93dG9vbHMubmV0Pj4NCkNjOiBpZHIgd2cgPGlkckBp ZXRmLm9yZzxtYWlsdG86aWRyQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbSWRyXSBwYWNrZXQt cmF0ZSBhY3Rpb24gZm9yIGZsb3dzcGVjDQoNCkpvaG4sDQoNClJvYmVydCwNCg0KICAgIFdlcyBo YXMgc3VibWl0dGVkIGEgbmV3IGRyYWZ0IHRvIGhhbmRsZSBhIG5ldyBleHRlbmRlZCBjb21tdW5p dHkgZm9yIHBwcywgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1lZGR5LWlkci1m bG93c3BlYy1wYWNrZXQtcmF0ZS0wMCwgPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1lZGR5LWlkci1mbG93c3BlYy1wYWNrZXQtcmF0ZS0wMD4gdGh1cyB0aGUgZGlzY3Vzc2lvbiBv biB0aGUgZGF0YSB0eXBlLg0KDQrigItZZXMgSSBhbSBhd2FyZSBvZiB0aGF0IGhlbmNlIG15IHNl Y29uZCBwYXJhZ3JhcGguDQoNCkFzZWVtIGhvd2V2ZXIgc291bmRlZCBsaWtlIG5ldyBwcm9wb3Nh bCBkZWZpbmluZyAicGFja2V0LXJhdGUiIHNob3VsZCBiZSBhIHJlcGxhY2VtZW50IG9mIGV4aXN0 aW5nICJ0cmFmZmljLXJhdGUiLg0KDQpPbiB0aGUgb3RoZXIgaGFuZCBpZiB0aGUgbmV3IHBhY2tl dCByYXRlIGlzIGFkZGVkIGFzIG5ldyBleHQgY29tbSB0eXBlIHRoZW4gSmVmZidzIHBvaW50IHN0 YW5kcyB3aGF0IGFjdGlvbnMgc2hvdWxkIGJlIGRvbmUgd2hlbiBib3RoIGFyZSBwcmVzZW50IGlu IHRoZSB1cGRhdGUgbWVzc2FnZS4gVGhlIGFib3ZlIGRyYWZ0IHNob3VsZCBjbGVhcmx5IGRlZmlu ZSBpdCBidXQgYXMgZmFyIGFzIEkgY2FuIHRlbGwgaXQgZG9lcyBub3QuDQoNClIuDQoNCg0K4oCL DQoNCg== --_000_D284E151F85DCasechoudciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <1B4A5659074EAC45B374DAD8CD80A336@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5IaSBSb2JlcnQs PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5BcG9sb2dpZXMgaWYgSSBzb3VuZGVkIGxp a2UgdGhhdC4gRXZlbnRob3VnaCwgaXQgd2lsbCBzaW1wbGlmeSB0byBoYXZlIHVuaXQsIGJ1dCBJ IGFncmVlIGl0IGlzIHRvbyBsYXRlLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+LXRo YW5rcyw8L2Rpdj4NCjxkaXY+QXNlZW08L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBp ZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJy aTsgZm9udC1zaXplOjExcHQ7IHRleHQtYWxpZ246bGVmdDsgY29sb3I6YmxhY2s7IEJPUkRFUi1C T1RUT006IG1lZGl1bSBub25lOyBCT1JERVItTEVGVDogbWVkaXVtIG5vbmU7IFBBRERJTkctQk9U VE9NOiAwaW47IFBBRERJTkctTEVGVDogMGluOyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRFUi1U T1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBCT1JERVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5H LVRPUDogM3B0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5Gcm9tOiA8L3NwYW4+ Um9iZXJ0IFJhc3p1ayAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJvYmVydEByYXN6dWsubmV0Ij5yb2Jl cnRAcmFzenVrLm5ldDwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQi PkRhdGU6IDwvc3Bhbj5XZWRuZXNkYXksIERlY2VtYmVyIDIsIDIwMTUgYXQgMzozNCBQTTxicj4N CjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5UbzogPC9zcGFuPkpvaG4gU2NoaWVsICZs dDs8YSBocmVmPSJtYWlsdG86anNjaGllbEBmbG93dG9vbHMubmV0Ij5qc2NoaWVsQGZsb3d0b29s cy5uZXQ8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5DYzogPC9z cGFuPmlkciB3ZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlkckBpZXRmLm9yZyI+aWRyQGlldGYub3Jn PC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDogPC9z cGFuPlJlOiBbSWRyXSBwYWNrZXQtcmF0ZSBhY3Rpb24gZm9yIGZsb3dzcGVjPGJyPg0KPC9kaXY+ DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2IGRpcj0ibHRyIj4NCjxkaXYg Y2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Es c2Fucy1zZXJpZjtmb250LXNpemU6c21hbGwiPg0KSm9obiw8L2Rpdj4NCjxkaXYgY2xhc3M9Imdt YWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJp Zjtmb250LXNpemU6c21hbGwiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRy YSI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxf cXVvdGUiIHN0eWxlPSJtYXJnaW46MHB4IDBweCAwcHggMC44ZXg7Ym9yZGVyLWxlZnQtd2lkdGg6 MXB4O2JvcmRlci1sZWZ0LWNvbG9yOnJnYigyMDQsMjA0LDIwNCk7Ym9yZGVyLWxlZnQtc3R5bGU6 c29saWQ7cGFkZGluZy1sZWZ0OjFleCI+DQo8ZGl2IGJnY29sb3I9IiNGRkZGRkYiIHRleHQ9IiMw MDAwMDAiPlJvYmVydCw8YnI+DQo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgV2VzIGhhcyBzdWJt aXR0ZWQgYSBuZXcgZHJhZnQgdG8gaGFuZGxlIGEgbmV3IGV4dGVuZGVkIGNvbW11bml0eSBmb3Ig cHBzLCZuYnNwOyA8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZWRk eS1pZHItZmxvd3NwZWMtcGFja2V0LXJhdGUtMDAiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1lZGR5LWlkci1mbG93c3BlYy1wYWNrZXQtcmF0ZS0w MCwgPC9hPnRodXMgdGhlIGRpc2N1c3Npb24gb24gdGhlIGRhdGEgdHlwZS48L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVm YXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmO2ZvbnQt c2l6ZTpzbWFsbCI+DQrigItZZXMgSSBhbSBhd2FyZSBvZiB0aGF0IGhlbmNlIG15IHNlY29uZCBw YXJhZ3JhcGguJm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0i Zm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsIj4N Cjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFt aWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+DQpBc2VlbSBo b3dldmVyIHNvdW5kZWQgbGlrZSBuZXcgcHJvcG9zYWwgZGVmaW5pbmcgJnF1b3Q7cGFja2V0LXJh dGUmcXVvdDsgc2hvdWxkIGJlIGEgcmVwbGFjZW1lbnQgb2YgZXhpc3RpbmcgJnF1b3Q7dHJhZmZp Yy1yYXRlJnF1b3Q7LjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZv bnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+DQo8 YnI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWls eTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGwiPg0KT24gdGhlIG90 aGVyIGhhbmQgaWYgdGhlIG5ldyBwYWNrZXQgcmF0ZSBpcyBhZGRlZCBhcyBuZXcgZXh0IGNvbW0g dHlwZSB0aGVuIEplZmYncyBwb2ludCBzdGFuZHMgd2hhdCBhY3Rpb25zIHNob3VsZCBiZSBkb25l IHdoZW4gYm90aCBhcmUgcHJlc2VudCBpbiB0aGUgdXBkYXRlIG1lc3NhZ2UuIFRoZSBhYm92ZSBk cmFmdCBzaG91bGQgY2xlYXJseSBkZWZpbmUgaXQgYnV0IGFzIGZhciBhcyBJIGNhbiB0ZWxsIGl0 IGRvZXMgbm90LiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9 ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+ DQo8YnI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZh bWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGwiPg0KUi48L2Rp dj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxo ZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGwiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2 IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNh LHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsIj4NCjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i Z21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNl cmlmO2ZvbnQtc2l6ZTpzbWFsbCI+DQrigIs8L2Rpdj4NCjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvc3Bhbj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_D284E151F85DCasechoudciscocom_-- From nobody Thu Dec 3 05:18:35 2015 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 23C951A70E1; Thu, 3 Dec 2015 05:18:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151203131834.17895.89453.idtracker@ietfa.amsl.com> Date: Thu, 03 Dec 2015 05:18:34 -0800 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-te-lsp-distribution-04.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2015 13:18:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Distribution of MPLS Traffic Engineering (TE) LSP State using BGP Authors : Jie Dong Mach(Guoyi) Chen Hannes Gredler Stefano Previdi Jeff Tantsura Filename : draft-ietf-idr-te-lsp-distribution-04.txt Pages : 17 Date : 2015-12-03 Abstract: This document describes a mechanism to collect the Traffic Engineering (TE) LSP information using BGP. Such information can be used by external components for path reoptimization, service placement, and network visualization. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-te-lsp-distribution/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-te-lsp-distribution-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-te-lsp-distribution-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 nobody Thu Dec 3 08:16:19 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEEBE1A88C8 for ; Thu, 3 Dec 2015 08:16:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nqNwrwMfIjHP for ; Thu, 3 Dec 2015 08:16:12 -0800 (PST) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 787721A00F1 for ; Thu, 3 Dec 2015 08:16:12 -0800 (PST) Received: by pfnn128 with SMTP id n128so10670772pfn.0 for ; Thu, 03 Dec 2015 08:16:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=flowtools-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=kQBUMNB8UQzoWUiYIdyamWEw8RiB+Yd//sYQM9kEiv0=; b=ubSNOYuAJWDY/4zqYXvErwocfe2YiiCOvUt18wvu043mDccsqAk9g8c42vpyvGKwM5 Sdj9ITjJyvYjXRRYmNhqzvbAA2YQVV7JzsYrW14sh57dZwWxLlmsklgV5fsbaa+8URFq f+Y5+DXjPyvEmHHwsAFA/rHu7/uz8oUjAlqIGafuPPunmFvXC8xbuKMo4D6Xh4zpPCIA FGl8DKCBBMfofGxZKEgwgOi5FhI9hrkPgmo2xOYOII7C83ABK8lFIZWkvnCR2ejVhpV3 uwLELkvMoNNe/YNJWTPCpALtzuxqu0/BaEdefKllu6dYX/1uJH/PXYxMSe3xHKG4m0vk 4m+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=kQBUMNB8UQzoWUiYIdyamWEw8RiB+Yd//sYQM9kEiv0=; b=NQBrr1AmQg1C1+9hj4WwFdvtarZL/va/PfrEAuUZsHBpWd8xwpzsX7LU13R5E+PndX tmzc8yisnNmsEUMPNQQ1lRBtQtw8Sk+n6AYHlX1CIn5UXZXnXPcv73lrYyJoG33bGRQ+ t3gKWquom4lVh6qIVNPO6YnMahWbvm28RFI1WJSRxjedThzoN3FQ772tnCooQnYO2L8C +PLSUeZ8IW0awg9YabTOXvfUA3ty3bZI1tN021lbNAXBo4JiH+kgfVcfkOosnHwx5A2h nAYdMiU5rMKFzc8BTb31ZUJJhSntASkTD6h7VRICJJIQUyAU9Wx9Rji5dfywaEaodbOn dhPQ== X-Gm-Message-State: ALoCoQmrjfzFM9ycTDXcTRZqmRWTCUZUoWlhDzebVdp/p+Jr906pb+yaiRvQ/3G97hQfz6sjztjD X-Received: by 10.98.42.9 with SMTP id q9mr14223498pfq.142.1449159372118; Thu, 03 Dec 2015 08:16:12 -0800 (PST) Received: from [205.169.63.165] ([205.169.63.165]) by smtp.googlemail.com with ESMTPSA id 73sm11670174pfh.14.2015.12.03.08.16.11 for (version=TLSv1/SSLv3 cipher=OTHER); Thu, 03 Dec 2015 08:16:11 -0800 (PST) To: idr@ietf.org References:

<565F7D58.1000700@flowtools.net> <565F83DE.4040009@flowtools.net> <565F9400.6060003@mti-systems.com> From: John Schiel Message-ID: <56606ACA.3040800@flowtools.net> Date: Thu, 3 Dec 2015 09:16:10 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <565F9400.6060003@mti-systems.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Idr] packet-rate action for flowspec X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2015 16:16:15 -0000 > > In RFC-speak, we can probably just say that they SHOULD NOT be used > together due to unclear semantics. > > Implementations will need to be robust to receiving both at the same > time (i.e. not crash, break the session, etc), and they can choose to > do something reasonable but implementation-specific (e.g. pick one or > the other). In this sense, I think it is similar to other strange > combinations of actions that could be sent. > Fair enough. Can we make some changes then? Change: +------+--------------------+--------------------------+ | type | extended community | encoding | +------+--------------------+--------------------------+ | TBD | packet-rate | 2-byte as#, 4-byte float | +------+--------------------+--------------------------+ To: +------+--------------------+----------------------------+ | type | extended community | encoding | +------+--------------------+----------------------------+ | TBD | packet-rate | 2-byte as#, 4-byte integer | +------+--------------------+----------------------------+ And at the bottom of the section 2. Packet Rate Action. The use of packet-rate filtering SHOULD NOT be used with traffic-rate filtering together due to unclear semantics. --John > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Thu Dec 3 08:29:01 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82B821A9036 for ; Thu, 3 Dec 2015 08:29:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kUcXCpY7_XO5 for ; Thu, 3 Dec 2015 08:28:58 -0800 (PST) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E145F1A9043 for ; Thu, 3 Dec 2015 08:28:54 -0800 (PST) Received: by wmec201 with SMTP id c201so35406671wme.0 for ; Thu, 03 Dec 2015 08:28:53 -0800 (PST) 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=QgclXYrViI8b7pT0NYU2SeImMMX56juio6rLC5hqVG0=; b=m6/SXpDnjbh1OA98M6Ja/L/SX5B9UZTciPCHgvLS+Hrgf3tMWtSM3laso1mSoUXUke QDCuPWmJJIj7EhAN5asXnSgcW1VRowATetfRfzCn52n+oX9BGx7b4rNzrGVrqMZUjvR0 rpHEjB6bdjvgkDqbyI6PScaLCWS9Xi6XF39Keb5s8JLfcXAMXEz1ve2RH7mV4YafQYyN l0HG6EGadt18uRE9vPCYC40C5uOdv2Gc6x2D3vvqUVt4jdnnBvr/6lFNW+f6HNhJdVpp aAxe04HyP1eVrj6QNETeohVj3+tKK3J2AUY7Glf/NF4EyIJRraqkGeU84InmGqTHAwAv 0TSA== MIME-Version: 1.0 X-Received: by 10.194.203.99 with SMTP id kp3mr12273190wjc.3.1449160133444; Thu, 03 Dec 2015 08:28:53 -0800 (PST) Sender: rraszuk@gmail.com Received: by 10.194.204.195 with HTTP; Thu, 3 Dec 2015 08:28:53 -0800 (PST) In-Reply-To: <56606ACA.3040800@flowtools.net> References:

<565F7D58.1000700@flowtools.net> <565F83DE.4040009@flowtools.net> <565F9400.6060003@mti-systems.com> <56606ACA.3040800@flowtools.net> Date: Thu, 3 Dec 2015 17:28:53 +0100 X-Google-Sender-Auth: Cl2yzfvc3IkfPbMzBTyvCzRo2sY Message-ID: From: Robert Raszuk To: John Schiel Content-Type: multipart/alternative; boundary=047d7bd91af2fa1024052600e205 Archived-At: Cc: idr wg Subject: Re: [Idr] packet-rate action for flowspec X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2015 16:29:00 -0000 --047d7bd91af2fa1024052600e205 Content-Type: text/plain; charset=UTF-8 Ok - I think this is moving fwd :) In the spirit of RFC2119 I recommend we express MUST NOT rather then SHOULD NOT the latter being just a recommendation. Now with "MUST NOT" IMO we actually should specify the implementation behaviour not to install entire NLRI as match when both ext communities are present treating it as sort of soft error. Syslog warning should be logged of course. Alternatively with "SHOULD NOT" draft needs to spec out the preference of which one to use by default when both are present. I think for backwards compatibility the default should be traffic-rate with a knob to use packet-rate instead when available. Best, r. On Thu, Dec 3, 2015 at 5:16 PM, John Schiel wrote: > > >> In RFC-speak, we can probably just say that they SHOULD NOT be used >> together due to unclear semantics. >> >> Implementations will need to be robust to receiving both at the same time >> (i.e. not crash, break the session, etc), and they can choose to do >> something reasonable but implementation-specific (e.g. pick one or the >> other). In this sense, I think it is similar to other strange combinations >> of actions that could be sent. >> >> > Fair enough. > > Can we make some changes then? > > Change: > > +------+--------------------+--------------------------+ > | type | extended community | encoding | > +------+--------------------+--------------------------+ > | TBD | packet-rate | 2-byte as#, 4-byte float | > +------+--------------------+--------------------------+ > > To: > > +------+--------------------+----------------------------+ > | type | extended community | encoding | > +------+--------------------+----------------------------+ > | TBD | packet-rate | 2-byte as#, 4-byte integer | > +------+--------------------+----------------------------+ > > > And at the bottom of the section 2. Packet Rate Action. > > The use of packet-rate filtering SHOULD NOT be used with traffic-rate > filtering together due to unclear semantics. > > --John > > > >> _______________________________________________ >> 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 > --047d7bd91af2fa1024052600e205 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Ok - I think this is moving fwd :)=C2= =A0

In the spirit of R= FC2119 I recommend we express MUST NOT rather then SHOULD NOT the latter be= ing just a recommendation.=C2=A0

Now with "MUST NOT" IMO we actually should specify the= implementation behaviour not to install entire NLRI as match when both ext= communities are present treating it as sort of soft error. Syslog warning = should be logged of course.=C2=A0

Alternatively with "SHOULD NOT" draft needs to spec= out the preference of which one to use by default when both are present. I= think for backwards compatibility the default should be traffic-rate with = a knob to use packet-rate instead when available.=C2=A0

Best,

On Thu, Dec 3,= 2015 at 5:16 PM, John Schiel <jschiel@flowtools.net> wr= ote:

In RFC-speak, we can probably just say that they SHOULD NOT be used togethe= r due to unclear semantics.

Implementations will need to be robust to receiving both at the same time (= i.e. not crash, break the session, etc), and they can choose to do somethin= g reasonable but implementation-specific (e.g. pick one or the other).=C2= =A0 In this sense, I think it is similar to other strange combinations of a= ctions that could be sent.

Fair enough.

Can we make some changes then?

Change:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+------+--------------------+------------= --------------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| type | extended community | encoding=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+------+--------------------+------------= --------------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| TBD=C2=A0 | packet-rate=C2=A0 =C2=A0 = =C2=A0 =C2=A0 | 2-byte as#, 4-byte float |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+------+--------------------+------------= --------------+

To:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+------+--------------------+------------= ----------------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| type | extended community | encoding=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+------+--------------------+------------= ----------------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| TBD=C2=A0 | packet-rate=C2=A0 =C2=A0 = =C2=A0 =C2=A0 | 2-byte as#, 4-byte integer |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+------+--------------------+------------= ----------------+

And at the bottom of the section 2. Packet Rate Action.

The use of packet-rate filtering SHOULD NOT be used with traffic-rate filte= ring together due to unclear semantics.

--John

_______________________________________________
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

--047d7bd91af2fa1024052600e205-- From nobody Thu Dec 3 11:00:55 2015 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B1951B3577; Thu, 3 Dec 2015 11:00:52 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151203190052.12377.76287.idtracker@ietfa.amsl.com> Date: Thu, 03 Dec 2015 11:00:52 -0800 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgpls-segment-routing-epe-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2015 19:00:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Segment Routing Egress Peer Engineering BGP-LS Extensions Authors : Stefano Previdi Clarence Filsfils Saikat Ray Keyur Patel Jie Dong Mach (Guoyi) Chen Filename : draft-ietf-idr-bgpls-segment-routing-epe-01.txt Pages : 19 Date : 2015-12-03 Abstract: Segment Routing (SR) leverages source routing. A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with an SR header. A segment can represent any instruction, topological or service-based. SR allows to enforce a flow through any topological path and service chain while maintaining per-flow state only at the ingress node of the SR domain. The Segment Routing architecture can be directly applied to the MPLS dataplane with no change on the forwarding plane. It requires minor extension to the existing link-state routing protocols. This document outline a BGP-LS extension for exporting BGP egress point topology information (including its peers, interfaces and peering ASs) in a way that is exploitable in order to compute efficient Egress Point Engineering policies and strategies. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgpls-segment-routing-epe/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-bgpls-segment-routing-epe-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgpls-segment-routing-epe-01 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 nobody Fri Dec 4 07:57:07 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D33901A88DE for ; Fri, 4 Dec 2015 07:57:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.578 X-Spam-Level: X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j3MK0mx9E7iQ for ; Fri, 4 Dec 2015 07:57:06 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 2B52F1A88A3 for ; Fri, 4 Dec 2015 07:57:06 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 76D0A1E42E; Fri, 4 Dec 2015 10:58:09 -0500 (EST) Date: Fri, 4 Dec 2015 10:58:09 -0500 From: Jeffrey Haas To: Robert Raszuk Message-ID: <20151204155809.GC16473@pfrc.org> References:

<565F7D58.1000700@flowtools.net> <565F83DE.4040009@flowtools.net> <565F9400.6060003@mti-systems.com> <56606ACA.3040800@flowtools.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: idr wg Subject: Re: [Idr] packet-rate action for flowspec X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 15:57:07 -0000 Robert, On Thu, Dec 03, 2015 at 05:28:53PM +0100, Robert Raszuk wrote: > Ok - I think this is moving fwd :) > > In the spirit of RFC2119 I recommend we express MUST NOT rather then SHOULD > NOT the latter being just a recommendation. > > Now with "MUST NOT" IMO we actually should specify the implementation > behaviour not to install entire NLRI as match when both ext communities are > present treating it as sort of soft error. Syslog warning should be logged > of course. I think the major issue with these sort of things is what happens when you're on an implementation that doesn't understand some but understands other forms of these action criteria. If I understand rate-limit but don't know pps, I can still do "something useful". If I understand both, I might be able to do both. In most cases, I'd expect pps to be set low enough that it'd take effect before bps. To that end, I'd be fine with pps taking precedence in implementations that understand both. -- Jeff From nobody Fri Dec 4 08:06:42 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BA491A88EA; Fri, 4 Dec 2015 08:06:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.578 X-Spam-Level: X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NhxVRO03HoHi; Fri, 4 Dec 2015 08:06:40 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id BD5F81A891A; Fri, 4 Dec 2015 08:06:40 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 110101E42E; Fri, 4 Dec 2015 11:07:44 -0500 (EST) Date: Fri, 4 Dec 2015 11:07:44 -0500 From: Jeffrey Haas To: Susan Hares Message-ID: <20151204160743.GE16473@pfrc.org> References: <056c01d126ab$61421980$23c64c80$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <056c01d126ab$61421980$23c64c80$@ndzh.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: idr@ietf.org, draft-liang-idr-bgp-flowspec-label@ietf.org Subject: Re: [Idr] WG Call for adoption on draft-liang-idr-bgp-flowspec-label-01 (11/24 to 12/8) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 16:06:42 -0000 On Tue, Nov 24, 2015 at 06:29:27AM -0500, Susan Hares wrote: > This begins a 2 week adoption call for > draft-liang-idr-bgp-flowspec-label-01.txt which can be found at: > > > > http://datatracker.ietf.org/doc/draft-liang-idr-bgp-flowspec-label/ At this time, I do not support the document for adoption. As some of the discussion in this thread is indicating, the use case isn't quite clear in some circumstances. This leaves me with operational and deployment concerns. I think once the document has been clarified, I would reconsider my stance. (Magic 8 ball says, "Ask again later".) -- Jeff From nobody Fri Dec 4 08:13:59 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7818A1A893F for ; Fri, 4 Dec 2015 08:13:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.578 X-Spam-Level: X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jp03d3dEIIvR for ; Fri, 4 Dec 2015 08:13:57 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id F3A921A893E for ; Fri, 4 Dec 2015 08:13:56 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 57E121E4AE; Fri, 4 Dec 2015 11:15:00 -0500 (EST) Date: Fri, 4 Dec 2015 11:15:00 -0500 From: Jeffrey Haas To: Denis Ovsienko Message-ID: <20151204161500.GF16473@pfrc.org> References: <14e40292f34.d2dcc804361197.2941336746668363165@ovsienko.info> <15158082a35.cf64977923064.985898708084118813@ovsienko.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15158082a35.cf64977923064.985898708084118813@ovsienko.info> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: idr@ietf.org Subject: Re: [Idr] Fwd: about the NLRI encoding extensions X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 16:13:58 -0000 Denis, On Mon, Nov 30, 2015 at 10:55:08AM +0000, Denis Ovsienko wrote: > As the below message had never been responded to, let me forward those comments to the WG mailing list (which I am not a subscriber of). They still seem to apply to the latest version of the I-D. You'll find the idea of updating NLRI format specifically to accommodate man-in-the-middle sniffers such as tcpdump/wireshark to be poorly received unfortunately. While I'm sympathetic, your best course of action is to either attempt to decode and use the first successful decoding to provide a hint for further decoding or to permit configuration hints for add-path configuration on the command-line. -- Jeff > > > == == == == == == Forwarded message == == == == == == > >From : Denis Ovsienko > To : > Date : Mon, 29 Jun 2015 18:59:34 +0100 > Subject : about the NLRI encoding extensions > == == == == == == Forwarded message == == == == == == > Greetings to the people behind draft-ietf-idr-add-paths! > > Today I was helping to look into a BGP issue, which later turned out to be a bug in an implementation of ADD-PATH. The first thing I noticed during the packet capture study was that tcpdump did not recognize the capability 69, so I found respective specification and decided to add that support while at it. The capability part of the specification (Section 4) was straightforward but looking at the NLRI section (Section 3) I had realized that there was no way to tell which of the encodings a given NLRI attribute is going to have. So it ended up done just half-way: https://github.com/the-tcpdump-group/tcpdump/commit/c9c3d3cfdf3a926e02114cfe611ffe20167ab5f4 > > Of course, it can be said that looking at both OPENs of a BGP session and the Send/Receive field of the capability it is possible to see which format must be used in the subsequent UPDATE messages. But in the scope of a network analyzer it is very much preferred to be able to decode a given protocol packet with as little dependency on earlier packets as possible. This is in part because packet loss just happens and in part because packet captures don't necessarily cover full protocol sessions, especially where sessions remain up for a long time. > > To add to this, the actual speaker behaviour was inconsistent with the OPENs: with the capability set to 3 on both ends one speaker sent MP_REACH_NLRI in the traditional encoding (without prepending the path identifier field). The network prefixes themselves were correct otherwise. The other speaker detected an encoding error and shut down the session with a NOTIFICATION message. But in a slightly different configuration the first speaker behaved according to the I-D and sent MP_REACH_NLRI respectively encoded. Though the BGP session stayed up it wasn't possible to read the prefixes any more as the decoder has no means to understand it needed to switch to the ADD-PATH format. In this context it would be very handy to have an explicit indicator of the encoding (normal/extended) right in the UPDATE message, so that the packet analyzer could properly display the contents regardless of the OPENs. > > In theory, a possible (from packet analyzer point of view) way to do that could be not to reuse previously assigned path attributes (MP_REACH_NLRI and MP_UNREACH_NLRI) to mean a new, not backward-compatible structure, but to assign new attributes for the new encoding. As far as I can see, this does not help the non-MP traditional NLRI part of an UPDATE, but this may be irrelevant. I am not an expert. Since this I-D is in a very late development phase and there are implementations around, I understand this is too complicated anyway due to existing deployments. > > Do you see any _other_ simple ways to encode the "extended NLRI format follows" hint into an UPDATE message? An additional attribute maybe? > > Thank you. > > -- > Denis Ovsienko > > > > -- > Denis Ovsienko > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Mon Dec 7 18:22:44 2015 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 90F151B2AC9; Mon, 7 Dec 2015 18:22:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151208022241.14650.4109.idtracker@ietfa.amsl.com> Date: Mon, 07 Dec 2015 18:22:41 -0800 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-eag-distribution-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2015 02:22:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Distribution of MPLS-TE Extended admin Group Using BGP Authors : Zitao Wang Qin Wu Jeff Tantsura Filename : draft-ietf-idr-eag-distribution-01.txt Pages : 5 Date : 2015-12-07 Abstract: As MPLS-TE network grows, administrative Groups advertised as a fixed-length 32-bit Bitmask is quite constraining. "Extended Administrative Group" IGP TE extensions sub-TLV defined in [RFC7308] is introduced to provide for additional administrative groups (link colors) beyond the current limit of 32. This document describes extensions to BGP protocol, that can be used to distribute extended administrative groups in MPLS-TE. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-eag-distribution/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-eag-distribution-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-eag-distribution-01 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 nobody Tue Dec 8 07:01:40 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62D651B2EB7 for ; Tue, 8 Dec 2015 07:01:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZgGKx66DG52i for ; Tue, 8 Dec 2015 07:01:37 -0800 (PST) Received: from relais-inet.orange.com (relais-nor36.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C0751B2EC7 for ; Tue, 8 Dec 2015 07:01:37 -0800 (PST) Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id 73189208E5 for ; Tue, 8 Dec 2015 16:01:35 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.41]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id 52B4B400AA for ; Tue, 8 Dec 2015 16:01:35 +0100 (CET) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM31.corporate.adroot.infra.ftgroup ([fe80::2cc9:4bac:7b7d:229d%19]) with mapi id 14.03.0248.002; Tue, 8 Dec 2015 16:01:35 +0100 From: To: "idr@ietf.org" Thread-Topic: I-D Action: draft-litkowski-idr-flowspec-interfaceset-03.txt Thread-Index: AQHRMcjAiQRYN2d7Zk29gwudcTHDJ57BLkBA Date: Tue, 8 Dec 2015 15:01:34 +0000 Message-ID: <16428_1449586895_5666F0CF_16428_3421_1_9E32478DFA9976438E7A22F69B08FF92167C7C2F@OPEXCLILMA4.corporate.adroot.infra.ftgroup> References: <20151208145714.5481.14086.idtracker@ietfa.amsl.com> In-Reply-To: <20151208145714.5481.14086.idtracker@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Idr] FW: I-D Action: draft-litkowski-idr-flowspec-interfaceset-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2015 15:01:39 -0000 Hi IDR folks, Please find below an update of the interface-set extension draft for BGP Fl= owspec. The major changes are : - call for using a Route Target instead of a generic extended community to = allow constrained route distribution. - add considerations about using ADD PATH when the same filter need to be a= pplied with different actions on different interface-sets. Please provide your feedback. Best Regards, Stephane -----Original Message----- From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of inte= rnet-drafts@ietf.org Sent: Tuesday, December 08, 2015 15:57 To: i-d-announce@ietf.org Subject: I-D Action: draft-litkowski-idr-flowspec-interfaceset-03.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Applying BGP flowspec rules on a specific interfa= ce set Authors : Stephane Litkowski Adam Simpson Keyur Patel Jeff Haas Filename : draft-litkowski-idr-flowspec-interfaceset-03.txt Pages : 13 Date : 2015-12-08 Abstract: BGP Flow-spec is an extension to BGP that allows for the dissemination of traffic flow specification rules. The primary application of this extension is DDoS mitigation where the flowspec rules are applied in most cases to all peering routers of the network. This document will present another use case of BGP Flow-spec where flow specifications are used to maintain some access control lists at network boundary. BGP Flowspec is a very efficient distributing machinery that can help in saving OPEX while deploying/updating ACLs. This new application requires flow specification rules to be applied only on a specific subset of interfaces and in a specific direction. The current specification of BGP Flow-spec does not detail where the flow specification rules need to be applied. This document presents a new interface-set flowspec action that will be used in complement of other actions (marking, rate-limiting ...). The purpose of this extension is to inform remote routers on where to apply the flow specification. This extension can also be used in a DDoS mitigation context where a provider wants to apply the filtering only on specific peers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-litkowski-idr-flowspec-interfaceset/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-litkowski-idr-flowspec-interfaceset-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-litkowski-idr-flowspec-interfaces= et-03 Please note that it may take a couple of minutes from the time of submissio= n 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/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ie= tf.org/ietf/1shadow-sites.txt ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorization. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange shall not be liable if th= is message was modified, changed or falsified. Thank you. From nobody Wed Dec 9 07:39:28 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 745941B2D72 for ; Wed, 9 Dec 2015 07:39:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qd2_UfnaMO3w for ; Wed, 9 Dec 2015 07:39:24 -0800 (PST) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DE7A1B2D6E for ; Wed, 9 Dec 2015 07:39:24 -0800 (PST) Received: by obbww6 with SMTP id ww6so38244836obb.0 for ; Wed, 09 Dec 2015 07:39:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=flowtools-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=LpJeWQD9bbWNZAM0K++KzCCDTtYIgoJUoeTbT7KfNGc=; b=spLKYJMBLgB0PY3SVuK9aUEAv0SJ6oXokmKQ+6jpgoBHDQFfotF/02oE7Abv0NhfTI +pGZvGycgFqePUzsfrIZeC9RleKFoOHPbNP1udyp79f5umkaYFfJE5tcp7H/5ueGJHSp nxXy5KCxHOrPSMTCwDR4pw5qpf3w4KwQPTPoptbENmrtaXjUcpD/nlBQmz5m8XSrjaNw iudeFQAqY9OnL0DVwPOa4sz+hAVtv+rf9teRAUFnma5SVo9LyaeX+Cnfuk10nAhDcS24 MmW51NW3+2LtmGdsKyVD6epEW3yp2RfWSQHYUqaAMX+bLAjynJC3soXmrHjAy+NsUZA9 zLYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=LpJeWQD9bbWNZAM0K++KzCCDTtYIgoJUoeTbT7KfNGc=; b=mMt4I8RMKJ2m68WCi34cliy6QKc7TlR2xF88S0e37ZRrEAH5wtsd9bTK2Ihx4ElhXO yvgw8v4qULM3ncEk9mV2c06r9nNeUd/++wf4EcuYYFQeUNkqJjbxQUxRmEY9bKH73sm8 1kJzEdkrfP/cLJ3N1JJIq2/JDO1+yR2710kfbnuHqS1NCJdb4mL6tPtNs5ZQ840vdRZZ iJbwMZGduxMvkmZpLeifKDxSBZmHL577E4v2LLidDx+5SBxdWojK3CwQYOCAI7QBsJJI HPpDx1/v6mMr+gInnjLjdxZfW58sZJrulVhMi8JnEmnsC3I3kuuudpy9kvxhULSeAIzC pJqw== X-Gm-Message-State: ALoCoQnX1vH91bqE7y2pYOU6WIBl4d6Sc2jkRjXfs+HthSiDZD8kA3tP4tekpJasgvcin3SsFdtbBxQGGkiBQYsCYKyfumNTUg== X-Received: by 10.182.29.39 with SMTP id g7mr4836795obh.15.1449675563527; Wed, 09 Dec 2015 07:39:23 -0800 (PST) Received: from [205.169.63.165] ([205.169.63.165]) by smtp.googlemail.com with ESMTPSA id c185sm3809586oih.15.2015.12.09.07.39.22 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 09 Dec 2015 07:39:22 -0800 (PST) To: Jeffrey Haas , Robert Raszuk References:

<565F7D58.1000700@flowtools.net> <565F83DE.4040009@flowtools.net> <565F9400.6060003@mti-systems.com> <56606ACA.3040800@flowtools.net> <20151204155809.GC16473@pfrc.org> From: John Schiel Message-ID: <56684B2A.2060701@flowtools.net> Date: Wed, 9 Dec 2015 08:39:22 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <20151204155809.GC16473@pfrc.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: idr wg Subject: Re: [Idr] packet-rate action for flowspec X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2015 15:39:26 -0000 Sorry, been very busy of late. I have no real preference on which takes rate limiting action takes precedence if both are allowed but I would like to keep the work level of this to a minimum so if Robert is correct in his statement that traffic-rate take priority for backwards compatibility, then I vote we go that direction. The knob can be tuned in a way that packet-rate action would take effect prior to traffic-rate if the levels are set appropriately. Thoughts? --John On 12/04/2015 08:58 AM, Jeffrey Haas wrote: > Robert, > > On Thu, Dec 03, 2015 at 05:28:53PM +0100, Robert Raszuk wrote: >> Ok - I think this is moving fwd :) >> >> In the spirit of RFC2119 I recommend we express MUST NOT rather then SHOULD >> NOT the latter being just a recommendation. >> >> Now with "MUST NOT" IMO we actually should specify the implementation >> behaviour not to install entire NLRI as match when both ext communities are >> present treating it as sort of soft error. Syslog warning should be logged >> of course. > I think the major issue with these sort of things is what happens when > you're on an implementation that doesn't understand some but understands > other forms of these action criteria. If I understand rate-limit but don't > know pps, I can still do "something useful". > > If I understand both, I might be able to do both. > > In most cases, I'd expect pps to be set low enough that it'd take effect > before bps. To that end, I'd be fine with pps taking precedence in > implementations that understand both. > > -- Jeff > From nobody Thu Dec 10 15:12:03 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D364B1B2DB5 for ; Thu, 10 Dec 2015 15:12:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p2n8_GMox09a for ; Thu, 10 Dec 2015 15:12:01 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0130.outbound.protection.outlook.com [65.55.169.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F10CB1B2D6F for ; Thu, 10 Dec 2015 15:12:00 -0800 (PST) Received: from BLUPR05MB451.namprd05.prod.outlook.com (10.141.28.26) by BLUPR05MB450.namprd05.prod.outlook.com (10.141.28.19) with Microsoft SMTP Server (TLS) id 15.1.337.19; Thu, 10 Dec 2015 23:11:57 +0000 Received: from BLUPR05MB451.namprd05.prod.outlook.com ([169.254.6.230]) by BLUPR05MB451.namprd05.prod.outlook.com ([169.254.6.230]) with mapi id 15.01.0337.015; Thu, 10 Dec 2015 23:11:57 +0000 From: John Scudder To: "idr@ietf.org" Thread-Topic: Clarifying add-paths capability formatting Thread-Index: AQHRM6Aq32ujbUoul0690ZqxIlA40Q== Date: Thu, 10 Dec 2015 23:11:57 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; x-originating-ip: [166.170.26.40] x-microsoft-exchange-diagnostics: 1; BLUPR05MB450; 5:TtmzCLJAm5RfZtB/WfbSnHuhxyIhdNG0HQqxdHZhIZ17TZP+Y5ThPTwX78a8U91ASMoJSl4KSTLsMsdGVXIdGLUtQjSN6TZbJ4VhPtUA8BpRYy0WPpeKD84S+RXx5k5ayF6IkvhPq+qucjpGUkJn5g==; 24:KE0PDGMMAVAvZgmTKBnjEmFt0cq+oYMFrgWyKq1Z01UhTJxE3gx6pT9WUIIkbDBbDYmbjWsLh08kbBxAwIzOdbCWnc561pw6IjiUKh5siS4= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB450; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(8121501046)(5005006)(10201501046)(3002001); SRVR:BLUPR05MB450; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB450; x-forefront-prvs: 078693968A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(53754006)(189002)(69234005)(164054003)(66066001)(36756003)(83716003)(81156007)(229853001)(11100500001)(5008740100001)(107886002)(82746002)(5001960100002)(2351001)(102836003)(10400500002)(1220700001)(1096002)(586003)(6116002)(86362001)(3846002)(189998001)(2900100001)(50986999)(450100001)(5004730100002)(110136002)(54356999)(97736004)(105586002)(2501003)(101416001)(99286002)(40100003)(16236675004)(122556002)(87936001)(33656002)(92566002)(106116001)(5002640100001)(1730700002)(106356001)(104396002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB450; H:BLUPR05MB451.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BDDBF5A7145341F681E54F10B6F5EDC4junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Dec 2015 23:11:57.4399 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB450 Archived-At: Subject: [Idr] Clarifying add-paths capability formatting X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2015 23:12:03 -0000 --_000_BDDBF5A7145341F681E54F10B6F5EDC4junipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRXZlcnlib2R5LA0KDQpXZSByZWNlbnRseSBiZWNhbWUgYXdhcmUgdGhhdCB0aGUgYWRkLXBh dGhzIGRyYWZ0IGNvdWxkIGJlIEV2ZW4gQ2xlYXJlciByZWdhcmRpbmcgaG93IHRoZSBBREQtUEFU SCBjYXBhYmlsaXR5IGlzIHRvIGJlIGZvcm1hdHRlZC4gVGhlIGF1dGhvcnMnIGludGVudCB3YXMg dGhhdCBhbGwgQUZJL1NBRkkgd2VyZSB0byBiZSBsaXN0ZWQgd2l0aGluIGEgc2luZ2xlIGNhcGFi aWxpdHkgYW5kIG1vc3QgaW1wbGVtZW50YXRpb25zIGRvIHRoaXMsIGJ1dCBvbmUgaW1wbGVtZW50 b3IgcmVjZW50bHkgY2hvc2UgdG8gZG8gaXQgYXMgbXVsdGlwbGUgY2FwYWJpbGl0aWVzIGVhY2gg Y2FycnlpbmcgYSBzaW5nbGUgQUZJL1NBRkkuDQoNClNpbmNlIGl0J3MgZXZpZGVudGx5IG5vdCBz dWZmaWNpZW50bHkgY2xlYXIgaW4gdGhlIGN1cnJlbnQgZHJhZnQsIHdlIHByb3Bvc2UgdG8gYWRk IHRoaXMgc2VudGVuY2UgYXQgdGhlIGVuZCBvZiBTZWN0aW9uIDQuIChBREQtUEFUSCBDYXBhYmls aXR5KToNCg0KIkEgQkdQIHNwZWFrZXIgdGhhdCB3aXNoZXMgdG8gaW5kaWNhdGUgc3VwcG9ydCBm b3IgbXVsdGlwbGUgQUZJL1NBRkkgTVVTVCBkbyBzbyBieSBpbmNsdWRpbmcgdGhlIGluZm9ybWF0 aW9uIGluIGEgc2luZ2xlIGluc3RhbmNlIG9mIHRoZSBBREQtUEFUSCBDYXBhYmlsaXR5LiINCg0K RllJIGFuZCBjb21tZW50cyBpZiBhbnkuDQoNClRoYW5rcywNCg0KLS1Kb2huDQogICh3ZWFyaW5n IGNvLWF1dGhvciBoYXQgYW5kIG5vdCBjby1jaGFpciBlcGF1bGV0cykNCg== --_000_BDDBF5A7145341F681E54F10B6F5EDC4junipernet_ Content-Type: text/html; charset="utf-8" Content-ID: <3D37E173FDB5324E98EAFD11582D7469@junipernetworks.onmicrosoft.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8 c3BhbiBzdHlsZT0iY29sb3I6IHJnYig2OSwgNjksIDY5KTsgdGV4dC1kZWNvcmF0aW9uOiAtd2Vi a2l0LWxldHRlcnByZXNzOyI+SGkgRXZlcnlib2R5LDwvc3Bhbj4NCjxkaXYgc3R5bGU9ImNvbG9y OiByZ2IoNjksIDY5LCA2OSk7IHRleHQtZGVjb3JhdGlvbjogLXdlYmtpdC1sZXR0ZXJwcmVzczsi Pjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYig2OSwgNjksIDY5KTsgdGV4dC1k ZWNvcmF0aW9uOiAtd2Via2l0LWxldHRlcnByZXNzOyI+V2UgcmVjZW50bHkgYmVjYW1lIGF3YXJl IHRoYXQgdGhlIGFkZC1wYXRocyBkcmFmdCBjb3VsZCBiZSBFdmVuIENsZWFyZXIgcmVnYXJkaW5n IGhvdyB0aGUgQURELVBBVEggY2FwYWJpbGl0eSBpcyB0byBiZSBmb3JtYXR0ZWQuIFRoZSBhdXRo b3JzJyBpbnRlbnQgd2FzIHRoYXQgYWxsIEFGSS9TQUZJIHdlcmUgdG8gYmUNCiBsaXN0ZWQgd2l0 aGluIGEgc2luZ2xlIGNhcGFiaWxpdHkgYW5kIG1vc3QgaW1wbGVtZW50YXRpb25zIGRvIHRoaXMs IGJ1dCBvbmUgaW1wbGVtZW50b3IgcmVjZW50bHkgY2hvc2UgdG8gZG8gaXQgYXMgbXVsdGlwbGUg Y2FwYWJpbGl0aWVzIGVhY2ggY2FycnlpbmcgYSBzaW5nbGUgQUZJL1NBRkkuJm5ic3A7PC9kaXY+ DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDY5LCA2OSwgNjkpOyB0ZXh0LWRlY29yYXRpb246IC13 ZWJraXQtbGV0dGVycHJlc3M7Ij48c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjogcmdiYSgy NTUsIDI1NSwgMjU1LCAwKTsiPjxicj4NCjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9y OiByZ2IoNjksIDY5LCA2OSk7IHRleHQtZGVjb3JhdGlvbjogLXdlYmtpdC1sZXR0ZXJwcmVzczsi PjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiByZ2JhKDI1NSwgMjU1LCAyNTUsIDApOyI+ U2luY2UgaXQncyBldmlkZW50bHkgbm90IHN1ZmZpY2llbnRseSBjbGVhciBpbiB0aGUgY3VycmVu dCBkcmFmdCwgd2UgcHJvcG9zZSB0byBhZGQmbmJzcDt0aGlzIHNlbnRlbmNlIGF0IHRoZSBlbmQg b2YgU2VjdGlvbiA0LiAoQURELVBBVEgmbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImJhY2tncm91 bmQtY29sb3I6IHJnYmEoMjU1LCAyNTUsIDI1NSwgMCk7Ij5DYXBhYmlsaXR5KTo8L3NwYW4+PC9k aXY+DQo8c3BhbiBzdHlsZT0iY29sb3I6IHJnYig2OSwgNjksIDY5KTsgdGV4dC1kZWNvcmF0aW9u OiAtd2Via2l0LWxldHRlcnByZXNzOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2JhKDI1NSwgMjU1LCAy NTUsIDApOyI+PGJyPg0KJnF1b3Q7QSBCR1Agc3BlYWtlciB0aGF0IHdpc2hlcyB0byBpbmRpY2F0 ZSBzdXBwb3J0IGZvciBtdWx0aXBsZSBBRkkvU0FGSSBNVVNUJm5ic3A7ZG8gc28gYnkgaW5jbHVk aW5nIHRoZSBpbmZvcm1hdGlvbiBpbiBhIHNpbmdsZSBpbnN0YW5jZSBvZiB0aGUgQURELVBBVEgm bmJzcDtDYXBhYmlsaXR5LiZxdW90Ozwvc3Bhbj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoNjks IDY5LCA2OSk7IHRleHQtZGVjb3JhdGlvbjogLXdlYmtpdC1sZXR0ZXJwcmVzczsiPjxzcGFuIHN0 eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiByZ2JhKDI1NSwgMjU1LCAyNTUsIDApOyI+PGJyPg0KPC9z cGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYig2OSwgNjksIDY5KTsgdGV4dC1kZWNv cmF0aW9uOiAtd2Via2l0LWxldHRlcnByZXNzOyI+RllJIGFuZCBjb21tZW50cyBpZiBhbnkuJm5i c3A7PC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDY5LCA2OSwgNjkpOyB0ZXh0LWRlY29y YXRpb246IC13ZWJraXQtbGV0dGVycHJlc3M7Ij48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImNv bG9yOiByZ2IoNjksIDY5LCA2OSk7IHRleHQtZGVjb3JhdGlvbjogLXdlYmtpdC1sZXR0ZXJwcmVz czsiPlRoYW5rcyw8L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoNjksIDY5LCA2OSk7IHRl eHQtZGVjb3JhdGlvbjogLXdlYmtpdC1sZXR0ZXJwcmVzczsiPjxicj4NCjwvZGl2Pg0KPGRpdiBz dHlsZT0iY29sb3I6IHJnYig2OSwgNjksIDY5KTsgdGV4dC1kZWNvcmF0aW9uOiAtd2Via2l0LWxl dHRlcnByZXNzOyI+LS1Kb2huPC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDY5LCA2OSwg NjkpOyB0ZXh0LWRlY29yYXRpb246IC13ZWJraXQtbGV0dGVycHJlc3M7Ij4mbmJzcDsgKHdlYXJp bmcgY28tYXV0aG9yIGhhdCBhbmQgbm90IGNvLWNoYWlyIGVwYXVsZXRzKTwvZGl2Pg0KPGRpdj48 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BDDBF5A7145341F681E54F10B6F5EDC4junipernet_-- From nobody Fri Dec 11 12:15:46 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAF1D1A1AA1; Fri, 11 Dec 2015 12:15:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.509 X-Spam-Level: X-Spam-Status: No, score=-14.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EJU1DUTi2Rrl; Fri, 11 Dec 2015 12:15:42 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D5401A01D7; Fri, 11 Dec 2015 12:15:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19153; q=dns/txt; s=iport; t=1449864941; x=1451074541; h=from:to:cc:subject:date:message-id:mime-version; bh=iMj/ytJtS4iGNDZ7IrrviH2iHJbkDXAEUDapyFEOT9A=; b=fy28JqgMw2B41BggoKNlmrWP+MIXycRxf304G+aFGUFNkmTp/bmbCrTV OPM+wGAgsECgkDk1k4QpU/c2hGLthbCLuhC76D6L+dbFjERuMmPIcdqer wDC46eKDQZLNwkiqsGBONjKfx4gGtBkoFNxQUXKT2NiLoCNoBHOBO+P6I k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D/AQAQLmtW/5JdJa1egm5MgUe9KQENg?= =?us-ascii?q?WKGD4EzOBQBAQEBAQEBfwuENwR5EgGBACcEDhmIG75WAQEBAQYBAQEBAQEdhlY?= =?us-ascii?q?BiT6EfgWTAoNwAY1DgVuERY4PhG6DcgEfAQFCghEdgVaFDQUCPIEHAQEB?= X-IronPort-AV: E=Sophos;i="5.20,415,1444694400"; d="scan'208,217";a="216452944" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Dec 2015 20:15:40 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id tBBKFdOA016297 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 11 Dec 2015 20:15:40 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 11 Dec 2015 14:15:39 -0600 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1104.009; Fri, 11 Dec 2015 14:15:39 -0600 From: "Alvaro Retana (aretana)" To: "draft-ietf-idr-ix-bgp-route-server@ietf.org" Thread-Topic: AD Review of draft-ietf-idr-ix-bgp-route-server-09 Thread-Index: AQHRNFCzHRdSwT+uvUK1lt056oVbCA== Date: Fri, 11 Dec 2015 20:15:39 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.15.5] Content-Type: multipart/alternative; boundary="_000_D29085C4EFB5Aaretanaciscocom_" MIME-Version: 1.0 Archived-At: Cc: "idr-chairs@ietf.org" , Susan Hares , "idr@ietf.org" Subject: [Idr] AD Review of draft-ietf-idr-ix-bgp-route-server-09 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2015 20:15:44 -0000 --_000_D29085C4EFB5Aaretanaciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi! I just finished reading this document. Please find my comments below. As you can see, the comments I labeled as Major are mostly related to secur= ity considerations, where I think there's more to add, and clarity with res= pect to the behavior in RFC4271. I don't think that any of the comment wil= l be hard to address. I will wait for your comments/discussion and/or an update before starting t= he IETF Last Call. Thanks! Alvaro. Major: 1. Should this document be marked as updating rfc4271? There are severa= l places in Section 2 where the behavior is different than what is specifie= d in rfc4271. Given that the route server functionality is an optional enh= ancement, I don't think this document should be marked as updating rfc4271 = (I.e. It changes the behavior only for the functionality specified here). = I'm assuming the authors/WG agree since there is no indication of an update= . Please include a clear statement (maybe in the Introduction) to the fact= that the mechanism is optional. 2. Section 2.1. (Client UPDATE Messages). "The route server SHOULD forwa= rd UPDATE messages where appropriate=85to its clients." When is it appropr= iate? I'm guessing that you mean something like "where local policy permit= s".. Please be clear. 3. Section 2.2.2. (AS_PATH Attribute) Not prepending the route server's= AS_PATH brings up a couple of issues/questions: * RFC4271 talks about prepending the local ASN (when advertising to = an EBGP peer), and it doesn't mention any exceptions. This document includ= es an exception. Clearly indicate the modifications to Section 5.1.2. (AS_= PATH) of RFC4271. * Section 6.3. (UPDATE Message Error Handling) of rfc4271 says that = when an "=85UPDATE message is received from an external peer, the local sys= tem MAY check whether the leftmost=85AS in the AS_PATH attribute is equal t= o the autonomous system number of the peer that sent the message", and MUST= send a NOTIFICATION if it doesn't. * Please be explicit about the required behavior for both the rou= te server, and the clients. * Even though this check is optional in RFC4271, mandating that i= s not be done could be interpreted as a security issue. Please include som= e text around it (and mitigation) in the Security Considerations section. * Independent of the check, not including an ASN in the AS_PATH coul= d (in the general case) result in loops; which I also interpret as a potent= ial security issue. Please include some text about this too =97 a mitigati= on option is clearly to not check the first ASN only when known route serve= rs are peers. 4. Section 2.2.4. (Communities Attributes) says that Communities "SHOULD= NOT be modified, processed or removed. However, if such an attribute is i= ntended for processing by the route server itself, it MAY be modified or re= moved." How does the route server know if the sender intended for a commun= ity to be processed by it, or not? Please add details. 5. Section 3. (Security Considerations) * Besides the points above, because clients rely on the route server= to implement outbound route filtering for them, there can be a privacy iss= ue/route leak scenario where the route server can send routes to clients th= at it shouldn't have. Not much can be done to mitigate this because it wil= l mostly be due to a bad implementation or simply a "bad operator". * You should point at relevant sections of RFC7454. 6. Minor: 1. Please be consistent: * s/exterior BGP/external BGP..or even just EBGP (yes, a nit..but th= at's how rfc4271 calls EBGP) * s/best path selection process/Decision Process * s/IX/IXP 2. Section 2.2.3. (MULTI_EXIT_DISC Attribute) specifically calls out the= MED, but you already said in Section 2.2. (Attribute Transparency) that al= l optional attributes "SHOULD NOT be updated by the route server=85and SHOU= LD be passed on to other route server clients." Is there anything special = about the MED that I'm missing? If not, then you should be able to delete = the section. 3. In Section 2.3.1. (Path Hiding on a Route Server) policy implementati= on is described in terms of outbound route filtering. The description of t= he example says that if "AS1's policy prevents AS2's path from being accept= ed, then AS1 would never receive a path to this prefix". To be consistent = with the outbound filtering description, you might want to change that text= to something like "AS2's policy prevents AS1 from receiving the path, =85"= . 4. Section 2.3.2.2. (Advertising Multiple Paths) says that if the route = server sends "more than a single path to a route server client,=85the path = hiding problem described in Section 2.3.1 would disappear." That statement= is true, but only if all the paths are propagated, not just "more than a s= ingle" one. [You do talk about that in 2.3.2.2.1, but not the general case.= ] 5. Section 2.3.2.2.2. (BGP ADD-PATH Approach) * This section says that if "the route server client propagates mult= iple paths for the same prefix to the route server, then this could potenti= ally cause the propagation of inactive, invalid or suboptimal paths to the = route server, thereby causing loss of reachability to other route server cl= ients." I can see how suboptimal (=3D non best) paths can be propagated by= the clients, but what about invalid? * To be consistent, there's no such thing as send-only and receive-o= nly modes negotiated with ADD-PATH. For the result in the text (having onl= y the route server send), the route server should advertise the Send/Receiv= e field in the ADD_PATH capability set to 2 (only able to send). It doesn'= t matter what the client sets the value to (as long as it is not 2). 6. References: I think the following can be made Informational: RFC1997= , RFC4360 Nits: 1. Given that Section 2.3 is "included for information purposes only", y= ou might want to consider making it an Appendix. 2. Section 2.3.3. (Implementation Suggestions) seems superfluous to me. --_000_D29085C4EFB5Aaretanaciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <02AEF4B7446B4F429B1F33F745FB0783@emea.cisco.com> Content-Transfer-Encoding: quoted-printable

Hi!

I just finished reading this document. Please find my comments below.=

As you can see, the comments I labeled as Major are mostly related to secur= ity considerations, where I think there's more to add, and clarity with res= pect to the behavior in RFC4271. I don't think that any of the commen= t will be hard to address.

I will wait for your comments/discussion and/or an update before starting t= he IETF Last Call.

Thanks!

Alvaro.

Major:

Should this document be marked as updating rfc4271? There are several= places in Section 2 where the behavior is different than what is specified= in rfc4271. Given that the route server functionality is an optional= enhancement, I don't think this document should be marked as updating rfc4271 (I.e. It changes the behavior only fo= r the functionality specified here). I'm assuming the authors/WG agre= e since there is no indication of an update. Please include a clear s= tatement (maybe in the Introduction) to the fact that the mechanism is optional.
Section 2.1. (Client UPDATE Messages). "The route server SHOULD f= orward UPDATE messages where appropriate=85to its clients." When= is it appropriate? I'm guessing that you mean something like "w= here local policy permits".. Please be clear.
Section 2.2.2. (AS_PATH Attribute) Not prepending the route serv= er's AS_PATH brings up a couple of issues/questions:
- RFC4271 talks about prepending the local ASN (when advertising to an EBGP p= eer), and it doesn't mention any exceptions. This document includes a= n exception. Clearly indicate the modifications to Section 5.1.2= . (AS_PATH) of RFC4271.
- Section 6.3. (UPDATE Message Error H= andling) of rfc4271 says that when an "=85UPDATE message is received f= rom an external peer, the local system MAY check whether the leftmost=85AS in the AS_PATH attribute is equal to the autonomous system number of the peer that sent= the message&= quot;, and MUST send a NOTIFICATION if it doesn't.
  - Please be explicit ab= out the required behavior for both the route server, and the clients.
  - Even though this chec= k is optional in RFC4271, mandating that is not be done could be interprete= d as a security issue. Please include some text around it (and mitiga= tion) in the Security Considerations section.
- Independent of the check, not in= cluding an ASN in the AS_PATH could (in the general case) result in loops; = which I also interpret as a potential security issue. Please inc= lude some text about this too =97 a mitigation option is clearly to not check the first ASN only when known route servers are pe= ers.
Section 2.2.4. (Communities Attributes) says that Communities "SHOULD NOT be modifi= ed, processed or removed. However, if such an attribute is intended for processing by the route server itself, it MAY be modified = or removed." How does the route server know if the sender intend= ed for a community to be processed by it, or not? Please add details.
3. (Security Consid= erations)
- Besides the points above, because cli= ents rely on the route server to implement outbound route filtering for the= m, there can be a privacy issue/route leak scenario where the route server = can send routes to clients that it shouldn't have. Not much can be done to mitigate this because it wil= l mostly be due to a bad implementation or simply a "bad operator"= ;.
- You should point at rel= evant sections of RFC7454.

Minor:

Please be consistent:
- s/exterior BGP/external BGP..or even just EBGP (yes, a nit..but that's = how rfc4271 calls EBGP)
- s/best path selection process/Decision Proc= ess
- s/IX/IXP
Section 2.2.3. (MULTI_EXIT_DISC Attribute) specificall= y calls out the MED, but you already said in Section 2.2. (Attribute Transparency) that all optional attributes "SHOULD NOT be = updated by the route server=85and SHOULD be passed on to other route <= /font>server clients.&quo= t; Is there anything special about the MED that I'm missing? If not, then you should be able to delete the section.
In Section 2.3.1. (Path Hiding on a Route Server) policy implementation is described in terms of outbound route filtering. &= nbsp;The description of the example says that if "AS1's policy prevents AS2's path from being accepted, then AS1 would never receive a path = to this prefix". &nb= sp;To be consistent with the outbound filtering description, you might want= to change that text to something like "AS2's policy prevents AS1 from receiving the path, =85".
Secti= on 2.3.2.2. (Advertising Mult= iple Paths) says that if the route server sends "more than a single path to a route server client,=85the path= hiding problem described in Section 2.3.1 would disappear." That statement i= s true, but only if all the paths are propagated, not just "more than a single" one. [You do talk about that in 2.3.2.= 2.1, but not the general case.]
Section 2.3.2.2.2. (BGP ADD-PATH Approach)
- This section says that if "the route server client= propagates m= ultiple paths for the same prefix to the route server, then this could potentially cause the propagation of inactive, invalid or suboptimal paths t= o the route server, thereby causing loss of reachability to other route server clients." I can see how suboptimal (=3D non best) paths can be = propagated by the clients, but what about invalid?
- To be consistent, there's no such thing as send-on= ly and receive-only modes negotiated with ADD-PATH. For the result in= the text (having only the route server send), the route server should adve= rtise the Send/Receive field in the ADD_PATH capability set to 2 (only able to send). It doesn't = matter what the client sets the value to (as long as it is not 2).
References: I think the fo= llowing can be made Informational: RFC1997, RFC4360

Nits:

Given that Section 2.3 is "included for information pu= rposes only", you might want to consider making it an Appendix.

Section 2.3.3. (Implementation Suggestions) seems superfluous to me.

--_000_D29085C4EFB5Aaretanaciscocom_-- From nobody Fri Dec 11 12:39:46 2015 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A15371A884D; Fri, 11 Dec 2015 12:39:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151211203942.24013.57206.idtracker@ietfa.amsl.com> Date: Fri, 11 Dec 2015 12:39:42 -0800 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-add-paths-13.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2015 20:39:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Advertisement of Multiple Paths in BGP Authors : Daniel Walton Alvaro Retana Enke Chen John Scudder Filename : draft-ietf-idr-add-paths-13.txt Pages : 8 Date : 2015-12-11 Abstract: This document defines a BGP extension that allows the advertisement of multiple paths for the same address prefix without the new paths implicitly replacing any previous ones. The essence of the extension is that each path is identified by a path identifier in addition to the address prefix. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-add-paths/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-add-paths-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-add-paths-13 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 nobody Mon Dec 14 09:10:20 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0203F1ACD86; Mon, 14 Dec 2015 09:10:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id If7eqhTkxtTN; Mon, 14 Dec 2015 09:10:14 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0735.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:735]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9C121ACDA7; Mon, 14 Dec 2015 09:10:01 -0800 (PST) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; Received: from [172.29.35.202] (66.129.241.13) by DM2PR05MB462.namprd05.prod.outlook.com (10.141.105.11) with Microsoft SMTP Server (TLS) id 15.1.337.19; Mon, 14 Dec 2015 17:09:39 +0000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 8.2 $2104$) From: "John G. Scudder" In-Reply-To: <20151214170534.11198.66446.idtracker@ietfa.amsl.com> Date: Mon, 14 Dec 2015 12:09:09 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20151214170534.11198.66446.idtracker@ietfa.amsl.com> To: "sidr@ietf.org list" , idr wg X-Mailer: Apple Mail (2.2104) X-Originating-IP: [66.129.241.13] X-ClientProxiedBy: BY2PR08CA039.namprd08.prod.outlook.com (10.141.248.157) To DM2PR05MB462.namprd05.prod.outlook.com (10.141.105.11) X-Microsoft-Exchange-Diagnostics: 1; DM2PR05MB462; 2:20KoHaua4bDk5hLsf301C1YnMqs4U4G/cdiwO3nb24CH5FDMQh/S7bADYNTQ4kQ/IIp+J6FBfAcg17YhAAepMjgHGKQAeJbfwXKY+wlUpV3BTgYNj5cuq5ENlzomeiJDcMkQZtHWJwWmlWVrXZEgFQ==; 3:y8YAGeLzXsccbTAGKI8qwecZsrapm1HqDmT71Jn7lW3b2d188DPOPTT/GDpnI9E4hFYkWSmL/kU9pYOyR1K1L/j1Da0nWv+aSGxKd/PYVSoFa3SIMwsDkSQdzZ86ZSKu; 25:vEAT/0HMaJZHjT8vvSb4cEjU5LkGYHH/96HUzqUyLBEYZaEzzh2/6RudBK/B4ZwujYcMdUdeeMJ1aNOQ/kG/JaRDzMpoyn4yBmaJPHkX4vsjbaBGo9ZlyzFtldZGINx64mBqKdEKDZhlLf+FIeRx2z5eiNW8iBL2T5mwDU4xEZlbKDEjYwLTkptub1slborTdruxaY04EOwGL4Y39rmdcgoeu677pMN2tMohjHeUth0wjDuQSBC92QYMSmprKQnlvT+KF7IEjkegeKJVcuWFwA== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR05MB462; X-Microsoft-Exchange-Diagnostics: 1; DM2PR05MB462; 20:hQt5waiRVl73oIPuEkzqs83CCOExMiYiH1ZLwghfyIr46fBvaVa0qZW11YgX8wPKKqVYIJXC2LY5oAjGdSECPq+1pSQJYVV75bk2LohRZ8t88Tw1546HfhDyIl7suxyEqVnr4Zq6cXEsabUiiMspvdp0Q8u5NRtA+nYC71T2sMxemo1FO8V/jJBwy5to/2un/sojjDuC99c9vHEEe7QUDTtLzXTEF3uujnfzA7KfKRI7ck4pZgoTMwh9xnCbQhF8UvX7Y115oolpBTsWmgMOLu5peWpkOfIA927ZOMGVNOjNlW1fs0kIBXldaSDOFHdXk7nCoInPwMnfWwbUN8mVSKmAD9dA2GQ3gxOV3uxj0GXlJeNr+fkTuoz/2kD3iRTVG6Kx6ybPE3FJbtXTzX2vNp1mo9ZoMHBCMwrIizizyuLikhzGtkO9HeFMmmzGlS7Rreqt8Qvt1XSKf0a7L2AwNvOsXSy6erpSg2LDIa5B4YhwXSz20qRP+JLRv+WmZuCh; 4:vkZkKczDh0/ZbMCVBEPCv7+iyUhRr1MeMghPc5gp0JaUY6J7UaHo7AfFwc3DSsDm6zV+BQy2TMrPVv9d36kgllT3ZTmJ9dT7iavF5jRQiuml1mQubZNIbvs8EIvtVvAr8/T4WKM+O0aM0gJ9o6xorsaeSA/3MkYfUNzaNmiAFi2yh8RaLa9Q6RsjnUgUGyksja/KoJVCIIVUIq/+9X5N/fJiFQjNaIyLUj5jUe7lMoohYNUrnJnSQZIvAD/N1Y8x27jJd4lOq2bjT0XiygTycMHfrOfIWsxCOwF3D2f8R98C9gBfK++iSsSw26b3WgECP7XRxOsTqLPXrsN406FYcADslAisRounI2NEH++EKLFNapnZf7LLgeBqD4a5ypYq X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(10201501046); SRVR:DM2PR05MB462; BCL:0; PCL:0; RULEID:; SRVR:DM2PR05MB462; X-Forefront-PRVS: 0790FB1F33 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(6009001)(377454003)(377424004)(53754006)(164054003)(24454002)(189002)(199003)(5008740100001)(450100001)(66066001)(33656002)(47776003)(87976001)(83716003)(586003)(23726003)(82746002)(1096002)(230783001)(50466002)(76176999)(3846002)(6116002)(101416001)(122386002)(40100003)(77096005)(81156007)(86362001)(50226001)(92566002)(42186005)(97756001)(46406003)(5001770100001)(36756003)(97736004)(50986999)(107886002)(2950100001)(5001960100002)(105586002)(189998001)(106356001)(19580405001)(4001150100001)(19580395003)(5004730100002)(57306001)(15975445007)(104396002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR05MB462; H:[172.29.35.202]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM2PR05MB462; 23:JqvtOQBE6U7M+Wccr7A9jT2BTiFJbV9ZlxMl7CIN5V?= =?us-ascii?Q?fUj7fKsVoO7euIoYq9GFd1cGeym03eDdAQGuSTDhXuasPz16TPdPd5XFAUT8?= =?us-ascii?Q?DcKlp8zeCfaWN2srb0BhyWB/ACxJpeI+0XYyfxI+bCb/DPS3WsFquG5RCkw+?= =?us-ascii?Q?fj5cUkKY7J4V6uMvqhLsRQB6mzX5DftnioQLyPblFWkD528PqG8pevHLp5jG?= =?us-ascii?Q?0vGQMJwfXT0foZySHn8cFjgqaJ+2S2/D4QBsTfuT9dxABMK62RZ9SKKGnUCn?= =?us-ascii?Q?IlMwYdrvVEhdanG7foU9MtfczNIJpFHrOUYmKqognWq3pKbB4ZOsoLmo6wBa?= =?us-ascii?Q?AUJzooyhNlNf+2WzzPBR3MImQk5heo5v5qd17i6g6lIx1bYFZneMDzCZ+I+I?= =?us-ascii?Q?l77KJQ6eRM5cfq/m/TqTDNw4NX8eMzcoSJMBy7P538tOjrEggZHvVAvUjDof?= =?us-ascii?Q?Pui8CY0+l8O99uHtm6qwcRCyWC92eqryJONXhmTd6HAIBJbuQ0kuXK8M02ql?= =?us-ascii?Q?r8VRVW4a8dV+mvNL8iBLxKZaSUCmWBK08xrNrJ0oayip+Xc1+z9nDKUQ1MQV?= =?us-ascii?Q?8EdAIBTtDLi6nHp1xNemL+AyulnoEbvWfocZO5jduk+HUdxA8jIiGtE10sd8?= =?us-ascii?Q?efGJQo4xSTdcttv1aZEsUlhfjAh/iWe9E5HI14TaZ3K/YgU8myRIEPPpIAx3?= =?us-ascii?Q?jh6cQuY1gpQQ51LjnE6YxSGBR7uLDvLbnbGyweu2hSggrlmEVLlz7ftA3CYV?= =?us-ascii?Q?w6mvnvh/NJs5oq5H0YEA5UX7s8wkkx/mkkWD+lJxqCH7D8kxFCcydcX5Isah?= =?us-ascii?Q?+2pr1b3qtbWBgQWmZfIAdIUNh0qPCrmEAIoc1hxolTSxV8VEgTB9Dc2Ysi+j?= =?us-ascii?Q?YFsN6Np4NISJpwzDinQW22bF9lD0tSt17ywmVmJUjJ0S/9pxBsa6G/oFUJvP?= =?us-ascii?Q?JQf+oI/BP3CrZuB1J1pNI08hhtBi/k9RHOJIacqqRT2erPiVNG6aDLXHdtpg?= =?us-ascii?Q?TmRe0pKcEEdLMr7+DX82lt8ITBP5ZZfQLvgim8srr4qQzgs7EfBz6MdbzXMZ?= =?us-ascii?Q?SfcGt41Ku4bVIUEB1xBJk1PL1T7O7DOY+p6Kgj1bffiM6H9LAN21t3FDGa+w?= =?us-ascii?Q?t76vtEmtYKworXkfnyxNfeSTwkTDVNnWy6OZWpqwcHUqrR1jEShCjn2E8AsO?= =?us-ascii?Q?prSxeRclIp48URJ1i1Tk8dvlJ67MHBg7PqtzkoZ1Ma4Byv7+sDjFYfeM4ErM?= =?us-ascii?Q?ZSQny4IC4YWq1I8HbYNt7GJjoS83TATdQpi7YPYY1lNZQWyqskONp780nA18?= =?us-ascii?Q?yJUqtXZdHLvUDh0jqZRLeUrw4om2ru/eizyE66ilGR9quTs0Fi3825Z3yN7E?= =?us-ascii?Q?bXizat14NYpxMbm//ymyQqQSpLm+v6sp1+eYCuYm470YMB?= X-Microsoft-Exchange-Diagnostics: 1; DM2PR05MB462; 5:1PuIrB1BAnalQZHaWF+Y6vDYWLQ9e/mx4qKQfT8+9Zuv/OeK37aVzGXM007VdAlWyZanmEGD+tuII5I5MlZR05qDms1ngaQnqLjSRz1CjTF0fNOxuTBffTRLqo7IOwRElGpiazQ8nXL7Om6wxEq20A==; 24:YXkJ7kdMN+g8DShYuUQTnjhcC32U/ZApTWfGRCmDhYPsN+OAU1bULRj2WAevNKGv4O/KQo93ljZk8WMVFt1BpdlOGteXAAxIu+kclXhuJGo= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Dec 2015 17:09:39.7173 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR05MB462 Archived-At: Subject: Re: [Idr] [sidr] I-D Action: draft-ietf-sidr-origin-validation-signaling-08.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2015 17:10:17 -0000 Hi Everybody, Just when we thought we were completely done with this draft, we were = approached by Thomas King who pointed out a use case that can be enabled = by validation signaling, which benefits from a minor revision in the = language of the draft. Here's the revision: OLD: By default, implementations SHOULD drop the origin validation state extended community if received from an EBGP peer, without further processing it. However an implementation MAY be configured to accept the community when warranted, for example when the EBGP session is to a neighbor AS under control of the same administration. Similarly, an implementation SHOULD NOT send the community to EBGP peers but MAY be configured to do so if warranted. NEW: By default, implementations SHOULD drop the origin validation state extended community if received from an EBGP peer, without further processing it. Similarly, by default an implementation SHOULD NOT send the community to EBGP peers. However it SHOULD be possible to configure an implementation to send or accept the community when warranted. An example of a case where the community would reasonably be received from, or sent to, an EBGP peer is when two adjacent ASes are under control of the same administration. A second example is documented in [I-D.kklf-sidr-route-server-rpki-light]. The change does two things. One is to add an informative reference to = Thomas's draft. The second is a change in emphasis. Whereas we formerly = said that an implementation MAY be configured to send and/or receive the = community over EBGP, now we say it SHOULD be possible to configure it to = do that. I'm hoping this change will be noncontroversial and we can continue to = move forward towards RFC, however I anticipate the respective working = group chairs of SIDR and IDR (for obvious reasons I'm recusing myself) = may want to have a period to allow people to comment. Thanks, --John > On Dec 14, 2015, at 12:05 PM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Secure Inter-Domain Routing Working = Group of the IETF. >=20 > Title : BGP Prefix Origin Validation State Extended = Community > Authors : Pradosh Mohapatra > Keyur Patel > John Scudder > Dave Ward > Randy Bush > Filename : = draft-ietf-sidr-origin-validation-signaling-08.txt > Pages : 5 > Date : 2015-12-14 >=20 > Abstract: > This document defines a new BGP opaque extended community to carry > the origination AS validation state inside an autonomous system. > IBGP speakers that receive this validation state can configure local > policies allowing it to influence their decision process. >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-sidr-origin-validation-signali= ng/ >=20 > There's also a htmlized version available at: > = https://tools.ietf.org/html/draft-ietf-sidr-origin-validation-signaling-08= >=20 > A diff from the previous version is available at: > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-origin-validation-sign= aling-08 >=20 >=20 > 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. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Mon Dec 14 09:50:13 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 810D11ACEBA; Mon, 14 Dec 2015 09:50:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.578 X-Spam-Level: X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iPtjfvyzD939; Mon, 14 Dec 2015 09:50:10 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id B8E281ACEAF; Mon, 14 Dec 2015 09:50:10 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id EC3CA1E45D; Mon, 14 Dec 2015 12:51:28 -0500 (EST) Date: Mon, 14 Dec 2015 12:51:28 -0500 From: Jeffrey Haas To: "John G. Scudder" Message-ID: <20151214175128.GA28772@pfrc.org> References: <20151214170534.11198.66446.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: idr wg , "sidr@ietf.org list" Subject: Re: [Idr] [sidr] I-D Action: draft-ietf-sidr-origin-validation-signaling-08.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: