From nobody Tue Mar 1 06:21:18 2016 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 351321A8865 for ; Tue, 1 Mar 2016 06:21:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.304 X-Spam-Level: X-Spam-Status: No, score=-1.304 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 fDXgglcrkNxH for ; Tue, 1 Mar 2016 06:21:11 -0800 (PST) Received: from relais-inet.orange.com (relais-nor34.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 550C31A884F for ; Tue, 1 Mar 2016 06:21:10 -0800 (PST) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id 9197AC01F5; Tue, 1 Mar 2016 15:21:08 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.41]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 4D35820069; Tue, 1 Mar 2016 15:21:08 +0100 (CET) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM31.corporate.adroot.infra.ftgroup ([fe80::2cc9:4bac:7b7d:229d%19]) with mapi id 14.03.0279.002; Tue, 1 Mar 2016 15:21:08 +0100 From: To: t.petch Thread-Topic: [Idr] [Technical Errata Reported] RFC4271 (4493) Thread-Index: AQHRbi/fOOzET0QUjEyatKu8IRwkd59EqhBw Date: Tue, 1 Mar 2016 14:21:07 +0000 Message-ID: <26208_1456842068_56D5A554_26208_2227_1_53C29892C857584299CBF5D05346208A0F7DE5DB@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <20151006081045.66A82187E04@rfc-editor.org> <008901d169a6$cc3d1da0$4001a8c0@gateway.2wire.net> <6928_1455786507_56C58A0B_6928_729_1_53C29892C857584299CBF5D05346208A0F7CE538@OPEXCLILM21.corporate.adroot.infra.ftgroup> <006d01d16e2f$f6b60fa0$4001a8c0@gateway.2wire.net> In-Reply-To: <006d01d16e2f$f6b60fa0$4001a8c0@gateway.2wire.net> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A0F7DE5DBOPEXCLILM21corp_" MIME-Version: 1.0 Archived-At: Cc: "idr@ietf.org" Subject: Re: [Idr] [Technical Errata Reported] RFC4271 (4493) 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 Mar 2016 14:21:16 -0000 --_000_53C29892C857584299CBF5D05346208A0F7DE5DBOPEXCLILM21corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Tom, Please see inline [Bruno2] > From: t.petch [mailto:ietfc@btconnect.com] > Sent: Tuesday, February 23, = 2016 12:47 PM > > > Tom Petch > > ----- Original Message ----- > From: > > To: "t.petch" >; "Alvaro = Retana (aretana)" > >; > > Sent: Thursday, February 18, 2016 9:08 > > > Hi Tom, > > Please see inline > > > From: t.petch [mailto:ietfc@btconnect.com] > Sent: Wednesday, February > 17, 2016 6:15 PM > > > > ----- Original Message ----- > > From: "Alvaro Retana (aretana)" > > > To: > > > Cc: > > > Sent: Wednesday, February 17, 2016 3:08 PM > > > > Idr WG: > > > > Please take a look at the Errata below. I need your opinion on it. > > > > I'm leaning towards rejecting it because I interpret "Unspecific" not > as > > the name of the subcode, but as just an indication that the error is > not > > specific. The IANA registry [1] lists the value 0 as "Reserved", > which > > I > > think is ok according to the definition in RFC5226: > > > > > > > > Reject. > > > > s.6.2 specifies a specific(!) instance of using 0(Unspecific) (so I > > think that IANA is in error here). Arguably, you could raise an > erratum > > to add 0(Unspecific) for the OPEN Message Error subcodes list > > Agreed. > > > but I > > think that it would be a technical change to add it for the other > > messages. As currently defined, it could be seen as an implementation > > error were subcode 0 be used for the other messages (an interpretation > > which I have no problem with). > > I don't think you can call "implementation error" a behavior which is > specified in the RFC: > "If no appropriate Error Subcode is defined, then a zero (Unspecific) > value is used for the Error Subcode field." > https://tools.ietf.org/html/rfc4271#section-4.5 > > This sentence is generic and applies to all error codes. > > > > Ah yes, my mistake. > > On balance, I would still support an Erratum that updates "OPEN Message > Error subcodes:" but would see updating all the lists of subcodes as > going too far. > > A zero subcode for any other message is not something that the IDR WG > could think of a reason for, unlike the case of OPEN, so while calling > it an error is wrong, it remains something unusual, unexpected. Adding > it to all the lists of subcodes would seem to go beyond what the IDR WG > consented to when it produced RFC4271. [Bruno2] I'm not asking to change the protocol specification (RFC 4271). I'm asking that the IANA section and the IANA registry be updated so that t= he sub-code "0" be marked as already allocated, so that we don't risk a col= lision in some hypothetical future. And I'm quoting the existing RFC 4271 stating that the use of this sub-code= 0 _is_ specified in RFC 4271, for _all_ error code. I'm reading it in RFC= 4271 at least twice: 6.1. Message Header Error Handling [...] When any of the conditions described here are detected, a NOTIFICATION message, with the indicated Error Code, Error Subcode, and Data fields, is sent, and the BGP connection is closed (unless it is explicitly stated that no NOTIFICATION message is to be sent and the BGP connection is not to be closed). If no Error Subcode is specified, then a zero MUST be used. https://tools.ietf.org/html/rfc4271#section-6 And as already stated, in 4.5. NOTIFICATION Message Format [...] Error Code: This 1-octet unsigned integer indicates the type of NOTIFICATION. The following Error Codes have been defined: Error Code Symbolic Name Reference 1 Message Header Error Section 6.1 2 OPEN Message Error Section 6.2 3 UPDATE Message Error Section 6.3 4 Hold Timer Expired Section 6.5 5 Finite State Machine Error Section 6.6 6 Cease Section 6.7 Error subcode: This 1-octet unsigned integer provides more specific information about the nature of the reported error. Each Error Code may have one or more Error Subcodes associated with it. If no appropriate Error Subcode is defined, then a zero (Unspecific) value is used for the Error Subcode field. https://tools.ietf.org/html/rfc4271#section-4.5 You may disagree with my reading of RFC4271, but if so, please quote/discus= s RFC 4271 text -- Bruno > Tom Petch > > Accepting the errata or not is a different story. > > -- Bruno > > > > If there are errors that cannot be reported using the subcodes in > > RC4271, then that is a separate issue that could be worth > investigating. > > > > Tom Petch > > > > > > Reserved: Not to be assigned. Reserved values are held for > > special uses, such as to extend the namespace when it > become > > exhausted. Reserved values are not available for general > > assignment. > > > > In this case the "special use" is when the error is not specific. > > > > Any thoughts? Other opinions? > > > > Thanks! > > > > Alvaro. > > > > [1] > > http://www.iana.org/assignments/bgp-parameters/bgp- > > parameters.xhtml#bgp- > > par > > ameters-4 > > > > On 10/6/15, 4:10 AM, "RFC Errata System" > > > wrote: > > > > >The following errata report has been submitted for RFC4271, > > >"A Border Gateway Protocol 4 (BGP-4)". > > > > > >-------------------------------------- > > >You may review the report below and at: > > >http://www.rfc-editor.org/errata_search.php?rfc=3D4271&eid=3D4493 > > > > > >-------------------------------------- > > >Type: Technical > > >Reported by: Bruno Decraene > > > > > > >Section: 4.5 > > > > > >Original Text > > >------------- > > >=A7\\"4.5 NOTIFICATION Message Format\\" says: > > > > > > Message Header Error subcodes: > > > > > > 1 - Connection Not Synchronized. > > > 2 - Bad Message Length. > > > 3 - Bad Message Type. > > > > > > OPEN Message Error subcodes: > > > > > > 1 - Unsupported Version Number. > > > 2 - Bad Peer AS. > > > 3 - Bad BGP Identifier. > > > 4 - Unsupported Optional Parameter. > > > 5 - [Deprecated - see Appendix A]. > > > 6 - Unacceptable Hold Time. > > > > > > UPDATE Message Error subcodes: > > > > > > 1 - Malformed Attribute List. > > > 2 - Unrecognized Well-known Attribute. > > > 3 - Missing Well-known Attribute. > > > 4 - Attribute Flags Error. > > > 5 - Attribute Length Error. > > > 6 - Invalid ORIGIN Attribute. > > > 7 - [Deprecated - see Appendix A]. > > > 8 - Invalid NEXT_HOP Attribute. > > > 9 - Optional Attribute Error. > > > 10 - Invalid Network Field. > > > 11 - Malformed AS_PATH. > > > > > >Corrected Text > > >-------------- > > > Message Header Error subcodes: > > > > > > 0 - Unspecific. > > > 1 - Connection Not Synchronized. > > > 2 - Bad Message Length. > > > 3 - Bad Message Type. > > > > > > OPEN Message Error subcodes: > > > > > > 0 - Unspecific. > > > 1 - Unsupported Version Number. > > > 2 - Bad Peer AS. > > > 3 - Bad BGP Identifier. > > > 4 - Unsupported Optional Parameter. > > > 5 - [Deprecated - see Appendix A]. > > > 6 - Unacceptable Hold Time. > > > > > > UPDATE Message Error subcodes: > > > > > > 0 - Unspecific. > > > 1 - Malformed Attribute List. > > > 2 - Unrecognized Well-known Attribute. > > > 3 - Missing Well-known Attribute. > > > 4 - Attribute Flags Error. > > > 5 - Attribute Length Error. > > > 6 - Invalid ORIGIN Attribute. > > > 7 - [Deprecated - see Appendix A]. > > > 8 - Invalid NEXT_HOP Attribute. > > > 9 - Optional Attribute Error. > > > 10 - Invalid Network Field. > > > 11 - Malformed AS_PATH. > > > > > >Notes > > >----- > > >RFC 4271 defines a use and a name for Error subcode 0: > > >- =A74.5 (any error code): > > > If no appropriate Error Subcode is defined, then a zero > > > (Unspecific) value is used for the Error Subcode field. > > > > > >- =A76.2 (OPEN error code): > > > If one of the Optional Parameters in the OPEN message is > recognized, > > > but is malformed, then the Error Subcode MUST be set to 0 > > > (Unspecific). > > > > > >If verified, the \\"IANA Considerations\\" section = and the IANA > > registry > > >would also need to be updated accordingly (currently says \\"0 > > >Reserved\\") > > >http://www.iana.org/assignments/bgp-parameters/bgp- > > parameters.xhtml#bgp > > -pa > > >rameters-4 > > > > > >Instructions: > > >------------- > > >This erratum is currently posted as "Reported". If necessary, please > > >use "Reply All" to discuss whether it should be verified or > > >rejected. When a decision is reached, the verifying party (IESG) > > >can log in to change the status and edit the report, if necessary. > > > > > >-------------------------------------- > > >RFC4271 (draft-ietf-idr-bgp4-26) > > >-------------------------------------- > > >Title : A Border Gateway Protocol 4 (BGP-4) > > >Publication Date : January 2006 > > >Author(s) : Y. Rekhter, Ed., T. Li, Ed., S. Hares, Ed. > > >Category : DRAFT STANDARD > > >Source : Inter-Domain Routing > > >Area : Routing > > >Stream : IETF > > >Verifying Party : IESG > > > > > > > _______________________________________________ > > Idr mailing list > > Idr@ietf.org > > https://www.ietf.org/mailman/listinfo/idr > > > ______________________________________________________________ > __________ > _________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles 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 > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme > ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have > been modified, changed or falsified. > Thank you. ___________________________________________________________________________= ______________________________________________ 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, Orange decline toute responsabilite si ce message a ete altere, 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 authorisation. 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, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_53C29892C857584299CBF5D05346208A0F7DE5DBOPEXCLILM21corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Tom,

 

Please see inline [Bruno2]

 

> From: t.petch [mailto:ietfc@btconnect.com] > <= span lang=3D"EN-US" style=3D"mso-ansi-language:EN-US;mso-fareast-language:F= R">Sent: Tuesday, February 23, 2016 12:47 PM

>

> <inline>

> Tom Petch

>

> ----- Original Message -----

> From: <bruno.decraene@orange.com>

> To: "t.petch" <ietfc@btconnect.com>; "Alvaro Reta= na (aretana)"

> <aret= ana@cisco.com>; <idr@ietf.o= rg>

> Sent: Thursday, February 18, 2016 9:08

>

>

> Hi Tom,

>

> Please see inline

>

> > From: t.petch [mailto:ietfc@btconnect.com] > Sent: Wednesday, = February

> 17, 2016 6:15 PM

> >

> > ----- Original Message -----

> > From: "Alvaro Retana (aretana)&quo= t; <aretana@cisco.com>=

> > To: <= idr@ietf.org>

> > Cc: <bruno.decraene@orange.com>

> > Sent: Wednesday, February 17, 2016 3:08= PM

> >

> > Idr WG:

> >

> > Please take a look at the Errata below.=   I need your opinion on it.

> >

> > I'm leaning towards rejecting it becaus= e I interpret "Unspecific" not

> as

> > the name of the subcode, but as just an= indication that the error is

> not

> > specific.  The IANA registry [1] lists the value 0 as "Reserved&= quot;,

> which

> > I

> > think is ok according to the definition= in RFC5226:

> >

> > <tp>

> >

> > Reject.

> >

> > s.6.2 specifies a specific(!) instance = of using 0(Unspecific) (so I

> > think that IANA is in error here).  Arguably, you could raise an

> erratum

> > to add 0(Unspecific) for the OPEN Messa= ge Error subcodes list

>

> Agreed.

>

> > but I

> > think that it would be a technical chan= ge to add it for the other

> > messages.  As currently defined, it could be seen as an implementatio= n

> > error were subcode 0 be used for the ot= her messages (an interpretation

> > which I have no problem with).

>

> I don't think you can call "implementat= ion error" a behavior which is

> specified in the RFC:

> "If no appropriate Error Subcode is def= ined, then a zero (Unspecific)

> value is used for the Error Subcode field.&q= uot;

> h= ttps://tools.ietf.org/html/rfc4271#section-4.5

>

> This sentence is generic and applies to all = error codes.

>

> <tp>

>

> Ah yes, my mistake.

>

> On balance, I would still support an Erratum= that updates "OPEN Message

> Error subcodes:" but would see updating= all the lists of subcodes as

> going too far.

>

> A zero subcode for any other message is not = something that the IDR WG

> could think of a reason for, unlike the case= of OPEN, so while calling

> it an error is wrong, it remains something u= nusual, unexpected.  Adding

> it to all the lists of subcodes would seem t= o go beyond what the IDR WG

> consented to when it produced RFC4271.

 

[Bruno2]

I'm not asking to change the protocol specification (RFC 4271).<= /o:p>

I'm asking that the IANA section and the IANA registry be updated so = that the sub-code "0" be marked as already allocated, so that we don= 't risk a collision in some hypothetical future.

 

And I'm quoting the existing RFC 4271 stating that the use of this su= b-code 0 _is_ specified in RFC 4271,  for _all_ error code. = I'm reading it in RFC 4271 at least twice:

 

6.1.  Message Header Error Handling

[...]

   When any of the conditions described here are detected, a=

   NOTIFICATION message, with the indicated Error Code, Error Subcode,

   and Data fields, is sent, and the BGP c= onnection is closed (unless it

   is explicitly stated that no NOTIFICATI= ON message is to be sent and

   the BGP connection is not to be closed<= span style=3D"background:yellow;mso-highlight:yellow">).  If no Error Subcode is

   specified, then a zero MUST be used.

 

https://too= ls.ietf.org/html/rfc4271#section-6

 

 

And as already stated, in

4.5.  NOTIFICATION Message Format

[...]

      Error Code:

 

      =    This 1-octet unsigned integer indicates the type of

      =    NOTIFICATION.  The following Error Codes have been defined:

 

      =       Error Code    &= nbsp;  Symbolic Name &nbs= p;             Reference

 

      =         1     &nbs= p;   Message Header Error=              Section 6.1

 

      =         2     &nbs= p;   OPEN Message Error&n= bsp;            = ;  Section 6.2

 

      =         3     &nbs= p;   UPDATE Message Error=              Section 6.3

 

      =         4     &nbs= p;   Hold Timer Expired&n= bsp;            = ;  Section 6.5

 

      =         5     &nbs= p;   Finite State Machine Error       Section 6.6

 

      =         6         Cease        &n= bsp;            = ;       Section 6.7

 

      Error subcode:

 

      =    This 1-octet unsigned integer provides more specific

      =    information about the nature of the rep= orted error.  Each Error

      =    Code may have one or more Error Subcodes associated with it.

      =    If no appropr= iate Error Subcode is defined, then a zero

         (Unspecific) value is used for the Error Subc= ode field.  

 

https://tools.ietf.org/html/rfc4271#section-4.5

 

 

You may disagree with my reading of RFC4271, but if so, p= lease quote/discuss RFC 4271 text

 

-- Bruno

 

> Tom Petch

>

> Accepting the errata or not is a different s= tory.

>

> -- Bruno

>

>

> > If there are errors that cannot be repo= rted using the subcodes in

> > RC4271, then that is a separate issue t= hat could be worth

> investigating.

> >

> > Tom Petch

> >

> >

> > &= nbsp;     Reserved:  Not to be assigned.  Re= served values are held for

> > &= nbsp;           sp= ecial uses, such as to extend the namespace when it

> become

> > &= nbsp;           ex= hausted.  Reserved values are not available for general

> > &= nbsp;           as= signment.

> >

> > In this case the "special use"= ; is when the error is not specific.

> >

> > Any thoughts?  Other opinions?

> >

> > Thanks!

> >

> > Alvaro.

> >

> > [1]

> > h= ttp://www.iana.org/assignments/bgp-parameters/bgp-

> > parameters.xhtml#bgp-

> > par

> > ameters-4

> >

> > On 10/6/15, 4:10 AM, "RFC Errata S= ystem" <rfc-editor@rfc-= editor.org>

> > wrote:

> >

> > >The following errata report has bee= n submitted for RFC4271,

> > >"A Border Gateway Protocol 4 (= BGP-4)".

> > >

> > >-----------------------------------= ---

> > >You may review the report below and= at:

> > >http://www.rfc-editor.org/err= ata_search.php?rfc=3D4271&eid=3D4493

> > >

> > >-----------------------------------= ---

> > >Type: Technical

> > >Reported by: Bruno Decraene <bruno.decraene@orange.com>

> > >

> > >Section: 4.5

> > >

> > >Original Text

> > >-------------

> > >=A7\\"4.5 NOTIFICATION Message= Format\\" says:

> > >

> > >&n= bsp;     Message Header Error subcodes:

> > >

> > >&n= bsp;            = ;  1 - Connection Not Synchronized.

> > >&n= bsp;            = ;  2 - Bad Message Length.

> > >&n= bsp;            = ;  3 - Bad Message Type.

> > >

> > >&n= bsp;     OPEN Message Error subcodes:

> > >

> > >&n= bsp;            = ;  1 - Unsupported Version Number.

> > >&n= bsp;            = ;  2 - Bad Peer AS.

> > >&n= bsp;            = ;  3 - Bad BGP Identifier.

> > >&n= bsp;            = ;  4 - Unsupported Optional Parameter.

> > >&n= bsp;            = ;  5 - [Deprecated - see Appendix A].

> > >&n= bsp;            = ;  6 - Unacceptable Hold Time.

> > >

> > >&n= bsp;     UPDATE Message Error subcodes:

> > >

> > >&n= bsp;            = ;  1 - Malformed Attribute List.

> > >&n= bsp;            = ;  2 - Unrecognized Well-known Attribute.

> > >&n= bsp;            = ;  3 - Missing Well-known Attribute.

> > >&n= bsp;      =         4 - Attribute Flags = Error.

> > >&n= bsp;            = ;  5 - Attribute Length Error.

> > >&n= bsp;            = ;  6 - Invalid ORIGIN Attribute.

> > >&n= bsp;            = ;  7 - [Deprecated - see Appendix A].

> > >&n= bsp;            = ;  8 - Invalid NEXT_HOP Attribute.

> > >&n= bsp;            = ;  9 - Optional Attribute Error.

> > >&n= bsp;            = ; 10 - Invalid Network Field.

> > >&n= bsp;            = ; 11 - Malformed AS_PATH.

> > >

> > >Corrected Text

> > >--------------

> > >&n= bsp;     Message Header Error subcodes:

> > >

> > >&n= bsp;            = ;  0 - Unspecific.

> > > &= nbsp;           &nbs= p; 1 - Connection Not Synchronized.

> > >&n= bsp;            = ;  2 - Bad Message Length.

> > >&n= bsp;            = ;  3 - Bad Message Type.

> > >

> > >&n= bsp;     OPEN Message Error subcodes:

> > >

> > >&n= bsp;            = ;  0 - Unspecific.

> > >&n= bsp;            = ;  1 - Unsupported Version Number.

> > >&n= bsp;            = ;  2 - Bad Peer AS.

> > >&n= bsp;            = ;  3 - Bad BGP Identifier.

> > >&n= bsp;            = ;  4 - Unsupported Optional Parameter.

> > >&n= bsp;            = ;  5 - [Deprecated - see Appendix A].

> > >&n= bsp;            = ;  6 - Unacceptable Hold Time.

> > >

> > >&n= bsp;     UPDATE Message Error subcodes:

> > >

> > >&n= bsp;            = ;  0 - Unspecific.

> > >&n= bsp;            = ;  1 - Malformed Attribute List.

> > >&n= bsp;            = ;  2 - Unrecognized Well-known Attribute.

> > >&n= bsp;            = ;  3 - Missing Well-known Attribute.

> > >&n= bsp;            = ;  4 - Attribute Flags Error.

> > >&n= bsp;            = ;  5 - Attribute Length Error.

> > >&n= bsp;            = ;  6 - Invalid ORIGIN Attribute.

> > >&n= bsp;            = ;  7 - [Deprecated - see Appendix A].

> > >&n= bsp;            = ;  8 - Invalid NEXT_HOP Attribute.

> > >&n= bsp;              9 - Optional Attribu= te Error.

> > >&n= bsp;            = ; 10 - Invalid Network Field.

> > >&n= bsp;            = ; 11 - Malformed AS_PATH.

> > >

> > >Notes

> > >-----

> > >RFC 4271 defines a use and a name f= or Error subcode 0:

> > >- =A74.5 (any error code):

> > >&n= bsp;        If no appropriate Err= or Subcode is defined, then a zero

> > >&n= bsp;        (Unspecific) value is= used for the Error Subcode field.

> > >

> > >- =A76.2 (OPEN error code):

> > >&n= bsp;  If one of the Optional Parameters in the OPEN message is<= /p>

> recognized,

> > >&n= bsp;  but is malformed, then the Error Subcode MUST be set to 0=

> > >&n= bsp;  (Unspecific).

> > >

> > >If verified, the \\"IANA Considerations\\" section and the I= ANA

> > registry

> > >would also need to be updated accor= dingly (currently says \\"0

> > >Reserved\\")

> > >http://www.iana.org/assignments/bgp-parameters/= bgp-

> > parameters.xhtml#bgp

> > -pa

> > >rameters-4

> > >

> > >Instructions:

> > >-------------

> > >This erratum is currently posted as= "Reported". If necessary, please

> > >use "Reply All" to discus= s whether it should be verified or

> > >rejected. When a decision is reache= d, the verifying party (IESG)

> > >can log in to change the status and= edit the report, if necessary.

> > >

> > >-----------------------------------= ---

> > >RFC4271 (draft-ietf-idr-bgp4-26)

> > >-----------------------------------= ---

> > >Title            =    : A Border Gateway Protocol 4 (BGP-4)

> > >Publication Date    : January 2006

> > >Author(s)           : Y. Rekhter, Ed., T. Li, Ed., S. Hares, Ed.

> > >Category            : DRAFT STANDARD

> > >Source            = ;  : Inter-Domain Routing

> > >Area            &= nbsp;   : Routing

> > >Stream            = ;  : IETF

> > >Verifying Party     : IESG

> > >

> >

> > _______________________________________= ________

> > Idr mailing list

> > Idr@ietf= .org

> > https://www.ietf.org/mailman/listinfo/idr

>

>

> ____________________________________________= __________________

> __________

> ____________________________________________= _____

>

> Ce message et ses pieces jointes peuvent con= tenir des informations

> confidentielles ou privilegiees et ne doiven= t donc

> pas etre diffuses, exploites ou copies sans = autorisation. Si vous avez

> recu ce message par erreur, veuillez le sign= aler

> a l'expediteur et le detruire ainsi que les = pieces jointes. Les messages

> electroniques etant susceptibles d'alteratio= n,

> Orange decline toute responsabilite si ce me= ssage a ete altere, deforme

> ou falsifie. Merci.

>

> This message and its attachments may contain= confidential or privileged

> information that may be protected by law;

> they should not be distributed, used or copi= ed without authorisation.

> If you have received this email in error, pl= ease notify the sender and

> delete this message and its attachments.

> As emails may be altered, Orange is not liab= le for messages that have

> been modified, changed or falsified.

> Thank you.

 

______________________________________________________________________=
___________________________________________________

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,
Orange decline toute responsabilite si ce message a ete altere, 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 authorisation.
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, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_53C29892C857584299CBF5D05346208A0F7DE5DBOPEXCLILM21corp_-- From nobody Tue Mar 1 08:08:27 2016 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 869441B2E0D for ; Tue, 1 Mar 2016 08:08:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.507 X-Spam-Level: X-Spam-Status: No, score=-14.507 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, 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 EhxKgkAe1t5b for ; Tue, 1 Mar 2016 08:08:24 -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 B42C01B2DEF for ; Tue, 1 Mar 2016 08:08:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1426; q=dns/txt; s=iport; t=1456848504; x=1458058104; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=0FUJniikkDcl3n/9Nt8HojAOkyFq7t8xymMsDhSq8SY=; b=Nutda0G0jQqbW0K+QRdPNgK/J91TwcYoNy8nIocPaeItgNv+ZvXVUbHf Obo5T2DGtnWAbLrDcK45hOW0J3OeFQMqUhyjJQrxvpDpwKxZWzBb/LaZM 8ACE33dp4XVYAZNdQ3RBZbv9037wY9rMlBbCHVI5W2YlRm9/QMLAodoHT A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AJAgALvdVW/4ENJK1egzpSbQa6LgENg?= =?us-ascii?q?WYjhXACgUk4FAEBAQEBAQFkJ4RBAQEBAwE6PQcLAgEIGB4QMiUCBBOIFwgOwA4?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEBAQEVhhKBbIJOhDODLYEPBY0riWMBhViCb4Uag?= =?us-ascii?q?WBLg3mIUo5LAR4BAUKCMIE0agGHQn4BAQE?= X-IronPort-AV: E=Sophos;i="5.22,523,1449532800"; d="scan'208";a="81204181" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Mar 2016 16:08:23 +0000 Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u21G8NgL005869 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 1 Mar 2016 16:08:23 GMT Received: from xch-aln-010.cisco.com (173.36.7.20) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 1 Mar 2016 10:08:23 -0600 Received: from xch-aln-010.cisco.com ([173.36.7.20]) by XCH-ALN-010.cisco.com ([173.36.7.20]) with mapi id 15.00.1104.009; Tue, 1 Mar 2016 10:08:22 -0600 From: "Stefano Previdi (sprevidi)" To: idr wg Thread-Topic: New Version Notification for draft-previdi-idr-bgpls-te-metric-extensions-01.txt Thread-Index: AQHRc9RXgbmePcQD8kOXyMJBH0ffgp9FJgMA Date: Tue, 1 Mar 2016 16:08:22 +0000 Message-ID: <730B58DB-551B-4E0E-8D02-EC4FDFD04828@cisco.com> References: <20160301160627.30415.96330.idtracker@ietfa.amsl.com> In-Reply-To: <20160301160627.30415.96330.idtracker@ietfa.amsl.com> 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.61.245.69] Content-Type: text/plain; charset="us-ascii" Content-ID: <38A890154D817D41A59F3CBD14D8D5F2@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] New Version Notification for draft-previdi-idr-bgpls-te-metric-extensions-01.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, 01 Mar 2016 16:08:26 -0000 Updated author-list (merged with previous incarnation of the daft). Note that the difference with this draft is the explicit encoding format of= the TLVs. s. > On Mar 1, 2016, at 5:06 PM, internet-drafts@ietf.org wrote: >=20 >=20 > A new version of I-D, draft-previdi-idr-bgpls-te-metric-extensions-01.txt > has been successfully submitted by Stefano Previdi and posted to the > IETF repository. >=20 > Name: draft-previdi-idr-bgpls-te-metric-extensions > Revision: 01 > Title: BGP-LS Traffic Engineering (TE) Metric Extensions > Document date: 2016-03-01 > Group: Individual Submission > Pages: 9 > URL: https://www.ietf.org/internet-drafts/draft-previdi-idr-bg= pls-te-metric-extensions-01.txt > Status: https://datatracker.ietf.org/doc/draft-previdi-idr-bgpls-= te-metric-extensions/ > Htmlized: https://tools.ietf.org/html/draft-previdi-idr-bgpls-te-me= tric-extensions-01 > Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-previdi-idr-bgp= ls-te-metric-extensions-01 >=20 > Abstract: > This document defines new BGP-LS TLVs in order to carry the IGP > Traffic Engineering Extensions defined in IS-IS and OSPF protocols. >=20 >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 From nobody Fri Mar 4 12:35:03 2016 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 4433C1A8998 for ; Fri, 4 Mar 2016 12:34:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.257 X-Spam-Level: X-Spam-Status: No, score=-98.257 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, FH_RELAY_NODNS=1.451, GB_I_INVITATION=-2, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.793, 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 4U4bkoznDyOv for ; Fri, 4 Mar 2016 12:34:57 -0800 (PST) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 138CC1A8997 for ; Fri, 4 Mar 2016 12:34:56 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.30; From: "Susan Hares" To: Date: Fri, 4 Mar 2016 15:34:18 -0500 Message-ID: <003401d17655$3a2472e0$ae6d58a0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0035_01D1762B.51517820" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdF2Uy3psDBctRRhT8ulPp+3LED1Ew== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: [Idr] BGP Interim on 3/4/2016 at 10:00am - 11:30am ET 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 Mar 2016 20:34:59 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0035_01D1762B.51517820 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable BGP interim will be held on Monday 3/7/2016 from 10:00am =E2=80=93 = 11:30am ET. =20 The topics are:=20 =20 1) BGP Flow Specification =E2=80=93 2 options for work [10:00 = =E2=80=93 11:00 am] =20 a. Option 1: Extension of current BGP Flow Specification=20 b. Option 2: Version 2 of BGP Flow Specification using new NLRI and = Wide BGP communities to allow ordering of filters and actions.=20 c. Option 3: Do both option 1 and option 2=20 =20 Documents discussed:=20 draft-hares-idr-bgp-flowspec-combo-01.txt=20 draft-eddy-idr-flowspec-packet-rate-00.txt draft-hao-idr-flowspec-nv03-03.txt=20 draft-hao-idr-redirect-tunnel-00.txt draft-liang-idr-bgp-flowspec-label-01.txt draft-liang-idr-bgp-flowspec-time-01.txt draft-litkowski-idr-flowspec-interfaceset-03.txt draft-vandevelde-idr-flowspec-path-redirect-01.txt draft-ietf-idr-wide-bgp-communities-01.txt=20 draft-ietf-idr-tunnel-encaps-01.txt draft-ietf-idr-flowspec-l2vpn-03.txt=20 draft-li-idr-flowspec-rpd-01.txt.=20 =20 2) Yang models [11:00am =E2=80=93 11:30]=20 a. BGP Flow Specification Yang model=20 b. BGP Extension models for BGP=20 =20 Documents discussed:=20 draft-wu-idr-flowspec-yang-cfg-02 draft-hares-idr-bgp-flowspec-combo-01.txt =20 draft-ietf-idr-bgp-model-01.txt=20 =20 =20 Web ex:=20 https://ietf.webex.com/ietf/j.php?MTID=3Dm944a81587e9ce48ff4c927d7545c145= 6 =20 1-877-668-4493 Call-in toll free number (US/Canada) 1-650-479-3208 Call-in toll number (US/Canada) =20 =20 Sue Hares and John Scudder=20 =20 From: IDR Working Group [mailto:messenger@webex.com]=20 Sent: Friday, March 04, 2016 3:19 PM To: idr-chairs@tools.ietf.org Subject: (Forward to others) WebEx meeting invitation: IDR interim 3: = Flow Specification =20 You can forward this invitation to others.=20 =20 Hello,=20 IDR Working Group invites you to join this WebEx meeting.=20 =20 =20 =20 IDR interim 3: Flow Specification=20 Monday, March 7, 2016=20 10:00 am | Eastern Standard Time (New York, GMT-05:00) | 2 hrs=20 =20 =20 =20 = Join WebEx meeting=20 =20 Meeting number:=20 644 627 626=20 Meeting password: flows.are.fun =20 =20 =20 Join by phone 1-877-668-4493 Call-in toll free number (US/Canada) 1-650-479-3208 Call-in toll number (US/Canada) Access code: 644 627 626 Toll-free calling = restrictions =20 =20 =20 = Add this meeting to your calendar. (Cannot add from mobile devices.) =20 =20 =20 Can't join the meeting? Contact = support.=20 =20 =20 =20 IMPORTANT NOTICE: Please note that this WebEx service allows audio and = other information sent during the session to be recorded, which may be = discoverable in a legal matter. By joining this session, you = automatically consent to such recordings. If you do not consent to being = recorded, discuss your concerns with the host or do not join the = session. =20 ------=_NextPart_000_0035_01D1762B.51517820 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

BGP interim will be held on Monday 3/7/2016 from 10:00am =E2=80=93 = 11:30am ET. =C2=A0

The topics are:

 

1)      = BGP Flow Specification =E2=80=93 2 options for work [10:00 =E2=80=93 = 11:00 am] =C2=A0

a.       = Option 1: Extension of current BGP Flow Specification =

b.      = Option 2: Version 2 of BGP Flow Specification using new NLRI and Wide = BGP communities to allow ordering of filters and actions. =

c.       = Option 3: Do both option 1 and option 2

 

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Documents discussed: =

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0draf= t-hares-idr-bgp-flowspec-combo-01.txt

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0draf= t-eddy-idr-flowspec-packet-rate-00.txt

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = draft-hao-idr-flowspec-nv03-03.txt

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0draf= t-hao-idr-redirect-tunnel-00.txt

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = draft-liang-idr-bgp-flowspec-label-01.txt

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = draft-liang-idr-bgp-flowspec-time-01.txt

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = draft-litkowski-idr-flowspec-interfaceset-03.txt

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = draft-vandevelde-idr-flowspec-path-redirect-01.txt

<= p class=3DMsoNormal>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = draft-ietf-idr-wide-bgp-communities-01.txt

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0draf= t-ietf-idr-tunnel-encaps-01.txt

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = draft-ietf-idr-flowspec-l2vpn-03.txt

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0draf= t-li-idr-flowspec-rpd-01.txt.

 

2)      = Yang models [11:00am =E2=80=93 11:30]

a.       = BGP Flow Specification Yang model

b.      = BGP Extension models for BGP

 

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Documents = discussed:

draft-wu-idr-flowspec-yang-cfg-02

draft-hares-idr-bgp-flowspec-combo-01.txt = =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=A0draft-ietf-idr-bgp-model-01.txt

 

 

Web ex:

https://ietf.webex.com/ietf/j.php?MTID=3Dm944a81587e9ce48ff4c9= 27d7545c1456

 

1-877-668-4493 Call-in toll free number = (US/Canada)

1-650-479-3208 Call-in toll number = (US/Canada)

 

 

Sue Hares and John Scudder

 

From:= = IDR Working Group [mailto:messenger@webex.com]
Sent: Friday, = March 04, 2016 3:19 PM
To: = idr-chairs@tools.ietf.org
Subject: (Forward to others) WebEx = meeting invitation: IDR interim 3: Flow = Specification

 

You can forward this invitation to others. =

 

Hello,

IDR Working Group invites you to join this WebEx meeting. =

 

 

 

IDR interim 3: = Flow Specification =

Monday, March 7, 2016

10:00 am  |  Eastern Standard Time (New York, = GMT-05:00)  |  2 hrs =

 

 

 

Join = WebEx meeting =

 

Meeting number:

644 627 626

Meeting password:

flows.are.fun

 

 

 

Join by = phone

1-877-668-4493 Call-in toll free number = (US/Canada)

1-650-479-3208 Call-in toll number = (US/Canada)

Access code: 644 627 626

Toll-free = calling = restrictions

 

 

 

Add this = meeting to your calendar. (Cannot add from mobile = devices.)

 

 

 

Can't join the meeting? Contact support. =

 

 

 

= IMPORTANT NOTICE: Please note that this WebEx service allows audio and = other information sent during the session to be recorded, which may be = discoverable in a legal matter. By joining this session, you = automatically consent to such recordings. If you do not consent to being = recorded, discuss your concerns with the host or do not join the = session.

 

------=_NextPart_000_0035_01D1762B.51517820-- From nobody Sat Mar 5 14:38:15 2016 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 389231B37F7; Sat, 5 Mar 2016 14:38:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.15.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160305223814.16229.44728.idtracker@ietfa.amsl.com> Date: Sat, 05 Mar 2016 14:38:14 -0800 Archived-At: Subject: [Idr] The IDR WG has placed draft-hares-idr-flowspec-combo in state "Call For Adoption By WG Issued" 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: Sat, 05 Mar 2016 22:38:14 -0000 The IDR WG has placed draft-hares-idr-flowspec-combo in state Call For Adoption By WG Issued (entered by Susan Hares) The document is available at https://datatracker.ietf.org/doc/draft-hares-idr-flowspec-combo/ From nobody Sat Mar 5 14:49:19 2016 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 D5EA21B381C for ; Sat, 5 Mar 2016 14:49:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.358 X-Spam-Level: X-Spam-Status: No, score=-94.358 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DOS_OUTLOOK_TO_MX=2.845, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.793, 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 PJWB8juAU2nB for ; Sat, 5 Mar 2016 14:49:16 -0800 (PST) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 ADD191B381B for ; Sat, 5 Mar 2016 14:49:15 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.30; From: "Susan Hares" To: Date: Sat, 5 Mar 2016 17:48:40 -0500 Message-ID: <000b01d17731$29d17230$7d745690$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000C_01D17707.40FFFE10" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdF3MOvE/JSvgLOkQ3a9MB8GleM7AQ== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: [Idr] WG Work item call - Opinions on work items (3/5/2016 to 3/17/2016) and adoption of draft-hares-idr-flowspec-combo-01.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: Sat, 05 Mar 2016 22:49:18 -0000 This is a multipart message in MIME format. ------=_NextPart_000_000C_01D17707.40FFFE10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The interim on 3/7/2016 will have a discussion of revisions to the BGP Flow specification (BGP-FS) to add more features. There are two suggested options: 1) A minimal features to existing BGP-FS (option 1) Add a few new match filters to the BGP-FS NLRI and few new actions to the BGP-FS actions (in Extended communities). Actions would need to be done in a defined order. Each new actions would need to define conflicts with existing actions. Best use case: DoS attack prevention 2) Create a BGP-FS version 2 (option 2) Create a new BGP-FS NLRI (v2) with a field that indicates the ordering of the BGP NLRI. Add new BGP-FS actions with an order field in the BGP Wide Communities. Filters are done in the order defined in the filter. Actions are done in the order defined in the actions. Order numbers that tie are handled in a defined order. Best use case: SDN/NFV filter management A write-up on the issues and proposed solutions is contained in: draft-hares-idr-flowspec-combo-01.txt. The WG can select both option 1 and option 2. This is a WG work item call for input to the chairs on the scope of the WG item. In you discussion of this topics, the chairs would appreciate if you would indicate if you would support IDR working on option 1, option 2 or both option 1 and 2. This WG call items also includes a call for draft-hares-idr-flowspec-combo-01.txt as a write-up of the work-item options. The WG may wish to split this draft into multiple drafts. The following drafts are being consider for either option: 1) draft-eddy-idr-flowspec-packet-rate 2) draft-hao-idr-flowspec-nv03 3) draft-hao-idr-flowspec-label 4) draft-liang-idr-bgp-flowspec-time 5) draft-litowski-idr-flowspec-interfaceset 6) draft-vandevelde-idr-flowspec-path-redirect 7) draft-li-idr-flowspec-rpd-01.txt 8) draft-wu-idr-flowspec-yang.cfg. If you wish to comment on any of these drafts, we will We will conclude the Call for WG opinions on 3/17/2016 so these authors can have a day to revise and submit their drafts before the draft deadline. Sue Hares and John Scudder PS: draft-li-idr-flowspec-rpd discusses limits on the distribution of the policy which has been recast in draft-hares-idr-flowspec-combo as a bgp-wide community of Container type 1 with an atom of BGP Flow Specification ordering. However, this draft is included in the list to be able to update the mechanism from this draft into that context. The yang model for BGP Flow specification is also included in this work item as it will need to be modified based on the approaches. The yang model is in draft-wu-idr-flowspec-yang-cfg. In your comments, please indicate if you feel these drafts or other drafts. ------=_NextPart_000_000C_01D17707.40FFFE10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The = interim on 3/7/2016 will have a discussion of revisions to the BGP Flow = specification (BGP-FS) to add more features.  There are two = suggested options:

1)      = A minimal features to existing BGP-FS (option 1) =

Add a few new match filters = to the BGP-FS NLRI and few new actions to the BGP-FS actions (in = Extended communities).  Actions would need to be done in a defined = order. Each new actions would need to define conflicts with existing = actions.   

 

Best use case:  DoS attack prevention =

 

2)      = Create a BGP-FS version 2 (option 2) =

Create a new BGP-FS NLRI (v2) = with a field that indicates the ordering of the BGP NLRI.  Add new = BGP-FS actions with an order field in the BGP Wide Communities.  = Filters are done in the order defined in the filter.  Actions are = done in the order defined in the actions.   Order numbers that = tie are handled in a defined order.

 

Best use case: SDN/NFV filter management =

 

A write-up on the issues and proposed solutions is = contained in:

draft-hares-idr-flowspec-combo-01.txt.    The WG can = select both option 1 and option 2.  This is a WG work item call for = input to the chairs on the scope of the WG item.  In you discussion = of this topics, the chairs would appreciate if you would indicate if you = would support IDR working on option 1, option 2 or both option 1 and 2. =  This WG call items also includes a call for = draft-hares-idr-flowspec-combo-01.txt as a write-up of the work-item = options.  The WG may wish to split this draft into multiple drafts. =

 

The following drafts are being consider for either = option:

1)      = draft-eddy-idr-flowspec-packet-rate

2)      = draft-hao-idr-flowspec-nv03

3)      = draft-hao-idr-flowspec-label

4)      = draft-liang-idr-bgp-flowspec-time

<= p class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l0 = level1 lfo4'>5)      = draft-litowski-idr-flowspec-interfaceset =

6)      = draft-vandevelde-idr-flowspec-path-redirect<= /o:p>

7)      = draft-li-idr-flowspec-rpd-01.txt =

8)      = draft-wu-idr-flowspec-yang.cfg. =

 

If you wish to comment on any of these drafts, we will =

 

We will conclude the Call for WG opinions on 3/17/2016 = so these authors can have a day to revise and submit their drafts before = the draft deadline.

 

Sue Hares = and John Scudder

 

PS:

draft-li-idr-flowspec-rpd discusses limits on the = distribution of the policy which has been recast in = draft-hares-idr-flowspec-combo as a bgp-wide community of Container type = 1 with an atom of BGP Flow Specification ordering. However,  this = draft is included in the list to be able to update the mechanism from = this draft into that context.  

 

The yang = model for BGP Flow specification is also included in this work item as = it will need to be modified based on the approaches.  The yang = model is in draft-wu-idr-flowspec-yang-cfg.  In your comments, = please indicate if you feel these drafts or other drafts.  =

 

------=_NextPart_000_000C_01D17707.40FFFE10-- From nobody Sun Mar 6 01:34:19 2016 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 B06931B30C2 for ; Sun, 6 Mar 2016 01:34:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 NHRoCoeqBwnW for ; Sun, 6 Mar 2016 01:34:15 -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 560921B30A7 for ; Sun, 6 Mar 2016 01:34:15 -0800 (PST) Received: from [10.214.90.112] (242.82-131-109.adsl-dyn.isp.belgacom.be [109.131.82.242]) by st13p11im-asmtp004.me.com (Oracle Communications Messaging Server 7.0.5.36.0 64bit (built Sep 8 2015)) with ESMTPSA id <0O3M00EMY2KZP700@st13p11im-asmtp004.me.com> for idr@ietf.org; Sun, 06 Mar 2016 09:34:14 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-03-06_04:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1015 suspectscore=3 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1510270003 definitions=main-1603060186 Content-type: multipart/alternative; boundary="Apple-Mail=_233C8F85-E3AA-4F80-8894-C01054EB4CFD" MIME-version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Gunter Van De Velde In-reply-to: <000b01d17731$29d17230$7d745690$@ndzh.com> Date: Sun, 06 Mar 2016 10:34:12 +0100 Message-id: References: <000b01d17731$29d17230$7d745690$@ndzh.com> To: Susan Hares X-Mailer: Apple Mail (2.3112) Archived-At: Cc: idr@ietf.org Subject: Re: [Idr] WG Work item call - Opinions on work items (3/5/2016 to 3/17/2016) and adoption of draft-hares-idr-flowspec-combo-01.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: Sun, 06 Mar 2016 09:34:17 -0000 --Apple-Mail=_233C8F85-E3AA-4F80-8894-C01054EB4CFD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 My consern with the concept of BGP-FS version 2 is that it means jumping = to solution space, even before having a rough agreement on the = requirements and scope for a SDN policy distribution mechanism. An additional concern is about using BGP for NFV management as there may = be more appropriate mechanisms available (outside BGP).=20 If the intent is to truly use BGP as a mechanism to distribute SDN = policies and and related management information, then what does that = mean exactly? what does such protocol extension=20 expose as capabilities? What are the use-cases that drive the need for = existence of such technology? In that case it may be better to construct = a tailor designed BGP Policy Distribution framework version 1 (BGP-PD = version 1) I believe in keeping changes to RFC5575 to a minimum, and only extend to = simple match/action capabilities that "drive indirection" and "network = wide" rules. I also believe that before trying to document a solution space for BGP = based SDN policy distribution, that both the problem space and intended = protocol properties exposed as consumable SDN API=E2=80=99s need to be = discussed and agreed upon. In that light i feel that the concept of a = BGP-FS version 2 is not the right approach. G/ > On 05 Mar 2016, at 23:48, Susan Hares wrote: >=20 > The interim on 3/7/2016 will have a discussion of revisions to the BGP = Flow specification (BGP-FS) to add more features. There are two = suggested options: > 1) A minimal features to existing BGP-FS (option 1)=20 > Add a few new match filters to the BGP-FS NLRI and few new actions to = the BGP-FS actions (in Extended communities). Actions would need to be = done in a defined order. Each new actions would need to define conflicts = with existing actions. =20 > =20 > Best use case: DoS attack prevention=20 > =20 > 2) Create a BGP-FS version 2 (option 2)=20 > Create a new BGP-FS NLRI (v2) with a field that indicates the ordering = of the BGP NLRI. Add new BGP-FS actions with an order field in the BGP = Wide Communities. Filters are done in the order defined in the filter. = Actions are done in the order defined in the actions. Order numbers = that tie are handled in a defined order.=20 > =20 > Best use case: SDN/NFV filter management=20 > =20 > A write-up on the issues and proposed solutions is contained in:=20 > draft-hares-idr-flowspec-combo-01.txt.=C2=A0 = The = WG can select both option 1 and option 2. This is a WG work item call = for input to the chairs on the scope of the WG item. In you discussion = of this topics, the chairs would appreciate if you would indicate if you = would support IDR working on option 1, option 2 or both option 1 and 2. = This WG call items also includes a call for = draft-hares-idr-flowspec-combo-01.txt as a write-up of the work-item = options. The WG may wish to split this draft into multiple drafts.=20 > =20 > The following drafts are being consider for either option:=20 > 1) draft-eddy-idr-flowspec-packet-rate > 2) draft-hao-idr-flowspec-nv03 > 3) draft-hao-idr-flowspec-label > 4) draft-liang-idr-bgp-flowspec-time > 5) draft-litowski-idr-flowspec-interfaceset=20 > 6) draft-vandevelde-idr-flowspec-path-redirect > 7) draft-li-idr-flowspec-rpd-01.txt=20 > 8) draft-wu-idr-flowspec-yang.cfg.=20 > =20 > If you wish to comment on any of these drafts, we will=20 > =20 > We will conclude the Call for WG opinions on 3/17/2016 so these = authors can have a day to revise and submit their drafts before the = draft deadline.=20 > =20 > Sue Hares and John Scudder=20 > =20 > PS: > draft-li-idr-flowspec-rpd discusses limits on the distribution of the = policy which has been recast in draft-hares-idr-flowspec-combo as a = bgp-wide community of Container type 1 with an atom of BGP Flow = Specification ordering. However, this draft is included in the list to = be able to update the mechanism from this draft into that context. =20 > =20 > The yang model for BGP Flow specification is also included in this = work item as it will need to be modified based on the approaches. The = yang model is in draft-wu-idr-flowspec-yang-cfg. In your comments, = please indicate if you feel these drafts or other drafts. =20 > =20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr = --Apple-Mail=_233C8F85-E3AA-4F80-8894-C01054EB4CFD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
My consern with the concept of BGP-FS version = 2 is that it means jumping to solution space, even before having a rough = agreement on the requirements and scope for a SDN policy distribution = mechanism.
An additional concern is about using BGP = for NFV management as there may be more appropriate mechanisms available = (outside BGP). 

If the intent is to truly use BGP as a mechanism to = distribute SDN policies and and related management information, then = what does that mean exactly? what does such protocol = extension 
expose as capabilities? What are = the use-cases that drive the need for existence of such technology? In = that case it may be better to construct a tailor designed BGP Policy = Distribution framework version 1 (BGP-PD version 1)

I believe in keeping = changes to RFC5575 to a minimum, and only extend to simple match/action = capabilities that "drive indirection" and "network wide" = rules.
I also believe that before trying to = document a solution space for BGP based SDN policy distribution, that = both the problem space and intended protocol properties exposed as = consumable SDN API=E2=80=99s need to be discussed and agreed upon. In = that light i feel that the concept of a BGP-FS version 2 is not the = right approach.

G/







On 05 Mar 2016, at 23:48, Susan = Hares <shares@ndzh.com> wrote:

The interim on 3/7/2016 will have a = discussion of revisions to the BGP Flow specification (BGP-FS) to add = more features.  There are two suggested options:
1)      A minimal = features to existing BGP-FS (option 1) 
Add a few = new match filters to the BGP-FS NLRI and few new actions to the BGP-FS = actions (in Extended communities).  Actions would need to be done = in a defined order. Each new actions would need to define conflicts with = existing actions.   
 
Best use case:  DoS attack = prevention 
 
2)      Create a = BGP-FS version 2 (option 2) 
Create a = new BGP-FS NLRI (v2) with a field that indicates the ordering of the BGP = NLRI.  Add new BGP-FS actions with an order field in the BGP Wide = Communities.  Filters are done in the order defined in the = filter.  Actions are done in the order defined in the = actions.   Order numbers that tie are handled in a defined = order. 
 
Best= use case: SDN/NFV filter management 
 
A = write-up on the issues and proposed solutions is contained in: 
draft-hares-idr-flowspec-combo-01.txt.    The = WG can select both option 1 and option 2.  This is a WG work item = call for input to the chairs on the scope of the WG item.  In you = discussion of this topics, the chairs would appreciate if you would = indicate if you would support IDR working on option 1, option 2 or both = option 1 and 2.  This WG call items also includes a call for = draft-hares-idr-flowspec-combo-01.txt as a write-up of the work-item = options.  The WG may wish to split this draft into multiple = drafts. 
 
The = following drafts are being consider for either option: 
1)      draft-eddy-idr-= flowspec-packet-rate
2)      draft-hao-idr-f= lowspec-nv03
3)      draft-hao-idr-f= lowspec-label
4)      draft-liang-idr= -bgp-flowspec-time
5)      draft-litowski-= idr-flowspec-interfaceset 
6)      draft-vandeveld= e-idr-flowspec-path-redirect
7)      draft-li-idr-fl= owspec-rpd-01.txt 
8)      draft-wu-idr-fl= owspec-yang.cfg. 
 
If you = wish to comment on any of these drafts, we will 
 
We will = conclude the Call for WG opinions on 3/17/2016 so these authors can have = a day to revise and submit their drafts before the draft deadline. 
 
Sue Hares = and John Scudder 
 
PS:
draft-li-idr-flowspec-rpd discusses limits on the = distribution of the policy which has been recast in = draft-hares-idr-flowspec-combo as a bgp-wide community of Container type = 1 with an atom of BGP Flow Specification ordering. However,  this = draft is included in the list to be able to update the mechanism from = this draft into that context.  
 
The yang model for BGP Flow = specification is also included in this work item as it will need to be = modified based on the approaches.  The yang model is in = draft-wu-idr-flowspec-yang-cfg.  In your comments, please indicate = if you feel these drafts or other drafts.  
 
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

= --Apple-Mail=_233C8F85-E3AA-4F80-8894-C01054EB4CFD-- From nobody Sun Mar 6 04:51:49 2016 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 110221B332C for ; Sun, 6 Mar 2016 04:51:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.257 X-Spam-Level: X-Spam-Status: No, score=-96.257 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.793, 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 GuAeGaMKKMOm for ; Sun, 6 Mar 2016 04:51:45 -0800 (PST) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 1C3671B3319 for ; Sun, 6 Mar 2016 04:51:44 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.30; From: "Susan Hares" To: "'Gunter Van De Velde'" References: <000b01d17731$29d17230$7d745690$@ndzh.com> In-Reply-To: Date: Sun, 6 Mar 2016 07:51:11 -0500 Message-ID: <005801d177a6$dcd8fea0$968afbe0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0059_01D1777C.F4091120" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGcwDBIhMS4vQbRNdLW21dU5JTRjQI/zGpmn6PL1sA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: idr@ietf.org Subject: Re: [Idr] WG Work item call - Opinions on work items (3/5/2016 to 3/17/2016) and adoption of draft-hares-idr-flowspec-combo-01.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: Sun, 06 Mar 2016 12:51:48 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0059_01D1777C.F4091120 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Gunter:=20 =20 Thank you for being the first responder to the BGP-FS call for input. = My understanding is that you approve option 1, but are concerned about = the scope of option 2. Do you feel the actions need ordering for = option 1? =20 =20 I will ask those who propose the SDN/NFV work to write their = understanding of the use cases for the next IETF, and post it on the = list. In the last few interims, there seem to be a consensus of people = indicating that the SDN/NFV was a valid use case. However, interims are = small discussion formats so the chairs have sent this call for input.=20 =20 On working toward a specific solution space: the IESG has encouraged = parallel efforts between problem space development and solutions in = order to aid rapid deployment of protocols. The = draft-hares-idr-flowspec-combo is a summary of the problem space and = solutions from the WG chair=E2=80=99s viewpoint. Thank you for letting = me know we need to add problem space details. =20 =20 Sue =20 =20 From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Gunter Van De Velde Sent: Sunday, March 06, 2016 4:34 AM To: Susan Hares Cc: idr@ietf.org Subject: Re: [Idr] WG Work item call - Opinions on work items (3/5/2016 = to 3/17/2016) and adoption of draft-hares-idr-flowspec-combo-01.txt =20 My consern with the concept of BGP-FS version 2 is that it means jumping = to solution space, even before having a rough agreement on the = requirements and scope for a SDN policy distribution mechanism. An additional concern is about using BGP for NFV management as there may = be more appropriate mechanisms available (outside BGP).=20 =20 If the intent is to truly use BGP as a mechanism to distribute SDN = policies and and related management information, then what does that = mean exactly? what does such protocol extension=20 expose as capabilities? What are the use-cases that drive the need for = existence of such technology? In that case it may be better to construct = a tailor designed BGP Policy Distribution framework version 1 (BGP-PD = version 1) =20 I believe in keeping changes to RFC5575 to a minimum, and only extend to = simple match/action capabilities that "drive indirection" and "network = wide" rules. I also believe that before trying to document a solution space for BGP = based SDN policy distribution, that both the problem space and intended = protocol properties exposed as consumable SDN API=E2=80=99s need to be = discussed and agreed upon. In that light i feel that the concept of a = BGP-FS version 2 is not the right approach. =20 G/ =20 =20 =20 =20 =20 =20 =20 On 05 Mar 2016, at 23:48, Susan Hares wrote: =20 The interim on 3/7/2016 will have a discussion of revisions to the BGP = Flow specification (BGP-FS) to add more features. There are two = suggested options: 1) A minimal features to existing BGP-FS (option 1)=20 Add a few new match filters to the BGP-FS NLRI and few new actions to = the BGP-FS actions (in Extended communities). Actions would need to be = done in a defined order. Each new actions would need to define conflicts = with existing actions. =20 =20 Best use case: DoS attack prevention=20 =20 2) Create a BGP-FS version 2 (option 2)=20 Create a new BGP-FS NLRI (v2) with a field that indicates the ordering = of the BGP NLRI. Add new BGP-FS actions with an order field in the BGP = Wide Communities. Filters are done in the order defined in the filter. = Actions are done in the order defined in the actions. Order numbers = that tie are handled in a defined order.=20 =20 Best use case: SDN/NFV filter management=20 =20 A write-up on the issues and proposed solutions is contained in:=20 = draft-hares-idr-flowspec-combo-01.txt. The WG can select both option = 1 and option 2. This is a WG work item call for input to the chairs on = the scope of the WG item. In you discussion of this topics, the chairs = would appreciate if you would indicate if you would support IDR working = on option 1, option 2 or both option 1 and 2. This WG call items also = includes a call for draft-hares-idr-flowspec-combo-01.txt as a write-up = of the work-item options. The WG may wish to split this draft into = multiple drafts.=20 =20 The following drafts are being consider for either option:=20 1) draft-eddy-idr-flowspec-packet-rate 2) draft-hao-idr-flowspec-nv03 3) draft-hao-idr-flowspec-label 4) draft-liang-idr-bgp-flowspec-time 5) draft-litowski-idr-flowspec-interfaceset=20 6) draft-vandevelde-idr-flowspec-path-redirect 7) draft-li-idr-flowspec-rpd-01.txt=20 8) draft-wu-idr-flowspec-yang.cfg.=20 =20 If you wish to comment on any of these drafts, we will=20 =20 We will conclude the Call for WG opinions on 3/17/2016 so these authors = can have a day to revise and submit their drafts before the draft = deadline.=20 =20 Sue Hares and John Scudder=20 =20 PS: draft-li-idr-flowspec-rpd discusses limits on the distribution of the = policy which has been recast in draft-hares-idr-flowspec-combo as a = bgp-wide community of Container type 1 with an atom of BGP Flow = Specification ordering. However, this draft is included in the list to = be able to update the mechanism from this draft into that context. =20 =20 The yang model for BGP Flow specification is also included in this work = item as it will need to be modified based on the approaches. The yang = model is in draft-wu-idr-flowspec-yang-cfg. In your comments, please = indicate if you feel these drafts or other drafts. =20 =20 _______________________________________________ Idr mailing list Idr@ietf.org = https://www.ietf.org/mailman/listinfo/idr =20 ------=_NextPart_000_0059_01D1777C.F4091120 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Gunter:

 

Thank you for being the first responder to the BGP-FS call for = input.=C2=A0 My understanding is that you approve option 1, but are = concerned about the scope of option 2. =C2=A0=C2=A0Do you feel the = actions need ordering for option 1? =C2=A0

 

I will ask those who propose the SDN/NFV work to write their = understanding of the use cases for the next IETF, and post it on the = list. =C2=A0In the last few interims, there seem to be a consensus of = people indicating that the SDN/NFV was a valid use case.=C2=A0 However, = interims are small discussion formats so the chairs have sent this call = for input.

 

On working toward a specific solution space: the IESG has encouraged = parallel efforts between problem space development and solutions in = order to aid rapid deployment of protocols.=C2=A0 =C2=A0The = draft-hares-idr-flowspec-combo =C2=A0is a summary of the problem space = and solutions from the WG chair=E2=80=99s viewpoint.=C2=A0 Thank you for = letting me know we need to add problem space details. = =C2=A0

 

Sue =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

 

From:= = Idr [mailto:idr-bounces@ietf.org] On Behalf Of Gunter Van De = Velde
Sent: Sunday, March 06, 2016 4:34 AM
To: Susan = Hares
Cc: idr@ietf.org
Subject: Re: [Idr] WG Work = item call - Opinions on work items (3/5/2016 to 3/17/2016) and adoption = of = draft-hares-idr-flowspec-combo-01.txt

 

My = consern with the concept of BGP-FS version 2 is that it means jumping to = solution space, even before having a rough agreement on the requirements = and scope for a SDN policy distribution = mechanism.

An additional = concern is about using BGP for NFV management as there may be more = appropriate mechanisms available (outside = BGP). 

 

If the intent is to truly use BGP as a mechanism to = distribute SDN policies and and related management information, then = what does that mean exactly? what does such protocol = extension 

expose as = capabilities? What are the use-cases that drive the need for existence = of such technology? In that case it may be better to construct a tailor = designed BGP Policy Distribution framework version 1 (BGP-PD version = 1)

 

I = believe in keeping changes to RFC5575 to a minimum, and only extend to = simple match/action capabilities that "drive indirection" and = "network wide" rules.

I also believe that before trying to document a = solution space for BGP based SDN policy distribution, that both the = problem space and intended protocol properties exposed as consumable SDN = API=E2=80=99s need to be discussed and agreed upon. In that light i feel = that the concept of a BGP-FS version 2 is not the right = approach.

 

G/

 

 

 

 

 

 

 

On 05 Mar 2016, at 23:48, Susan Hares <shares@ndzh.com> = wrote:

 

The = interim on 3/7/2016 will have a discussion of revisions to the BGP Flow = specification (BGP-FS) to add more features.  There are two = suggested options:

1)      A minimal = features to existing BGP-FS (option 1) 

Add a few = new match filters to the BGP-FS NLRI and few new actions to the BGP-FS = actions (in Extended communities).  Actions would need to be done = in a defined order. Each new actions would need to define conflicts with = existing actions.   

 =

Best use = case:  DoS attack prevention 

 =

2)      Create a = BGP-FS version 2 (option 2) 

Create a = new BGP-FS NLRI (v2) with a field that indicates the ordering of the BGP = NLRI.  Add new BGP-FS actions with an order field in the BGP Wide = Communities.  Filters are done in the order defined in the = filter.  Actions are done in the order defined in the = actions.   Order numbers that tie are handled in a defined = order. 

 =

Best use = case: SDN/NFV filter management 

 =

A write-up = on the issues and proposed solutions is contained in: 

draft-hares-idr-flowspec-combo-01.txt.    T= he WG can select both option 1 and option 2.  This is a WG work = item call for input to the chairs on the scope of the WG item.  In = you discussion of this topics, the chairs would appreciate if you would = indicate if you would support IDR working on option 1, option 2 or both = option 1 and 2.  This WG call items also includes a call for = draft-hares-idr-flowspec-combo-01.txt as a write-up of the work-item = options.  The WG may wish to split this draft into multiple = drafts. 

 =

The = following drafts are being consider for either option: 

1)      draft-eddy-= idr-flowspec-packet-rate

2)      draft-hao-i= dr-flowspec-nv03

3)      draft-hao-i= dr-flowspec-label

4)      draft-liang= -idr-bgp-flowspec-time

5)      draft-litow= ski-idr-flowspec-interfaceset 

6)      draft-vande= velde-idr-flowspec-path-redirect

7)      draft-li-id= r-flowspec-rpd-01.txt 

8)      draft-wu-id= r-flowspec-yang.cfg. 

 =

If you = wish to comment on any of these drafts, we will 

 =

We will = conclude the Call for WG opinions on 3/17/2016 so these authors can have = a day to revise and submit their drafts before the draft deadline. 

 =

Sue Hares = and John Scudder 

 =

PS:

draft-li-id= r-flowspec-rpd discusses limits on the distribution of the policy which = has been recast in draft-hares-idr-flowspec-combo as a bgp-wide = community of Container type 1 with an atom of BGP Flow Specification = ordering. However,  this draft is included in the list to be able = to update the mechanism from this draft into that context. =  

 =

The yang = model for BGP Flow specification is also included in this work item as = it will need to be modified based on the approaches.  The yang = model is in draft-wu-idr-flowspec-yang-cfg.  In your comments, = please indicate if you feel these drafts or other drafts.  

 =

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

 

------=_NextPart_000_0059_01D1777C.F4091120-- From nobody Mon Mar 7 00:15:14 2016 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 7A0BA1B3736 for ; Mon, 7 Mar 2016 00:15:13 -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 RcCj9Ooa0sQ9 for ; Mon, 7 Mar 2016 00:15:10 -0800 (PST) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::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 CB1FA1B3735 for ; Mon, 7 Mar 2016 00:15:09 -0800 (PST) Received: by mail-lb0-x235.google.com with SMTP id k15so121388935lbg.0 for ; Mon, 07 Mar 2016 00:15:09 -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; bh=h7p8GuU2nHX9LrX3eODR2XkYqKEixBMiN0sZ8/MR+Rw=; b=qjW5JI7RY+GCULSC9yvuVs7kpTfZ2OQtdQTXBf4ZxMN1OyrD/6dVA4CkeDKSCcKvTg V6qpUPnOb6c8ptjxm5zCVqRcy+tN5Qu3vy2xo2iEDg5N4531FdDrVVwuiVJ2KwGcAKag 9XjqRmg1hZcDs/lBXYn9mct2xkmyyndOtC+Db/jbSs+5QGIIJJoYSIetKWwMswoKPPbe 9sB37ECIkxxw6SaxPZHURVzMVvHp3RibbLeutCPZI/RJ6aaAh/wBwGCf9Qf6aC20g0sA ZSj7sHmkuAmBnv3OvON5jGDix271/T6N8+XoeM6Pk97OqOqDo/ZHO9noZVduZJDfviIH y6ng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=h7p8GuU2nHX9LrX3eODR2XkYqKEixBMiN0sZ8/MR+Rw=; b=nNO6FR1boWgkHPYdIQXj+i6c9jv+2okBbhF0RIwrGM6uHELf6hPNv2OJIz+hEVkilg DYpa19ORbEirCQHlaHiweuLy963EjIigSwaAOwwPWHb51UGeXu7xUMs36aPb0mmqOcjC E1Fmstnoej0Q0UtzG9K0yKfyEYHCW7yj1al0fCukYDMD2sFi0s706i6guM25OZJMaHPm 9NTbH8nbTsfJltU4Dd2s4bj5fPFRvtSNyhSEqFoyiGvhWK0xpsA2Uj/ubwR4NvR0YHEX LQl8wZuWGrCajBjQiLMiYtF8+TzGwm79R5/juIDfOQXmsk0yptgHsL22A80FHtB/tPjU EJeQ== X-Gm-Message-State: AD7BkJI2TiwtMmUTENdaivb6+3vQ84KDaCxMVBV4VsOxQENLj/Mci8PygRCd9U6RuYIumX4o2yQeVi6dZT/L4w== MIME-Version: 1.0 X-Received: by 10.25.155.194 with SMTP id d185mr7332612lfe.11.1457338507896; Mon, 07 Mar 2016 00:15:07 -0800 (PST) Sender: rraszuk@gmail.com Received: by 10.25.136.133 with HTTP; Mon, 7 Mar 2016 00:15:07 -0800 (PST) In-Reply-To: <005801d177a6$dcd8fea0$968afbe0$@ndzh.com> References: <000b01d17731$29d17230$7d745690$@ndzh.com> <005801d177a6$dcd8fea0$968afbe0$@ndzh.com> Date: Mon, 7 Mar 2016 09:15:07 +0100 X-Google-Sender-Auth: DXW8WyUQzxOoBe1RuDXHjBNzOHs Message-ID: From: Robert Raszuk To: Susan Hares Content-Type: multipart/alternative; boundary=001a113fbdd414b0b4052d71101d Archived-At: Cc: idr wg Subject: Re: [Idr] WG Work item call - Opinions on work items (3/5/2016 to 3/17/2016) and adoption of draft-hares-idr-flowspec-combo-01.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, 07 Mar 2016 08:15:13 -0000 --001a113fbdd414b0b4052d71101d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Sue/Gunter, On the topic of problem space, requirements ... etc aren't we reinventing the wheel ? Aren't I2RS documents doing that already ? https://datatracker.ietf.org/wg/i2rs/documents/ And if they do is BGP FSv2 the right approach to be used as I2RS channel ? If yes I would question that simply based on the nature of BGP which is p2mp distribution (even if augmented now for other reasons with RTC). In most of the cases network elements need to get unique set of parameters which just does not fit BGP distribution model. If so why BGP? Is using port 179 and reuse of non AF/SAFI specific code the only reason? Or is the problem perhaps due to no APIs and common message bus across vendors and we are trying to fit BGP to become one in the fear that it will take decade(s) for vendors to support new common network element mgmt/API channel ? If we go with FSv2 what is the "read" or telemetry channel from device which will trigger proper FSv2 filter ? Is it again BGP ? - - On FSv1 I think we are ok to proceed. On the question of ordered actions or not I think one may need to support both as likely there will be folks who will need one or the other depending on what they are going to filter :) Best, r. On Sun, Mar 6, 2016 at 1:51 PM, Susan Hares wrote: > Gunter: > > > > Thank you for being the first responder to the BGP-FS call for input. My > understanding is that you approve option 1, but are concerned about the > scope of option 2. Do you feel the actions need ordering for option 1? > > > > I will ask those who propose the SDN/NFV work to write their understandin= g > of the use cases for the next IETF, and post it on the list. In the last > few interims, there seem to be a consensus of people indicating that the > SDN/NFV was a valid use case. However, interims are small discussion > formats so the chairs have sent this call for input. > > > > On working toward a specific solution space: the IESG has encouraged > parallel efforts between problem space development and solutions in order > to aid rapid deployment of protocols. The draft-hares-idr-flowspec-comb= o > is a summary of the problem space and solutions from the WG chair=E2=80= =99s > viewpoint. Thank you for letting me know we need to add problem space > details. > > > > Sue > > > > *From:* Idr [mailto:idr-bounces@ietf.org] *On Behalf Of *Gunter Van De > Velde > *Sent:* Sunday, March 06, 2016 4:34 AM > *To:* Susan Hares > *Cc:* idr@ietf.org > *Subject:* Re: [Idr] WG Work item call - Opinions on work items (3/5/2016 > to 3/17/2016) and adoption of draft-hares-idr-flowspec-combo-01.txt > > > > My consern with the concept of BGP-FS version 2 is that it means jumping > to solution space, even before having a rough agreement on the requiremen= ts > and scope for a SDN policy distribution mechanism. > > An additional concern is about using BGP for NFV management as there may > be more appropriate mechanisms available (outside BGP). > > > > If the intent is to truly use BGP as a mechanism to distribute SDN > policies and and related management information, then what does that mean > exactly? what does such protocol extension > > expose as capabilities? What are the use-cases that drive the need for > existence of such technology? In that case it may be better to construct = a > tailor designed BGP Policy Distribution framework version 1 (BGP-PD versi= on > 1) > > > > I believe in keeping changes to RFC5575 to a minimum, and only extend to > simple match/action capabilities that "drive indirection" and "network > wide" rules. > > I also believe that before trying to document a solution space for BGP > based SDN policy distribution, that both the problem space and intended > protocol properties exposed as consumable SDN API=E2=80=99s need to be di= scussed > and agreed upon. In that light i feel that the concept of a BGP-FS versio= n > 2 is not the right approach. > > > > G/ > > > > > > > > > > > > > > > > On 05 Mar 2016, at 23:48, Susan Hares wrote: > > > > The interim on 3/7/2016 will have a discussion of revisions to the BGP > Flow specification (BGP-FS) to add more features. There are two suggeste= d > options: > > 1) A minimal features to existing BGP-FS (option 1) > > Add a few new match filters to the BGP-FS NLRI and few new actions to the > BGP-FS actions (in Extended communities). Actions would need to be done = in > a defined order. Each new actions would need to define conflicts with > existing actions. > > > > Best use case: DoS attack prevention > > > > 2) Create a BGP-FS version 2 (option 2) > > Create a new BGP-FS NLRI (v2) with a field that indicates the ordering of > the BGP NLRI. Add new BGP-FS actions with an order field in the BGP Wide > Communities. Filters are done in the order defined in the filter. Actio= ns > are done in the order defined in the actions. Order numbers that tie ar= e > handled in a defined order. > > > > Best use case: SDN/NFV filter management > > > > A write-up on the issues and proposed solutions is contained in: > > draft-hares-idr-flowspec-combo-01.txt. > The > WG can select both option 1 and option 2. This is a WG work item call fo= r > input to the chairs on the scope of the WG item. In you discussion of th= is > topics, the chairs would appreciate if you would indicate if you would > support IDR working on option 1, option 2 or both option 1 and 2. This W= G > call items also includes a call for draft-hares-idr-flowspec-combo-01.txt > as a write-up of the work-item options. The WG may wish to split this > draft into multiple drafts. > > > > The following drafts are being consider for either option: > > 1) draft-eddy-idr-flowspec-packet-rate > > 2) draft-hao-idr-flowspec-nv03 > > 3) draft-hao-idr-flowspec-label > > 4) draft-liang-idr-bgp-flowspec-time > > 5) draft-litowski-idr-flowspec-interfaceset > > 6) draft-vandevelde-idr-flowspec-path-redirect > > 7) draft-li-idr-flowspec-rpd-01.txt > > 8) draft-wu-idr-flowspec-yang.cfg. > > > > If you wish to comment on any of these drafts, we will > > > > We will conclude the Call for WG opinions on 3/17/2016 so these authors > can have a day to revise and submit their drafts before the draft deadlin= e. > > > > > Sue Hares and John Scudder > > > > PS: > > draft-li-idr-flowspec-rpd discusses limits on the distribution of the > policy which has been recast in draft-hares-idr-flowspec-combo as a > bgp-wide community of Container type 1 with an atom of BGP Flow > Specification ordering. However, this draft is included in the list to b= e > able to update the mechanism from this draft into that context. > > > > The yang model for BGP Flow specification is also included in this work > item as it will need to be modified based on the approaches. The yang > model is in draft-wu-idr-flowspec-yang-cfg. In your comments, please > indicate if you feel these drafts or other drafts. > > > > _______________________________________________ > 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 > > --001a113fbdd414b0b4052d71101d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Sue/Gunter,
=
On the topic of problem space, requirements ..= . etc aren't we reinventing the wheel ? Aren't I2RS documents doing= that already ?=C2=A0

https://datatracker.ietf.= org/wg/i2rs/documents/

And if they do is BGP FSv2 the right approach to be used as I2RS channel= ?=C2=A0

If yes I= would question that simply based on the nature of BGP which is p2mp distri= bution (even if augmented now for other reasons with RTC).=C2=A0
=

In most of the cases network eleme= nts need to get unique set of parameters which just does not fit BGP distri= bution model. If so why BGP?=C2=A0

Is using port 179 and reuse of non AF/SAFI specific code the only re= ason?=C2=A0

Or is the probl= em perhaps due to no APIs and common message bus across vendors and we are = trying to fit BGP to become one in the fear that it will take decade(s) for= vendors to support new common network element mgmt/API channel ? =C2=A0

If we go with FSv2 what is the= "read" or telemetry channel from device which will trigger prope= r FSv2 filter ? Is it again BGP ?=C2=A0

- -=C2=A0
<= font face=3D"arial, helvetica, sans-serif">
On FSv= 1 I think we are ok to proceed. On the question of ordered actions or not I= think one may need to support both as likely there will be folks who will = need one or the other depending on what they are going to filter :)<= /div>

Best,
r.


On Sun, Mar 6, 2016 at 1:51= PM, Susan Hares <shares@ndzh.com> wrote:

Gunter: <= /p>

=C2=A0

Thank you for be= ing the first responder to the BGP-FS call for input.=C2=A0 My understandin= g is that you approve option 1, but are concerned about the scope of option= 2. =C2=A0=C2=A0Do you feel the actions need ordering for option 1? =C2=A0<= u>

<= u>=C2=A0

I will ask those who propose the SDN/NFV work to write their understan= ding of the use cases for the next IETF, and post it on the list.=C2=A0 In = the last few interims, there seem to be a consensus of people indicating th= at the SDN/NFV was a valid use case.=C2=A0 However, interims are small disc= ussion formats so the chairs have sent this call for input. <= /span>

=C2=A0

On workin= g toward a specific solution space: the IESG has encouraged parallel effort= s between problem space development and solutions in order to aid rapid dep= loyment of protocols.=C2=A0 =C2=A0The draft-hares-idr-flowspec-combo =C2=A0= is a summary of the problem space and solutions from the WG chair=E2=80=99s= viewpoint.=C2=A0 Thank you for letting me know we need to add problem spac= e details. =C2=A0

=C2=A0

Sue =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

=C2= =A0

Fr= om: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Gunter = Van De Velde
Sent: Sunday, March 06, 2016 4:34 AM
To: S= usan Hares
Cc: = idr@ietf.org
Subject: Re: [Idr] WG Work item call - Opinions = on work items (3/5/2016 to 3/17/2016) and adoption of draft-hares-idr-flows= pec-combo-01.txt

=C2=A0

My consern with the concept of BGP-FS version 2 is that it means jumping t= o solution space, even before having a rough agreement on the requirements = and scope for a SDN policy distribution mechanism.

<= div>

An additional concern is about using BGP for NFV= management as there may be more appropriate mechanisms available (outside = BGP).=C2=A0

=C2= =A0

If the intent is to truly u= se BGP as a mechanism to distribute SDN policies and and related management= information, then what does that mean exactly? what does such protocol ext= ension=C2=A0

expose as c= apabilities? What are the use-cases that drive the need for existence of su= ch technology? In that case it may be better to construct a tailor designed= BGP Policy Distribution framework version 1 (BGP-PD version 1)

=C2=A0

=

I believe in keeping changes to RFC5575 to a minimum= , and only extend to simple match/action capabilities that "drive indi= rection" and "network wide" rules.

I also believe that before trying to document a s= olution space for BGP based SDN policy distribution, that both the problem = space and intended protocol properties exposed as consumable SDN API=E2=80= =99s need to be discussed and agreed upon. In that light i feel that the co= ncept of a BGP-FS version 2 is not the right approach.

=C2=A0

G/

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0=

=C2=A0

On 05 Mar 2016, at 23:48, Susan Hares <shares@ndzh.com> wrote:

=C2=A0

The interim on 3/7/2016 will have a discussion of revis= ions to the BGP Flow specification (BGP-FS) to add more features.=C2=A0 The= re are two suggested options:

1)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0A minimal features to existing BGP-FS (option 1)=C2=A0=

Add a few new match filters to the BGP-FS NL= RI and few new actions to the BGP-FS actions (in Extended communities).=C2= =A0 Actions would need to be done in a defined order. Each new actions woul= d need to define conflicts with existing actions. =C2=A0=C2=A0

=C2=A0

Best use case:=C2=A0 DoS attack pr= evention=C2=A0

=C2=A0

2)=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0Create a BGP-FS version 2 (option= 2)=C2=A0

Create a new BGP-FS NLRI (v2)= with a field that indicates the ordering of the BGP NLRI.=C2=A0 Add new BG= P-FS actions with an order field in the BGP Wide Communities.=C2=A0 Filters= are done in the order defined in the filter.=C2=A0 Actions are done in the= order defined in the actions.=C2=A0=C2=A0 Order numbers that tie are handl= ed in a defined order.=C2=A0

=C2=A0<= /u>

Best use case: SDN/NFV filter management=C2=A0

=C2=A0

A write-up on the issues and proposed solutions is contained in:= =C2=A0

draft-hares-idr-= flowspec-combo-01.txt.=C2=A0=C2=A0=C2=A0=C2=A0The W= G can select both option 1 and option 2.=C2=A0 This is a WG work item call = for input to the chairs on the scope of the WG item.=C2=A0 In you discussio= n of this topics, the chairs would appreciate if you would indicate if you = would support IDR working on option 1, option 2 or both option 1 and 2.=C2= =A0 This WG call items also includes a call for draft-hares-idr-flowspec-co= mbo-01.txt as a write-up of the work-item options.=C2=A0 The WG may wish to= split this draft into multiple drafts.=C2=A0

=C2=A0=

The following dra= fts are being consider for either option:=C2=A0<= /span>

1)=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0draft-eddy-idr-flowspec-packet= -rate

2)=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0draft-hao= -idr-flowspec-nv03

3)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0draft-hao-idr-flowspec-label

4)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0draft-liang-idr-bgp-flowspec-time

5)<= /span>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0draft-litowski-idr-flowspec-interfaceset=C2=A0

6)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0draft-vandevelde-idr-flowspec-path-redirect

7)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0draft-li-idr-flowspec-rpd-01.txt=C2=A0<= /span>

8)=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0draft-wu-= idr-flowspec-yang.cfg.=C2=A0

=C2=A0

=

If you wish to comment on any of t= hese drafts, we will=C2=A0

=

=C2=A0

We will conclude the Call for WG opi= nions on 3/17/2016 so these authors can have a day to revise and submit the= ir drafts before the draft deadline.=C2=A0

=C2=A0

Sue Hares and John S= cudder=C2=A0

=C2=A0

PS:

draft-li-idr-flowspec-rpd discusses limits on the = distribution of the policy which has been recast in draft-hares-idr-flowspe= c-combo as a bgp-wide community of Container type 1 with an atom of BGP Flo= w Specification ordering. However,=C2=A0 this draft is included in the list= to be able to update the mechanism from this draft into that context. =C2= =A0

=C2=A0

The yang model for BGP Flow specification is also included in this wor= k item as it will need to be modified based on the approaches.=C2=A0 The ya= ng model is in draft-wu-idr-flowspec-yang-cfg.=C2=A0 In your comments, plea= se indicate if you feel these drafts or other drafts.=C2=A0=C2=A0

=C2=A0

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

=

=C2=A0


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


--001a113fbdd414b0b4052d71101d-- From nobody Mon Mar 7 01:28:39 2016 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 73B001B3D2A for ; Mon, 7 Mar 2016 01:28:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 4MRv0RU1Gl5s for ; Mon, 7 Mar 2016 01:28:34 -0800 (PST) Received: from st11p00im-asmtp001.me.com (st11p00im-asmtp001.me.com [17.172.80.95]) (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 028F31B3D21 for ; Mon, 7 Mar 2016 01:28:34 -0800 (PST) Received: from [127.0.0.1] (ec2-52-70-63-169.compute-1.amazonaws.com [52.70.63.169]) by st11p00im-asmtp001.me.com (Oracle Communications Messaging Server 7.0.5.36.0 64bit (built Sep 8 2015)) with ESMTPSA id <0O3N00OTFWZKF700@st11p00im-asmtp001.me.com> for idr@ietf.org; Mon, 07 Mar 2016 09:28:33 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-03-07_06:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1015 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1510270003 definitions=main-1603070178 Content-type: multipart/alternative; boundary="----sinikael-?=_1-14573429121680.8666059907991439" From: Gunter Van De Velde To: Robert Raszuk In-reply-to: References: <000b01d17731$29d17230$7d745690$@ndzh.com> <005801d177a6$dcd8fea0$968afbe0$@ndzh.com> Date: Mon, 07 Mar 2016 10:28:29 +0100 X-Cm-Message-Id: 145734291177548015b8c23f2dad32f5fa0f2bce037ebacf56dd49bfbd5e8903977550 X-Cm-Draft-Id: WyJhIiwxLCJkcmFmdF9pZCIsMTQ1NzM0MjkwOTc2NSwidiIsMV0= X-Mailer: CloudMagic Message-id: <1457342912410-3d4101f0-217d1e54-48c0f9c0@icloud.com> MIME-version: 1.0 Archived-At: Cc: idr wg , Susan Hares Subject: Re: [Idr] WG Work item call - Opinions on work items (3/5/2016 to 3/17/2016) and adoption of draft-hares-idr-flowspec-combo-01.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, 07 Mar 2016 09:28:37 -0000 ------sinikael-?=_1-14573429121680.8666059907991439 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Indeed Robert, correct observation and roughly alined with mine on the = question asking if BGP is best API for SDN policy distribution ... For any new feature potentially added to BGP FS (rfc5575) i feel that the = p2mp and indirection property of BGP must be considered as a key component. Be well, G/ Sent using CloudMagic Email [https://cloudmagic.= com/k/d/mailapp?ct=3Dpa&cv=3D8.1.32&pv=3D6.0.1&source=3Demail_footer_2] On = Mon, Mar 07, 2016 at 9:15 AM, Robert Raszuk < robert@raszuk.net = [robert@raszuk.net] > wrote: Hi Sue/Gunter, On the topic of problem space, = requirements ... etc aren't we reinventing the wheel ? Aren't I2RS = documents doing that already ? https://datatracker.ietf.= org/wg/i2rs/documents/ [https://datatracker.ietf.org/wg/i2rs/documents/] And if they do is BGP FSv2 the right approach to be used as I2RS channel ? If yes I would question that simply based on the nature of BGP which is = p2mp distribution (even if augmented now for other reasons with RTC). In most of the cases network elements need to get unique set of parameters = which just does not fit BGP distribution model. If so why BGP? Is using port 179 and reuse of non AF/SAFI specific code the only reason? Or is the problem perhaps due to no APIs and common message bus across = vendors and we are trying to fit BGP to become one in the fear that it will= take decade(s) for vendors to support new common network element mgmt/API = channel ? If we go with FSv2 what is the "read" or telemetry channel from = device which will trigger proper FSv2 filter ? Is it again BGP ? - - On FSv1 I think we are ok to proceed. On the question of ordered actions or= not I think one may need to support both as likely there will be folks who= will need one or the other depending on what they are going to filter :) Best, r. On Sun, Mar 6, 2016 at 1:51 PM, Susan Hares < shares@ndzh.com = [shares@ndzh.com] > wrote: Gunter: Thank you for being the first = responder to the BGP-FS call for input. My understanding is that you = approve option 1, but are concerned about the scope of option 2. Do you feel the actions need ordering for option 1? I will ask those who propose the SDN/NFV work to write their understanding = of the use cases for the next IETF, and post it on the list. In the last = few interims, there seem to be a consensus of people indicating that the = SDN/NFV was a valid use case. However, interims are small discussion = formats so the chairs have sent this call for input. On working toward a specific solution space: the IESG has encouraged = parallel efforts between problem space development and solutions in order = to aid rapid deployment of protocols. The draft-hares-idr-flowspec-combo is= a summary of the problem space and solutions from the WG chair=E2=80=99s = viewpoint. Thank you for letting me know we need to add problem space = details. Sue From: Idr [mailto: idr-bounces@ietf.org = [idr-bounces@ietf.org] ] On Behalf Of Gunter Van De Velde Sent: Sunday, March 06, 2016 4:34 AM To: Susan Hares Cc: idr@ietf.org [idr@ietf.org] Subject: Re: [Idr] WG Work item call - = Opinions on work items (3/5/2016 to 3/17/2016) and adoption of = draft-hares-idr-flowspec-combo-01.txt My consern with the concept of = BGP-FS version 2 is that it means jumping to solution space, even before = having a rough agreement on the requirements and scope for a SDN policy = distribution mechanism. An additional concern is about using BGP for NFV = management as there may be more appropriate mechanisms available (outside = BGP). If the intent is to truly use BGP as a mechanism to distribute SDN= policies and and related management information, then what does that mean = exactly? what does such protocol extension expose as capabilities? What = are the use-cases that drive the need for existence of such technology? In that case it may be better to construct a tailor = designed BGP Policy Distribution framework version 1 (BGP-PD version 1) I believe in keeping changes to RFC5575 to a minimum, and only extend to = simple match/action capabilities that "drive indirection" and "network = wide" rules. I also believe that before trying to document a solution = space for BGP based SDN policy distribution, that both the problem space = and intended protocol properties exposed as consumable SDN API=E2=80=99s = need to be discussed and agreed upon. In that light i feel that the concept= of a BGP-FS version 2 is not the right approach. G/ On 05 Mar 2016, at 23:48, Susan Hares < shares@ndzh.com [shares@ndzh.com] >= wrote: The interim on 3/7/2016 will have a discussion of revisions to = the BGP Flow specification (BGP-FS) to add more features. There are two = suggested options: 1) A minimal features to existing BGP-FS (option 1) Add a few new match filters to the BGP-FS NLRI and few new actions to the = BGP-FS actions (in Extended communities). Actions would need to be done in = a defined order. Each new actions would need to define conflicts with = existing actions. Best use case: DoS attack prevention 2) Create a BGP-FS version 2 (option 2) Create a new BGP-FS NLRI (v2) with= a field that indicates the ordering of the BGP NLRI. Add new BGP-FS = actions with an order field in the BGP Wide Communities. Filters are done = in the order defined in the filter. Actions are done in the order defined = in the actions. Order numbers that tie are handled in a defined order. Best use case: SDN/NFV filter management A write-up on the issues and = proposed solutions is contained in: draft-hares-idr-flowspec-combo-01.txt. [https://datatracker.ietf.org/doc/draft-hares-idr-flowspec-combo/] The WG = can select both option 1 and option 2. This is a WG work item call for input to the chairs on the scope of the WG item. In you discussion of this topics, the chairs would appreciate if you would indicate if you would = support IDR working on option 1, option 2 or both option 1 and 2. This WG = call items also includes a call for draft-hares-idr-flowspec-combo-01.txt = as a write-up of the work-item options. The WG may wish to split this draft= into multiple drafts. The following drafts are being consider for = either option: 1) draft-eddy-idr-flowspec-packet-rate 2) draft-hao-idr-flowspec-nv03 3) draft-hao-idr-flowspec-label 4) draft-liang-idr-bgp-flowspec-time 5) draft-litowski-idr-flowspec-interf= aceset 6) draft-vandevelde-idr-flowspec-path-redirect 7) draft-li-idr-flowspec-rpd-01.txt 8) draft-wu-idr-flowspec-yang.cfg. If you wish to comment on any of these drafts, we will We will conclude the Call for WG opinions on 3/17/2016 so these authors can= have a day to revise and submit their drafts before the draft deadline. Sue Hares and John Scudder PS: draft-li-idr-flowspec-rpd discusses = limits on the distribution of the policy which has been recast in = draft-hares-idr-flowspec-combo as a bgp-wide community of Container type 1 with an atom of BGP Flow Specification ordering. = However, this draft is included in the list to be able to update the = mechanism from this draft into that context. The yang model for BGP Flow= specification is also included in this work item as it will need to be modified based on the approaches. The yang model is in draft-wu-idr-flowspec-yang-cfg. In your comments, please indicate if you = feel these drafts or other drafts. _____________________________________= __________ Idr mailing list Idr@ietf.org [Idr@ietf.org] https://www.ietf.org/mailman/listinfo/idr [https://www.ietf.= org/mailman/listinfo/idr] _____________________________________________= __ Idr mailing list Idr@ietf.org [Idr@ietf.org] https://www.ietf.= org/mailman/listinfo/idr [https://www.ietf.org/mailman/listinfo/idr] ------sinikael-?=_1-14573429121680.8666059907991439 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Indeed Robert, correct observation and roughly alined with = mine on the question asking if BGP is best API for SDN policy distribution = ...

For any new feature potentially added to BGP FS = (rfc5575) i feel that the p2mp and indirection property of BGP must be = considered as a key component.

Be well,
G/


Sent using CloudMagic Email =
On Mon, Mar 07, = 2016 at 9:15 AM, Robert Raszuk <robert@raszuk.net> wrote:

Hi Sue/Gunter,

On the = topic of problem space, requirements ... etc aren't we reinventing the = wheel ? Aren't I2RS documents doing that already ?

https://datatracke= r.ietf.org/wg/i2rs/documents/

And if they do is BGP FSv2 the right = approach to be used as I2RS channel ?

If yes I would question = that simply based on the nature of BGP which is p2mp distribution (even if = augmented now for other reasons with RTC).

In most of the cases network elements= need to get unique set of parameters which just does not fit BGP = distribution model. If so why BGP?

Is using port 179 and reuse of non = AF/SAFI specific code the only reason?

Or is the problem perhaps due to no = APIs and common message bus across vendors and we are trying to fit BGP to = become one in the fear that it will take decade(s) for vendors to support = new common network element mgmt/API channel ?

If we go with FSv2 what is the "read"= or telemetry channel from device which will trigger proper FSv2 filter ? = Is it again BGP ?

- -

On FSv1 I think we are ok to proceed. On the question of = ordered actions or not I think one may need to support both as likely there= will be folks who will need one or the other depending on what they are = going to filter :)

Best,


On Sun, Mar 6, 2016 at= 1:51 PM, Susan Hares <shares@ndzh.com> wrote:

Gunter: =

=

Thank you for being the first = responder to the BGP-FS call for input. My understanding is that you = approve option 1, but are concerned about the scope of option 2. Do you = feel the actions need ordering for option 1?

I will ask those who = propose the SDN/NFV work to write their understanding of the use cases for = the next IETF, and post it on the list. In the last few interims, there = seem to be a consensus of people indicating that the SDN/NFV was a valid = use case. However, interims are small discussion formats so the chairs = have sent this call for input.

On working toward a = specific solution space: the IESG has encouraged parallel efforts between = problem space development and solutions in order to aid rapid deployment of= protocols. The draft-hares-idr-flowspec-combo is a summary of the = problem space and solutions from the WG chair=E2=80=99s viewpoint. Thank = you for letting me know we need to add problem space details. =

=

Sue

=

From: Idr [mailto:idr-bounces@ietf.org] On Behalf= Of Gunter Van De Velde
Sent: Sunday, March 06, 2016 4:34 = AM
To: Susan Hares
Cc: idr@ietf.org
Subject: Re: [Idr] WG Work item call - = Opinions on work items (3/5/2016 to 3/17/2016) and adoption of = draft-hares-idr-flowspec-combo-01.txt

<= div>

My consern with the concept of BGP-FS version 2 is that= it means jumping to solution space, even before having a rough agreement = on the requirements and scope for a SDN policy distribution mechanism.=

An additional concern = is about using BGP for NFV management as there may be more appropriate = mechanisms available (outside BGP).

If= the intent is to truly use BGP as a mechanism to distribute SDN policies = and and related management information, then what does that mean exactly? = what does such protocol extension

expose as capabilities? What are the use-cases that = drive the need for existence of such technology? In that case it may be = better to construct a tailor designed BGP Policy Distribution framework = version 1 (BGP-PD version 1)

I = believe in keeping changes to RFC5575 to a minimum, and only extend to = simple match/action capabilities that "drive indirection" and "network = wide" rules.

I also = believe that before trying to document a solution space for BGP based SDN = policy distribution, that both the problem space and intended protocol = properties exposed as consumable SDN API=E2=80=99s need to be discussed and= agreed upon. In that light i feel that the concept of a BGP-FS version 2 = is not the right approach.

G/

=

On 05 Mar 2016, at 23:48, Susan Hares = <shares@ndzh.com> = wrote:

=

The interim on = 3/7/2016 will have a discussion of revisions to the BGP Flow specification = (BGP-FS) to add more features. There are two suggested = options:

1) = A minimal = features to existing BGP-FS (option 1)

Add a few new match filters to the BGP-FS NLRI and = few new actions to the BGP-FS actions (in Extended communities). Actions = would need to be done in a defined order. Each new actions would need to = define conflicts with existing actions.

Best use case: DoS attack prevention =

2) = Create a BGP-FS version 2 (option = 2)

Create a new = BGP-FS NLRI (v2) with a field that indicates the ordering of the BGP NLRI. = Add new BGP-FS actions with an order field in the BGP Wide Communities. = Filters are done in the order defined in the filter. Actions are done in = the order defined in the actions. Order numbers that tie are handled in a= defined order.

Best use case: SDN/NFV filter management =

A write-up on the issues and proposed = solutions is contained in:

<= span style=3D"color:purple">draft-hares-idr-flowspec-combo-01.txt. = The WG can select both option 1 and option 2. This is= a WG work item call for input to the chairs on the scope of the WG item. = In you discussion of this topics, the chairs would appreciate if you would = indicate if you would support IDR working on option 1, option 2 or both = option 1 and 2. This WG call items also includes a call for = draft-hares-idr-flowspec-combo-01.txt as a write-up of the work-item = options. The WG may wish to split this draft into multiple drafts. =

The following drafts are being consider = for either option:

1) = draft-eddy-idr-flowspec-packet-rate

2) = draft-hao-idr-f= lowspec-nv03

3) draft-hao-idr-flowspec-label

4) = draft-liang-idr-bgp-flowspec-time<= u>

5) = draft-litowski-= idr-flowspec-interfaceset

6) = draft-vandevelde-idr-flowspec-path-redire= ct

7) = draft-li-idr-fl= owspec-rpd-01.txt

8) = draft-wu-idr-flowspec-yang.cfg. =

If you wish to comment on any of these = drafts, we will

We will conclude the Call for WG opinions = on 3/17/2016 so these authors can have a day to revise and submit their = drafts before the draft deadline.

=

Sue Hares and John Scudder =

PS:

draft-li-idr-flowspec-rpd discusses limits= on the distribution of the policy which has been recast in = draft-hares-idr-flowspec-combo as a bgp-wide community of Container type 1 = with an atom of BGP Flow Specification ordering. However, this draft is = included in the list to be able to update the mechanism from this draft = into that context.

The yang model for BGP Flow specification = is also included in this work item as it will need to be modified based on = the approaches. The yang model is in draft-wu-idr-flowspec-yang-cfg. In = your comments, please indicate if you feel these drafts or other drafts. =

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

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


------sinikael-?=_1-14573429121680.8666059907991439-- From nobody Mon Mar 7 07:01:55 2016 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 9409A1B421A for ; Mon, 7 Mar 2016 07:01:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.257 X-Spam-Level: X-Spam-Status: No, score=-96.257 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.793, 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 VglGjUeihSdP for ; Mon, 7 Mar 2016 07:01:48 -0800 (PST) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 F0B441B4205 for ; Mon, 7 Mar 2016 07:01:47 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.30; From: "Susan Hares" To: "'Robert Raszuk'" References: <000b01d17731$29d17230$7d745690$@ndzh.com> <005801d177a6$dcd8fea0$968afbe0$@ndzh.com> In-Reply-To: Date: Mon, 7 Mar 2016 10:01:15 -0500 Message-ID: <00d001d17882$328f9fd0$97aedf70$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D1_01D17858.49BCA510" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGcwDBIhMS4vQbRNdLW21dU5JTRjQI/zGpmAmCBwpsCWexqoJ9/hyUQ Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'idr wg' Subject: Re: [Idr] WG Work item call - Opinions on work items (3/5/2016 to 3/17/2016) and adoption of draft-hares-idr-flowspec-combo-01.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, 07 Mar 2016 15:01:51 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00D1_01D17858.49BCA510 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Robert:=20 =20 Thank you for your input on IDR Flow specification version 2=E2=80=99s ( = that I2RS provides the ordering of flow specifications), and that BGP = does not need to add option 2. Does your concern on overlapping with = I2RS include option 1 as well?=20 =20 Sue=20 =20 From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Robert Raszuk Sent: Monday, March 07, 2016 3:15 AM To: Susan Hares Cc: idr wg Subject: Re: [Idr] WG Work item call - Opinions on work items (3/5/2016 = to 3/17/2016) and adoption of draft-hares-idr-flowspec-combo-01.txt =20 Hi Sue/Gunter, =20 On the topic of problem space, requirements ... etc aren't we = reinventing the wheel ? Aren't I2RS documents doing that already ?=20 =20 https://datatracker.ietf.org/wg/i2rs/documents/ =20 And if they do is BGP FSv2 the right approach to be used as I2RS channel = ?=20 =20 If yes I would question that simply based on the nature of BGP which is = p2mp distribution (even if augmented now for other reasons with RTC).=20 =20 In most of the cases network elements need to get unique set of = parameters which just does not fit BGP distribution model. If so why = BGP?=20 =20 Is using port 179 and reuse of non AF/SAFI specific code the only = reason?=20 =20 Or is the problem perhaps due to no APIs and common message bus across = vendors and we are trying to fit BGP to become one in the fear that it = will take decade(s) for vendors to support new common network element = mgmt/API channel ? =20 =20 If we go with FSv2 what is the "read" or telemetry channel from device = which will trigger proper FSv2 filter ? Is it again BGP ?=20 =20 - -=20 =20 On FSv1 I think we are ok to proceed. On the question of ordered actions = or not I think one may need to support both as likely there will be = folks who will need one or the other depending on what they are going to = filter :) =20 Best, r. =20 =20 On Sun, Mar 6, 2016 at 1:51 PM, Susan Hares wrote: Gunter:=20 =20 Thank you for being the first responder to the BGP-FS call for input. = My understanding is that you approve option 1, but are concerned about = the scope of option 2. Do you feel the actions need ordering for = option 1? =20 =20 I will ask those who propose the SDN/NFV work to write their = understanding of the use cases for the next IETF, and post it on the = list. In the last few interims, there seem to be a consensus of people = indicating that the SDN/NFV was a valid use case. However, interims are = small discussion formats so the chairs have sent this call for input.=20 =20 On working toward a specific solution space: the IESG has encouraged = parallel efforts between problem space development and solutions in = order to aid rapid deployment of protocols. The = draft-hares-idr-flowspec-combo is a summary of the problem space and = solutions from the WG chair=E2=80=99s viewpoint. Thank you for letting = me know we need to add problem space details. =20 =20 Sue =20 =20 From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Gunter Van De Velde Sent: Sunday, March 06, 2016 4:34 AM To: Susan Hares Cc: idr@ietf.org Subject: Re: [Idr] WG Work item call - Opinions on work items (3/5/2016 = to 3/17/2016) and adoption of draft-hares-idr-flowspec-combo-01.txt =20 My consern with the concept of BGP-FS version 2 is that it means jumping = to solution space, even before having a rough agreement on the = requirements and scope for a SDN policy distribution mechanism. An additional concern is about using BGP for NFV management as there may = be more appropriate mechanisms available (outside BGP).=20 =20 If the intent is to truly use BGP as a mechanism to distribute SDN = policies and and related management information, then what does that = mean exactly? what does such protocol extension=20 expose as capabilities? What are the use-cases that drive the need for = existence of such technology? In that case it may be better to construct = a tailor designed BGP Policy Distribution framework version 1 (BGP-PD = version 1) =20 I believe in keeping changes to RFC5575 to a minimum, and only extend to = simple match/action capabilities that "drive indirection" and "network = wide" rules. I also believe that before trying to document a solution space for BGP = based SDN policy distribution, that both the problem space and intended = protocol properties exposed as consumable SDN API=E2=80=99s need to be = discussed and agreed upon. In that light i feel that the concept of a = BGP-FS version 2 is not the right approach. =20 G/ =20 =20 =20 =20 =20 =20 =20 On 05 Mar 2016, at 23:48, Susan Hares wrote: =20 The interim on 3/7/2016 will have a discussion of revisions to the BGP = Flow specification (BGP-FS) to add more features. There are two = suggested options: 1) A minimal features to existing BGP-FS (option 1)=20 Add a few new match filters to the BGP-FS NLRI and few new actions to = the BGP-FS actions (in Extended communities). Actions would need to be = done in a defined order. Each new actions would need to define conflicts = with existing actions. =20 =20 Best use case: DoS attack prevention=20 =20 2) Create a BGP-FS version 2 (option 2)=20 Create a new BGP-FS NLRI (v2) with a field that indicates the ordering = of the BGP NLRI. Add new BGP-FS actions with an order field in the BGP = Wide Communities. Filters are done in the order defined in the filter. = Actions are done in the order defined in the actions. Order numbers = that tie are handled in a defined order.=20 =20 Best use case: SDN/NFV filter management=20 =20 A write-up on the issues and proposed solutions is contained in:=20 = draft-hares-idr-flowspec-combo-01.txt. The WG can select both option = 1 and option 2. This is a WG work item call for input to the chairs on = the scope of the WG item. In you discussion of this topics, the chairs = would appreciate if you would indicate if you would support IDR working = on option 1, option 2 or both option 1 and 2. This WG call items also = includes a call for draft-hares-idr-flowspec-combo-01.txt as a write-up = of the work-item options. The WG may wish to split this draft into = multiple drafts.=20 =20 The following drafts are being consider for either option:=20 1) draft-eddy-idr-flowspec-packet-rate 2) draft-hao-idr-flowspec-nv03 3) draft-hao-idr-flowspec-label 4) draft-liang-idr-bgp-flowspec-time 5) draft-litowski-idr-flowspec-interfaceset=20 6) draft-vandevelde-idr-flowspec-path-redirect 7) draft-li-idr-flowspec-rpd-01.txt=20 8) draft-wu-idr-flowspec-yang.cfg.=20 =20 If you wish to comment on any of these drafts, we will=20 =20 We will conclude the Call for WG opinions on 3/17/2016 so these authors = can have a day to revise and submit their drafts before the draft = deadline.=20 =20 Sue Hares and John Scudder=20 =20 PS: draft-li-idr-flowspec-rpd discusses limits on the distribution of the = policy which has been recast in draft-hares-idr-flowspec-combo as a = bgp-wide community of Container type 1 with an atom of BGP Flow = Specification ordering. However, this draft is included in the list to = be able to update the mechanism from this draft into that context. =20 =20 The yang model for BGP Flow specification is also included in this work = item as it will need to be modified based on the approaches. The yang = model is in draft-wu-idr-flowspec-yang-cfg. In your comments, please = indicate if you feel these drafts or other drafts. =20 =20 _______________________________________________ Idr mailing list Idr@ietf.org = https://www.ietf.org/mailman/listinfo/idr =20 _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr =20 ------=_NextPart_000_00D1_01D17858.49BCA510 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Robert:

 

Thank you for your input on IDR Flow specification version = 2=E2=80=99s ( that I2RS provides the ordering of flow specifications), = and that BGP does not need to add option 2. =C2=A0=C2=A0=C2=A0Does your = concern on overlapping with I2RS include option 1 as well? =

 

Sue

 

From:= = Idr [mailto:idr-bounces@ietf.org] On Behalf Of Robert = Raszuk
Sent: Monday, March 07, 2016 3:15 AM
To: = Susan Hares
Cc: idr wg
Subject: Re: [Idr] WG Work = item call - Opinions on work items (3/5/2016 to 3/17/2016) and adoption = of draft-hares-idr-flowspec-combo-01.txt

 

Hi = Sue/Gunter,

 

On the topic of problem = space, requirements ... etc aren't we reinventing the wheel ? Aren't = I2RS documents doing that already = ? 

 

 

And = if they do is BGP FSv2 the right approach to be used as I2RS channel = ? 

 

If = yes I would question that simply based on the nature of BGP which is = p2mp distribution (even if augmented now for other reasons with = RTC). 

 

In = most of the cases network elements need to get unique set of parameters = which just does not fit BGP distribution model. If so why = BGP? 

 

Is = using port 179 and reuse of non AF/SAFI specific code the only = reason? 

 

Or is = the problem perhaps due to no APIs and common message bus across vendors = and we are trying to fit BGP to become one in the fear that it will take = decade(s) for vendors to support new common network element mgmt/API = channel ?  

 

If we = go with FSv2 what is the "read" or telemetry channel from = device which will trigger proper FSv2 filter ? Is it again BGP = ? 

 

- = - 

 

On = FSv1 I think we are ok to proceed. On the question of ordered actions or = not I think one may need to support both as likely there will be folks = who will need one or the other depending on what they are going to = filter :)

 

Best,

r.

=

 

 

On Sun, = Mar 6, 2016 at 1:51 PM, Susan Hares <shares@ndzh.com> = wrote:

Gunter:

 

Thank you for being the first responder to the BGP-FS call for = input.  My understanding is that you approve option 1, but are = concerned about the scope of option 2.   Do you feel the = actions need ordering for option 1?  

 

I will ask those who propose the SDN/NFV work to write their = understanding of the use cases for the next IETF, and post it on the = list.  In the last few interims, there seem to be a consensus of = people indicating that the SDN/NFV was a valid use case.  However, = interims are small discussion formats so the chairs have sent this call = for input.

 

On working toward a specific solution space: the IESG has encouraged = parallel efforts between problem space development and solutions in = order to aid rapid deployment of protocols.   The = draft-hares-idr-flowspec-combo  is a summary of the problem space = and solutions from the WG chair=E2=80=99s viewpoint.  Thank you for = letting me know we need to add problem space details. =  

 

Sue       

 

From:= = Idr [mailto:idr-bounces@ietf.org] On Behalf Of Gunter = Van De Velde
Sent: Sunday, March 06, 2016 4:34 = AM
To: Susan Hares
Cc: idr@ietf.org
Subject: Re: [Idr] WG Work = item call - Opinions on work items (3/5/2016 to 3/17/2016) and adoption = of = draft-hares-idr-flowspec-combo-01.txt

 <= /o:p>

My consern = with the concept of BGP-FS version 2 is that it means jumping to = solution space, even before having a rough agreement on the requirements = and scope for a SDN policy distribution = mechanism.

An = additional concern is about using BGP for NFV management as there may be = more appropriate mechanisms available (outside = BGP). 

 <= /o:p>

If the = intent is to truly use BGP as a mechanism to distribute SDN policies and = and related management information, then what does that mean exactly? = what does such protocol extension 

expose as = capabilities? What are the use-cases that drive the need for existence = of such technology? In that case it may be better to construct a tailor = designed BGP Policy Distribution framework version 1 (BGP-PD version = 1)

 <= /o:p>

I believe = in keeping changes to RFC5575 to a minimum, and only extend to simple = match/action capabilities that "drive indirection" and = "network wide" rules.

I also = believe that before trying to document a solution space for BGP based = SDN policy distribution, that both the problem space and intended = protocol properties exposed as consumable SDN API=E2=80=99s need to be = discussed and agreed upon. In that light i feel that the concept of a = BGP-FS version 2 is not the right approach.

 <= /o:p>

G/

 <= /o:p>

 <= /o:p>

 <= /o:p>

 <= /o:p>

 <= /o:p>

 <= /o:p>

 <= /o:p>

On 05 Mar = 2016, at 23:48, Susan Hares <shares@ndzh.com> wrote:

 <= /o:p>

The = interim on 3/7/2016 will have a discussion of revisions to the BGP Flow = specification (BGP-FS) to add more features.  There are two = suggested options:

1)      A = minimal features to existing BGP-FS (option = 1) 

Add a few = new match filters to the BGP-FS NLRI and few new actions to the BGP-FS = actions (in Extended communities).  Actions would need to be done = in a defined order. Each new actions would need to define conflicts with = existing actions.   

 

Best use = case:  DoS attack prevention 

 

2)      Create a = BGP-FS version 2 (option 2) 

Create a = new BGP-FS NLRI (v2) with a field that indicates the ordering of the BGP = NLRI.  Add new BGP-FS actions with an order field in the BGP Wide = Communities.  Filters are done in the order defined in the = filter.  Actions are done in the order defined in the = actions.   Order numbers that tie are handled in a defined = order. 

 

Best use = case: SDN/NFV filter management 

 

A write-up = on the issues and proposed solutions is contained = in: 

draft-hares-idr-flowspec-combo-01.txt.    The WG can select both option 1 and option = 2.  This is a WG work item call for input to the chairs on the = scope of the WG item.  In you discussion of this topics, the chairs = would appreciate if you would indicate if you would support IDR working = on option 1, option 2 or both option 1 and 2.  This WG call items = also includes a call for draft-hares-idr-flowspec-combo-01.txt as a = write-up of the work-item options.  The WG may wish to split this = draft into multiple drafts. 

 

The = following drafts are being consider for either = option: 

1)      draft-eddy-= idr-flowspec-packet-rate

2)      draft-hao-i= dr-flowspec-nv03

3)      draft-hao-i= dr-flowspec-label

4)      draft-liang= -idr-bgp-flowspec-time

5)      draft-litow= ski-idr-flowspec-interfaceset 

6)      draft-vande= velde-idr-flowspec-path-redirect

7)      draft-li-id= r-flowspec-rpd-01.txt 

8)      draft-wu-id= r-flowspec-yang.cfg. 

 

If you = wish to comment on any of these drafts, we = will 

 

We will = conclude the Call for WG opinions on 3/17/2016 so these authors can have = a day to revise and submit their drafts before the draft = deadline. 

 

Sue Hares = and John Scudder 

 

PS:<= o:p>

draft-li-id= r-flowspec-rpd discusses limits on the distribution of the policy which = has been recast in draft-hares-idr-flowspec-combo as a bgp-wide = community of Container type 1 with an atom of BGP Flow Specification = ordering. However,  this draft is included in the list to be able = to update the mechanism from this draft into that context. =  

 

The yang = model for BGP Flow specification is also included in this work item as = it will need to be modified based on the approaches.  The yang = model is in draft-wu-idr-flowspec-yang-cfg.  In your comments, = please indicate if you feel these drafts or other = drafts.  

 

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

 <= /o:p>


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

 

------=_NextPart_000_00D1_01D17858.49BCA510-- From nobody Mon Mar 7 07:09:17 2016 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 84E9D1B4270 for ; Mon, 7 Mar 2016 07:09:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.257 X-Spam-Level: X-Spam-Status: No, score=-98.257 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, FH_RELAY_NODNS=1.451, GB_I_INVITATION=-2, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.793, 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 4Us5uhhI8dru for ; Mon, 7 Mar 2016 07:09:13 -0800 (PST) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 2C11F1B4282 for ; Mon, 7 Mar 2016 07:09:08 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.30; From: "Susan Hares" To: Date: Mon, 7 Mar 2016 10:08:34 -0500 Message-ID: <00dd01d17883$384f3920$a8edab60$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00DE_01D17859.4F7C3E60" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdF4gv7W4op0fIbrTFSf5HLnMD6Cyg== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: jgs@bgp.nu Subject: Re: [Idr] BGP Interim will be held on 3/7/2016 at 10:00am - 11:30am ET 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, 07 Mar 2016 15:09:15 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00DE_01D17859.4F7C3E60 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Here=E2=80=99s the information for the Interim on March 7th interim. = We are meeting now.=20 =20 Sue=20 =20 From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Friday, March 04, 2016 3:34 PM To: idr@ietf.org Subject: [Idr] BGP Interim on 3/7/2016 at 10:00am - 11:30am ET =20 BGP interim will be held on Monday 3/7/2016 from 10:00am =E2=80=93 = 11:30am ET. =20 The topics are:=20 =20 1) BGP Flow Specification =E2=80=93 2 options for work [10:00 = =E2=80=93 11:00 am] =20 a. Option 1: Extension of current BGP Flow Specification=20 b. Option 2: Version 2 of BGP Flow Specification using new NLRI and = Wide BGP communities to allow ordering of filters and actions.=20 c. Option 3: Do both option 1 and option 2=20 =20 Documents discussed:=20 draft-hares-idr-bgp-flowspec-combo-01.txt=20 draft-eddy-idr-flowspec-packet-rate-00.txt draft-hao-idr-flowspec-nv03-03.txt=20 draft-hao-idr-redirect-tunnel-00.txt draft-liang-idr-bgp-flowspec-label-01.txt draft-liang-idr-bgp-flowspec-time-01.txt draft-litkowski-idr-flowspec-interfaceset-03.txt draft-vandevelde-idr-flowspec-path-redirect-01.txt draft-ietf-idr-wide-bgp-communities-01.txt=20 draft-ietf-idr-tunnel-encaps-01.txt draft-ietf-idr-flowspec-l2vpn-03.txt=20 draft-li-idr-flowspec-rpd-01.txt.=20 =20 2) Yang models [11:00am =E2=80=93 11:30]=20 a. BGP Flow Specification Yang model=20 b. BGP Extension models for BGP=20 =20 Documents discussed:=20 draft-wu-idr-flowspec-yang-cfg-02 draft-hares-idr-bgp-flowspec-combo-01.txt =20 draft-ietf-idr-bgp-model-01.txt=20 =20 =20 Web ex:=20 = = https://ietf.webex.com/ietf/j.php?MTID=3Dm944a81587e9ce48ff4c927d7545c145= 6 =20 1-877-668-4493 Call-in toll free number (US/Canada) 1-650-479-3208 Call-in toll number (US/Canada) =20 =20 Sue Hares and John Scudder=20 =20 From: IDR Working Group [mailto:messenger@webex.com]=20 Sent: Friday, March 04, 2016 3:19 PM To: idr-chairs@tools.ietf.org Subject: (Forward to others) WebEx meeting invitation: IDR interim 3: = Flow Specification =20 You can forward this invitation to others.=20 =20 Hello,=20 IDR Working Group invites you to join this WebEx meeting.=20 =20 =20 =20 IDR interim 3: Flow Specification=20 Monday, March 7, 2016=20 10:00 am | Eastern Standard Time (New York, GMT-05:00) | 2 hrs=20 =20 =20 =20 = Join WebEx meeting=20 =20 Meeting number:=20 644 627 626=20 Meeting password: flows.are.fun =20 =20 =20 Join by phone 1-877-668-4493 Call-in toll free number (US/Canada) 1-650-479-3208 Call-in toll number (US/Canada) Access code: 644 627 626 Toll-free calling = restrictions =20 =20 =20 = Add this meeting to your calendar. (Cannot add from mobile devices.) =20 =20 =20 Can't join the meeting? Contact = support.=20 =20 =20 =20 IMPORTANT NOTICE: Please note that this WebEx service allows audio and = other information sent during the session to be recorded, which may be = discoverable in a legal matter. By joining this session, you = automatically consent to such recordings. If you do not consent to being = recorded, discuss your concerns with the host or do not join the = session. =20 ------=_NextPart_000_00DE_01D17859.4F7C3E60 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Here=E2=80=99s the information for the Interim on March = 7th interim.=C2=A0=C2=A0 We are meeting now. =

 

Sue

 

From:= = Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan = Hares
Sent: Friday, March 04, 2016 3:34 PM
To: = idr@ietf.org
Subject: [Idr] BGP Interim on 3/7/2016 at 10:00am = - 11:30am ET

 

BGP interim will be held on Monday 3/7/2016 from 10:00am =E2=80=93 = 11:30am ET.  

The topics are:

 

1)      = BGP Flow Specification =E2=80=93 2 options for work [10:00 =E2=80=93 = 11:00 am]  

a.       = Option 1: Extension of current BGP Flow Specification =

b.      = Option 2: Version 2 of BGP Flow Specification using new NLRI and Wide = BGP communities to allow ordering of filters and actions. =

c.       = Option 3: Do both option 1 and option 2

 

       Documents discussed: =

           draf= t-hares-idr-bgp-flowspec-combo-01.txt

           draf= t-eddy-idr-flowspec-packet-rate-00.txt

           = draft-hao-idr-flowspec-nv03-03.txt

           draf= t-hao-idr-redirect-tunnel-00.txt

           = draft-liang-idr-bgp-flowspec-label-01.txt

           = draft-liang-idr-bgp-flowspec-time-01.txt

           = draft-litkowski-idr-flowspec-interfaceset-03.txt

           = draft-vandevelde-idr-flowspec-path-redirect-01.txt

<= p class=3DMsoNormal>           = draft-ietf-idr-wide-bgp-communities-01.txt

           draf= t-ietf-idr-tunnel-encaps-01.txt

           = draft-ietf-idr-flowspec-l2vpn-03.txt

           draf= t-li-idr-flowspec-rpd-01.txt.

 

2)      = Yang models [11:00am =E2=80=93 11:30]

a.       = BGP Flow Specification Yang model

b.      = BGP Extension models for BGP

 

          Documents = discussed:

draft-wu-idr-flowspec-yang-cfg-02

draft-hares-idr-bgp-flowspec-combo-01.txt =     

           &nbs= p; draft-ietf-idr-bgp-model-01.txt

 

 

Web ex:

https://ietf.webex.com/ietf/j.= php?MTID=3Dm944a81587e9ce48ff4c927d7545c1456=

 

1-877-668-4493 Call-in toll free number = (US/Canada)

1-650-479-3208 Call-in toll number = (US/Canada)

 

 

Sue Hares and John Scudder

 

From:= = IDR Working Group [mailto:messenger@webex.com] =
Sent: Friday, March 04, 2016 3:19 PM
To: idr-chairs@tools.ietf.orgSubject: (Forward to others) WebEx meeting invitation: IDR = interim 3: Flow Specification

 

You can forward this invitation to others. =

 

Hello,

IDR Working Group invites you to join this WebEx meeting. =

 

 

 

IDR interim 3: = Flow Specification =

Monday, March 7, 2016

10:00 am  |  Eastern Standard Time (New York, = GMT-05:00)  |  2 hrs =

 

 

 

Join = WebEx meeting =

 

Meeting number:

644 627 626

Meeting password:

flows.are.fun

 

 

 

Join by = phone

1-877-668-4493 Call-in toll free number = (US/Canada)

1-650-479-3208 Call-in toll number = (US/Canada)

Access code: 644 627 626

Toll-free = calling = restrictions

 

 

 

Add this = meeting to your calendar. (Cannot add from mobile = devices.)

 

 

 

Can't join the meeting? Contact support. =

 

 

 

= IMPORTANT NOTICE: Please note that this WebEx service allows audio and = other information sent during the session to be recorded, which may be = discoverable in a legal matter. By joining this session, you = automatically consent to such recordings. If you do not consent to being = recorded, discuss your concerns with the host or do not join the = session.

 

------=_NextPart_000_00DE_01D17859.4F7C3E60-- From nobody Wed Mar 9 09:10:32 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A07112D8AC for ; Wed, 9 Mar 2016 09:07:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PUdLRBATnhQi for ; Wed, 9 Mar 2016 09:07:42 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0107.outbound.protection.outlook.com [65.55.169.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9596E12E082 for ; Wed, 9 Mar 2016 09:06:58 -0800 (PST) Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; Received: from [172.29.110.147] (66.129.239.15) by DM2PR05MB702.namprd05.prod.outlook.com (10.141.177.23) with Microsoft SMTP Server (TLS) id 15.1.427.16; Wed, 9 Mar 2016 17:06:53 +0000 From: John G.Scudder Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 9 Mar 2016 12:06:44 -0500 Message-ID: To: "idr@ietf. org" MIME-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) X-Originating-IP: [66.129.239.15] X-ClientProxiedBy: BY2PR08CA0067.namprd08.prod.outlook.com (25.163.62.163) To DM2PR05MB702.namprd05.prod.outlook.com (10.141.177.23) X-MS-Office365-Filtering-Correlation-Id: 93963e37-ba97-40ca-5f34-08d3483d370f X-Microsoft-Exchange-Diagnostics: 1; DM2PR05MB702; 2:j57+vIq8V3kkVF8T2drD+dw/gUYzx9hSpWKgguGXNTE1rKCoBmy5eC3YGd0Tvfah7ZqyyWpypxgUvGakCy9MQnhdY3RyJGzmrmX5RRA8Kklr3dHUUr6H07xHdQZI+mL1amKr9fpAVg3XPOd5ArCbUJEoho9l35bOA4RScrZ55Sj3j+UdzD9MUbtrmM4wFpoZ; 3:o6PjJQFbk+diHZWzdQiLybs629pKXGOzZMcv7OeKbPfEFp0Kc1SUvKE4giepEQZv/i1kpn8cVNRsrMuU0LcaiJ8t2qfjoKT3Osh7V3U4qgSM1dodQc4WAA8dUgiz9G0o; 25:NnJKvjW873mPdt6zeozQUfYP7JJWl8Ogzq7FnhApm07xOMcvzXTeR62hU3pUwB7rVbUkaKC02PMBLnNGtMJR9mjqyNwDpEQa9xSN2/ZPT3YXI4VdH5tu/XkMAySdig7L4f4hmYf+DnTYbf3d9HSDVGYhW2psBmdIRe6oAwWWbgSzhAoHxlt2vjaXL0kqxGWzNFJg2hD4Wc8NqfrioQ8xQw6MqpqlaEmPvstX1uQlVUTXCldgpJ9I9oLh3Nd2E9n0e9QG88jcY8BmqKYeWEtcty/J9A9AJhjEpf85BQSt5o26tWWpZO1arsJj1zmU26YcgyVyU8qJHADcC3/PUPti8g== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR05MB702; X-Microsoft-Exchange-Diagnostics: 1; DM2PR05MB702; 20:zOa9/2usU/9XpDvKdprwIr9NPb/VO2BclwK/vk3Rz3VsZTAv+G8CNxPRW7jQWbgzBvyH7w28s2duHdfMBPJzG+LzjaRYNp1gCT5sQHsob/YEE0ww4MjdbICMHRrFSHDomZrxmS4CXOFZm2S7nu0keA+aicMb0y8bs8jOf+KqvS9whgjg0vJwm8yIRh8rt9WW/+rJIsy5cV7g6b6LYn2k6jk8K9zF3k4Pu3F4QDytidsBOh5C84XqXhHLm4nPBxH5waJNpZe+akJ+oDifAHMo7Zs+uJAI8VBUU7I3JvmoP+fLInp6wfXZ+O0MGMQdioAY482wkZG1vrkdcv82DpIL1oALaZYeOKYBqPEd74IuzkLOKt7im+r/i2RI7DTq0LMs2QcSGaENQCjF9gulNEuci10OmxXdw+ePOOMd+0Sc/Lw7vivi/GhtKzOJLl6ObRGWTmE/JknFCcSHClaR6U/vgT8BAjUkC48pCo7gbG4pSDOXrHInoKmKdN3ExJEQVPgk; 4:p5gjr2WWjn1nPQZduGHIxDRXTcxrJHvRomexLfPknrO9FjcvZuJ8f6/aLXIFIarivq2wNm5s0cpPW110RAwZ8MuJqg8qs6/OepxCHFv+S/yFRa0RqZgQOTIuqKIYPeWXAzfGh+HNDNI8vnJskk//jzMkRpDVakn4LI3pZ69q9tsEM/J09XoMlmtc2Md0WBawmjSHBveS/EhHspvAXH3gZFrEWUSHpZrlpMBeHWLD0w1Sa13QsCAKa9duDZFsgFBPb+Bv4tjKXC6yt9nQCyEIHu3HlZ/D823346jLj1QMM38ZL3D+O6/oDlQxV6gjvr1RarVfemywxE/SQLLQYo0dRugBHT6lV3jVtboViD9aNsADroqDwGRlWIbq2kCev8bt X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:DM2PR05MB702; BCL:0; PCL:0; RULEID:; SRVR:DM2PR05MB702; X-Forefront-PRVS: 0876988AF0 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(164054003)(54014002)(377454003)(5008740100001)(77096005)(36756003)(97756001)(586003)(1096002)(23726003)(86362001)(47776003)(66066001)(57306001)(42186005)(4326007)(33656002)(50226001)(15975445007)(50986999)(110136002)(46406003)(19580395003)(81166005)(83716003)(92566002)(2906002)(5004730100002)(189998001)(3846002)(82746002)(229853001)(6116002)(50466002)(42262002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR05MB702; H:[172.29.110.147]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM2PR05MB702; 23:LxlPvzrn9yQCYjHe0suAF5ryccH32HApNFySB1dde5?= =?us-ascii?Q?YSRyH+cHg/p4rkMDAHEHDH0AkGbv0ZrS9KtrvHCDLD+Va3dXJ6MGpkJ6DJHw?= =?us-ascii?Q?igvvAlkZZgNM81pwBR/UWsZW8uzxLSBrdViTJrxPkUMWF3mPc1kSdfarFG9J?= =?us-ascii?Q?yHerBCenllneKDtSC9N6QKLU9YUbdfAx0TFyo3CBeuf48GmARfa/Csp5cjCJ?= =?us-ascii?Q?oYFCYUCK5OzLM33IVk4NxnR1gvfNlHn9BJyqnLa+jZSmu3Mg4PUyHNWERAj0?= =?us-ascii?Q?jKPg4UI6LWQCLWcLC0yTM6JmHoAb3xNgw2g+62No6pZLkanCpZpQtLPTC+d3?= =?us-ascii?Q?u/Vy70WfImshVC2bfJW56CJ6AmJU+xhiGQw4ZcyXEYoRCD8Z1UdRkNwk4TeM?= =?us-ascii?Q?dFI+VwelpK+xOoTv9wgNCjsNJM2qu+h2t13Spj0htrD0UZBbb/IpJTHBfZpU?= =?us-ascii?Q?c00SMufDisRZtkpzKpal49CcSMtbO5aELtTgx96gPrJ/EKWShDe0zLeDijXx?= =?us-ascii?Q?Y/j1CehxLhb08j2ZoARKzCI/XMXz2hNB04nlE4yWx+XveCizYLMiT+YNrcca?= =?us-ascii?Q?RgkJT3BdywqRuYsM6lR2DnGQbG34r23xxeZGYc33xb/UoqMhcjWPOLOFsqOQ?= =?us-ascii?Q?eySlSL/6aeGtgNm9MLcsxOLt2EeZejteqAZl9133zsuHyBdqCEFRVUu1Upbx?= =?us-ascii?Q?57bAYMv4TH4zjOzHEerqfQgU/c51bPfYL5RUqs5DQ/6tsFmPvUWUKPG9+lq5?= =?us-ascii?Q?ofIhzZOe8wgjBrB5WjZuEt0qzvfoDInDsrjFtIvDH6c7GwS72ve0++1znLr5?= =?us-ascii?Q?nAXB0K/FWv3z6B4+mU/r7VNUvjyWnEUAVoMKqVqTzyJ3o5fbTaWWyhDo5Uj7?= =?us-ascii?Q?Y53fZ4vnEKVAsmi62S2NOuKslWZPnkaCLQItK4zA2MlpsnrdKZXIH6rWFMUr?= =?us-ascii?Q?EAxPat5NWRvsW7PV0iTa1Tlaj1J/+lAex/U3MInPrPMCOQi4VVqmee1ZFdB2?= =?us-ascii?Q?+ty4khlcZLzpo+1tqYYVfZ1ZsVmaJk4aYiaJkUG/vz8g=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; DM2PR05MB702; 5:KyZyJDL+yn+I0tF9OPRPd963MhDvhLYshCyVzH13C/D7FaElyfsIM2IwPNQ+ROn9cL9vmJJWZOZElml6qlcz4INzLmrU+dhQhOE50JjysXuDQ+M8LlQz66eKMu6v0k1hnO+dz19/g93RsgnSj58UOw==; 24:QDWUDOcOGr7Yf/USZJA912cktUMRcGWmz0PIiHZIV7JED45UWlfSdvc1nnzG+pSe617dOtjOeXHt6Yg/EtU/5GUwVK3lJpLzV35KZm1D2sY= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Mar 2016 17:06:53.8487 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR05MB702 Archived-At: Cc: Hares Susan Subject: [Idr] IETF-95 agenda topics X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2016 17:07:45 -0000 Folks, IDR will meet at IETF-95 on Tuesday, April 5 from 10 a.m. to 12:30 p.m.. = Please forward any IDR agenda items you might have to Sue and me. The = deadline is March 18 (a week from Friday) by 10:00 U.S. Eastern Time. = Priority will be given to those who get their requests in by the = deadline, though if agenda space permits it we will consider requests = gotten in before March 28 at 10:00 U.S. Eastern Time. If you have previously presented on your topic at an IDR meeting, please = explain in your request what you hope to achieve with your presentation = this time. If you have requested to present the same work at multiple = WGs, please note this so that we can coordinate as needed. If you plan to make a presentation, please keep in mind the IDR = tradition, "no Internet Draft - no time slot". You should also plan to = send your slides to Sue and me no later than 24 hours prior to the = meeting, though again, earlier is better. If we don't have your slides = by the deadline, you may lose your slot. Please number your slides for = the benefit of remote attendees, and if you plan to use any fancy builds = or transitions you must arrange this with us in advance -- otherwise you = should assume your slides may be converted to PDF and presented from the = PDF. Finally, if you request an agenda slot, please do so by replying to this = message, making sure to include both Sue and me in the To: or Cc: and = don't change the subject line. Please include the name of the person who = will be presenting and give an estimate for how much time you think = you'll need (including Q/A). There is a checklist for presenting at IDR: = https://trac.tools.ietf.org/wg/idr/trac/wiki/Checklist%20for%20presenting%= 20at%20an%20IDR%20meeting. Potential presenters, please take a look. = Suggestions for improvements to the chairs, please, or just edit the = wiki directly. Thanks, --John & Sue From nobody Wed Mar 9 09:55:55 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FE3612D61D for ; Wed, 9 Mar 2016 09:55:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rCZCsMdUJwyt for ; Wed, 9 Mar 2016 09:55:49 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88C8512D86A for ; Wed, 9 Mar 2016 09:55:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3104; q=dns/txt; s=iport; t=1457546145; x=1458755745; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=sb/UtC1Stdyj1fA2XH07OIZ72zSO10N5Ot8m5dvq8uM=; b=frnzG3wvzAz/W/ZgDjzYPbSov6cAH8TxozktOi3PpDvEFpU/w33eqXlq 9oyzhK4Tlu6q+HpdsN3z7DkUQibgjV9nBj1QFgvfJzRDdyS6tO+atThMF lpYPDCP12lzvJLC9Rah+aeh6dnJgJkN5muMeKG9PQ6Bu8Dni1LLXbtsIE w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CvBADSYuBW/xbLJq1cAYQNbQa8SRcMh?= =?us-ascii?q?WwCHIF6AQEBAQEBZSeEQQEBAQMBAQEBIBE6CwULAgEIDgoCAhUCDwICAiULFRA?= =?us-ascii?q?CBA4FiBwIDrAGjyQBAQEBAQEBAQEBAQEBAQEBAQEBAQERBHyHDwiCR4Q4XwGCI?= =?us-ascii?q?iuBDwEEjTGKBgGFZIgNgWSERYhTjl0BYoNkagGIVH4BAQE?= X-IronPort-AV: E=Sophos;i="5.24,311,1454976000"; d="scan'208";a="633708129" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Mar 2016 17:55:34 +0000 Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u29HtV14019614 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 9 Mar 2016 17:55:32 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 9 Mar 2016 12:55:30 -0500 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.009; Wed, 9 Mar 2016 12:55:30 -0500 From: "Acee Lindem (acee)" To: John Scudder Thread-Topic: [Idr] IETF-95 agenda topics Thread-Index: AQHReiazXohk3oTSmUmVUV+1upO6qp9RuUCA Date: Wed, 9 Mar 2016 17:55:30 +0000 Message-ID: <2097397F-4B33-4748-8139-F65686B36642@cisco.com> References: In-Reply-To: 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.116.152.201] Content-Type: text/plain; charset="utf-8" Content-ID: <30D296896C076047BF97303FC324A2D0@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "idr@ietf. org" , Susan Hares Subject: Re: [Idr] IETF-95 agenda topics X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2016 17:55:52 -0000 SGkgSm9obiwgDQpUaGlzIHJlbWluZHMgbWUgLSBpcyB0aGVyZSBhIFdlYkV4IHJlY29yZGluZyBm cm9tIE1vbmRheeKAmXMgSW50ZXJpbT8gSSBoYWQgYSBjb25mbGljdCBhbmQgY291bGRu4oCZdCBk aWFsIGluLiANClRoYW5rcywNCkFjZWUgDQoNCj4gT24gTWFyIDksIDIwMTYsIGF0IDEyOjA2IFBN LCBKb2huIEcuU2N1ZGRlciA8amdzQGp1bmlwZXIubmV0PiB3cm90ZToNCj4gDQo+IEZvbGtzLA0K PiANCj4gSURSIHdpbGwgbWVldCBhdCBJRVRGLTk1IG9uIFR1ZXNkYXksIEFwcmlsIDUgZnJvbSAx MCBhLm0uIHRvIDEyOjMwIHAubS4uICBQbGVhc2UgZm9yd2FyZCBhbnkgSURSIGFnZW5kYSBpdGVt cyB5b3UgbWlnaHQgaGF2ZSB0byBTdWUgYW5kIG1lLiAgVGhlIGRlYWRsaW5lIGlzIE1hcmNoIDE4 IChhIHdlZWsgZnJvbSBGcmlkYXkpIGJ5IDEwOjAwIFUuUy4gRWFzdGVybiBUaW1lLiBQcmlvcml0 eSB3aWxsIGJlIGdpdmVuIHRvIHRob3NlIHdobyBnZXQgdGhlaXIgcmVxdWVzdHMgaW4gYnkgdGhl IGRlYWRsaW5lLCB0aG91Z2ggaWYgYWdlbmRhIHNwYWNlIHBlcm1pdHMgaXQgd2Ugd2lsbCBjb25z aWRlciByZXF1ZXN0cyBnb3R0ZW4gaW4gYmVmb3JlIE1hcmNoIDI4IGF0IDEwOjAwIFUuUy4gRWFz dGVybiBUaW1lLg0KPiANCj4gSWYgeW91IGhhdmUgcHJldmlvdXNseSBwcmVzZW50ZWQgb24geW91 ciB0b3BpYyBhdCBhbiBJRFIgbWVldGluZywgcGxlYXNlIGV4cGxhaW4gaW4geW91ciByZXF1ZXN0 IHdoYXQgeW91IGhvcGUgdG8gYWNoaWV2ZSB3aXRoIHlvdXIgcHJlc2VudGF0aW9uIHRoaXMgdGlt ZS4gSWYgeW91IGhhdmUgcmVxdWVzdGVkIHRvIHByZXNlbnQgdGhlIHNhbWUgd29yayBhdCBtdWx0 aXBsZSBXR3MsIHBsZWFzZSBub3RlIHRoaXMgc28gdGhhdCB3ZSBjYW4gY29vcmRpbmF0ZSBhcyBu ZWVkZWQuDQo+IA0KPiBJZiB5b3UgcGxhbiB0byBtYWtlIGEgcHJlc2VudGF0aW9uLCBwbGVhc2Ug a2VlcCBpbiBtaW5kIHRoZSBJRFIgdHJhZGl0aW9uLCAibm8gSW50ZXJuZXQgRHJhZnQgLSBubyB0 aW1lIHNsb3QiLiAgWW91IHNob3VsZCBhbHNvIHBsYW4gdG8gc2VuZCB5b3VyIHNsaWRlcyB0byBT dWUgYW5kIG1lIG5vIGxhdGVyIHRoYW4gMjQgaG91cnMgcHJpb3IgdG8gdGhlIG1lZXRpbmcsIHRo b3VnaCBhZ2FpbiwgZWFybGllciBpcyBiZXR0ZXIuIElmIHdlIGRvbid0IGhhdmUgeW91ciBzbGlk ZXMgYnkgdGhlIGRlYWRsaW5lLCB5b3UgbWF5IGxvc2UgeW91ciBzbG90LiBQbGVhc2UgbnVtYmVy IHlvdXIgc2xpZGVzIGZvciB0aGUgYmVuZWZpdCBvZiByZW1vdGUgYXR0ZW5kZWVzLCBhbmQgaWYg eW91IHBsYW4gdG8gdXNlIGFueSBmYW5jeSBidWlsZHMgb3IgdHJhbnNpdGlvbnMgeW91IG11c3Qg YXJyYW5nZSB0aGlzIHdpdGggdXMgaW4gYWR2YW5jZSAtLSBvdGhlcndpc2UgeW91IHNob3VsZCBh c3N1bWUgeW91ciBzbGlkZXMgbWF5IGJlIGNvbnZlcnRlZCB0byBQREYgYW5kIHByZXNlbnRlZCBm cm9tIHRoZSBQREYuDQo+IA0KPiBGaW5hbGx5LCBpZiB5b3UgcmVxdWVzdCBhbiBhZ2VuZGEgc2xv dCwgcGxlYXNlIGRvIHNvIGJ5IHJlcGx5aW5nIHRvIHRoaXMgbWVzc2FnZSwgbWFraW5nIHN1cmUg dG8gaW5jbHVkZSBib3RoIFN1ZSBhbmQgbWUgaW4gdGhlIFRvOiBvciBDYzogYW5kIGRvbid0IGNo YW5nZSB0aGUgc3ViamVjdCBsaW5lLiBQbGVhc2UgaW5jbHVkZSB0aGUgbmFtZSBvZiB0aGUgcGVy c29uIHdobyB3aWxsIGJlIHByZXNlbnRpbmcgYW5kIGdpdmUgYW4gZXN0aW1hdGUgZm9yIGhvdyBt dWNoIHRpbWUgeW91IHRoaW5rIHlvdSdsbCBuZWVkIChpbmNsdWRpbmcgUS9BKS4NCj4gDQo+IFRo ZXJlIGlzIGEgY2hlY2tsaXN0IGZvciBwcmVzZW50aW5nIGF0IElEUjogaHR0cHM6Ly90cmFjLnRv b2xzLmlldGYub3JnL3dnL2lkci90cmFjL3dpa2kvQ2hlY2tsaXN0JTIwZm9yJTIwcHJlc2VudGlu ZyUyMGF0JTIwYW4lMjBJRFIlMjBtZWV0aW5nLiBQb3RlbnRpYWwgcHJlc2VudGVycywgcGxlYXNl IHRha2UgYSBsb29rLiBTdWdnZXN0aW9ucyBmb3IgaW1wcm92ZW1lbnRzIHRvIHRoZSBjaGFpcnMs IHBsZWFzZSwgb3IganVzdCBlZGl0IHRoZSB3aWtpIGRpcmVjdGx5Lg0KPiANCj4gVGhhbmtzLA0K PiANCj4gLS1Kb2huICYgU3VlDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiBJZHIgbWFpbGluZyBsaXN0DQo+IElkckBpZXRmLm9yZw0KPiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkcg0KDQo= From nobody Wed Mar 9 10:48:53 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F3B512D56D for ; Wed, 9 Mar 2016 10:48:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.738 X-Spam-Level: * X-Spam-Status: No, score=1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, RDNS_NONE=0.793] autolearn=no autolearn_force=no Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FZwsesEt-qkb for ; Wed, 9 Mar 2016 10:48:50 -0800 (PST) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 5463C12D568 for ; Wed, 9 Mar 2016 10:48:49 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.30; From: "Susan Hares" To: "'Acee Lindem \(acee\)'" , "'John Scudder'" Date: Wed, 9 Mar 2016 13:48:09 -0500 Message-ID: <000c01d17a34$39ec4a90$adc4dfb0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdF6NDlip9d3Hfz2QgKX66s0hAm9eQ== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: "'idr@ietf. org'" Subject: Re: [Idr] IETF-95 agenda topics - interim's recording. X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2016 18:48:52 -0000 To download the link it is at:=20 https://ietf.webex.com/ietf/lsr.php?RCID=3D9612b9c2fc951695b0106c046b571f= f3 To stream it is at:=20 https://ietf.webex.com/ietf/ldr.php?RCID=3Ddc9d871391e63104db22dc43d69143= 4f Sue Hares=20 -----Original Message----- From: Acee Lindem (acee) [mailto:acee@cisco.com]=20 Sent: Wednesday, March 09, 2016 12:56 PM To: John Scudder Cc: idr@ietf. org; Susan Hares Subject: Re: [Idr] IETF-95 agenda topics Hi John,=20 This reminds me - is there a WebEx recording from Monday=E2=80=99s = Interim? I had a conflict and couldn=E2=80=99t dial in.=20 Thanks, Acee=20 > On Mar 9, 2016, at 12:06 PM, John G.Scudder wrote: >=20 > Folks, >=20 > IDR will meet at IETF-95 on Tuesday, April 5 from 10 a.m. to 12:30 = p.m.. Please forward any IDR agenda items you might have to Sue and me. = The deadline is March 18 (a week from Friday) by 10:00 U.S. Eastern = Time. Priority will be given to those who get their requests in by the = deadline, though if agenda space permits it we will consider requests = gotten in before March 28 at 10:00 U.S. Eastern Time. >=20 > If you have previously presented on your topic at an IDR meeting, = please explain in your request what you hope to achieve with your = presentation this time. If you have requested to present the same work = at multiple WGs, please note this so that we can coordinate as needed. >=20 > If you plan to make a presentation, please keep in mind the IDR = tradition, "no Internet Draft - no time slot". You should also plan to = send your slides to Sue and me no later than 24 hours prior to the = meeting, though again, earlier is better. If we don't have your slides = by the deadline, you may lose your slot. Please number your slides for = the benefit of remote attendees, and if you plan to use any fancy builds = or transitions you must arrange this with us in advance -- otherwise you = should assume your slides may be converted to PDF and presented from the = PDF. >=20 > Finally, if you request an agenda slot, please do so by replying to = this message, making sure to include both Sue and me in the To: or Cc: = and don't change the subject line. Please include the name of the person = who will be presenting and give an estimate for how much time you think = you'll need (including Q/A). >=20 > There is a checklist for presenting at IDR: = https://trac.tools.ietf.org/wg/idr/trac/wiki/Checklist%20for%20presenting= %20at%20an%20IDR%20meeting. Potential presenters, please take a look. = Suggestions for improvements to the chairs, please, or just edit the = wiki directly. >=20 > Thanks, >=20 > --John & Sue >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Thu Mar 10 00:46:07 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43FE812D5AF; Thu, 10 Mar 2016 00:46:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 v6qrkXiJcXkN; Thu, 10 Mar 2016 00:46:01 -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 2263412D5BA; Thu, 10 Mar 2016 00:46:00 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CKE50321; Thu, 10 Mar 2016 08:45:59 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 10 Mar 2016 08:45:58 +0000 Received: from NKGEML515-MBS.china.huawei.com ([169.254.5.102]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Thu, 10 Mar 2016 16:45:51 +0800 From: "Dongjie (Jimmy)" To: "pce@ietf.org" Thread-Topic: I-D Action: draft-dong-pce-discovery-proto-bgp-04.txt Thread-Index: AQHReoOjrZBVfyQeG0eqB0oT5R97aJ9SU9qQ Date: Thu, 10 Mar 2016 08:45:50 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C92774E35E33@NKGEML515-MBS.china.huawei.com> References: <20160310015239.25364.91254.idtracker@ietfa.amsl.com> In-Reply-To: <20160310015239.25364.91254.idtracker@ietfa.amsl.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.151.75] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.56E13447.00EA, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.5.102, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: edd14a939ef8788cc969ffe1ff681893 Archived-At: Cc: "idr@ietf.org" Subject: [Idr] FW: I-D Action: draft-dong-pce-discovery-proto-bgp-04.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2016 08:46:04 -0000 RGVhciBhbGwsIA0KDQpXZSBoYXZlIHVwZGF0ZWQgdGhlIEJHUCBiYXNlZCBQQ0UgZGlzY292ZXJ5 IGRyYWZ0IHRvIHJlc29sdmUgdGhlIGNvbW1lbnRzIHJlY2VpdmVkIGR1cmluZyBJRVRGOTQgbWVl dGluZy4gDQoNClRoZSBtYWluIGNoYW5nZXMgYXJlOg0KDQoxLiBTcGVjaWZ5IHRoZSBsaW1pdGF0 aW9uIGluIElHUCBiYXNlZCBkaXNjb3ZlcnksIGFuZCBpbXByb3ZlIHRoZSB1c2UgY2FzZXMgb2Yg QkdQIGJhc2VkIGRpc2NvdmVyeSBtZWNoYW5pc20uDQoyLiBFeHBsaWNpdGx5IHNwZWNpZnkgdGhh dCB0aGUgaW50ZXJhY3Rpb24gYmV0d2VlbiBCR1AgYW5kIElHUCBiYXNlZCBkaXNjb3ZlcnkgaXMg b3V0IG9mIHNjb3BlLiANCjMuIE1vZGlmeSB0aGUgcmVjb21tZW5kZWQgcHJvdG9jb2wtSUQgdmFs dWUgZm9yIFBDRSBkaXNjb3ZlcnkgaW5mb3JtYXRpb24uDQo0LiBJbXByb3ZlIHRoZSBvcGVyYXRp b25hbCBjb25zaWRlcmF0aW9ucy4NCjUuIEVkaXRvcmlhbCBjaGFuZ2VzLg0KDQpBbnkgZnVydGhl ciByZXZpZXcgY29tbWVudHMgYXJlIHdlbGNvbWUgYW5kIGF1dGhvcnMgYmVsaWV2ZSB0aGlzIHJl dmlzaW9uIGlzIHJlYWR5IGZvciB3ZyBhZG9wdGlvbi4gDQoNCk1hbnkgdGhhbmtzLA0KSmllIChv biBiZWhhbGYgb2YgY28tYXV0aG9ycykNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZy b206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRm Lm9yZ10gDQpTZW50OiBUaHVyc2RheSwgTWFyY2ggMTAsIDIwMTYgOTo1MyBBTQ0KVG86IGktZC1h bm5vdW5jZUBpZXRmLm9yZw0KU3ViamVjdDogSS1EIEFjdGlvbjogZHJhZnQtZG9uZy1wY2UtZGlz Y292ZXJ5LXByb3RvLWJncC0wNC50eHQNCg0KDQpBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFp bGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQoNCg0K ICAgICAgICBUaXRsZSAgICAgICAgICAgOiBCR1AgRXh0ZW5zaW9ucyBmb3IgUGF0aCBDb21wdXRh dGlvbiBFbGVtZW50IChQQ0UpIERpc2NvdmVyeQ0KICAgICAgICBBdXRob3JzICAgICAgICAgOiBK aWUgRG9uZw0KICAgICAgICAgICAgICAgICAgICAgICAgICBNYWNoKEd1b3lpKSBDaGVuDQogICAg ICAgICAgICAgICAgICAgICAgICAgIERocnV2IERob2R5DQogICAgICAgICAgICAgICAgICAgICAg ICAgIEplZmYgVGFudHN1cmENCglGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1kb25nLXBjZS1kaXNj b3ZlcnktcHJvdG8tYmdwLTA0LnR4dA0KCVBhZ2VzICAgICAgICAgICA6IDkNCglEYXRlICAgICAg ICAgICAgOiAyMDE2LTAzLTA5DQoNCkFic3RyYWN0Og0KICAgSW4gbmV0d29ya3Mgd2hlcmUgUGF0 aCBDb21wdXRhdGlvbiBFbGVtZW50IChQQ0UpIGlzIHVzZWQgZm9yDQogICBjZW50cmFsaXplZCBw YXRoIGNvbXB1dGF0aW9uLCBpdCBpcyBkZXNpcmFibGUgZm9yIHRoZSBQYXRoDQogICBDb21wdXRh dGlvbiBDbGllbnRzIChQQ0NzKSB0byBhdXRvbWF0aWNhbGx5IGRpc2NvdmVyIGEgc2V0IG9mIFBD RXMNCiAgIGFuZCBzZWxlY3QgdGhlIHN1aXRhYmxlIG9uZXMgdG8gZXN0YWJsaXNoIHRoZSBQQ0VQ IHNlc3Npb24uICBSRkMgNTA4OA0KICAgYW5kIFJGQyA1MDg5IGRlZmluZSB0aGUgUENFIGRpc2Nv dmVyeSBtZWNoYW5pc21zIGJhc2VkIG9uIEludGVyaW9yDQogICBHYXRld2F5IFByb3RvY29scyAo SUdQKS4gIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIHNldmVyYWwgc2NlbmFyaW9zDQogICBpbiB3 aGljaCB0aGUgSUdQIGJhc2VkIFBDRSBkaXNjb3ZlcnkgbWVjaGFuaXNtcyBjYW5ub3QgYmUgdXNl ZA0KICAgZGlyZWN0bHkuICBJbiBzdWNoIHNjZW5hcmlvcywgQkdQIG1pZ2h0IGJlIHN1aXRhYmxl LCB0aHVzIHRoaXMNCiAgIGRvY3VtZW50IHNwZWNpZmllcyB0aGUgQkdQIGV4dGVuc2lvbnMgZm9y IFBDRSBkaXNjb3ZlcnkuICBUaGUgQkdQDQogICBiYXNlZCBQQ0UgZGlzY292ZXJ5IG1lY2hhbmlz bSBpcyBjb21wbGVtZW50YXJ5IHRvIHRoZSBleGlzdGluZyBJR1ANCiAgIGJhc2VkIG1lY2hhbmlz bXMuDQoNCg0KDQpUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFm dCBpczoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWRvbmctcGNlLWRp c2NvdmVyeS1wcm90by1iZ3AvDQoNClRoZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZlcnNpb24gYXZh aWxhYmxlIGF0Og0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWRvbmctcGNlLWRp c2NvdmVyeS1wcm90by1iZ3AtMDQNCg0KQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24g aXMgYXZhaWxhYmxlIGF0Og0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0 LWRvbmctcGNlLWRpc2NvdmVyeS1wcm90by1iZ3AtMDQNCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0 IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9u IHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9v bHMuaWV0Zi5vcmcuDQoNCkludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5v bnltb3VzIEZUUCBhdDoNCmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQoNCg0K From nobody Sat Mar 12 10:05:09 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12D7312D62B for ; Sat, 12 Mar 2016 10:05:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=fb.com 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 IZo-4R0_b0IZ for ; Sat, 12 Mar 2016 10:05:06 -0800 (PST) Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (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 1A03C12D5C9 for ; Sat, 12 Mar 2016 10:05:06 -0800 (PST) Received: from pps.filterd (m0044012.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u2CI1vCo030777; Sat, 12 Mar 2016 10:04:49 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=facebook; bh=W7IZWPBudTIzjiOapgpNGOmGcHV9c4iniyzoE3CCZ2w=; b=FvqSjslfouWLMfp0O6aHmjpcalIvrbM2yCg0bsUDZhm0Z+O7TkeW3tT7YLyVqncpdqIT axSdAAxQMRZofp4+7T2Y3+5EU2fdbu1QeQnl1vOfZ+SB7ZhGMa3jaIuxlVKjZDOaM7Et WADlWBFAlxVkRKFTL8Ui/NRanCQUgydtdx8= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0a-00082601.pphosted.com with ESMTP id 21mhp714a2-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Sat, 12 Mar 2016 10:04:49 -0800 Received: from PRN-MBX01-2.TheFacebook.com ([169.254.3.204]) by PRN-CHUB05.TheFacebook.com ([fe80::9886:b2c2:db18:5ba7%12]) with mapi id 14.03.0248.002; Sat, 12 Mar 2016 10:04:48 -0800 From: Petr Lapukhov To: "John G.Scudder" , Hares Susan Thread-Topic: [Idr] IETF-95 agenda topics Thread-Index: AQHReiaxLt/ArboZTkudnACwisVP1J9WHOIS Date: Sat, 12 Mar 2016 18:04:47 +0000 Message-ID: <3F437107848A5140A6A19222EFFB3481200E20B5@PRN-MBX01-2.TheFacebook.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.52.123] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-03-12_08:, , signatures=0 Archived-At: Cc: "keyupate@cisco.com" , "idr@ietf. org" , Tom Herbert Subject: Re: [Idr] IETF-95 agenda topics X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Mar 2016 18:05:08 -0000 John/Sue,=0A= =0A= I would like to present =0A= =0A= http://www.ietf.org/id/draft-lapukhov-bgp-opaque-signaling-01.txt=0A= =0A= and=0A= =0A= http://www.ietf.org/id/draft-lapukhov-bgp-ila-afi-00.txt =0A= =0A= at the upcoming IDR session. Each likely needs about 15 minutes. =0A= =0A= Thank you!=0A= =0A= Petr=0A= ________________________________________=0A= From: Idr [idr-bounces@ietf.org] on behalf of John G.Scudder [jgs@juniper.n= et]=0A= Sent: Wednesday, March 09, 2016 9:06 AM=0A= To: idr@ietf. org=0A= Cc: Hares Susan=0A= Subject: [Idr] IETF-95 agenda topics=0A= =0A= Folks,=0A= =0A= IDR will meet at IETF-95 on Tuesday, April 5 from 10 a.m. to 12:30 p.m.. P= lease forward any IDR agenda items you might have to Sue and me. The deadl= ine is March 18 (a week from Friday) by 10:00 U.S. Eastern Time. Priority w= ill be given to those who get their requests in by the deadline, though if = agenda space permits it we will consider requests gotten in before March 28= at 10:00 U.S. Eastern Time.=0A= =0A= If you have previously presented on your topic at an IDR meeting, please ex= plain in your request what you hope to achieve with your presentation this = time. If you have requested to present the same work at multiple WGs, pleas= e note this so that we can coordinate as needed.=0A= =0A= If you plan to make a presentation, please keep in mind the IDR tradition, = "no Internet Draft - no time slot". You should also plan to send your slid= es to Sue and me no later than 24 hours prior to the meeting, though again,= earlier is better. If we don't have your slides by the deadline, you may l= ose your slot. Please number your slides for the benefit of remote attendee= s, and if you plan to use any fancy builds or transitions you must arrange = this with us in advance -- otherwise you should assume your slides may be c= onverted to PDF and presented from the PDF.=0A= =0A= Finally, if you request an agenda slot, please do so by replying to this me= ssage, making sure to include both Sue and me in the To: or Cc: and don't c= hange the subject line. Please include the name of the person who will be p= resenting and give an estimate for how much time you think you'll need (inc= luding Q/A).=0A= =0A= There is a checklist for presenting at IDR: https://urldefense.proofpoint.c= om/v2/url?u=3Dhttps-3A__trac.tools.ietf.org_wg_idr_trac_wiki_Checklist-2520= for-2520presenting-2520at-2520an-2520IDR-2520meeting&d=3DCwICAg&c=3D5VD0RTt= NlTh3ycd41b3MUw&r=3DLU_vJaM_EQu1Ssm35j2xlA&m=3Dgc36hlWb0H54l2EJJIXC0ShXyT5P= 1pjMpChwP3EYU3I&s=3DGqUAiA2Ki7rbb_m0HtuAb0wMW16IT3uo9rvt7ubpTvw&e=3D . Pote= ntial presenters, please take a look. Suggestions for improvements to the c= hairs, please, or just edit the wiki directly.=0A= =0A= Thanks,=0A= =0A= --John & Sue=0A= =0A= _______________________________________________=0A= Idr mailing list=0A= Idr@ietf.org=0A= https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_idr&d=3DCwICAg&c=3D5VD0RTtNlTh3ycd41b3MUw&r=3DLU_vJaM_EQu1Ssm35j2= xlA&m=3Dgc36hlWb0H54l2EJJIXC0ShXyT5P1pjMpChwP3EYU3I&s=3DcCQwRLhjrR0gbjIMHk0= 4R3cR_-B67q7_m69FuCPXbmU&e=3D=0A= From nobody Sat Mar 12 12:27:43 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9713812D83E for ; Sat, 12 Mar 2016 12:27:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 X4je-kt_q_-p for ; Sat, 12 Mar 2016 12:27:40 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E207212D52F for ; Sat, 12 Mar 2016 12:27:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4264; q=dns/txt; s=iport; t=1457814459; x=1459024059; h=from:to:date:message-id:mime-version:subject; bh=R7xjJ0mmH35MmdcMDK/PzYjehpQli9QbKvdkk6N7leY=; b=MOLLr4plelCpSdwOTRaCqL555EBkdBdvWWXxmrGwcA60rCT0Kgu6T4LT UiO6nDWWY/GMJIvXQlrxvHFoWQnLrVILxAfoUbP8JCA6fvvHf+y3R+HHN zRtkgQRzuB+yLO5vt7K3cE63xo/TP5pmt59pK+ABISVBuJF3XfAL1/nYK Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D3AQC2euRW/5FdJa1dgnJMUm0GjV+sS?= =?us-ascii?q?QENgW0hhxU4FAEBAQEBAQFkHAuESC1eAYEAJgEEGwGIGw6eGZ5GAQEBAQYBAQE?= =?us-ascii?q?BARuGGI02BZMDhEgBjXiBbIdvhTGOfAEeAQFCg2RqAYh1fgEBAQ?= X-IronPort-AV: E=Sophos;i="unknown"; e="0x0't"; a="246836386" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Mar 2016 20:26:33 +0000 Received: from XCH-RCD-014.cisco.com (xch-rcd-014.cisco.com [173.37.102.24]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u2CKQXrA022117 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Sat, 12 Mar 2016 20:26:33 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-RCD-014.cisco.com (173.37.102.24) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sat, 12 Mar 2016 14:26:32 -0600 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1104.009; Sat, 12 Mar 2016 14:26:32 -0600 From: "Jakob Heitz (jheitz)" To: "idr@ietf.org" Thread-Topic: draft-lapukhov-bgp-opaque-signaling Thread-Index: AdF8nS8FQTTx9jiyQtWM4z1Bl2Fmug== Date: Sat, 12 Mar 2016 20:26:32 +0000 Message-ID: <2d12cade49ac4ec19a7f2c80aee3b72d@XCH-ALN-014.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.26.203] Content-Type: multipart/alternative; boundary="_000_2d12cade49ac4ec19a7f2c80aee3b72dXCHALN014ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [Idr] [WARNING : A/V UNSCANNABLE] draft-lapukhov-bgp-opaque-signaling X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Mar 2016 20:27:41 -0000 --_000_2d12cade49ac4ec19a7f2c80aee3b72dXCHALN014ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I read http://www.ietf.org/id/draft-lapukhov-bgp-opaque-signaling-01.txt Is this intended for any and multiple applications to use? If so, how do independent applications guarantee no duplication in NLRI? If not, what is the target application? Thanks Jakob. --_000_2d12cade49ac4ec19a7f2c80aee3b72dXCHALN014ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I read

http://www.ietf.org/id/draft-lapukhov-bgp-opaq= ue-signaling-01.txt

 

Is this intended for any and multipl= e applications to use?

If so, how do independent applicatio= ns guarantee no duplication in NLRI?

If not, what is the target applicati= on?

 

Thanks

Jakob.

--_000_2d12cade49ac4ec19a7f2c80aee3b72dXCHALN014ciscocom_-- From nobody Sat Mar 12 13:05:38 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C308912D855 for ; Sat, 12 Mar 2016 13:05:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com 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 AOUnSlRuIfcU for ; Sat, 12 Mar 2016 13:05:36 -0800 (PST) Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (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 1291812D6FF for ; Sat, 12 Mar 2016 13:05:36 -0800 (PST) Received: from pps.filterd (m0044010.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u2CL2UDG026674; Sat, 12 Mar 2016 13:05:34 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fb.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=qyRDzRWKkSlJVaQxFpW15CVo/sPa9RhTyZ7HClaxqS8=; b=KZrfbJXc9VaUQj61nIH+PldixSSOV6LaIusUQ5EIK26h2kF7gCxBwCoBWXF8xtjEuPpJ nZohwM9dhXLMktT9QTexQU8SEbQyXpRUxkLpKZofzTp7iiSvCXjY+EzDA1/SfERZJART Xr47aLJGWd9YPeYw0n4iExJauiFWLRNZFUc= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0a-00082601.pphosted.com with ESMTP id 21mg8nhpsa-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Sat, 12 Mar 2016 13:05:34 -0800 Received: from PRN-CHUB18.TheFacebook.com (192.168.16.72) by PRN-CHUB07.TheFacebook.com (192.168.16.17) with Microsoft SMTP Server (TLS) id 14.3.248.2; Sat, 12 Mar 2016 13:05:34 -0800 Received: from PRN-MBX01-2.TheFacebook.com ([169.254.3.204]) by PRN-CHUB18.TheFacebook.com ([fe80::6964:6730:1d3b:b80c%13]) with mapi id 14.03.0248.002; Sat, 12 Mar 2016 13:05:33 -0800 From: Petr Lapukhov To: "Jakob Heitz (jheitz)" , "idr@ietf.org" Thread-Topic: draft-lapukhov-bgp-opaque-signaling Thread-Index: AdF8nS8FQTTx9jiyQtWM4z1Bl2FmugABRu++ Date: Sat, 12 Mar 2016 21:05:33 +0000 Message-ID: <3F437107848A5140A6A19222EFFB3481200E2389@PRN-MBX01-2.TheFacebook.com> References: <2d12cade49ac4ec19a7f2c80aee3b72d@XCH-ALN-014.cisco.com> In-Reply-To: <2d12cade49ac4ec19a7f2c80aee3b72d@XCH-ALN-014.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.52.123] Content-Type: multipart/alternative; boundary="_000_3F437107848A5140A6A19222EFFB3481200E2389PRNMBX012TheFac_" MIME-Version: 1.0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-03-12_10:, , signatures=0 Archived-At: Subject: Re: [Idr] draft-lapukhov-bgp-opaque-signaling X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Mar 2016 21:05:38 -0000 --_000_3F437107848A5140A6A19222EFFB3481200E2389PRNMBX012TheFac_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jakob, There is an ongoing discussion around avoiding NLRI (key) collisions. For n= ow, the plan is to externally generate unique key prefix per application, e= .g. application name, or UUID or some other globally unique string. Ensurin= g the uniqueness of those prefixes is outside the scope of the proposal, th= ough - it's more of a deployment consideration. Regards, Petr ________________________________ From: Idr [idr-bounces@ietf.org] on behalf of Jakob Heitz (jheitz) [jheitz@= cisco.com] Sent: Saturday, March 12, 2016 12:26 PM To: idr@ietf.org Subject: [Idr] [WARNING : A/V UNSCANNABLE] draft-lapukhov-bgp-opaque-signal= ing I read http://www.ietf.org/id/draft-lapukhov-bgp-opaque-signaling-01.txt Is this intended for any and multiple applications to use? If so, how do independent applications guarantee no duplication in NLRI? If not, what is the target application? Thanks Jakob. --_000_3F437107848A5140A6A19222EFFB3481200E2389PRNMBX012TheFac_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Jakob,

There is an ongoing discussion around avoiding NLRI (key) collisions. = For now, the plan is to externally generate unique key prefix per applicati= on, e.g. application name, or UUID or some other globally unique string.&nb= sp;Ensuring the uniqueness of those prefixes is outside the scope of the proposal, tho= ugh - it's more of a deployment consideration.

Regards,

Petr

From: Idr [idr-bounces@ietf.org] on behal= f of Jakob Heitz (jheitz) [jheitz@cisco.com]
Sent: Saturday, March 12, 2016 12:26 PM
To: idr@ietf.org
Subject: [Idr] [WARNING : A/V UNSCANNABLE] draft-lapukhov-bgp-opaque= -signaling

I read

http:/= /www.ietf.org/id/draft-lapukhov-bgp-opaque-signaling-01.txt

 

Is this intended for any and multi= ple applications to use?

If so, how do independent applicat= ions guarantee no duplication in NLRI?

If not, what is the target applica= tion?

 

Thanks

Jakob.

--_000_3F437107848A5140A6A19222EFFB3481200E2389PRNMBX012TheFac_-- From nobody Sat Mar 12 13:10:21 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7859212D855 for ; Sat, 12 Mar 2016 13:10:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 CrQyoSdA264b for ; Sat, 12 Mar 2016 13:10:10 -0800 (PST) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::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 6E3B712D866 for ; Sat, 12 Mar 2016 13:10:05 -0800 (PST) Received: by mail-lb0-x230.google.com with SMTP id x1so195932743lbj.3 for ; Sat, 12 Mar 2016 13:10:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc; bh=0EqoEwK8eGauvle2WDBNijxPPhznoF0XtpRlBuIeEZw=; b=kgr3NaGrLVbZAObthXSin56ZUanAMp8tfvYM7KNcaLp7U3FIB30/eHTEHtwn5mRSHU vK/x271w6noSDrVTGGtvrd+M3KWVQGptuDRGFGxhL5G0OJc4UebhkVX4ii/cDKTJiVOZ BdoEOyzug/Tm2TRLyhVs/C1rGyMpyAFOnirVMkAmoVmxrvI9+iEHEFS7/jI1rPwKWo7c lbcisuaif8YpjAfHi5jlQwXw0k3oizHoeqwrqkuZxYO3zIQ1XxlRwG5IDHGsvoBiwZrc 1pvzFFR4ZqmbUoFMiIoLP2Uh1xk4xx3rWmTfn7RLf9fjhiGKszVaPR/ZpBZSgC0aFkDQ KpHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:date:message-id:subject:from :to:cc; bh=0EqoEwK8eGauvle2WDBNijxPPhznoF0XtpRlBuIeEZw=; b=bxm5VdrW1FlZUJUN/wluYXaDshD//ShafkGkovW8juD9NNbrGhg6eQNfJv+U/TxRfo mUJ4P+86BNnjIEtvVKLA174ZOhZ5rjl4bpP7POGT25K87GkUBPvt1iNQH/Ed40YqgzNk +TGsucqq+lhNa0TmD/vEPq7RdNRV8/SbZ8NywLb19pex9jgoHNw+W6Mbd+SPTbgR1C8a 1g8WJUbOjAjZHlT2OovBu9NuU8p0cToqPXGs7hUCX9vf69gefBTd0O2QeGuyIWd8bRL2 7oqWvdeWHSvsT3GBxqGXeVkouSHgIsWPO4SAghg8QFBAxro9To4rovOz6V6i9P9V6moy +lKw== X-Gm-Message-State: AD7BkJIvtdZH5Pe/1TWDuRN4nTw33eG2lM+m+yodPN9D5uH9NyGMT51q+DBIfJrVmic3s3l3Vg4BuRtKkhZGVg== MIME-Version: 1.0 X-Received: by 10.25.208.143 with SMTP id h137mr4119200lfg.110.1457817003499; Sat, 12 Mar 2016 13:10:03 -0800 (PST) Sender: rraszuk@gmail.com Received: by 10.25.136.133 with HTTP; Sat, 12 Mar 2016 13:10:03 -0800 (PST) Date: Sat, 12 Mar 2016 16:10:03 -0500 X-Google-Sender-Auth: 9TB5o6ijt5QVHAtKbqd_069w24I Message-ID: From: Robert Raszuk To: Petr Lapukhov , exa@juniper.net Content-Type: multipart/alternative; boundary=001a11411876a42c42052de078b7 Archived-At: Cc: idr wg Subject: [Idr] Use of BGP for Opaque Signaling X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Mar 2016 21:10:19 -0000 --001a11411876a42c42052de078b7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =E2=80=8BPetr, Eben, I have few questions and comments to your proposal. - The draft =E2=80=8Battempts to reuse BGP mechanism for p2mp distribution = of opaque information. That alone is not a bad thing :) However when you make reference to BGP-LS it needs to be observed that BGP-LS is not position to directly impact routing (ie content of RIB and FIBs) unlike one of the use cases described in your draft Intro paragraph. That means that unlike BGP-LS it must co-exist with routing BGP on the same BGP speakers. Here I would like to bring back my proposal to define new port for Transport Instance BGP https://tools.ietf.org/html/draft-raszuk-ti-bgp-01 which at the time of discussion was supposed to be shortly addressed by dynamic port allocations of multisessions which to the best of my knowledge never happened. So first comment is that if we go with reusing BGP-4 for this type of signalling let's enforce it's early separation from "classic" BGP. - Second comment is related to the scope of use. If the scope is private - let's perhaps enforce it more explicitly such that by the spec it is illegal AFI/SAFI pair in the public Internet. For example by stating that it is illegal to have non private AS in the AS_PATH of such UPDATE msg. - Third the draft states that there is no new security implications .. well if the scope is non private I am afraid that is no the case. As you have seen (and still seeing) securing BGP UPDATE MSG is MP_REACH content dependent. If content is free form I am afraid it will be rather hard to secure it well :) - Last as opaque value container you are defining an transitive attribute ? Is the intention to use this attribute in existing AFI/SAFIs as well ? Otherwise if not why do you need this to be transitive if capability negotiation already may implicitly define it's support by new AFI/SAFI. Cheers, R. PS. > There is an ongoing discussion around avoiding NLRI (key) collisions. Where is such discussion taking place ? Shouldn't IDR be perhaps in the loop a bit :) --001a11411876a42c42052de078b7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=E2=80=8BPetr, Eben,

I have few questions and comments to you= r proposal.=C2=A0

- Th= e draft =E2=80=8Battempts to reuse BGP mechanism for p2mp distribution of o= paque information. That alone is not a bad thing :) However when you make r= eference to BGP-LS it needs to be observed that BGP-LS is not position to d= irectly impact routing (ie content of RIB and FIBs) unlike one of the use c= ases described in your draft Intro paragraph. That means that unlike BGP-LS= it must co-exist with routing BGP on the same BGP speakers.=C2=A0

Here I would like to bring bac= k my proposal to define new port for Transport Instance BGP=C2=A0https://tools.ietf.org= /html/draft-raszuk-ti-bgp-01 which at the time of discussion was suppos= ed to be shortly addressed by dynamic port allocations of multisessions whi= ch to the best of my knowledge never happened.=C2=A0

So first comment is that if we go with reusi= ng BGP-4 for this type of signalling let's enforce it's early separ= ation from "classic" BGP.=C2=A0

- Second comment is related to the scope of use. If the= scope is private - let's perhaps enforce it more explicitly such that = by the spec it is illegal AFI/SAFI pair in the public Internet. For example= by stating that it is illegal to have non private AS in the AS_PATH of suc= h UPDATE msg.=C2=A0

- = Third the draft states that there is no new security implications .. well i= f the scope is non private I am afraid that is no the case. As you have see= n (and still seeing) securing BGP UPDATE MSG is MP_REACH content dependent.= If content is free form I am afraid it will be rather hard to secure it we= ll :)=C2=A0

- Last as = opaque value container you are defining an transitive attribute ? Is the in= tention to use this attribute in existing AFI/SAFIs as well ? Otherwise if = not why do you need this to be transitive if capability negotiation already= may implicitly define it's support by new AFI/SAFI.

Cheers,
R.
PS.=C2=A0

> There is an ongoing discussion around avoiding NLRI (key) = collisions.

Where is such discussion taking place ? Shouldn't IDR be perhaps in t= he loop a bit :)=C2=A0



= =C2=A0
--001a11411876a42c42052de078b7-- From nobody Sat Mar 12 13:11:37 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4720112D859 for ; Sat, 12 Mar 2016 13:11:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 AUU1ooHM0teQ for ; Sat, 12 Mar 2016 13:11:34 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAF7B12D855 for ; Sat, 12 Mar 2016 13:11:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11785; q=dns/txt; s=iport; t=1457817094; x=1459026694; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=dYMUzHqdQzCnj06v4boIFAG7eI3Qeq09qeBNvsz/h7M=; b=UrsRdOoKawp7A0bWC7I0g8vpQSro5KikWH/lF1JC+E1bll4dFxUWbe/D i6Cprv9nfEkYCIZPs5W3o9OTAR8iDM8/dwOHlQGpK9UyVTsWfuQldoGaC zszASUPfGM9+tPkn24nqKpU+73dIooc4rrhCBZaVJFSHxMh/SD01S5Wid c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D2AQAjheRW/5tdJa1dgnJMUm0GuisBD?= =?us-ascii?q?YFtIIVtAoEnOBQBAQEBAQEBZCeEQQEBAQQtXAIBCBEEAQEoBzIUCQgBAQQBEgg?= =?us-ascii?q?BEogJDrxrAQEBAQEBAQEBAQEBAQEBAQEBAQEBFYYYhEKEZwmEBAWIO4R+hUqES?= =?us-ascii?q?AGFbYgLgWxLhySFMY58AR4BAUKBTDcZgUhqAQEBiHN+AQEB?= X-IronPort-AV: E=Sophos; i="5.24,326,1454976000"; d="scan'208,217"; a="82201118" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Mar 2016 21:11:33 +0000 Received: from XCH-ALN-011.cisco.com (xch-aln-011.cisco.com [173.36.7.21]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u2CLBXjr010996 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 12 Mar 2016 21:11:33 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-011.cisco.com (173.36.7.21) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sat, 12 Mar 2016 15:11:32 -0600 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1104.009; Sat, 12 Mar 2016 15:11:32 -0600 From: "Jakob Heitz (jheitz)" To: Petr Lapukhov , "idr@ietf.org" Thread-Topic: draft-lapukhov-bgp-opaque-signaling Thread-Index: AdF8nS8FQTTx9jiyQtWM4z1Bl2FmugABRu++AABFuBA= Date: Sat, 12 Mar 2016 21:11:32 +0000 Message-ID: <976fb2df5f974b298a04b547afb917b7@XCH-ALN-014.cisco.com> References: <2d12cade49ac4ec19a7f2c80aee3b72d@XCH-ALN-014.cisco.com> <3F437107848A5140A6A19222EFFB3481200E2389@PRN-MBX01-2.TheFacebook.com> In-Reply-To: <3F437107848A5140A6A19222EFFB3481200E2389@PRN-MBX01-2.TheFacebook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.26.203] Content-Type: multipart/alternative; boundary="_000_976fb2df5f974b298a04b547afb917b7XCHALN014ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] draft-lapukhov-bgp-opaque-signaling X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Mar 2016 21:11:36 -0000 --_000_976fb2df5f974b298a04b547afb917b7XCHALN014ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Without this problem solved, the proposal is not useful. Everybody using it must stick to the eventual solution to ensure interopera= bility. Therefore, it should be inside the scope. Actually, BGP already has a way to distinguish applicationd: AFI and SAFI. Jakob. From: Petr Lapukhov [mailto:petr@fb.com] Sent: Saturday, March 12, 2016 1:06 PM To: Jakob Heitz (jheitz) ; idr@ietf.org Subject: RE: draft-lapukhov-bgp-opaque-signaling Hi Jakob, There is an ongoing discussion around avoiding NLRI (key) collisions. For n= ow, the plan is to externally generate unique key prefix per application, e= .g. application name, or UUID or some other globally unique string. Ensurin= g the uniqueness of those prefixes is outside the scope of the proposal, th= ough - it's more of a deployment consideration. Regards, Petr ________________________________ From: Idr [idr-bounces@ietf.org] on behalf of Jakob Heitz (jheitz) [jheitz@= cisco.com] Sent: Saturday, March 12, 2016 12:26 PM To: idr@ietf.org Subject: [Idr] [WARNING : A/V UNSCANNABLE] draft-lapukhov-bgp-opaque-signal= ing I read http://www.ietf.org/id/draft-lapukhov-bgp-opaque-signaling-01.txt Is this intended for any and multiple applications to use? If so, how do independent applications guarantee no duplication in NLRI? If not, what is the target application? Thanks Jakob. --_000_976fb2df5f974b298a04b547afb917b7XCHALN014ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Without this problem solved, the pro= posal is not useful.

Everybody using it must stick to the= eventual solution to ensure interoperability.

Therefore, it should be inside the s= cope.

 

Actually, BGP already has a way to d= istinguish applicationd: AFI and SAFI.

 

Jakob.

&nb= sp;

From: Petr Lapukhov [mailto:petr@fb.com]
Sent: Saturday, March 12, 2016 1:06 PM
To: Jakob Heitz (jheitz) <jheitz@cisco.com>; idr@ietf.org
Subject: RE: draft-lapukhov-bgp-opaque-signaling

 

Hi Jakob,

 

There is an ongoing discussion around av= oiding NLRI (key) collisions. For now, the plan is to externally generate u= nique key prefix per application, e.g. application name, or UUID or some other globally unique string. Ensuring the uniq= ueness of those prefixes is outside the scope of the proposal, though - it'= s more of a deployment consideration.

 

Regards,

 

Petr

 

From:<= /span> Idr [idr-bounces@ietf.org] on behalf of Jakob Heitz (jheitz) [jheitz@cisco.com]
Sent: Saturday, March 12, 2016 12:26 PM
To: idr@ietf.org
Subject: [Idr] [WARNING : A/V UNSCANNABLE] draft-lapukhov-bgp-opaque= -signaling

I read

http://www.ietf.org/id/draft-lapukhov-bgp-opaque-sig= naling-01.txt

 

Is this intended for any and multipl= e applications to use?=

If so, how do independent applicatio= ns guarantee no duplication in NLRI?

If not, what is the target applicati= on?

 

Thanks

Jakob.

--_000_976fb2df5f974b298a04b547afb917b7XCHALN014ciscocom_-- From nobody Sat Mar 12 14:05:54 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEDF012D8AD for ; Sat, 12 Mar 2016 14:05:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 4hAWl8z8hmWv for ; Sat, 12 Mar 2016 14:05:51 -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 06B6212D775 for ; Sat, 12 Mar 2016 14:05:49 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CKK44920; Sat, 12 Mar 2016 22:05:47 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.218.25.36) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.235.1; Sat, 12 Mar 2016 22:05:46 +0000 Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.108]) by SJCEML703-CHM.china.huawei.com ([169.254.5.158]) with mapi id 14.03.0235.001; Sat, 12 Mar 2016 14:05:41 -0800 From: Huaimo Chen To: "idr@ietf.org" Thread-Topic: [Idr] WG Work item call - Opinions on work items (3/5/2016 to 3/17/2016) and adoption of draft-hares-idr-flowspec-combo-01.txt Thread-Index: AQHRfKtQC5ksvufhtEmdcVhL7dhHJg== Date: Sat, 12 Mar 2016 22:05:40 +0000 Message-ID: <5316A0AB3C851246A7CA5758973207D44E4EFB05@SJCEML702-CHM.china.huawei.com> References: <2d12cade49ac4ec19a7f2c80aee3b72d@XCH-ALN-014.cisco.com> <3F437107848A5140A6A19222EFFB3481200E2389@PRN-MBX01-2.TheFacebook.com> <976fb2df5f974b298a04b547afb917b7@XCH-ALN-014.cisco.com> In-Reply-To: <976fb2df5f974b298a04b547afb917b7@XCH-ALN-014.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.57] Content-Type: multipart/alternative; boundary="_000_5316A0AB3C851246A7CA5758973207D44E4EFB05SJCEML702CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0205.56E492BC.00B9, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.108, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 93342675c6a64e0df87795efaec54cf1 Archived-At: Cc: Susan Hares Subject: Re: [Idr] WG Work item call - Opinions on work items (3/5/2016 to 3/17/2016) and adoption of draft-hares-idr-flowspec-combo-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Mar 2016 22:05:54 -0000 --_000_5316A0AB3C851246A7CA5758973207D44E4EFB05SJCEML702CHMchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I read draft-hares-idr-flowspec-combo-01.txt and support it. The work descr= ibed in the draft is useful and well fit in BGP. Regarding to option 1 and = option 2, in the current stage, I support working on both. In the long run,= I think option 2 is better. Best Regards, Huaimo > On 05 Mar 2016, at 23:48, Susan Hares wrote: > > The interim on 3/7/2016 will have a discussion of revisions to the BGP Fl= ow specification (BGP-FS) to add more features. There are two suggested op= tions: > 1) A minimal features to existing BGP-FS (option 1) > Add a few new match filters to the BGP-FS NLRI and few new actions to the= BGP-FS actions (in Extended communities). Actions would need to be done i= n a defined order. Each new actions would need to define conflicts with exi= sting actions. > > Best use case: DoS attack prevention > > 2) Create a BGP-FS version 2 (option 2) > Create a new BGP-FS NLRI (v2) with a field that indicates the ordering of= the BGP NLRI. Add new BGP-FS actions with an order field in the BGP Wide = Communities. Filters are done in the order defined in the filter. Actions= are done in the order defined in the actions. Order numbers that tie are= handled in a defined order. > > Best use case: SDN/NFV filter management > > A write-up on the issues and proposed solutions is contained in: > draft-hares-idr-flowspec-combo-01.txt. The WG can select both option 1 and opt= ion 2. This is a WG work item call for input to the chairs on the scope of= the WG item. In you discussion of this topics, the chairs would appreciat= e if you would indicate if you would support IDR working on option 1, optio= n 2 or both option 1 and 2. This WG call items also includes a call for dr= aft-hares-idr-flowspec-combo-01.txt as a write-up of the work-item options.= The WG may wish to split this draft into multiple drafts. > > The following drafts are being consider for either option: > 1) draft-eddy-idr-flowspec-packet-rate > 2) draft-hao-idr-flowspec-nv03 > 3) draft-hao-idr-flowspec-label > 4) draft-liang-idr-bgp-flowspec-time > 5) draft-litowski-idr-flowspec-interfaceset > 6) draft-vandevelde-idr-flowspec-path-redirect > 7) draft-li-idr-flowspec-rpd-01.txt > 8) draft-wu-idr-flowspec-yang.cfg. > > If you wish to comment on any of these drafts, we will > > We will conclude the Call for WG opinions on 3/17/2016 so these authors c= an have a day to revise and submit their drafts before the draft deadline. > > Sue Hares and John Scudder > > PS: > draft-li-idr-flowspec-rpd discusses limits on the distribution of the pol= icy which has been recast in draft-hares-idr-flowspec-combo as a bgp-wide c= ommunity of Container type 1 with an atom of BGP Flow Specification orderin= g. However, this draft is included in the list to be able to update the me= chanism from this draft into that context. > > The yang model for BGP Flow specification is also included in this work i= tem as it will need to be modified based on the approaches. The yang model= is in draft-wu-idr-flowspec-yang-cfg. In your comments, please indicate i= f you feel these drafts or other drafts. > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr --_000_5316A0AB3C851246A7CA5758973207D44E4EFB05SJCEML702CHMchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I read draft-hares-idr-flowspec-combo-01.txt and support it. The work desc= ribed in the draft is useful and well fit in BGP. Regarding to option 1 and= option 2, in the current stage, I support working on both. In the long run, I think option 2 is better.

 

Best Regards,

Huaimo

 

> On 05 Mar 2016, at 23:48, Susan Hares <shares@ndzh.com> wrote:<= o:p>

>

> The interim on 3/7/2016 will have a discussion of revisions to the BG= P Flow specification (BGP-FS) to add more features.  There are two sug= gested options:

> 1)      A minimal features to existing BGP-F= S (option 1)

> Add a few new match filters to the BGP-FS NLRI and few new actions to= the BGP-FS actions (in Extended communities).  Actions would need to = be done in a defined order. Each new actions would need to define conflicts with existing actions.  

> 

> Best use case:  DoS attack prevention

> 

> 2)      Create a BGP-FS version 2 (option 2)

> Create a new BGP-FS NLRI (v2) with a field that indicates the orderin= g of the BGP NLRI.  Add new BGP-FS actions with an order field in the = BGP Wide Communities.  Filters are done in the order defined in the filter.  Actions are done in the order defined i= n the actions.   Order numbers that tie are handled in a defined = order.

> 

> Best use case: SDN/NFV filter management

> 

> A write-up on the issues and proposed solutions is contained in:

> draft-hares-idr-flowspec-combo-01.txt.  <https://datatracker.= ietf.org/doc/draft-hares-idr-flowspec-combo/>   The WG can sel= ect both option 1 and option 2.  This is a WG work item call for input to the chairs on the scope of the WG item.  In you discussi= on of this topics, the chairs would appreciate if you would indicate if you= would support IDR working on option 1, option 2 or both option 1 and 2.&nb= sp; This WG call items also includes a call for draft-hares-idr-flowspec-combo-01.txt as a write-up of the work-item o= ptions.  The WG may wish to split this draft into multiple drafts.

> 

> The following drafts are being consider for either option:

> 1)      draft-eddy-idr-flowspec-packet-rate<= o:p>

> 2)      draft-hao-idr-flowspec-nv03

> 3)      draft-hao-idr-flowspec-label

> 4)      draft-liang-idr-bgp-flowspec-time

> 5)      draft-litowski-idr-flowspec-interfac= eset

> 6)      draft-vandevelde-idr-flowspec-path-r= edirect

> 7)      draft-li-idr-flowspec-rpd-01.txt

> 8)      draft-wu-idr-flowspec-yang.cfg.

> 

> If you wish to comment on any of these drafts, we will

> 

> We will conclude the Call for WG opinions on 3/17/2016 so these autho= rs can have a day to revise and submit their drafts before the draft deadli= ne.

> 

> Sue Hares and John Scudder

> 

> PS:

> draft-li-idr-flowspec-rpd discusses limits on the distribution of the= policy which has been recast in draft-hares-idr-flowspec-combo as a bgp-wi= de community of Container type 1 with an atom of BGP Flow Specification ordering. However,  this draft is incl= uded in the list to be able to update the mechanism from this draft into th= at context. 

> 

> The yang model for BGP Flow specification is also included in this wo= rk item as it will need to be modified based on the approaches.  The y= ang model is in draft-wu-idr-flowspec-yang-cfg.  In your comments, please indicate if you feel these drafts or other drafts= . 

> 

> _______________________________________________

> Idr mailing list

> Idr@ietf.org <mailto:Idr@ietf.org>

> https://www.ietf.org/mailman/listinfo/idr

--_000_5316A0AB3C851246A7CA5758973207D44E4EFB05SJCEML702CHMchi_-- From nobody Sat Mar 12 15:42:49 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49C3312D679 for ; Sat, 12 Mar 2016 15:42:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 qoMSStY1F2m7 for ; Sat, 12 Mar 2016 15:42:47 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 018DB12D5D9 for ; Sat, 12 Mar 2016 15:42:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1600; q=dns/txt; s=iport; t=1457826166; x=1459035766; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=GtOLwICipQ143BSxaxAU3MqMrYJERXmyoL/ZLusOego=; b=ikbNQ9XmniCV7lSkeQQcyoSQQJ/3cDGx3gBzhSVByZikwaUddz4I+uPA YX32Q3FVeWIqk1EfWTj/DLFmAbTx/5oywYEIOvqDR8CiuvnTbN8VBOsYi upHQI+E/PdOQ+JmqZ8+FbnJL9FQPg/3eJe4jRXMz0A8RTDvDAttEN7zdu o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D+AQDNqORW/40NJK1dKAOCR0yBRboqA?= =?us-ascii?q?Q2BbYR9gRACgSE4FAEBAQEBAQFkJ4Q4CgEBBHkQAgEIAwFCMiUCBAENiCm8eQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEBARWGGIRCiHQBBI1xiVoBjX+PBY58AR4BAUKCC?= =?us-ascii?q?BSBSIlgfgEBAQ?= X-IronPort-AV: E=Sophos; i="5.24,327,1454976000"; d="scan'208,217"; a="80424531" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Mar 2016 23:42:45 +0000 Received: from XCH-ALN-010.cisco.com (xch-aln-010.cisco.com [173.36.7.20]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u2CNgjt0010444 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 12 Mar 2016 23:42:45 GMT Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-ALN-010.cisco.com (173.36.7.20) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sat, 12 Mar 2016 17:42:45 -0600 Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1104.009; Sat, 12 Mar 2016 17:42:44 -0600 From: "Bertrand Duvivier (bduvivie)" To: Robert Raszuk , Petr Lapukhov , "exa@juniper.net" Thread-Topic: [Idr] Use of BGP for Opaque Signaling Thread-Index: AQHRfKOpQtOB56wyTEatZCWHvAz3u59W7GeA Date: Sat, 12 Mar 2016 23:42:44 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.79.97.187] Content-Type: multipart/alternative; boundary="_000_D30A653045264bduvivieciscocom_" MIME-Version: 1.0 Archived-At: Cc: idr wg Subject: Re: [Idr] Use of BGP for Opaque Signaling X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Mar 2016 23:42:48 -0000 --_000_D30A653045264bduvivieciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Petr, Eben, What about L3VPN use-cases ? If we make this VRF aware, couldn't we have 2 VPN's sending same / similar= opaque updates... and therefor leaking from one VPN to another VPN. Should we also carry the Route Distinguisher or VPN-id to avoid collision, = and of course for non VPN cases, this could be zero. Best Regards Bertrand Duvivier --_000_D30A653045264bduvivieciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
Petr, Eben,

What about L3VPN use-cases ? 

If we make this VRF aware,  couldn’t we have 2 VPN's sendin= g same / similar opaque updates… and therefor leaking from one VPN to= another VPN.

Should we also carry the Route Distinguisher or VPN-id to avoid collis= ion, and of course for non VPN cases, this could be zero. 

Best Regards Bertrand Duvivier

--_000_D30A653045264bduvivieciscocom_-- From nobody Sat Mar 12 16:57:52 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 119FC12D8ED for ; Sat, 12 Mar 2016 16:57:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.731 X-Spam-Level: X-Spam-Status: No, score=-0.731 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com 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 4Nbo0AOBZXhf for ; Sat, 12 Mar 2016 16:57:48 -0800 (PST) Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (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 D9C5312D8F2 for ; Sat, 12 Mar 2016 16:57:48 -0800 (PST) Received: from pps.filterd (m0044008.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u2D0tZIF005902; Sat, 12 Mar 2016 16:57:48 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=z12qhP3gETugz4dVooYAyXZ6ae/zSp2UlTYf6v2c+pI=; b=DZkFSsr/fiyiivsWze5G+PJwP1e5+8ug4bwBviyHMc6ldoKJlQ68qTFiRI/yoOBHQ2iT C3FAOjO1C75f8c0j2McMyVKm2g8WhkcA4V8oau2AWYj3vmwV7rZ54xXa2nWMFLdKRgvf dz1yx3Tk4Nz78rbHPQ/iw5lLdO7SLoYol1c= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0a-00082601.pphosted.com with ESMTP id 21mwegr2vd-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Sat, 12 Mar 2016 16:57:48 -0800 Received: from PRN-MBX01-2.TheFacebook.com ([169.254.3.204]) by PRN-CHUB07.TheFacebook.com ([fe80::d38:43fc:554e:146a%12]) with mapi id 14.03.0248.002; Sat, 12 Mar 2016 16:57:47 -0800 From: Petr Lapukhov To: Robert Raszuk , "exa@juniper.net" Thread-Topic: Use of BGP for Opaque Signaling Thread-Index: AQHRfKONNK1upwIbukaCHqWz2SNu2p9WgK6P Date: Sun, 13 Mar 2016 00:57:47 +0000 Message-ID: <3F437107848A5140A6A19222EFFB3481200E2839@PRN-MBX01-2.TheFacebook.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.52.123] Content-Type: multipart/alternative; boundary="_000_3F437107848A5140A6A19222EFFB3481200E2839PRNMBX012TheFac_" MIME-Version: 1.0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-03-12_10:, , signatures=0 Archived-At: Cc: idr wg Subject: Re: [Idr] Use of BGP for Opaque Signaling X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2016 00:57:51 -0000 --_000_3F437107848A5140A6A19222EFFB3481200E2839PRNMBX012TheFac_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Um9iZXJ0LCB0aGFua3MgZm9yIHlvdXIgY29tbWVudHMhDQoNClJlOiBJbXBhY3Qgb24gcm91dGlu Zy4gSSBzaG91bGQgYmUgbW9yZSBleHBsaWNpdCBzdGF0aW5nIHRoYXQgdGhlIGlkZWEgaXMgZm9y IEJHUCB0byBub3QgaW50ZXJwcmV0IHRoZSBrZXktdmFsdWUgbWFwcGluZ3MgaW4gYW55IHdheS4g VGhlIGNvbnN1bWVyIChydW5uaW5nIG9uIHNhbWUgZGV2aWNlLCBwb3NzaWJseSkgbWF5IHN0aWxs IGluZmx1ZW5jZSByb3V0aW5nIGJhc2VkIG9uIGl0cyBpbnRlcnByZXRhdGlvbiBvZiBkYXRhLCBl aXRoZXIgYnkgYWNjZXNzaW5nIHRoZSBwbGF0Zm9ybSBTREsgb3IgYnkgcGVyZm9ybWluZyBCR1Ag cm91dGluZyBpbmplY3Rpb24gb3ZlciB0aGUgY29ycmVzcG9uZGluZyBBRkkvU0FGSS4NCg0KUmU6 IFRyYW5zcG9ydCBpbnN0YW5jZS4gSSB0aGluayBpdCdzIGEgZ3JlYXQgaWRlYSB0byBydW4gdGhp cyBvbiBzZXBhcmF0ZSBpbnN0YW5jZSwgYnV0IHJpZ2h0IG5vdyB3ZSB0eXBpY2FsbHkgcnVuIGp1 c3Qgb25lIHByb2Nlc3MsIGFuZCBpdCBhZGRzIHNvbWUgb3BlcmF0aW9uYWwgb3ZlcmhlYWQgdG8g bWFpbnRhaW4gdHdvIG9mIHRoZW0uIEFsc28sIG9mdGVuIHRoaXMgZXh0ZW5zaW9uIGNvdWxkIGJl IHVzZWQganVzdCB3aXRoIG91dC1vZi1iYW5kIHJlZmxlY3Rpb24uIFRoaXMgaXMgd2h5IEkgZmVl bCBpdCBpcyByYXRoZXIgYmV0dGVyIHRvIGtlZXAgdGhpcyBhcHBsaWNhYmxlIHRvIGFueSB0eXBl IG9mIEJHUCBpbnN0YW5jZS4NCg0KUmU6IFNjb3BlIG9mIGFwcGxpY2F0aW9uLiBUaGUgbWFpbiBn b2FsIHdhcyB0byB1c2UgdGhpcyBpbiBkYXRhLWNlbnRlciwgYnV0IEkgY2FuIHRoZW9yaXplIHRo aXMgY291bGQgYmUgdXNlZCBhbW9uZyBmZXcgb3BlcmF0b3JzIHRoYXQgYXJlIHdpbGxpbmcgdG8g ZGV2ZWxvcCBvbi1kZXZpY2UgYXBwbGljYXRpb25zIGFuZCBleGNoYW5nZSBkYXRhIHVzaW5nIHRo ZSBwcmUtZXN0YWJsaXNoZWQgY2hhbm5lbHMgKGUuZy4gdGhlIFdJU0VSIHVzZSBjYXNlKS4gSW4g dGhpcyBzaXR1YXRpb24sIGxpbWl0aW5nIHNjb3BlIHRvIGp1c3QgcHJpdmF0ZSBBU05zIGNvdWxk IGJlIHRyaWNreS4gRnVydGhlcm1vcmUsIG5vbi1wcml2YXRlIEFTTnMgY291bGQgYmUgdXNlZCBp biBkYXRhLWNlbnRlciBhcyB3ZWxsIChqdXN0IG5vdCBleHBvc2VkIG91dHNpZGUuLi4pLg0KDQpS ZTogVHJhbnNpdGl2ZSBhdHRyaWJ1dGUuIElkZWFsbHksIGl0IHdvdWxkIGJlIGdyZWF0IHRvIGNh cnJ5IHRoZSB2YWx1ZSBpbiBuZXh0LWhvcCBmaWVsZCBvZiBNUF9SRUFDSF9OTFJJLCBidXQgdGhl IGxlbmd0aCBpcyBsaW1pdGVkIHRvIDggYnl0ZXMsIGhlbmNlIHRoZSBuZXcgYXR0cmlidXRlLiBJ IGRvIG5vdCBoYXZlIHN0cm9uZyBhcmd1bWVudHMgdG8gbWFraW5nIHRoaXMgdHJhbnNpdGl2ZSwg aXQgc2hvdWxkIGJlIGZpbmUgdG8gZ28gd2l0aCBub24tdHJhbnNpdGl2ZSBhbmQgY29ycmVzcG9u ZGluZyBlcnJvciBoYW5kbGluZy4NCg0KUmU6IFNlY3VyaXR5LiBTaW5jZSB3ZSBkbyBub3QgZGly ZWN0bHkgaW5mbHVlbmNlIHBhdGggc2VsZWN0aW9uIHdpdGggbmV3IGRhdGEsIHRoZSB0aHJlYXRz IGNvdWxkIGJlIGxpbWl0ZWQgdG8gdGhvc2UgdGFyZ2V0aW5nIEJHUGluZnJhIGl0c2VsZiBlLmcu IGZsb29kaW5nIHdpdGggaW5mb3JtYXRpb24sIGRpc3J1cHRpbmcgc2Vzc2lvbiBldGMuIFRoZXJl IGNvdWxkIGJlIHF1ZXN0aW9ucyBhYm91dCBpbmZvcm1hdGlvbiBhdXRoZW50aWNpdHksIGJ1dCB0 aGlzIGNvdWxkIGJlIGxlZnQgdXAgdG8gdGhlIGFwcGxpY2F0aW9ucyB0byBkZWNpZGUgKGUuZy4g c2lnbmluZyB0aGUga2V5LXZhbHVlIGJpbmRpbmdzKS4NCg0KUmVnYXJkcywNCg0KUGV0cg0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogcnJhc3p1a0BnbWFpbC5jb20g W3JyYXN6dWtAZ21haWwuY29tXSBvbiBiZWhhbGYgb2YgUm9iZXJ0IFJhc3p1ayBbcm9iZXJ0QHJh c3p1ay5uZXRdDQpTZW50OiBTYXR1cmRheSwgTWFyY2ggMTIsIDIwMTYgMToxMCBQTQ0KVG86IFBl dHIgTGFwdWtob3Y7IGV4YUBqdW5pcGVyLm5ldA0KQ2M6IGlkciB3Zw0KU3ViamVjdDogVXNlIG9m IEJHUCBmb3IgT3BhcXVlIFNpZ25hbGluZw0KDQrigItQZXRyLCBFYmVuLA0KDQpJIGhhdmUgZmV3 IHF1ZXN0aW9ucyBhbmQgY29tbWVudHMgdG8geW91ciBwcm9wb3NhbC4NCg0KLSBUaGUgZHJhZnQg 4oCLYXR0ZW1wdHMgdG8gcmV1c2UgQkdQIG1lY2hhbmlzbSBmb3IgcDJtcCBkaXN0cmlidXRpb24g b2Ygb3BhcXVlIGluZm9ybWF0aW9uLiBUaGF0IGFsb25lIGlzIG5vdCBhIGJhZCB0aGluZyA6KSBI b3dldmVyIHdoZW4geW91IG1ha2UgcmVmZXJlbmNlIHRvIEJHUC1MUyBpdCBuZWVkcyB0byBiZSBv YnNlcnZlZCB0aGF0IEJHUC1MUyBpcyBub3QgcG9zaXRpb24gdG8gZGlyZWN0bHkgaW1wYWN0IHJv dXRpbmcgKGllIGNvbnRlbnQgb2YgUklCIGFuZCBGSUJzKSB1bmxpa2Ugb25lIG9mIHRoZSB1c2Ug Y2FzZXMgZGVzY3JpYmVkIGluIHlvdXIgZHJhZnQgSW50cm8gcGFyYWdyYXBoLiBUaGF0IG1lYW5z IHRoYXQgdW5saWtlIEJHUC1MUyBpdCBtdXN0IGNvLWV4aXN0IHdpdGggcm91dGluZyBCR1Agb24g dGhlIHNhbWUgQkdQIHNwZWFrZXJzLg0KDQpIZXJlIEkgd291bGQgbGlrZSB0byBicmluZyBiYWNr IG15IHByb3Bvc2FsIHRvIGRlZmluZSBuZXcgcG9ydCBmb3IgVHJhbnNwb3J0IEluc3RhbmNlIEJH UCBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcmFzenVrLXRpLWJncC0wMTxodHRw czovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3Rvb2xzLmll dGYub3JnX2h0bWxfZHJhZnQtMkRyYXN6dWstMkR0aS0yRGJncC0yRDAxJmQ9Q3dNRmFRJmM9NVZE MFJUdE5sVGgzeWNkNDFiM01VdyZyPUxVX3ZKYU1fRVF1MVNzbTM1ajJ4bEEmbT03NVEtbnZYMlJo aHhZbS1yMkJJeEZodElwS3pUOXBFZ0d4OVVXanE2ZlQ0JnM9a0s3MWVTcVdCSVRhbEcxWTFpTldh aUhhU0E3dnJNTW5MNGxraWVhcTJ1WSZlPT4gd2hpY2ggYXQgdGhlIHRpbWUgb2YgZGlzY3Vzc2lv biB3YXMgc3VwcG9zZWQgdG8gYmUgc2hvcnRseSBhZGRyZXNzZWQgYnkgZHluYW1pYyBwb3J0IGFs bG9jYXRpb25zIG9mIG11bHRpc2Vzc2lvbnMgd2hpY2ggdG8gdGhlIGJlc3Qgb2YgbXkga25vd2xl ZGdlIG5ldmVyIGhhcHBlbmVkLg0KDQpTbyBmaXJzdCBjb21tZW50IGlzIHRoYXQgaWYgd2UgZ28g d2l0aCByZXVzaW5nIEJHUC00IGZvciB0aGlzIHR5cGUgb2Ygc2lnbmFsbGluZyBsZXQncyBlbmZv cmNlIGl0J3MgZWFybHkgc2VwYXJhdGlvbiBmcm9tICJjbGFzc2ljIiBCR1AuDQoNCi0gU2Vjb25k IGNvbW1lbnQgaXMgcmVsYXRlZCB0byB0aGUgc2NvcGUgb2YgdXNlLiBJZiB0aGUgc2NvcGUgaXMg cHJpdmF0ZSAtIGxldCdzIHBlcmhhcHMgZW5mb3JjZSBpdCBtb3JlIGV4cGxpY2l0bHkgc3VjaCB0 aGF0IGJ5IHRoZSBzcGVjIGl0IGlzIGlsbGVnYWwgQUZJL1NBRkkgcGFpciBpbiB0aGUgcHVibGlj IEludGVybmV0LiBGb3IgZXhhbXBsZSBieSBzdGF0aW5nIHRoYXQgaXQgaXMgaWxsZWdhbCB0byBo YXZlIG5vbiBwcml2YXRlIEFTIGluIHRoZSBBU19QQVRIIG9mIHN1Y2ggVVBEQVRFIG1zZy4NCg0K LSBUaGlyZCB0aGUgZHJhZnQgc3RhdGVzIHRoYXQgdGhlcmUgaXMgbm8gbmV3IHNlY3VyaXR5IGlt cGxpY2F0aW9ucyAuLiB3ZWxsIGlmIHRoZSBzY29wZSBpcyBub24gcHJpdmF0ZSBJIGFtIGFmcmFp ZCB0aGF0IGlzIG5vIHRoZSBjYXNlLiBBcyB5b3UgaGF2ZSBzZWVuIChhbmQgc3RpbGwgc2VlaW5n KSBzZWN1cmluZyBCR1AgVVBEQVRFIE1TRyBpcyBNUF9SRUFDSCBjb250ZW50IGRlcGVuZGVudC4g SWYgY29udGVudCBpcyBmcmVlIGZvcm0gSSBhbSBhZnJhaWQgaXQgd2lsbCBiZSByYXRoZXIgaGFy ZCB0byBzZWN1cmUgaXQgd2VsbCA6KQ0KDQotIExhc3QgYXMgb3BhcXVlIHZhbHVlIGNvbnRhaW5l ciB5b3UgYXJlIGRlZmluaW5nIGFuIHRyYW5zaXRpdmUgYXR0cmlidXRlID8gSXMgdGhlIGludGVu dGlvbiB0byB1c2UgdGhpcyBhdHRyaWJ1dGUgaW4gZXhpc3RpbmcgQUZJL1NBRklzIGFzIHdlbGwg PyBPdGhlcndpc2UgaWYgbm90IHdoeSBkbyB5b3UgbmVlZCB0aGlzIHRvIGJlIHRyYW5zaXRpdmUg aWYgY2FwYWJpbGl0eSBuZWdvdGlhdGlvbiBhbHJlYWR5IG1heSBpbXBsaWNpdGx5IGRlZmluZSBp dCdzIHN1cHBvcnQgYnkgbmV3IEFGSS9TQUZJLg0KDQpDaGVlcnMsDQpSLg0KDQpQUy4NCg0KPiBU aGVyZSBpcyBhbiBvbmdvaW5nIGRpc2N1c3Npb24gYXJvdW5kIGF2b2lkaW5nIE5MUkkgKGtleSkg Y29sbGlzaW9ucy4NCg0KV2hlcmUgaXMgc3VjaCBkaXNjdXNzaW9uIHRha2luZyBwbGFjZSA/IFNo b3VsZG4ndCBJRFIgYmUgcGVyaGFwcyBpbiB0aGUgbG9vcCBhIGJpdCA6KQ0KDQoNCg0KDQo= --_000_3F437107848A5140A6A19222EFFB3481200E2839PRNMBX012TheFac_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgZGlyPSJsdHIiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUi IGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8c3R5bGUgdHlwZT0idGV4dC9j c3MiIGlkPSJvd2FQYXJhU3R5bGUiPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBmcHN0eWxlPSIx IiBvY3NpPSIwIj4NCjxkaXYgc3R5bGU9ImRpcmVjdGlvbjogbHRyO2ZvbnQtZmFtaWx5OiBUYWhv bWE7Y29sb3I6ICMwMDAwMDA7Zm9udC1zaXplOiAxMHB0OyI+Um9iZXJ0LCB0aGFua3MgZm9yIHlv dXIgY29tbWVudHMhDQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5SZTogSW1wYWN0IG9uIHJvdXRp bmcuIEkgc2hvdWxkIGJlIG1vcmUgZXhwbGljaXQgc3RhdGluZyB0aGF0IHRoZSBpZGVhIGlzIGZv ciBCR1AgdG8gbm90IGludGVycHJldCB0aGUga2V5LXZhbHVlIG1hcHBpbmdzIGluIGFueSB3YXku IFRoZSBjb25zdW1lciAocnVubmluZyBvbiBzYW1lIGRldmljZSwgcG9zc2libHkpIG1heSBzdGls bCBpbmZsdWVuY2Ugcm91dGluZyBiYXNlZCBvbiBpdHMgaW50ZXJwcmV0YXRpb24gb2YgZGF0YSwg ZWl0aGVyDQogYnkgYWNjZXNzaW5nIHRoZSBwbGF0Zm9ybSBTREsgb3IgYnkgcGVyZm9ybWluZyBC R1Agcm91dGluZyBpbmplY3Rpb24gb3ZlciB0aGUgY29ycmVzcG9uZGluZyBBRkkvU0FGSS48L2Rp dj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlJlOiBUcmFuc3BvcnQgaW5zdGFuY2UuIEkgdGhp bmsgaXQncyBhIGdyZWF0IGlkZWEgdG8gcnVuIHRoaXMgb24gc2VwYXJhdGUgaW5zdGFuY2UsIGJ1 dCByaWdodCBub3cgd2UgdHlwaWNhbGx5IHJ1biBqdXN0IG9uZSBwcm9jZXNzLCBhbmQgaXQgYWRk cyBzb21lIG9wZXJhdGlvbmFsIG92ZXJoZWFkIHRvIG1haW50YWluIHR3byBvZiB0aGVtLiBBbHNv LCBvZnRlbiB0aGlzIGV4dGVuc2lvbiBjb3VsZCBiZSB1c2VkIGp1c3Qgd2l0aCBvdXQtb2YtYmFu ZA0KIHJlZmxlY3Rpb24uIFRoaXMgaXMgd2h5IEkgZmVlbCBpdCBpcyByYXRoZXIgYmV0dGVyIHRv IGtlZXAgdGhpcyBhcHBsaWNhYmxlIHRvIGFueSB0eXBlIG9mIEJHUCBpbnN0YW5jZS48L2Rpdj4N CjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlJlOiBTY29wZSBvZiBhcHBsaWNhdGlvbi4gVGhlIG1h aW4gZ29hbCB3YXMgdG8gdXNlIHRoaXMgaW4gZGF0YS1jZW50ZXIsIGJ1dCBJIGNhbiB0aGVvcml6 ZSB0aGlzIGNvdWxkIGJlIHVzZWQgYW1vbmcgZmV3IG9wZXJhdG9ycyB0aGF0IGFyZSB3aWxsaW5n IHRvIGRldmVsb3Agb24tZGV2aWNlIGFwcGxpY2F0aW9ucyBhbmQgZXhjaGFuZ2UgZGF0YSB1c2lu ZyB0aGUgcHJlLWVzdGFibGlzaGVkIGNoYW5uZWxzIChlLmcuIHRoZSBXSVNFUiB1c2UNCiBjYXNl KS4gSW4gdGhpcyBzaXR1YXRpb24sIGxpbWl0aW5nIHNjb3BlIHRvIGp1c3QgcHJpdmF0ZSBBU05z IGNvdWxkIGJlIHRyaWNreS4gRnVydGhlcm1vcmUsIG5vbi1wcml2YXRlIEFTTnMgY291bGQgYmUg dXNlZCBpbiBkYXRhLWNlbnRlciBhcyB3ZWxsIChqdXN0IG5vdCBleHBvc2VkIG91dHNpZGUuLi4p LjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+UmU6IFRyYW5zaXRpdmUgYXR0cmlidXRl LiBJZGVhbGx5LCBpdCB3b3VsZCBiZSBncmVhdCB0byBjYXJyeSB0aGUgdmFsdWUgaW4gbmV4dC1o b3AgZmllbGQgb2YgTVBfUkVBQ0hfTkxSSSwgYnV0IHRoZSBsZW5ndGggaXMgbGltaXRlZCB0byA4 IGJ5dGVzLCBoZW5jZSB0aGUgbmV3IGF0dHJpYnV0ZS4gSSBkbyBub3QgaGF2ZSBzdHJvbmcgYXJn dW1lbnRzIHRvIG1ha2luZyB0aGlzIHRyYW5zaXRpdmUsIGl0IHNob3VsZCBiZSBmaW5lIHRvIGdv DQogd2l0aCBub24tdHJhbnNpdGl2ZSBhbmQgY29ycmVzcG9uZGluZyBlcnJvciBoYW5kbGluZy4m bmJzcDs8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlJlOiBTZWN1cml0eS4gU2luY2Ug d2UgZG8gbm90IGRpcmVjdGx5IGluZmx1ZW5jZSBwYXRoIHNlbGVjdGlvbiB3aXRoIG5ldyBkYXRh LCB0aGUgdGhyZWF0cyBjb3VsZCBiZSBsaW1pdGVkIHRvIHRob3NlIHRhcmdldGluZyBCR1BpbmZy YSBpdHNlbGYgZS5nLiBmbG9vZGluZyB3aXRoIGluZm9ybWF0aW9uLCBkaXNydXB0aW5nIHNlc3Np b24gZXRjLiBUaGVyZSBjb3VsZCBiZSBxdWVzdGlvbnMgYWJvdXQgaW5mb3JtYXRpb24gYXV0aGVu dGljaXR5LA0KIGJ1dCB0aGlzIGNvdWxkIGJlIGxlZnQgdXAgdG8gdGhlIGFwcGxpY2F0aW9ucyB0 byBkZWNpZGUgKGUuZy4gc2lnbmluZyB0aGUga2V5LXZhbHVlIGJpbmRpbmdzKS48L2Rpdj4NCjxk aXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlJlZ2FyZHMsPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0K PGRpdj5QZXRyPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImZv bnQtZmFtaWx5OiBUaW1lcyBOZXcgUm9tYW47IGNvbG9yOiAjMDAwMDAwOyBmb250LXNpemU6IDE2 cHgiPg0KPGhyIHRhYmluZGV4PSItMSI+DQo8ZGl2IGlkPSJkaXZScEYyOTAwOTMiIHN0eWxlPSJk aXJlY3Rpb246IGx0cjsiPjxmb250IGZhY2U9IlRhaG9tYSIgc2l6ZT0iMiIgY29sb3I9IiMwMDAw MDAiPjxiPkZyb206PC9iPiBycmFzenVrQGdtYWlsLmNvbSBbcnJhc3p1a0BnbWFpbC5jb21dIG9u IGJlaGFsZiBvZiBSb2JlcnQgUmFzenVrIFtyb2JlcnRAcmFzenVrLm5ldF08YnI+DQo8Yj5TZW50 OjwvYj4gU2F0dXJkYXksIE1hcmNoIDEyLCAyMDE2IDE6MTAgUE08YnI+DQo8Yj5Ubzo8L2I+IFBl dHIgTGFwdWtob3Y7IGV4YUBqdW5pcGVyLm5ldDxicj4NCjxiPkNjOjwvYj4gaWRyIHdnPGJyPg0K PGI+U3ViamVjdDo8L2I+IFVzZSBvZiBCR1AgZm9yIE9wYXF1ZSBTaWduYWxpbmc8YnI+DQo8L2Zv bnQ+PGJyPg0KPC9kaXY+DQo8ZGl2PjwvZGl2Pg0KPGRpdj4NCjxkaXYgZGlyPSJsdHIiPg0KPGRp diBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGlj YSxzYW5zLXNlcmlmOyBmb250LXNpemU6c21hbGwiPg0K4oCLUGV0ciwgRWJlbiw8L2Rpdj4NCjxk aXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRp Y2Esc2Fucy1zZXJpZjsgZm9udC1zaXplOnNtYWxsIj4NCjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5z LXNlcmlmOyBmb250LXNpemU6c21hbGwiPg0KSSBoYXZlIGZldyBxdWVzdGlvbnMgYW5kIGNvbW1l bnRzIHRvIHlvdXIgcHJvcG9zYWwuJm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZh dWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7IGZvbnQt c2l6ZTpzbWFsbCI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0 eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjsgZm9udC1zaXplOnNt YWxsIj4NCi0gVGhlIGRyYWZ0IOKAi2F0dGVtcHRzIHRvIHJldXNlIEJHUCBtZWNoYW5pc20gZm9y IHAybXAgZGlzdHJpYnV0aW9uIG9mIG9wYXF1ZSBpbmZvcm1hdGlvbi4gVGhhdCBhbG9uZSBpcyBu b3QgYSBiYWQgdGhpbmcgOikgSG93ZXZlciB3aGVuIHlvdSBtYWtlIHJlZmVyZW5jZSB0byBCR1At TFMgaXQgbmVlZHMgdG8gYmUgb2JzZXJ2ZWQgdGhhdCBCR1AtTFMgaXMgbm90IHBvc2l0aW9uIHRv IGRpcmVjdGx5IGltcGFjdCByb3V0aW5nIChpZSBjb250ZW50IG9mDQogUklCIGFuZCBGSUJzKSB1 bmxpa2Ugb25lIG9mIHRoZSB1c2UgY2FzZXMgZGVzY3JpYmVkIGluIHlvdXIgZHJhZnQgSW50cm8g cGFyYWdyYXBoLiBUaGF0IG1lYW5zIHRoYXQgdW5saWtlIEJHUC1MUyBpdCBtdXN0IGNvLWV4aXN0 IHdpdGggcm91dGluZyBCR1Agb24gdGhlIHNhbWUgQkdQIHNwZWFrZXJzLiZuYnNwOzwvZGl2Pg0K PGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZl dGljYSxzYW5zLXNlcmlmOyBmb250LXNpemU6c21hbGwiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNh bnMtc2VyaWY7IGZvbnQtc2l6ZTpzbWFsbCI+DQpIZXJlIEkgd291bGQgbGlrZSB0byBicmluZyBi YWNrIG15IHByb3Bvc2FsIHRvIGRlZmluZSBuZXcgcG9ydCBmb3IgVHJhbnNwb3J0IEluc3RhbmNl IEJHUCZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91 cmw/dT1odHRwcy0zQV9fdG9vbHMuaWV0Zi5vcmdfaHRtbF9kcmFmdC0yRHJhc3p1ay0yRHRpLTJE YmdwLTJEMDEmYW1wO2Q9Q3dNRmFRJmFtcDtjPTVWRDBSVHRObFRoM3ljZDQxYjNNVXcmYW1wO3I9 TFVfdkphTV9FUXUxU3NtMzVqMnhsQSZhbXA7bT03NVEtbnZYMlJoaHhZbS1yMkJJeEZodElwS3pU OXBFZ0d4OVVXanE2ZlQ0JmFtcDtzPWtLNzFlU3FXQklUYWxHMVkxaU5XYWlIYVNBN3ZyTU1uTDRs a2llYXEydVkmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LXJhc3p1ay10aS1iZ3AtMDE8L2E+DQogd2hpY2ggYXQgdGhlIHRpbWUgb2YgZGlz Y3Vzc2lvbiB3YXMgc3VwcG9zZWQgdG8gYmUgc2hvcnRseSBhZGRyZXNzZWQgYnkgZHluYW1pYyBw b3J0IGFsbG9jYXRpb25zIG9mIG11bHRpc2Vzc2lvbnMgd2hpY2ggdG8gdGhlIGJlc3Qgb2YgbXkg a25vd2xlZGdlIG5ldmVyIGhhcHBlbmVkLiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxf ZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmOyBm b250LXNpemU6c21hbGwiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0 IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7IGZvbnQtc2l6 ZTpzbWFsbCI+DQpTbyBmaXJzdCBjb21tZW50IGlzIHRoYXQgaWYgd2UgZ28gd2l0aCByZXVzaW5n IEJHUC00IGZvciB0aGlzIHR5cGUgb2Ygc2lnbmFsbGluZyBsZXQncyBlbmZvcmNlIGl0J3MgZWFy bHkgc2VwYXJhdGlvbiBmcm9tICZxdW90O2NsYXNzaWMmcXVvdDsgQkdQLiZuYnNwOzwvZGl2Pg0K PGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZl dGljYSxzYW5zLXNlcmlmOyBmb250LXNpemU6c21hbGwiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNh bnMtc2VyaWY7IGZvbnQtc2l6ZTpzbWFsbCI+DQotIFNlY29uZCBjb21tZW50IGlzIHJlbGF0ZWQg dG8gdGhlIHNjb3BlIG9mIHVzZS4gSWYgdGhlIHNjb3BlIGlzIHByaXZhdGUgLSBsZXQncyBwZXJo YXBzIGVuZm9yY2UgaXQgbW9yZSBleHBsaWNpdGx5IHN1Y2ggdGhhdCBieSB0aGUgc3BlYyBpdCBp cyBpbGxlZ2FsIEFGSS9TQUZJIHBhaXIgaW4gdGhlIHB1YmxpYyBJbnRlcm5ldC4gRm9yIGV4YW1w bGUgYnkgc3RhdGluZyB0aGF0IGl0IGlzIGlsbGVnYWwgdG8gaGF2ZSBub24gcHJpdmF0ZSBBUyBp bg0KIHRoZSBBU19QQVRIIG9mIHN1Y2ggVVBEQVRFIG1zZy4mbmJzcDs8L2Rpdj4NCjxkaXYgY2xh c3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fu cy1zZXJpZjsgZm9udC1zaXplOnNtYWxsIj4NCjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21h aWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlm OyBmb250LXNpemU6c21hbGwiPg0KLSBUaGlyZCB0aGUgZHJhZnQgc3RhdGVzIHRoYXQgdGhlcmUg aXMgbm8gbmV3IHNlY3VyaXR5IGltcGxpY2F0aW9ucyAuLiB3ZWxsIGlmIHRoZSBzY29wZSBpcyBu b24gcHJpdmF0ZSBJIGFtIGFmcmFpZCB0aGF0IGlzIG5vIHRoZSBjYXNlLiBBcyB5b3UgaGF2ZSBz ZWVuIChhbmQgc3RpbGwgc2VlaW5nKSBzZWN1cmluZyBCR1AgVVBEQVRFIE1TRyBpcyBNUF9SRUFD SCBjb250ZW50IGRlcGVuZGVudC4gSWYgY29udGVudCBpcyBmcmVlIGZvcm0gSSBhbQ0KIGFmcmFp ZCBpdCB3aWxsIGJlIHJhdGhlciBoYXJkIHRvIHNlY3VyZSBpdCB3ZWxsIDopJm5ic3A7PC9kaXY+ DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVs dmV0aWNhLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTpzbWFsbCI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYg Y2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Es c2Fucy1zZXJpZjsgZm9udC1zaXplOnNtYWxsIj4NCi0gTGFzdCBhcyBvcGFxdWUgdmFsdWUgY29u dGFpbmVyIHlvdSBhcmUgZGVmaW5pbmcgYW4gdHJhbnNpdGl2ZSBhdHRyaWJ1dGUgPyBJcyB0aGUg aW50ZW50aW9uIHRvIHVzZSB0aGlzIGF0dHJpYnV0ZSBpbiBleGlzdGluZyBBRkkvU0FGSXMgYXMg d2VsbCA/IE90aGVyd2lzZSBpZiBub3Qgd2h5IGRvIHlvdSBuZWVkIHRoaXMgdG8gYmUgdHJhbnNp dGl2ZSBpZiBjYXBhYmlsaXR5IG5lZ290aWF0aW9uIGFscmVhZHkgbWF5IGltcGxpY2l0bHkgZGVm aW5lDQogaXQncyBzdXBwb3J0IGJ5IG5ldyBBRkkvU0FGSS48L2Rpdj4NCjxkaXYgY2xhc3M9Imdt YWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJp ZjsgZm9udC1zaXplOnNtYWxsIj4NCjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVm YXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmOyBmb250 LXNpemU6c21hbGwiPg0KQ2hlZXJzLDxicj4NClIuPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9k ZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7IGZv bnQtc2l6ZTpzbWFsbCI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQi IHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjsgZm9udC1zaXpl OnNtYWxsIj4NClBTLiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5 bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmOyBmb250LXNpemU6c21h bGwiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9u dC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTpzbWFsbCI+DQo8 c3BhbiBzdHlsZT0iY29sb3I6cmdiKDAsMCwwKTsgZm9udC1mYW1pbHk6VGFob21hOyBmb250LXNp emU6MTMuMzMzM3B4Ij4mZ3Q7IFRoZXJlIGlzIGFuIG9uZ29pbmcgZGlzY3Vzc2lvbiBhcm91bmQg YXZvaWRpbmcgTkxSSSAoa2V5KSBjb2xsaXNpb25zLjwvc3Bhbj48YnI+DQo8L2Rpdj4NCjxkaXYg Y2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Es c2Fucy1zZXJpZjsgZm9udC1zaXplOnNtYWxsIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjpyZ2IoMCww LDApOyBmb250LWZhbWlseTpUYWhvbWE7IGZvbnQtc2l6ZToxMy4zMzMzcHgiPjxicj4NCjwvc3Bh bj48L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTph cmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjsgZm9udC1zaXplOnNtYWxsIj4NCjxzcGFuIHN0eWxl PSJjb2xvcjpyZ2IoMCwwLDApOyBmb250LWZhbWlseTpUYWhvbWE7IGZvbnQtc2l6ZToxMy4zMzMz cHgiPldoZXJlIGlzIHN1Y2ggZGlzY3Vzc2lvbiB0YWtpbmcgcGxhY2UgPyBTaG91bGRuJ3QgSURS IGJlIHBlcmhhcHMgaW4gdGhlIGxvb3AgYSBiaXQgOikmbmJzcDs8L3NwYW4+PC9kaXY+DQo8ZGl2 IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNh LHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTpzbWFsbCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6cmdiKDAs MCwwKTsgZm9udC1mYW1pbHk6VGFob21hOyBmb250LXNpemU6MTMuMzMzM3B4Ij48YnI+DQo8L3Nw YW4+PC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6 YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTpzbWFsbCI+DQo8c3BhbiBzdHls ZT0iY29sb3I6cmdiKDAsMCwwKTsgZm9udC1mYW1pbHk6VGFob21hOyBmb250LXNpemU6MTMuMzMz M3B4Ij48YnI+DQo8L3NwYW4+PC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHls ZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTpzbWFs bCI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250 LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjsgZm9udC1zaXplOnNtYWxsIj4NCiZu YnNwOzwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_3F437107848A5140A6A19222EFFB3481200E2839PRNMBX012TheFac_-- From nobody Sat Mar 12 17:02:23 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D14612D8F5 for ; Sat, 12 Mar 2016 17:02:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com 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 0qE2W7WXY_Bt for ; Sat, 12 Mar 2016 17:02:19 -0800 (PST) Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (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 F3B1312D8ED for ; Sat, 12 Mar 2016 17:02:18 -0800 (PST) Received: from pps.filterd (m0044010.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u2D12HC6028868; Sat, 12 Mar 2016 17:02:17 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=hsM1Ip1AARhrmVQcKLyKOJ+ti/h5qOHxx9rMKpemF1U=; b=qSToNl0sNqC43PcsCQfNvBrR3z3Yic2sfpYTdOi/k/Z/dJeuH00RLpnZWYzof8f0KZjn 0nsrw0i+MJoi4jyvs/8v+0YhMlVl4vwY3wQX5azEi2Lf8b9VrPSSlOab6qjPGvp7UF42 sE+2TfNED3nIQ47p5vkW1k1EQ1OwiXtzUgI= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0a-00082601.pphosted.com with ESMTP id 21mg8nj4ww-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Sat, 12 Mar 2016 17:02:17 -0800 Received: from PRN-MBX01-2.TheFacebook.com ([169.254.3.204]) by PRN-CHUB16.TheFacebook.com ([fe80::7948:a494:45d7:3dd9%12]) with mapi id 14.03.0248.002; Sat, 12 Mar 2016 17:02:16 -0800 From: Petr Lapukhov To: "Bertrand Duvivier (bduvivie)" , Robert Raszuk , "exa@juniper.net" Thread-Topic: [Idr] Use of BGP for Opaque Signaling Thread-Index: AQHRfKONNK1upwIbukaCHqWz2SNu2p9W/pQA//+O93c= Date: Sun, 13 Mar 2016 01:02:15 +0000 Message-ID: <3F437107848A5140A6A19222EFFB3481200E2855@PRN-MBX01-2.TheFacebook.com> References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.52.123] Content-Type: multipart/alternative; boundary="_000_3F437107848A5140A6A19222EFFB3481200E2855PRNMBX012TheFac_" MIME-Version: 1.0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-03-12_10:, , signatures=0 Archived-At: Cc: idr wg Subject: Re: [Idr] Use of BGP for Opaque Signaling X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2016 01:02:21 -0000 --_000_3F437107848A5140A6A19222EFFB3481200E2855PRNMBX012TheFac_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Bertrand, we spent some time discussing whether an explicit multiplexor is needed wit= h the key (NLRI) field. The major problem is agreeing on format and uniquen= ess of such multiplexor. In the end, the agreement was to make this look mo= re like memcache/redis and let the applications decide on how the data shou= ld be properly separated. The content is VPN-agnostic, in the sense that th= e new AFI/SAFI is completely orthogonal to routing information distribution= . Keyur had some suggestions to make this more "domain-unique", I hope he can= comment here as well. I think it's pretty common to feel awkward about fla= t name-space, but in general there are way to independently generate unique= identifiers and distribute them out of band. Since there is so many of the= m, it is probably better not to include them in specification... ________________________________ From: Bertrand Duvivier (bduvivie) [bduvivie@cisco.com] Sent: Saturday, March 12, 2016 3:42 PM To: Robert Raszuk; Petr Lapukhov; exa@juniper.net Cc: idr wg Subject: Re: [Idr] Use of BGP for Opaque Signaling Petr, Eben, What about L3VPN use-cases ? If we make this VRF aware, couldn=92t we have 2 VPN's sending same / simil= ar opaque updates=85 and therefor leaking from one VPN to another VPN. Should we also carry the Route Distinguisher or VPN-id to avoid collision, = and of course for non VPN cases, this could be zero. Best Regards Bertrand Duvivier --_000_3F437107848A5140A6A19222EFFB3481200E2855PRNMBX012TheFac_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Bertrand,

we spent some time discussing whether an explicit multiplexor is neede= d with the key (NLRI) field. The major problem is agreeing on format and un= iqueness of such multiplexor. In the end, the agreement was to make this lo= ok more like memcache/redis and let the applications decide on how the data should be properly separated. = The content is VPN-agnostic, in the sense that the new AFI/SAFI is complete= ly orthogonal to routing information distribution. 

Keyur had some suggestions to make this more "domain-unique"= , I hope he can comment here as well. I think it's pretty common to feel aw= kward about flat name-space, but in general there are way to independently = generate unique identifiers and distribute them out of band. Since there is so many of them, it is probably better no= t to include them in specification...

From: Bertrand Duvivier (bduvivie) [bduvi= vie@cisco.com]
Sent: Saturday, March 12, 2016 3:42 PM
To: Robert Raszuk; Petr Lapukhov; exa@juniper.net
Cc: idr wg
Subject: Re: [Idr] Use of BGP for Opaque Signaling

Petr, Eben,

What about L3VPN use-cases ? 

If we make this VRF aware,  couldn=92t we have 2 VPN's sending sa= me / similar opaque updates=85 and therefor leaking from one VPN to another= VPN.

Should we also carry the Route Distinguisher or VPN-id to avoid collis= ion, and of course for non VPN cases, this could be zero. 

Best Regards Bertrand Duvivier

--_000_3F437107848A5140A6A19222EFFB3481200E2855PRNMBX012TheFac_-- From nobody Sat Mar 12 17:25:43 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7383A12D856 for ; Sat, 12 Mar 2016 17:25:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.36 X-Spam-Level: X-Spam-Status: No, score=-0.36 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 lJokuGI8EgLd for ; Sat, 12 Mar 2016 17:25:38 -0800 (PST) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (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 1056D12D617 for ; Sat, 12 Mar 2016 17:25:38 -0800 (PST) Received: by mail-lb0-x22b.google.com with SMTP id bc4so198894745lbc.2 for ; Sat, 12 Mar 2016 17:25:37 -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; bh=8AYJkTkiIcSTnxJV2v+FudE6m43idHksLgXXYds2wK8=; b=B1XvJWTXTh79GqZKlk2TtDjhIVWtYX2NIQmiWX7aIR8AsQvVzpXXHRKlcZxKE2ZFDZ XYLtgxnVkqnAr+J55Fu7VRzXE3ZH0yHtdGTCaSMAlpwXi6E2/wch6ysIUzJf/egFM7aV XRpgHSwbW9MhRCMjDardgumjyb9YJk0du1QP2ezcyKbjR/cctXZ8znZji1AGgzKSP1hk 8CdhbZoVtb8Dl+KlFAaDhrzpahC7sFl6FZaTj0/LyNE3dHo6Pq1CuTrBRV/NqmxnHrvP mcqlSQqb6xdTgkjYd2ClMM7txPZZl9pJbmnRhloz2fU82i9lmeV28IynbUpkmeUfgzoA zs6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=8AYJkTkiIcSTnxJV2v+FudE6m43idHksLgXXYds2wK8=; b=Pola6x0E5REthMYCg/tL8ioRgiAkZ+Wcq2NJ/ciayBg7dGI9oxtwT8UV8xsJU/VM0k GwMNqQXJgC75r8tiIAs6rNbQ31z1u9VTRSp+hYkXfey7Yfnp/NAyjShYX9NAYMNtAWXf 6Irp+A7FcThAtHsOspXXuZtXyit6lRcEnaobPKGGXU31+GALHaECXzrOGAe1GdXVVkaE voJxvz/0RBSjOtvCua1htz47InKkHGi6+2YdmeyphG/oPrYcRPuuXqGlnQ84bqQHkIC7 l+IG/GLgYlcLcVLrc7oO+lvfEn7+DeUzGhv8oX0+Wrnjc+EB9+mIZFNuMkKvswM1XN66 y/Kg== X-Gm-Message-State: AD7BkJIWJ8UxyJ/CdM27AJAlelk2ytWNRYPpuU8kHquNEgX9UjfKkontgf/RTBbiq7N3RtBpvpD0zctemjcrmg== MIME-Version: 1.0 X-Received: by 10.112.170.137 with SMTP id am9mr4244647lbc.84.1457832336014; Sat, 12 Mar 2016 17:25:36 -0800 (PST) Sender: rraszuk@gmail.com Received: by 10.25.136.133 with HTTP; Sat, 12 Mar 2016 17:25:35 -0800 (PST) In-Reply-To: <3F437107848A5140A6A19222EFFB3481200E2839@PRN-MBX01-2.TheFacebook.com> References: <3F437107848A5140A6A19222EFFB3481200E2839@PRN-MBX01-2.TheFacebook.com> Date: Sat, 12 Mar 2016 20:25:35 -0500 X-Google-Sender-Auth: GmnM_qfBqXq-xv6UW52nM1SvG-A Message-ID: From: Robert Raszuk To: Petr Lapukhov Content-Type: multipart/alternative; boundary=001a11c3743887c790052de40ae1 Archived-At: Cc: idr wg Subject: Re: [Idr] Use of BGP for Opaque Signaling X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2016 01:25:41 -0000 --001a11c3743887c790052de40ae1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =E2=80=8BHello Petr,=E2=80=8B > Re: Impact on routing. I should be more explicit stating that the idea is > for BGP to not interpret the key-value mappings in any way. > =E2=80=8BThat was very clear already. But if you look at number of BGP implementations recognizing the AFI/SAFI coming over single session is not done immediately in the BGP message parsing. That is my main point suggesting transport instance port. I no longer believe multisessions will do it neither that we could off load it as implementation specific thing.=E2=80=8B > The consumer (running on same device, possibly) may still influence > routing based on its interpretation of data, either by accessing the > platform SDK or by performing BGP routing injection over the correspondin= g > AFI/SAFI. > =E2=80=8BThat is exactly the issue. The only way BGP-LS went by was the cla= im about their explicit disjointed topology from existing BGP. It was well positioned that BGP-LS can be completely incongruent with "routing" BGP. = =E2=80=8B =E2=80=8BThe possible channels the IGP information may impact routing were classified as out of the band likely coming via some other ways from controllers (I2RS, APIs, routing BGP SAFI etc ...). > Re: Transport instance. I think it's a great idea to run this on separate > instance, but right now we typically run just one process, and it adds so= me > operational overhead to maintain two of them. Also, often this extension > could be used just with out-of-band reflection. This is why I feel it is > rather better to keep this applicable to any type of BGP instance. > =E2=80=8BImagine that you will not get far in this BGP proposal. Then what = is left is nothing else like a new process talking over one of few message buses today to distribute the set of information you need. In fact I am not convinced p2mp is the best way to go with here. Pub-sub without RTC hacks may be much better - don't you honestly think ? Best, R.=E2=80=8B > Re: Scope of application. The main goal was to use this in data-center, > but I can theorize this could be used among few operators that are willin= g > to develop on-device applications and exchange data using the > pre-established channels (e.g. the WISER use case). In this situation, > limiting scope to just private ASNs could be tricky. Furthermore, > non-private ASNs could be used in data-center as well (just not exposed > outside...). > > Re: Transitive attribute. Ideally, it would be great to carry the value i= n > next-hop field of MP_REACH_NLRI, but the length is limited to 8 bytes, > hence the new attribute. I do not have strong arguments to making this > transitive, it should be fine to go with non-transitive and corresponding > error handling. > > Re: Security. Since we do not directly influence path selection with new > data, the threats could be limited to those targeting BGPinfra itself e.g= . > flooding with information, disrupting session etc. There could be questio= ns > about information authenticity, but this could be left up to the > applications to decide (e.g. signing the key-value bindings). > > Regards, > > Petr > > ------------------------------ > *From:* rraszuk@gmail.com [rraszuk@gmail.com] on behalf of Robert Raszuk = [ > robert@raszuk.net] > *Sent:* Saturday, March 12, 2016 1:10 PM > *To:* Petr Lapukhov; exa@juniper.net > *Cc:* idr wg > *Subject:* Use of BGP for Opaque Signaling > > =E2=80=8BPetr, Eben, > > I have few questions and comments to your proposal. > > - The draft =E2=80=8Battempts to reuse BGP mechanism for p2mp distributio= n of > opaque information. That alone is not a bad thing :) However when you mak= e > reference to BGP-LS it needs to be observed that BGP-LS is not position t= o > directly impact routing (ie content of RIB and FIBs) unlike one of the us= e > cases described in your draft Intro paragraph. That means that unlike > BGP-LS it must co-exist with routing BGP on the same BGP speakers. > > Here I would like to bring back my proposal to define new port for > Transport Instance BGP https://tools.ietf.org/html/draft-raszuk-ti-bgp-01 > > which at the time of discussion was supposed to be shortly addressed by > dynamic port allocations of multisessions which to the best of my knowled= ge > never happened. > > So first comment is that if we go with reusing BGP-4 for this type of > signalling let's enforce it's early separation from "classic" BGP. > > - Second comment is related to the scope of use. If the scope is private = - > let's perhaps enforce it more explicitly such that by the spec it is > illegal AFI/SAFI pair in the public Internet. For example by stating that > it is illegal to have non private AS in the AS_PATH of such UPDATE msg. > > - Third the draft states that there is no new security implications .. > well if the scope is non private I am afraid that is no the case. As you > have seen (and still seeing) securing BGP UPDATE MSG is MP_REACH content > dependent. If content is free form I am afraid it will be rather hard to > secure it well :) > > - Last as opaque value container you are defining an transitive attribute > ? Is the intention to use this attribute in existing AFI/SAFIs as well ? > Otherwise if not why do you need this to be transitive if capability > negotiation already may implicitly define it's support by new AFI/SAFI. > > Cheers, > R. > > PS. > > > There is an ongoing discussion around avoiding NLRI (key) collisions. > > Where is such discussion taking place ? Shouldn't IDR be perhaps in the > loop a bit :) > > > > > --001a11c3743887c790052de40ae1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=E2=80=8BHello Petr,=E2=80=8B
=C2=A0
Re: Impact on routing. I sho= uld be more explicit stating that the idea is for BGP to not interpret the = key-value mappings in any way.

=E2=80=8BThat was very clear already. But if you= look at number of BGP implementations recognizing the AFI/SAFI coming over= single session is not done immediately in the BGP message parsing. That is= my main point suggesting transport instance port.=C2=A0

I no longer believe multisessions will d= o it neither that we could off load it as implementation specific thing.=E2= =80=8B

=C2=A0
The consumer (running on same device, possibly) may sti= ll influence routing based on its interpretation of data, either by accessing the platform SDK or by performing BGP routing injection over = the corresponding AFI/SAFI.

=E2=80=8BThat is exactly the issue. The only way= BGP-LS went by was the claim about their explicit disjointed topology from= existing BGP. It was well positioned that BGP-LS can be completely incongr= uent with "routing" BGP. =E2=80=8B

=E2=80=8BThe possible channels the IGP information may impact rout= ing were classified as out of the band likely coming via some other ways fr= om controllers (I2RS, APIs, routing BGP SAFI etc ...).=C2=A0

=C2=A0
<= div>
Re: Transport instance. I think it's a great idea to run this on s= eparate instance, but right now we typically run just one process, and it a= dds some operational overhead to maintain two of them. Also, often this ext= ension could be used just with out-of-band reflection. This is why I feel it is rather better to keep this applicable= to any type of BGP instance.

=

=E2=80=8BImagine that you will not g= et far in this BGP proposal. Then what is left is nothing else like a new p= rocess talking over one of few message buses today to distribute the set of= information you need.=C2=A0

In fact I am not convinced p2mp is the best way to go with here. P= ub-sub without RTC hacks may be much better - don't you honestly think = ?=C2=A0

Best,
R.=E2=80=8B

=C2=A0
Re: Scope of application. The main goal= was to use this in data-center, but I can theorize this could be used amon= g few operators that are willing to develop on-device applications and exch= ange data using the pre-established channels (e.g. the WISER use case). In this situation, limiting scope to just private ASNs could be tri= cky. Furthermore, non-private ASNs could be used in data-center as well (ju= st not exposed outside...).

Re: Transitive attribute. Ideally, it would be great to carry the valu= e in next-hop field of MP_REACH_NLRI, but the length is limited to 8 bytes,= hence the new attribute. I do not have strong arguments to making this tra= nsitive, it should be fine to go with non-transitive and corresponding error handling.=C2=A0

Re: Security. Since we do not directly influence path selection with n= ew data, the threats could be limited to those targeting BGPinfra itself e.= g. flooding with information, disrupting session etc. There could be questi= ons about information authenticity, but this could be left up to the applications to decide (e.g. signing the = key-value bindings).

Regards,

Petr

From: rr= aszuk@gmail.com [rraszuk@gmail.com] on behalf of Robert Raszuk [robert@raszuk.net]
Sent: Saturday, March 12, 2016 1:10 PM
To: Petr Lapukhov; exa@juniper.net
Cc: idr wg
Subject: Use of BGP for Opaque Signaling

=E2=80=8BPetr, Eben,

I have few questions and comments to your proposal.=C2=A0

- The draft =E2=80=8Battempts to reuse BGP mechanism for p2mp distribution = of opaque information. That alone is not a bad thing :) However when you ma= ke reference to BGP-LS it needs to be observed that BGP-LS is not position = to directly impact routing (ie content of RIB and FIBs) unlike one of the use cases described in your draft Intro pa= ragraph. That means that unlike BGP-LS it must co-exist with routing BGP on= the same BGP speakers.=C2=A0

Here I would like to bring back my proposal to define new port for Transpor= t Instance BGP=C2=A0https://tools.ietf.org/html= /draft-raszuk-ti-bgp-01 which at the time of discussion was supposed to be shortly addressed by dy= namic port allocations of multisessions which to the best of my knowledge n= ever happened.=C2=A0

So first comment is that if we go with reusing BGP-4 for this type of signa= lling let's enforce it's early separation from "classic" = BGP.=C2=A0

- Second comment is related to the scope of use. If the scope is private - = let's perhaps enforce it more explicitly such that by the spec it is il= legal AFI/SAFI pair in the public Internet. For example by stating that it = is illegal to have non private AS in the AS_PATH of such UPDATE msg.=C2=A0

- Third the draft states that there is no new security implications .. well= if the scope is non private I am afraid that is no the case. As you have s= een (and still seeing) securing BGP UPDATE MSG is MP_REACH content dependen= t. If content is free form I am afraid it will be rather hard to secure it well :)=C2=A0

- Last as opaque value container you are defining an transitive attribute ?= Is the intention to use this attribute in existing AFI/SAFIs as well ? Oth= erwise if not why do you need this to be transitive if capability negotiati= on already may implicitly define it's support by new AFI/SAFI.

Cheers,
R.

PS.=C2=A0

>= ; There is an ongoing discussion around avoiding NLRI (key) collisions.
Whe= re is such discussion taking place ? Shouldn't IDR be perhaps in the lo= op a bit :)=C2=A0

=C2=A0

--001a11c3743887c790052de40ae1-- From nobody Sat Mar 12 19:20:36 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 994BC12D704 for ; Sat, 12 Mar 2016 19:20:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.731 X-Spam-Level: X-Spam-Status: No, score=-0.731 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com 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 13wIDT1gF-LS for ; Sat, 12 Mar 2016 19:20:30 -0800 (PST) Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (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 89CF112D6B5 for ; Sat, 12 Mar 2016 19:20:30 -0800 (PST) Received: from pps.filterd (m0044010.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u2D3GeM3022740; Sat, 12 Mar 2016 19:20:30 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=3iU5Y/xKspCPhYy1dE9Iy2lh/5w9sKWobPRcrMVZNaQ=; b=LCCmvrc3zVHLaA5FiFBcr0GtPynF/cZ8JIeUfO0lCU+S0w0cRrA3DuyLANIxrw6t1yVF z2DK6h57H8vcrW+428Eu53TLMHrmbalpXb5fUEd6eQoghkARfGvlKMh4nntP1HTdmOcB 0+k1sAWbftJHzcEQ5bPHq27nwPiGtthhSI0= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0a-00082601.pphosted.com with ESMTP id 21mg8njcqy-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Sat, 12 Mar 2016 19:20:30 -0800 Received: from PRN-MBX01-2.TheFacebook.com ([169.254.3.204]) by PRN-CHUB05.TheFacebook.com ([fe80::9886:b2c2:db18:5ba7%12]) with mapi id 14.03.0248.002; Sat, 12 Mar 2016 19:20:29 -0800 From: Petr Lapukhov To: Robert Raszuk Thread-Topic: Use of BGP for Opaque Signaling Thread-Index: AQHRfKONNK1upwIbukaCHqWz2SNu2p9WgK6PgACao4D//5fqtw== Date: Sun, 13 Mar 2016 03:20:28 +0000 Message-ID: <3F437107848A5140A6A19222EFFB3481200E2A32@PRN-MBX01-2.TheFacebook.com> References: <3F437107848A5140A6A19222EFFB3481200E2839@PRN-MBX01-2.TheFacebook.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.52.123] Content-Type: multipart/alternative; boundary="_000_3F437107848A5140A6A19222EFFB3481200E2A32PRNMBX012TheFac_" MIME-Version: 1.0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-03-13_01:, , signatures=0 Archived-At: Cc: idr wg Subject: Re: [Idr] Use of BGP for Opaque Signaling X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2016 03:20:34 -0000 --_000_3F437107848A5140A6A19222EFFB3481200E2A32PRNMBX012TheFac_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBJbiBmYWN0IEkgYW0gbm90IGNvbnZpbmNlZCBwMm1wIGlzIHRoZSBiZXN0IHdheSB0byBnbyB3 aXRoIGhlcmUuDQo+IFB1Yi1zdWIgd2l0aG91dCBSVEMgaGFja3MgbWF5IGJlIG11Y2ggYmV0dGVy IC0gZG9uJ3QgeW91IGhvbmVzdGx5IHRoaW5rID8NCg0KTm90IGV4YWN0bHksIGJ1dCBtYXliZSBJ IG1pc3VuZGVyc3Rvb2Qgd2hhdCBwMm1wIG1lYW5zIDopIFRoZSBtYWluIGFkdmFudGFnZSBvZiB1 c2luZyBCR1AgKGF0IGxlYXN0IGluIG91ciBlbnZpcm9ubWVudCkgY29tZXMgZnJvbSB0aGUgZmFj dCB0aGF0IGl0J3MgYWxyZWFkeSBib290c3RyYXBwZWQgd2hlbiBvbi1zd2l0Y2ggKG9yIG9uLXNl cnZlcikgYXBwbGljYXRpb25zIHN0YXJ0IGNvbWluZyB1cC4gQW5kIGl0IHN0YXlzIHRoZXJlIGV2 ZW4gd2hlbiB0aGUgc2VydmVycyBob3N0aW5nIGV4dGVybmFsIGtleS12YWx1ZSBzdG9yZSBtYXkg YmUgZ29uZS4NCg0KQXNpZGUgZnJvbSB0aGlzLCBJIGZ1bGx5IGFncmVlIC0gaXQgZG9lcyBub3Qg b2ZmZXIgbXVjaCBtb3JlIHRoYW4gYW55IGtleS12YWx1ZSBzdG9yZS4gQW5kIGl0IGhhcyBpdHMg b3duIGNvbnN0cmFpbnRzLCBsaWtlIH40SyB2YWx1ZSBzaXplLiBQbHVzLCBpdCdzIG5vdCBldmVu IGEgcHJvcGVyIHB1Yi1zdWIsIHNpbmNlIHRoZXJlIGlzIG5vIGRpc2NyZWV0IG1lc3NhZ2Ugc2Vt YW50aWMgLSBvbmx5IHN0YXRlIGRpc3NlbWluYXRpb24gOikNCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCkZyb206IHJyYXN6dWtAZ21haWwuY29tIFtycmFzenVrQGdtYWlsLmNv bV0gb24gYmVoYWxmIG9mIFJvYmVydCBSYXN6dWsgW3JvYmVydEByYXN6dWsubmV0XQ0KU2VudDog U2F0dXJkYXksIE1hcmNoIDEyLCAyMDE2IDU6MjUgUE0NClRvOiBQZXRyIExhcHVraG92DQpDYzog ZXhhQGp1bmlwZXIubmV0OyBpZHIgd2cNClN1YmplY3Q6IFJlOiBVc2Ugb2YgQkdQIGZvciBPcGFx dWUgU2lnbmFsaW5nDQoNCuKAi0hlbGxvIFBldHIs4oCLDQoNClJlOiBJbXBhY3Qgb24gcm91dGlu Zy4gSSBzaG91bGQgYmUgbW9yZSBleHBsaWNpdCBzdGF0aW5nIHRoYXQgdGhlIGlkZWEgaXMgZm9y IEJHUCB0byBub3QgaW50ZXJwcmV0IHRoZSBrZXktdmFsdWUgbWFwcGluZ3MgaW4gYW55IHdheS4N Cg0K4oCLVGhhdCB3YXMgdmVyeSBjbGVhciBhbHJlYWR5LiBCdXQgaWYgeW91IGxvb2sgYXQgbnVt YmVyIG9mIEJHUCBpbXBsZW1lbnRhdGlvbnMgcmVjb2duaXppbmcgdGhlIEFGSS9TQUZJIGNvbWlu ZyBvdmVyIHNpbmdsZSBzZXNzaW9uIGlzIG5vdCBkb25lIGltbWVkaWF0ZWx5IGluIHRoZSBCR1Ag bWVzc2FnZSBwYXJzaW5nLiBUaGF0IGlzIG15IG1haW4gcG9pbnQgc3VnZ2VzdGluZyB0cmFuc3Bv cnQgaW5zdGFuY2UgcG9ydC4NCg0KSSBubyBsb25nZXIgYmVsaWV2ZSBtdWx0aXNlc3Npb25zIHdp bGwgZG8gaXQgbmVpdGhlciB0aGF0IHdlIGNvdWxkIG9mZiBsb2FkIGl0IGFzIGltcGxlbWVudGF0 aW9uIHNwZWNpZmljIHRoaW5nLuKAiw0KDQoNClRoZSBjb25zdW1lciAocnVubmluZyBvbiBzYW1l IGRldmljZSwgcG9zc2libHkpIG1heSBzdGlsbCBpbmZsdWVuY2Ugcm91dGluZyBiYXNlZCBvbiBp dHMgaW50ZXJwcmV0YXRpb24gb2YgZGF0YSwgZWl0aGVyIGJ5IGFjY2Vzc2luZyB0aGUgcGxhdGZv cm0gU0RLIG9yIGJ5IHBlcmZvcm1pbmcgQkdQIHJvdXRpbmcgaW5qZWN0aW9uIG92ZXIgdGhlIGNv cnJlc3BvbmRpbmcgQUZJL1NBRkkuDQoNCuKAi1RoYXQgaXMgZXhhY3RseSB0aGUgaXNzdWUuIFRo ZSBvbmx5IHdheSBCR1AtTFMgd2VudCBieSB3YXMgdGhlIGNsYWltIGFib3V0IHRoZWlyIGV4cGxp Y2l0IGRpc2pvaW50ZWQgdG9wb2xvZ3kgZnJvbSBleGlzdGluZyBCR1AuIEl0IHdhcyB3ZWxsIHBv c2l0aW9uZWQgdGhhdCBCR1AtTFMgY2FuIGJlIGNvbXBsZXRlbHkgaW5jb25ncnVlbnQgd2l0aCAi cm91dGluZyIgQkdQLiDigIsNCg0K4oCLVGhlIHBvc3NpYmxlIGNoYW5uZWxzIHRoZSBJR1AgaW5m b3JtYXRpb24gbWF5IGltcGFjdCByb3V0aW5nIHdlcmUgY2xhc3NpZmllZCBhcyBvdXQgb2YgdGhl IGJhbmQgbGlrZWx5IGNvbWluZyB2aWEgc29tZSBvdGhlciB3YXlzIGZyb20gY29udHJvbGxlcnMg KEkyUlMsIEFQSXMsIHJvdXRpbmcgQkdQIFNBRkkgZXRjIC4uLikuDQoNCg0KUmU6IFRyYW5zcG9y dCBpbnN0YW5jZS4gSSB0aGluayBpdCdzIGEgZ3JlYXQgaWRlYSB0byBydW4gdGhpcyBvbiBzZXBh cmF0ZSBpbnN0YW5jZSwgYnV0IHJpZ2h0IG5vdyB3ZSB0eXBpY2FsbHkgcnVuIGp1c3Qgb25lIHBy b2Nlc3MsIGFuZCBpdCBhZGRzIHNvbWUgb3BlcmF0aW9uYWwgb3ZlcmhlYWQgdG8gbWFpbnRhaW4g dHdvIG9mIHRoZW0uIEFsc28sIG9mdGVuIHRoaXMgZXh0ZW5zaW9uIGNvdWxkIGJlIHVzZWQganVz dCB3aXRoIG91dC1vZi1iYW5kIHJlZmxlY3Rpb24uIFRoaXMgaXMgd2h5IEkgZmVlbCBpdCBpcyBy YXRoZXIgYmV0dGVyIHRvIGtlZXAgdGhpcyBhcHBsaWNhYmxlIHRvIGFueSB0eXBlIG9mIEJHUCBp bnN0YW5jZS4NCg0KDQrigItJbWFnaW5lIHRoYXQgeW91IHdpbGwgbm90IGdldCBmYXIgaW4gdGhp cyBCR1AgcHJvcG9zYWwuIFRoZW4gd2hhdCBpcyBsZWZ0IGlzIG5vdGhpbmcgZWxzZSBsaWtlIGEg bmV3IHByb2Nlc3MgdGFsa2luZyBvdmVyIG9uZSBvZiBmZXcgbWVzc2FnZSBidXNlcyB0b2RheSB0 byBkaXN0cmlidXRlIHRoZSBzZXQgb2YgaW5mb3JtYXRpb24geW91IG5lZWQuDQoNCkluIGZhY3Qg SSBhbSBub3QgY29udmluY2VkIHAybXAgaXMgdGhlIGJlc3Qgd2F5IHRvIGdvIHdpdGggaGVyZS4g UHViLXN1YiB3aXRob3V0IFJUQyBoYWNrcyBtYXkgYmUgbXVjaCBiZXR0ZXIgLSBkb24ndCB5b3Ug aG9uZXN0bHkgdGhpbmsgPw0KDQpCZXN0LA0KUi7igIsNCg0KDQpSZTogU2NvcGUgb2YgYXBwbGlj YXRpb24uIFRoZSBtYWluIGdvYWwgd2FzIHRvIHVzZSB0aGlzIGluIGRhdGEtY2VudGVyLCBidXQg SSBjYW4gdGhlb3JpemUgdGhpcyBjb3VsZCBiZSB1c2VkIGFtb25nIGZldyBvcGVyYXRvcnMgdGhh dCBhcmUgd2lsbGluZyB0byBkZXZlbG9wIG9uLWRldmljZSBhcHBsaWNhdGlvbnMgYW5kIGV4Y2hh bmdlIGRhdGEgdXNpbmcgdGhlIHByZS1lc3RhYmxpc2hlZCBjaGFubmVscyAoZS5nLiB0aGUgV0lT RVIgdXNlIGNhc2UpLiBJbiB0aGlzIHNpdHVhdGlvbiwgbGltaXRpbmcgc2NvcGUgdG8ganVzdCBw cml2YXRlIEFTTnMgY291bGQgYmUgdHJpY2t5LiBGdXJ0aGVybW9yZSwgbm9uLXByaXZhdGUgQVNO cyBjb3VsZCBiZSB1c2VkIGluIGRhdGEtY2VudGVyIGFzIHdlbGwgKGp1c3Qgbm90IGV4cG9zZWQg b3V0c2lkZS4uLikuDQoNClJlOiBUcmFuc2l0aXZlIGF0dHJpYnV0ZS4gSWRlYWxseSwgaXQgd291 bGQgYmUgZ3JlYXQgdG8gY2FycnkgdGhlIHZhbHVlIGluIG5leHQtaG9wIGZpZWxkIG9mIE1QX1JF QUNIX05MUkksIGJ1dCB0aGUgbGVuZ3RoIGlzIGxpbWl0ZWQgdG8gOCBieXRlcywgaGVuY2UgdGhl IG5ldyBhdHRyaWJ1dGUuIEkgZG8gbm90IGhhdmUgc3Ryb25nIGFyZ3VtZW50cyB0byBtYWtpbmcg dGhpcyB0cmFuc2l0aXZlLCBpdCBzaG91bGQgYmUgZmluZSB0byBnbyB3aXRoIG5vbi10cmFuc2l0 aXZlIGFuZCBjb3JyZXNwb25kaW5nIGVycm9yIGhhbmRsaW5nLg0KDQpSZTogU2VjdXJpdHkuIFNp bmNlIHdlIGRvIG5vdCBkaXJlY3RseSBpbmZsdWVuY2UgcGF0aCBzZWxlY3Rpb24gd2l0aCBuZXcg ZGF0YSwgdGhlIHRocmVhdHMgY291bGQgYmUgbGltaXRlZCB0byB0aG9zZSB0YXJnZXRpbmcgQkdQ aW5mcmEgaXRzZWxmIGUuZy4gZmxvb2Rpbmcgd2l0aCBpbmZvcm1hdGlvbiwgZGlzcnVwdGluZyBz ZXNzaW9uIGV0Yy4gVGhlcmUgY291bGQgYmUgcXVlc3Rpb25zIGFib3V0IGluZm9ybWF0aW9uIGF1 dGhlbnRpY2l0eSwgYnV0IHRoaXMgY291bGQgYmUgbGVmdCB1cCB0byB0aGUgYXBwbGljYXRpb25z IHRvIGRlY2lkZSAoZS5nLiBzaWduaW5nIHRoZSBrZXktdmFsdWUgYmluZGluZ3MpLg0KDQpSZWdh cmRzLA0KDQpQZXRyDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBy cmFzenVrQGdtYWlsLmNvbTxtYWlsdG86cnJhc3p1a0BnbWFpbC5jb20+IFtycmFzenVrQGdtYWls LmNvbTxtYWlsdG86cnJhc3p1a0BnbWFpbC5jb20+XSBvbiBiZWhhbGYgb2YgUm9iZXJ0IFJhc3p1 ayBbcm9iZXJ0QHJhc3p1ay5uZXQ8bWFpbHRvOnJvYmVydEByYXN6dWsubmV0Pl0NClNlbnQ6IFNh dHVyZGF5LCBNYXJjaCAxMiwgMjAxNiAxOjEwIFBNDQpUbzogUGV0ciBMYXB1a2hvdjsgZXhhQGp1 bmlwZXIubmV0PG1haWx0bzpleGFAanVuaXBlci5uZXQ+DQpDYzogaWRyIHdnDQpTdWJqZWN0OiBV c2Ugb2YgQkdQIGZvciBPcGFxdWUgU2lnbmFsaW5nDQoNCuKAi1BldHIsIEViZW4sDQoNCkkgaGF2 ZSBmZXcgcXVlc3Rpb25zIGFuZCBjb21tZW50cyB0byB5b3VyIHByb3Bvc2FsLg0KDQotIFRoZSBk cmFmdCDigIthdHRlbXB0cyB0byByZXVzZSBCR1AgbWVjaGFuaXNtIGZvciBwMm1wIGRpc3RyaWJ1 dGlvbiBvZiBvcGFxdWUgaW5mb3JtYXRpb24uIFRoYXQgYWxvbmUgaXMgbm90IGEgYmFkIHRoaW5n IDopIEhvd2V2ZXIgd2hlbiB5b3UgbWFrZSByZWZlcmVuY2UgdG8gQkdQLUxTIGl0IG5lZWRzIHRv IGJlIG9ic2VydmVkIHRoYXQgQkdQLUxTIGlzIG5vdCBwb3NpdGlvbiB0byBkaXJlY3RseSBpbXBh Y3Qgcm91dGluZyAoaWUgY29udGVudCBvZiBSSUIgYW5kIEZJQnMpIHVubGlrZSBvbmUgb2YgdGhl IHVzZSBjYXNlcyBkZXNjcmliZWQgaW4geW91ciBkcmFmdCBJbnRybyBwYXJhZ3JhcGguIFRoYXQg bWVhbnMgdGhhdCB1bmxpa2UgQkdQLUxTIGl0IG11c3QgY28tZXhpc3Qgd2l0aCByb3V0aW5nIEJH UCBvbiB0aGUgc2FtZSBCR1Agc3BlYWtlcnMuDQoNCkhlcmUgSSB3b3VsZCBsaWtlIHRvIGJyaW5n IGJhY2sgbXkgcHJvcG9zYWwgdG8gZGVmaW5lIG5ldyBwb3J0IGZvciBUcmFuc3BvcnQgSW5zdGFu Y2UgQkdQIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1yYXN6dWstdGktYmdwLTAx PGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fdG9v bHMuaWV0Zi5vcmdfaHRtbF9kcmFmdC0yRHJhc3p1ay0yRHRpLTJEYmdwLTJEMDEmZD1Dd01GYVEm Yz01VkQwUlR0TmxUaDN5Y2Q0MWIzTVV3JnI9TFVfdkphTV9FUXUxU3NtMzVqMnhsQSZtPTc1US1u dlgyUmhoeFltLXIyQkl4Rmh0SXBLelQ5cEVnR3g5VVdqcTZmVDQmcz1rSzcxZVNxV0JJVGFsRzFZ MWlOV2FpSGFTQTd2ck1Nbkw0bGtpZWFxMnVZJmU9PiB3aGljaCBhdCB0aGUgdGltZSBvZiBkaXNj dXNzaW9uIHdhcyBzdXBwb3NlZCB0byBiZSBzaG9ydGx5IGFkZHJlc3NlZCBieSBkeW5hbWljIHBv cnQgYWxsb2NhdGlvbnMgb2YgbXVsdGlzZXNzaW9ucyB3aGljaCB0byB0aGUgYmVzdCBvZiBteSBr bm93bGVkZ2UgbmV2ZXIgaGFwcGVuZWQuDQoNClNvIGZpcnN0IGNvbW1lbnQgaXMgdGhhdCBpZiB3 ZSBnbyB3aXRoIHJldXNpbmcgQkdQLTQgZm9yIHRoaXMgdHlwZSBvZiBzaWduYWxsaW5nIGxldCdz IGVuZm9yY2UgaXQncyBlYXJseSBzZXBhcmF0aW9uIGZyb20gImNsYXNzaWMiIEJHUC4NCg0KLSBT ZWNvbmQgY29tbWVudCBpcyByZWxhdGVkIHRvIHRoZSBzY29wZSBvZiB1c2UuIElmIHRoZSBzY29w ZSBpcyBwcml2YXRlIC0gbGV0J3MgcGVyaGFwcyBlbmZvcmNlIGl0IG1vcmUgZXhwbGljaXRseSBz dWNoIHRoYXQgYnkgdGhlIHNwZWMgaXQgaXMgaWxsZWdhbCBBRkkvU0FGSSBwYWlyIGluIHRoZSBw dWJsaWMgSW50ZXJuZXQuIEZvciBleGFtcGxlIGJ5IHN0YXRpbmcgdGhhdCBpdCBpcyBpbGxlZ2Fs IHRvIGhhdmUgbm9uIHByaXZhdGUgQVMgaW4gdGhlIEFTX1BBVEggb2Ygc3VjaCBVUERBVEUgbXNn Lg0KDQotIFRoaXJkIHRoZSBkcmFmdCBzdGF0ZXMgdGhhdCB0aGVyZSBpcyBubyBuZXcgc2VjdXJp dHkgaW1wbGljYXRpb25zIC4uIHdlbGwgaWYgdGhlIHNjb3BlIGlzIG5vbiBwcml2YXRlIEkgYW0g YWZyYWlkIHRoYXQgaXMgbm8gdGhlIGNhc2UuIEFzIHlvdSBoYXZlIHNlZW4gKGFuZCBzdGlsbCBz ZWVpbmcpIHNlY3VyaW5nIEJHUCBVUERBVEUgTVNHIGlzIE1QX1JFQUNIIGNvbnRlbnQgZGVwZW5k ZW50LiBJZiBjb250ZW50IGlzIGZyZWUgZm9ybSBJIGFtIGFmcmFpZCBpdCB3aWxsIGJlIHJhdGhl ciBoYXJkIHRvIHNlY3VyZSBpdCB3ZWxsIDopDQoNCi0gTGFzdCBhcyBvcGFxdWUgdmFsdWUgY29u dGFpbmVyIHlvdSBhcmUgZGVmaW5pbmcgYW4gdHJhbnNpdGl2ZSBhdHRyaWJ1dGUgPyBJcyB0aGUg aW50ZW50aW9uIHRvIHVzZSB0aGlzIGF0dHJpYnV0ZSBpbiBleGlzdGluZyBBRkkvU0FGSXMgYXMg d2VsbCA/IE90aGVyd2lzZSBpZiBub3Qgd2h5IGRvIHlvdSBuZWVkIHRoaXMgdG8gYmUgdHJhbnNp dGl2ZSBpZiBjYXBhYmlsaXR5IG5lZ290aWF0aW9uIGFscmVhZHkgbWF5IGltcGxpY2l0bHkgZGVm aW5lIGl0J3Mgc3VwcG9ydCBieSBuZXcgQUZJL1NBRkkuDQoNCkNoZWVycywNClIuDQoNClBTLg0K DQo+IFRoZXJlIGlzIGFuIG9uZ29pbmcgZGlzY3Vzc2lvbiBhcm91bmQgYXZvaWRpbmcgTkxSSSAo a2V5KSBjb2xsaXNpb25zLg0KDQpXaGVyZSBpcyBzdWNoIGRpc2N1c3Npb24gdGFraW5nIHBsYWNl ID8gU2hvdWxkbid0IElEUiBiZSBwZXJoYXBzIGluIHRoZSBsb29wIGEgYml0IDopDQoNCg0KDQoN Cg0K --_000_3F437107848A5140A6A19222EFFB3481200E2A32PRNMBX012TheFac_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgZGlyPSJsdHIiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUi IGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8c3R5bGUgdHlwZT0idGV4dC9j c3MiIGlkPSJvd2FQYXJhU3R5bGUiPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBmcHN0eWxlPSIx IiBvY3NpPSIwIj4NCjxkaXYgc3R5bGU9ImRpcmVjdGlvbjogbHRyO2ZvbnQtZmFtaWx5OiBUYWhv bWE7Y29sb3I6ICMwMDAwMDA7Zm9udC1zaXplOiAxMHB0OyI+Jmd0OyZuYnNwOzxzcGFuIHN0eWxl PSJmb250LWZhbWlseTogYXJpYWwsIGhlbHZldGljYSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiBz bWFsbDsiPkluIGZhY3QgSSBhbSBub3QgY29udmluY2VkIHAybXAgaXMgdGhlIGJlc3Qgd2F5IHRv IGdvIHdpdGggaGVyZS4mbmJzcDs8L3NwYW4+DQo8ZGl2PjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTogYXJpYWwsIGhlbHZldGljYSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiBzbWFsbDsiPiZndDsg UHViLXN1YiB3aXRob3V0IFJUQyBoYWNrcyBtYXkgYmUgbXVjaCBiZXR0ZXIgLSBkb24ndCB5b3Ug aG9uZXN0bHkgdGhpbmsgPyZuYnNwOzwvc3Bhbj48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iYXJp YWwsIGhlbHZldGljYSwgc2Fucy1zZXJpZiIgc2l6ZT0iMiI+PGJyPg0KPC9mb250PjwvZGl2Pg0K PGRpdj48Zm9udCBmYWNlPSJhcmlhbCwgaGVsdmV0aWNhLCBzYW5zLXNlcmlmIiBzaXplPSIyIj5O b3QgZXhhY3RseSwgYnV0IG1heWJlIEkgbWlzdW5kZXJzdG9vZCB3aGF0IHAybXAgbWVhbnMgOikg VGhlIG1haW4gYWR2YW50YWdlIG9mIHVzaW5nIEJHUCAoYXQgbGVhc3QgaW4gb3VyIGVudmlyb25t ZW50KSBjb21lcyBmcm9tIHRoZSBmYWN0IHRoYXQgaXQncyBhbHJlYWR5IGJvb3RzdHJhcHBlZCB3 aGVuIG9uLXN3aXRjaCAob3Igb24tc2VydmVyKQ0KIGFwcGxpY2F0aW9ucyBzdGFydCBjb21pbmcg dXAuIEFuZCBpdCBzdGF5cyB0aGVyZSBldmVuIHdoZW4gdGhlIHNlcnZlcnMgaG9zdGluZyBleHRl cm5hbCBrZXktdmFsdWUgc3RvcmUgbWF5IGJlIGdvbmUuJm5ic3A7PC9mb250PjwvZGl2Pg0KPGRp dj48Zm9udCBmYWNlPSJhcmlhbCwgaGVsdmV0aWNhLCBzYW5zLXNlcmlmIiBzaXplPSIyIj48YnI+ DQo8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9ImFyaWFsLCBoZWx2ZXRpY2EsIHNhbnMt c2VyaWYiIHNpemU9IjIiPkFzaWRlIGZyb20gdGhpcywgSSBmdWxseSBhZ3JlZSAtIGl0IGRvZXMg bm90IG9mZmVyIG11Y2ggbW9yZSB0aGFuIGFueSBrZXktdmFsdWUgc3RvcmUuIEFuZCBpdCBoYXMg aXRzIG93biBjb25zdHJhaW50cywgbGlrZSB+NEsgdmFsdWUgc2l6ZS4gUGx1cywgaXQncyBub3Qg ZXZlbiBhIHByb3BlciBwdWItc3ViLCBzaW5jZSB0aGVyZSBpcyBubyBkaXNjcmVldA0KIG1lc3Nh Z2Ugc2VtYW50aWMgLSBvbmx5IHN0YXRlIGRpc3NlbWluYXRpb24gOik8L2ZvbnQ+PC9kaXY+DQo8 ZGl2Pjxmb250IGZhY2U9ImFyaWFsLCBoZWx2ZXRpY2EsIHNhbnMtc2VyaWYiIHNpemU9IjIiPjxi cj4NCjwvZm9udD4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBUaW1lcyBOZXcgUm9tYW47IGNv bG9yOiAjMDAwMDAwOyBmb250LXNpemU6IDE2cHgiPg0KPGhyIHRhYmluZGV4PSItMSI+DQo8ZGl2 IGlkPSJkaXZScEY1NzcwODIiIHN0eWxlPSJkaXJlY3Rpb246IGx0cjsiPjxmb250IGZhY2U9IlRh aG9tYSIgc2l6ZT0iMiIgY29sb3I9IiMwMDAwMDAiPjxiPkZyb206PC9iPiBycmFzenVrQGdtYWls LmNvbSBbcnJhc3p1a0BnbWFpbC5jb21dIG9uIGJlaGFsZiBvZiBSb2JlcnQgUmFzenVrIFtyb2Jl cnRAcmFzenVrLm5ldF08YnI+DQo8Yj5TZW50OjwvYj4gU2F0dXJkYXksIE1hcmNoIDEyLCAyMDE2 IDU6MjUgUE08YnI+DQo8Yj5Ubzo8L2I+IFBldHIgTGFwdWtob3Y8YnI+DQo8Yj5DYzo8L2I+IGV4 YUBqdW5pcGVyLm5ldDsgaWRyIHdnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBVc2Ugb2YgQkdQ IGZvciBPcGFxdWUgU2lnbmFsaW5nPGJyPg0KPC9mb250Pjxicj4NCjwvZGl2Pg0KPGRpdj48L2Rp dj4NCjxkaXY+DQo8ZGl2IGRpcj0ibHRyIj4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj4NCjxk aXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxl PSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjsgZm9udC1zaXplOnNtYWxs Ij4NCuKAi0hlbGxvIFBldHIs4oCLPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGJsb2NrcXVv dGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4IDAuOGV4OyBi b3JkZXItbGVmdC13aWR0aDoxcHg7IGJvcmRlci1sZWZ0LWNvbG9yOnJnYigyMDQsMjA0LDIwNCk7 IGJvcmRlci1sZWZ0LXN0eWxlOnNvbGlkOyBwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxkaXYgc3R5bGU9 ImRpcmVjdGlvbjpsdHI7IGZvbnQtZmFtaWx5OlRhaG9tYTsgY29sb3I6IzAwMDAwMDsgZm9udC1z aXplOjEwcHQiPg0KPGRpdj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwcHQiPlJlOiBJbXBhY3Qg b24gcm91dGluZy4gSSBzaG91bGQgYmUgbW9yZSBleHBsaWNpdCBzdGF0aW5nIHRoYXQgdGhlIGlk ZWEgaXMgZm9yIEJHUCB0byBub3QgaW50ZXJwcmV0IHRoZSBrZXktdmFsdWUgbWFwcGluZ3MgaW4g YW55IHdheS4NCjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnI+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1m YW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTpzbWFsbCI+DQrigItU aGF0IHdhcyB2ZXJ5IGNsZWFyIGFscmVhZHkuIEJ1dCBpZiB5b3UgbG9vayBhdCBudW1iZXIgb2Yg QkdQIGltcGxlbWVudGF0aW9ucyByZWNvZ25pemluZyB0aGUgQUZJL1NBRkkgY29taW5nIG92ZXIg c2luZ2xlIHNlc3Npb24gaXMgbm90IGRvbmUgaW1tZWRpYXRlbHkgaW4gdGhlIEJHUCBtZXNzYWdl IHBhcnNpbmcuIFRoYXQgaXMgbXkgbWFpbiBwb2ludCBzdWdnZXN0aW5nIHRyYW5zcG9ydCBpbnN0 YW5jZSBwb3J0LiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9 ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmOyBmb250LXNpemU6c21hbGwi Pg0KPGJyPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1m YW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTpzbWFsbCI+DQpJIG5v IGxvbmdlciBiZWxpZXZlIG11bHRpc2Vzc2lvbnMgd2lsbCBkbyBpdCBuZWl0aGVyIHRoYXQgd2Ug Y291bGQgb2ZmIGxvYWQgaXQgYXMgaW1wbGVtZW50YXRpb24gc3BlY2lmaWMgdGhpbmcu4oCLPC9k aXY+DQo8YnI+DQo8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8YmxvY2txdW90ZSBjbGFzcz0i Z21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MHB4IDBweCAwcHggMC44ZXg7IGJvcmRlci1sZWZ0 LXdpZHRoOjFweDsgYm9yZGVyLWxlZnQtY29sb3I6cmdiKDIwNCwyMDQsMjA0KTsgYm9yZGVyLWxl ZnQtc3R5bGU6c29saWQ7IHBhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBzdHlsZT0iZGlyZWN0aW9u Omx0cjsgZm9udC1mYW1pbHk6VGFob21hOyBjb2xvcjojMDAwMDAwOyBmb250LXNpemU6MTBwdCI+ DQo8ZGl2PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTBwdCI+VGhlIGNvbnN1bWVyIChydW5uaW5n IG9uIHNhbWUgZGV2aWNlLCBwb3NzaWJseSkgbWF5IHN0aWxsIGluZmx1ZW5jZSByb3V0aW5nIGJh c2VkIG9uIGl0cyBpbnRlcnByZXRhdGlvbiBvZiBkYXRhLCBlaXRoZXIgYnkgYWNjZXNzaW5nIHRo ZSBwbGF0Zm9ybSBTREsgb3IgYnkgcGVyZm9ybWluZyBCR1Agcm91dGluZyBpbmplY3Rpb24gb3Zl ciB0aGUgY29ycmVzcG9uZGluZyBBRkkvU0FGSS48L3NwYW4+PGJyPg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBjbGFzcz0iZ21h aWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlm OyBmb250LXNpemU6c21hbGwiPg0K4oCLVGhhdCBpcyBleGFjdGx5IHRoZSBpc3N1ZS4gVGhlIG9u bHkgd2F5IEJHUC1MUyB3ZW50IGJ5IHdhcyB0aGUgY2xhaW0gYWJvdXQgdGhlaXIgZXhwbGljaXQg ZGlzam9pbnRlZCB0b3BvbG9neSBmcm9tIGV4aXN0aW5nIEJHUC4gSXQgd2FzIHdlbGwgcG9zaXRp b25lZCB0aGF0IEJHUC1MUyBjYW4gYmUgY29tcGxldGVseSBpbmNvbmdydWVudCB3aXRoICZxdW90 O3JvdXRpbmcmcXVvdDsgQkdQLiDigIs8L2Rpdj4NCjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYg Y2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Es c2Fucy1zZXJpZjsgZm9udC1zaXplOnNtYWxsIj4NCuKAi1RoZSBwb3NzaWJsZSBjaGFubmVscyB0 aGUgSUdQIGluZm9ybWF0aW9uIG1heSBpbXBhY3Qgcm91dGluZyB3ZXJlIGNsYXNzaWZpZWQgYXMg b3V0IG9mIHRoZSBiYW5kIGxpa2VseSBjb21pbmcgdmlhIHNvbWUgb3RoZXIgd2F5cyBmcm9tIGNv bnRyb2xsZXJzIChJMlJTLCBBUElzLCByb3V0aW5nIEJHUCBTQUZJIGV0YyAuLi4pLiZuYnNwOzwv ZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFs LGhlbHZldGljYSxzYW5zLXNlcmlmOyBmb250LXNpemU6c21hbGwiPg0KPGJyPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUi IHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDsgYm9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7IHBh ZGRpbmctbGVmdDoxZXgiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImRpcmVjdGlvbjpsdHI7IGZvbnQt ZmFtaWx5OlRhaG9tYTsgY29sb3I6IzAwMDAwMDsgZm9udC1zaXplOjEwcHQiPg0KPGRpdj48L2Rp dj4NCjxkaXY+UmU6IFRyYW5zcG9ydCBpbnN0YW5jZS4gSSB0aGluayBpdCdzIGEgZ3JlYXQgaWRl YSB0byBydW4gdGhpcyBvbiBzZXBhcmF0ZSBpbnN0YW5jZSwgYnV0IHJpZ2h0IG5vdyB3ZSB0eXBp Y2FsbHkgcnVuIGp1c3Qgb25lIHByb2Nlc3MsIGFuZCBpdCBhZGRzIHNvbWUgb3BlcmF0aW9uYWwg b3ZlcmhlYWQgdG8gbWFpbnRhaW4gdHdvIG9mIHRoZW0uIEFsc28sIG9mdGVuIHRoaXMgZXh0ZW5z aW9uIGNvdWxkIGJlIHVzZWQganVzdCB3aXRoIG91dC1vZi1iYW5kDQogcmVmbGVjdGlvbi4gVGhp cyBpcyB3aHkgSSBmZWVsIGl0IGlzIHJhdGhlciBiZXR0ZXIgdG8ga2VlcCB0aGlzIGFwcGxpY2Fi bGUgdG8gYW55IHR5cGUgb2YgQkdQIGluc3RhbmNlLjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2 ZXRpY2Esc2Fucy1zZXJpZjsgZm9udC1zaXplOnNtYWxsIj4NCuKAi0ltYWdpbmUgdGhhdCB5b3Ug d2lsbCBub3QgZ2V0IGZhciBpbiB0aGlzIEJHUCBwcm9wb3NhbC4gVGhlbiB3aGF0IGlzIGxlZnQg aXMgbm90aGluZyBlbHNlIGxpa2UgYSBuZXcgcHJvY2VzcyB0YWxraW5nIG92ZXIgb25lIG9mIGZl dyBtZXNzYWdlIGJ1c2VzIHRvZGF5IHRvIGRpc3RyaWJ1dGUgdGhlIHNldCBvZiBpbmZvcm1hdGlv biB5b3UgbmVlZC4mbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxl PSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjsgZm9udC1zaXplOnNtYWxs Ij4NCjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQt ZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmOyBmb250LXNpemU6c21hbGwiPg0KSW4g ZmFjdCBJIGFtIG5vdCBjb252aW5jZWQgcDJtcCBpcyB0aGUgYmVzdCB3YXkgdG8gZ28gd2l0aCBo ZXJlLiBQdWItc3ViIHdpdGhvdXQgUlRDIGhhY2tzIG1heSBiZSBtdWNoIGJldHRlciAtIGRvbid0 IHlvdSBob25lc3RseSB0aGluayA/Jm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZh dWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7IGZvbnQt c2l6ZTpzbWFsbCI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0 eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjsgZm9udC1zaXplOnNt YWxsIj4NCkJlc3QsPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9u dC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTpzbWFsbCI+DQpS LuKAizwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4N CjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4 OyBib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDsgcGFkZGluZy1sZWZ0OjFleCI+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0iZGlyZWN0aW9uOmx0cjsgZm9udC1mYW1pbHk6VGFob21hOyBjb2xvcjojMDAw MDAwOyBmb250LXNpemU6MTBwdCI+DQo8ZGl2PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTBwdCI+ UmU6IFNjb3BlIG9mIGFwcGxpY2F0aW9uLiBUaGUgbWFpbiBnb2FsIHdhcyB0byB1c2UgdGhpcyBp biBkYXRhLWNlbnRlciwgYnV0IEkgY2FuIHRoZW9yaXplIHRoaXMgY291bGQgYmUgdXNlZCBhbW9u ZyBmZXcgb3BlcmF0b3JzIHRoYXQgYXJlIHdpbGxpbmcgdG8gZGV2ZWxvcCBvbi1kZXZpY2UgYXBw bGljYXRpb25zIGFuZCBleGNoYW5nZSBkYXRhIHVzaW5nIHRoZSBwcmUtZXN0YWJsaXNoZWQNCiBj aGFubmVscyAoZS5nLiB0aGUgV0lTRVIgdXNlIGNhc2UpLiBJbiB0aGlzIHNpdHVhdGlvbiwgbGlt aXRpbmcgc2NvcGUgdG8ganVzdCBwcml2YXRlIEFTTnMgY291bGQgYmUgdHJpY2t5LiBGdXJ0aGVy bW9yZSwgbm9uLXByaXZhdGUgQVNOcyBjb3VsZCBiZSB1c2VkIGluIGRhdGEtY2VudGVyIGFzIHdl bGwgKGp1c3Qgbm90IGV4cG9zZWQgb3V0c2lkZS4uLikuPC9zcGFuPjxicj4NCjwvZGl2Pg0KPGRp dj48YnI+DQo8L2Rpdj4NCjxkaXY+UmU6IFRyYW5zaXRpdmUgYXR0cmlidXRlLiBJZGVhbGx5LCBp dCB3b3VsZCBiZSBncmVhdCB0byBjYXJyeSB0aGUgdmFsdWUgaW4gbmV4dC1ob3AgZmllbGQgb2Yg TVBfUkVBQ0hfTkxSSSwgYnV0IHRoZSBsZW5ndGggaXMgbGltaXRlZCB0byA4IGJ5dGVzLCBoZW5j ZSB0aGUgbmV3IGF0dHJpYnV0ZS4gSSBkbyBub3QgaGF2ZSBzdHJvbmcgYXJndW1lbnRzIHRvIG1h a2luZyB0aGlzIHRyYW5zaXRpdmUsIGl0IHNob3VsZCBiZSBmaW5lIHRvIGdvDQogd2l0aCBub24t dHJhbnNpdGl2ZSBhbmQgY29ycmVzcG9uZGluZyBlcnJvciBoYW5kbGluZy4mbmJzcDs8L2Rpdj4N CjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlJlOiBTZWN1cml0eS4gU2luY2Ugd2UgZG8gbm90IGRp cmVjdGx5IGluZmx1ZW5jZSBwYXRoIHNlbGVjdGlvbiB3aXRoIG5ldyBkYXRhLCB0aGUgdGhyZWF0 cyBjb3VsZCBiZSBsaW1pdGVkIHRvIHRob3NlIHRhcmdldGluZyBCR1BpbmZyYSBpdHNlbGYgZS5n LiBmbG9vZGluZyB3aXRoIGluZm9ybWF0aW9uLCBkaXNydXB0aW5nIHNlc3Npb24gZXRjLiBUaGVy ZSBjb3VsZCBiZSBxdWVzdGlvbnMgYWJvdXQgaW5mb3JtYXRpb24gYXV0aGVudGljaXR5LA0KIGJ1 dCB0aGlzIGNvdWxkIGJlIGxlZnQgdXAgdG8gdGhlIGFwcGxpY2F0aW9ucyB0byBkZWNpZGUgKGUu Zy4gc2lnbmluZyB0aGUga2V5LXZhbHVlIGJpbmRpbmdzKS48L2Rpdj4NCjxkaXY+PGJyPg0KPC9k aXY+DQo8ZGl2PlJlZ2FyZHMsPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5QZXRyPC9k aXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OlRp bWVzIE5ldyBSb21hbjsgY29sb3I6IzAwMDAwMDsgZm9udC1zaXplOjE2cHgiPg0KPGhyPg0KPGRp diBzdHlsZT0iZGlyZWN0aW9uOmx0ciI+PGZvbnQgZmFjZT0iVGFob21hIiBzaXplPSIyIiBjb2xv cj0iIzAwMDAwMCI+PGI+RnJvbTo8L2I+DQo8YSBocmVmPSJtYWlsdG86cnJhc3p1a0BnbWFpbC5j b20iIHRhcmdldD0iX2JsYW5rIj5ycmFzenVrQGdtYWlsLmNvbTwvYT4gWzxhIGhyZWY9Im1haWx0 bzpycmFzenVrQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnJyYXN6dWtAZ21haWwuY29tPC9h Pl0gb24gYmVoYWxmIG9mIFJvYmVydCBSYXN6dWsgWzxhIGhyZWY9Im1haWx0bzpyb2JlcnRAcmFz enVrLm5ldCIgdGFyZ2V0PSJfYmxhbmsiPnJvYmVydEByYXN6dWsubmV0PC9hPl08YnI+DQo8Yj5T ZW50OjwvYj4gU2F0dXJkYXksIE1hcmNoIDEyLCAyMDE2IDE6MTAgUE08YnI+DQo8Yj5Ubzo8L2I+ IFBldHIgTGFwdWtob3Y7IDxhIGhyZWY9Im1haWx0bzpleGFAanVuaXBlci5uZXQiIHRhcmdldD0i X2JsYW5rIj5leGFAanVuaXBlci5uZXQ8L2E+PGJyPg0KPGI+Q2M6PC9iPiBpZHIgd2c8YnI+DQo8 Yj5TdWJqZWN0OjwvYj4gVXNlIG9mIEJHUCBmb3IgT3BhcXVlIFNpZ25hbGluZzxicj4NCjwvZm9u dD48YnI+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IGNsYXNzPSJoNSI+DQo8ZGl2PjwvZGl2Pg0KPGRp dj4NCjxkaXYgZGlyPSJsdHIiPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0 aWNhLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTpzbWFsbCI+4oCLUGV0ciwgRWJlbiw8L2Rpdj4NCjxk aXYgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmOyBmb250LXNp emU6c21hbGwiPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVs dmV0aWNhLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTpzbWFsbCI+SSBoYXZlIGZldyBxdWVzdGlvbnMg YW5kIGNvbW1lbnRzIHRvIHlvdXIgcHJvcG9zYWwuJm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxlPSJm b250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjsgZm9udC1zaXplOnNtYWxsIj48 YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5z LXNlcmlmOyBmb250LXNpemU6c21hbGwiPi0gVGhlIGRyYWZ0IOKAi2F0dGVtcHRzIHRvIHJldXNl IEJHUCBtZWNoYW5pc20gZm9yIHAybXAgZGlzdHJpYnV0aW9uIG9mIG9wYXF1ZSBpbmZvcm1hdGlv bi4gVGhhdCBhbG9uZSBpcyBub3QgYSBiYWQgdGhpbmcgOikgSG93ZXZlciB3aGVuIHlvdSBtYWtl IHJlZmVyZW5jZSB0byBCR1AtTFMgaXQgbmVlZHMgdG8gYmUgb2JzZXJ2ZWQNCiB0aGF0IEJHUC1M UyBpcyBub3QgcG9zaXRpb24gdG8gZGlyZWN0bHkgaW1wYWN0IHJvdXRpbmcgKGllIGNvbnRlbnQg b2YgUklCIGFuZCBGSUJzKSB1bmxpa2Ugb25lIG9mIHRoZSB1c2UgY2FzZXMgZGVzY3JpYmVkIGlu IHlvdXIgZHJhZnQgSW50cm8gcGFyYWdyYXBoLiBUaGF0IG1lYW5zIHRoYXQgdW5saWtlIEJHUC1M UyBpdCBtdXN0IGNvLWV4aXN0IHdpdGggcm91dGluZyBCR1Agb24gdGhlIHNhbWUgQkdQIHNwZWFr ZXJzLiZuYnNwOzwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNh LHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTpzbWFsbCI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJm b250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjsgZm9udC1zaXplOnNtYWxsIj5I ZXJlIEkgd291bGQgbGlrZSB0byBicmluZyBiYWNrIG15IHByb3Bvc2FsIHRvIGRlZmluZSBuZXcg cG9ydCBmb3IgVHJhbnNwb3J0IEluc3RhbmNlIEJHUCZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdXJs ZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fdG9vbHMuaWV0Zi5vcmdf aHRtbF9kcmFmdC0yRHJhc3p1ay0yRHRpLTJEYmdwLTJEMDEmYW1wO2Q9Q3dNRmFRJmFtcDtjPTVW RDBSVHRObFRoM3ljZDQxYjNNVXcmYW1wO3I9TFVfdkphTV9FUXUxU3NtMzVqMnhsQSZhbXA7bT03 NVEtbnZYMlJoaHhZbS1yMkJJeEZodElwS3pUOXBFZ0d4OVVXanE2ZlQ0JmFtcDtzPWtLNzFlU3FX QklUYWxHMVkxaU5XYWlIYVNBN3ZyTU1uTDRsa2llYXEydVkmYW1wO2U9IiB0YXJnZXQ9Il9ibGFu ayI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXJhc3p1ay10aS1iZ3AtMDE8L2E+ DQogd2hpY2ggYXQgdGhlIHRpbWUgb2YgZGlzY3Vzc2lvbiB3YXMgc3VwcG9zZWQgdG8gYmUgc2hv cnRseSBhZGRyZXNzZWQgYnkgZHluYW1pYyBwb3J0IGFsbG9jYXRpb25zIG9mIG11bHRpc2Vzc2lv bnMgd2hpY2ggdG8gdGhlIGJlc3Qgb2YgbXkga25vd2xlZGdlIG5ldmVyIGhhcHBlbmVkLiZuYnNw OzwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2Vy aWY7IGZvbnQtc2l6ZTpzbWFsbCI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWls eTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjsgZm9udC1zaXplOnNtYWxsIj5TbyBmaXJzdCBj b21tZW50IGlzIHRoYXQgaWYgd2UgZ28gd2l0aCByZXVzaW5nIEJHUC00IGZvciB0aGlzIHR5cGUg b2Ygc2lnbmFsbGluZyBsZXQncyBlbmZvcmNlIGl0J3MgZWFybHkgc2VwYXJhdGlvbiBmcm9tICZx dW90O2NsYXNzaWMmcXVvdDsgQkdQLiZuYnNwOzwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1p bHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTpzbWFsbCI+PGJyPg0KPC9k aXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjsg Zm9udC1zaXplOnNtYWxsIj4tIFNlY29uZCBjb21tZW50IGlzIHJlbGF0ZWQgdG8gdGhlIHNjb3Bl IG9mIHVzZS4gSWYgdGhlIHNjb3BlIGlzIHByaXZhdGUgLSBsZXQncyBwZXJoYXBzIGVuZm9yY2Ug aXQgbW9yZSBleHBsaWNpdGx5IHN1Y2ggdGhhdCBieSB0aGUgc3BlYyBpdCBpcyBpbGxlZ2FsIEFG SS9TQUZJIHBhaXIgaW4gdGhlIHB1YmxpYyBJbnRlcm5ldC4NCiBGb3IgZXhhbXBsZSBieSBzdGF0 aW5nIHRoYXQgaXQgaXMgaWxsZWdhbCB0byBoYXZlIG5vbiBwcml2YXRlIEFTIGluIHRoZSBBU19Q QVRIIG9mIHN1Y2ggVVBEQVRFIG1zZy4mbmJzcDs8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFt aWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmOyBmb250LXNpemU6c21hbGwiPjxicj4NCjwv ZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7 IGZvbnQtc2l6ZTpzbWFsbCI+LSBUaGlyZCB0aGUgZHJhZnQgc3RhdGVzIHRoYXQgdGhlcmUgaXMg bm8gbmV3IHNlY3VyaXR5IGltcGxpY2F0aW9ucyAuLiB3ZWxsIGlmIHRoZSBzY29wZSBpcyBub24g cHJpdmF0ZSBJIGFtIGFmcmFpZCB0aGF0IGlzIG5vIHRoZSBjYXNlLiBBcyB5b3UgaGF2ZSBzZWVu IChhbmQgc3RpbGwgc2VlaW5nKSBzZWN1cmluZyBCR1AgVVBEQVRFDQogTVNHIGlzIE1QX1JFQUNI IGNvbnRlbnQgZGVwZW5kZW50LiBJZiBjb250ZW50IGlzIGZyZWUgZm9ybSBJIGFtIGFmcmFpZCBp dCB3aWxsIGJlIHJhdGhlciBoYXJkIHRvIHNlY3VyZSBpdCB3ZWxsIDopJm5ic3A7PC9kaXY+DQo8 ZGl2IHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjsgZm9udC1z aXplOnNtYWxsIj48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhl bHZldGljYSxzYW5zLXNlcmlmOyBmb250LXNpemU6c21hbGwiPi0gTGFzdCBhcyBvcGFxdWUgdmFs dWUgY29udGFpbmVyIHlvdSBhcmUgZGVmaW5pbmcgYW4gdHJhbnNpdGl2ZSBhdHRyaWJ1dGUgPyBJ cyB0aGUgaW50ZW50aW9uIHRvIHVzZSB0aGlzIGF0dHJpYnV0ZSBpbiBleGlzdGluZyBBRkkvU0FG SXMgYXMgd2VsbCA/IE90aGVyd2lzZSBpZiBub3Qgd2h5IGRvIHlvdSBuZWVkIHRoaXMgdG8NCiBi ZSB0cmFuc2l0aXZlIGlmIGNhcGFiaWxpdHkgbmVnb3RpYXRpb24gYWxyZWFkeSBtYXkgaW1wbGlj aXRseSBkZWZpbmUgaXQncyBzdXBwb3J0IGJ5IG5ldyBBRkkvU0FGSS48L2Rpdj4NCjxkaXYgc3R5 bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmOyBmb250LXNpemU6c21h bGwiPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNh LHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTpzbWFsbCI+Q2hlZXJzLDxicj4NClIuPC9kaXY+DQo8ZGl2 IHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjsgZm9udC1zaXpl OnNtYWxsIj48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZl dGljYSxzYW5zLXNlcmlmOyBmb250LXNpemU6c21hbGwiPlBTLiZuYnNwOzwvZGl2Pg0KPGRpdiBz dHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTpz bWFsbCI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRp Y2Esc2Fucy1zZXJpZjsgZm9udC1zaXplOnNtYWxsIj48c3BhbiBzdHlsZT0iY29sb3I6cmdiKDAs MCwwKTsgZm9udC1mYW1pbHk6VGFob21hOyBmb250LXNpemU6MTMuMzMzM3B4Ij4mZ3Q7IFRoZXJl IGlzIGFuIG9uZ29pbmcgZGlzY3Vzc2lvbiBhcm91bmQgYXZvaWRpbmcgTkxSSSAoa2V5KSBjb2xs aXNpb25zLjwvc3Bhbj48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFs LGhlbHZldGljYSxzYW5zLXNlcmlmOyBmb250LXNpemU6c21hbGwiPjxzcGFuIHN0eWxlPSJjb2xv cjpyZ2IoMCwwLDApOyBmb250LWZhbWlseTpUYWhvbWE7IGZvbnQtc2l6ZToxMy4zMzMzcHgiPjxi cj4NCjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGlj YSxzYW5zLXNlcmlmOyBmb250LXNpemU6c21hbGwiPjxzcGFuIHN0eWxlPSJjb2xvcjpyZ2IoMCww LDApOyBmb250LWZhbWlseTpUYWhvbWE7IGZvbnQtc2l6ZToxMy4zMzMzcHgiPldoZXJlIGlzIHN1 Y2ggZGlzY3Vzc2lvbiB0YWtpbmcgcGxhY2UgPyBTaG91bGRuJ3QgSURSIGJlIHBlcmhhcHMgaW4g dGhlIGxvb3AgYSBiaXQgOikmbmJzcDs8L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZh bWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjsgZm9udC1zaXplOnNtYWxsIj48c3BhbiBz dHlsZT0iY29sb3I6cmdiKDAsMCwwKTsgZm9udC1mYW1pbHk6VGFob21hOyBmb250LXNpemU6MTMu MzMzM3B4Ij48YnI+DQo8L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTphcmlh bCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjsgZm9udC1zaXplOnNtYWxsIj48c3BhbiBzdHlsZT0iY29s b3I6cmdiKDAsMCwwKTsgZm9udC1mYW1pbHk6VGFob21hOyBmb250LXNpemU6MTMuMzMzM3B4Ij48 YnI+DQo8L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRp Y2Esc2Fucy1zZXJpZjsgZm9udC1zaXplOnNtYWxsIj48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9 ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmOyBmb250LXNpemU6c21hbGwi PiZuYnNwOzwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_3F437107848A5140A6A19222EFFB3481200E2A32PRNMBX012TheFac_-- From nobody Sun Mar 13 01:11:57 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44AA012D535 for ; Sun, 13 Mar 2016 01:11:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.612 X-Spam-Level: X-Spam-Status: No, score=-0.612 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 eUVgf96N0w-w for ; Sun, 13 Mar 2016 01:11:52 -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 5540F12D533 for ; Sun, 13 Mar 2016 01:11:52 -0800 (PST) Received: from [10.214.90.112] (242.82-131-109.adsl-dyn.isp.belgacom.be [109.131.82.242]) by st13p11im-asmtp004.me.com (Oracle Communications Messaging Server 7.0.5.36.0 64bit (built Sep 8 2015)) with ESMTPSA id <0O3Z00HQ807OFM10@st13p11im-asmtp004.me.com> for idr@ietf.org; Sun, 13 Mar 2016 09:11:51 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-03-13_02:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1011 suspectscore=3 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1510270003 definitions=main-1603130136 Content-type: multipart/alternative; boundary="Apple-Mail=_0CE73F24-7B25-4DA1-8503-9659AAC7A4BA" MIME-version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Gunter Van De Velde In-reply-to: <3F437107848A5140A6A19222EFFB3481200E2A32@PRN-MBX01-2.TheFacebook.com> Date: Sun, 13 Mar 2016 10:11:48 +0100 Message-id: References: <3F437107848A5140A6A19222EFFB3481200E2839@PRN-MBX01-2.TheFacebook.com> <3F437107848A5140A6A19222EFFB3481200E2A32@PRN-MBX01-2.TheFacebook.com> To: Petr Lapukhov X-Mailer: Apple Mail (2.3112) Archived-At: Cc: idr wg , Robert Raszuk Subject: Re: [Idr] Use of BGP for Opaque Signaling X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2016 09:11:55 -0000 --Apple-Mail=_0CE73F24-7B25-4DA1-8503-9659AAC7A4BA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 imo the promise of a proposal like this one, is that it allows = Application development at DevOps speed and removes slowness of industry = bodies for innovation. I believe it is a valid problem space that is being addressed. Maybe = some features/optimisations from EVN could be transplanted? (i.e. = Designated router selection, aliasing and mass-withdraw) G/ > On 13 Mar 2016, at 04:20, Petr Lapukhov wrote: >=20 > > In fact I am not convinced p2mp is the best way to go with here.=20 > > Pub-sub without RTC hacks may be much better - don't you honestly = think ?=20 >=20 > Not exactly, but maybe I misunderstood what p2mp means :) The main = advantage of using BGP (at least in our environment) comes from the fact = that it's already bootstrapped when on-switch (or on-server) = applications start coming up. And it stays there even when the servers = hosting external key-value store may be gone.=20 >=20 > Aside from this, I fully agree - it does not offer much more than any = key-value store. And it has its own constraints, like ~4K value size. = Plus, it's not even a proper pub-sub, since there is no discreet message = semantic - only state dissemination :) >=20 > From: rraszuk@gmail.com [rraszuk@gmail.com = ] on behalf of Robert Raszuk = [robert@raszuk.net ] > Sent: Saturday, March 12, 2016 5:25 PM > To: Petr Lapukhov > Cc: exa@juniper.net ; idr wg > Subject: Re: Use of BGP for Opaque Signaling >=20 > =E2=80=8BHello Petr,=E2=80=8B > =20 > Re: Impact on routing. I should be more explicit stating that the idea = is for BGP to not interpret the key-value mappings in any way. >=20 > =E2=80=8BThat was very clear already. But if you look at number of BGP = implementations recognizing the AFI/SAFI coming over single session is = not done immediately in the BGP message parsing. That is my main point = suggesting transport instance port.=20 >=20 > I no longer believe multisessions will do it neither that we could off = load it as implementation specific thing.=E2=80=8B >=20 > =20 > The consumer (running on same device, possibly) may still influence = routing based on its interpretation of data, either by accessing the = platform SDK or by performing BGP routing injection over the = corresponding AFI/SAFI. >=20 > =E2=80=8BThat is exactly the issue. The only way BGP-LS went by was = the claim about their explicit disjointed topology from existing BGP. It = was well positioned that BGP-LS can be completely incongruent with = "routing" BGP. =E2=80=8B >=20 > =E2=80=8BThe possible channels the IGP information may impact routing = were classified as out of the band likely coming via some other ways = from controllers (I2RS, APIs, routing BGP SAFI etc ...).=20 >=20 > =20 > Re: Transport instance. I think it's a great idea to run this on = separate instance, but right now we typically run just one process, and = it adds some operational overhead to maintain two of them. Also, often = this extension could be used just with out-of-band reflection. This is = why I feel it is rather better to keep this applicable to any type of = BGP instance. >=20 >=20 > =E2=80=8BImagine that you will not get far in this BGP proposal. Then = what is left is nothing else like a new process talking over one of few = message buses today to distribute the set of information you need.=20 >=20 > In fact I am not convinced p2mp is the best way to go with here. = Pub-sub without RTC hacks may be much better - don't you honestly think = ?=20 >=20 > Best, > R.=E2=80=8B >=20 > =20 > Re: Scope of application. The main goal was to use this in = data-center, but I can theorize this could be used among few operators = that are willing to develop on-device applications and exchange data = using the pre-established channels (e.g. the WISER use case). In this = situation, limiting scope to just private ASNs could be tricky. = Furthermore, non-private ASNs could be used in data-center as well (just = not exposed outside...). >=20 > Re: Transitive attribute. Ideally, it would be great to carry the = value in next-hop field of MP_REACH_NLRI, but the length is limited to 8 = bytes, hence the new attribute. I do not have strong arguments to making = this transitive, it should be fine to go with non-transitive and = corresponding error handling.=20 >=20 > Re: Security. Since we do not directly influence path selection with = new data, the threats could be limited to those targeting BGPinfra = itself e.g. flooding with information, disrupting session etc. There = could be questions about information authenticity, but this could be = left up to the applications to decide (e.g. signing the key-value = bindings). >=20 > Regards, >=20 > Petr >=20 > From: rraszuk@gmail.com [rraszuk@gmail.com = ] on behalf of Robert Raszuk = [robert@raszuk.net ] > Sent: Saturday, March 12, 2016 1:10 PM > To: Petr Lapukhov; exa@juniper.net > Cc: idr wg > Subject: Use of BGP for Opaque Signaling >=20 > =E2=80=8BPetr, Eben, >=20 > I have few questions and comments to your proposal.=20 >=20 > - The draft =E2=80=8Battempts to reuse BGP mechanism for p2mp = distribution of opaque information. That alone is not a bad thing :) = However when you make reference to BGP-LS it needs to be observed that = BGP-LS is not position to directly impact routing (ie content of RIB and = FIBs) unlike one of the use cases described in your draft Intro = paragraph. That means that unlike BGP-LS it must co-exist with routing = BGP on the same BGP speakers.=20 >=20 > Here I would like to bring back my proposal to define new port for = Transport Instance BGP = https://tools.ietf.org/html/draft-raszuk-ti-bgp-01 = which at the time of = discussion was supposed to be shortly addressed by dynamic port = allocations of multisessions which to the best of my knowledge never = happened.=20 >=20 > So first comment is that if we go with reusing BGP-4 for this type of = signalling let's enforce it's early separation from "classic" BGP.=20 >=20 > - Second comment is related to the scope of use. If the scope is = private - let's perhaps enforce it more explicitly such that by the spec = it is illegal AFI/SAFI pair in the public Internet. For example by = stating that it is illegal to have non private AS in the AS_PATH of such = UPDATE msg.=20 >=20 > - Third the draft states that there is no new security implications .. = well if the scope is non private I am afraid that is no the case. As you = have seen (and still seeing) securing BGP UPDATE MSG is MP_REACH content = dependent. If content is free form I am afraid it will be rather hard to = secure it well :)=20 >=20 > - Last as opaque value container you are defining an transitive = attribute ? Is the intention to use this attribute in existing AFI/SAFIs = as well ? Otherwise if not why do you need this to be transitive if = capability negotiation already may implicitly define it's support by new = AFI/SAFI. >=20 > Cheers, > R. >=20 > PS.=20 >=20 > > There is an ongoing discussion around avoiding NLRI (key) = collisions. >=20 > Where is such discussion taking place ? Shouldn't IDR be perhaps in = the loop a bit :)=20 >=20 >=20 >=20 > =20 >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr --Apple-Mail=_0CE73F24-7B25-4DA1-8503-9659AAC7A4BA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
imo the promise of a proposal like this one, = is that it allows Application development at DevOps speed and removes = slowness of industry bodies for innovation.

I believe it is a valid problem space = that is being addressed. Maybe some features/optimisations from EVN = could be transplanted? (i.e. Designated router selection, aliasing and = mass-withdraw)

G/


On = 13 Mar 2016, at 04:20, Petr Lapukhov <petr@fb.com> wrote:

> In fact I am not convinced p2mp is the best way to go with = here. 
> Pub-sub = without RTC hacks may be much better - don't you honestly think = ? 

Not exactly, but maybe I misunderstood what p2mp means :) The = main advantage of using BGP (at least in our environment) comes from the = fact that it's already bootstrapped when on-switch (or on-server) = applications start coming up. And it stays there even when the servers = hosting external key-value store may be gone. 

Aside from = this, I fully agree - it does not offer much more than any key-value = store. And it has its own constraints, like ~4K value size. Plus, it's = not even a proper pub-sub, since there is no discreet message semantic - = only state dissemination :)

From: rraszuk@gmail.com [rraszuk@gmail.com] on = behalf of Robert Raszuk [robert@raszuk.net]
Sent: Saturday, March 12, 2016 = 5:25 PM
To: Petr Lapukhov
Cc: exa@juniper.net; idr = wg
Subject: Re: Use of BGP for Opaque = Signaling

=E2=80=8BHello Petr,=E2=80=8B
 
Re:= Impact on routing. I should be more explicit stating that the idea is = for BGP to not interpret the key-value mappings in any = way.

=E2=80=8BThat was very clear already. But if you look at number = of BGP implementations recognizing the AFI/SAFI coming over single = session is not done immediately in the BGP message parsing. That is my = main point suggesting transport instance port. 

I no longer believe multisessions will do = it neither that we could off load it as implementation specific = thing.=E2=80=8B

 
The= consumer (running on same device, possibly) may still influence routing = based on its interpretation of data, either by accessing the platform = SDK or by performing BGP routing injection over the corresponding = AFI/SAFI.

=E2=80=8BThat is exactly the issue. The = only way BGP-LS went by was the claim about their explicit disjointed = topology from existing BGP. It was well positioned that BGP-LS can be = completely incongruent with "routing" BGP. =E2=80=8B

=E2=80=8BThe possible channels the IGP information may impact = routing were classified as out of the band likely coming via some other = ways from controllers (I2RS, APIs, routing BGP SAFI etc = ...). 

 
Re: Transport instance. = I think it's a great idea to run this on separate instance, but right = now we typically run just one process, and it adds some operational = overhead to maintain two of them. Also, often this extension could be = used just with out-of-band reflection. This is why I feel it is rather = better to keep this applicable to any type of BGP = instance.


=E2=80=8BImagine that you will not get = far in this BGP proposal. Then what is left is nothing else like a new = process talking over one of few message buses today to distribute the = set of information you need. 

In fact I am not convinced p2mp is the best way to go with here. = Pub-sub without RTC hacks may be much better - don't you honestly think = ? 

Best,
R.=E2=80=8B

 
Re: Scope of application. The main goal was to use this in = data-center, but I can theorize this could be used among few operators = that are willing to develop on-device applications and exchange data = using the pre-established channels (e.g. the WISER use case). In this = situation, limiting scope to just private ASNs could be tricky. = Furthermore, non-private ASNs could be used in data-center as well (just = not exposed outside...).

Re: Transitive attribute. Ideally, it = would be great to carry the value in next-hop field of MP_REACH_NLRI, = but the length is limited to 8 bytes, hence the new attribute. I do not = have strong arguments to making this transitive, it should be fine to go = with non-transitive and corresponding error handling. 

Re: Security. Since we = do not directly influence path selection with new data, the threats = could be limited to those targeting BGPinfra itself e.g. flooding with = information, disrupting session etc. There could be questions about = information authenticity, but this could be left up to the applications = to decide (e.g. signing the key-value bindings).

Regards,

Petr

From: rraszuk@gmail.com [rraszuk@gmail.com] on behalf of Robert Raszuk [robert@raszuk.net]
Sent: Saturday, March 12, 2016 = 1:10 PM
To: Petr Lapukhov; exa@juniper.net
Cc: idr wg
Subject: Use of BGP for Opaque = Signaling

=E2=80=8BPetr, Eben,

I have few = questions and comments to your proposal. 

- The draft = =E2=80=8Battempts to reuse BGP mechanism for p2mp distribution of opaque = information. That alone is not a bad thing :) However when you make = reference to BGP-LS it needs to be observed that BGP-LS is not position = to directly impact routing (ie content of RIB and FIBs) unlike one of = the use cases described in your draft Intro paragraph. That means that = unlike BGP-LS it must co-exist with routing BGP on the same BGP = speakers. 

Here I would like to bring back my proposal to define new = port for Transport Instance BGP https://tools.ietf.org/html/draft-raszuk-ti-bgp-01 which at the time of = discussion was supposed to be shortly addressed by dynamic port = allocations of multisessions which to the best of my knowledge never = happened. 

So first comment is that if we go with reusing BGP-4 for this = type of signalling let's enforce it's early separation from "classic" = BGP. 

- Second comment is related to the scope of use. If the scope = is private - let's perhaps enforce it more explicitly such that by the = spec it is illegal AFI/SAFI pair in the public Internet. For example by = stating that it is illegal to have non private AS in the AS_PATH of such = UPDATE msg. 

- Third the draft states that there is no new security = implications .. well if the scope is non private I am afraid that is no = the case. As you have seen (and still seeing) securing BGP UPDATE MSG is = MP_REACH content dependent. If content is free form I am afraid it will = be rather hard to secure it well :) 

- Last as opaque value = container you are defining an transitive attribute ? Is the intention to = use this attribute in existing AFI/SAFIs as well ? Otherwise if not why = do you need this to be transitive if capability negotiation already may = implicitly define it's support by new AFI/SAFI.

Cheers,
R.

PS. 

> There is an ongoing discussion around avoiding NLRI = (key) collisions.

Where is such discussion = taking place ? Shouldn't IDR be perhaps in the loop a bit = :) 



 

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr
= --Apple-Mail=_0CE73F24-7B25-4DA1-8503-9659AAC7A4BA-- From nobody Sun Mar 13 07:59:55 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A15112D631 for ; Sun, 13 Mar 2016 07:59:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.36 X-Spam-Level: X-Spam-Status: No, score=-0.36 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 9OXN3P-Mv3Zo for ; Sun, 13 Mar 2016 07:59:50 -0700 (PDT) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::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 24E6C12D584 for ; Sun, 13 Mar 2016 07:59:50 -0700 (PDT) Received: by mail-lb0-x22f.google.com with SMTP id bc4so209381768lbc.2 for ; Sun, 13 Mar 2016 07:59:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=2ZM0nbY3joNGBRVfsZ5GLUhL7/F2p1HgWl9k2+Uhbko=; b=T+1VzHa0lUxw1A79lfHMK59ho3qVOoYpR0Jz7Ayzvk4A644V7tcdJ37oQMwCaUrnUY 3hM5ExuOcLRModMI7onjifPfSVyg4UcSTUqNmpNXeosogJa4H2upGBYhgqKNdM/A/Et2 iHvc1kuXq1xOq+rA1mCaNUgS1cZnaEqVevZN26D8YIzdrdz0AgoFpux4t7h/pH9J4qhi EF7YQqo/1s5qLsFKYYV2QQiQzsE1V0RSiWqIcrvvtZkwCaX0ui+33sXhN6kuiK69pIo4 KdSLdq5+q9YG3woPMwGrz6iDnnZdqpQQMQtf1YE5WuKTv7NxO5lIOknXnyo5ZxJDmy72 tcUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=2ZM0nbY3joNGBRVfsZ5GLUhL7/F2p1HgWl9k2+Uhbko=; b=jjjNN8Pf3W67ZtyUSAN/YertB7WVpUiW+v3hFL3bAu5DPy/ZSCEvX8z5KLzRCjcGvU Bdiqr4zqaJRW2DAQ1JX2lG0ZOoM5HCc5wGMJnb94rClqe/WhA5VRWISwK4IBL4Bs6Yae LyTV11KRU3H6l02n0DkOx/JHVpCAjCN2hGMy+bzXM/cGzsndqGAawwYTDDx2+dGOL/X+ Rf2XOUSKg6xWkQbVoWqBbYTOcGQeEB1CGf+7rDVaUclhZ/JGknziLbzXPmHTKuLp26YM QqlUSaNirkDbgOkJrWOsIHCLGX804XzEOse5KHbPRqpfrppPOrnbBJgXqhmXnif9e71s Mx5Q== X-Gm-Message-State: AD7BkJK/xEEy62N6rNQYV9L/wWrSpH6SHuOyUBTEHT8VW/AQkgSg4p/VMzWM1rjJHUh62NZr42UKs56CqVZX7A== MIME-Version: 1.0 X-Received: by 10.112.170.68 with SMTP id ak4mr4831745lbc.94.1457881188193; Sun, 13 Mar 2016 07:59:48 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.25.136.133 with HTTP; Sun, 13 Mar 2016 07:59:48 -0700 (PDT) In-Reply-To: References: <3F437107848A5140A6A19222EFFB3481200E2839@PRN-MBX01-2.TheFacebook.com> <3F437107848A5140A6A19222EFFB3481200E2A32@PRN-MBX01-2.TheFacebook.com> Date: Sun, 13 Mar 2016 10:59:48 -0400 X-Google-Sender-Auth: VFAGMSWe8ZuFit1Ku-ve_Hoc9v8 Message-ID: From: Robert Raszuk To: Gunter Van De Velde Content-Type: multipart/alternative; boundary=001a11c259a858e185052def6a38 Archived-At: Cc: idr wg Subject: Re: [Idr] Use of BGP for Opaque Signaling X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2016 14:59:54 -0000 --001a11c259a858e185052def6a38 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Gunter, For dissemination of information produced by network applications we already have today various tools be it ansible, chef, puppet etc ... If there is need to use inter-domain distribution of such applications I see no reason why not to define registered or private wide bgp community and use this as transport instead of new SAFI on already established BGP sessions. Note that wide BGP community precisely like new attribute being proposed here can carry opaque to BGP data. Hi Petr, Do you see any issue with the above wide community approach to address you needs ? Especially for bootstrapping the transport it is even easier as you do not need to enable new SAFI. And those are already IDR WG docs. https://tools.ietf.org/html/draft-ietf-idr-wide-bgp-communities-01 https://tools.ietf.org/html/draft-ietf-idr-registered-wide-bgp-communities-= 01 As far as limit of 4K let's all note that we already have a draft addressing this and moving the limit to 65K: https://tools.ietf.org/html/draft-ietf-idr-bgp-extended-messages-11 Cheers, r. On Sun, Mar 13, 2016 at 5:11 AM, Gunter Van De Velde < guntervandeveldecc@icloud.com> wrote: > imo the promise of a proposal like this one, is that it allows Applicatio= n > development at DevOps speed and removes slowness of industry bodies for > innovation. > > I believe it is a valid problem space that is being addressed. Maybe some > features/optimisations from EVN could be transplanted? (i.e. Designated > router selection, aliasing and mass-withdraw) > > G/ > > > On 13 Mar 2016, at 04:20, Petr Lapukhov wrote: > > > In fact I am not convinced p2mp is the best way to go with here. > > Pub-sub without RTC hacks may be much better - don't you honestly think > ? > > Not exactly, but maybe I misunderstood what p2mp means :) The main > advantage of using BGP (at least in our environment) comes from the fact > that it's already bootstrapped when on-switch (or on-server) applications > start coming up. And it stays there even when the servers hosting externa= l > key-value store may be gone. > > Aside from this, I fully agree - it does not offer much more than any > key-value store. And it has its own constraints, like ~4K value size. Plu= s, > it's not even a proper pub-sub, since there is no discreet message semant= ic > - only state dissemination :) > > ------------------------------ > *From:* rraszuk@gmail.com [rraszuk@gmail.com] on behalf of Robert Raszuk = [ > robert@raszuk.net] > *Sent:* Saturday, March 12, 2016 5:25 PM > *To:* Petr Lapukhov > *Cc:* exa@juniper.net; idr wg > *Subject:* Re: Use of BGP for Opaque Signaling > > =E2=80=8BHello Petr,=E2=80=8B > > >> Re: Impact on routing. I should be more explicit stating that the idea i= s >> for BGP to not interpret the key-value mappings in any way. >> > > =E2=80=8BThat was very clear already. But if you look at number of BGP > implementations recognizing the AFI/SAFI coming over single session is no= t > done immediately in the BGP message parsing. That is my main point > suggesting transport instance port. > > I no longer believe multisessions will do it neither that we could off > load it as implementation specific thing.=E2=80=8B > > > >> The consumer (running on same device, possibly) may still influence >> routing based on its interpretation of data, either by accessing the >> platform SDK or by performing BGP routing injection over the correspondi= ng >> AFI/SAFI. >> > > =E2=80=8BThat is exactly the issue. The only way BGP-LS went by was the c= laim > about their explicit disjointed topology from existing BGP. It was well > positioned that BGP-LS can be completely incongruent with "routing" BGP. = =E2=80=8B > > =E2=80=8BThe possible channels the IGP information may impact routing wer= e > classified as out of the band likely coming via some other ways from > controllers (I2RS, APIs, routing BGP SAFI etc ...). > > > >> Re: Transport instance. I think it's a great idea to run this on separat= e >> instance, but right now we typically run just one process, and it adds s= ome >> operational overhead to maintain two of them. Also, often this extension >> could be used just with out-of-band reflection. This is why I feel it is >> rather better to keep this applicable to any type of BGP instance. >> > > > =E2=80=8BImagine that you will not get far in this BGP proposal. Then wha= t is left > is nothing else like a new process talking over one of few message buses > today to distribute the set of information you need. > > In fact I am not convinced p2mp is the best way to go with here. Pub-sub > without RTC hacks may be much better - don't you honestly think ? > > Best, > R.=E2=80=8B > > > >> Re: Scope of application. The main goal was to use this in data-center, >> but I can theorize this could be used among few operators that are willi= ng >> to develop on-device applications and exchange data using the >> pre-established channels (e.g. the WISER use case). In this situation, >> limiting scope to just private ASNs could be tricky. Furthermore, >> non-private ASNs could be used in data-center as well (just not exposed >> outside...). >> >> Re: Transitive attribute. Ideally, it would be great to carry the value >> in next-hop field of MP_REACH_NLRI, but the length is limited to 8 bytes= , >> hence the new attribute. I do not have strong arguments to making this >> transitive, it should be fine to go with non-transitive and correspondin= g >> error handling. >> >> Re: Security. Since we do not directly influence path selection with new >> data, the threats could be limited to those targeting BGPinfra itself e.= g. >> flooding with information, disrupting session etc. There could be questi= ons >> about information authenticity, but this could be left up to the >> applications to decide (e.g. signing the key-value bindings). >> >> Regards, >> >> Petr >> >> ------------------------------ >> *From:* rraszuk@gmail.com [rraszuk@gmail.com] on behalf of Robert Raszuk >> [robert@raszuk.net] >> *Sent:* Saturday, March 12, 2016 1:10 PM >> *To:* Petr Lapukhov; exa@juniper.net >> *Cc:* idr wg >> *Subject:* Use of BGP for Opaque Signaling >> >> =E2=80=8BPetr, Eben, >> >> I have few questions and comments to your proposal. >> >> - The draft =E2=80=8Battempts to reuse BGP mechanism for p2mp distributi= on of >> opaque information. That alone is not a bad thing :) However when you ma= ke >> reference to BGP-LS it needs to be observed that BGP-LS is not position = to >> directly impact routing (ie content of RIB and FIBs) unlike one of the u= se >> cases described in your draft Intro paragraph. That means that unlike >> BGP-LS it must co-exist with routing BGP on the same BGP speakers. >> >> Here I would like to bring back my proposal to define new port for >> Transport Instance BGP https://tools.ietf.org/html/draft-raszuk-ti-bgp-0= 1 >> >> which at the time of discussion was supposed to be shortly addressed by >> dynamic port allocations of multisessions which to the best of my knowle= dge >> never happened. >> >> So first comment is that if we go with reusing BGP-4 for this type of >> signalling let's enforce it's early separation from "classic" BGP. >> >> - Second comment is related to the scope of use. If the scope is private >> - let's perhaps enforce it more explicitly such that by the spec it is >> illegal AFI/SAFI pair in the public Internet. For example by stating tha= t >> it is illegal to have non private AS in the AS_PATH of such UPDATE msg. >> >> - Third the draft states that there is no new security implications .. >> well if the scope is non private I am afraid that is no the case. As you >> have seen (and still seeing) securing BGP UPDATE MSG is MP_REACH content >> dependent. If content is free form I am afraid it will be rather hard to >> secure it well :) >> >> - Last as opaque value container you are defining an transitive attribut= e >> ? Is the intention to use this attribute in existing AFI/SAFIs as well ? >> Otherwise if not why do you need this to be transitive if capability >> negotiation already may implicitly define it's support by new AFI/SAFI. >> >> Cheers, >> R. >> >> PS. >> >> > There is an ongoing discussion around avoiding NLRI (key) collisions. >> >> Where is such discussion taking place ? Shouldn't IDR be perhaps in the >> loop a bit :) >> >> >> >> >> > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > > --001a11c259a858e185052def6a38 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Gunter,

=
For dissemination of information produced by netwo= rk applications we already have today various tools be it ansible, chef, pu= ppet etc ...=C2=A0

If = there is need to use inter-domain distribution of such applications I see n= o reason why not to define registered or private wide bgp community and use= this as transport instead of new SAFI on already established BGP sessions.= Note that wide BGP community precisely like new attribute being proposed h= ere can carry opaque to BGP data.=C2=A0

<= div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif= ;font-size:small">Hi Petr,

Do you see any issue with the above wide community approach to address= you needs ? Especially for bootstrapping the transport it is even easier a= s you do not need to enable new SAFI. And those are already IDR WG docs.=C2= =A0

https://tools.ietf.org/h= tml/draft-ietf-idr-wide-bgp-communities-01
<= a href=3D"https://tools.ietf.org/html/draft-ietf-idr-registered-wide-bgp-co= mmunities-01">https://tools.ietf.org/html/draft-ietf-idr-registered-wide-bg= p-communities-01

As far as limit of 4K let's all note that we already have a draft= addressing this and moving the limit to 65K:=C2=A0https://tools.ietf.= org/html/draft-ietf-idr-bgp-extended-messages-11

Cheers,
r.




<= div class=3D"gmail_quote">On Sun, Mar 13, 2016 at 5:11 AM, Gunter Van De Ve= lde <guntervandeveldecc@icloud.com> wrote:
imo t= he promise of a proposal like this one, is that it allows Application devel= opment at DevOps speed and removes slowness of industry bodies for innovati= on.

I believe it is a valid problem space that is = being addressed. Maybe some features/optimisations from EVN could be transp= lanted? (i.e. Designated router selection, aliasing and mass-withdraw)

G/


On 13 Mar 2016, at 04:20, Petr Lapukhov <= ;petr@fb.com> wrote= :

>=C2=A0In fact I am= not convinced p2mp is the best way to go with here.=C2=A0
> Pub-= sub without RTC hacks may be much better - don't you honestly think ?= =C2=A0

Not exactly, but maybe I misunderstood what p2mp means :) The main a= dvantage of using BGP (at least in our environment) comes from the fact tha= t it's already bootstrapped when on-switch (or on-server) applications = start coming up. And it stays there even when the servers hosting external = key-value store may be gone.=C2=A0

Aside from this, I fully agree - it does = not offer much more than any key-value store. And it has its own constraint= s, like ~4K value size. Plus, it's not even a proper pub-sub, since the= re is no discreet message semantic - only state dissemination :)

From:= =C2=A0rraszuk= @gmail.com=C2=A0[rraszuk@gmail.com] on behalf of Robert Raszuk [robert@raszuk.net]
S= ent:=C2=A0Saturday, March 12, 2016 5:25 PM
To:=C2=A0Petr Lapukhov
Cc:=C2=A0exa@juniper.net; idr wg
= Subject:=C2=A0Re: Use of BGP for Opaque Signaling

=E2=80=8BHello Petr,=E2=80=8B
=C2=A0
Re: Impact on = routing. I should be more explicit stating that the idea is for BGP to not = interpret the key-value mappings in any way.

=E2=80=8BThat was very clear alread= y. But if you look at number of BGP implementations recognizing the AFI/SAF= I coming over single session is not done immediately in the BGP message par= sing. That is my main point suggesting transport instance port.=C2=A0
=

I no longer believe multise= ssions will do it neither that we could off load it as implementation speci= fic thing.=E2=80=8B

=C2=A0
The consumer (running on same device, possibly) may sti= ll influence routing based on its interpretation of data, either by accessi= ng the platform SDK or by performing BGP routing injection over the corresp= onding AFI/SAFI.

=E2=80=8BThat is exactly the issue. The only way BGP-LS wen= t by was the claim about their explicit disjointed topology from existing B= GP. It was well positioned that BGP-LS can be completely incongruent with &= quot;routing" BGP. =E2=80=8B

= =E2=80=8BThe possible channels the IGP information may impact routing were = classified as out of the band likely coming via some other ways from contro= llers (I2RS, APIs, routing BGP SAFI etc ...).=C2=A0

=C2=A0
Re: Transport= instance. I think it's a great idea to run this on separate instance, = but right now we typically run just one process, and it adds some operation= al overhead to maintain two of them. Also, often this extension could be us= ed just with out-of-band reflection. This is why I feel it is rather better= to keep this applicable to any type of BGP instance.


=E2=80=8BIma= gine that you will not get far in this BGP proposal. Then what is left is n= othing else like a new process talking over one of few message buses today = to distribute the set of information you need.=C2=A0

In fact I am not convinced p2mp is the best = way to go with here. Pub-sub without RTC hacks may be much better - don'= ;t you honestly think ?=C2=A0

Best,
R.=E2=80=8B

=C2=A0
Re: Scope = of application. The main goal was to use this in data-center, but I can the= orize this could be used among few operators that are willing to develop on= -device applications and exchange data using the pre-established channels (= e.g. the WISER use case). In this situation, limiting scope to just private= ASNs could be tricky. Furthermore, non-private ASNs could be used in data-= center as well (just not exposed outside...).

Re: Transitive attribute. Ideally, it would be great to carry the va= lue in next-hop field of MP_REACH_NLRI, but the length is limited to 8 byte= s, hence the new attribute. I do not have strong arguments to making this t= ransitive, it should be fine to go with non-transitive and corresponding er= ror handling.=C2=A0

Re: Security. Since we do not = directly influence path selection with new data, the threats could be limit= ed to those targeting BGPinfra itself e.g. flooding with information, disru= pting session etc. There could be questions about information authenticity,= but this could be left up to the applications to decide (e.g. signing the = key-value bindings).

Regards,

=
Petr

From:=C2=A0rraszuk@gmail.com=C2=A0[rraszuk@gmail.com] o= n behalf of Robert Raszuk [robert@raszuk.net]
Sent:=C2=A0Saturday, M= arch 12, 2016 1:10 PM
To:=C2=A0Petr Lapukhov;= =C2=A0exa@junip= er.net
Cc:=C2=A0idr wg
Subject:= =C2=A0Use of BGP for Opaque Signaling

=
=E2=80=8BPetr, Eben,

I have few questions = and comments to your proposal.=C2=A0

- The draft =E2=80=8Battempts to = reuse BGP mechanism for p2mp distribution of opaque information. That alone= is not a bad thing :) However when you make reference to BGP-LS it needs t= o be observed that BGP-LS is not position to directly impact routing (ie co= ntent of RIB and FIBs) unlike one of the use cases described in your draft = Intro paragraph. That means that unlike BGP-LS it must co-exist with routin= g BGP on the same BGP speakers.=C2=A0

Here I would like to bring back = my proposal to define new port for Transport Instance BGP=C2=A0https://tools.ietf.org/html/draft-raszuk-ti-bgp-01= =C2=A0which at the time of discussion was supposed to be shortly add= ressed by dynamic port allocations of multisessions which to the best of my= knowledge never happened.=C2=A0

So first comment is that if we go wit= h reusing BGP-4 for this type of signalling let's enforce it's earl= y separation from "classic" BGP.=C2=A0

- Second comment is r= elated to the scope of use. If the scope is private - let's perhaps enf= orce it more explicitly such that by the spec it is illegal AFI/SAFI pair i= n the public Internet. For example by stating that it is illegal to have no= n private AS in the AS_PATH of such UPDATE msg.=C2=A0

- Third the dra= ft states that there is no new security implications .. well if the scope i= s non private I am afraid that is no the case. As you have seen (and still = seeing) securing BGP UPDATE MSG is MP_REACH content dependent. If content i= s free form I am afraid it will be rather hard to secure it well :)=C2=A0
<= br>
- Last as opaque value container you are defining an transitive attribu= te ? Is the intention to use this attribute in existing AFI/SAFIs as well ?= Otherwise if not why do you need this to be transitive if capability negot= iation already may implicitly define it's support by new AFI/SAFI.

=
Cheers,
R.

PS.=C2=A0

> There is an ongoing discussion around avoiding NLRI (ke= y) collisions.

Wh= ere is such discussion taking place ? Shouldn't IDR be perhaps in the l= oop a bit :)=C2=A0


=C2=A0
=

_______________________________________________=
Idr mailing list
Idr@ietf.org
<= span style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-v= ariant:normal;font-weight:normal;letter-spacing:normal;text-align:start;tex= t-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:= none;display:inline!important">https://www.ietf.org/mailman/listinfo/idr


--001a11c259a858e185052def6a38-- From nobody Sun Mar 13 09:09:21 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 152A812D5E7 for ; Sun, 13 Mar 2016 09:09:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.731 X-Spam-Level: X-Spam-Status: No, score=-0.731 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com 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 RYyt4Ia5OObf for ; Sun, 13 Mar 2016 09:09:16 -0700 (PDT) Received: from mx0b-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.30]) (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 EB5BD12D5D3 for ; Sun, 13 Mar 2016 09:09:15 -0700 (PDT) Received: from pps.filterd (m0089730.ppops.net [127.0.0.1]) by m0089730.ppops.net (8.16.0.11/8.16.0.11) with SMTP id u2DG5lcq023376; Sun, 13 Mar 2016 09:09:09 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=dB7M8ehnG19NTANM4CofKL3thASe4pL8PrgRV/DX/O8=; b=FqGbjeDzsej6Bk824cmBiqqtlrKSPoSXnUnvuiMG7PBnU9kTGnWWTUPt0tCsxL22ApWl Oq+J+60Q/iwoX4MPt6rw/fAKfblSUVmU7+D1xDeY7doEczrkVwknS9iUWnqPWAtnum+f DIgmrY5E0KhzXFV0L8cg0GPR1L/ecjfwr9U= Received: from mail.thefacebook.com ([199.201.64.23]) by m0089730.ppops.net with ESMTP id 21mh3wuf5n-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Sun, 13 Mar 2016 09:09:09 -0700 Received: from PRN-MBX01-2.TheFacebook.com ([169.254.3.204]) by PRN-CHUB03.TheFacebook.com ([fe80::fd64:bd05:4514:bbad%12]) with mapi id 14.03.0248.002; Sun, 13 Mar 2016 09:09:08 -0700 From: Petr Lapukhov To: Gunter Van De Velde Thread-Topic: [Idr] Use of BGP for Opaque Signaling Thread-Index: AQHRfKONNK1upwIbukaCHqWz2SNu2p9WgK6PgACao4D//5fqt4AA2ZQA///+D30= Date: Sun, 13 Mar 2016 16:09:07 +0000 Message-ID: <3F437107848A5140A6A19222EFFB3481200E32DD@PRN-MBX01-2.TheFacebook.com> References: <3F437107848A5140A6A19222EFFB3481200E2839@PRN-MBX01-2.TheFacebook.com> <3F437107848A5140A6A19222EFFB3481200E2A32@PRN-MBX01-2.TheFacebook.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.52.123] Content-Type: multipart/alternative; boundary="_000_3F437107848A5140A6A19222EFFB3481200E32DDPRNMBX012TheFac_" MIME-Version: 1.0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-03-13_04:, , signatures=0 Archived-At: Cc: idr wg , Robert Raszuk Subject: Re: [Idr] Use of BGP for Opaque Signaling X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2016 16:09:19 -0000 --_000_3F437107848A5140A6A19222EFFB3481200E32DDPRNMBX012TheFac_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 R3VudGVyIC0gdGhhdCdzIGV4YWN0bHkgdGhlIHBvaW50LiBUaGUgaWRlYSBpcyB0byBoYXZlIHNv bWV0aGluZyB0aGF0IGRvZXMgbm90IHJlcXVpcmUgc3RhbmRhcmRzIGJvZHkgY29vcmRpbmF0aW9u IGFuZCBjb3VsZCBiZSB1c2VkIGluIGFkLWhvYyBmYXNoaW9uLiBOYXR1cmFsbHksIHRoZXJlIGFy ZSBkb3duc2lkZXMgdG8gdGhpcyBhcHByb2FjaCAoZS5nLiBvdXQtb2YtYmFuZCBjb29yZGluYXRp b24gbmVlZGVkKSwgYnV0IEkgZmVlbCB0aGF0IGtlZXBpbmcgaXQgc2ltcGxlIGlzIG1vcmUgaW1w b3J0YW50LiBQbHVzLCB0aGlzIHNpbXBsaWNpdHkgbWFrZXMgaW1wbGVtZW50YXRpb24gcmVhbGx5 IHN0cmFpZ2h0Zm9yd2FyZCA6KQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K RnJvbTogR3VudGVyIFZhbiBEZSBWZWxkZSBbZ3VudGVydmFuZGV2ZWxkZWNjQGljbG91ZC5jb21d DQpTZW50OiBTdW5kYXksIE1hcmNoIDEzLCAyMDE2IDE6MTEgQU0NClRvOiBQZXRyIExhcHVraG92 DQpDYzogUm9iZXJ0IFJhc3p1azsgaWRyIHdnDQpTdWJqZWN0OiBSZTogW0lkcl0gVXNlIG9mIEJH UCBmb3IgT3BhcXVlIFNpZ25hbGluZw0KDQppbW8gdGhlIHByb21pc2Ugb2YgYSBwcm9wb3NhbCBs aWtlIHRoaXMgb25lLCBpcyB0aGF0IGl0IGFsbG93cyBBcHBsaWNhdGlvbiBkZXZlbG9wbWVudCBh dCBEZXZPcHMgc3BlZWQgYW5kIHJlbW92ZXMgc2xvd25lc3Mgb2YgaW5kdXN0cnkgYm9kaWVzIGZv ciBpbm5vdmF0aW9uLg0KDQpJIGJlbGlldmUgaXQgaXMgYSB2YWxpZCBwcm9ibGVtIHNwYWNlIHRo YXQgaXMgYmVpbmcgYWRkcmVzc2VkLiBNYXliZSBzb21lIGZlYXR1cmVzL29wdGltaXNhdGlvbnMg ZnJvbSBFVk4gY291bGQgYmUgdHJhbnNwbGFudGVkPyAoaS5lLiBEZXNpZ25hdGVkIHJvdXRlciBz ZWxlY3Rpb24sIGFsaWFzaW5nIGFuZCBtYXNzLXdpdGhkcmF3KQ0KDQpHLw0KDQoNCk9uIDEzIE1h ciAyMDE2LCBhdCAwNDoyMCwgUGV0ciBMYXB1a2hvdiA8cGV0ckBmYi5jb208bWFpbHRvOnBldHJA ZmIuY29tPj4gd3JvdGU6DQoNCj4gSW4gZmFjdCBJIGFtIG5vdCBjb252aW5jZWQgcDJtcCBpcyB0 aGUgYmVzdCB3YXkgdG8gZ28gd2l0aCBoZXJlLg0KPiBQdWItc3ViIHdpdGhvdXQgUlRDIGhhY2tz IG1heSBiZSBtdWNoIGJldHRlciAtIGRvbid0IHlvdSBob25lc3RseSB0aGluayA/DQoNCk5vdCBl eGFjdGx5LCBidXQgbWF5YmUgSSBtaXN1bmRlcnN0b29kIHdoYXQgcDJtcCBtZWFucyA6KSBUaGUg bWFpbiBhZHZhbnRhZ2Ugb2YgdXNpbmcgQkdQIChhdCBsZWFzdCBpbiBvdXIgZW52aXJvbm1lbnQp IGNvbWVzIGZyb20gdGhlIGZhY3QgdGhhdCBpdCdzIGFscmVhZHkgYm9vdHN0cmFwcGVkIHdoZW4g b24tc3dpdGNoIChvciBvbi1zZXJ2ZXIpIGFwcGxpY2F0aW9ucyBzdGFydCBjb21pbmcgdXAuIEFu ZCBpdCBzdGF5cyB0aGVyZSBldmVuIHdoZW4gdGhlIHNlcnZlcnMgaG9zdGluZyBleHRlcm5hbCBr ZXktdmFsdWUgc3RvcmUgbWF5IGJlIGdvbmUuDQoNCkFzaWRlIGZyb20gdGhpcywgSSBmdWxseSBh Z3JlZSAtIGl0IGRvZXMgbm90IG9mZmVyIG11Y2ggbW9yZSB0aGFuIGFueSBrZXktdmFsdWUgc3Rv cmUuIEFuZCBpdCBoYXMgaXRzIG93biBjb25zdHJhaW50cywgbGlrZSB+NEsgdmFsdWUgc2l6ZS4g UGx1cywgaXQncyBub3QgZXZlbiBhIHByb3BlciBwdWItc3ViLCBzaW5jZSB0aGVyZSBpcyBubyBk aXNjcmVldCBtZXNzYWdlIHNlbWFudGljIC0gb25seSBzdGF0ZSBkaXNzZW1pbmF0aW9uIDopDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBycmFzenVrQGdtYWlsLmNv bTxtYWlsdG86cnJhc3p1a0BnbWFpbC5jb20+IFtycmFzenVrQGdtYWlsLmNvbTxtYWlsdG86cnJh c3p1a0BnbWFpbC5jb20+XSBvbiBiZWhhbGYgb2YgUm9iZXJ0IFJhc3p1ayBbcm9iZXJ0QHJhc3p1 ay5uZXQ8bWFpbHRvOnJvYmVydEByYXN6dWsubmV0Pl0NClNlbnQ6IFNhdHVyZGF5LCBNYXJjaCAx MiwgMjAxNiA1OjI1IFBNDQpUbzogUGV0ciBMYXB1a2hvdg0KQ2M6IGV4YUBqdW5pcGVyLm5ldDxt YWlsdG86ZXhhQGp1bmlwZXIubmV0PjsgaWRyIHdnDQpTdWJqZWN0OiBSZTogVXNlIG9mIEJHUCBm b3IgT3BhcXVlIFNpZ25hbGluZw0KDQrigItIZWxsbyBQZXRyLOKAiw0KDQpSZTogSW1wYWN0IG9u IHJvdXRpbmcuIEkgc2hvdWxkIGJlIG1vcmUgZXhwbGljaXQgc3RhdGluZyB0aGF0IHRoZSBpZGVh IGlzIGZvciBCR1AgdG8gbm90IGludGVycHJldCB0aGUga2V5LXZhbHVlIG1hcHBpbmdzIGluIGFu eSB3YXkuDQoNCuKAi1RoYXQgd2FzIHZlcnkgY2xlYXIgYWxyZWFkeS4gQnV0IGlmIHlvdSBsb29r IGF0IG51bWJlciBvZiBCR1AgaW1wbGVtZW50YXRpb25zIHJlY29nbml6aW5nIHRoZSBBRkkvU0FG SSBjb21pbmcgb3ZlciBzaW5nbGUgc2Vzc2lvbiBpcyBub3QgZG9uZSBpbW1lZGlhdGVseSBpbiB0 aGUgQkdQIG1lc3NhZ2UgcGFyc2luZy4gVGhhdCBpcyBteSBtYWluIHBvaW50IHN1Z2dlc3Rpbmcg dHJhbnNwb3J0IGluc3RhbmNlIHBvcnQuDQoNCkkgbm8gbG9uZ2VyIGJlbGlldmUgbXVsdGlzZXNz aW9ucyB3aWxsIGRvIGl0IG5laXRoZXIgdGhhdCB3ZSBjb3VsZCBvZmYgbG9hZCBpdCBhcyBpbXBs ZW1lbnRhdGlvbiBzcGVjaWZpYyB0aGluZy7igIsNCg0KDQpUaGUgY29uc3VtZXIgKHJ1bm5pbmcg b24gc2FtZSBkZXZpY2UsIHBvc3NpYmx5KSBtYXkgc3RpbGwgaW5mbHVlbmNlIHJvdXRpbmcgYmFz ZWQgb24gaXRzIGludGVycHJldGF0aW9uIG9mIGRhdGEsIGVpdGhlciBieSBhY2Nlc3NpbmcgdGhl IHBsYXRmb3JtIFNESyBvciBieSBwZXJmb3JtaW5nIEJHUCByb3V0aW5nIGluamVjdGlvbiBvdmVy IHRoZSBjb3JyZXNwb25kaW5nIEFGSS9TQUZJLg0KDQrigItUaGF0IGlzIGV4YWN0bHkgdGhlIGlz c3VlLiBUaGUgb25seSB3YXkgQkdQLUxTIHdlbnQgYnkgd2FzIHRoZSBjbGFpbSBhYm91dCB0aGVp ciBleHBsaWNpdCBkaXNqb2ludGVkIHRvcG9sb2d5IGZyb20gZXhpc3RpbmcgQkdQLiBJdCB3YXMg d2VsbCBwb3NpdGlvbmVkIHRoYXQgQkdQLUxTIGNhbiBiZSBjb21wbGV0ZWx5IGluY29uZ3J1ZW50 IHdpdGggInJvdXRpbmciIEJHUC4g4oCLDQoNCuKAi1RoZSBwb3NzaWJsZSBjaGFubmVscyB0aGUg SUdQIGluZm9ybWF0aW9uIG1heSBpbXBhY3Qgcm91dGluZyB3ZXJlIGNsYXNzaWZpZWQgYXMgb3V0 IG9mIHRoZSBiYW5kIGxpa2VseSBjb21pbmcgdmlhIHNvbWUgb3RoZXIgd2F5cyBmcm9tIGNvbnRy b2xsZXJzIChJMlJTLCBBUElzLCByb3V0aW5nIEJHUCBTQUZJIGV0YyAuLi4pLg0KDQoNClJlOiBU cmFuc3BvcnQgaW5zdGFuY2UuIEkgdGhpbmsgaXQncyBhIGdyZWF0IGlkZWEgdG8gcnVuIHRoaXMg b24gc2VwYXJhdGUgaW5zdGFuY2UsIGJ1dCByaWdodCBub3cgd2UgdHlwaWNhbGx5IHJ1biBqdXN0 IG9uZSBwcm9jZXNzLCBhbmQgaXQgYWRkcyBzb21lIG9wZXJhdGlvbmFsIG92ZXJoZWFkIHRvIG1h aW50YWluIHR3byBvZiB0aGVtLiBBbHNvLCBvZnRlbiB0aGlzIGV4dGVuc2lvbiBjb3VsZCBiZSB1 c2VkIGp1c3Qgd2l0aCBvdXQtb2YtYmFuZCByZWZsZWN0aW9uLiBUaGlzIGlzIHdoeSBJIGZlZWwg aXQgaXMgcmF0aGVyIGJldHRlciB0byBrZWVwIHRoaXMgYXBwbGljYWJsZSB0byBhbnkgdHlwZSBv ZiBCR1AgaW5zdGFuY2UuDQoNCg0K4oCLSW1hZ2luZSB0aGF0IHlvdSB3aWxsIG5vdCBnZXQgZmFy IGluIHRoaXMgQkdQIHByb3Bvc2FsLiBUaGVuIHdoYXQgaXMgbGVmdCBpcyBub3RoaW5nIGVsc2Ug bGlrZSBhIG5ldyBwcm9jZXNzIHRhbGtpbmcgb3ZlciBvbmUgb2YgZmV3IG1lc3NhZ2UgYnVzZXMg dG9kYXkgdG8gZGlzdHJpYnV0ZSB0aGUgc2V0IG9mIGluZm9ybWF0aW9uIHlvdSBuZWVkLg0KDQpJ biBmYWN0IEkgYW0gbm90IGNvbnZpbmNlZCBwMm1wIGlzIHRoZSBiZXN0IHdheSB0byBnbyB3aXRo IGhlcmUuIFB1Yi1zdWIgd2l0aG91dCBSVEMgaGFja3MgbWF5IGJlIG11Y2ggYmV0dGVyIC0gZG9u J3QgeW91IGhvbmVzdGx5IHRoaW5rID8NCg0KQmVzdCwNClIu4oCLDQoNCg0KUmU6IFNjb3BlIG9m IGFwcGxpY2F0aW9uLiBUaGUgbWFpbiBnb2FsIHdhcyB0byB1c2UgdGhpcyBpbiBkYXRhLWNlbnRl ciwgYnV0IEkgY2FuIHRoZW9yaXplIHRoaXMgY291bGQgYmUgdXNlZCBhbW9uZyBmZXcgb3BlcmF0 b3JzIHRoYXQgYXJlIHdpbGxpbmcgdG8gZGV2ZWxvcCBvbi1kZXZpY2UgYXBwbGljYXRpb25zIGFu ZCBleGNoYW5nZSBkYXRhIHVzaW5nIHRoZSBwcmUtZXN0YWJsaXNoZWQgY2hhbm5lbHMgKGUuZy4g dGhlIFdJU0VSIHVzZSBjYXNlKS4gSW4gdGhpcyBzaXR1YXRpb24sIGxpbWl0aW5nIHNjb3BlIHRv IGp1c3QgcHJpdmF0ZSBBU05zIGNvdWxkIGJlIHRyaWNreS4gRnVydGhlcm1vcmUsIG5vbi1wcml2 YXRlIEFTTnMgY291bGQgYmUgdXNlZCBpbiBkYXRhLWNlbnRlciBhcyB3ZWxsIChqdXN0IG5vdCBl eHBvc2VkIG91dHNpZGUuLi4pLg0KDQpSZTogVHJhbnNpdGl2ZSBhdHRyaWJ1dGUuIElkZWFsbHks IGl0IHdvdWxkIGJlIGdyZWF0IHRvIGNhcnJ5IHRoZSB2YWx1ZSBpbiBuZXh0LWhvcCBmaWVsZCBv ZiBNUF9SRUFDSF9OTFJJLCBidXQgdGhlIGxlbmd0aCBpcyBsaW1pdGVkIHRvIDggYnl0ZXMsIGhl bmNlIHRoZSBuZXcgYXR0cmlidXRlLiBJIGRvIG5vdCBoYXZlIHN0cm9uZyBhcmd1bWVudHMgdG8g bWFraW5nIHRoaXMgdHJhbnNpdGl2ZSwgaXQgc2hvdWxkIGJlIGZpbmUgdG8gZ28gd2l0aCBub24t dHJhbnNpdGl2ZSBhbmQgY29ycmVzcG9uZGluZyBlcnJvciBoYW5kbGluZy4NCg0KUmU6IFNlY3Vy aXR5LiBTaW5jZSB3ZSBkbyBub3QgZGlyZWN0bHkgaW5mbHVlbmNlIHBhdGggc2VsZWN0aW9uIHdp dGggbmV3IGRhdGEsIHRoZSB0aHJlYXRzIGNvdWxkIGJlIGxpbWl0ZWQgdG8gdGhvc2UgdGFyZ2V0 aW5nIEJHUGluZnJhIGl0c2VsZiBlLmcuIGZsb29kaW5nIHdpdGggaW5mb3JtYXRpb24sIGRpc3J1 cHRpbmcgc2Vzc2lvbiBldGMuIFRoZXJlIGNvdWxkIGJlIHF1ZXN0aW9ucyBhYm91dCBpbmZvcm1h dGlvbiBhdXRoZW50aWNpdHksIGJ1dCB0aGlzIGNvdWxkIGJlIGxlZnQgdXAgdG8gdGhlIGFwcGxp Y2F0aW9ucyB0byBkZWNpZGUgKGUuZy4gc2lnbmluZyB0aGUga2V5LXZhbHVlIGJpbmRpbmdzKS4N Cg0KUmVnYXJkcywNCg0KUGV0cg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K RnJvbTogcnJhc3p1a0BnbWFpbC5jb208bWFpbHRvOnJyYXN6dWtAZ21haWwuY29tPiBbcnJhc3p1 a0BnbWFpbC5jb208bWFpbHRvOnJyYXN6dWtAZ21haWwuY29tPl0gb24gYmVoYWxmIG9mIFJvYmVy dCBSYXN6dWsgW3JvYmVydEByYXN6dWsubmV0PG1haWx0bzpyb2JlcnRAcmFzenVrLm5ldD5dDQpT ZW50OiBTYXR1cmRheSwgTWFyY2ggMTIsIDIwMTYgMToxMCBQTQ0KVG86IFBldHIgTGFwdWtob3Y7 IGV4YUBqdW5pcGVyLm5ldDxtYWlsdG86ZXhhQGp1bmlwZXIubmV0Pg0KQ2M6IGlkciB3Zw0KU3Vi amVjdDogVXNlIG9mIEJHUCBmb3IgT3BhcXVlIFNpZ25hbGluZw0KDQrigItQZXRyLCBFYmVuLA0K DQpJIGhhdmUgZmV3IHF1ZXN0aW9ucyBhbmQgY29tbWVudHMgdG8geW91ciBwcm9wb3NhbC4NCg0K LSBUaGUgZHJhZnQg4oCLYXR0ZW1wdHMgdG8gcmV1c2UgQkdQIG1lY2hhbmlzbSBmb3IgcDJtcCBk aXN0cmlidXRpb24gb2Ygb3BhcXVlIGluZm9ybWF0aW9uLiBUaGF0IGFsb25lIGlzIG5vdCBhIGJh ZCB0aGluZyA6KSBIb3dldmVyIHdoZW4geW91IG1ha2UgcmVmZXJlbmNlIHRvIEJHUC1MUyBpdCBu ZWVkcyB0byBiZSBvYnNlcnZlZCB0aGF0IEJHUC1MUyBpcyBub3QgcG9zaXRpb24gdG8gZGlyZWN0 bHkgaW1wYWN0IHJvdXRpbmcgKGllIGNvbnRlbnQgb2YgUklCIGFuZCBGSUJzKSB1bmxpa2Ugb25l IG9mIHRoZSB1c2UgY2FzZXMgZGVzY3JpYmVkIGluIHlvdXIgZHJhZnQgSW50cm8gcGFyYWdyYXBo LiBUaGF0IG1lYW5zIHRoYXQgdW5saWtlIEJHUC1MUyBpdCBtdXN0IGNvLWV4aXN0IHdpdGggcm91 dGluZyBCR1Agb24gdGhlIHNhbWUgQkdQIHNwZWFrZXJzLg0KDQpIZXJlIEkgd291bGQgbGlrZSB0 byBicmluZyBiYWNrIG15IHByb3Bvc2FsIHRvIGRlZmluZSBuZXcgcG9ydCBmb3IgVHJhbnNwb3J0 IEluc3RhbmNlIEJHUCBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcmFzenVrLXRp LWJncC0wMTxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMt M0FfX3Rvb2xzLmlldGYub3JnX2h0bWxfZHJhZnQtMkRyYXN6dWstMkR0aS0yRGJncC0yRDAxJmQ9 Q3dNRmFRJmM9NVZEMFJUdE5sVGgzeWNkNDFiM01VdyZyPUxVX3ZKYU1fRVF1MVNzbTM1ajJ4bEEm bT03NVEtbnZYMlJoaHhZbS1yMkJJeEZodElwS3pUOXBFZ0d4OVVXanE2ZlQ0JnM9a0s3MWVTcVdC SVRhbEcxWTFpTldhaUhhU0E3dnJNTW5MNGxraWVhcTJ1WSZlPT4gd2hpY2ggYXQgdGhlIHRpbWUg b2YgZGlzY3Vzc2lvbiB3YXMgc3VwcG9zZWQgdG8gYmUgc2hvcnRseSBhZGRyZXNzZWQgYnkgZHlu YW1pYyBwb3J0IGFsbG9jYXRpb25zIG9mIG11bHRpc2Vzc2lvbnMgd2hpY2ggdG8gdGhlIGJlc3Qg b2YgbXkga25vd2xlZGdlIG5ldmVyIGhhcHBlbmVkLg0KDQpTbyBmaXJzdCBjb21tZW50IGlzIHRo YXQgaWYgd2UgZ28gd2l0aCByZXVzaW5nIEJHUC00IGZvciB0aGlzIHR5cGUgb2Ygc2lnbmFsbGlu ZyBsZXQncyBlbmZvcmNlIGl0J3MgZWFybHkgc2VwYXJhdGlvbiBmcm9tICJjbGFzc2ljIiBCR1Au DQoNCi0gU2Vjb25kIGNvbW1lbnQgaXMgcmVsYXRlZCB0byB0aGUgc2NvcGUgb2YgdXNlLiBJZiB0 aGUgc2NvcGUgaXMgcHJpdmF0ZSAtIGxldCdzIHBlcmhhcHMgZW5mb3JjZSBpdCBtb3JlIGV4cGxp Y2l0bHkgc3VjaCB0aGF0IGJ5IHRoZSBzcGVjIGl0IGlzIGlsbGVnYWwgQUZJL1NBRkkgcGFpciBp biB0aGUgcHVibGljIEludGVybmV0LiBGb3IgZXhhbXBsZSBieSBzdGF0aW5nIHRoYXQgaXQgaXMg aWxsZWdhbCB0byBoYXZlIG5vbiBwcml2YXRlIEFTIGluIHRoZSBBU19QQVRIIG9mIHN1Y2ggVVBE QVRFIG1zZy4NCg0KLSBUaGlyZCB0aGUgZHJhZnQgc3RhdGVzIHRoYXQgdGhlcmUgaXMgbm8gbmV3 IHNlY3VyaXR5IGltcGxpY2F0aW9ucyAuLiB3ZWxsIGlmIHRoZSBzY29wZSBpcyBub24gcHJpdmF0 ZSBJIGFtIGFmcmFpZCB0aGF0IGlzIG5vIHRoZSBjYXNlLiBBcyB5b3UgaGF2ZSBzZWVuIChhbmQg c3RpbGwgc2VlaW5nKSBzZWN1cmluZyBCR1AgVVBEQVRFIE1TRyBpcyBNUF9SRUFDSCBjb250ZW50 IGRlcGVuZGVudC4gSWYgY29udGVudCBpcyBmcmVlIGZvcm0gSSBhbSBhZnJhaWQgaXQgd2lsbCBi ZSByYXRoZXIgaGFyZCB0byBzZWN1cmUgaXQgd2VsbCA6KQ0KDQotIExhc3QgYXMgb3BhcXVlIHZh bHVlIGNvbnRhaW5lciB5b3UgYXJlIGRlZmluaW5nIGFuIHRyYW5zaXRpdmUgYXR0cmlidXRlID8g SXMgdGhlIGludGVudGlvbiB0byB1c2UgdGhpcyBhdHRyaWJ1dGUgaW4gZXhpc3RpbmcgQUZJL1NB RklzIGFzIHdlbGwgPyBPdGhlcndpc2UgaWYgbm90IHdoeSBkbyB5b3UgbmVlZCB0aGlzIHRvIGJl IHRyYW5zaXRpdmUgaWYgY2FwYWJpbGl0eSBuZWdvdGlhdGlvbiBhbHJlYWR5IG1heSBpbXBsaWNp dGx5IGRlZmluZSBpdCdzIHN1cHBvcnQgYnkgbmV3IEFGSS9TQUZJLg0KDQpDaGVlcnMsDQpSLg0K DQpQUy4NCg0KPiBUaGVyZSBpcyBhbiBvbmdvaW5nIGRpc2N1c3Npb24gYXJvdW5kIGF2b2lkaW5n IE5MUkkgKGtleSkgY29sbGlzaW9ucy4NCg0KV2hlcmUgaXMgc3VjaCBkaXNjdXNzaW9uIHRha2lu ZyBwbGFjZSA/IFNob3VsZG4ndCBJRFIgYmUgcGVyaGFwcyBpbiB0aGUgbG9vcCBhIGJpdCA6KQ0K DQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpJZHIgbWFpbGluZyBsaXN0DQpJZHJAaWV0Zi5vcmc8bWFpbHRvOklkckBpZXRmLm9yZz4NCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWRyPGh0dHBzOi8vdXJsZGVmZW5z ZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5f bGlzdGluZm9faWRyJmQ9Q3dNRmFRJmM9NVZEMFJUdE5sVGgzeWNkNDFiM01VdyZyPUxVX3ZKYU1f RVF1MVNzbTM1ajJ4bEEmbT1LWUpnMURCeGM2R2djNEhReXhGM1hNTWx3c2xQZldLR2FyZkpEZ2VX WEVVJnM9ZU1rOE40NFNuc1RYbHM4UU4zSS1DMHNUdDNadi1CZS10Q0FYck14MF9wdyZlPT4NCg0K --_000_3F437107848A5140A6A19222EFFB3481200E32DDPRNMBX012TheFac_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgZGlyPSJsdHIiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUi IGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8c3R5bGUgdHlwZT0idGV4dC9j c3MiIGlkPSJvd2FQYXJhU3R5bGUiPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBjbGFzcz0iIiBz dHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQiIGZwc3R5bGU9IjEiIG9jc2k9IjAiPg0KPGRpdiBz dHlsZT0iZGlyZWN0aW9uOiBsdHI7Zm9udC1mYW1pbHk6IFRhaG9tYTtjb2xvcjogIzAwMDAwMDtm b250LXNpemU6IDEwcHQ7Ij5HdW50ZXIgLSB0aGF0J3MgZXhhY3RseSB0aGUgcG9pbnQuIFRoZSBp ZGVhIGlzIHRvIGhhdmUgc29tZXRoaW5nIHRoYXQgZG9lcyBub3QgcmVxdWlyZSBzdGFuZGFyZHMg Ym9keSBjb29yZGluYXRpb24gYW5kIGNvdWxkIGJlIHVzZWQgaW4gYWQtaG9jIGZhc2hpb24uIE5h dHVyYWxseSwgdGhlcmUgYXJlIGRvd25zaWRlcw0KIHRvIHRoaXMgYXBwcm9hY2ggKGUuZy4gb3V0 LW9mLWJhbmQgY29vcmRpbmF0aW9uIG5lZWRlZCksIGJ1dCBJIGZlZWwgdGhhdCBrZWVwaW5nIGl0 IHNpbXBsZSBpcyBtb3JlIGltcG9ydGFudC4gUGx1cywgdGhpcyBzaW1wbGljaXR5IG1ha2VzIGlt cGxlbWVudGF0aW9uIHJlYWxseSBzdHJhaWdodGZvcndhcmQgOikNCjxkaXY+PGJyPg0KPGRpdj4N CjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBUaW1lcyBOZXcgUm9tYW47IGNvbG9yOiAjMDAwMDAw OyBmb250LXNpemU6IDE2cHgiPg0KPGhyIHRhYmluZGV4PSItMSI+DQo8ZGl2IGlkPSJkaXZScEYx MDI3NzciIHN0eWxlPSJkaXJlY3Rpb246IGx0cjsiPjxmb250IGZhY2U9IlRhaG9tYSIgc2l6ZT0i MiIgY29sb3I9IiMwMDAwMDAiPjxiPkZyb206PC9iPiBHdW50ZXIgVmFuIERlIFZlbGRlIFtndW50 ZXJ2YW5kZXZlbGRlY2NAaWNsb3VkLmNvbV08YnI+DQo8Yj5TZW50OjwvYj4gU3VuZGF5LCBNYXJj aCAxMywgMjAxNiAxOjExIEFNPGJyPg0KPGI+VG86PC9iPiBQZXRyIExhcHVraG92PGJyPg0KPGI+ Q2M6PC9iPiBSb2JlcnQgUmFzenVrOyBpZHIgd2c8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtJ ZHJdIFVzZSBvZiBCR1AgZm9yIE9wYXF1ZSBTaWduYWxpbmc8YnI+DQo8L2ZvbnQ+PGJyPg0KPC9k aXY+DQo8ZGl2PjwvZGl2Pg0KPGRpdj4NCjxkaXYgY2xhc3M9IiI+aW1vIHRoZSBwcm9taXNlIG9m IGEgcHJvcG9zYWwgbGlrZSB0aGlzIG9uZSwgaXMgdGhhdCBpdCBhbGxvd3MgQXBwbGljYXRpb24g ZGV2ZWxvcG1lbnQgYXQgRGV2T3BzIHNwZWVkIGFuZCByZW1vdmVzIHNsb3duZXNzIG9mIGluZHVz dHJ5IGJvZGllcyBmb3IgaW5ub3ZhdGlvbi48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNz PSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkkgYmVsaWV2ZSBpdCBpcyBhIHZhbGlkIHByb2Js ZW0gc3BhY2UgdGhhdCBpcyBiZWluZyBhZGRyZXNzZWQuIE1heWJlIHNvbWUgZmVhdHVyZXMvb3B0 aW1pc2F0aW9ucyBmcm9tIEVWTiBjb3VsZCBiZSB0cmFuc3BsYW50ZWQ/IChpLmUuIERlc2lnbmF0 ZWQgcm91dGVyIHNlbGVjdGlvbiwgYWxpYXNpbmcgYW5kIG1hc3Mtd2l0aGRyYXcpPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5HLzwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxk aXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24g MTMgTWFyIDIwMTYsIGF0IDA0OjIwLCBQZXRyIExhcHVraG92ICZsdDs8YSBocmVmPSJtYWlsdG86 cGV0ckBmYi5jb20iIGNsYXNzPSIiIHRhcmdldD0iX2JsYW5rIj5wZXRyQGZiLmNvbTwvYT4mZ3Q7 IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxk aXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJmb250LXN0eWxlOm5vcm1hbDsgZm9u dC12YXJpYW50Om5vcm1hbDsgZm9udC13ZWlnaHQ6bm9ybWFsOyBsZXR0ZXItc3BhY2luZzpub3Jt YWw7IG9ycGhhbnM6YXV0bzsgdGV4dC1hbGlnbjpzdGFydDsgdGV4dC1pbmRlbnQ6MHB4OyB0ZXh0 LXRyYW5zZm9ybTpub25lOyB3aGl0ZS1zcGFjZTpub3JtYWw7IHdpZG93czphdXRvOyB3b3JkLXNw YWNpbmc6MHB4OyBkaXJlY3Rpb246bHRyOyBmb250LWZhbWlseTpUYWhvbWE7IGZvbnQtc2l6ZTox MHB0Ij4NCiZndDsmbmJzcDs8c3BhbiBjbGFzcz0iIiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWws aGVsdmV0aWNhLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTpzbWFsbCI+SW4gZmFjdCBJIGFtIG5vdCBj b252aW5jZWQgcDJtcCBpcyB0aGUgYmVzdCB3YXkgdG8gZ28gd2l0aCBoZXJlLiZuYnNwOzwvc3Bh bj4NCjxkaXYgY2xhc3M9IiI+PHNwYW4gY2xhc3M9IiIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFs LGhlbHZldGljYSxzYW5zLXNlcmlmOyBmb250LXNpemU6c21hbGwiPiZndDsgUHViLXN1YiB3aXRo b3V0IFJUQyBoYWNrcyBtYXkgYmUgbXVjaCBiZXR0ZXIgLSBkb24ndCB5b3UgaG9uZXN0bHkgdGhp bmsgPyZuYnNwOzwvc3Bhbj48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgZmFjZT0iYXJpYWws IGhlbHZldGljYSwgc2Fucy1zZXJpZiIgc2l6ZT0iMiIgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0K PC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBmYWNlPSJhcmlhbCwgaGVsdmV0aWNh LCBzYW5zLXNlcmlmIiBzaXplPSIyIiBjbGFzcz0iIj5Ob3QgZXhhY3RseSwgYnV0IG1heWJlIEkg bWlzdW5kZXJzdG9vZCB3aGF0IHAybXAgbWVhbnMgOikgVGhlIG1haW4gYWR2YW50YWdlIG9mIHVz aW5nIEJHUCAoYXQgbGVhc3QgaW4gb3VyIGVudmlyb25tZW50KSBjb21lcyBmcm9tIHRoZSBmYWN0 IHRoYXQgaXQncyBhbHJlYWR5IGJvb3RzdHJhcHBlZCB3aGVuIG9uLXN3aXRjaA0KIChvciBvbi1z ZXJ2ZXIpIGFwcGxpY2F0aW9ucyBzdGFydCBjb21pbmcgdXAuIEFuZCBpdCBzdGF5cyB0aGVyZSBl dmVuIHdoZW4gdGhlIHNlcnZlcnMgaG9zdGluZyBleHRlcm5hbCBrZXktdmFsdWUgc3RvcmUgbWF5 IGJlIGdvbmUuJm5ic3A7PC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBmYWNlPSJh cmlhbCwgaGVsdmV0aWNhLCBzYW5zLXNlcmlmIiBzaXplPSIyIiBjbGFzcz0iIj48YnIgY2xhc3M9 IiI+DQo8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGZhY2U9ImFyaWFsLCBoZWx2 ZXRpY2EsIHNhbnMtc2VyaWYiIHNpemU9IjIiIGNsYXNzPSIiPkFzaWRlIGZyb20gdGhpcywgSSBm dWxseSBhZ3JlZSAtIGl0IGRvZXMgbm90IG9mZmVyIG11Y2ggbW9yZSB0aGFuIGFueSBrZXktdmFs dWUgc3RvcmUuIEFuZCBpdCBoYXMgaXRzIG93biBjb25zdHJhaW50cywgbGlrZSB+NEsgdmFsdWUg c2l6ZS4gUGx1cywgaXQncyBub3QgZXZlbiBhIHByb3BlciBwdWItc3ViLCBzaW5jZQ0KIHRoZXJl IGlzIG5vIGRpc2NyZWV0IG1lc3NhZ2Ugc2VtYW50aWMgLSBvbmx5IHN0YXRlIGRpc3NlbWluYXRp b24gOik8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGZhY2U9ImFyaWFsLCBoZWx2 ZXRpY2EsIHNhbnMtc2VyaWYiIHNpemU9IjIiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZm9u dD4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9ImZvbnQtZmFtaWx5OidUaW1lcyBOZXcgUm9tYW4nOyBm b250LXNpemU6MTZweCI+DQo8aHIgdGFiaW5kZXg9Ii0xIiBjbGFzcz0iIj4NCjxkaXYgaWQ9ImRp dlJwRjU3NzA4MiIgY2xhc3M9IiIgc3R5bGU9ImRpcmVjdGlvbjpsdHIiPjxmb250IGZhY2U9IlRh aG9tYSIgc2l6ZT0iMiIgY2xhc3M9IiI+PGIgY2xhc3M9IiI+RnJvbTo8L2I+PHNwYW4gY2xhc3M9 IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpycmFz enVrQGdtYWlsLmNvbSIgY2xhc3M9IiIgdGFyZ2V0PSJfYmxhbmsiPnJyYXN6dWtAZ21haWwuY29t PC9hPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5bPGEg aHJlZj0ibWFpbHRvOnJyYXN6dWtAZ21haWwuY29tIiBjbGFzcz0iIiB0YXJnZXQ9Il9ibGFuayI+ cnJhc3p1a0BnbWFpbC5jb208L2E+XQ0KIG9uIGJlaGFsZiBvZiBSb2JlcnQgUmFzenVrIFs8YSBo cmVmPSJtYWlsdG86cm9iZXJ0QHJhc3p1ay5uZXQiIGNsYXNzPSIiIHRhcmdldD0iX2JsYW5rIj5y b2JlcnRAcmFzenVrLm5ldDwvYT5dPGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+U2VudDo8L2I+ PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlNhdHVyZGF5 LCBNYXJjaCAxMiwgMjAxNiA1OjI1IFBNPGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+VG86PC9i PjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5QZXRyIExh cHVraG92PGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+Q2M6PC9iPjxzcGFuIGNsYXNzPSJBcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86ZXhhQGp1bmlw ZXIubmV0IiBjbGFzcz0iIiB0YXJnZXQ9Il9ibGFuayI+ZXhhQGp1bmlwZXIubmV0PC9hPjsgaWRy IHdnPGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+U3ViamVjdDo8L2I+PHNwYW4gY2xhc3M9IkFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlJlOiBVc2Ugb2YgQkdQIGZvciBPcGFx dWUgU2lnbmFsaW5nPGJyIGNsYXNzPSIiPg0KPC9mb250PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFz cz0iIj4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3Rl Ij4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxo ZWx2ZXRpY2Esc2Fucy1zZXJpZjsgZm9udC1zaXplOnNtYWxsIj4NCuKAi0hlbGxvIFBldHIs4oCL PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOzwvZGl2Pg0KPGJsb2NrcXVvdGUgY2xhc3M9Imdt YWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4IDAuOGV4OyBib3JkZXItbGVmdC13 aWR0aDoxcHg7IGJvcmRlci1sZWZ0LWNvbG9yOnJnYigyMDQsMjA0LDIwNCk7IGJvcmRlci1sZWZ0 LXN0eWxlOnNvbGlkOyBwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9ImRp cmVjdGlvbjpsdHI7IGZvbnQtZmFtaWx5OlRhaG9tYTsgZm9udC1zaXplOjEwcHQiPg0KPGRpdiBj bGFzcz0iIj48c3BhbiBjbGFzcz0iIiBzdHlsZT0iZm9udC1zaXplOjEwcHQiPlJlOiBJbXBhY3Qg b24gcm91dGluZy4gSSBzaG91bGQgYmUgbW9yZSBleHBsaWNpdCBzdGF0aW5nIHRoYXQgdGhlIGlk ZWEgaXMgZm9yIEJHUCB0byBub3QgaW50ZXJwcmV0IHRoZSBrZXktdmFsdWUgbWFwcGluZ3MgaW4g YW55IHdheS48L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXYgY2xhc3M9 IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iZ21h aWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlm OyBmb250LXNpemU6c21hbGwiPg0K4oCLVGhhdCB3YXMgdmVyeSBjbGVhciBhbHJlYWR5LiBCdXQg aWYgeW91IGxvb2sgYXQgbnVtYmVyIG9mIEJHUCBpbXBsZW1lbnRhdGlvbnMgcmVjb2duaXppbmcg dGhlIEFGSS9TQUZJIGNvbWluZyBvdmVyIHNpbmdsZSBzZXNzaW9uIGlzIG5vdCBkb25lIGltbWVk aWF0ZWx5IGluIHRoZSBCR1AgbWVzc2FnZSBwYXJzaW5nLiBUaGF0IGlzIG15IG1haW4gcG9pbnQg c3VnZ2VzdGluZyB0cmFuc3BvcnQgaW5zdGFuY2UgcG9ydC4mbmJzcDs8L2Rpdj4NCjxkaXYgY2xh c3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fu cy1zZXJpZjsgZm9udC1zaXplOnNtYWxsIj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxz YW5zLXNlcmlmOyBmb250LXNpemU6c21hbGwiPg0KSSBubyBsb25nZXIgYmVsaWV2ZSBtdWx0aXNl c3Npb25zIHdpbGwgZG8gaXQgbmVpdGhlciB0aGF0IHdlIGNvdWxkIG9mZiBsb2FkIGl0IGFzIGlt cGxlbWVudGF0aW9uIHNwZWNpZmljIHRoaW5nLuKAizwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOzwvZGl2Pg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWls X3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4IDAuOGV4OyBib3JkZXItbGVmdC13aWR0 aDoxcHg7IGJvcmRlci1sZWZ0LWNvbG9yOnJnYigyMDQsMjA0LDIwNCk7IGJvcmRlci1sZWZ0LXN0 eWxlOnNvbGlkOyBwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9ImRpcmVj dGlvbjpsdHI7IGZvbnQtZmFtaWx5OlRhaG9tYTsgZm9udC1zaXplOjEwcHQiPg0KPGRpdiBjbGFz cz0iIj48c3BhbiBjbGFzcz0iIiBzdHlsZT0iZm9udC1zaXplOjEwcHQiPlRoZSBjb25zdW1lciAo cnVubmluZyBvbiBzYW1lIGRldmljZSwgcG9zc2libHkpIG1heSBzdGlsbCBpbmZsdWVuY2Ugcm91 dGluZyBiYXNlZCBvbiBpdHMgaW50ZXJwcmV0YXRpb24gb2YgZGF0YSwgZWl0aGVyIGJ5IGFjY2Vz c2luZyB0aGUgcGxhdGZvcm0gU0RLIG9yIGJ5IHBlcmZvcm1pbmcgQkdQIHJvdXRpbmcgaW5qZWN0 aW9uIG92ZXIgdGhlIGNvcnJlc3BvbmRpbmcNCiBBRkkvU0FGSS48L3NwYW4+PGJyIGNsYXNzPSIi Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNz PSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIg c3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmOyBmb250LXNpemU6 c21hbGwiPg0K4oCLVGhhdCBpcyBleGFjdGx5IHRoZSBpc3N1ZS4gVGhlIG9ubHkgd2F5IEJHUC1M UyB3ZW50IGJ5IHdhcyB0aGUgY2xhaW0gYWJvdXQgdGhlaXIgZXhwbGljaXQgZGlzam9pbnRlZCB0 b3BvbG9neSBmcm9tIGV4aXN0aW5nIEJHUC4gSXQgd2FzIHdlbGwgcG9zaXRpb25lZCB0aGF0IEJH UC1MUyBjYW4gYmUgY29tcGxldGVseSBpbmNvbmdydWVudCB3aXRoICZxdW90O3JvdXRpbmcmcXVv dDsgQkdQLiDigIs8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4N CjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2 ZXRpY2Esc2Fucy1zZXJpZjsgZm9udC1zaXplOnNtYWxsIj4NCuKAi1RoZSBwb3NzaWJsZSBjaGFu bmVscyB0aGUgSUdQIGluZm9ybWF0aW9uIG1heSBpbXBhY3Qgcm91dGluZyB3ZXJlIGNsYXNzaWZp ZWQgYXMgb3V0IG9mIHRoZSBiYW5kIGxpa2VseSBjb21pbmcgdmlhIHNvbWUgb3RoZXIgd2F5cyBm cm9tIGNvbnRyb2xsZXJzIChJMlJTLCBBUElzLCByb3V0aW5nIEJHUCBTQUZJIGV0YyAuLi4pLiZu YnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5 OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmOyBmb250LXNpemU6c21hbGwiPg0KPGJyIGNsYXNz PSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7PC9kaXY+DQo8YmxvY2tx dW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MHB4IDBweCAwcHggMC44ZXg7 IGJvcmRlci1sZWZ0LXdpZHRoOjFweDsgYm9yZGVyLWxlZnQtY29sb3I6cmdiKDIwNCwyMDQsMjA0 KTsgYm9yZGVyLWxlZnQtc3R5bGU6c29saWQ7IHBhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBjbGFz cz0iIj4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9ImRpcmVjdGlvbjpsdHI7IGZvbnQtZmFtaWx5OlRh aG9tYTsgZm9udC1zaXplOjEwcHQiPg0KPGRpdiBjbGFzcz0iIj48L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+UmU6IFRyYW5zcG9ydCBpbnN0YW5jZS4gSSB0aGluayBpdCdzIGEgZ3JlYXQgaWRlYSB0byBy dW4gdGhpcyBvbiBzZXBhcmF0ZSBpbnN0YW5jZSwgYnV0IHJpZ2h0IG5vdyB3ZSB0eXBpY2FsbHkg cnVuIGp1c3Qgb25lIHByb2Nlc3MsIGFuZCBpdCBhZGRzIHNvbWUgb3BlcmF0aW9uYWwgb3Zlcmhl YWQgdG8gbWFpbnRhaW4gdHdvIG9mIHRoZW0uIEFsc28sIG9mdGVuIHRoaXMgZXh0ZW5zaW9uIGNv dWxkIGJlIHVzZWQganVzdCB3aXRoDQogb3V0LW9mLWJhbmQgcmVmbGVjdGlvbi4gVGhpcyBpcyB3 aHkgSSBmZWVsIGl0IGlzIHJhdGhlciBiZXR0ZXIgdG8ga2VlcCB0aGlzIGFwcGxpY2FibGUgdG8g YW55IHR5cGUgb2YgQkdQIGluc3RhbmNlLjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIi PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9ImdtYWls X2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjsg Zm9udC1zaXplOnNtYWxsIj4NCuKAi0ltYWdpbmUgdGhhdCB5b3Ugd2lsbCBub3QgZ2V0IGZhciBp biB0aGlzIEJHUCBwcm9wb3NhbC4gVGhlbiB3aGF0IGlzIGxlZnQgaXMgbm90aGluZyBlbHNlIGxp a2UgYSBuZXcgcHJvY2VzcyB0YWxraW5nIG92ZXIgb25lIG9mIGZldyBtZXNzYWdlIGJ1c2VzIHRv ZGF5IHRvIGRpc3RyaWJ1dGUgdGhlIHNldCBvZiBpbmZvcm1hdGlvbiB5b3UgbmVlZC4mbmJzcDs8 L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlh bCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjsgZm9udC1zaXplOnNtYWxsIj4NCjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFy aWFsLGhlbHZldGljYSxzYW5zLXNlcmlmOyBmb250LXNpemU6c21hbGwiPg0KSW4gZmFjdCBJIGFt IG5vdCBjb252aW5jZWQgcDJtcCBpcyB0aGUgYmVzdCB3YXkgdG8gZ28gd2l0aCBoZXJlLiBQdWIt c3ViIHdpdGhvdXQgUlRDIGhhY2tzIG1heSBiZSBtdWNoIGJldHRlciAtIGRvbid0IHlvdSBob25l c3RseSB0aGluayA/Jm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHls ZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTpzbWFs bCI+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0 eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjsgZm9udC1zaXplOnNt YWxsIj4NCkJlc3QsPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9u dC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTpzbWFsbCI+DQpS LuKAizwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj4mbmJzcDs8L2Rpdj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90 ZSIgc3R5bGU9Im1hcmdpbjowcHggMHB4IDBweCAwLjhleDsgYm9yZGVyLWxlZnQtd2lkdGg6MXB4 OyBib3JkZXItbGVmdC1jb2xvcjpyZ2IoMjA0LDIwNCwyMDQpOyBib3JkZXItbGVmdC1zdHlsZTpz b2xpZDsgcGFkZGluZy1sZWZ0OjFleCI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIiBz dHlsZT0iZGlyZWN0aW9uOmx0cjsgZm9udC1mYW1pbHk6VGFob21hOyBmb250LXNpemU6MTBwdCI+ DQo8ZGl2IGNsYXNzPSIiPjxzcGFuIGNsYXNzPSIiIHN0eWxlPSJmb250LXNpemU6MTBwdCI+UmU6 IFNjb3BlIG9mIGFwcGxpY2F0aW9uLiBUaGUgbWFpbiBnb2FsIHdhcyB0byB1c2UgdGhpcyBpbiBk YXRhLWNlbnRlciwgYnV0IEkgY2FuIHRoZW9yaXplIHRoaXMgY291bGQgYmUgdXNlZCBhbW9uZyBm ZXcgb3BlcmF0b3JzIHRoYXQgYXJlIHdpbGxpbmcgdG8gZGV2ZWxvcCBvbi1kZXZpY2UgYXBwbGlj YXRpb25zIGFuZCBleGNoYW5nZSBkYXRhIHVzaW5nDQogdGhlIHByZS1lc3RhYmxpc2hlZCBjaGFu bmVscyAoZS5nLiB0aGUgV0lTRVIgdXNlIGNhc2UpLiBJbiB0aGlzIHNpdHVhdGlvbiwgbGltaXRp bmcgc2NvcGUgdG8ganVzdCBwcml2YXRlIEFTTnMgY291bGQgYmUgdHJpY2t5LiBGdXJ0aGVybW9y ZSwgbm9uLXByaXZhdGUgQVNOcyBjb3VsZCBiZSB1c2VkIGluIGRhdGEtY2VudGVyIGFzIHdlbGwg KGp1c3Qgbm90IGV4cG9zZWQgb3V0c2lkZS4uLikuPC9zcGFuPjxiciBjbGFzcz0iIj4NCjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+UmU6 IFRyYW5zaXRpdmUgYXR0cmlidXRlLiBJZGVhbGx5LCBpdCB3b3VsZCBiZSBncmVhdCB0byBjYXJy eSB0aGUgdmFsdWUgaW4gbmV4dC1ob3AgZmllbGQgb2YgTVBfUkVBQ0hfTkxSSSwgYnV0IHRoZSBs ZW5ndGggaXMgbGltaXRlZCB0byA4IGJ5dGVzLCBoZW5jZSB0aGUgbmV3IGF0dHJpYnV0ZS4gSSBk byBub3QgaGF2ZSBzdHJvbmcgYXJndW1lbnRzIHRvIG1ha2luZyB0aGlzIHRyYW5zaXRpdmUsIGl0 IHNob3VsZCBiZSBmaW5lDQogdG8gZ28gd2l0aCBub24tdHJhbnNpdGl2ZSBhbmQgY29ycmVzcG9u ZGluZyBlcnJvciBoYW5kbGluZy4mbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNz PSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlJlOiBTZWN1cml0eS4gU2luY2Ugd2UgZG8gbm90 IGRpcmVjdGx5IGluZmx1ZW5jZSBwYXRoIHNlbGVjdGlvbiB3aXRoIG5ldyBkYXRhLCB0aGUgdGhy ZWF0cyBjb3VsZCBiZSBsaW1pdGVkIHRvIHRob3NlIHRhcmdldGluZyBCR1BpbmZyYSBpdHNlbGYg ZS5nLiBmbG9vZGluZyB3aXRoIGluZm9ybWF0aW9uLCBkaXNydXB0aW5nIHNlc3Npb24gZXRjLiBU aGVyZSBjb3VsZCBiZSBxdWVzdGlvbnMgYWJvdXQgaW5mb3JtYXRpb24gYXV0aGVudGljaXR5LA0K IGJ1dCB0aGlzIGNvdWxkIGJlIGxlZnQgdXAgdG8gdGhlIGFwcGxpY2F0aW9ucyB0byBkZWNpZGUg KGUuZy4gc2lnbmluZyB0aGUga2V5LXZhbHVlIGJpbmRpbmdzKS48L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlJlZ2FyZHMsPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5QZXRyPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4N CjxkaXYgY2xhc3M9IiIgc3R5bGU9ImZvbnQtZmFtaWx5OidUaW1lcyBOZXcgUm9tYW4nOyBmb250 LXNpemU6MTZweCI+DQo8aHIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJkaXJlY3Rp b246bHRyIj48Zm9udCBmYWNlPSJUYWhvbWEiIHNpemU9IjIiIGNsYXNzPSIiPjxiIGNsYXNzPSIi PkZyb206PC9iPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj48YSBocmVmPSJtYWlsdG86cnJhc3p1a0BnbWFpbC5jb20iIGNsYXNzPSIiIHRhcmdldD0iX2Js YW5rIj5ycmFzenVrQGdtYWlsLmNvbTwvYT48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+WzxhIGhyZWY9Im1haWx0bzpycmFzenVrQGdtYWlsLmNvbSIgY2xh c3M9IiIgdGFyZ2V0PSJfYmxhbmsiPnJyYXN6dWtAZ21haWwuY29tPC9hPl0NCiBvbiBiZWhhbGYg b2YgUm9iZXJ0IFJhc3p1ayBbPGEgaHJlZj0ibWFpbHRvOnJvYmVydEByYXN6dWsubmV0IiBjbGFz cz0iIiB0YXJnZXQ9Il9ibGFuayI+cm9iZXJ0QHJhc3p1ay5uZXQ8L2E+XTxiciBjbGFzcz0iIj4N CjxiIGNsYXNzPSIiPlNlbnQ6PC9iPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOzwvc3Bhbj5TYXR1cmRheSwgTWFyY2ggMTIsIDIwMTYgMToxMCBQTTxiciBjbGFzcz0i Ij4NCjxiIGNsYXNzPSIiPlRvOjwvYj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+UGV0ciBMYXB1a2hvdjs8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVk LXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmV4YUBqdW5pcGVyLm5ldCIgY2xh c3M9IiIgdGFyZ2V0PSJfYmxhbmsiPmV4YUBqdW5pcGVyLm5ldDwvYT48YnIgY2xhc3M9IiI+DQo8 YiBjbGFzcz0iIj5DYzo8L2I+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5i c3A7PC9zcGFuPmlkciB3ZzxiciBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPlN1YmplY3Q6PC9iPjxz cGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5Vc2Ugb2YgQkdQ IGZvciBPcGFxdWUgU2lnbmFsaW5nPGJyIGNsYXNzPSIiPg0KPC9mb250PjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9Img1Ij4NCjxkaXYgY2xhc3M9IiI+ PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+DQo8ZGl2IGNs YXNzPSIiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjsgZm9u dC1zaXplOnNtYWxsIj7igItQZXRyLCBFYmVuLDwvZGl2Pg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0i Zm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTpzbWFsbCI+ PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJmb250LWZhbWlseTph cmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjsgZm9udC1zaXplOnNtYWxsIj5JIGhhdmUgZmV3IHF1 ZXN0aW9ucyBhbmQgY29tbWVudHMgdG8geW91ciBwcm9wb3NhbC4mbmJzcDs8L2Rpdj4NCjxkaXYg Y2xhc3M9IiIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmOyBm b250LXNpemU6c21hbGwiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIiBzdHls ZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTpzbWFs bCI+LSBUaGUgZHJhZnQg4oCLYXR0ZW1wdHMgdG8gcmV1c2UgQkdQIG1lY2hhbmlzbSBmb3IgcDJt cCBkaXN0cmlidXRpb24gb2Ygb3BhcXVlIGluZm9ybWF0aW9uLiBUaGF0IGFsb25lIGlzIG5vdCBh IGJhZCB0aGluZyA6KSBIb3dldmVyIHdoZW4geW91IG1ha2UgcmVmZXJlbmNlIHRvIEJHUC1MUyBp dCBuZWVkcyB0byBiZQ0KIG9ic2VydmVkIHRoYXQgQkdQLUxTIGlzIG5vdCBwb3NpdGlvbiB0byBk aXJlY3RseSBpbXBhY3Qgcm91dGluZyAoaWUgY29udGVudCBvZiBSSUIgYW5kIEZJQnMpIHVubGlr ZSBvbmUgb2YgdGhlIHVzZSBjYXNlcyBkZXNjcmliZWQgaW4geW91ciBkcmFmdCBJbnRybyBwYXJh Z3JhcGguIFRoYXQgbWVhbnMgdGhhdCB1bmxpa2UgQkdQLUxTIGl0IG11c3QgY28tZXhpc3Qgd2l0 aCByb3V0aW5nIEJHUCBvbiB0aGUgc2FtZSBCR1Agc3BlYWtlcnMuJm5ic3A7PC9kaXY+DQo8ZGl2 IGNsYXNzPSIiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjsg Zm9udC1zaXplOnNtYWxsIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiIgc3R5 bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmOyBmb250LXNpemU6c21h bGwiPkhlcmUgSSB3b3VsZCBsaWtlIHRvIGJyaW5nIGJhY2sgbXkgcHJvcG9zYWwgdG8gZGVmaW5l IG5ldyBwb3J0IGZvciBUcmFuc3BvcnQgSW5zdGFuY2UgQkdQJm5ic3A7PGEgaHJlZj0iaHR0cHM6 Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX190b29scy5pZXRm Lm9yZ19odG1sX2RyYWZ0LTJEcmFzenVrLTJEdGktMkRiZ3AtMkQwMSZhbXA7ZD1Dd01GYVEmYW1w O2M9NVZEMFJUdE5sVGgzeWNkNDFiM01VdyZhbXA7cj1MVV92SmFNX0VRdTFTc20zNWoyeGxBJmFt cDttPTc1US1udlgyUmhoeFltLXIyQkl4Rmh0SXBLelQ5cEVnR3g5VVdqcTZmVDQmYW1wO3M9a0s3 MWVTcVdCSVRhbEcxWTFpTldhaUhhU0E3dnJNTW5MNGxraWVhcTJ1WSZhbXA7ZT0iIGNsYXNzPSIi IHRhcmdldD0iX2JsYW5rIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcmFzenVr LXRpLWJncC0wMTwvYT48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+d2hpY2gNCiBhdCB0aGUgdGltZSBvZiBkaXNjdXNzaW9uIHdhcyBzdXBwb3NlZCB0byBi ZSBzaG9ydGx5IGFkZHJlc3NlZCBieSBkeW5hbWljIHBvcnQgYWxsb2NhdGlvbnMgb2YgbXVsdGlz ZXNzaW9ucyB3aGljaCB0byB0aGUgYmVzdCBvZiBteSBrbm93bGVkZ2UgbmV2ZXIgaGFwcGVuZWQu Jm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2 ZXRpY2Esc2Fucy1zZXJpZjsgZm9udC1zaXplOnNtYWxsIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9IiIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNl cmlmOyBmb250LXNpemU6c21hbGwiPlNvIGZpcnN0IGNvbW1lbnQgaXMgdGhhdCBpZiB3ZSBnbyB3 aXRoIHJldXNpbmcgQkdQLTQgZm9yIHRoaXMgdHlwZSBvZiBzaWduYWxsaW5nIGxldCdzIGVuZm9y Y2UgaXQncyBlYXJseSBzZXBhcmF0aW9uIGZyb20gJnF1b3Q7Y2xhc3NpYyZxdW90OyBCR1AuJm5i c3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRp Y2Esc2Fucy1zZXJpZjsgZm9udC1zaXplOnNtYWxsIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9IiIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlm OyBmb250LXNpemU6c21hbGwiPi0gU2Vjb25kIGNvbW1lbnQgaXMgcmVsYXRlZCB0byB0aGUgc2Nv cGUgb2YgdXNlLiBJZiB0aGUgc2NvcGUgaXMgcHJpdmF0ZSAtIGxldCdzIHBlcmhhcHMgZW5mb3Jj ZSBpdCBtb3JlIGV4cGxpY2l0bHkgc3VjaCB0aGF0IGJ5IHRoZSBzcGVjIGl0IGlzIGlsbGVnYWwg QUZJL1NBRkkgcGFpciBpbiB0aGUgcHVibGljDQogSW50ZXJuZXQuIEZvciBleGFtcGxlIGJ5IHN0 YXRpbmcgdGhhdCBpdCBpcyBpbGxlZ2FsIHRvIGhhdmUgbm9uIHByaXZhdGUgQVMgaW4gdGhlIEFT X1BBVEggb2Ygc3VjaCBVUERBVEUgbXNnLiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIiBzdHls ZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTpzbWFs bCI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJmb250LWZhbWls eTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjsgZm9udC1zaXplOnNtYWxsIj4tIFRoaXJkIHRo ZSBkcmFmdCBzdGF0ZXMgdGhhdCB0aGVyZSBpcyBubyBuZXcgc2VjdXJpdHkgaW1wbGljYXRpb25z IC4uIHdlbGwgaWYgdGhlIHNjb3BlIGlzIG5vbiBwcml2YXRlIEkgYW0gYWZyYWlkIHRoYXQgaXMg bm8gdGhlIGNhc2UuIEFzIHlvdSBoYXZlIHNlZW4gKGFuZCBzdGlsbCBzZWVpbmcpIHNlY3VyaW5n DQogQkdQIFVQREFURSBNU0cgaXMgTVBfUkVBQ0ggY29udGVudCBkZXBlbmRlbnQuIElmIGNvbnRl bnQgaXMgZnJlZSBmb3JtIEkgYW0gYWZyYWlkIGl0IHdpbGwgYmUgcmF0aGVyIGhhcmQgdG8gc2Vj dXJlIGl0IHdlbGwgOikmbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9ImZvbnQtZmFt aWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmOyBmb250LXNpemU6c21hbGwiPjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVs dmV0aWNhLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTpzbWFsbCI+LSBMYXN0IGFzIG9wYXF1ZSB2YWx1 ZSBjb250YWluZXIgeW91IGFyZSBkZWZpbmluZyBhbiB0cmFuc2l0aXZlIGF0dHJpYnV0ZSA/IElz IHRoZSBpbnRlbnRpb24gdG8gdXNlIHRoaXMgYXR0cmlidXRlIGluIGV4aXN0aW5nIEFGSS9TQUZJ cyBhcyB3ZWxsID8gT3RoZXJ3aXNlIGlmIG5vdCB3aHkgZG8geW91IG5lZWQNCiB0aGlzIHRvIGJl IHRyYW5zaXRpdmUgaWYgY2FwYWJpbGl0eSBuZWdvdGlhdGlvbiBhbHJlYWR5IG1heSBpbXBsaWNp dGx5IGRlZmluZSBpdCdzIHN1cHBvcnQgYnkgbmV3IEFGSS9TQUZJLjwvZGl2Pg0KPGRpdiBjbGFz cz0iIiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7IGZvbnQt c2l6ZTpzbWFsbCI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJm b250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjsgZm9udC1zaXplOnNtYWxsIj5D aGVlcnMsPGJyIGNsYXNzPSIiPg0KUi48L2Rpdj4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9ImZvbnQt ZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmOyBmb250LXNpemU6c21hbGwiPjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWws aGVsdmV0aWNhLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTpzbWFsbCI+UFMuJm5ic3A7PC9kaXY+DQo8 ZGl2IGNsYXNzPSIiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJp ZjsgZm9udC1zaXplOnNtYWxsIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiIg c3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmOyBmb250LXNpemU6 c21hbGwiPjxzcGFuIGNsYXNzPSIiIHN0eWxlPSJmb250LWZhbWlseTpUYWhvbWE7IGZvbnQtc2l6 ZToxMy4zMzMzcHgiPiZndDsgVGhlcmUgaXMgYW4gb25nb2luZyBkaXNjdXNzaW9uIGFyb3VuZCBh dm9pZGluZyBOTFJJIChrZXkpIGNvbGxpc2lvbnMuPC9zcGFuPjxiciBjbGFzcz0iIj4NCjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMt c2VyaWY7IGZvbnQtc2l6ZTpzbWFsbCI+PHNwYW4gY2xhc3M9IiIgc3R5bGU9ImZvbnQtZmFtaWx5 OlRhaG9tYTsgZm9udC1zaXplOjEzLjMzMzNweCI+PGJyIGNsYXNzPSIiPg0KPC9zcGFuPjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMt c2VyaWY7IGZvbnQtc2l6ZTpzbWFsbCI+PHNwYW4gY2xhc3M9IiIgc3R5bGU9ImZvbnQtZmFtaWx5 OlRhaG9tYTsgZm9udC1zaXplOjEzLjMzMzNweCI+V2hlcmUgaXMgc3VjaCBkaXNjdXNzaW9uIHRh a2luZyBwbGFjZSA/IFNob3VsZG4ndCBJRFIgYmUgcGVyaGFwcyBpbiB0aGUgbG9vcCBhIGJpdCA6 KSZuYnNwOzwvc3Bhbj48L2Rpdj4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9ImZvbnQtZmFtaWx5OmFy aWFsLGhlbHZldGljYSxzYW5zLXNlcmlmOyBmb250LXNpemU6c21hbGwiPjxzcGFuIGNsYXNzPSIi IHN0eWxlPSJmb250LWZhbWlseTpUYWhvbWE7IGZvbnQtc2l6ZToxMy4zMzMzcHgiPjxiciBjbGFz cz0iIj4NCjwvc3Bhbj48L2Rpdj4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9ImZvbnQtZmFtaWx5OmFy aWFsLGhlbHZldGljYSxzYW5zLXNlcmlmOyBmb250LXNpemU6c21hbGwiPjxzcGFuIGNsYXNzPSIi IHN0eWxlPSJmb250LWZhbWlseTpUYWhvbWE7IGZvbnQtc2l6ZToxMy4zMzMzcHgiPjxiciBjbGFz cz0iIj4NCjwvc3Bhbj48L2Rpdj4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9ImZvbnQtZmFtaWx5OmFy aWFsLGhlbHZldGljYSxzYW5zLXNlcmlmOyBmb250LXNpemU6c21hbGwiPjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNh LHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTpzbWFsbCI+Jm5ic3A7PC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8c3BhbiBjbGFzcz0iIiBzdHlsZT0iZm9udC1mYW1pbHk6 SGVsdmV0aWNhOyBmb250LXNpemU6MTJweDsgZm9udC1zdHlsZTpub3JtYWw7IGZvbnQtdmFyaWFu dDpub3JtYWw7IGZvbnQtd2VpZ2h0Om5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6bm9ybWFsOyBvcnBo YW5zOmF1dG87IHRleHQtYWxpZ246c3RhcnQ7IHRleHQtaW5kZW50OjBweDsgdGV4dC10cmFuc2Zv cm06bm9uZTsgd2hpdGUtc3BhY2U6bm9ybWFsOyB3aWRvd3M6YXV0bzsgd29yZC1zcGFjaW5nOjBw eDsgZmxvYXQ6bm9uZTsgZGlzcGxheTppbmxpbmUhaW1wb3J0YW50Ij5fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvc3Bhbj48YnIgY2xhc3M9IiIgc3R5bGU9 ImZvbnQtZmFtaWx5OkhlbHZldGljYTsgZm9udC1zaXplOjEycHg7IGZvbnQtc3R5bGU6bm9ybWFs OyBmb250LXZhcmlhbnQ6bm9ybWFsOyBmb250LXdlaWdodDpub3JtYWw7IGxldHRlci1zcGFjaW5n Om5vcm1hbDsgb3JwaGFuczphdXRvOyB0ZXh0LWFsaWduOnN0YXJ0OyB0ZXh0LWluZGVudDowcHg7 IHRleHQtdHJhbnNmb3JtOm5vbmU7IHdoaXRlLXNwYWNlOm5vcm1hbDsgd2lkb3dzOmF1dG87IHdv cmQtc3BhY2luZzowcHgiPg0KPHNwYW4gY2xhc3M9IiIgc3R5bGU9ImZvbnQtZmFtaWx5OkhlbHZl dGljYTsgZm9udC1zaXplOjEycHg7IGZvbnQtc3R5bGU6bm9ybWFsOyBmb250LXZhcmlhbnQ6bm9y bWFsOyBmb250LXdlaWdodDpub3JtYWw7IGxldHRlci1zcGFjaW5nOm5vcm1hbDsgb3JwaGFuczph dXRvOyB0ZXh0LWFsaWduOnN0YXJ0OyB0ZXh0LWluZGVudDowcHg7IHRleHQtdHJhbnNmb3JtOm5v bmU7IHdoaXRlLXNwYWNlOm5vcm1hbDsgd2lkb3dzOmF1dG87IHdvcmQtc3BhY2luZzowcHg7IGZs b2F0Om5vbmU7IGRpc3BsYXk6aW5saW5lIWltcG9ydGFudCI+SWRyDQogbWFpbGluZyBsaXN0PC9z cGFuPjxiciBjbGFzcz0iIiBzdHlsZT0iZm9udC1mYW1pbHk6SGVsdmV0aWNhOyBmb250LXNpemU6 MTJweDsgZm9udC1zdHlsZTpub3JtYWw7IGZvbnQtdmFyaWFudDpub3JtYWw7IGZvbnQtd2VpZ2h0 Om5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6bm9ybWFsOyBvcnBoYW5zOmF1dG87IHRleHQtYWxpZ246 c3RhcnQ7IHRleHQtaW5kZW50OjBweDsgdGV4dC10cmFuc2Zvcm06bm9uZTsgd2hpdGUtc3BhY2U6 bm9ybWFsOyB3aWRvd3M6YXV0bzsgd29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBjbGFzcz0iIiBz dHlsZT0iZm9udC1mYW1pbHk6SGVsdmV0aWNhOyBmb250LXNpemU6MTJweDsgZm9udC1zdHlsZTpu b3JtYWw7IGZvbnQtdmFyaWFudDpub3JtYWw7IGZvbnQtd2VpZ2h0Om5vcm1hbDsgbGV0dGVyLXNw YWNpbmc6bm9ybWFsOyBvcnBoYW5zOmF1dG87IHRleHQtYWxpZ246c3RhcnQ7IHRleHQtaW5kZW50 OjBweDsgdGV4dC10cmFuc2Zvcm06bm9uZTsgd2hpdGUtc3BhY2U6bm9ybWFsOyB3aWRvd3M6YXV0 bzsgd29yZC1zcGFjaW5nOjBweDsgZmxvYXQ6bm9uZTsgZGlzcGxheTppbmxpbmUhaW1wb3J0YW50 Ij48YSBocmVmPSJtYWlsdG86SWRyQGlldGYub3JnIiBjbGFzcz0iIiB0YXJnZXQ9Il9ibGFuayI+ SWRyQGlldGYub3JnPC9hPjwvc3Bhbj48YnIgY2xhc3M9IiIgc3R5bGU9ImZvbnQtZmFtaWx5Okhl bHZldGljYTsgZm9udC1zaXplOjEycHg7IGZvbnQtc3R5bGU6bm9ybWFsOyBmb250LXZhcmlhbnQ6 bm9ybWFsOyBmb250LXdlaWdodDpub3JtYWw7IGxldHRlci1zcGFjaW5nOm5vcm1hbDsgb3JwaGFu czphdXRvOyB0ZXh0LWFsaWduOnN0YXJ0OyB0ZXh0LWluZGVudDowcHg7IHRleHQtdHJhbnNmb3Jt Om5vbmU7IHdoaXRlLXNwYWNlOm5vcm1hbDsgd2lkb3dzOmF1dG87IHdvcmQtc3BhY2luZzowcHgi Pg0KPHNwYW4gY2xhc3M9IiIgc3R5bGU9ImZvbnQtZmFtaWx5OkhlbHZldGljYTsgZm9udC1zaXpl OjEycHg7IGZvbnQtc3R5bGU6bm9ybWFsOyBmb250LXZhcmlhbnQ6bm9ybWFsOyBmb250LXdlaWdo dDpub3JtYWw7IGxldHRlci1zcGFjaW5nOm5vcm1hbDsgb3JwaGFuczphdXRvOyB0ZXh0LWFsaWdu OnN0YXJ0OyB0ZXh0LWluZGVudDowcHg7IHRleHQtdHJhbnNmb3JtOm5vbmU7IHdoaXRlLXNwYWNl Om5vcm1hbDsgd2lkb3dzOmF1dG87IHdvcmQtc3BhY2luZzowcHg7IGZsb2F0Om5vbmU7IGRpc3Bs YXk6aW5saW5lIWltcG9ydGFudCI+PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9p bnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19p ZHImYW1wO2Q9Q3dNRmFRJmFtcDtjPTVWRDBSVHRObFRoM3ljZDQxYjNNVXcmYW1wO3I9TFVfdkph TV9FUXUxU3NtMzVqMnhsQSZhbXA7bT1LWUpnMURCeGM2R2djNEhReXhGM1hNTWx3c2xQZldLR2Fy ZkpEZ2VXWEVVJmFtcDtzPWVNazhONDRTbnNUWGxzOFFOM0ktQzBzVHQzWnYtQmUtdENBWHJNeDBf cHcmYW1wO2U9IiBjbGFzcz0iIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9pZHI8L2E+PC9zcGFuPjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_3F437107848A5140A6A19222EFFB3481200E32DDPRNMBX012TheFac_-- From nobody Sun Mar 13 09:37:19 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B40A12D671 for ; Sun, 13 Mar 2016 09:37:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.731 X-Spam-Level: X-Spam-Status: No, score=-0.731 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com 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 VGugsrkNUJJz for ; Sun, 13 Mar 2016 09:37:14 -0700 (PDT) Received: from mx0b-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.30]) (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 D1A6112D665 for ; Sun, 13 Mar 2016 09:37:13 -0700 (PDT) Received: from pps.filterd (m0089730.ppops.net [127.0.0.1]) by m0089730.ppops.net (8.16.0.11/8.16.0.11) with SMTP id u2DGZjFc012059; Sun, 13 Mar 2016 09:37:11 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=9cTC0wpv7CxIpEkdfhN+XOHgiGgrzR4i52ofg9zQR5s=; b=Mxb3o2ZBlNC95fOcRC8w5TTLZ8x+p366iaP/DOH5wjVCPlFYxVZF2BdvnpG5WyQcA4X6 RA5g8t2/XHJOqzBro7qtOK+73qFLGkAnKo5GA+hLas9zFUKKzA8h1FxHdJQ+Zx6IInRV 5fIITUeBsM2+/sRby3TZTYHrzsPnpX6D1sY= Received: from mail.thefacebook.com ([199.201.64.23]) by m0089730.ppops.net with ESMTP id 21mh3wuh78-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Sun, 13 Mar 2016 09:37:11 -0700 Received: from PRN-MBX01-2.TheFacebook.com ([169.254.3.204]) by PRN-CHUB01.TheFacebook.com ([fe80::d5cc:849:f520:db6b%12]) with mapi id 14.03.0248.002; Sun, 13 Mar 2016 09:37:09 -0700 From: Petr Lapukhov To: Robert Raszuk , Gunter Van De Velde Thread-Topic: [Idr] Use of BGP for Opaque Signaling Thread-Index: AQHRfKONNK1upwIbukaCHqWz2SNu2p9WgK6PgACao4D//5fqt4AA2ZQAgABhOwD//54QBQ== Date: Sun, 13 Mar 2016 16:37:08 +0000 Message-ID: <3F437107848A5140A6A19222EFFB3481200E335E@PRN-MBX01-2.TheFacebook.com> References: <3F437107848A5140A6A19222EFFB3481200E2839@PRN-MBX01-2.TheFacebook.com> <3F437107848A5140A6A19222EFFB3481200E2A32@PRN-MBX01-2.TheFacebook.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.52.123] Content-Type: multipart/alternative; boundary="_000_3F437107848A5140A6A19222EFFB3481200E335EPRNMBX012TheFac_" MIME-Version: 1.0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-03-13_04:, , signatures=0 Archived-At: Cc: idr wg Subject: Re: [Idr] Use of BGP for Opaque Signaling X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2016 16:37:17 -0000 --_000_3F437107848A5140A6A19222EFFB3481200E335EPRNMBX012TheFac_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Um9iZXJ0LCBJIHRvdGFsbHkgbG9va2VkIGF0IHRoZSB3aWRlIGNvbW11bml0aWVzIGJlZm9yZSB0 cnlpbmcgdGhlIG9wYXF1ZSBzdHVmZi4gSG93ZXZlciwgdGhlcmUgd2FzIHNvbWUgc2VtYW50aWNh bCBhd2t3YXJkbmVzcyBpbiByZWdhcmQgdG8gdHJhbnNwb3J0aW5nIG9wYXF1ZSBkYXRhLiBFLmcu LCB5b3UgbmVlZCBhbiBOTFJJIG9mIHNvbWUga2luZCB0byBhdHRhY2ggdGhlIGNvbW11bml0aWVz LCBpLmUuIGV2ZXJ5IG9yaWdpbmF0b3IgbmVlZHMgdG8gaW5qZWN0IGEgcHJlZml4IC0gd2hpY2gg aXNuJ3QgdG9vIGJhZCBpbXBsZW1lbnRhdGlvbiB3aXNlLCBidXQgdGllcyBpbmZvcm1hdGlvbiBk aXN0cmlidXRpb24gdG8gcmVhY2hhYmlsaXR5IGluZm8sIHJlcXVpcmluZyBhIHBvbGljeSB0byBp Z25vcmUgdGhpcyByZWFjaGFiaWxpdHkgaW5mb3JtYXRpb24uIEkgcmVhbGx5IGRvbid0IGxpa2Ug YWRkaW5nIG1vcmUgcG9saWNpZXMgOikNCg0KRnVydGhlcm1vcmUsIHdpZGUgY29tbXVuaXRpZXMg Y291bGQgYmUgaW50ZXJwcmV0ZWQgYnkgQkdQIHByb2Nlc3MsIGFuZCBoZW5jZSB0aGVpciBpbXBs ZW1lbnRhdGlvbiBpcyBhIGJpdCBtb3JlIGludm9sdmVkIGFuZCByZXF1aXJlcyBtb3JlIGludGVy b3AgdGVzdGluZy4gVGhlIG9wYXF1ZSBBRkkgc2ltcGx5IGFjdHMgYXMgYSBwaXBlIHRvIGRpc3Nl bWluYXRlIGJpdHMgaW4gdGhlIGRvbWFpbiAoZS5nLiB3ZSB1c2UgdGhyaWZ0IHRvIGVuY29kZSB2 YWx1ZXMpLiBJbXBsZW1lbnRpbmcgaXQgcmVxdWlyZXMgYWNjZXB0aW5nIHRoZSBuZXcgQUZJL1NB RkkgYW5kIHNraXBwaW5nIElQLXNwZWNpZmljIHBvbGljeSBjb2RlIChlLmcuIGZpbHRlcmluZyBv bmx5IG9uIGF0dHJpYnV0ZXMpLg0KDQpNb3N0IGltcG9ydGFudGx5LCBvcGFxdWUgZGF0YSBpcyAi ZnJlZSIgb2YgYW55IHN0cnVjdHVyZSB0aGF0IGNvdWxkIHJlcXVpcmUgZnVydGhlciBzdGFuZGFy ZGl6YXRpb24gOikgVGhpcyBpcyBvbiBwdXJwb3NlIC0gSSB3YXMgaG9waW5nIHRvIGhhdmUgdGhp cyBjaGFubmVsIGRlZmluZWQgb25jZSwgYW5kIGxldCBpdCBnbyB3aXRob3V0IGFueSBmdXJ0aGVy IG5lZWQgb2YgZGVmaW5pbmcgYWRkaXRpb25hbCBzdWItc3RydWN0dXJlcy4uLg0KDQpQUw0KVGhl IDY0SyBtZXNzYWdlcyB3b3VsZCBiZSBwcmV0dHkgYXdlc29tZSEgOikgSGF2aW5nIHRoZSA0SyBs aW1pdCBpbiBzb21lIGNhc2VzIHJlcXVpcmVzIGFubm95aW5nIHZhbHVlIGZyYWdtZW50YXRpb24u IFVnaC4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IHJyYXN6dWtA Z21haWwuY29tIFtycmFzenVrQGdtYWlsLmNvbV0gb24gYmVoYWxmIG9mIFJvYmVydCBSYXN6dWsg W3JvYmVydEByYXN6dWsubmV0XQ0KU2VudDogU3VuZGF5LCBNYXJjaCAxMywgMjAxNiA3OjU5IEFN DQpUbzogR3VudGVyIFZhbiBEZSBWZWxkZQ0KQ2M6IFBldHIgTGFwdWtob3Y7IGlkciB3Zw0KU3Vi amVjdDogUmU6IFtJZHJdIFVzZSBvZiBCR1AgZm9yIE9wYXF1ZSBTaWduYWxpbmcNCg0KSGkgR3Vu dGVyLA0KDQpGb3IgZGlzc2VtaW5hdGlvbiBvZiBpbmZvcm1hdGlvbiBwcm9kdWNlZCBieSBuZXR3 b3JrIGFwcGxpY2F0aW9ucyB3ZSBhbHJlYWR5IGhhdmUgdG9kYXkgdmFyaW91cyB0b29scyBiZSBp dCBhbnNpYmxlLCBjaGVmLCBwdXBwZXQgZXRjIC4uLg0KDQpJZiB0aGVyZSBpcyBuZWVkIHRvIHVz ZSBpbnRlci1kb21haW4gZGlzdHJpYnV0aW9uIG9mIHN1Y2ggYXBwbGljYXRpb25zIEkgc2VlIG5v IHJlYXNvbiB3aHkgbm90IHRvIGRlZmluZSByZWdpc3RlcmVkIG9yIHByaXZhdGUgd2lkZSBiZ3Ag Y29tbXVuaXR5IGFuZCB1c2UgdGhpcyBhcyB0cmFuc3BvcnQgaW5zdGVhZCBvZiBuZXcgU0FGSSBv biBhbHJlYWR5IGVzdGFibGlzaGVkIEJHUCBzZXNzaW9ucy4gTm90ZSB0aGF0IHdpZGUgQkdQIGNv bW11bml0eSBwcmVjaXNlbHkgbGlrZSBuZXcgYXR0cmlidXRlIGJlaW5nIHByb3Bvc2VkIGhlcmUg Y2FuIGNhcnJ5IG9wYXF1ZSB0byBCR1AgZGF0YS4NCg0KSGkgUGV0ciwNCg0KRG8geW91IHNlZSBh bnkgaXNzdWUgd2l0aCB0aGUgYWJvdmUgd2lkZSBjb21tdW5pdHkgYXBwcm9hY2ggdG8gYWRkcmVz cyB5b3UgbmVlZHMgPyBFc3BlY2lhbGx5IGZvciBib290c3RyYXBwaW5nIHRoZSB0cmFuc3BvcnQg aXQgaXMgZXZlbiBlYXNpZXIgYXMgeW91IGRvIG5vdCBuZWVkIHRvIGVuYWJsZSBuZXcgU0FGSS4g QW5kIHRob3NlIGFyZSBhbHJlYWR5IElEUiBXRyBkb2NzLg0KDQpodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtaWV0Zi1pZHItd2lkZS1iZ3AtY29tbXVuaXRpZXMtMDE8aHR0cHM6Ly91 cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX190b29scy5pZXRmLm9y Z19odG1sX2RyYWZ0LTJEaWV0Zi0yRGlkci0yRHdpZGUtMkRiZ3AtMkRjb21tdW5pdGllcy0yRDAx JmQ9Q3dNRmFRJmM9NVZEMFJUdE5sVGgzeWNkNDFiM01VdyZyPUxVX3ZKYU1fRVF1MVNzbTM1ajJ4 bEEmbT1oLTdFSm51ZGJCaFl4dGxrZ04tRHZIM0VRd3haa0JmTjlZbGtXR3FyZzhnJnM9Y0dIM2JL eFRBbTFYaXkxcWt3bzNmNjlVanF2d1RUaktxdTJXNG5yWWhHOCZlPT4NCmh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWlkci1yZWdpc3RlcmVkLXdpZGUtYmdwLWNvbW11bml0 aWVzLTAxPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0z QV9fdG9vbHMuaWV0Zi5vcmdfaHRtbF9kcmFmdC0yRGlldGYtMkRpZHItMkRyZWdpc3RlcmVkLTJE d2lkZS0yRGJncC0yRGNvbW11bml0aWVzLTJEMDEmZD1Dd01GYVEmYz01VkQwUlR0TmxUaDN5Y2Q0 MWIzTVV3JnI9TFVfdkphTV9FUXUxU3NtMzVqMnhsQSZtPWgtN0VKbnVkYkJoWXh0bGtnTi1Edkgz RVF3eFprQmZOOVlsa1dHcXJnOGcmcz1iQXBHQVMwVmM2NUktNUpYUEViUk15bXZpY292SEtaWUFy WFV3YlpjUmFVJmU9Pg0KDQpBcyBmYXIgYXMgbGltaXQgb2YgNEsgbGV0J3MgYWxsIG5vdGUgdGhh dCB3ZSBhbHJlYWR5IGhhdmUgYSBkcmFmdCBhZGRyZXNzaW5nIHRoaXMgYW5kIG1vdmluZyB0aGUg bGltaXQgdG8gNjVLOiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1pZHIt YmdwLWV4dGVuZGVkLW1lc3NhZ2VzLTExPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNv bS92Mi91cmw/dT1odHRwcy0zQV9fdG9vbHMuaWV0Zi5vcmdfaHRtbF9kcmFmdC0yRGlldGYtMkRp ZHItMkRiZ3AtMkRleHRlbmRlZC0yRG1lc3NhZ2VzLTJEMTEmZD1Dd01GYVEmYz01VkQwUlR0TmxU aDN5Y2Q0MWIzTVV3JnI9TFVfdkphTV9FUXUxU3NtMzVqMnhsQSZtPWgtN0VKbnVkYkJoWXh0bGtn Ti1EdkgzRVF3eFprQmZOOVlsa1dHcXJnOGcmcz00NHNuMkc0czB5TWZyYk5mN0dHdGNmZDFJbm12 cFJFNmF4dEtock0zYlZVJmU9Pg0KDQpDaGVlcnMsDQpyLg0KDQoNCg0KDQoNCk9uIFN1biwgTWFy IDEzLCAyMDE2IGF0IDU6MTEgQU0sIEd1bnRlciBWYW4gRGUgVmVsZGUgPGd1bnRlcnZhbmRldmVs ZGVjY0BpY2xvdWQuY29tPG1haWx0bzpndW50ZXJ2YW5kZXZlbGRlY2NAaWNsb3VkLmNvbT4+IHdy b3RlOg0KaW1vIHRoZSBwcm9taXNlIG9mIGEgcHJvcG9zYWwgbGlrZSB0aGlzIG9uZSwgaXMgdGhh dCBpdCBhbGxvd3MgQXBwbGljYXRpb24gZGV2ZWxvcG1lbnQgYXQgRGV2T3BzIHNwZWVkIGFuZCBy ZW1vdmVzIHNsb3duZXNzIG9mIGluZHVzdHJ5IGJvZGllcyBmb3IgaW5ub3ZhdGlvbi4NCg0KSSBi ZWxpZXZlIGl0IGlzIGEgdmFsaWQgcHJvYmxlbSBzcGFjZSB0aGF0IGlzIGJlaW5nIGFkZHJlc3Nl ZC4gTWF5YmUgc29tZSBmZWF0dXJlcy9vcHRpbWlzYXRpb25zIGZyb20gRVZOIGNvdWxkIGJlIHRy YW5zcGxhbnRlZD8gKGkuZS4gRGVzaWduYXRlZCByb3V0ZXIgc2VsZWN0aW9uLCBhbGlhc2luZyBh bmQgbWFzcy13aXRoZHJhdykNCg0KRy8NCg0KDQpPbiAxMyBNYXIgMjAxNiwgYXQgMDQ6MjAsIFBl dHIgTGFwdWtob3YgPHBldHJAZmIuY29tPG1haWx0bzpwZXRyQGZiLmNvbT4+IHdyb3RlOg0KDQo+ IEluIGZhY3QgSSBhbSBub3QgY29udmluY2VkIHAybXAgaXMgdGhlIGJlc3Qgd2F5IHRvIGdvIHdp dGggaGVyZS4NCj4gUHViLXN1YiB3aXRob3V0IFJUQyBoYWNrcyBtYXkgYmUgbXVjaCBiZXR0ZXIg LSBkb24ndCB5b3UgaG9uZXN0bHkgdGhpbmsgPw0KDQpOb3QgZXhhY3RseSwgYnV0IG1heWJlIEkg bWlzdW5kZXJzdG9vZCB3aGF0IHAybXAgbWVhbnMgOikgVGhlIG1haW4gYWR2YW50YWdlIG9mIHVz aW5nIEJHUCAoYXQgbGVhc3QgaW4gb3VyIGVudmlyb25tZW50KSBjb21lcyBmcm9tIHRoZSBmYWN0 IHRoYXQgaXQncyBhbHJlYWR5IGJvb3RzdHJhcHBlZCB3aGVuIG9uLXN3aXRjaCAob3Igb24tc2Vy dmVyKSBhcHBsaWNhdGlvbnMgc3RhcnQgY29taW5nIHVwLiBBbmQgaXQgc3RheXMgdGhlcmUgZXZl biB3aGVuIHRoZSBzZXJ2ZXJzIGhvc3RpbmcgZXh0ZXJuYWwga2V5LXZhbHVlIHN0b3JlIG1heSBi ZSBnb25lLg0KDQpBc2lkZSBmcm9tIHRoaXMsIEkgZnVsbHkgYWdyZWUgLSBpdCBkb2VzIG5vdCBv ZmZlciBtdWNoIG1vcmUgdGhhbiBhbnkga2V5LXZhbHVlIHN0b3JlLiBBbmQgaXQgaGFzIGl0cyBv d24gY29uc3RyYWludHMsIGxpa2UgfjRLIHZhbHVlIHNpemUuIFBsdXMsIGl0J3Mgbm90IGV2ZW4g YSBwcm9wZXIgcHViLXN1Yiwgc2luY2UgdGhlcmUgaXMgbm8gZGlzY3JlZXQgbWVzc2FnZSBzZW1h bnRpYyAtIG9ubHkgc3RhdGUgZGlzc2VtaW5hdGlvbiA6KQ0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KRnJvbTogcnJhc3p1a0BnbWFpbC5jb208bWFpbHRvOnJyYXN6dWtAZ21h aWwuY29tPiBbcnJhc3p1a0BnbWFpbC5jb208bWFpbHRvOnJyYXN6dWtAZ21haWwuY29tPl0gb24g YmVoYWxmIG9mIFJvYmVydCBSYXN6dWsgW3JvYmVydEByYXN6dWsubmV0PG1haWx0bzpyb2JlcnRA cmFzenVrLm5ldD5dDQpTZW50OiBTYXR1cmRheSwgTWFyY2ggMTIsIDIwMTYgNToyNSBQTQ0KVG86 IFBldHIgTGFwdWtob3YNCkNjOiBleGFAanVuaXBlci5uZXQ8bWFpbHRvOmV4YUBqdW5pcGVyLm5l dD47IGlkciB3Zw0KU3ViamVjdDogUmU6IFVzZSBvZiBCR1AgZm9yIE9wYXF1ZSBTaWduYWxpbmcN Cg0K4oCLSGVsbG8gUGV0cizigIsNCg0KUmU6IEltcGFjdCBvbiByb3V0aW5nLiBJIHNob3VsZCBi ZSBtb3JlIGV4cGxpY2l0IHN0YXRpbmcgdGhhdCB0aGUgaWRlYSBpcyBmb3IgQkdQIHRvIG5vdCBp bnRlcnByZXQgdGhlIGtleS12YWx1ZSBtYXBwaW5ncyBpbiBhbnkgd2F5Lg0KDQrigItUaGF0IHdh cyB2ZXJ5IGNsZWFyIGFscmVhZHkuIEJ1dCBpZiB5b3UgbG9vayBhdCBudW1iZXIgb2YgQkdQIGlt cGxlbWVudGF0aW9ucyByZWNvZ25pemluZyB0aGUgQUZJL1NBRkkgY29taW5nIG92ZXIgc2luZ2xl IHNlc3Npb24gaXMgbm90IGRvbmUgaW1tZWRpYXRlbHkgaW4gdGhlIEJHUCBtZXNzYWdlIHBhcnNp bmcuIFRoYXQgaXMgbXkgbWFpbiBwb2ludCBzdWdnZXN0aW5nIHRyYW5zcG9ydCBpbnN0YW5jZSBw b3J0Lg0KDQpJIG5vIGxvbmdlciBiZWxpZXZlIG11bHRpc2Vzc2lvbnMgd2lsbCBkbyBpdCBuZWl0 aGVyIHRoYXQgd2UgY291bGQgb2ZmIGxvYWQgaXQgYXMgaW1wbGVtZW50YXRpb24gc3BlY2lmaWMg dGhpbmcu4oCLDQoNCg0KVGhlIGNvbnN1bWVyIChydW5uaW5nIG9uIHNhbWUgZGV2aWNlLCBwb3Nz aWJseSkgbWF5IHN0aWxsIGluZmx1ZW5jZSByb3V0aW5nIGJhc2VkIG9uIGl0cyBpbnRlcnByZXRh dGlvbiBvZiBkYXRhLCBlaXRoZXIgYnkgYWNjZXNzaW5nIHRoZSBwbGF0Zm9ybSBTREsgb3IgYnkg cGVyZm9ybWluZyBCR1Agcm91dGluZyBpbmplY3Rpb24gb3ZlciB0aGUgY29ycmVzcG9uZGluZyBB RkkvU0FGSS4NCg0K4oCLVGhhdCBpcyBleGFjdGx5IHRoZSBpc3N1ZS4gVGhlIG9ubHkgd2F5IEJH UC1MUyB3ZW50IGJ5IHdhcyB0aGUgY2xhaW0gYWJvdXQgdGhlaXIgZXhwbGljaXQgZGlzam9pbnRl ZCB0b3BvbG9neSBmcm9tIGV4aXN0aW5nIEJHUC4gSXQgd2FzIHdlbGwgcG9zaXRpb25lZCB0aGF0 IEJHUC1MUyBjYW4gYmUgY29tcGxldGVseSBpbmNvbmdydWVudCB3aXRoICJyb3V0aW5nIiBCR1Au IOKAiw0KDQrigItUaGUgcG9zc2libGUgY2hhbm5lbHMgdGhlIElHUCBpbmZvcm1hdGlvbiBtYXkg aW1wYWN0IHJvdXRpbmcgd2VyZSBjbGFzc2lmaWVkIGFzIG91dCBvZiB0aGUgYmFuZCBsaWtlbHkg Y29taW5nIHZpYSBzb21lIG90aGVyIHdheXMgZnJvbSBjb250cm9sbGVycyAoSTJSUywgQVBJcywg cm91dGluZyBCR1AgU0FGSSBldGMgLi4uKS4NCg0KDQpSZTogVHJhbnNwb3J0IGluc3RhbmNlLiBJ IHRoaW5rIGl0J3MgYSBncmVhdCBpZGVhIHRvIHJ1biB0aGlzIG9uIHNlcGFyYXRlIGluc3RhbmNl LCBidXQgcmlnaHQgbm93IHdlIHR5cGljYWxseSBydW4ganVzdCBvbmUgcHJvY2VzcywgYW5kIGl0 IGFkZHMgc29tZSBvcGVyYXRpb25hbCBvdmVyaGVhZCB0byBtYWludGFpbiB0d28gb2YgdGhlbS4g QWxzbywgb2Z0ZW4gdGhpcyBleHRlbnNpb24gY291bGQgYmUgdXNlZCBqdXN0IHdpdGggb3V0LW9m LWJhbmQgcmVmbGVjdGlvbi4gVGhpcyBpcyB3aHkgSSBmZWVsIGl0IGlzIHJhdGhlciBiZXR0ZXIg dG8ga2VlcCB0aGlzIGFwcGxpY2FibGUgdG8gYW55IHR5cGUgb2YgQkdQIGluc3RhbmNlLg0KDQoN CuKAi0ltYWdpbmUgdGhhdCB5b3Ugd2lsbCBub3QgZ2V0IGZhciBpbiB0aGlzIEJHUCBwcm9wb3Nh bC4gVGhlbiB3aGF0IGlzIGxlZnQgaXMgbm90aGluZyBlbHNlIGxpa2UgYSBuZXcgcHJvY2VzcyB0 YWxraW5nIG92ZXIgb25lIG9mIGZldyBtZXNzYWdlIGJ1c2VzIHRvZGF5IHRvIGRpc3RyaWJ1dGUg dGhlIHNldCBvZiBpbmZvcm1hdGlvbiB5b3UgbmVlZC4NCg0KSW4gZmFjdCBJIGFtIG5vdCBjb252 aW5jZWQgcDJtcCBpcyB0aGUgYmVzdCB3YXkgdG8gZ28gd2l0aCBoZXJlLiBQdWItc3ViIHdpdGhv dXQgUlRDIGhhY2tzIG1heSBiZSBtdWNoIGJldHRlciAtIGRvbid0IHlvdSBob25lc3RseSB0aGlu ayA/DQoNCkJlc3QsDQpSLuKAiw0KDQoNClJlOiBTY29wZSBvZiBhcHBsaWNhdGlvbi4gVGhlIG1h aW4gZ29hbCB3YXMgdG8gdXNlIHRoaXMgaW4gZGF0YS1jZW50ZXIsIGJ1dCBJIGNhbiB0aGVvcml6 ZSB0aGlzIGNvdWxkIGJlIHVzZWQgYW1vbmcgZmV3IG9wZXJhdG9ycyB0aGF0IGFyZSB3aWxsaW5n IHRvIGRldmVsb3Agb24tZGV2aWNlIGFwcGxpY2F0aW9ucyBhbmQgZXhjaGFuZ2UgZGF0YSB1c2lu ZyB0aGUgcHJlLWVzdGFibGlzaGVkIGNoYW5uZWxzIChlLmcuIHRoZSBXSVNFUiB1c2UgY2FzZSku IEluIHRoaXMgc2l0dWF0aW9uLCBsaW1pdGluZyBzY29wZSB0byBqdXN0IHByaXZhdGUgQVNOcyBj b3VsZCBiZSB0cmlja3kuIEZ1cnRoZXJtb3JlLCBub24tcHJpdmF0ZSBBU05zIGNvdWxkIGJlIHVz ZWQgaW4gZGF0YS1jZW50ZXIgYXMgd2VsbCAoanVzdCBub3QgZXhwb3NlZCBvdXRzaWRlLi4uKS4N Cg0KUmU6IFRyYW5zaXRpdmUgYXR0cmlidXRlLiBJZGVhbGx5LCBpdCB3b3VsZCBiZSBncmVhdCB0 byBjYXJyeSB0aGUgdmFsdWUgaW4gbmV4dC1ob3AgZmllbGQgb2YgTVBfUkVBQ0hfTkxSSSwgYnV0 IHRoZSBsZW5ndGggaXMgbGltaXRlZCB0byA4IGJ5dGVzLCBoZW5jZSB0aGUgbmV3IGF0dHJpYnV0 ZS4gSSBkbyBub3QgaGF2ZSBzdHJvbmcgYXJndW1lbnRzIHRvIG1ha2luZyB0aGlzIHRyYW5zaXRp dmUsIGl0IHNob3VsZCBiZSBmaW5lIHRvIGdvIHdpdGggbm9uLXRyYW5zaXRpdmUgYW5kIGNvcnJl c3BvbmRpbmcgZXJyb3IgaGFuZGxpbmcuDQoNClJlOiBTZWN1cml0eS4gU2luY2Ugd2UgZG8gbm90 IGRpcmVjdGx5IGluZmx1ZW5jZSBwYXRoIHNlbGVjdGlvbiB3aXRoIG5ldyBkYXRhLCB0aGUgdGhy ZWF0cyBjb3VsZCBiZSBsaW1pdGVkIHRvIHRob3NlIHRhcmdldGluZyBCR1BpbmZyYSBpdHNlbGYg ZS5nLiBmbG9vZGluZyB3aXRoIGluZm9ybWF0aW9uLCBkaXNydXB0aW5nIHNlc3Npb24gZXRjLiBU aGVyZSBjb3VsZCBiZSBxdWVzdGlvbnMgYWJvdXQgaW5mb3JtYXRpb24gYXV0aGVudGljaXR5LCBi dXQgdGhpcyBjb3VsZCBiZSBsZWZ0IHVwIHRvIHRoZSBhcHBsaWNhdGlvbnMgdG8gZGVjaWRlIChl LmcuIHNpZ25pbmcgdGhlIGtleS12YWx1ZSBiaW5kaW5ncykuDQoNClJlZ2FyZHMsDQoNClBldHIN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IHJyYXN6dWtAZ21haWwu Y29tPG1haWx0bzpycmFzenVrQGdtYWlsLmNvbT4gW3JyYXN6dWtAZ21haWwuY29tPG1haWx0bzpy cmFzenVrQGdtYWlsLmNvbT5dIG9uIGJlaGFsZiBvZiBSb2JlcnQgUmFzenVrIFtyb2JlcnRAcmFz enVrLm5ldDxtYWlsdG86cm9iZXJ0QHJhc3p1ay5uZXQ+XQ0KU2VudDogU2F0dXJkYXksIE1hcmNo IDEyLCAyMDE2IDE6MTAgUE0NClRvOiBQZXRyIExhcHVraG92OyBleGFAanVuaXBlci5uZXQ8bWFp bHRvOmV4YUBqdW5pcGVyLm5ldD4NCkNjOiBpZHIgd2cNClN1YmplY3Q6IFVzZSBvZiBCR1AgZm9y IE9wYXF1ZSBTaWduYWxpbmcNCg0K4oCLUGV0ciwgRWJlbiwNCg0KSSBoYXZlIGZldyBxdWVzdGlv bnMgYW5kIGNvbW1lbnRzIHRvIHlvdXIgcHJvcG9zYWwuDQoNCi0gVGhlIGRyYWZ0IOKAi2F0dGVt cHRzIHRvIHJldXNlIEJHUCBtZWNoYW5pc20gZm9yIHAybXAgZGlzdHJpYnV0aW9uIG9mIG9wYXF1 ZSBpbmZvcm1hdGlvbi4gVGhhdCBhbG9uZSBpcyBub3QgYSBiYWQgdGhpbmcgOikgSG93ZXZlciB3 aGVuIHlvdSBtYWtlIHJlZmVyZW5jZSB0byBCR1AtTFMgaXQgbmVlZHMgdG8gYmUgb2JzZXJ2ZWQg dGhhdCBCR1AtTFMgaXMgbm90IHBvc2l0aW9uIHRvIGRpcmVjdGx5IGltcGFjdCByb3V0aW5nIChp ZSBjb250ZW50IG9mIFJJQiBhbmQgRklCcykgdW5saWtlIG9uZSBvZiB0aGUgdXNlIGNhc2VzIGRl c2NyaWJlZCBpbiB5b3VyIGRyYWZ0IEludHJvIHBhcmFncmFwaC4gVGhhdCBtZWFucyB0aGF0IHVu bGlrZSBCR1AtTFMgaXQgbXVzdCBjby1leGlzdCB3aXRoIHJvdXRpbmcgQkdQIG9uIHRoZSBzYW1l IEJHUCBzcGVha2Vycy4NCg0KSGVyZSBJIHdvdWxkIGxpa2UgdG8gYnJpbmcgYmFjayBteSBwcm9w b3NhbCB0byBkZWZpbmUgbmV3IHBvcnQgZm9yIFRyYW5zcG9ydCBJbnN0YW5jZSBCR1AgaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXJhc3p1ay10aS1iZ3AtMDE8aHR0cHM6Ly91cmxk ZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX190b29scy5pZXRmLm9yZ19o dG1sX2RyYWZ0LTJEcmFzenVrLTJEdGktMkRiZ3AtMkQwMSZkPUN3TUZhUSZjPTVWRDBSVHRObFRo M3ljZDQxYjNNVXcmcj1MVV92SmFNX0VRdTFTc20zNWoyeGxBJm09NzVRLW52WDJSaGh4WW0tcjJC SXhGaHRJcEt6VDlwRWdHeDlVV2pxNmZUNCZzPWtLNzFlU3FXQklUYWxHMVkxaU5XYWlIYVNBN3Zy TU1uTDRsa2llYXEydVkmZT0+IHdoaWNoIGF0IHRoZSB0aW1lIG9mIGRpc2N1c3Npb24gd2FzIHN1 cHBvc2VkIHRvIGJlIHNob3J0bHkgYWRkcmVzc2VkIGJ5IGR5bmFtaWMgcG9ydCBhbGxvY2F0aW9u cyBvZiBtdWx0aXNlc3Npb25zIHdoaWNoIHRvIHRoZSBiZXN0IG9mIG15IGtub3dsZWRnZSBuZXZl ciBoYXBwZW5lZC4NCg0KU28gZmlyc3QgY29tbWVudCBpcyB0aGF0IGlmIHdlIGdvIHdpdGggcmV1 c2luZyBCR1AtNCBmb3IgdGhpcyB0eXBlIG9mIHNpZ25hbGxpbmcgbGV0J3MgZW5mb3JjZSBpdCdz IGVhcmx5IHNlcGFyYXRpb24gZnJvbSAiY2xhc3NpYyIgQkdQLg0KDQotIFNlY29uZCBjb21tZW50 IGlzIHJlbGF0ZWQgdG8gdGhlIHNjb3BlIG9mIHVzZS4gSWYgdGhlIHNjb3BlIGlzIHByaXZhdGUg LSBsZXQncyBwZXJoYXBzIGVuZm9yY2UgaXQgbW9yZSBleHBsaWNpdGx5IHN1Y2ggdGhhdCBieSB0 aGUgc3BlYyBpdCBpcyBpbGxlZ2FsIEFGSS9TQUZJIHBhaXIgaW4gdGhlIHB1YmxpYyBJbnRlcm5l dC4gRm9yIGV4YW1wbGUgYnkgc3RhdGluZyB0aGF0IGl0IGlzIGlsbGVnYWwgdG8gaGF2ZSBub24g cHJpdmF0ZSBBUyBpbiB0aGUgQVNfUEFUSCBvZiBzdWNoIFVQREFURSBtc2cuDQoNCi0gVGhpcmQg dGhlIGRyYWZ0IHN0YXRlcyB0aGF0IHRoZXJlIGlzIG5vIG5ldyBzZWN1cml0eSBpbXBsaWNhdGlv bnMgLi4gd2VsbCBpZiB0aGUgc2NvcGUgaXMgbm9uIHByaXZhdGUgSSBhbSBhZnJhaWQgdGhhdCBp cyBubyB0aGUgY2FzZS4gQXMgeW91IGhhdmUgc2VlbiAoYW5kIHN0aWxsIHNlZWluZykgc2VjdXJp bmcgQkdQIFVQREFURSBNU0cgaXMgTVBfUkVBQ0ggY29udGVudCBkZXBlbmRlbnQuIElmIGNvbnRl bnQgaXMgZnJlZSBmb3JtIEkgYW0gYWZyYWlkIGl0IHdpbGwgYmUgcmF0aGVyIGhhcmQgdG8gc2Vj dXJlIGl0IHdlbGwgOikNCg0KLSBMYXN0IGFzIG9wYXF1ZSB2YWx1ZSBjb250YWluZXIgeW91IGFy ZSBkZWZpbmluZyBhbiB0cmFuc2l0aXZlIGF0dHJpYnV0ZSA/IElzIHRoZSBpbnRlbnRpb24gdG8g dXNlIHRoaXMgYXR0cmlidXRlIGluIGV4aXN0aW5nIEFGSS9TQUZJcyBhcyB3ZWxsID8gT3RoZXJ3 aXNlIGlmIG5vdCB3aHkgZG8geW91IG5lZWQgdGhpcyB0byBiZSB0cmFuc2l0aXZlIGlmIGNhcGFi aWxpdHkgbmVnb3RpYXRpb24gYWxyZWFkeSBtYXkgaW1wbGljaXRseSBkZWZpbmUgaXQncyBzdXBw b3J0IGJ5IG5ldyBBRkkvU0FGSS4NCg0KQ2hlZXJzLA0KUi4NCg0KUFMuDQoNCj4gVGhlcmUgaXMg YW4gb25nb2luZyBkaXNjdXNzaW9uIGFyb3VuZCBhdm9pZGluZyBOTFJJIChrZXkpIGNvbGxpc2lv bnMuDQoNCldoZXJlIGlzIHN1Y2ggZGlzY3Vzc2lvbiB0YWtpbmcgcGxhY2UgPyBTaG91bGRuJ3Qg SURSIGJlIHBlcmhhcHMgaW4gdGhlIGxvb3AgYSBiaXQgOikNCg0KDQoNCg0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KSWRyIG1haWxpbmcgbGlzdA0K SWRyQGlldGYub3JnPG1haWx0bzpJZHJAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2lkcjxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIv dXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lkciZkPUN3TUZh USZjPTVWRDBSVHRObFRoM3ljZDQxYjNNVXcmcj1MVV92SmFNX0VRdTFTc20zNWoyeGxBJm09aC03 RUpudWRiQmhZeHRsa2dOLUR2SDNFUXd4WmtCZk45WWxrV0dxcmc4ZyZzPVVFakR0Q3E1ejR1T1JL MkJBOVdxZzZJOE1uYnh4dGFqUnIzM0RXLWRXV00mZT0+DQoNCg0K --_000_3F437107848A5140A6A19222EFFB3481200E335EPRNMBX012TheFac_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgZGlyPSJsdHIiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUi IGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8c3R5bGUgdHlwZT0idGV4dC9j c3MiIGlkPSJvd2FQYXJhU3R5bGUiPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBmcHN0eWxlPSIx IiBvY3NpPSIwIj4NCjxkaXYgc3R5bGU9ImRpcmVjdGlvbjogbHRyO2ZvbnQtZmFtaWx5OiBUYWhv bWE7Y29sb3I6ICMwMDAwMDA7Zm9udC1zaXplOiAxMHB0OyI+Um9iZXJ0LCBJIHRvdGFsbHkgbG9v a2VkIGF0IHRoZSB3aWRlIGNvbW11bml0aWVzIGJlZm9yZSB0cnlpbmcgdGhlIG9wYXF1ZSBzdHVm Zi4gSG93ZXZlciwgdGhlcmUgd2FzIHNvbWUgc2VtYW50aWNhbCBhd2t3YXJkbmVzcyBpbiByZWdh cmQgdG8gdHJhbnNwb3J0aW5nIG9wYXF1ZSBkYXRhLiBFLmcuLCB5b3UNCiBuZWVkIGFuIE5MUkkg b2Ygc29tZSBraW5kIHRvIGF0dGFjaCB0aGUgY29tbXVuaXRpZXMsIGkuZS4gZXZlcnkgb3JpZ2lu YXRvciBuZWVkcyB0byBpbmplY3QgYSBwcmVmaXggLSB3aGljaCBpc24ndCB0b28gYmFkIGltcGxl bWVudGF0aW9uIHdpc2UsIGJ1dCB0aWVzIGluZm9ybWF0aW9uIGRpc3RyaWJ1dGlvbiB0byByZWFj aGFiaWxpdHkgaW5mbywgcmVxdWlyaW5nIGEgcG9saWN5IHRvIGlnbm9yZSB0aGlzIHJlYWNoYWJp bGl0eSBpbmZvcm1hdGlvbi4NCiBJIHJlYWxseSBkb24ndCBsaWtlIGFkZGluZyBtb3JlIHBvbGlj aWVzIDopJm5ic3A7DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5GdXJ0aGVybW9yZSwgd2lkZSBj b21tdW5pdGllcyBjb3VsZCBiZSBpbnRlcnByZXRlZCBieSBCR1AgcHJvY2VzcywgYW5kIGhlbmNl IHRoZWlyIGltcGxlbWVudGF0aW9uIGlzIGEgYml0IG1vcmUgaW52b2x2ZWQgYW5kIHJlcXVpcmVz IG1vcmUgaW50ZXJvcCB0ZXN0aW5nLiBUaGUgb3BhcXVlIEFGSSBzaW1wbHkgYWN0cyBhcyBhIHBp cGUgdG8gZGlzc2VtaW5hdGUgYml0cyBpbiB0aGUgZG9tYWluIChlLmcuIHdlIHVzZSB0aHJpZnQg dG8gZW5jb2RlDQogdmFsdWVzKS4gSW1wbGVtZW50aW5nIGl0IHJlcXVpcmVzIGFjY2VwdGluZyB0 aGUgbmV3IEFGSS9TQUZJIGFuZCBza2lwcGluZyBJUC1zcGVjaWZpYyBwb2xpY3kgY29kZSAoZS5n LiBmaWx0ZXJpbmcgb25seSBvbiBhdHRyaWJ1dGVzKS48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+ DQo8ZGl2Pk1vc3QgaW1wb3J0YW50bHksIG9wYXF1ZSBkYXRhIGlzICZxdW90O2ZyZWUmcXVvdDsg b2YgYW55IHN0cnVjdHVyZSB0aGF0IGNvdWxkIHJlcXVpcmUgZnVydGhlciBzdGFuZGFyZGl6YXRp b24gOikgVGhpcyBpcyBvbiBwdXJwb3NlIC0gSSB3YXMgaG9waW5nIHRvIGhhdmUgdGhpcyBjaGFu bmVsIGRlZmluZWQgb25jZSwgYW5kIGxldCBpdCBnbyB3aXRob3V0IGFueSBmdXJ0aGVyIG5lZWQg b2YgZGVmaW5pbmcgYWRkaXRpb25hbCBzdWItc3RydWN0dXJlcy4uLjwvZGl2Pg0KPGRpdj48YnI+ DQo8L2Rpdj4NCjxkaXY+UFM8L2Rpdj4NCjxkaXY+VGhlIDY0SyBtZXNzYWdlcyB3b3VsZCBiZSBw cmV0dHkgYXdlc29tZSEgOikgSGF2aW5nIHRoZSA0SyBsaW1pdCBpbiBzb21lIGNhc2VzIHJlcXVp cmVzIGFubm95aW5nIHZhbHVlIGZyYWdtZW50YXRpb24uIFVnaC48YnI+DQo8ZGl2Pjxicj4NCjxk aXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBUaW1lcyBOZXcgUm9tYW47IGNvbG9yOiAjMDAwMDAwOyBm b250LXNpemU6IDE2cHgiPg0KPGhyIHRhYmluZGV4PSItMSI+DQo8ZGl2IGlkPSJkaXZScEY1MzY3 IiBzdHlsZT0iZGlyZWN0aW9uOiBsdHI7Ij48Zm9udCBmYWNlPSJUYWhvbWEiIHNpemU9IjIiIGNv bG9yPSIjMDAwMDAwIj48Yj5Gcm9tOjwvYj4gcnJhc3p1a0BnbWFpbC5jb20gW3JyYXN6dWtAZ21h aWwuY29tXSBvbiBiZWhhbGYgb2YgUm9iZXJ0IFJhc3p1ayBbcm9iZXJ0QHJhc3p1ay5uZXRdPGJy Pg0KPGI+U2VudDo8L2I+IFN1bmRheSwgTWFyY2ggMTMsIDIwMTYgNzo1OSBBTTxicj4NCjxiPlRv OjwvYj4gR3VudGVyIFZhbiBEZSBWZWxkZTxicj4NCjxiPkNjOjwvYj4gUGV0ciBMYXB1a2hvdjsg aWRyIHdnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbSWRyXSBVc2Ugb2YgQkdQIGZvciBPcGFx dWUgU2lnbmFsaW5nPGJyPg0KPC9mb250Pjxicj4NCjwvZGl2Pg0KPGRpdj48L2Rpdj4NCjxkaXY+ DQo8ZGl2IGRpcj0ibHRyIj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250 LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjsgZm9udC1zaXplOnNtYWxsIj4NCkhp IEd1bnRlciw8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZh bWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjsgZm9udC1zaXplOnNtYWxsIj4NCjxicj4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFy aWFsLGhlbHZldGljYSxzYW5zLXNlcmlmOyBmb250LXNpemU6c21hbGwiPg0KRm9yIGRpc3NlbWlu YXRpb24gb2YgaW5mb3JtYXRpb24gcHJvZHVjZWQgYnkgbmV0d29yayBhcHBsaWNhdGlvbnMgd2Ug YWxyZWFkeSBoYXZlIHRvZGF5IHZhcmlvdXMgdG9vbHMgYmUgaXQgYW5zaWJsZSwgY2hlZiwgcHVw cGV0IGV0YyAuLi4mbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxl PSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjsgZm9udC1zaXplOnNtYWxs Ij4NCjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQt ZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmOyBmb250LXNpemU6c21hbGwiPg0KSWYg dGhlcmUgaXMgbmVlZCB0byB1c2UgaW50ZXItZG9tYWluIGRpc3RyaWJ1dGlvbiBvZiBzdWNoIGFw cGxpY2F0aW9ucyBJIHNlZSBubyByZWFzb24gd2h5IG5vdCB0byBkZWZpbmUgcmVnaXN0ZXJlZCBv ciBwcml2YXRlIHdpZGUgYmdwIGNvbW11bml0eSBhbmQgdXNlIHRoaXMgYXMgdHJhbnNwb3J0IGlu c3RlYWQgb2YgbmV3IFNBRkkgb24gYWxyZWFkeSBlc3RhYmxpc2hlZCBCR1Agc2Vzc2lvbnMuIE5v dGUgdGhhdCB3aWRlIEJHUCBjb21tdW5pdHkNCiBwcmVjaXNlbHkgbGlrZSBuZXcgYXR0cmlidXRl IGJlaW5nIHByb3Bvc2VkIGhlcmUgY2FuIGNhcnJ5IG9wYXF1ZSB0byBCR1AgZGF0YS4mbmJzcDs8 L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlh bCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjsgZm9udC1zaXplOnNtYWxsIj4NCjxicj4NCjwvZGl2Pg0K PGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZl dGljYSxzYW5zLXNlcmlmOyBmb250LXNpemU6c21hbGwiPg0KSGkgUGV0ciw8L2Rpdj4NCjxkaXYg Y2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Es c2Fucy1zZXJpZjsgZm9udC1zaXplOnNtYWxsIj4NCjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i Z21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNl cmlmOyBmb250LXNpemU6c21hbGwiPg0KRG8geW91IHNlZSBhbnkgaXNzdWUgd2l0aCB0aGUgYWJv dmUgd2lkZSBjb21tdW5pdHkgYXBwcm9hY2ggdG8gYWRkcmVzcyB5b3UgbmVlZHMgPyBFc3BlY2lh bGx5IGZvciBib290c3RyYXBwaW5nIHRoZSB0cmFuc3BvcnQgaXQgaXMgZXZlbiBlYXNpZXIgYXMg eW91IGRvIG5vdCBuZWVkIHRvIGVuYWJsZSBuZXcgU0FGSS4gQW5kIHRob3NlIGFyZSBhbHJlYWR5 IElEUiBXRyBkb2NzLiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5 bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmOyBmb250LXNpemU6c21h bGwiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iIj48 Zm9udCBmYWNlPSJhcmlhbCwgaGVsdmV0aWNhLCBzYW5zLXNlcmlmIj48YSBocmVmPSJodHRwczov L3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3Rvb2xzLmlldGYu b3JnX2h0bWxfZHJhZnQtMkRpZXRmLTJEaWRyLTJEd2lkZS0yRGJncC0yRGNvbW11bml0aWVzLTJE MDEmYW1wO2Q9Q3dNRmFRJmFtcDtjPTVWRDBSVHRObFRoM3ljZDQxYjNNVXcmYW1wO3I9TFVfdkph TV9FUXUxU3NtMzVqMnhsQSZhbXA7bT1oLTdFSm51ZGJCaFl4dGxrZ04tRHZIM0VRd3haa0JmTjlZ bGtXR3FyZzhnJmFtcDtzPWNHSDNiS3hUQW0xWGl5MXFrd28zZjY5VWpxdndUVGpLcXUyVzRucllo RzgmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWlldGYtaWRyLXdpZGUtYmdwLWNvbW11bml0aWVzLTAxPC9hPjwvZm9udD48YnI+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSIiPjxmb250IGZhY2U9ImFyaWFs LCBoZWx2ZXRpY2EsIHNhbnMtc2VyaWYiPjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9v ZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fdG9vbHMuaWV0Zi5vcmdfaHRtbF9kcmFmdC0y RGlldGYtMkRpZHItMkRyZWdpc3RlcmVkLTJEd2lkZS0yRGJncC0yRGNvbW11bml0aWVzLTJEMDEm YW1wO2Q9Q3dNRmFRJmFtcDtjPTVWRDBSVHRObFRoM3ljZDQxYjNNVXcmYW1wO3I9TFVfdkphTV9F UXUxU3NtMzVqMnhsQSZhbXA7bT1oLTdFSm51ZGJCaFl4dGxrZ04tRHZIM0VRd3haa0JmTjlZbGtX R3FyZzhnJmFtcDtzPWJBcEdBUzBWYzY1SS01SlhQRWJSTXltdmljb3ZIS1pZQXJYVXdiWmNSYVUm YW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWlldGYtaWRyLXJlZ2lzdGVyZWQtd2lkZS1iZ3AtY29tbXVuaXRpZXMtMDE8L2E+PC9mb250Pjwv ZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFs LGhlbHZldGljYSxzYW5zLXNlcmlmOyBmb250LXNpemU6c21hbGwiPg0KPGJyPg0KPC9kaXY+DQo8 ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0 aWNhLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTpzbWFsbCI+DQpBcyBmYXIgYXMgbGltaXQgb2YgNEsg bGV0J3MgYWxsIG5vdGUgdGhhdCB3ZSBhbHJlYWR5IGhhdmUgYSBkcmFmdCBhZGRyZXNzaW5nIHRo aXMgYW5kIG1vdmluZyB0aGUgbGltaXQgdG8gNjVLOiZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdXJs ZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fdG9vbHMuaWV0Zi5vcmdf aHRtbF9kcmFmdC0yRGlldGYtMkRpZHItMkRiZ3AtMkRleHRlbmRlZC0yRG1lc3NhZ2VzLTJEMTEm YW1wO2Q9Q3dNRmFRJmFtcDtjPTVWRDBSVHRObFRoM3ljZDQxYjNNVXcmYW1wO3I9TFVfdkphTV9F UXUxU3NtMzVqMnhsQSZhbXA7bT1oLTdFSm51ZGJCaFl4dGxrZ04tRHZIM0VRd3haa0JmTjlZbGtX R3FyZzhnJmFtcDtzPTQ0c24yRzRzMHlNZnJiTmY3R0d0Y2ZkMUlubXZwUkU2YXh0S2hyTTNiVlUm YW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWlldGYtaWRyLWJncC1leHRlbmRlZC1tZXNzYWdlcy0xMTwvYT48L2Rpdj4NCjxkaXYgY2xhc3M9 ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1z ZXJpZjsgZm9udC1zaXplOnNtYWxsIj4NCjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxf ZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmOyBm b250LXNpemU6c21hbGwiPg0KQ2hlZXJzLDwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVs dCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmOyBmb250LXNp emU6c21hbGwiPg0Kci48L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJm b250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjsgZm9udC1zaXplOnNtYWxsIj4N Cjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFt aWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmOyBmb250LXNpemU6c21hbGwiPg0KPGJyPg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJp YWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTpzbWFsbCI+DQo8YnI+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2 ZXRpY2Esc2Fucy1zZXJpZjsgZm9udC1zaXplOnNtYWxsIj4NCjxicj4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+PGJyPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUi Pk9uIFN1biwgTWFyIDEzLCAyMDE2IGF0IDU6MTEgQU0sIEd1bnRlciBWYW4gRGUgVmVsZGUgPHNw YW4gZGlyPSJsdHIiPg0KJmx0OzxhIGhyZWY9Im1haWx0bzpndW50ZXJ2YW5kZXZlbGRlY2NAaWNs b3VkLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmd1bnRlcnZhbmRldmVsZGVjY0BpY2xvdWQuY29tPC9h PiZndDs8L3NwYW4+IHdyb3RlOjxicj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIg c3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4OyBib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDsgcGFk ZGluZy1sZWZ0OjFleCI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZCI+DQo8ZGl2 PmltbyB0aGUgcHJvbWlzZSBvZiBhIHByb3Bvc2FsIGxpa2UgdGhpcyBvbmUsIGlzIHRoYXQgaXQg YWxsb3dzIEFwcGxpY2F0aW9uIGRldmVsb3BtZW50IGF0IERldk9wcyBzcGVlZCBhbmQgcmVtb3Zl cyBzbG93bmVzcyBvZiBpbmR1c3RyeSBib2RpZXMgZm9yIGlubm92YXRpb24uPC9kaXY+DQo8ZGl2 Pjxicj4NCjwvZGl2Pg0KPGRpdj5JIGJlbGlldmUgaXQgaXMgYSB2YWxpZCBwcm9ibGVtIHNwYWNl IHRoYXQgaXMgYmVpbmcgYWRkcmVzc2VkLiBNYXliZSBzb21lIGZlYXR1cmVzL29wdGltaXNhdGlv bnMgZnJvbSBFVk4gY291bGQgYmUgdHJhbnNwbGFudGVkPyAoaS5lLiBEZXNpZ25hdGVkIHJvdXRl ciBzZWxlY3Rpb24sIGFsaWFzaW5nIGFuZCBtYXNzLXdpdGhkcmF3KTwvZGl2Pg0KPGRpdj48YnI+ DQo8L2Rpdj4NCjxkaXY+Ry88L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8YnI+DQo8ZGl2Pg0K PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8ZGl2Pg0KPGRpdiBjbGFzcz0iaDUiPg0KPGRpdj5P biAxMyBNYXIgMjAxNiwgYXQgMDQ6MjAsIFBldHIgTGFwdWtob3YgJmx0OzxhIGhyZWY9Im1haWx0 bzpwZXRyQGZiLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnBldHJAZmIuY29tPC9hPiZndDsgd3JvdGU6 PC9kaXY+DQo8YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2IGNsYXNzPSJo NSI+DQo8ZGl2IHN0eWxlPSJmb250LXN0eWxlOm5vcm1hbDsgZm9udC12YXJpYW50Om5vcm1hbDsg Zm9udC13ZWlnaHQ6bm9ybWFsOyBsZXR0ZXItc3BhY2luZzpub3JtYWw7IHRleHQtYWxpZ246c3Rh cnQ7IHRleHQtaW5kZW50OjBweDsgdGV4dC10cmFuc2Zvcm06bm9uZTsgd2hpdGUtc3BhY2U6bm9y bWFsOyB3b3JkLXNwYWNpbmc6MHB4OyBkaXJlY3Rpb246bHRyOyBmb250LWZhbWlseTpUYWhvbWE7 IGZvbnQtc2l6ZToxMHB0Ij4NCiZndDsmbmJzcDs8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6YXJp YWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTpzbWFsbCI+SW4gZmFjdCBJIGFtIG5v dCBjb252aW5jZWQgcDJtcCBpcyB0aGUgYmVzdCB3YXkgdG8gZ28gd2l0aCBoZXJlLiZuYnNwOzwv c3Bhbj4NCjxkaXY+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5z LXNlcmlmOyBmb250LXNpemU6c21hbGwiPiZndDsgUHViLXN1YiB3aXRob3V0IFJUQyBoYWNrcyBt YXkgYmUgbXVjaCBiZXR0ZXIgLSBkb24ndCB5b3UgaG9uZXN0bHkgdGhpbmsgPyZuYnNwOzwvc3Bh bj48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iYXJpYWwsIGhlbHZldGljYSwgc2Fucy1zZXJpZiIg c2l6ZT0iMiI+PGJyPg0KPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJhcmlhbCwgaGVs dmV0aWNhLCBzYW5zLXNlcmlmIiBzaXplPSIyIj5Ob3QgZXhhY3RseSwgYnV0IG1heWJlIEkgbWlz dW5kZXJzdG9vZCB3aGF0IHAybXAgbWVhbnMgOikgVGhlIG1haW4gYWR2YW50YWdlIG9mIHVzaW5n IEJHUCAoYXQgbGVhc3QgaW4gb3VyIGVudmlyb25tZW50KSBjb21lcyBmcm9tIHRoZSBmYWN0IHRo YXQgaXQncyBhbHJlYWR5IGJvb3RzdHJhcHBlZCB3aGVuIG9uLXN3aXRjaCAob3Igb24tc2VydmVy KQ0KIGFwcGxpY2F0aW9ucyBzdGFydCBjb21pbmcgdXAuIEFuZCBpdCBzdGF5cyB0aGVyZSBldmVu IHdoZW4gdGhlIHNlcnZlcnMgaG9zdGluZyBleHRlcm5hbCBrZXktdmFsdWUgc3RvcmUgbWF5IGJl IGdvbmUuJm5ic3A7PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJhcmlhbCwgaGVsdmV0 aWNhLCBzYW5zLXNlcmlmIiBzaXplPSIyIj48YnI+DQo8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250 IGZhY2U9ImFyaWFsLCBoZWx2ZXRpY2EsIHNhbnMtc2VyaWYiIHNpemU9IjIiPkFzaWRlIGZyb20g dGhpcywgSSBmdWxseSBhZ3JlZSAtIGl0IGRvZXMgbm90IG9mZmVyIG11Y2ggbW9yZSB0aGFuIGFu eSBrZXktdmFsdWUgc3RvcmUuIEFuZCBpdCBoYXMgaXRzIG93biBjb25zdHJhaW50cywgbGlrZSB+ NEsgdmFsdWUgc2l6ZS4gUGx1cywgaXQncyBub3QgZXZlbiBhIHByb3BlciBwdWItc3ViLCBzaW5j ZSB0aGVyZSBpcyBubyBkaXNjcmVldA0KIG1lc3NhZ2Ugc2VtYW50aWMgLSBvbmx5IHN0YXRlIGRp c3NlbWluYXRpb24gOik8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9ImFyaWFsLCBoZWx2 ZXRpY2EsIHNhbnMtc2VyaWYiIHNpemU9IjIiPjxicj4NCjwvZm9udD4NCjxkaXYgc3R5bGU9ImZv bnQtZmFtaWx5OidUaW1lcyBOZXcgUm9tYW4nOyBmb250LXNpemU6MTZweCI+DQo8aHI+DQo8ZGl2 IHN0eWxlPSJkaXJlY3Rpb246bHRyIj48Zm9udCBmYWNlPSJUYWhvbWEiIHNpemU9IjIiPjxiPkZy b206PC9iPjxzcGFuPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86cnJhc3p1a0BnbWFpbC5j b20iIHRhcmdldD0iX2JsYW5rIj5ycmFzenVrQGdtYWlsLmNvbTwvYT48c3Bhbj4mbmJzcDs8L3Nw YW4+WzxhIGhyZWY9Im1haWx0bzpycmFzenVrQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnJy YXN6dWtAZ21haWwuY29tPC9hPl0gb24gYmVoYWxmIG9mIFJvYmVydA0KIFJhc3p1ayBbPGEgaHJl Zj0ibWFpbHRvOnJvYmVydEByYXN6dWsubmV0IiB0YXJnZXQ9Il9ibGFuayI+cm9iZXJ0QHJhc3p1 ay5uZXQ8L2E+XTxicj4NCjxiPlNlbnQ6PC9iPjxzcGFuPiZuYnNwOzwvc3Bhbj5TYXR1cmRheSwg TWFyY2ggMTIsIDIwMTYgNToyNSBQTTxicj4NCjxiPlRvOjwvYj48c3Bhbj4mbmJzcDs8L3NwYW4+ UGV0ciBMYXB1a2hvdjxicj4NCjxiPkNjOjwvYj48c3Bhbj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0i bWFpbHRvOmV4YUBqdW5pcGVyLm5ldCIgdGFyZ2V0PSJfYmxhbmsiPmV4YUBqdW5pcGVyLm5ldDwv YT47IGlkciB3Zzxicj4NCjxiPlN1YmplY3Q6PC9iPjxzcGFuPiZuYnNwOzwvc3Bhbj5SZTogVXNl IG9mIEJHUCBmb3IgT3BhcXVlIFNpZ25hbGluZzxicj4NCjwvZm9udD48YnI+DQo8L2Rpdj4NCjxk aXY+PC9kaXY+DQo8ZGl2Pg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRy YSI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0 IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7IGZvbnQtc2l6 ZTpzbWFsbCI+DQrigItIZWxsbyBQZXRyLOKAizwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxi bG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowcHggMHB4IDBweCAw LjhleDsgYm9yZGVyLWxlZnQtd2lkdGg6MXB4OyBib3JkZXItbGVmdC1jb2xvcjpyZ2IoMjA0LDIw NCwyMDQpOyBib3JkZXItbGVmdC1zdHlsZTpzb2xpZDsgcGFkZGluZy1sZWZ0OjFleCI+DQo8ZGl2 IHN0eWxlPSJkaXJlY3Rpb246bHRyOyBmb250LWZhbWlseTpUYWhvbWE7IGZvbnQtc2l6ZToxMHB0 Ij4NCjxkaXY+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMHB0Ij5SZTogSW1wYWN0IG9uIHJvdXRp bmcuIEkgc2hvdWxkIGJlIG1vcmUgZXhwbGljaXQgc3RhdGluZyB0aGF0IHRoZSBpZGVhIGlzIGZv ciBCR1AgdG8gbm90IGludGVycHJldCB0aGUga2V5LXZhbHVlIG1hcHBpbmdzIGluIGFueSB3YXku PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlh bCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjsgZm9udC1zaXplOnNtYWxsIj4NCuKAi1RoYXQgd2FzIHZl cnkgY2xlYXIgYWxyZWFkeS4gQnV0IGlmIHlvdSBsb29rIGF0IG51bWJlciBvZiBCR1AgaW1wbGVt ZW50YXRpb25zIHJlY29nbml6aW5nIHRoZSBBRkkvU0FGSSBjb21pbmcgb3ZlciBzaW5nbGUgc2Vz c2lvbiBpcyBub3QgZG9uZSBpbW1lZGlhdGVseSBpbiB0aGUgQkdQIG1lc3NhZ2UgcGFyc2luZy4g VGhhdCBpcyBteSBtYWluIHBvaW50IHN1Z2dlc3RpbmcgdHJhbnNwb3J0IGluc3RhbmNlIHBvcnQu Jm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1p bHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTpzbWFsbCI+DQo8YnI+DQo8 L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlh bCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjsgZm9udC1zaXplOnNtYWxsIj4NCkkgbm8gbG9uZ2VyIGJl bGlldmUgbXVsdGlzZXNzaW9ucyB3aWxsIGRvIGl0IG5laXRoZXIgdGhhdCB3ZSBjb3VsZCBvZmYg bG9hZCBpdCBhcyBpbXBsZW1lbnRhdGlvbiBzcGVjaWZpYyB0aGluZy7igIs8L2Rpdj4NCjxicj4N CjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90 ZSIgc3R5bGU9Im1hcmdpbjowcHggMHB4IDBweCAwLjhleDsgYm9yZGVyLWxlZnQtd2lkdGg6MXB4 OyBib3JkZXItbGVmdC1jb2xvcjpyZ2IoMjA0LDIwNCwyMDQpOyBib3JkZXItbGVmdC1zdHlsZTpz b2xpZDsgcGFkZGluZy1sZWZ0OjFleCI+DQo8ZGl2IHN0eWxlPSJkaXJlY3Rpb246bHRyOyBmb250 LWZhbWlseTpUYWhvbWE7IGZvbnQtc2l6ZToxMHB0Ij4NCjxkaXY+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMHB0Ij5UaGUgY29uc3VtZXIgKHJ1bm5pbmcgb24gc2FtZSBkZXZpY2UsIHBvc3NpYmx5 KSBtYXkgc3RpbGwgaW5mbHVlbmNlIHJvdXRpbmcgYmFzZWQgb24gaXRzIGludGVycHJldGF0aW9u IG9mIGRhdGEsIGVpdGhlciBieSBhY2Nlc3NpbmcgdGhlIHBsYXRmb3JtIFNESyBvciBieSBwZXJm b3JtaW5nIEJHUCByb3V0aW5nIGluamVjdGlvbiBvdmVyIHRoZSBjb3JyZXNwb25kaW5nIEFGSS9T QUZJLjwvc3Bhbj48YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnI+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1m YW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTpzbWFsbCI+DQrigItU aGF0IGlzIGV4YWN0bHkgdGhlIGlzc3VlLiBUaGUgb25seSB3YXkgQkdQLUxTIHdlbnQgYnkgd2Fz IHRoZSBjbGFpbSBhYm91dCB0aGVpciBleHBsaWNpdCBkaXNqb2ludGVkIHRvcG9sb2d5IGZyb20g ZXhpc3RpbmcgQkdQLiBJdCB3YXMgd2VsbCBwb3NpdGlvbmVkIHRoYXQgQkdQLUxTIGNhbiBiZSBj b21wbGV0ZWx5IGluY29uZ3J1ZW50IHdpdGggJnF1b3Q7cm91dGluZyZxdW90OyBCR1AuIOKAizwv ZGl2Pg0KPGJyPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5 bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmOyBmb250LXNpemU6c21h bGwiPg0K4oCLVGhlIHBvc3NpYmxlIGNoYW5uZWxzIHRoZSBJR1AgaW5mb3JtYXRpb24gbWF5IGlt cGFjdCByb3V0aW5nIHdlcmUgY2xhc3NpZmllZCBhcyBvdXQgb2YgdGhlIGJhbmQgbGlrZWx5IGNv bWluZyB2aWEgc29tZSBvdGhlciB3YXlzIGZyb20gY29udHJvbGxlcnMgKEkyUlMsIEFQSXMsIHJv dXRpbmcgQkdQIFNBRkkgZXRjIC4uLikuJm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9k ZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7IGZv bnQtc2l6ZTpzbWFsbCI+DQo8YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4N CjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowcHggMHB4IDBw eCAwLjhleDsgYm9yZGVyLWxlZnQtd2lkdGg6MXB4OyBib3JkZXItbGVmdC1jb2xvcjpyZ2IoMjA0 LDIwNCwyMDQpOyBib3JkZXItbGVmdC1zdHlsZTpzb2xpZDsgcGFkZGluZy1sZWZ0OjFleCI+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0iZGlyZWN0aW9uOmx0cjsgZm9udC1mYW1pbHk6VGFob21hOyBmb250 LXNpemU6MTBwdCI+DQo8ZGl2PjwvZGl2Pg0KPGRpdj5SZTogVHJhbnNwb3J0IGluc3RhbmNlLiBJ IHRoaW5rIGl0J3MgYSBncmVhdCBpZGVhIHRvIHJ1biB0aGlzIG9uIHNlcGFyYXRlIGluc3RhbmNl LCBidXQgcmlnaHQgbm93IHdlIHR5cGljYWxseSBydW4ganVzdCBvbmUgcHJvY2VzcywgYW5kIGl0 IGFkZHMgc29tZSBvcGVyYXRpb25hbCBvdmVyaGVhZCB0byBtYWludGFpbiB0d28gb2YgdGhlbS4g QWxzbywgb2Z0ZW4gdGhpcyBleHRlbnNpb24gY291bGQgYmUgdXNlZCBqdXN0IHdpdGggb3V0LW9m LWJhbmQNCiByZWZsZWN0aW9uLiBUaGlzIGlzIHdoeSBJIGZlZWwgaXQgaXMgcmF0aGVyIGJldHRl ciB0byBrZWVwIHRoaXMgYXBwbGljYWJsZSB0byBhbnkgdHlwZSBvZiBCR1AgaW5zdGFuY2UuPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxk aXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9 ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmOyBmb250LXNpemU6c21hbGwi Pg0K4oCLSW1hZ2luZSB0aGF0IHlvdSB3aWxsIG5vdCBnZXQgZmFyIGluIHRoaXMgQkdQIHByb3Bv c2FsLiBUaGVuIHdoYXQgaXMgbGVmdCBpcyBub3RoaW5nIGVsc2UgbGlrZSBhIG5ldyBwcm9jZXNz IHRhbGtpbmcgb3ZlciBvbmUgb2YgZmV3IG1lc3NhZ2UgYnVzZXMgdG9kYXkgdG8gZGlzdHJpYnV0 ZSB0aGUgc2V0IG9mIGluZm9ybWF0aW9uIHlvdSBuZWVkLiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFz cz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5z LXNlcmlmOyBmb250LXNpemU6c21hbGwiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFp bF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7 IGZvbnQtc2l6ZTpzbWFsbCI+DQpJbiBmYWN0IEkgYW0gbm90IGNvbnZpbmNlZCBwMm1wIGlzIHRo ZSBiZXN0IHdheSB0byBnbyB3aXRoIGhlcmUuIFB1Yi1zdWIgd2l0aG91dCBSVEMgaGFja3MgbWF5 IGJlIG11Y2ggYmV0dGVyIC0gZG9uJ3QgeW91IGhvbmVzdGx5IHRoaW5rID8mbmJzcDs8L2Rpdj4N CjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2 ZXRpY2Esc2Fucy1zZXJpZjsgZm9udC1zaXplOnNtYWxsIj4NCjxicj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxz YW5zLXNlcmlmOyBmb250LXNpemU6c21hbGwiPg0KQmVzdCw8L2Rpdj4NCjxkaXYgY2xhc3M9Imdt YWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJp ZjsgZm9udC1zaXplOnNtYWxsIj4NClIu4oCLPC9kaXY+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9k aXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBz dHlsZT0ibWFyZ2luOjBweCAwcHggMHB4IDAuOGV4OyBib3JkZXItbGVmdC13aWR0aDoxcHg7IGJv cmRlci1sZWZ0LWNvbG9yOnJnYigyMDQsMjA0LDIwNCk7IGJvcmRlci1sZWZ0LXN0eWxlOnNvbGlk OyBwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJkaXJlY3Rpb246bHRyOyBm b250LWZhbWlseTpUYWhvbWE7IGZvbnQtc2l6ZToxMHB0Ij4NCjxkaXY+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMHB0Ij5SZTogU2NvcGUgb2YgYXBwbGljYXRpb24uIFRoZSBtYWluIGdvYWwgd2Fz IHRvIHVzZSB0aGlzIGluIGRhdGEtY2VudGVyLCBidXQgSSBjYW4gdGhlb3JpemUgdGhpcyBjb3Vs ZCBiZSB1c2VkIGFtb25nIGZldyBvcGVyYXRvcnMgdGhhdCBhcmUgd2lsbGluZyB0byBkZXZlbG9w IG9uLWRldmljZSBhcHBsaWNhdGlvbnMgYW5kIGV4Y2hhbmdlIGRhdGEgdXNpbmcgdGhlIHByZS1l c3RhYmxpc2hlZA0KIGNoYW5uZWxzIChlLmcuIHRoZSBXSVNFUiB1c2UgY2FzZSkuIEluIHRoaXMg c2l0dWF0aW9uLCBsaW1pdGluZyBzY29wZSB0byBqdXN0IHByaXZhdGUgQVNOcyBjb3VsZCBiZSB0 cmlja3kuIEZ1cnRoZXJtb3JlLCBub24tcHJpdmF0ZSBBU05zIGNvdWxkIGJlIHVzZWQgaW4gZGF0 YS1jZW50ZXIgYXMgd2VsbCAoanVzdCBub3QgZXhwb3NlZCBvdXRzaWRlLi4uKS48L3NwYW4+PGJy Pg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5SZTogVHJhbnNpdGl2ZSBhdHRyaWJ1 dGUuIElkZWFsbHksIGl0IHdvdWxkIGJlIGdyZWF0IHRvIGNhcnJ5IHRoZSB2YWx1ZSBpbiBuZXh0 LWhvcCBmaWVsZCBvZiBNUF9SRUFDSF9OTFJJLCBidXQgdGhlIGxlbmd0aCBpcyBsaW1pdGVkIHRv IDggYnl0ZXMsIGhlbmNlIHRoZSBuZXcgYXR0cmlidXRlLiBJIGRvIG5vdCBoYXZlIHN0cm9uZyBh cmd1bWVudHMgdG8gbWFraW5nIHRoaXMgdHJhbnNpdGl2ZSwgaXQgc2hvdWxkIGJlIGZpbmUgdG8g Z28NCiB3aXRoIG5vbi10cmFuc2l0aXZlIGFuZCBjb3JyZXNwb25kaW5nIGVycm9yIGhhbmRsaW5n LiZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+UmU6IFNlY3VyaXR5LiBTaW5j ZSB3ZSBkbyBub3QgZGlyZWN0bHkgaW5mbHVlbmNlIHBhdGggc2VsZWN0aW9uIHdpdGggbmV3IGRh dGEsIHRoZSB0aHJlYXRzIGNvdWxkIGJlIGxpbWl0ZWQgdG8gdGhvc2UgdGFyZ2V0aW5nIEJHUGlu ZnJhIGl0c2VsZiBlLmcuIGZsb29kaW5nIHdpdGggaW5mb3JtYXRpb24sIGRpc3J1cHRpbmcgc2Vz c2lvbiBldGMuIFRoZXJlIGNvdWxkIGJlIHF1ZXN0aW9ucyBhYm91dCBpbmZvcm1hdGlvbiBhdXRo ZW50aWNpdHksDQogYnV0IHRoaXMgY291bGQgYmUgbGVmdCB1cCB0byB0aGUgYXBwbGljYXRpb25z IHRvIGRlY2lkZSAoZS5nLiBzaWduaW5nIHRoZSBrZXktdmFsdWUgYmluZGluZ3MpLjwvZGl2Pg0K PGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+UmVnYXJkcyw8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+ DQo8ZGl2PlBldHI8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i Zm9udC1mYW1pbHk6J1RpbWVzIE5ldyBSb21hbic7IGZvbnQtc2l6ZToxNnB4Ij4NCjxocj4NCjxk aXYgc3R5bGU9ImRpcmVjdGlvbjpsdHIiPjxmb250IGZhY2U9IlRhaG9tYSIgc2l6ZT0iMiI+PGI+ RnJvbTo8L2I+PHNwYW4+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpycmFzenVrQGdtYWls LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnJyYXN6dWtAZ21haWwuY29tPC9hPjxzcGFuPiZuYnNwOzwv c3Bhbj5bPGEgaHJlZj0ibWFpbHRvOnJyYXN6dWtAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+ cnJhc3p1a0BnbWFpbC5jb208L2E+XSBvbiBiZWhhbGYgb2YgUm9iZXJ0DQogUmFzenVrIFs8YSBo cmVmPSJtYWlsdG86cm9iZXJ0QHJhc3p1ay5uZXQiIHRhcmdldD0iX2JsYW5rIj5yb2JlcnRAcmFz enVrLm5ldDwvYT5dPGJyPg0KPGI+U2VudDo8L2I+PHNwYW4+Jm5ic3A7PC9zcGFuPlNhdHVyZGF5 LCBNYXJjaCAxMiwgMjAxNiAxOjEwIFBNPGJyPg0KPGI+VG86PC9iPjxzcGFuPiZuYnNwOzwvc3Bh bj5QZXRyIExhcHVraG92OzxzcGFuPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86ZXhhQGp1 bmlwZXIubmV0IiB0YXJnZXQ9Il9ibGFuayI+ZXhhQGp1bmlwZXIubmV0PC9hPjxicj4NCjxiPkNj OjwvYj48c3Bhbj4mbmJzcDs8L3NwYW4+aWRyIHdnPGJyPg0KPGI+U3ViamVjdDo8L2I+PHNwYW4+ Jm5ic3A7PC9zcGFuPlVzZSBvZiBCR1AgZm9yIE9wYXF1ZSBTaWduYWxpbmc8YnI+DQo8L2ZvbnQ+ PGJyPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+PC9kaXY+DQo8ZGl2Pg0KPGRpdiBkaXI9 Imx0ciI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJp ZjsgZm9udC1zaXplOnNtYWxsIj7igItQZXRyLCBFYmVuLDwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9u dC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTpzbWFsbCI+PGJy Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1z ZXJpZjsgZm9udC1zaXplOnNtYWxsIj5JIGhhdmUgZmV3IHF1ZXN0aW9ucyBhbmQgY29tbWVudHMg dG8geW91ciBwcm9wb3NhbC4mbmJzcDs8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OmFy aWFsLGhlbHZldGljYSxzYW5zLXNlcmlmOyBmb250LXNpemU6c21hbGwiPjxicj4NCjwvZGl2Pg0K PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7IGZvbnQt c2l6ZTpzbWFsbCI+LSBUaGUgZHJhZnQg4oCLYXR0ZW1wdHMgdG8gcmV1c2UgQkdQIG1lY2hhbmlz bSBmb3IgcDJtcCBkaXN0cmlidXRpb24gb2Ygb3BhcXVlIGluZm9ybWF0aW9uLiBUaGF0IGFsb25l IGlzIG5vdCBhIGJhZCB0aGluZyA6KSBIb3dldmVyIHdoZW4geW91IG1ha2UgcmVmZXJlbmNlIHRv IEJHUC1MUyBpdCBuZWVkcyB0byBiZSBvYnNlcnZlZA0KIHRoYXQgQkdQLUxTIGlzIG5vdCBwb3Np dGlvbiB0byBkaXJlY3RseSBpbXBhY3Qgcm91dGluZyAoaWUgY29udGVudCBvZiBSSUIgYW5kIEZJ QnMpIHVubGlrZSBvbmUgb2YgdGhlIHVzZSBjYXNlcyBkZXNjcmliZWQgaW4geW91ciBkcmFmdCBJ bnRybyBwYXJhZ3JhcGguIFRoYXQgbWVhbnMgdGhhdCB1bmxpa2UgQkdQLUxTIGl0IG11c3QgY28t ZXhpc3Qgd2l0aCByb3V0aW5nIEJHUCBvbiB0aGUgc2FtZSBCR1Agc3BlYWtlcnMuJm5ic3A7PC9k aXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjsg Zm9udC1zaXplOnNtYWxsIj48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OmFy aWFsLGhlbHZldGljYSxzYW5zLXNlcmlmOyBmb250LXNpemU6c21hbGwiPkhlcmUgSSB3b3VsZCBs aWtlIHRvIGJyaW5nIGJhY2sgbXkgcHJvcG9zYWwgdG8gZGVmaW5lIG5ldyBwb3J0IGZvciBUcmFu c3BvcnQgSW5zdGFuY2UgQkdQJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29m cG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX190b29scy5pZXRmLm9yZ19odG1sX2RyYWZ0LTJE cmFzenVrLTJEdGktMkRiZ3AtMkQwMSZhbXA7ZD1Dd01GYVEmYW1wO2M9NVZEMFJUdE5sVGgzeWNk NDFiM01VdyZhbXA7cj1MVV92SmFNX0VRdTFTc20zNWoyeGxBJmFtcDttPTc1US1udlgyUmhoeFlt LXIyQkl4Rmh0SXBLelQ5cEVnR3g5VVdqcTZmVDQmYW1wO3M9a0s3MWVTcVdCSVRhbEcxWTFpTldh aUhhU0E3dnJNTW5MNGxraWVhcTJ1WSZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcmFzenVrLXRpLWJncC0wMTwvYT48c3Bhbj4mbmJzcDs8 L3NwYW4+d2hpY2gNCiBhdCB0aGUgdGltZSBvZiBkaXNjdXNzaW9uIHdhcyBzdXBwb3NlZCB0byBi ZSBzaG9ydGx5IGFkZHJlc3NlZCBieSBkeW5hbWljIHBvcnQgYWxsb2NhdGlvbnMgb2YgbXVsdGlz ZXNzaW9ucyB3aGljaCB0byB0aGUgYmVzdCBvZiBteSBrbm93bGVkZ2UgbmV2ZXIgaGFwcGVuZWQu Jm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fu cy1zZXJpZjsgZm9udC1zaXplOnNtYWxsIj48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQt ZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmOyBmb250LXNpemU6c21hbGwiPlNvIGZp cnN0IGNvbW1lbnQgaXMgdGhhdCBpZiB3ZSBnbyB3aXRoIHJldXNpbmcgQkdQLTQgZm9yIHRoaXMg dHlwZSBvZiBzaWduYWxsaW5nIGxldCdzIGVuZm9yY2UgaXQncyBlYXJseSBzZXBhcmF0aW9uIGZy b20gJnF1b3Q7Y2xhc3NpYyZxdW90OyBCR1AuJm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250 LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjsgZm9udC1zaXplOnNtYWxsIj48YnI+ DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNl cmlmOyBmb250LXNpemU6c21hbGwiPi0gU2Vjb25kIGNvbW1lbnQgaXMgcmVsYXRlZCB0byB0aGUg c2NvcGUgb2YgdXNlLiBJZiB0aGUgc2NvcGUgaXMgcHJpdmF0ZSAtIGxldCdzIHBlcmhhcHMgZW5m b3JjZSBpdCBtb3JlIGV4cGxpY2l0bHkgc3VjaCB0aGF0IGJ5IHRoZSBzcGVjIGl0IGlzIGlsbGVn YWwgQUZJL1NBRkkgcGFpciBpbiB0aGUgcHVibGljIEludGVybmV0Lg0KIEZvciBleGFtcGxlIGJ5 IHN0YXRpbmcgdGhhdCBpdCBpcyBpbGxlZ2FsIHRvIGhhdmUgbm9uIHByaXZhdGUgQVMgaW4gdGhl IEFTX1BBVEggb2Ygc3VjaCBVUERBVEUgbXNnLiZuYnNwOzwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9u dC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTpzbWFsbCI+PGJy Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1z ZXJpZjsgZm9udC1zaXplOnNtYWxsIj4tIFRoaXJkIHRoZSBkcmFmdCBzdGF0ZXMgdGhhdCB0aGVy ZSBpcyBubyBuZXcgc2VjdXJpdHkgaW1wbGljYXRpb25zIC4uIHdlbGwgaWYgdGhlIHNjb3BlIGlz IG5vbiBwcml2YXRlIEkgYW0gYWZyYWlkIHRoYXQgaXMgbm8gdGhlIGNhc2UuIEFzIHlvdSBoYXZl IHNlZW4gKGFuZCBzdGlsbCBzZWVpbmcpIHNlY3VyaW5nIEJHUCBVUERBVEUNCiBNU0cgaXMgTVBf UkVBQ0ggY29udGVudCBkZXBlbmRlbnQuIElmIGNvbnRlbnQgaXMgZnJlZSBmb3JtIEkgYW0gYWZy YWlkIGl0IHdpbGwgYmUgcmF0aGVyIGhhcmQgdG8gc2VjdXJlIGl0IHdlbGwgOikmbmJzcDs8L2Rp dj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmOyBm b250LXNpemU6c21hbGwiPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6YXJp YWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTpzbWFsbCI+LSBMYXN0IGFzIG9wYXF1 ZSB2YWx1ZSBjb250YWluZXIgeW91IGFyZSBkZWZpbmluZyBhbiB0cmFuc2l0aXZlIGF0dHJpYnV0 ZSA/IElzIHRoZSBpbnRlbnRpb24gdG8gdXNlIHRoaXMgYXR0cmlidXRlIGluIGV4aXN0aW5nIEFG SS9TQUZJcyBhcyB3ZWxsID8gT3RoZXJ3aXNlIGlmIG5vdCB3aHkgZG8geW91IG5lZWQgdGhpcyB0 bw0KIGJlIHRyYW5zaXRpdmUgaWYgY2FwYWJpbGl0eSBuZWdvdGlhdGlvbiBhbHJlYWR5IG1heSBp bXBsaWNpdGx5IGRlZmluZSBpdCdzIHN1cHBvcnQgYnkgbmV3IEFGSS9TQUZJLjwvZGl2Pg0KPGRp diBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7IGZvbnQtc2l6 ZTpzbWFsbCI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2 ZXRpY2Esc2Fucy1zZXJpZjsgZm9udC1zaXplOnNtYWxsIj5DaGVlcnMsPGJyPg0KUi48L2Rpdj4N CjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmOyBmb250 LXNpemU6c21hbGwiPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWws aGVsdmV0aWNhLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTpzbWFsbCI+UFMuJm5ic3A7PC9kaXY+DQo8 ZGl2IHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjsgZm9udC1z aXplOnNtYWxsIj48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhl bHZldGljYSxzYW5zLXNlcmlmOyBmb250LXNpemU6c21hbGwiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTpUYWhvbWE7IGZvbnQtc2l6ZToxMy4zMzMzcHgiPiZndDsgVGhlcmUgaXMgYW4gb25nb2lu ZyBkaXNjdXNzaW9uIGFyb3VuZCBhdm9pZGluZyBOTFJJIChrZXkpIGNvbGxpc2lvbnMuPC9zcGFu Pjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNh bnMtc2VyaWY7IGZvbnQtc2l6ZTpzbWFsbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlRhaG9t YTsgZm9udC1zaXplOjEzLjMzMzNweCI+PGJyPg0KPC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0i Zm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTpzbWFsbCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlRhaG9tYTsgZm9udC1zaXplOjEzLjMzMzNweCI+V2hl cmUgaXMgc3VjaCBkaXNjdXNzaW9uIHRha2luZyBwbGFjZSA/IFNob3VsZG4ndCBJRFIgYmUgcGVy aGFwcyBpbiB0aGUgbG9vcCBhIGJpdCA6KSZuYnNwOzwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9 ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmOyBmb250LXNpemU6c21hbGwi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpUYWhvbWE7IGZvbnQtc2l6ZToxMy4zMzMzcHgiPjxi cj4NCjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGlj YSxzYW5zLXNlcmlmOyBmb250LXNpemU6c21hbGwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpU YWhvbWE7IGZvbnQtc2l6ZToxMy4zMzMzcHgiPjxicj4NCjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5 bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmOyBmb250LXNpemU6c21h bGwiPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNh LHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTpzbWFsbCI+Jm5ic3A7PC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5Okhl bHZldGljYTsgZm9udC1zaXplOjEycHg7IGZvbnQtc3R5bGU6bm9ybWFsOyBmb250LXZhcmlhbnQ6 bm9ybWFsOyBmb250LXdlaWdodDpub3JtYWw7IGxldHRlci1zcGFjaW5nOm5vcm1hbDsgdGV4dC1h bGlnbjpzdGFydDsgdGV4dC1pbmRlbnQ6MHB4OyB0ZXh0LXRyYW5zZm9ybTpub25lOyB3aGl0ZS1z cGFjZTpub3JtYWw7IHdvcmQtc3BhY2luZzowcHg7IGZsb2F0Om5vbmU7IGRpc3BsYXk6aW5saW5l IWltcG9ydGFudCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTpIZWx2ZXRpY2E7IGZvbnQtc2l6ZToxMnB4 OyBmb250LXN0eWxlOm5vcm1hbDsgZm9udC12YXJpYW50Om5vcm1hbDsgZm9udC13ZWlnaHQ6bm9y bWFsOyBsZXR0ZXItc3BhY2luZzpub3JtYWw7IHRleHQtYWxpZ246c3RhcnQ7IHRleHQtaW5kZW50 OjBweDsgdGV4dC10cmFuc2Zvcm06bm9uZTsgd2hpdGUtc3BhY2U6bm9ybWFsOyB3b3JkLXNwYWNp bmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpIZWx2ZXRpY2E7IGZvbnQtc2l6ZTox MnB4OyBmb250LXN0eWxlOm5vcm1hbDsgZm9udC12YXJpYW50Om5vcm1hbDsgZm9udC13ZWlnaHQ6 bm9ybWFsOyBsZXR0ZXItc3BhY2luZzpub3JtYWw7IHRleHQtYWxpZ246c3RhcnQ7IHRleHQtaW5k ZW50OjBweDsgdGV4dC10cmFuc2Zvcm06bm9uZTsgd2hpdGUtc3BhY2U6bm9ybWFsOyB3b3JkLXNw YWNpbmc6MHB4OyBmbG9hdDpub25lOyBkaXNwbGF5OmlubGluZSFpbXBvcnRhbnQiPklkcg0KIG1h aWxpbmcgbGlzdDwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OkhlbHZldGljYTsgZm9udC1z aXplOjEycHg7IGZvbnQtc3R5bGU6bm9ybWFsOyBmb250LXZhcmlhbnQ6bm9ybWFsOyBmb250LXdl aWdodDpub3JtYWw7IGxldHRlci1zcGFjaW5nOm5vcm1hbDsgdGV4dC1hbGlnbjpzdGFydDsgdGV4 dC1pbmRlbnQ6MHB4OyB0ZXh0LXRyYW5zZm9ybTpub25lOyB3aGl0ZS1zcGFjZTpub3JtYWw7IHdv cmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkhlbHZldGljYTsgZm9u dC1zaXplOjEycHg7IGZvbnQtc3R5bGU6bm9ybWFsOyBmb250LXZhcmlhbnQ6bm9ybWFsOyBmb250 LXdlaWdodDpub3JtYWw7IGxldHRlci1zcGFjaW5nOm5vcm1hbDsgdGV4dC1hbGlnbjpzdGFydDsg dGV4dC1pbmRlbnQ6MHB4OyB0ZXh0LXRyYW5zZm9ybTpub25lOyB3aGl0ZS1zcGFjZTpub3JtYWw7 IHdvcmQtc3BhY2luZzowcHg7IGZsb2F0Om5vbmU7IGRpc3BsYXk6aW5saW5lIWltcG9ydGFudCI+ PGEgaHJlZj0ibWFpbHRvOklkckBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPklkckBpZXRmLm9y ZzwvYT48L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTpIZWx2ZXRpY2E7IGZvbnQtc2l6ZTox MnB4OyBmb250LXN0eWxlOm5vcm1hbDsgZm9udC12YXJpYW50Om5vcm1hbDsgZm9udC13ZWlnaHQ6 bm9ybWFsOyBsZXR0ZXItc3BhY2luZzpub3JtYWw7IHRleHQtYWxpZ246c3RhcnQ7IHRleHQtaW5k ZW50OjBweDsgdGV4dC10cmFuc2Zvcm06bm9uZTsgd2hpdGUtc3BhY2U6bm9ybWFsOyB3b3JkLXNw YWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpIZWx2ZXRpY2E7IGZvbnQtc2l6 ZToxMnB4OyBmb250LXN0eWxlOm5vcm1hbDsgZm9udC12YXJpYW50Om5vcm1hbDsgZm9udC13ZWln aHQ6bm9ybWFsOyBsZXR0ZXItc3BhY2luZzpub3JtYWw7IHRleHQtYWxpZ246c3RhcnQ7IHRleHQt aW5kZW50OjBweDsgdGV4dC10cmFuc2Zvcm06bm9uZTsgd2hpdGUtc3BhY2U6bm9ybWFsOyB3b3Jk LXNwYWNpbmc6MHB4OyBmbG9hdDpub25lOyBkaXNwbGF5OmlubGluZSFpbXBvcnRhbnQiPjxhIGhy ZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9f d3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9faWRyJmFtcDtkPUN3TUZhUSZhbXA7Yz01VkQw UlR0TmxUaDN5Y2Q0MWIzTVV3JmFtcDtyPUxVX3ZKYU1fRVF1MVNzbTM1ajJ4bEEmYW1wO209aC03 RUpudWRiQmhZeHRsa2dOLUR2SDNFUXd4WmtCZk45WWxrV0dxcmc4ZyZhbXA7cz1VRWpEdENxNXo0 dU9SSzJCQTlXcWc2SThNbmJ4eHRhalJyMzNEVy1kV1dNJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsi Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWRyPC9hPjwvc3Bhbj48L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_3F437107848A5140A6A19222EFFB3481200E335EPRNMBX012TheFac_-- From nobody Sun Mar 13 09:47:14 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69FFE12D670 for ; Sun, 13 Mar 2016 09:47:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=instituut-net.20150623.gappssmtp.com 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 I7ULg53UexrW for ; Sun, 13 Mar 2016 09:47:10 -0700 (PDT) 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 4B3C012D675 for ; Sun, 13 Mar 2016 09:47:10 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id p65so74401341wmp.0 for ; Sun, 13 Mar 2016 09:47:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=instituut-net.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=d430ZHKX9CaR4VL/4h0RbeXeIxo5V0LyN7FUebBcz6g=; b=mWnHNA2vvf+5JKnTqtNkQU2BFwZ6+mz7ykWMpgCDChIgzZJL4Ps/OiPTIlAj6k+auu BuqgzS6hNYIb302I/qMNDwn/RX4QrKnjC7+BN5//mOaUNgWjoLNsn6OvU6F0uOy3y0bI MgxrsRzjRlcHYKeppoay4wwFM53koMzxAbvnHw76fsWPmy3/rCGEGpLreEdKIO1j/u0z PpYK+I8ZXynVf/vqaCiHTCk1BYsL0QVwaQ50tKlRGj/7RgOFEpBqRrftYAox+kXVPJrZ ig8rsdQsGWXD6Lhj/052v/PbV3s8d5Z11n7p0fht8BSYR+4tyedWVbOdfatU+MbSagZu rquw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=d430ZHKX9CaR4VL/4h0RbeXeIxo5V0LyN7FUebBcz6g=; b=chTC0RkuBJqrjL4QvQGsDVoN//L8F1Z9ZmyvR6EF/y1H/H7rnqNws7UxtSfwDDWz5j XFqlCpBiA4ZYzAkqO/gABHiRRY8BZRpbFGveyOz19MGwBtC+GDAm2OU7Q4mvIWPzqD2K zpu2aw2WgfK5yfcA4+u3NetCN5uKw/0LR6bacWm1rxlmPMvnm0CHqUzVoCRzAJFI3YlZ GFHSbxbQ2xuPxPoNyedbTEh2UMi5nKiKdfA7ADvL+t37o3iViKP3IU3aa2EERZr2Pxk7 bnEXkxxR/0lL9Lg7AG3UTg0nHKyeGSo0wtJfsWCr6EPj8AFJxyVxLuq81yJXEcKTme9l Ngag== X-Gm-Message-State: AD7BkJKZ8/fZdEFCUGROzADiUnsH+42GafBeJkroQtufA2L3juc9gARIysYBLecApjn7CQ== X-Received: by 10.28.232.87 with SMTP id f84mr13913980wmh.56.1457887628621; Sun, 13 Mar 2016 09:47:08 -0700 (PDT) Received: from localhost ([2001:67c:208c:10:7c52:779e:8a0e:2783]) by smtp.gmail.com with ESMTPSA id 198sm12255777wml.22.2016.03.13.09.47.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 13 Mar 2016 09:47:07 -0700 (PDT) Date: Sun, 13 Mar 2016 17:47:06 +0100 From: Job Snijders To: Petr Lapukhov Message-ID: <20160313164706.GG80711@22.rev.meerval.net> References: <3F437107848A5140A6A19222EFFB3481200E2839@PRN-MBX01-2.TheFacebook.com> <3F437107848A5140A6A19222EFFB3481200E2A32@PRN-MBX01-2.TheFacebook.com> <3F437107848A5140A6A19222EFFB3481200E335E@PRN-MBX01-2.TheFacebook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F437107848A5140A6A19222EFFB3481200E335E@PRN-MBX01-2.TheFacebook.com> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Cc: Robert Raszuk , idr wg Subject: Re: [Idr] Use of BGP for Opaque Signaling X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2016 16:47:13 -0000 On Sun, Mar 13, 2016 at 04:37:08PM +0000, Petr Lapukhov wrote: > Most importantly, opaque data is "free" of any structure that could > require further standardization :) This is on purpose - I was hoping > to have this channel defined once, and let it go without any further > need of defining additional sub-structures... Have you considered using a regular messaging bus such as AMQP or Kafka instead of bolting this on BGP? Kind regards, Job From nobody Sun Mar 13 10:17:50 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03DAF12D64E for ; Sun, 13 Mar 2016 10:17:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com 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 U2WuwgQ-UfGQ for ; Sun, 13 Mar 2016 10:17:47 -0700 (PDT) Received: from mx0b-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.30]) (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 6EFF412D5A5 for ; Sun, 13 Mar 2016 10:17:47 -0700 (PDT) Received: from pps.filterd (m0089730.ppops.net [127.0.0.1]) by m0089730.ppops.net (8.16.0.11/8.16.0.11) with SMTP id u2DHFwII007515; Sun, 13 Mar 2016 10:17:41 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=facebook; bh=nM2y16S6IUs7uBO354XGz6Dn0l9HcT95iKb/s4VlQRw=; b=e2+zifQcqGeQATjC8HnN3iMf2JZe1mO9ZuwHDaqK9KIILYpwnAg4uoMbETkg+BY7Ey1u ejxTBS5TxTUzzC1WLU0vuw3tebHGZmMEMA131Is245C3VjiCZ76OAIxwwlOzGMBrWVPo qmsd3wuRYeaXBmQvzu5QmmSBykFNu2r+y9E= Received: from mail.thefacebook.com ([199.201.64.23]) by m0089730.ppops.net with ESMTP id 21mh3wun5d-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Sun, 13 Mar 2016 10:17:41 -0700 Received: from PRN-MBX01-2.TheFacebook.com ([169.254.3.204]) by PRN-CHUB08.TheFacebook.com ([fe80::c9c7:30fd:ad3:b94%12]) with mapi id 14.03.0248.002; Sun, 13 Mar 2016 10:17:39 -0700 From: Petr Lapukhov To: Job Snijders Thread-Topic: [Idr] Use of BGP for Opaque Signaling Thread-Index: AQHRfKONNK1upwIbukaCHqWz2SNu2p9WgK6PgACao4D//5fqt4AA2ZQAgABhOwD//54QBYAAf+sA//+RX+U= Date: Sun, 13 Mar 2016 17:17:39 +0000 Message-ID: <3F437107848A5140A6A19222EFFB3481200E3403@PRN-MBX01-2.TheFacebook.com> References: <3F437107848A5140A6A19222EFFB3481200E2839@PRN-MBX01-2.TheFacebook.com> <3F437107848A5140A6A19222EFFB3481200E2A32@PRN-MBX01-2.TheFacebook.com> <3F437107848A5140A6A19222EFFB3481200E335E@PRN-MBX01-2.TheFacebook.com>, <20160313164706.GG80711@22.rev.meerval.net> In-Reply-To: <20160313164706.GG80711@22.rev.meerval.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.52.123] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-03-13_04:, , signatures=0 Archived-At: Cc: Robert Raszuk , idr wg Subject: Re: [Idr] Use of BGP for Opaque Signaling X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2016 17:17:49 -0000 Surely, those work just fine, though I'm more in ZMQ :) As I mentioned befo= re, the major reason to turn to BGP is the "simple bootstrapping" part - on= ce DC network is built up, BGP is available (at least for those who use BGP= for routing in DC). Same for inter-AS communications: it would be easier t= o use existing pre-established channel, rather than agreeing on configuring= a shared pub-sub system. Also, co-locating message transport with network = allows to be more robust in presence of infra failures - your "messaging" s= ystem is as reliable as your network.=0A= ________________________________________=0A= From: Job Snijders [job@instituut.net]=0A= Sent: Sunday, March 13, 2016 9:47 AM=0A= To: Petr Lapukhov=0A= Cc: Robert Raszuk; Gunter Van De Velde; idr wg=0A= Subject: Re: [Idr] Use of BGP for Opaque Signaling=0A= =0A= On Sun, Mar 13, 2016 at 04:37:08PM +0000, Petr Lapukhov wrote:=0A= > Most importantly, opaque data is "free" of any structure that could=0A= > require further standardization :) This is on purpose - I was hoping=0A= > to have this channel defined once, and let it go without any further=0A= > need of defining additional sub-structures...=0A= =0A= Have you considered using a regular messaging bus such as AMQP or Kafka=0A= instead of bolting this on BGP?=0A= =0A= Kind regards,=0A= =0A= Job=0A= From nobody Sun Mar 13 12:12:46 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D9EB12D784 for ; Sun, 13 Mar 2016 12:12:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.36 X-Spam-Level: X-Spam-Status: No, score=-0.36 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 NlFoiSlx8YLn for ; Sun, 13 Mar 2016 12:12:41 -0700 (PDT) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (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 8892512D778 for ; Sun, 13 Mar 2016 12:12:40 -0700 (PDT) Received: by mail-lb0-x236.google.com with SMTP id x1so213794535lbj.3 for ; Sun, 13 Mar 2016 12:12:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=stTlA6qhNVTa3V1dw7L9dQ0H/sLah9dHOYNHuKcDQbk=; b=wd5PjeU6UqF9my3wtKI5RR9l17C2kVFxANa+k025BIYxDJEIXJie4WMrmcqKsBKY73 ukhUHvZJ1KudA/toJGhy4a11hzv+Pc1YZb2Ddm4apNG2hK272H0U/SWjsH/hCH1aZBtK 6L290SAGxP504+s2JIVPi0+pCP+O7q0Hubf8LqsHSs/Nc94IiD5teFMjLSx6/1jS+RSg EPI+wFilFiDa8VSwHQHN1h+lDpwG7NzPXo+2v8jiUMjOax4tmHw+tmQKZFhOjJQ/qj+Y W9e92/uCO2/1upIX60JmUaAyZzvnv3bBo9GkKiwNQHFpamhMD9XgMNQkIfpzeylUzH4g RRXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=stTlA6qhNVTa3V1dw7L9dQ0H/sLah9dHOYNHuKcDQbk=; b=FQLLEaDJCsqdfoeWPv3/L4Xrz4mYFGO/p4IzO/tN+84QLJEUwBI0E2g/kIWwo9gZ4k b5xZ/q10+X9XG4I+YLBDu1sahqWfTGbkVGMU7cp+BcDUeP6xgfEe6tl83gPluRinwIla TtoakNua6O9oIOHkMIGENWR+9TxWEuVSgCJB6kqX8on4thcKQi5pO7VVtKsgGGyCTW/a Bxl734V/euYLYkTHMcpDtqaLHLwP/EQqyHO7807a9DbsmqdAsGzvCEWBlBeFBX37+0M0 kimSH9HBvHA4brSLKb8qGiKuCpKc8SodoXlspCvCyQZuYJnRZtyN2I5+GWq1smNL0KiW 8NcA== X-Gm-Message-State: AD7BkJLMC/KXGJNI2+Vw21AKZPPyvMICbcJcjFKDeWNyIg+495Z2XnyYuH/+xokS5/tBImuZL9U91ACxVnciFQ== MIME-Version: 1.0 X-Received: by 10.112.150.165 with SMTP id uj5mr6612379lbb.95.1457896358560; Sun, 13 Mar 2016 12:12:38 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.25.136.133 with HTTP; Sun, 13 Mar 2016 12:12:38 -0700 (PDT) In-Reply-To: <3F437107848A5140A6A19222EFFB3481200E335E@PRN-MBX01-2.TheFacebook.com> References: <3F437107848A5140A6A19222EFFB3481200E2839@PRN-MBX01-2.TheFacebook.com> <3F437107848A5140A6A19222EFFB3481200E2A32@PRN-MBX01-2.TheFacebook.com> <3F437107848A5140A6A19222EFFB3481200E335E@PRN-MBX01-2.TheFacebook.com> Date: Sun, 13 Mar 2016 15:12:38 -0400 X-Google-Sender-Auth: 3ZWO6Ex4D29e-KXAU9A2a8zZhRA Message-ID: From: Robert Raszuk To: Petr Lapukhov Content-Type: multipart/alternative; boundary=047d7b3a8396924f91052df2f277 Archived-At: Cc: idr wg Subject: Re: [Idr] Use of BGP for Opaque Signaling X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2016 19:12:45 -0000 --047d7b3a8396924f91052df2f277 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Petr, > E.g., you need an NLRI of some kind to attach the communities, i.e. every originator > needs to inject a prefix - which isn't too bad implementation wise, but ties information > distribution to reachability info True about need for NLRI. Not so true about putting equal sign between NLRI and reachability in existing SAFIs IMHO. Let's consider that we define a special (v6) prefix which will be used as an NLRI prefix for your opaque distribution. Part of such prefix (suffix) can be your key (verbatim) ... values on the other hand can be carried in wide communities or if you insist in your new attribute. We could even have one for v4 too - say 240.*.*.*. It will be much easier to filter or accept such UPDATE messages and policy required will be pretty much the same as filtering to accept or drop some keys from your new SAFI. Besides AFI/SAFI 2/1 is already there both on RRs or ASBRs hence interested parties may not need to upgrade OS running on those routers. Besides we have already seen from the other drafts (for example Stephane's https://tools.ietf.org/html/draft-litkowski-idr-bgp-timestamp-02) the need to define such special NLRIs to carry opaque information in existing SAFIs which do not really need to be processed by BGP implementations. > Furthermore, wide communities could be interpreted by BGP process Only if you configure them to be processed or they are registered as public and their types are maintained by IANA. The default is opaque just as you need it. Thoughts ? Best, Robert. On Sun, Mar 13, 2016 at 12:37 PM, Petr Lapukhov wrote: > Robert, I totally looked at the wide communities before trying the opaque > stuff. However, there was some semantical awkwardness in regard to > transporting opaque data. E.g., you need an NLRI of some kind to attach t= he > communities, i.e. every originator needs to inject a prefix - which isn't > too bad implementation wise, but ties information distribution to > reachability info, requiring a policy to ignore this reachability > information. I really don't like adding more policies :) > > Furthermore, wide communities could be interpreted by BGP process, and > hence their implementation is a bit more involved and requires more inter= op > testing. The opaque AFI simply acts as a pipe to disseminate bits in the > domain (e.g. we use thrift to encode values). Implementing it requires > accepting the new AFI/SAFI and skipping IP-specific policy code (e.g. > filtering only on attributes). > > Most importantly, opaque data is "free" of any structure that could > require further standardization :) This is on purpose - I was hoping to > have this channel defined once, and let it go without any further need of > defining additional sub-structures... > > PS > The 64K messages would be pretty awesome! :) Having the 4K limit in some > cases requires annoying value fragmentation. Ugh. > > ------------------------------ > *From:* rraszuk@gmail.com [rraszuk@gmail.com] on behalf of Robert Raszuk = [ > robert@raszuk.net] > *Sent:* Sunday, March 13, 2016 7:59 AM > *To:* Gunter Van De Velde > *Cc:* Petr Lapukhov; idr wg > *Subject:* Re: [Idr] Use of BGP for Opaque Signaling > > Hi Gunter, > > For dissemination of information produced by network applications we > already have today various tools be it ansible, chef, puppet etc ... > > If there is need to use inter-domain distribution of such applications I > see no reason why not to define registered or private wide bgp community > and use this as transport instead of new SAFI on already established BGP > sessions. Note that wide BGP community precisely like new attribute being > proposed here can carry opaque to BGP data. > > Hi Petr, > > Do you see any issue with the above wide community approach to address yo= u > needs ? Especially for bootstrapping the transport it is even easier as y= ou > do not need to enable new SAFI. And those are already IDR WG docs. > > https://tools.ietf.org/html/draft-ietf-idr-wide-bgp-communities-01 > > > https://tools.ietf.org/html/draft-ietf-idr-registered-wide-bgp-communitie= s-01 > > > As far as limit of 4K let's all note that we already have a draft > addressing this and moving the limit to 65K: > https://tools.ietf.org/html/draft-ietf-idr-bgp-extended-messages-11 > > > Cheers, > r. > > > > > > On Sun, Mar 13, 2016 at 5:11 AM, Gunter Van De Velde < > guntervandeveldecc@icloud.com> wrote: > >> imo the promise of a proposal like this one, is that it allows >> Application development at DevOps speed and removes slowness of industry >> bodies for innovation. >> >> I believe it is a valid problem space that is being addressed. Maybe som= e >> features/optimisations from EVN could be transplanted? (i.e. Designated >> router selection, aliasing and mass-withdraw) >> >> G/ >> >> >> On 13 Mar 2016, at 04:20, Petr Lapukhov wrote: >> >> > In fact I am not convinced p2mp is the best way to go with here. >> > Pub-sub without RTC hacks may be much better - don't you honestly thin= k >> ? >> >> Not exactly, but maybe I misunderstood what p2mp means :) The main >> advantage of using BGP (at least in our environment) comes from the fact >> that it's already bootstrapped when on-switch (or on-server) application= s >> start coming up. And it stays there even when the servers hosting extern= al >> key-value store may be gone. >> >> Aside from this, I fully agree - it does not offer much more than any >> key-value store. And it has its own constraints, like ~4K value size. Pl= us, >> it's not even a proper pub-sub, since there is no discreet message seman= tic >> - only state dissemination :) >> >> ------------------------------ >> *From:* rraszuk@gmail.com [rraszuk@gmail.com] on behalf of Robert Raszuk >> [robert@raszuk.net] >> *Sent:* Saturday, March 12, 2016 5:25 PM >> *To:* Petr Lapukhov >> *Cc:* exa@juniper.net; idr wg >> *Subject:* Re: Use of BGP for Opaque Signaling >> >> =E2=80=8BHello Petr,=E2=80=8B >> >> >>> Re: Impact on routing. I should be more explicit stating that the idea >>> is for BGP to not interpret the key-value mappings in any way. >>> >> >> =E2=80=8BThat was very clear already. But if you look at number of BGP >> implementations recognizing the AFI/SAFI coming over single session is n= ot >> done immediately in the BGP message parsing. That is my main point >> suggesting transport instance port. >> >> I no longer believe multisessions will do it neither that we could off >> load it as implementation specific thing.=E2=80=8B >> >> >> >>> The consumer (running on same device, possibly) may still influence >>> routing based on its interpretation of data, either by accessing the >>> platform SDK or by performing BGP routing injection over the correspond= ing >>> AFI/SAFI. >>> >> >> =E2=80=8BThat is exactly the issue. The only way BGP-LS went by was the = claim >> about their explicit disjointed topology from existing BGP. It was well >> positioned that BGP-LS can be completely incongruent with "routing" BGP.= =E2=80=8B >> >> =E2=80=8BThe possible channels the IGP information may impact routing we= re >> classified as out of the band likely coming via some other ways from >> controllers (I2RS, APIs, routing BGP SAFI etc ...). >> >> >> >>> Re: Transport instance. I think it's a great idea to run this on >>> separate instance, but right now we typically run just one process, and= it >>> adds some operational overhead to maintain two of them. Also, often thi= s >>> extension could be used just with out-of-band reflection. This is why I >>> feel it is rather better to keep this applicable to any type of BGP >>> instance. >>> >> >> >> =E2=80=8BImagine that you will not get far in this BGP proposal. Then wh= at is >> left is nothing else like a new process talking over one of few message >> buses today to distribute the set of information you need. >> >> In fact I am not convinced p2mp is the best way to go with here. Pub-sub >> without RTC hacks may be much better - don't you honestly think ? >> >> Best, >> R.=E2=80=8B >> >> >> >>> Re: Scope of application. The main goal was to use this in data-center, >>> but I can theorize this could be used among few operators that are will= ing >>> to develop on-device applications and exchange data using the >>> pre-established channels (e.g. the WISER use case). In this situation, >>> limiting scope to just private ASNs could be tricky. Furthermore, >>> non-private ASNs could be used in data-center as well (just not exposed >>> outside...). >>> >>> Re: Transitive attribute. Ideally, it would be great to carry the value >>> in next-hop field of MP_REACH_NLRI, but the length is limited to 8 byte= s, >>> hence the new attribute. I do not have strong arguments to making this >>> transitive, it should be fine to go with non-transitive and correspondi= ng >>> error handling. >>> >>> Re: Security. Since we do not directly influence path selection with ne= w >>> data, the threats could be limited to those targeting BGPinfra itself e= .g. >>> flooding with information, disrupting session etc. There could be quest= ions >>> about information authenticity, but this could be left up to the >>> applications to decide (e.g. signing the key-value bindings). >>> >>> Regards, >>> >>> Petr >>> >>> ------------------------------ >>> *From:* rraszuk@gmail.com [rraszuk@gmail.com] on behalf of Robert >>> Raszuk [robert@raszuk.net] >>> *Sent:* Saturday, March 12, 2016 1:10 PM >>> *To:* Petr Lapukhov; exa@juniper.net >>> *Cc:* idr wg >>> *Subject:* Use of BGP for Opaque Signaling >>> >>> =E2=80=8BPetr, Eben, >>> >>> I have few questions and comments to your proposal. >>> >>> - The draft =E2=80=8Battempts to reuse BGP mechanism for p2mp distribut= ion of >>> opaque information. That alone is not a bad thing :) However when you m= ake >>> reference to BGP-LS it needs to be observed that BGP-LS is not position= to >>> directly impact routing (ie content of RIB and FIBs) unlike one of the = use >>> cases described in your draft Intro paragraph. That means that unlike >>> BGP-LS it must co-exist with routing BGP on the same BGP speakers. >>> >>> Here I would like to bring back my proposal to define new port for >>> Transport Instance BGP >>> https://tools.ietf.org/html/draft-raszuk-ti-bgp-01 >>> >>> which at the time of discussion was supposed to be shortly addressed >>> by dynamic port allocations of multisessions which to the best of my >>> knowledge never happened. >>> >>> So first comment is that if we go with reusing BGP-4 for this type of >>> signalling let's enforce it's early separation from "classic" BGP. >>> >>> - Second comment is related to the scope of use. If the scope is privat= e >>> - let's perhaps enforce it more explicitly such that by the spec it is >>> illegal AFI/SAFI pair in the public Internet. For example by stating th= at >>> it is illegal to have non private AS in the AS_PATH of such UPDATE msg. >>> >>> - Third the draft states that there is no new security implications .. >>> well if the scope is non private I am afraid that is no the case. As yo= u >>> have seen (and still seeing) securing BGP UPDATE MSG is MP_REACH conten= t >>> dependent. If content is free form I am afraid it will be rather hard t= o >>> secure it well :) >>> >>> - Last as opaque value container you are defining an transitive >>> attribute ? Is the intention to use this attribute in existing AFI/SAFI= s as >>> well ? Otherwise if not why do you need this to be transitive if capabi= lity >>> negotiation already may implicitly define it's support by new AFI/SAFI. >>> >>> Cheers, >>> R. >>> >>> PS. >>> >>> > There is an ongoing discussion around avoiding NLRI (key) collisions. >>> >>> Where is such discussion taking place ? Shouldn't IDR be perhaps in the >>> loop a bit :) >>> >>> >>> >>> >>> >> >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >> >> >> >> > --047d7b3a8396924f91052df2f277 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Petr,

> E.g., you need an NLRI of some kind to attach the com= munities, i.e. every originator=C2=A0
> need= s to inject a prefix - which isn't too bad implementation wise, but tie= s information=C2=A0
> distribution to reacha= bility info

True about need for NLRI. Not so true about putting equal sign between NLR= I and reachability in existing SAFIs IMHO.=C2=A0
Let's consider that we define a special (v6)= prefix which will be used as an NLRI prefix for your opaque distribution. = Part of such prefix (suffix) can be your key (verbatim) ... values on the o= ther hand can be carried in wide communities or if you insist in your new a= ttribute. We could even have one for v4 too - say 240.*.*.*.=C2=A0

It will be much easier to filt= er or accept such UPDATE messages and policy required will be pretty much t= he same as filtering to accept or drop some keys from your new SAFI. Beside= s AFI/SAFI 2/1 is already there both on RRs or ASBRs hence interested parti= es may not need to upgrade OS running on those routers.=C2=A0

Besides we have already seen from t= he other drafts (for example=C2=A0Stephane's https://to= ols.ietf.org/html/draft-litkowski-idr-bgp-timestamp-02) the need to def= ine such special NLRIs to carry opaque information in existing SAFIs which = do not really need to be processed by BGP implementations.=C2=A0

> Furthermore, wide communities = could be interpreted by BGP process

Only if you configure them to be processed or the= y are registered as public and their types are maintained by IANA. The defa= ult is opaque just as you need it.=C2=A0
Thoughts ?=C2=A0

Best,
Robert.


On Sun, Mar 13, 2016 at 12:37 PM, Petr Lapukhov <petr@fb.com> wr= ote:
Robert, I totally looked at the wide communities before trying the opa= que stuff. However, there was some semantical awkwardness in regard to tran= sporting opaque data. E.g., you need an NLRI of some kind to attach the communities, i.e. every originator= needs to inject a prefix - which isn't too bad implementation wise, bu= t ties information distribution to reachability info, requiring a policy to= ignore this reachability information. I really don't like adding more policies :)=C2=A0

Furthermore, wide communities could be interpreted by BGP process, and= hence their implementation is a bit more involved and requires more intero= p testing. The opaque AFI simply acts as a pipe to disseminate bits in the = domain (e.g. we use thrift to encode values). Implementing it requires accepting the new AFI/SAFI and skipping = IP-specific policy code (e.g. filtering only on attributes).

Most importantly, opaque data is "free" of any structure tha= t could require further standardization :) This is on purpose - I was hopin= g to have this channel defined once, and let it go without any further need= of defining additional sub-structures...

PS
The 64K messages would be pretty awesome! :) Having the 4K limit in so= me cases requires annoying value fragmentation. Ugh.

From: rraszuk@gmail.com [rraszuk@gmail.com] on behalf of Robert Raszuk [robert@raszuk.net]
Sent: Sunday, March 13, 2016 7:59 AM
To: Gunter Van De Velde
Cc: Petr Lapukhov; idr wg
Subject: Re: [Idr] Use of BGP for Opaque Signaling

Hi Gunter,

For dissemination of information produced by network applications we alread= y have today various tools be it ansible, chef, puppet etc ...=C2=A0

If there is need to use inter-domain distribution of such applications I se= e no reason why not to define registered or private wide bgp community and = use this as transport instead of new SAFI on already established BGP sessio= ns. Note that wide BGP community precisely like new attribute being proposed here can carry opaque to BGP d= ata.=C2=A0

Hi Petr,

Do you see any issue with the above wide community approach to address you = needs ? Especially for bootstrapping the transport it is even easier as you= do not need to enable new SAFI. And those are already IDR WG docs.=C2=A0


As far as limit of 4K let's all note that we already have a draft addre= ssing this and moving the limit to 65K:=C2=A0https://tools.ietf.org/html/draft-ietf-idr-bgp-extended-me= ssages-11

Cheers,
r.





On Sun, Mar 13, 2016 at 5:11 AM, Gunter Van De V= elde <gunt= ervandeveldecc@icloud.com> wrote:
imo the promise of a proposal like this one, is that it allows Applica= tion development at DevOps speed and removes slowness of industry bodies fo= r innovation.

I believe it is a valid problem space that is being addressed. Maybe s= ome features/optimisations from EVN could be transplanted? (i.e. Designated= router selection, aliasing and mass-withdraw)

G/


On 13 Mar 2016, at 04:20, Petr Lapukhov <petr@fb.com> wrote:

>=C2=A0In fact I am not convinced p2mp is the best way to go with here.=C2= =A0
> Pub-sub without RTC hacks may be much better - don't you honestly= think ?=C2=A0

Not exactly, bu= t maybe I misunderstood what p2mp means :) The main advantage of using BGP = (at least in our environment) comes from the fact that it's already boo= tstrapped when on-switch (or on-server) applications start coming up. And it stays there even when the servers hos= ting external key-value store may be gone.=C2=A0

Aside from this= , I fully agree - it does not offer much more than any key-value store. And= it has its own constraints, like ~4K value size. Plus, it's not even a= proper pub-sub, since there is no discreet message semantic - only state dissemination :)
From:<= span>=C2=A0rr= aszuk@gmail.com=C2=A0[rraszuk@gmail.com] on behalf of Robert Raszuk [robert@rasz= uk.net]
Sent:=C2=A0Saturday, March 12, 2016 5:25 PM
To:=C2=A0Petr Lapukhov
Cc:=C2=A0exa@juniper.net; idr wg
Subject:=C2=A0Re: Use of BGP for Opaque Signaling

=E2=80=8BHello Petr,=E2=80=8B
=C2=A0
Re: Impact on routing. I should be more= explicit stating that the idea is for BGP to not interpret the key-value m= appings in any way.

=E2=80=8BThat was very clear already. But if you look at number of BGP impl= ementations recognizing the AFI/SAFI coming over single session is not done= immediately in the BGP message parsing. That is my main point suggesting t= ransport instance port.=C2=A0

I no longer believe multisessions will do it neither that we could off load= it as implementation specific thing.=E2=80=8B

=C2=A0
The consumer (running on same device, p= ossibly) may still influence routing based on its interpretation of data, e= ither by accessing the platform SDK or by performing BGP routing injection = over the corresponding AFI/SAFI.

=E2=80=8BThat is exactly the issue. The only way BGP-LS went by was the cla= im about their explicit disjointed topology from existing BGP. It was well = positioned that BGP-LS can be completely incongruent with "routing&quo= t; BGP. =E2=80=8B

=E2=80=8BThe possible channels the IGP information may impact routing were = classified as out of the band likely coming via some other ways from contro= llers (I2RS, APIs, routing BGP SAFI etc ...).=C2=A0

=C2=A0
Re: Transport instance. I think it's a great idea to run this on s= eparate instance, but right now we typically run just one process, and it a= dds some operational overhead to maintain two of them. Also, often this ext= ension could be used just with out-of-band reflection. This is why I feel it is rather better to keep this applicable= to any type of BGP instance.


=E2=80=8BImagine that you will not get far in this BGP proposal. Then what = is left is nothing else like a new process talking over one of few message = buses today to distribute the set of information you need.=C2=A0

In fact I am not convinced p2mp is the best way to go with here. Pub-sub wi= thout RTC hacks may be much better - don't you honestly think ?=C2=A0

Best,
R.=E2=80=8B

=C2=A0
Re: Scope of application. The main goal= was to use this in data-center, but I can theorize this could be used amon= g few operators that are willing to develop on-device applications and exch= ange data using the pre-established channels (e.g. the WISER use case). In this situation, limiting scope to j= ust private ASNs could be tricky. Furthermore, non-private ASNs could be us= ed in data-center as well (just not exposed outside...).

Re: Transitive attribute. Ideally, it would be great to carry the valu= e in next-hop field of MP_REACH_NLRI, but the length is limited to 8 bytes,= hence the new attribute. I do not have strong arguments to making this tra= nsitive, it should be fine to go with non-transitive and corresponding error handling.=C2=A0

Re: Security. Since we do not directly influence path selection with n= ew data, the threats could be limited to those targeting BGPinfra itself e.= g. flooding with information, disrupting session etc. There could be questi= ons about information authenticity, but this could be left up to the applications to decide (e.g. signing the = key-value bindings).

Regards,

Petr

From:<= span>=C2=A0rr= aszuk@gmail.com=C2=A0[rraszuk@gmail.com] on behalf of Robert Raszuk [robert@rasz= uk.net]
Sent:=C2=A0Saturday, March 12, 2016 1:10 PM
To:=C2=A0Petr Lapukhov;=C2=A0exa@juniper.net
Cc:=C2=A0idr wg
Subject:=C2=A0Use of BGP for Opaque Signaling

=E2= =80=8BPetr, Eben,

I hav= e few questions and comments to your proposal.=C2=A0

- The= draft =E2=80=8Battempts to reuse BGP mechanism for p2mp distribution of op= aque information. That alone is not a bad thing :) However when you make re= ference to BGP-LS it needs to be observed that BGP-LS is not position to directly impact routing (ie content of RIB = and FIBs) unlike one of the use cases described in your draft Intro paragra= ph. That means that unlike BGP-LS it must co-exist with routing BGP on the = same BGP speakers.=C2=A0

Here = I would like to bring back my proposal to define new port for Transport Ins= tance BGP=C2=A0https://tools.ietf.org/html/draft-= raszuk-ti-bgp-01=C2=A0which at the time of discussion was supposed to be shortly addressed by dynamic = port allocations of multisessions which to the best of my knowledge never h= appened.=C2=A0

So fi= rst comment is that if we go with reusing BGP-4 for this type of signalling= let's enforce it's early separation from "classic" BGP.= =C2=A0

- Sec= ond comment is related to the scope of use. If the scope is private - let&#= 39;s perhaps enforce it more explicitly such that by the spec it is illegal= AFI/SAFI pair in the public Internet. For example by stating that it is illegal to have non private AS in the AS= _PATH of such UPDATE msg.=C2=A0

- Thi= rd the draft states that there is no new security implications .. well if t= he scope is non private I am afraid that is no the case. As you have seen (= and still seeing) securing BGP UPDATE MSG is MP_REACH content dependent. If content is free form I am afraid it = will be rather hard to secure it well :)=C2=A0

- Las= t as opaque value container you are defining an transitive attribute ? Is t= he intention to use this attribute in existing AFI/SAFIs as well ? Otherwis= e if not why do you need this to be transitive if capability negotiation already may implicitly define it&#= 39;s support by new AFI/SAFI.

Cheer= s,
R.

PS.= =C2=A0

> There is an ongoing = discussion around avoiding NLRI (key) collisions.

Where is such discussion = taking place ? Shouldn't IDR be perhaps in the loop a bit :)=C2=A0



=C2= =A0

___________________________________________= ____
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listi= nfo/idr



--047d7b3a8396924f91052df2f277-- From nobody Sun Mar 13 12:42:19 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA1E912D7B0 for ; Sun, 13 Mar 2016 12:42:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.612 X-Spam-Level: X-Spam-Status: No, score=-0.612 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 pUrwvgavVxai for ; Sun, 13 Mar 2016 12:42:14 -0700 (PDT) Received: from st13p11im-asmtp003.me.com (st13p11im-asmtp003.me.com [17.164.40.218]) (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 8BB0D12D6F9 for ; Sun, 13 Mar 2016 12:42:14 -0700 (PDT) Received: from [10.214.90.112] (242.82-131-109.adsl-dyn.isp.belgacom.be [109.131.82.242]) by st13p11im-asmtp003.me.com (Oracle Communications Messaging Server 7.0.5.36.0 64bit (built Sep 8 2015)) with ESMTPSA id <0O3Z00C2FTE05P00@st13p11im-asmtp003.me.com> for idr@ietf.org; Sun, 13 Mar 2016 19:42:03 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-03-13_04:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1015 suspectscore=10 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1510270003 definitions=main-1603130292 Content-type: multipart/alternative; boundary="Apple-Mail=_820D7F73-C3BC-44C1-B927-C1BB40FD768F" MIME-version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Gunter Van De Velde In-reply-to: Date: Sun, 13 Mar 2016 20:42:00 +0100 Message-id: References: <3F437107848A5140A6A19222EFFB3481200E2839@PRN-MBX01-2.TheFacebook.com> <3F437107848A5140A6A19222EFFB3481200E2A32@PRN-MBX01-2.TheFacebook.com> <3F437107848A5140A6A19222EFFB3481200E335E@PRN-MBX01-2.TheFacebook.com> To: Robert Raszuk , Petr Lapukhov X-Mailer: Apple Mail (2.3112) Archived-At: Cc: idr wg Subject: Re: [Idr] Use of BGP for Opaque Signaling X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2016 19:42:17 -0000 --Apple-Mail=_820D7F73-C3BC-44C1-B927-C1BB40FD768F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 One of the questions in the equation is if signalling of Opaque = information needs potentially modified/different path selection = mechanisms compared to a placeholder IPv6 NLRI + wide community. Ciao, G/ > On 13 Mar 2016, at 20:12, Robert Raszuk wrote: >=20 > Petr, >=20 > > E.g., you need an NLRI of some kind to attach the communities, i.e. = every originator=20 > > needs to inject a prefix - which isn't too bad implementation wise, = but ties information=20 > > distribution to reachability info >=20 > True about need for NLRI. Not so true about putting equal sign between = NLRI and reachability in existing SAFIs IMHO.=20 >=20 > Let's consider that we define a special (v6) prefix which will be used = as an NLRI prefix for your opaque distribution. Part of such prefix = (suffix) can be your key (verbatim) ... values on the other hand can be = carried in wide communities or if you insist in your new attribute. We = could even have one for v4 too - say 240.*.*.*.=20 >=20 > It will be much easier to filter or accept such UPDATE messages and = policy required will be pretty much the same as filtering to accept or = drop some keys from your new SAFI. Besides AFI/SAFI 2/1 is already there = both on RRs or ASBRs hence interested parties may not need to upgrade OS = running on those routers.=20 >=20 > Besides we have already seen from the other drafts (for example = Stephane's = https://tools.ietf.org/html/draft-litkowski-idr-bgp-timestamp-02 = ) the = need to define such special NLRIs to carry opaque information in = existing SAFIs which do not really need to be processed by BGP = implementations.=20 >=20 > > Furthermore, wide communities could be interpreted by BGP process >=20 > Only if you configure them to be processed or they are registered as = public and their types are maintained by IANA. The default is opaque = just as you need it.=20 >=20 > Thoughts ?=20 >=20 > Best, > Robert. >=20 >=20 > On Sun, Mar 13, 2016 at 12:37 PM, Petr Lapukhov > wrote: > Robert, I totally looked at the wide communities before trying the = opaque stuff. However, there was some semantical awkwardness in regard = to transporting opaque data. E.g., you need an NLRI of some kind to = attach the communities, i.e. every originator needs to inject a prefix - = which isn't too bad implementation wise, but ties information = distribution to reachability info, requiring a policy to ignore this = reachability information. I really don't like adding more policies :)=20 >=20 > Furthermore, wide communities could be interpreted by BGP process, and = hence their implementation is a bit more involved and requires more = interop testing. The opaque AFI simply acts as a pipe to disseminate = bits in the domain (e.g. we use thrift to encode values). Implementing = it requires accepting the new AFI/SAFI and skipping IP-specific policy = code (e.g. filtering only on attributes). >=20 > Most importantly, opaque data is "free" of any structure that could = require further standardization :) This is on purpose - I was hoping to = have this channel defined once, and let it go without any further need = of defining additional sub-structures... >=20 > PS > The 64K messages would be pretty awesome! :) Having the 4K limit in = some cases requires annoying value fragmentation. Ugh. >=20 > From: rraszuk@gmail.com [rraszuk@gmail.com = ] on behalf of Robert Raszuk = [robert@raszuk.net ] > Sent: Sunday, March 13, 2016 7:59 AM > To: Gunter Van De Velde > Cc: Petr Lapukhov; idr wg > Subject: Re: [Idr] Use of BGP for Opaque Signaling >=20 > Hi Gunter, >=20 > For dissemination of information produced by network applications we = already have today various tools be it ansible, chef, puppet etc ...=20 >=20 > If there is need to use inter-domain distribution of such applications = I see no reason why not to define registered or private wide bgp = community and use this as transport instead of new SAFI on already = established BGP sessions. Note that wide BGP community precisely like = new attribute being proposed here can carry opaque to BGP data.=20 >=20 > Hi Petr, >=20 > Do you see any issue with the above wide community approach to address = you needs ? Especially for bootstrapping the transport it is even easier = as you do not need to enable new SAFI. And those are already IDR WG = docs.=20 >=20 > https://tools.ietf.org/html/draft-ietf-idr-wide-bgp-communities-01 = > = https://tools.ietf.org/html/draft-ietf-idr-registered-wide-bgp-communities= -01 = >=20 > As far as limit of 4K let's all note that we already have a draft = addressing this and moving the limit to 65K: = https://tools.ietf.org/html/draft-ietf-idr-bgp-extended-messages-11 = >=20 > Cheers, > r. >=20 >=20 >=20 >=20 >=20 > On Sun, Mar 13, 2016 at 5:11 AM, Gunter Van De Velde = > = wrote: > imo the promise of a proposal like this one, is that it allows = Application development at DevOps speed and removes slowness of industry = bodies for innovation. >=20 > I believe it is a valid problem space that is being addressed. Maybe = some features/optimisations from EVN could be transplanted? (i.e. = Designated router selection, aliasing and mass-withdraw) >=20 > G/ >=20 >=20 >> On 13 Mar 2016, at 04:20, Petr Lapukhov > wrote: >>=20 >> > In fact I am not convinced p2mp is the best way to go with here.=20 >> > Pub-sub without RTC hacks may be much better - don't you honestly = think ?=20 >>=20 >> Not exactly, but maybe I misunderstood what p2mp means :) The main = advantage of using BGP (at least in our environment) comes from the fact = that it's already bootstrapped when on-switch (or on-server) = applications start coming up. And it stays there even when the servers = hosting external key-value store may be gone.=20 >>=20 >> Aside from this, I fully agree - it does not offer much more than any = key-value store. And it has its own constraints, like ~4K value size. = Plus, it's not even a proper pub-sub, since there is no discreet message = semantic - only state dissemination :) >>=20 >> From: rraszuk@gmail.com [rraszuk@gmail.com = ] on behalf of Robert Raszuk = [robert@raszuk.net ] >> Sent: Saturday, March 12, 2016 5:25 PM >> To: Petr Lapukhov >> Cc: exa@juniper.net ; idr wg >> Subject: Re: Use of BGP for Opaque Signaling >>=20 >> =E2=80=8BHello Petr,=E2=80=8B >> =20 >> Re: Impact on routing. I should be more explicit stating that the = idea is for BGP to not interpret the key-value mappings in any way. >>=20 >> =E2=80=8BThat was very clear already. But if you look at number of = BGP implementations recognizing the AFI/SAFI coming over single session = is not done immediately in the BGP message parsing. That is my main = point suggesting transport instance port.=20 >>=20 >> I no longer believe multisessions will do it neither that we could = off load it as implementation specific thing.=E2=80=8B >>=20 >> =20 >> The consumer (running on same device, possibly) may still influence = routing based on its interpretation of data, either by accessing the = platform SDK or by performing BGP routing injection over the = corresponding AFI/SAFI. >>=20 >> =E2=80=8BThat is exactly the issue. The only way BGP-LS went by was = the claim about their explicit disjointed topology from existing BGP. It = was well positioned that BGP-LS can be completely incongruent with = "routing" BGP. =E2=80=8B >>=20 >> =E2=80=8BThe possible channels the IGP information may impact routing = were classified as out of the band likely coming via some other ways = from controllers (I2RS, APIs, routing BGP SAFI etc ...).=20 >>=20 >> =20 >> Re: Transport instance. I think it's a great idea to run this on = separate instance, but right now we typically run just one process, and = it adds some operational overhead to maintain two of them. Also, often = this extension could be used just with out-of-band reflection. This is = why I feel it is rather better to keep this applicable to any type of = BGP instance. >>=20 >>=20 >> =E2=80=8BImagine that you will not get far in this BGP proposal. Then = what is left is nothing else like a new process talking over one of few = message buses today to distribute the set of information you need.=20 >>=20 >> In fact I am not convinced p2mp is the best way to go with here. = Pub-sub without RTC hacks may be much better - don't you honestly think = ?=20 >>=20 >> Best, >> R.=E2=80=8B >>=20 >> =20 >> Re: Scope of application. The main goal was to use this in = data-center, but I can theorize this could be used among few operators = that are willing to develop on-device applications and exchange data = using the pre-established channels (e.g. the WISER use case). In this = situation, limiting scope to just private ASNs could be tricky. = Furthermore, non-private ASNs could be used in data-center as well (just = not exposed outside...). >>=20 >> Re: Transitive attribute. Ideally, it would be great to carry the = value in next-hop field of MP_REACH_NLRI, but the length is limited to 8 = bytes, hence the new attribute. I do not have strong arguments to making = this transitive, it should be fine to go with non-transitive and = corresponding error handling.=20 >>=20 >> Re: Security. Since we do not directly influence path selection with = new data, the threats could be limited to those targeting BGPinfra = itself e.g. flooding with information, disrupting session etc. There = could be questions about information authenticity, but this could be = left up to the applications to decide (e.g. signing the key-value = bindings). >>=20 >> Regards, >>=20 >> Petr >>=20 >> From: rraszuk@gmail.com [rraszuk@gmail.com = ] on behalf of Robert Raszuk = [robert@raszuk.net ] >> Sent: Saturday, March 12, 2016 1:10 PM >> To: Petr Lapukhov; exa@juniper.net >> Cc: idr wg >> Subject: Use of BGP for Opaque Signaling >>=20 >> =E2=80=8BPetr, Eben, >>=20 >> I have few questions and comments to your proposal.=20 >>=20 >> - The draft =E2=80=8Battempts to reuse BGP mechanism for p2mp = distribution of opaque information. That alone is not a bad thing :) = However when you make reference to BGP-LS it needs to be observed that = BGP-LS is not position to directly impact routing (ie content of RIB and = FIBs) unlike one of the use cases described in your draft Intro = paragraph. That means that unlike BGP-LS it must co-exist with routing = BGP on the same BGP speakers.=20 >>=20 >> Here I would like to bring back my proposal to define new port for = Transport Instance BGP = https://tools.ietf.org/html/draft-raszuk-ti-bgp-01 = which at the time of = discussion was supposed to be shortly addressed by dynamic port = allocations of multisessions which to the best of my knowledge never = happened.=20 >>=20 >> So first comment is that if we go with reusing BGP-4 for this type of = signalling let's enforce it's early separation from "classic" BGP.=20 >>=20 >> - Second comment is related to the scope of use. If the scope is = private - let's perhaps enforce it more explicitly such that by the spec = it is illegal AFI/SAFI pair in the public Internet. For example by = stating that it is illegal to have non private AS in the AS_PATH of such = UPDATE msg.=20 >>=20 >> - Third the draft states that there is no new security implications = .. well if the scope is non private I am afraid that is no the case. As = you have seen (and still seeing) securing BGP UPDATE MSG is MP_REACH = content dependent. If content is free form I am afraid it will be rather = hard to secure it well :)=20 >>=20 >> - Last as opaque value container you are defining an transitive = attribute ? Is the intention to use this attribute in existing AFI/SAFIs = as well ? Otherwise if not why do you need this to be transitive if = capability negotiation already may implicitly define it's support by new = AFI/SAFI. >>=20 >> Cheers, >> R. >>=20 >> PS.=20 >>=20 >> > There is an ongoing discussion around avoiding NLRI (key) = collisions. >>=20 >> Where is such discussion taking place ? Shouldn't IDR be perhaps in = the loop a bit :)=20 >>=20 >>=20 >>=20 >> =20 >>=20 >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr = >=20 >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr --Apple-Mail=_820D7F73-C3BC-44C1-B927-C1BB40FD768F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 One of the questions in the equation is if signalling of = Opaque information needs potentially modified/different path selection = mechanisms compared to a placeholder IPv6 NLRI + wide community.

Ciao,
G/



On = 13 Mar 2016, at 20:12, Robert Raszuk <robert@raszuk.net> = wrote:

Petr,

> = E.g., you need an NLRI of some kind to attach the communities, i.e. = every originator 
> = needs to inject a prefix - which isn't too bad implementation wise, but = ties information 
> = distribution to reachability info

True = about need for NLRI. Not so true about putting equal sign between NLRI = and reachability in existing SAFIs IMHO. 

Let's = consider that we define a special (v6) prefix which will be used as an = NLRI prefix for your opaque distribution. Part of such prefix (suffix) = can be your key (verbatim) ... values on the other hand can be carried = in wide communities or if you insist in your new attribute. We could = even have one for v4 too - say 240.*.*.*. 

It will = be much easier to filter or accept such UPDATE messages and policy = required will be pretty much the same as filtering to accept or drop = some keys from your new SAFI. Besides AFI/SAFI 2/1 is already there both = on RRs or ASBRs hence interested parties may not need to upgrade OS = running on those routers. 

Besides = we have already seen from the other drafts (for example Stephane's https://tools.ietf.org/html/draft-litkowski-idr-bgp-timestamp-0= 2) the need to define such special NLRIs to carry opaque information = in existing SAFIs which do not really need to be processed by BGP = implementations. 

> = Furthermore, wide communities could be interpreted by BGP = process

Only if = you configure them to be processed or they are registered as public and = their types are maintained by IANA. The default is opaque just as you = need it. 

Thoughts = ? 

Best,
Robert.


On Sun, Mar 13, 2016 at 12:37 PM, Petr Lapukhov = <petr@fb.com> wrote:
Robert, I totally looked at the wide communities before = trying the opaque stuff. However, there was some semantical awkwardness = in regard to transporting opaque data. E.g., you need an NLRI of some kind to attach the communities, i.e. every = originator needs to inject a prefix - which isn't too bad implementation = wise, but ties information distribution to reachability info, requiring = a policy to ignore this reachability information. I really don't like adding more policies :) 

Furthermore, wide communities could be interpreted by = BGP process, and hence their implementation is a bit more involved and = requires more interop testing. The opaque AFI simply acts as a pipe to = disseminate bits in the domain (e.g. we use thrift to encode values). Implementing it requires accepting the new AFI/SAFI and = skipping IP-specific policy code (e.g. filtering only on = attributes).

Most importantly, opaque data is "free" of any structure = that could require further standardization :) This is on purpose - I was = hoping to have this channel defined once, and let it go without any = further need of defining additional sub-structures...

PS
The 64K messages would be pretty awesome! :) Having the = 4K limit in some cases requires annoying value fragmentation. Ugh.

From: rraszuk@gmail.com [rraszuk@gmail.com] on behalf of Robert = Raszuk [robert@raszuk.net]
Sent: Sunday, March 13, 2016 7:59 AM
To: Gunter Van De Velde
Cc: Petr Lapukhov; idr wg
Subject: Re: [Idr] Use of BGP for Opaque Signaling

Hi Gunter,

For dissemination of information produced by network applications we = already have today various tools be it ansible, chef, puppet etc = ... 

If there is need to use inter-domain distribution of such applications I = see no reason why not to define registered or private wide bgp community = and use this as transport instead of new SAFI on already established BGP = sessions. Note that wide BGP community precisely like new attribute being proposed here can carry opaque to = BGP data. 

Hi Petr,

Do you see any issue with the above wide community approach to address = you needs ? Especially for bootstrapping the transport it is even easier = as you do not need to enable new SAFI. And those are already IDR WG = docs. 

https://tools.ietf.org/html/draft-ietf-idr-wide-bgp-communities= -01
https://tools.ietf.org/html/draft-ietf-idr-registered-wide-bgp-= communities-01

As far as limit of 4K let's all note that we already have a draft = addressing this and moving the limit to 65K: https://tools.ietf.org/html/draft-ietf-idr-bgp-extended-message= s-11

Cheers,
r.





On Sun, Mar 13, 2016 at 5:11 AM, Gunter Van = De Velde <guntervandeveldecc@icloud.com> wrote:
imo the promise of a proposal like this one, is that it = allows Application development at DevOps speed and removes slowness of = industry bodies for innovation.

I believe it is a valid problem space that is being = addressed. Maybe some features/optimisations from EVN could be = transplanted? (i.e. Designated router selection, aliasing and = mass-withdraw)

G/


On 13 Mar 2016, at 04:20, Petr Lapukhov <petr@fb.com> wrote:

> In fact I am not convinced p2mp is the best way to go with = here. 
> Pub-sub without RTC hacks may be much better - don't you = honestly think ? 

Not exactly, but maybe I misunderstood what p2mp means :) The = main advantage of using BGP (at least in our environment) comes from the = fact that it's already bootstrapped when on-switch (or on-server) applications start coming up. And it stays there even when the servers = hosting external key-value store may be gone. 

Aside from this, I fully agree - it does not offer much more = than any key-value store. And it has its own constraints, like ~4K value = size. Plus, it's not even a proper pub-sub, since there is no discreet message semantic - only state dissemination :)
From: rraszuk@gmail.com [rraszuk@gmail.com] on behalf of Robert Raszuk [robert@raszuk.net]
Sent: Saturday, March 12, = 2016 5:25 PM
To: Petr Lapukhov
Cc: exa@juniper.net; idr wg
Subject: Re: Use of BGP = for Opaque Signaling

=E2=80=8BHello Petr,=E2=80=8B
 
=
Re: Impact on = routing. I should be more explicit stating that the idea is for BGP to = not interpret the key-value mappings in any way.

=E2=80=8BThat was very clear already. But if you look at number of BGP = implementations recognizing the AFI/SAFI coming over single session is = not done immediately in the BGP message parsing. That is my main point = suggesting transport instance port. 

I no longer believe multisessions will do it neither that we could off = load it as implementation specific thing.=E2=80=8B

 
=
The consumer = (running on same device, possibly) may still influence routing based on = its interpretation of data, either by accessing the platform SDK or by = performing BGP routing injection over the corresponding = AFI/SAFI.

=E2=80=8BThat is exactly the issue. The only way BGP-LS went by was the = claim about their explicit disjointed topology from existing BGP. It was = well positioned that BGP-LS can be completely incongruent with "routing" = BGP. =E2=80=8B

=E2=80=8BThe possible channels the IGP information may impact routing = were classified as out of the band likely coming via some other ways = from controllers (I2RS, APIs, routing BGP SAFI etc ...). 

 
=
Re: Transport instance. I think it's a great idea to run = this on separate instance, but right now we typically run just one = process, and it adds some operational overhead to maintain two of them. = Also, often this extension could be used just with out-of-band reflection. This is why I feel it is rather better to keep this = applicable to any type of BGP instance.


=E2=80=8BImagine that you will not get far in this BGP proposal. Then = what is left is nothing else like a new process talking over one of few = message buses today to distribute the set of information you = need. 

In fact I am not convinced p2mp is the best way to go with here. Pub-sub = without RTC hacks may be much better - don't you honestly think = ? 

Best,
R.=E2=80=8B

 
=
Re: Scope of = application. The main goal was to use this in data-center, but I can = theorize this could be used among few operators that are willing to = develop on-device applications and exchange data using the = pre-established channels (e.g. the WISER use case). In this situation, limiting scope = to just private ASNs could be tricky. Furthermore, non-private ASNs = could be used in data-center as well (just not exposed = outside...).

Re: Transitive attribute. Ideally, it would be great to = carry the value in next-hop field of MP_REACH_NLRI, but the length is = limited to 8 bytes, hence the new attribute. I do not have strong = arguments to making this transitive, it should be fine to go with non-transitive and corresponding error handling. 

Re: Security. Since we do not directly influence path = selection with new data, the threats could be limited to those targeting = BGPinfra itself e.g. flooding with information, disrupting session etc. = There could be questions about information authenticity, but this could be left up to the applications to decide (e.g. signing = the key-value bindings).

Regards,

Petr

From: rraszuk@gmail.com [rraszuk@gmail.com] on behalf of Robert Raszuk [robert@raszuk.net]
Sent: Saturday, March 12, = 2016 1:10 PM
To: Petr Lapukhov; exa@juniper.net
Cc: idr wg
Subject: Use of BGP for = Opaque Signaling

=E2=80=8BPetr, Eben,

I have few questions and comments to your = proposal. 

- The draft =E2=80=8Battempts to reuse BGP mechanism for p2mp = distribution of opaque information. That alone is not a bad thing :) = However when you make reference to BGP-LS it needs to be observed that BGP-LS is not position to directly impact routing (ie content of = RIB and FIBs) unlike one of the use cases described in your draft Intro = paragraph. That means that unlike BGP-LS it must co-exist with routing = BGP on the same BGP speakers. 

Here I would like to bring back my proposal to define new = port for Transport Instance BGP https://tools.ietf.org/html/draft-raszuk-ti-bgp-01 which at the time of discussion was supposed to be shortly addressed by = dynamic port allocations of multisessions which to the best of my = knowledge never happened. 

So first comment is that if we go with reusing BGP-4 for this = type of signalling let's enforce it's early separation from "classic" = BGP. 

- Second comment is related to the scope of use. If the scope = is private - let's perhaps enforce it more explicitly such that by the = spec it is illegal AFI/SAFI pair in the public Internet. For example by stating that it is illegal to have non private AS in the = AS_PATH of such UPDATE msg. 

- Third the draft states that there is no new security = implications .. well if the scope is non private I am afraid that is no = the case. As you have seen (and still seeing) securing BGP UPDATE MSG is MP_REACH content dependent. If content is free form I am afraid = it will be rather hard to secure it well :) 

- Last as opaque value container you are defining an = transitive attribute ? Is the intention to use this attribute in = existing AFI/SAFIs as well ? Otherwise if not why do you need this to be transitive if capability negotiation already may implicitly define = it's support by new AFI/SAFI.

Cheers,
R.

PS. 

> There is an ongoing discussion around avoiding NLRI = (key) collisions.

Where is such discussion taking place ? Shouldn't IDR be = perhaps in the loop a bit :) 



 

_______________________________________________
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

= --Apple-Mail=_820D7F73-C3BC-44C1-B927-C1BB40FD768F-- From nobody Sun Mar 13 12:54:01 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1ECD12D7DF for ; Sun, 13 Mar 2016 12:53:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.36 X-Spam-Level: X-Spam-Status: No, score=-0.36 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 E6M11argfup0 for ; Sun, 13 Mar 2016 12:53:55 -0700 (PDT) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::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 E468312D6A2 for ; Sun, 13 Mar 2016 12:53:54 -0700 (PDT) Received: by mail-lb0-x230.google.com with SMTP id x1so214471063lbj.3 for ; Sun, 13 Mar 2016 12:53:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=rmcKVrGlU1kUwfM4wlcWZ7RYElqGAD7AAG82vbpxIw0=; b=FNHc9Pv3G0e93xyA+3/pC7DGdc+balMDoHBZcGukoEPxe1KClqhtiDR51q7UQiksoL 2uu6X00jhRvMyWrhSetyq9P4oO4J6dBhciymiG9OGVH01dcntuKvmmGbeCmmVEuq9BJi hc+4kwUyU5x/m1Owk762S2mB5tveFJ37Q32eocBTJxt+muyI7VeVX4qf87z8tYjomrKn noWekx60zu27/atNhwJRrZCIhHaV8zWv6dejhNeTZ0H67sTCyIKcdlIGglHbt2w/CIuY AqKTK2WM9DUQkVWN9eEW+vPVLpIRB2wtDSL4COZ3bPw4RRl7pCNi5w4Bx2zfP6afUijv 8LaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=rmcKVrGlU1kUwfM4wlcWZ7RYElqGAD7AAG82vbpxIw0=; b=jVbh1pomks/EyTVlTP+Ze3kCeEdyRddTLiK+xk3074ADq+eLUsP0adkPvG/upBb8uY Ij1ypMAgaWZVFKJYBvq6MI2IUkcF13O49hXXRqva3+Cw/IIl0ODIzGiEz6G6l/IOtVPl 7LOMPElVeOjUEqJyB/jdEW0Q+XOxtC4kLDAz9f0e1Zpi/2MQPsOhNCdNWXh+DliRkB2K RItmXYgoukItDbP0XKNHwnsU4dThKLIjsKwjBbbwEkADc+URLi1f5VjLZdS23fJLlC+F MwIq/Trm/RzdsJbT6mIX/uRhAqQyfC+xB1LYmEMVNYBBmYIIaNLq7rU4evpPjbicenwX lbYA== X-Gm-Message-State: AD7BkJIhnjJuzNxUeiA0UiVIrfYoq+Cq3LzdM5l551h0/GybG3itIUgUwl3FO5hsZDGRnZs3KBPsc8R3gBEEDg== MIME-Version: 1.0 X-Received: by 10.112.147.101 with SMTP id tj5mr5047604lbb.119.1457898818039; Sun, 13 Mar 2016 12:53:38 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.25.136.133 with HTTP; Sun, 13 Mar 2016 12:53:37 -0700 (PDT) In-Reply-To: References: <3F437107848A5140A6A19222EFFB3481200E2839@PRN-MBX01-2.TheFacebook.com> <3F437107848A5140A6A19222EFFB3481200E2A32@PRN-MBX01-2.TheFacebook.com> <3F437107848A5140A6A19222EFFB3481200E335E@PRN-MBX01-2.TheFacebook.com> Date: Sun, 13 Mar 2016 15:53:37 -0400 X-Google-Sender-Auth: TmQ4ezAQAxUV1bs0rASmFhDnVEU Message-ID: From: Robert Raszuk To: Gunter Van De Velde Content-Type: multipart/alternative; boundary=047d7b3a8bd22af717052df385c9 Archived-At: Cc: idr wg Subject: Re: [Idr] Use of BGP for Opaque Signaling X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2016 19:53:58 -0000 --047d7b3a8bd22af717052df385c9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Gunter, In BGP path selection happens per prefix. Here prefix is either key alone (new SAFI) or v4/6+key (existing SAFIs). So there is rather no difference if you add different set of attributes to enforce path selection to one or other UPDATE Msgs unless you are talking about completely new rules for selecting best path in the new SAFI (which may be rather contr-argument :) Moreover draft already says that use of add-paths may be useful and that alone would rather be much simpler to have it enabled for existing SAFIs (where it is already working) vs in the new ones of quite loosely defined NLRI semantics. Cheers, R. On Sun, Mar 13, 2016 at 3:42 PM, Gunter Van De Velde < guntervandeveldecc@icloud.com> wrote: > One of the questions in the equation is if signalling of Opaque > information needs potentially modified/different path selection mechanism= s > compared to a placeholder IPv6 NLRI + wide community. > > Ciao, > G/ > > > > On 13 Mar 2016, at 20:12, Robert Raszuk wrote: > > Petr, > > > E.g., you need an NLRI of some kind to attach the communities, i.e. > every originator > > needs to inject a prefix - which isn't too bad implementation wise, but > ties information > > distribution to reachability info > > True about need for NLRI. Not so true about putting equal sign between > NLRI and reachability in existing SAFIs IMHO. > > Let's consider that we define a special (v6) prefix which will be used as > an NLRI prefix for your opaque distribution. Part of such prefix (suffix) > can be your key (verbatim) ... values on the other hand can be carried in > wide communities or if you insist in your new attribute. We could even ha= ve > one for v4 too - say 240.*.*.*. > > It will be much easier to filter or accept such UPDATE messages and polic= y > required will be pretty much the same as filtering to accept or drop some > keys from your new SAFI. Besides AFI/SAFI 2/1 is already there both on RR= s > or ASBRs hence interested parties may not need to upgrade OS running on > those routers. > > Besides we have already seen from the other drafts (for example Stephane'= s > https://tools.ietf.org/html/draft-litkowski-idr-bgp-timestamp-02) the > need to define such special NLRIs to carry opaque information in existing > SAFIs which do not really need to be processed by BGP implementations. > > > Furthermore, wide communities could be interpreted by BGP process > > Only if you configure them to be processed or they are registered as > public and their types are maintained by IANA. The default is opaque just > as you need it. > > Thoughts ? > > Best, > Robert. > > > On Sun, Mar 13, 2016 at 12:37 PM, Petr Lapukhov wrote: > >> Robert, I totally looked at the wide communities before trying the opaqu= e >> stuff. However, there was some semantical awkwardness in regard to >> transporting opaque data. E.g., you need an NLRI of some kind to attach = the >> communities, i.e. every originator needs to inject a prefix - which isn'= t >> too bad implementation wise, but ties information distribution to >> reachability info, requiring a policy to ignore this reachability >> information. I really don't like adding more policies :) >> >> Furthermore, wide communities could be interpreted by BGP process, and >> hence their implementation is a bit more involved and requires more inte= rop >> testing. The opaque AFI simply acts as a pipe to disseminate bits in the >> domain (e.g. we use thrift to encode values). Implementing it requires >> accepting the new AFI/SAFI and skipping IP-specific policy code (e.g. >> filtering only on attributes). >> >> Most importantly, opaque data is "free" of any structure that could >> require further standardization :) This is on purpose - I was hoping to >> have this channel defined once, and let it go without any further need o= f >> defining additional sub-structures... >> >> PS >> The 64K messages would be pretty awesome! :) Having the 4K limit in some >> cases requires annoying value fragmentation. Ugh. >> >> ------------------------------ >> *From:* rraszuk@gmail.com [rraszuk@gmail.com] on behalf of Robert Raszuk >> [robert@raszuk.net] >> *Sent:* Sunday, March 13, 2016 7:59 AM >> *To:* Gunter Van De Velde >> *Cc:* Petr Lapukhov; idr wg >> *Subject:* Re: [Idr] Use of BGP for Opaque Signaling >> >> Hi Gunter, >> >> For dissemination of information produced by network applications we >> already have today various tools be it ansible, chef, puppet etc ... >> >> If there is need to use inter-domain distribution of such applications I >> see no reason why not to define registered or private wide bgp community >> and use this as transport instead of new SAFI on already established BGP >> sessions. Note that wide BGP community precisely like new attribute bein= g >> proposed here can carry opaque to BGP data. >> >> Hi Petr, >> >> Do you see any issue with the above wide community approach to address >> you needs ? Especially for bootstrapping the transport it is even easier= as >> you do not need to enable new SAFI. And those are already IDR WG docs. >> >> https://tools.ietf.org/html/draft-ietf-idr-wide-bgp-communities-01 >> >> >> https://tools.ietf.org/html/draft-ietf-idr-registered-wide-bgp-communiti= es-01 >> >> >> As far as limit of 4K let's all note that we already have a draft >> addressing this and moving the limit to 65K: >> https://tools.ietf.org/html/draft-ietf-idr-bgp-extended-messages-11 >> >> >> Cheers, >> r. >> >> >> >> >> >> On Sun, Mar 13, 2016 at 5:11 AM, Gunter Van De Velde < >> guntervandeveldecc@icloud.com> wrote: >> >>> imo the promise of a proposal like this one, is that it allows >>> Application development at DevOps speed and removes slowness of industr= y >>> bodies for innovation. >>> >>> I believe it is a valid problem space that is being addressed. Maybe >>> some features/optimisations from EVN could be transplanted? (i.e. >>> Designated router selection, aliasing and mass-withdraw) >>> >>> G/ >>> >>> >>> On 13 Mar 2016, at 04:20, Petr Lapukhov wrote: >>> >>> > In fact I am not convinced p2mp is the best way to go with here. >>> > Pub-sub without RTC hacks may be much better - don't you honestly >>> think ? >>> >>> Not exactly, but maybe I misunderstood what p2mp means :) The main >>> advantage of using BGP (at least in our environment) comes from the fac= t >>> that it's already bootstrapped when on-switch (or on-server) applicatio= ns >>> start coming up. And it stays there even when the servers hosting exter= nal >>> key-value store may be gone. >>> >>> Aside from this, I fully agree - it does not offer much more than any >>> key-value store. And it has its own constraints, like ~4K value size. P= lus, >>> it's not even a proper pub-sub, since there is no discreet message sema= ntic >>> - only state dissemination :) >>> >>> ------------------------------ >>> *From:* rraszuk@gmail.com [rraszuk@gmail.com] on behalf of Robert >>> Raszuk [robert@raszuk.net] >>> *Sent:* Saturday, March 12, 2016 5:25 PM >>> *To:* Petr Lapukhov >>> *Cc:* exa@juniper.net; idr wg >>> *Subject:* Re: Use of BGP for Opaque Signaling >>> >>> =E2=80=8BHello Petr,=E2=80=8B >>> >>> >>>> Re: Impact on routing. I should be more explicit stating that the idea >>>> is for BGP to not interpret the key-value mappings in any way. >>>> >>> >>> =E2=80=8BThat was very clear already. But if you look at number of BGP >>> implementations recognizing the AFI/SAFI coming over single session is = not >>> done immediately in the BGP message parsing. That is my main point >>> suggesting transport instance port. >>> >>> I no longer believe multisessions will do it neither that we could off >>> load it as implementation specific thing.=E2=80=8B >>> >>> >>> >>>> The consumer (running on same device, possibly) may still influence >>>> routing based on its interpretation of data, either by accessing the >>>> platform SDK or by performing BGP routing injection over the correspon= ding >>>> AFI/SAFI. >>>> >>> >>> =E2=80=8BThat is exactly the issue. The only way BGP-LS went by was the= claim >>> about their explicit disjointed topology from existing BGP. It was well >>> positioned that BGP-LS can be completely incongruent with "routing" BGP= . =E2=80=8B >>> >>> =E2=80=8BThe possible channels the IGP information may impact routing w= ere >>> classified as out of the band likely coming via some other ways from >>> controllers (I2RS, APIs, routing BGP SAFI etc ...). >>> >>> >>> >>>> Re: Transport instance. I think it's a great idea to run this on >>>> separate instance, but right now we typically run just one process, an= d it >>>> adds some operational overhead to maintain two of them. Also, often th= is >>>> extension could be used just with out-of-band reflection. This is why = I >>>> feel it is rather better to keep this applicable to any type of BGP >>>> instance. >>>> >>> >>> >>> =E2=80=8BImagine that you will not get far in this BGP proposal. Then w= hat is >>> left is nothing else like a new process talking over one of few message >>> buses today to distribute the set of information you need. >>> >>> In fact I am not convinced p2mp is the best way to go with here. Pub-su= b >>> without RTC hacks may be much better - don't you honestly think ? >>> >>> Best, >>> R.=E2=80=8B >>> >>> >>> >>>> Re: Scope of application. The main goal was to use this in data-center= , >>>> but I can theorize this could be used among few operators that are wil= ling >>>> to develop on-device applications and exchange data using the >>>> pre-established channels (e.g. the WISER use case). In this situation, >>>> limiting scope to just private ASNs could be tricky. Furthermore, >>>> non-private ASNs could be used in data-center as well (just not expose= d >>>> outside...). >>>> >>>> Re: Transitive attribute. Ideally, it would be great to carry the valu= e >>>> in next-hop field of MP_REACH_NLRI, but the length is limited to 8 byt= es, >>>> hence the new attribute. I do not have strong arguments to making this >>>> transitive, it should be fine to go with non-transitive and correspond= ing >>>> error handling. >>>> >>>> Re: Security. Since we do not directly influence path selection with >>>> new data, the threats could be limited to those targeting BGPinfra its= elf >>>> e.g. flooding with information, disrupting session etc. There could be >>>> questions about information authenticity, but this could be left up to= the >>>> applications to decide (e.g. signing the key-value bindings). >>>> >>>> Regards, >>>> >>>> Petr >>>> >>>> ------------------------------ >>>> *From:* rraszuk@gmail.com [rraszuk@gmail.com] on behalf of Robert >>>> Raszuk [robert@raszuk.net] >>>> *Sent:* Saturday, March 12, 2016 1:10 PM >>>> *To:* Petr Lapukhov; exa@juniper.net >>>> *Cc:* idr wg >>>> *Subject:* Use of BGP for Opaque Signaling >>>> >>>> =E2=80=8BPetr, Eben, >>>> >>>> I have few questions and comments to your proposal. >>>> >>>> - The draft =E2=80=8Battempts to reuse BGP mechanism for p2mp distribu= tion of >>>> opaque information. That alone is not a bad thing :) However when you = make >>>> reference to BGP-LS it needs to be observed that BGP-LS is not positio= n to >>>> directly impact routing (ie content of RIB and FIBs) unlike one of the= use >>>> cases described in your draft Intro paragraph. That means that unlike >>>> BGP-LS it must co-exist with routing BGP on the same BGP speakers. >>>> >>>> Here I would like to bring back my proposal to define new port for >>>> Transport Instance BGP >>>> https://tools.ietf.org/html/draft-raszuk-ti-bgp-01 >>>> >>>> which at the time of discussion was supposed to be shortly addressed >>>> by dynamic port allocations of multisessions which to the best of my >>>> knowledge never happened. >>>> >>>> So first comment is that if we go with reusing BGP-4 for this type of >>>> signalling let's enforce it's early separation from "classic" BGP. >>>> >>>> - Second comment is related to the scope of use. If the scope is >>>> private - let's perhaps enforce it more explicitly such that by the sp= ec it >>>> is illegal AFI/SAFI pair in the public Internet. For example by statin= g >>>> that it is illegal to have non private AS in the AS_PATH of such UPDAT= E >>>> msg. >>>> >>>> - Third the draft states that there is no new security implications .. >>>> well if the scope is non private I am afraid that is no the case. As y= ou >>>> have seen (and still seeing) securing BGP UPDATE MSG is MP_REACH conte= nt >>>> dependent. If content is free form I am afraid it will be rather hard = to >>>> secure it well :) >>>> >>>> - Last as opaque value container you are defining an transitive >>>> attribute ? Is the intention to use this attribute in existing AFI/SAF= Is as >>>> well ? Otherwise if not why do you need this to be transitive if capab= ility >>>> negotiation already may implicitly define it's support by new AFI/SAFI= . >>>> >>>> Cheers, >>>> R. >>>> >>>> PS. >>>> >>>> > There is an ongoing discussion around avoiding NLRI (key) collisions= . >>>> >>>> Where is such discussion taking place ? Shouldn't IDR be perhaps in th= e >>>> loop a bit :) >>>> >>>> >>>> >>>> >>>> >>> >>> _______________________________________________ >>> 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 > > > --047d7b3a8bd22af717052df385c9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Gunter,

In BGP path selection happens per prefix. Here prefix= is either key alone (new SAFI) or v4/6+key (existing SAFIs).

So there is rather no difference if= you add different set of attributes to enforce path selection to one or ot= her UPDATE Msgs unless you are talking about completely new rules for selec= ting best path in the new SAFI (which may be rather contr-argument :)
=

Moreover draft already says= that use of add-paths may be useful and that alone would rather be much si= mpler to have it enabled for existing SAFIs (where it is already working) v= s in the new ones of quite loosely defined NLRI semantics.=C2=A0

Cheers,
R.=C2=A0

=C2=A0

On Sun, Mar 13, 2016 at 3:42 PM, = Gunter Van De Velde <guntervandeveldecc@icloud.com> wrote:
One of the questions in the equation is if signalling of Opaque infor= mation needs potentially modified/different path selection mechanisms compa= red to a placeholder IPv6 NLRI + wide community.

Ciao,
G/


=
On 13 Mar 2016, at 20:12, Robert Ra= szuk <robert@rasz= uk.net> wrote:

Pet= r,

> E.g., you need an NLRI of some kin= d to attach the communities, i.e. every originator=C2=A0
> ne= eds to inject a prefix - which isn't too bad implementation wise, but t= ies information=C2=A0
> distribution to reachability info

True about nee= d for NLRI. Not so true about putting equal sign between NLRI and reachabil= ity in existing SAFIs IMHO.=C2=A0

Let's consider that we define a special (v6) prefix which= will be used as an NLRI prefix for your opaque distribution. Part of such = prefix (suffix) can be your key (verbatim) ... values on the other hand can= be carried in wide communities or if you insist in your new attribute. We = could even have one for v4 too - say 240.*.*.*.=C2=A0

It will be much easier to filter or accept = such UPDATE messages and policy required will be pretty much the same as fi= ltering to accept or drop some keys from your new SAFI. Besides AFI/SAFI 2/= 1 is already there both on RRs or ASBRs hence interested parties may not ne= ed to upgrade OS running on those routers.=C2=A0
Besides we have already seen from the other draf= ts (for example=C2=A0Stephane's https://tools.ietf.org= /html/draft-litkowski-idr-bgp-timestamp-02) the need to define such spe= cial NLRIs to carry opaque information in existing SAFIs which do not reall= y need to be processed by BGP implementations.=C2=A0

> Furthermore, wide communities could be interpreted by BGP p= rocess

Only if you configure them to be pr= ocessed or they are registered as public and their types are maintained by = IANA. The default is opaque just as you need it.=C2=A0

Thoughts ?=C2=A0

Best,
Robert.


On Sun, Mar 13, 2016 at 12:37 PM, Petr Lapukhov <petr@fb.com> wrote:
Robert, I to= tally looked at the wide communities before trying the opaque stuff. Howeve= r, there was some semantical awkwardness in regard to transporting opaque d= ata. E.g., you need an NLRI of some kind to attach the communities, i.e. every originator= needs to inject a prefix - which isn't too bad implementation wise, bu= t ties information distribution to reachability info, requiring a policy to= ignore this reachability information. I really don't like adding more policies :)=C2=A0

Furthermore, wide communities could be interpreted by BGP process, and= hence their implementation is a bit more involved and requires more intero= p testing. The opaque AFI simply acts as a pipe to disseminate bits in the = domain (e.g. we use thrift to encode values). Implementing it requires accepting the new AFI/SAFI and skipping = IP-specific policy code (e.g. filtering only on attributes).

Most importantly, opaque data is "free" of any structure tha= t could require further standardization :) This is on purpose - I was hopin= g to have this channel defined once, and let it go without any further need= of defining additional sub-structures...

PS
The 64K messages would be pretty awesome! :) Having the 4K limit in so= me cases requires annoying value fragmentation. Ugh.

From= : rraszuk@gmail.= com [rraszuk@gma= il.com] on behalf of Robert Raszuk [robert@raszuk.net]
Sent: Sunday, March 13, 2016 7:59 AM
To: Gunter Van De Velde
Cc: Petr Lapukhov; idr wg
Subject: Re: [Idr] Use of BGP for Opaque Signaling

Hi Gunter,

For dissemination of information produced by network applications we alread= y have today various tools be it ansible, chef, puppet etc ...=C2=A0

If there is need to use inter-domain distribution of such applications I se= e no reason why not to define registered or private wide bgp community and = use this as transport instead of new SAFI on already established BGP sessio= ns. Note that wide BGP community precisely like new attribute being proposed here can carry opaque to BGP d= ata.=C2=A0

Hi Petr,

Do you see any issue with the above wide community approach to address you = needs ? Especially for bootstrapping the transport it is even easier as you= do not need to enable new SAFI. And those are already IDR WG docs.=C2=A0


As far as limit of 4K let's all note that we already have a draft addre= ssing this and moving the limit to 65K:=C2=A0https://tools.ietf.org/html/draft-ietf-idr-bgp-extended-me= ssages-11

Cheers,
r.





On Sun, Mar 13, 2016 at 5:11 AM, Gunter Van De V= elde <gunt= ervandeveldecc@icloud.com> wrote:
imo the promise of a proposal like this one, is that it allows Applica= tion development at DevOps speed and removes slowness of industry bodies fo= r innovation.

I believe it is a valid problem space that is being addressed. Maybe s= ome features/optimisations from EVN could be transplanted? (i.e. Designated= router selection, aliasing and mass-withdraw)

G/


On 13 Mar 2016, at 04:20, Petr Lapukhov <petr@fb.com> wrote:

>=C2=A0In fact I am not convinced p2mp is the best way to go with here.=C2= =A0
> Pub-sub without RTC hacks may be much better - don't you honestly= think ?=C2=A0

Not exactly, bu= t maybe I misunderstood what p2mp means :) The main advantage of using BGP = (at least in our environment) comes from the fact that it's already boo= tstrapped when on-switch (or on-server) applications start coming up. And it stays there even when the servers hos= ting external key-value store may be gone.=C2=A0

Aside from this= , I fully agree - it does not offer much more than any key-value store. And= it has its own constraints, like ~4K value size. Plus, it's not even a= proper pub-sub, since there is no discreet message semantic - only state dissemination :)
From:<= span>=C2=A0rr= aszuk@gmail.com=C2=A0[rraszuk@gmail.com] on behalf of Robert Raszuk [robert@rasz= uk.net]
Sent:=C2=A0Saturday, March 12, 2016 5:25 PM
To:=C2=A0Petr Lapukhov
Cc:=C2=A0exa@juniper.net; idr wg
Subject:=C2=A0Re: Use of BGP for Opaque Signaling

=E2=80=8BHello Petr,=E2=80=8B
=C2=A0
Re: Impact on routing. I should be more= explicit stating that the idea is for BGP to not interpret the key-value m= appings in any way.

=E2=80=8BThat was very clear already. But if you look at number of BGP impl= ementations recognizing the AFI/SAFI coming over single session is not done= immediately in the BGP message parsing. That is my main point suggesting t= ransport instance port.=C2=A0

I no longer believe multisessions will do it neither that we could off load= it as implementation specific thing.=E2=80=8B

=C2=A0
The consumer (running on same device, p= ossibly) may still influence routing based on its interpretation of data, e= ither by accessing the platform SDK or by performing BGP routing injection = over the corresponding AFI/SAFI.

=E2=80=8BThat is exactly the issue. The only way BGP-LS went by was the cla= im about their explicit disjointed topology from existing BGP. It was well = positioned that BGP-LS can be completely incongruent with "routing&quo= t; BGP. =E2=80=8B

=E2=80=8BThe possible channels the IGP information may impact routing were = classified as out of the band likely coming via some other ways from contro= llers (I2RS, APIs, routing BGP SAFI etc ...).=C2=A0

=C2=A0
Re: Transport instance. I think it's a great idea to run this on s= eparate instance, but right now we typically run just one process, and it a= dds some operational overhead to maintain two of them. Also, often this ext= ension could be used just with out-of-band reflection. This is why I feel it is rather better to keep this applicable= to any type of BGP instance.


=E2=80=8BImagine that you will not get far in this BGP proposal. Then what = is left is nothing else like a new process talking over one of few message = buses today to distribute the set of information you need.=C2=A0

In fact I am not convinced p2mp is the best way to go with here. Pub-sub wi= thout RTC hacks may be much better - don't you honestly think ?=C2=A0

Best,
R.=E2=80=8B

=C2=A0
Re: Scope of application. The main goal= was to use this in data-center, but I can theorize this could be used amon= g few operators that are willing to develop on-device applications and exch= ange data using the pre-established channels (e.g. the WISER use case). In this situation, limiting scope to j= ust private ASNs could be tricky. Furthermore, non-private ASNs could be us= ed in data-center as well (just not exposed outside...).

Re: Transitive attribute. Ideally, it would be great to carry the valu= e in next-hop field of MP_REACH_NLRI, but the length is limited to 8 bytes,= hence the new attribute. I do not have strong arguments to making this tra= nsitive, it should be fine to go with non-transitive and corresponding error handling.=C2=A0

Re: Security. Since we do not directly influence path selection with n= ew data, the threats could be limited to those targeting BGPinfra itself e.= g. flooding with information, disrupting session etc. There could be questi= ons about information authenticity, but this could be left up to the applications to decide (e.g. signing the = key-value bindings).

Regards,

Petr

From:<= span>=C2=A0rr= aszuk@gmail.com=C2=A0[rraszuk@gmail.com] on behalf of Robert Raszuk [robert@rasz= uk.net]
Sent:=C2=A0Saturday, March 12, 2016 1:10 PM
To:=C2=A0Petr Lapukhov;=C2=A0exa@juniper.net
Cc:=C2=A0idr wg
Subject:=C2=A0Use of BGP for Opaque Signaling

=E2= =80=8BPetr, Eben,

I hav= e few questions and comments to your proposal.=C2=A0

- The= draft =E2=80=8Battempts to reuse BGP mechanism for p2mp distribution of op= aque information. That alone is not a bad thing :) However when you make re= ference to BGP-LS it needs to be observed that BGP-LS is not position to directly impact routing (ie content of RIB = and FIBs) unlike one of the use cases described in your draft Intro paragra= ph. That means that unlike BGP-LS it must co-exist with routing BGP on the = same BGP speakers.=C2=A0

Here = I would like to bring back my proposal to define new port for Transport Ins= tance BGP=C2=A0https://tools.ietf.org/html/draft-= raszuk-ti-bgp-01=C2=A0which at the time of discussion was supposed to be shortly addressed by dynamic = port allocations of multisessions which to the best of my knowledge never h= appened.=C2=A0

So fi= rst comment is that if we go with reusing BGP-4 for this type of signalling= let's enforce it's early separation from "classic" BGP.= =C2=A0

- Sec= ond comment is related to the scope of use. If the scope is private - let&#= 39;s perhaps enforce it more explicitly such that by the spec it is illegal= AFI/SAFI pair in the public Internet. For example by stating that it is illegal to have non private AS in the AS= _PATH of such UPDATE msg.=C2=A0

- Thi= rd the draft states that there is no new security implications .. well if t= he scope is non private I am afraid that is no the case. As you have seen (= and still seeing) securing BGP UPDATE MSG is MP_REACH content dependent. If content is free form I am afraid it = will be rather hard to secure it well :)=C2=A0

- Las= t as opaque value container you are defining an transitive attribute ? Is t= he intention to use this attribute in existing AFI/SAFIs as well ? Otherwis= e if not why do you need this to be transitive if capability negotiation already may implicitly define it&#= 39;s support by new AFI/SAFI.

Cheer= s,
R.

PS.= =C2=A0

> There is an ongoing = discussion around avoiding NLRI (key) collisions.

Where is such discussion = taking place ? Shouldn't IDR be perhaps in the loop a bit :)=C2=A0



=C2= =A0

___________________________________________= ____
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listi= nfo/idr



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

<= /div>

--047d7b3a8bd22af717052df385c9-- From nobody Sun Mar 13 21:37:52 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CC2C12DA0C for ; Sun, 13 Mar 2016 21:37:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 ocqsblMi_zLP for ; Sun, 13 Mar 2016 21:37:48 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFA5E12D9CA for ; Sun, 13 Mar 2016 21:37:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16082; q=dns/txt; s=iport; t=1457930267; x=1459139867; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=DVHgC7D/c+CzOI2QIpcolxo5VHXDx/tt5syMZm1c/9s=; b=IKtafolrC1B5g76uKklhaZtQOqgVtG3W2Qo4Q1sk1bdkk0cbpJ5IALz0 45IBjb0QDobqyfIooiBGyqPSS8B/EI7FxpA7EknF26QSXP7l4mtXksL3P 5/lt+KxXWUkpjg1Ek5WlkfEbk7NgMX8SnJdAx/XBgCCwEPnUqwqYIqe6U E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AmAgBOP+ZW/4cNJK1dgnpMUm0GuioBD?= =?us-ascii?q?YFtIIVtAoEmOBQBAQEBAQEBZCeEQQEBAQQtXAIBCBEEAQEoBzIUCQgBAQQBEgg?= =?us-ascii?q?BEogJDro7AQEBAQEBAQEBAQEBAQEBAQEBAQEBFYYYhEKEZwmEBAWIO4R+hUqES?= =?us-ascii?q?AGFbYgLgWxLhySFMYYIiHQBHgEBQoFMNxmBSGoBAQGJYn4BAQE?= X-IronPort-AV: E=Sophos;i="5.24,334,1454976000"; d="scan'208,217";a="249112032" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Mar 2016 04:37:46 +0000 Received: from XCH-RCD-014.cisco.com (xch-rcd-014.cisco.com [173.37.102.24]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u2E4bkQb018803 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 14 Mar 2016 04:37:46 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-RCD-014.cisco.com (173.37.102.24) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sun, 13 Mar 2016 23:37:45 -0500 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1104.009; Sun, 13 Mar 2016 23:37:45 -0500 From: "Jakob Heitz (jheitz)" To: Petr Lapukhov , "idr@ietf.org" Thread-Topic: draft-lapukhov-bgp-opaque-signaling Thread-Index: AdF8nS8FQTTx9jiyQtWM4z1Bl2FmugABRu++AABFuBAAPFwa0A== Date: Mon, 14 Mar 2016 04:37:45 +0000 Message-ID: <82489e182ab34b74a29cea2f5e3866bf@XCH-ALN-014.cisco.com> References: <2d12cade49ac4ec19a7f2c80aee3b72d@XCH-ALN-014.cisco.com> <3F437107848A5140A6A19222EFFB3481200E2389@PRN-MBX01-2.TheFacebook.com> <976fb2df5f974b298a04b547afb917b7@XCH-ALN-014.cisco.com> In-Reply-To: <976fb2df5f974b298a04b547afb917b7@XCH-ALN-014.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.75.186] Content-Type: multipart/alternative; boundary="_000_82489e182ab34b74a29cea2f5e3866bfXCHALN014ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] draft-lapukhov-bgp-opaque-signaling X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2016 04:37:50 -0000 --_000_82489e182ab34b74a29cea2f5e3866bfXCHALN014ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I was thinking more of how a service provider would use this with different customers that don't know about each other, like preventing ships in the ni= ght from crashing into each other. However, it could work in private. Without a route target, any data sent will go everywhere and be stored in e= very router. You probably don't want that. This new AFI should require a route target. That means an update message wi= thout an RT must be dropped. BGP treats all updates the same. Once the floodgates are open to generic data, you might want to invent a pr= ecedence attribute. Thanks, Jakob. From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jakob Heitz (jheitz) Sent: Saturday, March 12, 2016 1:12 PM To: Petr Lapukhov ; idr@ietf.org Subject: Re: [Idr] draft-lapukhov-bgp-opaque-signaling Without this problem solved, the proposal is not useful. Everybody using it must stick to the eventual solution to ensure interopera= bility. Therefore, it should be inside the scope. Actually, BGP already has a way to distinguish applicationd: AFI and SAFI. Jakob. From: Petr Lapukhov [mailto:petr@fb.com] Sent: Saturday, March 12, 2016 1:06 PM To: Jakob Heitz (jheitz) ; idr@ietf.org Subject: RE: draft-lapukhov-bgp-opaque-signaling Hi Jakob, There is an ongoing discussion around avoiding NLRI (key) collisions. For n= ow, the plan is to externally generate unique key prefix per application, e= .g. application name, or UUID or some other globally unique string. Ensurin= g the uniqueness of those prefixes is outside the scope of the proposal, th= ough - it's more of a deployment consideration. Regards, Petr ________________________________ From: Idr [idr-bounces@ietf.org] on behalf of Jakob Heitz (jheitz) [jheitz@= cisco.com] Sent: Saturday, March 12, 2016 12:26 PM To: idr@ietf.org Subject: [Idr] [WARNING : A/V UNSCANNABLE] draft-lapukhov-bgp-opaque-signal= ing I read http://www.ietf.org/id/draft-lapukhov-bgp-opaque-signaling-01.txt Is this intended for any and multiple applications to use? If so, how do independent applications guarantee no duplication in NLRI? If not, what is the target application? Thanks Jakob. --_000_82489e182ab34b74a29cea2f5e3866bfXCHALN014ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I was thinking more of how a service= provider would use this with different

customers that don't know about each= other, like preventing ships in the night from

crashing into each other. However, i= t could work in private.

 

Without a route target, any data sen= t will go everywhere and be stored in every router.

You probably don't want that.

This new AFI should require a route = target. That means an update message without an RT must be dropped.

 

BGP treats all updates the same.

Once the floodgates are open to gene= ric data, you might want to invent a precedence attribute.

 

Thanks,

Jakob.

 

&nb= sp;

From: Idr [mailto:idr-bounces@ietf.org] On= Behalf Of Jakob Heitz (jheitz)
Sent: Saturday, March 12, 2016 1:12 PM
To: Petr Lapukhov <petr@fb.com>; idr@ietf.org
Subject: Re: [Idr] draft-lapukhov-bgp-opaque-signaling

 

Without this problem solved, the pro= posal is not useful.

Everybody using it must stick to the= eventual solution to ensure interoperability.

Therefore, it should be inside the s= cope.

 

Actually, BGP already has a way to d= istinguish applicationd: AFI and SAFI.

 

Jakob.

 

From: Petr Lapukhov [mailto:petr@fb.com]
Sent: Saturday, March 12, 2016 1:06 PM
To: Jakob Heitz (jheitz) <jheitz@cisco.com>; idr@ietf.org
Subject: RE: draft-lapukhov-bgp-opaque-signaling

 

Hi Jakob,

 

There is an ongoing discussion around av= oiding NLRI (key) collisions. For now, the plan is to externally generate u= nique key prefix per application, e.g. application name, or UUID or some other globally unique string. Ensuring the uniq= ueness of those prefixes is outside the scope of the proposal, though - it'= s more of a deployment consideration.

 

Regards,

 

Petr

 

From:<= /span> Idr [idr-bounces@ietf.org] on behalf of Jakob Heitz (jheitz) [jheitz@cisco.com]
Sent: Saturday, March 12, 2016 12:26 PM
To: idr@ietf.org
Subject: [Idr] [WARNING : A/V UNSCANNABLE] draft-lapukhov-bgp-opaque= -signaling

I read

http://www.ietf.org/id/draft-lapukhov-bgp-opaque-sig= naling-01.txt

 

Is this intended for any and multipl= e applications to use?=

If so, how do independent applicatio= ns guarantee no duplication in NLRI?

If not, what is the target applicati= on?

 

Thanks

Jakob.

--_000_82489e182ab34b74a29cea2f5e3866bfXCHALN014ciscocom_-- From nobody Sun Mar 13 22:51:50 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B999112DA2E for ; Sun, 13 Mar 2016 22:51:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 OET5toBdJTfo for ; Sun, 13 Mar 2016 22:51:46 -0700 (PDT) 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 4FE6112D8C3 for ; Sun, 13 Mar 2016 22:51:45 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CFY07951; Mon, 14 Mar 2016 05:51:43 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml706-cah.china.huawei.com (10.201.5.182) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 14 Mar 2016 05:51:41 +0000 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Mon, 14 Mar 2016 13:51:34 +0800 From: Zhuangshunwan To: "Van De Velde, Gunter (Nokia - BE)" , "idr@ietf.org" Thread-Topic: [Feedback request] Are there implementations of draft-ietf-idr-flowspec-redirect-ip-02 out there? Thread-Index: AQHRaMIwf2HTDCcwb0qQXOqjdaaCNZ9Ykzxw Date: Mon, 14 Mar 2016 05:51:34 +0000 Message-ID: <19AB2A007F56DB4E8257F949A2FB9858AA1A1713@NKGEML515-MBX.china.huawei.com> References: <09D3C0C6-E1B5-496B-82C9-93D7A745E196@alcatel-lucent.com> In-Reply-To: <09D3C0C6-E1B5-496B-82C9-93D7A745E196@alcatel-lucent.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.86.254] Content-Type: multipart/alternative; boundary="_000_19AB2A007F56DB4E8257F949A2FB9858AA1A1713NKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.56E6516F.00E0, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: d57e347661a8a7b9a3d48c6e3c04f527 Archived-At: Subject: Re: [Idr] [Feedback request] Are there implementations of draft-ietf-idr-flowspec-redirect-ip-02 out there? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2016 05:51:49 -0000 --_000_19AB2A007F56DB4E8257F949A2FB9858AA1A1713NKGEML515MBXchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQWxsLA0KDQpJIGFsc28gd2FudCB0byBrbm93IHRoZSBhbnN3ZXIgdGhhdCBHdW50ZXIgcmVx dWVzdGVkLg0KSSBrbm93IHNvbWUgY3VycmVudCBpbXBsZW1lbnRhdGlvbnMgcGVyIGRyYWZ0LXNp bXBzb24taWRyLWZsb3dzcGVjLXJlZGlyZWN0LTAyOiBSZWRpcmVjdCBOZXh0SG9wIGlzIGVuY29k ZWQgYXMgdGhlIE1QX1JFQUNIIE5leHRIb3AgaW4gdGhlIEJHUCBmbG93c3BlYyBOTFJJIGFsb25n IHdpdGggYXNzb2NpYXRlZCBleHRlbmRlZCBjb21tdW5pdHkgMHgwODAwLg0KDQpXaGVuIHNvbWUg TmV0d29yayBPcGVyYXRpb24gU3lzdGVtcyBpbnRlbmQgdG8gaW1wbGVtZW50IFJlZGlyZWN0IE5l eHRIb3AgZnVuY3Rpb24sIHRoZXkgaGF2ZSB0byBkbyBkcmFmdC1zaW1wc29uLWlkci1mbG93c3Bl Yy1yZWRpcmVjdC0wMiBpbnN0ZWFkIG9mIGRyYWZ0LWlldGYtaWRyLWZsb3dzcGVjLXJlZGlyZWN0 LWlwIGZvciBpbnRlcm9wZXJhYmlsaXR5IHJlcXVpcmVtZW50cy4NCg0KV2hlbiBzaG91bGQgdGhl IGltcGxlbWVudGF0aW9ucyBiZSBjb25zaXN0ZW50IHdpdGggV0cgZG9jIGRyYWZ0LWlldGYtaWRy LWZsb3dzcGVjLXJlZGlyZWN0LWlwPw0KDQpSZWdhcmRzLA0KU2h1bndhbg0KDQrlj5Hku7bkuro6 IElkciBbbWFpbHRvOmlkci1ib3VuY2VzQGlldGYub3JnXSDku6PooaggVmFuIERlIFZlbGRlLCBH dW50ZXIgKE5va2lhIC0gQkUpDQrlj5HpgIHml7bpl7Q6IDIwMTblubQy5pyIMTbml6UgMjE6NTkN CuaUtuS7tuS6ujogaWRyQGlldGYub3JnDQrkuLvpopg6IFtJZHJdIFtGZWVkYmFjayByZXF1ZXN0 XSBBcmUgdGhlcmUgaW1wbGVtZW50YXRpb25zIG9mIGRyYWZ0LWlldGYtaWRyLWZsb3dzcGVjLXJl ZGlyZWN0LWlwLTAyIG91dCB0aGVyZT8NCg0KDQoNCkhpIEFsbCwNCg0KSSBhbHJlYWR5IGRpZCBh IHByZS1jaGVjayB3aXRoIHRoZSBjby1hdXRob3JzIG9mIHRoaXMgZHJhZnQgYWxyZWFkeSwgYW5k IGFtIG5vdyByZWFjaGluZyBvdXQgdG8gdGhlIElEUiBXRy4NCg0KSW4gdGhlIGJhY2tlbmQgcHJv Y2VzcyBvZiBoZWxwaW5nIFdpbS9BZGFtIHJlZ2FyZGluZyBkcmFmdC1pZXRmLWlkci1mbG93c3Bl Yy1yZWRpcmVjdC1pcCB0byByZXF1ZXN0IElBTkEgYW4gZXh0ZW5kZWQgY29tbXVuaXR5IHN1Yi10 eXBlIHRvIGZ1cnRoZXIgdXBkYXRlIHRoZSBkcmFmdCBpIHdhcyB3b25kZXJpbmcgaWYgYW55IGlt cGxlbWVudGVkIGRyYWZ0LWlldGYtaWRyLWZsb3dzcGVjLXJlZGlyZWN0LWlwLTAxIG9yIGRyYWZ0 LWlldGYtaWRyLWZsb3dzcGVjLXJlZGlyZWN0LWlwLTAyID8gSWYgeWVzLCB3aGF0IGlzIHRoZSBz dWItdHlwZSB5b3UgdXNlZD8NCg0KSSB1bmRlcnN0b29kIHRoYXQgc29tZSBwb3RlbnRpYWxseSBp bXBsZW1lbnRlZCBlYXJsaWVyIGRyYWZ0LXNpbXBzb24taWRyLWZsb3dzcGVjLXJlZGlyZWN0LTAy ICwgYnV0IHRoYXQgb25lIGlzIGVmZmVjdGl2ZWx5IGJlaW5nIGRlcHJlY2F0ZWQuDQoNCk1hbnkg dGhhbmtzIGZvciB5b3VyIHJlc3BvbnNlcywNCkcvDQoNCg0K --_000_19AB2A007F56DB4E8257F949A2FB9858AA1A1713NKGEML515MBXchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0K CW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1s PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpl eHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVs YXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJaSC1DTiIgbGlu az0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2NvbG9yOiMxRjQ5N0QiPkhpIEFsbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9y OiMxRjQ5N0QiPkkgYWxzbyB3YW50IHRvIGtub3cgdGhlIGFuc3dlciB0aGF0IEd1bnRlciByZXF1 ZXN0ZWQuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6IzFGNDk3RCI+SSBr bm93IHNvbWUgY3VycmVudCBpbXBsZW1lbnRhdGlvbnMgcGVyIGRyYWZ0LXNpbXBzb24taWRyLWZs b3dzcGVjLXJlZGlyZWN0LTAyOiBSZWRpcmVjdCBOZXh0SG9wIGlzIGVuY29kZWQgYXMgdGhlIE1Q X1JFQUNIIE5leHRIb3AgaW4gdGhlIEJHUCBmbG93c3BlYyBOTFJJIGFsb25nIHdpdGggYXNzb2Np YXRlZA0KIGV4dGVuZGVkIGNvbW11bml0eSAweDA4MDAuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtjb2xvcjojMUY0OTdEIj5XaGVuIHNvbWUgTmV0d29yayBPcGVyYXRpb24gU3lzdGVtcyBpbnRl bmQgdG8gaW1wbGVtZW50IFJlZGlyZWN0IE5leHRIb3AgZnVuY3Rpb24sIHRoZXkgaGF2ZSB0byBk byBkcmFmdC1zaW1wc29uLWlkci1mbG93c3BlYy1yZWRpcmVjdC0wMiBpbnN0ZWFkIG9mIGRyYWZ0 LWlldGYtaWRyLWZsb3dzcGVjLXJlZGlyZWN0LWlwDQogZm9yIGludGVyb3BlcmFiaWxpdHkgcmVx dWlyZW1lbnRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6IzFGNDk3RCI+V2hlbiBz aG91bGQgdGhlIGltcGxlbWVudGF0aW9ucyBiZSBjb25zaXN0ZW50IHdpdGggV0cgZG9jIGRyYWZ0 LWlldGYtaWRyLWZsb3dzcGVjLXJlZGlyZWN0LWlwPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Y29sb3I6IzFGNDk3RCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29s b3I6IzFGNDk3RCI+U2h1bndhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQg MGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk65a6L5L2TIj7lj5Hku7bkuro8c3BhbiBsYW5nPSJFTi1V UyI+Ojwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTrlrovkvZMiPiBJZHIgW21haWx0bzppZHItYm91bmNlc0BpZXRm Lm9yZ10NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTrlrovkvZMiPuS7o+ihqCA8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTrlrovkvZMiPlZhbiBEZSBWZWxkZSwgR3VudGVyIChO b2tpYSAtIEJFKTxicj4NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTrlrovkvZMiPuWPkemAgeaXtumXtDxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFu Pjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OuWui+S9kyI+IDIwMTY8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk65a6L5L2TIj7lubQ8c3BhbiBsYW5nPSJFTi1VUyI+Mjwvc3Bhbj7mnIg8 c3BhbiBsYW5nPSJFTi1VUyI+MTY8L3NwYW4+5pelPHNwYW4gbGFuZz0iRU4tVVMiPg0KIDIxOjU5 PGJyPg0KPC9zcGFuPjxiPuaUtuS7tuS6ujxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvYj48 c3BhbiBsYW5nPSJFTi1VUyI+IGlkckBpZXRmLm9yZzxicj4NCjwvc3Bhbj48Yj7kuLvpopg8c3Bh biBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBbSWRyXSBbRmVl ZGJhY2sgcmVxdWVzdF0gQXJlIHRoZXJlIGltcGxlbWVudGF0aW9ucyBvZiBkcmFmdC1pZXRmLWlk ci1mbG93c3BlYy1yZWRpcmVjdC1pcC0wMiBvdXQgdGhlcmU/PG86cD48L286cD48L3NwYW4+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtj b2xvcjpibGFjayI+SGkgQWxsLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+SSBhbHJlYWR5IGRp ZCBhIHByZS1jaGVjayB3aXRoIHRoZSBjby1hdXRob3JzIG9mIHRoaXMgZHJhZnQgYWxyZWFkeSwg YW5kIGFtIG5vdyByZWFjaGluZyBvdXQgdG8gdGhlIElEUiBXRy4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFj ayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Nv bG9yOmJsYWNrIj5JbiB0aGUgYmFja2VuZCBwcm9jZXNzIG9mIGhlbHBpbmcgV2ltL0FkYW0gcmVn YXJkaW5nIGRyYWZ0LWlldGYtaWRyLWZsb3dzcGVjLXJlZGlyZWN0LWlwIHRvIHJlcXVlc3QgSUFO QSBhbiBleHRlbmRlZCBjb21tdW5pdHkgc3ViLXR5cGUgdG8gZnVydGhlciB1cGRhdGUgdGhlIGRy YWZ0IGkgd2FzIHdvbmRlcmluZw0KIGlmIGFueSBpbXBsZW1lbnRlZCZuYnNwO2RyYWZ0LWlldGYt aWRyLWZsb3dzcGVjLXJlZGlyZWN0LWlwLTAxIG9yJm5ic3A7ZHJhZnQtaWV0Zi1pZHItZmxvd3Nw ZWMtcmVkaXJlY3QtaXAtMDIgPyBJZiB5ZXMsIHdoYXQgaXMgdGhlIHN1Yi10eXBlIHlvdSB1c2Vk PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFj ayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Nv bG9yOmJsYWNrIj5JIHVuZGVyc3Rvb2QgdGhhdCBzb21lIHBvdGVudGlhbGx5IGltcGxlbWVudGVk IGVhcmxpZXIgZHJhZnQtc2ltcHNvbi1pZHItZmxvd3NwZWMtcmVkaXJlY3QtMDIgLCBidXQgdGhh dCBvbmUgaXMgZWZmZWN0aXZlbHkgYmVpbmcgZGVwcmVjYXRlZC48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+TWFueSB0aGFu a3MgZm9yIHlvdXIgcmVzcG9uc2VzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtjb2xvcjpibGFjayI+Ry88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_19AB2A007F56DB4E8257F949A2FB9858AA1A1713NKGEML515MBXchi_-- From nobody Mon Mar 14 05:21:33 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A866B12D594 for ; Mon, 14 Mar 2016 05:21:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 MyGaXMyRz5Yy for ; Mon, 14 Mar 2016 05:21:28 -0700 (PDT) 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 B4C3C12D591 for ; Mon, 14 Mar 2016 05:21:27 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CFZ42751; Mon, 14 Mar 2016 12:21:25 +0000 (GMT) Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml703-cah.china.huawei.com (10.201.5.104) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 14 Mar 2016 12:21:23 +0000 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0235.001; Mon, 14 Mar 2016 20:21:14 +0800 From: Zhuangshunwan To: Huaimo Chen , "idr@ietf.org" Thread-Topic: [Idr] WG Work item call - Opinions on work items (3/5/2016 to 3/17/2016) and adoption of draft-hares-idr-flowspec-combo-01.txt Thread-Index: AQHRfKtl/LaN5Kls00m8JEClXywhj59Y3YJA Date: Mon, 14 Mar 2016 12:21:14 +0000 Message-ID: <19AB2A007F56DB4E8257F949A2FB9858AA1A2859@NKGEML515-MBX.china.huawei.com> References: <2d12cade49ac4ec19a7f2c80aee3b72d@XCH-ALN-014.cisco.com> <3F437107848A5140A6A19222EFFB3481200E2389@PRN-MBX01-2.TheFacebook.com> <976fb2df5f974b298a04b547afb917b7@XCH-ALN-014.cisco.com> <5316A0AB3C851246A7CA5758973207D44E4EFB05@SJCEML702-CHM.china.huawei.com> In-Reply-To: <5316A0AB3C851246A7CA5758973207D44E4EFB05@SJCEML702-CHM.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.86.254] Content-Type: multipart/alternative; boundary="_000_19AB2A007F56DB4E8257F949A2FB9858AA1A2859NKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.56E6ACC5.021E, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: b08adeac930db02b388e15a11341e427 Archived-At: Cc: Susan Hares Subject: Re: [Idr] WG Work item call - Opinions on work items (3/5/2016 to 3/17/2016) and adoption of draft-hares-idr-flowspec-combo-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2016 12:21:31 -0000 --_000_19AB2A007F56DB4E8257F949A2FB9858AA1A2859NKGEML515MBXchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 DQpJIGFsc28gc3VwcG9ydCB3b3JraW5nIG9uIGJvdGguDQoNClJlZ2FyZHMsDQpTaHVud2FuDQoN CreivP7IyzogSWRyIFttYWlsdG86aWRyLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gSHVhaW1vIENo ZW4NCreiy83KsbzkOiAyMDE2xOoz1MIxM8jVIDY6MDYNCsrVvP7IyzogaWRyQGlldGYub3JnDQqz rcvNOiBTdXNhbiBIYXJlcw0K1vfM4jogUmU6IFtJZHJdIFdHIFdvcmsgaXRlbSBjYWxsIC0gT3Bp bmlvbnMgb24gd29yayBpdGVtcyAoMy81LzIwMTYgdG8gMy8xNy8yMDE2KSBhbmQgYWRvcHRpb24g b2YgZHJhZnQtaGFyZXMtaWRyLWZsb3dzcGVjLWNvbWJvLTAxLnR4dA0KDQpJIHJlYWQgZHJhZnQt aGFyZXMtaWRyLWZsb3dzcGVjLWNvbWJvLTAxLnR4dCBhbmQgc3VwcG9ydCBpdC4gVGhlIHdvcmsg ZGVzY3JpYmVkIGluIHRoZSBkcmFmdCBpcyB1c2VmdWwgYW5kIHdlbGwgZml0IGluIEJHUC4gUmVn YXJkaW5nIHRvIG9wdGlvbiAxIGFuZCBvcHRpb24gMiwgaW4gdGhlIGN1cnJlbnQgc3RhZ2UsIEkg c3VwcG9ydCB3b3JraW5nIG9uIGJvdGguIEluIHRoZSBsb25nIHJ1biwgSSB0aGluayBvcHRpb24g MiBpcyBiZXR0ZXIuDQoNCkJlc3QgUmVnYXJkcywNCkh1YWltbw0KDQo+IE9uIDA1IE1hciAyMDE2 LCBhdCAyMzo0OCwgU3VzYW4gSGFyZXMgPHNoYXJlc0BuZHpoLmNvbTxtYWlsdG86c2hhcmVzQG5k emguY29tPj4gd3JvdGU6DQo+DQo+IFRoZSBpbnRlcmltIG9uIDMvNy8yMDE2IHdpbGwgaGF2ZSBh IGRpc2N1c3Npb24gb2YgcmV2aXNpb25zIHRvIHRoZSBCR1AgRmxvdyBzcGVjaWZpY2F0aW9uIChC R1AtRlMpIHRvIGFkZCBtb3JlIGZlYXR1cmVzLiAgVGhlcmUgYXJlIHR3byBzdWdnZXN0ZWQgb3B0 aW9uczoNCj4gMSkgICAgICBBIG1pbmltYWwgZmVhdHVyZXMgdG8gZXhpc3RpbmcgQkdQLUZTIChv cHRpb24gMSkNCj4gQWRkIGEgZmV3IG5ldyBtYXRjaCBmaWx0ZXJzIHRvIHRoZSBCR1AtRlMgTkxS SSBhbmQgZmV3IG5ldyBhY3Rpb25zIHRvIHRoZSBCR1AtRlMgYWN0aW9ucyAoaW4gRXh0ZW5kZWQg Y29tbXVuaXRpZXMpLiAgQWN0aW9ucyB3b3VsZCBuZWVkIHRvIGJlIGRvbmUgaW4gYSBkZWZpbmVk IG9yZGVyLiBFYWNoIG5ldyBhY3Rpb25zIHdvdWxkIG5lZWQgdG8gZGVmaW5lIGNvbmZsaWN0cyB3 aXRoIGV4aXN0aW5nIGFjdGlvbnMuDQo+DQo+IEJlc3QgdXNlIGNhc2U6ICBEb1MgYXR0YWNrIHBy ZXZlbnRpb24NCj4NCj4gMikgICAgICBDcmVhdGUgYSBCR1AtRlMgdmVyc2lvbiAyIChvcHRpb24g MikNCj4gQ3JlYXRlIGEgbmV3IEJHUC1GUyBOTFJJICh2Mikgd2l0aCBhIGZpZWxkIHRoYXQgaW5k aWNhdGVzIHRoZSBvcmRlcmluZyBvZiB0aGUgQkdQIE5MUkkuICBBZGQgbmV3IEJHUC1GUyBhY3Rp b25zIHdpdGggYW4gb3JkZXIgZmllbGQgaW4gdGhlIEJHUCBXaWRlIENvbW11bml0aWVzLiAgRmls dGVycyBhcmUgZG9uZSBpbiB0aGUgb3JkZXIgZGVmaW5lZCBpbiB0aGUgZmlsdGVyLiAgQWN0aW9u cyBhcmUgZG9uZSBpbiB0aGUgb3JkZXIgZGVmaW5lZCBpbiB0aGUgYWN0aW9ucy4gICBPcmRlciBu dW1iZXJzIHRoYXQgdGllIGFyZSBoYW5kbGVkIGluIGEgZGVmaW5lZCBvcmRlci4NCj4NCj4gQmVz dCB1c2UgY2FzZTogU0ROL05GViBmaWx0ZXIgbWFuYWdlbWVudA0KPg0KPiBBIHdyaXRlLXVwIG9u IHRoZSBpc3N1ZXMgYW5kIHByb3Bvc2VkIHNvbHV0aW9ucyBpcyBjb250YWluZWQgaW46DQo+IGRy YWZ0LWhhcmVzLWlkci1mbG93c3BlYy1jb21iby0wMS50eHQuICA8aHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtaGFyZXMtaWRyLWZsb3dzcGVjLWNvbWJvLz4gICBUaGUgV0cg Y2FuIHNlbGVjdCBib3RoIG9wdGlvbiAxIGFuZCBvcHRpb24gMi4gIFRoaXMgaXMgYSBXRyB3b3Jr IGl0ZW0gY2FsbCBmb3IgaW5wdXQgdG8gdGhlIGNoYWlycyBvbiB0aGUgc2NvcGUgb2YgdGhlIFdH IGl0ZW0uICBJbiB5b3UgZGlzY3Vzc2lvbiBvZiB0aGlzIHRvcGljcywgdGhlIGNoYWlycyB3b3Vs ZCBhcHByZWNpYXRlIGlmIHlvdSB3b3VsZCBpbmRpY2F0ZSBpZiB5b3Ugd291bGQgc3VwcG9ydCBJ RFIgd29ya2luZyBvbiBvcHRpb24gMSwgb3B0aW9uIDIgb3IgYm90aCBvcHRpb24gMSBhbmQgMi4g IFRoaXMgV0cgY2FsbCBpdGVtcyBhbHNvIGluY2x1ZGVzIGEgY2FsbCBmb3IgZHJhZnQtaGFyZXMt aWRyLWZsb3dzcGVjLWNvbWJvLTAxLnR4dCBhcyBhIHdyaXRlLXVwIG9mIHRoZSB3b3JrLWl0ZW0g b3B0aW9ucy4gIFRoZSBXRyBtYXkgd2lzaCB0byBzcGxpdCB0aGlzIGRyYWZ0IGludG8gbXVsdGlw bGUgZHJhZnRzLg0KPg0KPiBUaGUgZm9sbG93aW5nIGRyYWZ0cyBhcmUgYmVpbmcgY29uc2lkZXIg Zm9yIGVpdGhlciBvcHRpb246DQo+IDEpICAgICAgZHJhZnQtZWRkeS1pZHItZmxvd3NwZWMtcGFj a2V0LXJhdGUNCj4gMikgICAgICBkcmFmdC1oYW8taWRyLWZsb3dzcGVjLW52MDMNCj4gMykgICAg ICBkcmFmdC1oYW8taWRyLWZsb3dzcGVjLWxhYmVsDQo+IDQpICAgICAgZHJhZnQtbGlhbmctaWRy LWJncC1mbG93c3BlYy10aW1lDQo+IDUpICAgICAgZHJhZnQtbGl0b3dza2ktaWRyLWZsb3dzcGVj LWludGVyZmFjZXNldA0KPiA2KSAgICAgIGRyYWZ0LXZhbmRldmVsZGUtaWRyLWZsb3dzcGVjLXBh dGgtcmVkaXJlY3QNCj4gNykgICAgICBkcmFmdC1saS1pZHItZmxvd3NwZWMtcnBkLTAxLnR4dA0K PiA4KSAgICAgIGRyYWZ0LXd1LWlkci1mbG93c3BlYy15YW5nLmNmZy4NCj4NCj4gSWYgeW91IHdp c2ggdG8gY29tbWVudCBvbiBhbnkgb2YgdGhlc2UgZHJhZnRzLCB3ZSB3aWxsDQo+DQo+IFdlIHdp bGwgY29uY2x1ZGUgdGhlIENhbGwgZm9yIFdHIG9waW5pb25zIG9uIDMvMTcvMjAxNiBzbyB0aGVz ZSBhdXRob3JzIGNhbiBoYXZlIGEgZGF5IHRvIHJldmlzZSBhbmQgc3VibWl0IHRoZWlyIGRyYWZ0 cyBiZWZvcmUgdGhlIGRyYWZ0IGRlYWRsaW5lLg0KPg0KPiBTdWUgSGFyZXMgYW5kIEpvaG4gU2N1 ZGRlcg0KPg0KPiBQUzoNCj4gZHJhZnQtbGktaWRyLWZsb3dzcGVjLXJwZCBkaXNjdXNzZXMgbGlt aXRzIG9uIHRoZSBkaXN0cmlidXRpb24gb2YgdGhlIHBvbGljeSB3aGljaCBoYXMgYmVlbiByZWNh c3QgaW4gZHJhZnQtaGFyZXMtaWRyLWZsb3dzcGVjLWNvbWJvIGFzIGEgYmdwLXdpZGUgY29tbXVu aXR5IG9mIENvbnRhaW5lciB0eXBlIDEgd2l0aCBhbiBhdG9tIG9mIEJHUCBGbG93IFNwZWNpZmlj YXRpb24gb3JkZXJpbmcuIEhvd2V2ZXIsICB0aGlzIGRyYWZ0IGlzIGluY2x1ZGVkIGluIHRoZSBs aXN0IHRvIGJlIGFibGUgdG8gdXBkYXRlIHRoZSBtZWNoYW5pc20gZnJvbSB0aGlzIGRyYWZ0IGlu dG8gdGhhdCBjb250ZXh0Lg0KPg0KPiBUaGUgeWFuZyBtb2RlbCBmb3IgQkdQIEZsb3cgc3BlY2lm aWNhdGlvbiBpcyBhbHNvIGluY2x1ZGVkIGluIHRoaXMgd29yayBpdGVtIGFzIGl0IHdpbGwgbmVl ZCB0byBiZSBtb2RpZmllZCBiYXNlZCBvbiB0aGUgYXBwcm9hY2hlcy4gIFRoZSB5YW5nIG1vZGVs IGlzIGluIGRyYWZ0LXd1LWlkci1mbG93c3BlYy15YW5nLWNmZy4gIEluIHlvdXIgY29tbWVudHMs IHBsZWFzZSBpbmRpY2F0ZSBpZiB5b3UgZmVlbCB0aGVzZSBkcmFmdHMgb3Igb3RoZXIgZHJhZnRz Lg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiBJZHIgbWFpbGluZyBsaXN0DQo+IElkckBpZXRmLm9yZzxtYWlsdG86SWRyQGlldGYub3JnPiA8 bWFpbHRvOklkckBpZXRmLm9yZz4NCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9pZHINCg== --_000_19AB2A007F56DB4E8257F949A2FB9858AA1A2859NKGEML515MBXchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

 

I also support working on both.

 

Regards,

Shunwan

 

=B7=A2=BC=FE=C8=CB: Idr [ma= ilto:idr-bounces@ietf.org] =B4=FA= =B1=ED Huaimo Chen
=B7=A2= =CB=CD=CA=B1=BC=E4: 2016=C4=EA3=D4=C213=C8=D5 6:06
=CA=D5=BC=FE=C8=CB: idr@ietf.org
=B3=AD=CB=CD: Susan Hares
=D6=F7=CC=E2: Re: [Idr] WG Work item call - Opinions on work items (3/5/2016 to 3/17/20= 16) and adoption of draft-hares-idr-flowspec-combo-01.txt=

 

I read draft-hares-idr-flowspec-combo-01.txt and support it= . The work described in the draft is useful and well fit in BGP. Regarding = to option 1 and option 2, in the current stage, I support working on both. In the long run, I think option 2 is bet= ter.

 

Best Regards,

Huaimo

 

> On 05 Mar 2016, at 23:48, Susan Hares <shares@ndzh.com> wrote:

>

> The interim on 3/7/2016 will have a discussion of revi= sions to the BGP Flow specification (BGP-FS) to add more features.  Th= ere are two suggested options:

> 1)      A minimal features to= existing BGP-FS (option 1)

> Add a few new match filters to the BGP-FS NLRI and few= new actions to the BGP-FS actions (in Extended communities).  Actions= would need to be done in a defined order. Each new actions would need to define conflicts with existing actions. &nb= sp;

> 

> Best use case:  DoS attack prevention

> 

> 2)      Create a BGP-FS versi= on 2 (option 2)

> Create a new BGP-FS NLRI (v2) with a field that indica= tes the ordering of the BGP NLRI.  Add new BGP-FS actions with an orde= r field in the BGP Wide Communities.  Filters are done in the order defined in the filter.  Actions are done in the= order defined in the actions.   Order numbers that tie are handl= ed in a defined order.

> 

> Best use case: SDN/NFV filter management

> 

> A write-up on the issues and proposed solutions is con= tained in:

> draft-hares-idr-flowspec-combo-01.txt.  <htt= ps://datatracker.ietf.org/doc/draft-hares-idr-flowspec-combo/> =   The WG can select both option 1 and option 2.  This is a WG work item= call for input to the chairs on the scope of the WG item.  In you dis= cussion of this topics, the chairs would appreciate if you would indicate i= f you would support IDR working on option 1, option 2 or both option 1 and 2.  This WG call items also includes= a call for draft-hares-idr-flowspec-combo-01.txt as a write-up of the work= -item options.  The WG may wish to split this draft into multiple draf= ts.

> 

> The following drafts are being consider for either opt= ion:

> 1)      draft-eddy-idr-flowsp= ec-packet-rate

> 2)      draft-hao-idr-flowspe= c-nv03

> 3)      draft-hao-idr-flowspe= c-label

> 4)      draft-liang-idr-bgp-f= lowspec-time

> 5)      draft-litowski-idr-fl= owspec-interfaceset

> 6)      draft-vandevelde-idr-= flowspec-path-redirect

> 7)      draft-li-idr-flowspec= -rpd-01.txt

> 8)      draft-wu-idr-flowspec= -yang.cfg.

> 

> If you wish to comment on any of these drafts, we will

> 

> We will conclude the Call for WG opinions on 3/17/2016= so these authors can have a day to revise and submit their drafts before t= he draft deadline.

> 

> Sue Hares and John Scudder

> 

> PS:

> draft-li-idr-flowspec-rpd discusses limits on the dist= ribution of the policy which has been recast in draft-hares-idr-flowspec-co= mbo as a bgp-wide community of Container type 1 with an atom of BGP Flow Specification ordering. However,  thi= s draft is included in the list to be able to update the mechanism from thi= s draft into that context. 

> 

> The yang model for BGP Flow specification is also incl= uded in this work item as it will need to be modified based on the approach= es.  The yang model is in draft-wu-idr-flowspec-yang-cfg.  In your comments, please indicate if you feel these drafts or other drafts= . 

> 

> _______________________________________________

> Idr mailing list

> Idr@ietf.org <mailto:Idr@ietf.org>

> https://www.ietf.org/= mailman/listinfo/idr

--_000_19AB2A007F56DB4E8257F949A2FB9858AA1A2859NKGEML515MBXchi_-- From nobody Mon Mar 14 07:07:03 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7429012DA9F for ; Mon, 14 Mar 2016 07:07:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 T2kyAlrtdRad for ; Mon, 14 Mar 2016 07:06:58 -0700 (PDT) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::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 DE9BC12D626 for ; Mon, 14 Mar 2016 07:06:54 -0700 (PDT) Received: by mail-lb0-x22f.google.com with SMTP id bc4so240154078lbc.2 for ; Mon, 14 Mar 2016 07:06:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=mvXTIdpmfHsInTXZmfwAuU2bG6gab+Lo6hqZ/euw0tw=; b=MBcpFK36xuJatWicsBvH8u9AJgDqlKkHQVd3+nWmu8aVLr3jomr21qtidmV9WDychk IIfchiCE+DIozs91frNdAeOUPsrQB8ShRDlYKeDwsOeLiu/q/J33oGyo+TOGh7kfKFLG De3BgoogKtUeqYZkHG8xwpE7be1+yIPXBS4DJbkX9Nwa4hErLUWdE7rzvaqfydML8WLz EpjKnbjqZCk2lFPm4MZB5gz2RgWovY5Le8kZysOmDwL7zPMZQyXmHE6p7E+fo1t7fwGm XLXC1jaArAEofBcYTucV0LszN7EZzP9ysrFPNocFxkR6YBdEbTujb43TnFLtQqSPbDru 8wmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=mvXTIdpmfHsInTXZmfwAuU2bG6gab+Lo6hqZ/euw0tw=; b=J9a7HBY5qkOK/lAvLGArWKCI7mBcXCYmoy7L/l8Wj6y3kdg2ZaZel0v1AK4T3TrPS8 U+OpxOqygr1kJc7BEyhhLhbFFxPECc4jI3nPjmZkO4rZzNpANSIBoCrORT45fq1bKRmk aZAquXoPKiKibab62+/lah9twmInWaXlKeb5Y82NoEsaTvJ9pod67hsCxsxrrwxX34V8 m6qnrZkChqxFeZuajTU2ZsbTs1eWAPpKC+WPv+41DgDS4FIiuX/jQ/OQC/+53XbOu8o5 aKyA+XazaP6PvleIuzW6X+uDemGiIlHrCHcmAzJLkV+a1C9LFdwiaWiaiHe0javz+nPp uqTw== X-Gm-Message-State: AD7BkJJgbkBn0HSqcmQC+NQV8AEA8mRauqgLPjWlUBkprr6DsycMFU44eUL4yVw5N8KhRgDi8VhXJQ5Zfqv32A== MIME-Version: 1.0 X-Received: by 10.112.38.104 with SMTP id f8mr7825376lbk.115.1457964412976; Mon, 14 Mar 2016 07:06:52 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.25.136.133 with HTTP; Mon, 14 Mar 2016 07:06:52 -0700 (PDT) In-Reply-To: <82489e182ab34b74a29cea2f5e3866bf@XCH-ALN-014.cisco.com> References: <2d12cade49ac4ec19a7f2c80aee3b72d@XCH-ALN-014.cisco.com> <3F437107848A5140A6A19222EFFB3481200E2389@PRN-MBX01-2.TheFacebook.com> <976fb2df5f974b298a04b547afb917b7@XCH-ALN-014.cisco.com> <82489e182ab34b74a29cea2f5e3866bf@XCH-ALN-014.cisco.com> Date: Mon, 14 Mar 2016 10:06:52 -0400 X-Google-Sender-Auth: KfLtcPx02scUBFGY_QwiyAmmEJc Message-ID: From: Robert Raszuk To: "Jakob Heitz (jheitz)" Content-Type: multipart/alternative; boundary=001a11345cc4ee4e37052e02ca83 Archived-At: Cc: "idr@ietf.org" Subject: Re: [Idr] draft-lapukhov-bgp-opaque-signaling X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2016 14:07:01 -0000 --001a11345cc4ee4e37052e02ca83 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > Without a route target, any data sent will go everywhere and be stored in > every router. > > You probably don't want that. > > This new AFI should require a route target. That means an update message > without an RT must be dropped. > =E2=80=8BI do not think RTC is enough here. The fact that you can filter messages by receiver (or have receiver push those filters to upstream peers) does not in any way assures that receiver is authorized to receive such data which for generic distribution of any content seems like a bit of a fundamental problem to me. Besides to agree on inter-as RT schemas is an adventure on its own. Thx, r.=E2=80=8B > BGP treats all updates the same. > > Once the floodgates are open to generic data, you might want to invent a > precedence attribute. > > > > Thanks, > > Jakob. > > > > > > *From:* Idr [mailto:idr-bounces@ietf.org] *On Behalf Of *Jakob Heitz > (jheitz) > *Sent:* Saturday, March 12, 2016 1:12 PM > *To:* Petr Lapukhov ; idr@ietf.org > *Subject:* Re: [Idr] draft-lapukhov-bgp-opaque-signaling > > > > Without this problem solved, the proposal is not useful. > > Everybody using it must stick to the eventual solution to ensure > interoperability. > > Therefore, it should be inside the scope. > > > > Actually, BGP already has a way to distinguish applicationd: AFI and SAFI= . > > > > Jakob. > > > > *From:* Petr Lapukhov [mailto:petr@fb.com] > *Sent:* Saturday, March 12, 2016 1:06 PM > *To:* Jakob Heitz (jheitz) ; idr@ietf.org > *Subject:* RE: draft-lapukhov-bgp-opaque-signaling > > > > Hi Jakob, > > > > There is an ongoing discussion around avoiding NLRI (key) collisions. For > now, the plan is to externally generate unique key prefix per application= , > e.g. application name, or UUID or some other globally unique > string. Ensuring the uniqueness of those prefixes is outside the scope of > the proposal, though - it's more of a deployment consideration. > > > > Regards, > > > > Petr > > > ------------------------------ > > *From:* Idr [idr-bounces@ietf.org] on behalf of Jakob Heitz (jheitz) [ > jheitz@cisco.com] > *Sent:* Saturday, March 12, 2016 12:26 PM > *To:* idr@ietf.org > *Subject:* [Idr] [WARNING : A/V UNSCANNABLE] > draft-lapukhov-bgp-opaque-signaling > > I read > > http://www.ietf.org/id/draft-lapukhov-bgp-opaque-signaling-01.txt > > > > > Is this intended for any and multiple applications to use? > > If so, how do independent applications guarantee no duplication in NLRI? > > If not, what is the target application? > > > > Thanks > > Jakob. > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > --001a11345cc4ee4e37052e02ca83 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Without a route target, any data sen= t will go everywhere and be stored in every router.

You probably don't want that.=

This new AFI should require a route = target. That means an update message without an RT must be dropped.<= /p>



=E2=80=8BI do not think RTC is enough here.=C2=A0

The fact that you can filter messages= by receiver (or have receiver push those =C2=A0filters to upstream peers) = does not in any way assures that receiver is authorized to receive such dat= a which for generic distribution of any content seems like a bit of a funda= mental problem to me.=C2=A0

Besides to agree on inter-as RT schemas is an adventure on its own.= =C2=A0

Thx,
r.=E2=80=8B


=C2=A0

BGP treats all updates the same.=

Once the floodgates are open to gene= ric data, you might want to invent a precedence attribute.

=C2=A0

Thanks,

Jakob.

=C2=A0

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jakob Heitz (jheitz)
Sent: Saturday, March 12, 2016 1:12 PM
To: Petr Lapukhov <petr@fb.com>; i= dr@ietf.org
Subject: Re: [Idr] draft-lapukhov-bgp-opaque-signaling=

=C2=A0

Without this problem solved, the pro= posal is not useful.

Everybody using it must stick to the= eventual solution to ensure interoperability.

Therefore, it should be inside the s= cope.

=C2=A0

Actually, BGP already has a way to d= istinguish applicationd: AFI and SAFI.

=C2=A0

Jakob.

=C2=A0

From: Petr Lapukhov [mailto:petr@fb.com]
Sent: Saturday, March 12, 2016 1:06 PM
To: Jakob Heitz (jheitz) <jheitz@cisco.com>; idr@ietf.org
Subject: RE: draft-lapukhov-bgp-opaque-signaling

=C2=A0

Hi Jakob,

=C2=A0

There is an ongoing discussion around av= oiding NLRI (key) collisions. For now, the plan is to externally generate u= nique key prefix per application, e.g. application name, or UUID or some other globally unique string.=C2=A0Ensuring the uniq= ueness of those prefixes is outside the scope of the proposal, though - it&= #39;s more of a deployment consideration.

=C2=A0

Regards,

=C2=A0

Petr

=C2=A0

From:<= /span> Idr [idr-bounces@ietf.org] on behalf of Jakob Heitz (jheitz) [jheitz@cisco.com]
Sent: Saturday, March 12, 2016 12:26 PM
To: idr@ietf.org
Subject: [Idr] [WARNING : A/V UNSCANNABLE] draft-lapukhov-bgp-opaque= -signaling

I read<= u>

= http://www.ietf.org/id/draft-lapukhov-bgp-opaque-signaling-01.txt

=C2=A0

Is this intended for any and multipl= e applications to use?

If so, how do independent applicatio= ns guarantee no duplication in NLRI?<= /u>

If not, what is the target applicati= on?

=C2=A0

Thanks

Jakob.


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


--001a11345cc4ee4e37052e02ca83-- From nobody Mon Mar 14 08:08:03 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD0412DC66 for ; Mon, 14 Mar 2016 08:08:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 z2TdNJDwkpW4 for ; Mon, 14 Mar 2016 08:07:56 -0700 (PDT) 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 8CECF12D513 for ; Mon, 14 Mar 2016 07:59:07 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CFZ62408; Mon, 14 Mar 2016 14:59:05 +0000 (GMT) Received: from DFWEML703-CHM.china.huawei.com (10.193.5.130) by lhreml706-cah.china.huawei.com (10.201.5.182) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 14 Mar 2016 14:59:04 +0000 Received: from DFWEML501-MBS.china.huawei.com ([10.193.5.222]) by dfweml703-chm ([10.193.5.130]) with mapi id 14.03.0235.001; Mon, 14 Mar 2016 07:59:01 -0700 From: Linda Dunbar To: "idr@ietf.org" Thread-Topic: [Idr] WG Work item call - Opinions on work items (3/5/2016 to 3/17/2016) and adoption of draft-hares-idr-flowspec-combo-01.txt Thread-Index: AQHRfKtnYYXsP5nLFk+gqsP9WQBu6p9ZVAIA//+2bkA= Date: Mon, 14 Mar 2016 14:59:00 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657E33505@dfweml501-mbs> References: <2d12cade49ac4ec19a7f2c80aee3b72d@XCH-ALN-014.cisco.com> <3F437107848A5140A6A19222EFFB3481200E2389@PRN-MBX01-2.TheFacebook.com> <976fb2df5f974b298a04b547afb917b7@XCH-ALN-014.cisco.com> <5316A0AB3C851246A7CA5758973207D44E4EFB05@SJCEML702-CHM.china.huawei.com> <19AB2A007F56DB4E8257F949A2FB9858AA1A2859@NKGEML515-MBX.china.huawei.com> In-Reply-To: <19AB2A007F56DB4E8257F949A2FB9858AA1A2859@NKGEML515-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.112] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657E33505dfweml501mbs_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.56E6D1BA.002E, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: e4edb7c6df8844fa6b7b5cf07d23fbf1 Archived-At: Cc: Susan Hares Subject: Re: [Idr] WG Work item call - Opinions on work items (3/5/2016 to 3/17/2016) and adoption of draft-hares-idr-flowspec-combo-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2016 15:08:00 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F657E33505dfweml501mbs_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 U3VwcG9ydC4NCg0KTGluZGEgRHVuYmFyDQoNCreivP7IyzogSWRyIFttYWlsdG86aWRyLWJvdW5j ZXNAaWV0Zi5vcmddILT6se0gSHVhaW1vIENoZW4NCreiy83KsbzkOiAyMDE2xOoz1MIxM8jVIDY6 MDYNCsrVvP7IyzogaWRyQGlldGYub3JnPG1haWx0bzppZHJAaWV0Zi5vcmc+DQqzrcvNOiBTdXNh biBIYXJlcw0K1vfM4jogUmU6IFtJZHJdIFdHIFdvcmsgaXRlbSBjYWxsIC0gT3BpbmlvbnMgb24g d29yayBpdGVtcyAoMy81LzIwMTYgdG8gMy8xNy8yMDE2KSBhbmQgYWRvcHRpb24gb2YgZHJhZnQt aGFyZXMtaWRyLWZsb3dzcGVjLWNvbWJvLTAxLnR4dA0KDQpJIHJlYWQgZHJhZnQtaGFyZXMtaWRy LWZsb3dzcGVjLWNvbWJvLTAxLnR4dCBhbmQgc3VwcG9ydCBpdC4gVGhlIHdvcmsgZGVzY3JpYmVk IGluIHRoZSBkcmFmdCBpcyB1c2VmdWwgYW5kIHdlbGwgZml0IGluIEJHUC4gUmVnYXJkaW5nIHRv IG9wdGlvbiAxIGFuZCBvcHRpb24gMiwgaW4gdGhlIGN1cnJlbnQgc3RhZ2UsIEkgc3VwcG9ydCB3 b3JraW5nIG9uIGJvdGguIEluIHRoZSBsb25nIHJ1biwgSSB0aGluayBvcHRpb24gMiBpcyBiZXR0 ZXIuDQoNCkJlc3QgUmVnYXJkcywNCkh1YWltbw0KDQo+IE9uIDA1IE1hciAyMDE2LCBhdCAyMzo0 OCwgU3VzYW4gSGFyZXMgPHNoYXJlc0BuZHpoLmNvbTxtYWlsdG86c2hhcmVzQG5kemguY29tPj4g d3JvdGU6DQo+DQo+IFRoZSBpbnRlcmltIG9uIDMvNy8yMDE2IHdpbGwgaGF2ZSBhIGRpc2N1c3Np b24gb2YgcmV2aXNpb25zIHRvIHRoZSBCR1AgRmxvdyBzcGVjaWZpY2F0aW9uIChCR1AtRlMpIHRv IGFkZCBtb3JlIGZlYXR1cmVzLiAgVGhlcmUgYXJlIHR3byBzdWdnZXN0ZWQgb3B0aW9uczoNCj4g MSkgICAgICBBIG1pbmltYWwgZmVhdHVyZXMgdG8gZXhpc3RpbmcgQkdQLUZTIChvcHRpb24gMSkN Cj4gQWRkIGEgZmV3IG5ldyBtYXRjaCBmaWx0ZXJzIHRvIHRoZSBCR1AtRlMgTkxSSSBhbmQgZmV3 IG5ldyBhY3Rpb25zIHRvIHRoZSBCR1AtRlMgYWN0aW9ucyAoaW4gRXh0ZW5kZWQgY29tbXVuaXRp ZXMpLiAgQWN0aW9ucyB3b3VsZCBuZWVkIHRvIGJlIGRvbmUgaW4gYSBkZWZpbmVkIG9yZGVyLiBF YWNoIG5ldyBhY3Rpb25zIHdvdWxkIG5lZWQgdG8gZGVmaW5lIGNvbmZsaWN0cyB3aXRoIGV4aXN0 aW5nIGFjdGlvbnMuDQo+DQo+IEJlc3QgdXNlIGNhc2U6ICBEb1MgYXR0YWNrIHByZXZlbnRpb24N Cj4NCj4gMikgICAgICBDcmVhdGUgYSBCR1AtRlMgdmVyc2lvbiAyIChvcHRpb24gMikNCj4gQ3Jl YXRlIGEgbmV3IEJHUC1GUyBOTFJJICh2Mikgd2l0aCBhIGZpZWxkIHRoYXQgaW5kaWNhdGVzIHRo ZSBvcmRlcmluZyBvZiB0aGUgQkdQIE5MUkkuICBBZGQgbmV3IEJHUC1GUyBhY3Rpb25zIHdpdGgg YW4gb3JkZXIgZmllbGQgaW4gdGhlIEJHUCBXaWRlIENvbW11bml0aWVzLiAgRmlsdGVycyBhcmUg ZG9uZSBpbiB0aGUgb3JkZXIgZGVmaW5lZCBpbiB0aGUgZmlsdGVyLiAgQWN0aW9ucyBhcmUgZG9u ZSBpbiB0aGUgb3JkZXIgZGVmaW5lZCBpbiB0aGUgYWN0aW9ucy4gICBPcmRlciBudW1iZXJzIHRo YXQgdGllIGFyZSBoYW5kbGVkIGluIGEgZGVmaW5lZCBvcmRlci4NCj4NCj4gQmVzdCB1c2UgY2Fz ZTogU0ROL05GViBmaWx0ZXIgbWFuYWdlbWVudA0KPg0KPiBBIHdyaXRlLXVwIG9uIHRoZSBpc3N1 ZXMgYW5kIHByb3Bvc2VkIHNvbHV0aW9ucyBpcyBjb250YWluZWQgaW46DQo+IGRyYWZ0LWhhcmVz LWlkci1mbG93c3BlYy1jb21iby0wMS50eHQuICA8aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtaGFyZXMtaWRyLWZsb3dzcGVjLWNvbWJvLz4gICBUaGUgV0cgY2FuIHNlbGVj dCBib3RoIG9wdGlvbiAxIGFuZCBvcHRpb24gMi4gIFRoaXMgaXMgYSBXRyB3b3JrIGl0ZW0gY2Fs bCBmb3IgaW5wdXQgdG8gdGhlIGNoYWlycyBvbiB0aGUgc2NvcGUgb2YgdGhlIFdHIGl0ZW0uICBJ biB5b3UgZGlzY3Vzc2lvbiBvZiB0aGlzIHRvcGljcywgdGhlIGNoYWlycyB3b3VsZCBhcHByZWNp YXRlIGlmIHlvdSB3b3VsZCBpbmRpY2F0ZSBpZiB5b3Ugd291bGQgc3VwcG9ydCBJRFIgd29ya2lu ZyBvbiBvcHRpb24gMSwgb3B0aW9uIDIgb3IgYm90aCBvcHRpb24gMSBhbmQgMi4gIFRoaXMgV0cg Y2FsbCBpdGVtcyBhbHNvIGluY2x1ZGVzIGEgY2FsbCBmb3IgZHJhZnQtaGFyZXMtaWRyLWZsb3dz cGVjLWNvbWJvLTAxLnR4dCBhcyBhIHdyaXRlLXVwIG9mIHRoZSB3b3JrLWl0ZW0gb3B0aW9ucy4g IFRoZSBXRyBtYXkgd2lzaCB0byBzcGxpdCB0aGlzIGRyYWZ0IGludG8gbXVsdGlwbGUgZHJhZnRz Lg0KPg0KPiBUaGUgZm9sbG93aW5nIGRyYWZ0cyBhcmUgYmVpbmcgY29uc2lkZXIgZm9yIGVpdGhl ciBvcHRpb246DQo+IDEpICAgICAgZHJhZnQtZWRkeS1pZHItZmxvd3NwZWMtcGFja2V0LXJhdGUN Cj4gMikgICAgICBkcmFmdC1oYW8taWRyLWZsb3dzcGVjLW52MDMNCj4gMykgICAgICBkcmFmdC1o YW8taWRyLWZsb3dzcGVjLWxhYmVsDQo+IDQpICAgICAgZHJhZnQtbGlhbmctaWRyLWJncC1mbG93 c3BlYy10aW1lDQo+IDUpICAgICAgZHJhZnQtbGl0b3dza2ktaWRyLWZsb3dzcGVjLWludGVyZmFj ZXNldA0KPiA2KSAgICAgIGRyYWZ0LXZhbmRldmVsZGUtaWRyLWZsb3dzcGVjLXBhdGgtcmVkaXJl Y3QNCj4gNykgICAgICBkcmFmdC1saS1pZHItZmxvd3NwZWMtcnBkLTAxLnR4dA0KPiA4KSAgICAg IGRyYWZ0LXd1LWlkci1mbG93c3BlYy15YW5nLmNmZy4NCj4NCj4gSWYgeW91IHdpc2ggdG8gY29t bWVudCBvbiBhbnkgb2YgdGhlc2UgZHJhZnRzLCB3ZSB3aWxsDQo+DQo+IFdlIHdpbGwgY29uY2x1 ZGUgdGhlIENhbGwgZm9yIFdHIG9waW5pb25zIG9uIDMvMTcvMjAxNiBzbyB0aGVzZSBhdXRob3Jz IGNhbiBoYXZlIGEgZGF5IHRvIHJldmlzZSBhbmQgc3VibWl0IHRoZWlyIGRyYWZ0cyBiZWZvcmUg dGhlIGRyYWZ0IGRlYWRsaW5lLg0KPg0KPiBTdWUgSGFyZXMgYW5kIEpvaG4gU2N1ZGRlcg0KPg0K PiBQUzoNCj4gZHJhZnQtbGktaWRyLWZsb3dzcGVjLXJwZCBkaXNjdXNzZXMgbGltaXRzIG9uIHRo ZSBkaXN0cmlidXRpb24gb2YgdGhlIHBvbGljeSB3aGljaCBoYXMgYmVlbiByZWNhc3QgaW4gZHJh ZnQtaGFyZXMtaWRyLWZsb3dzcGVjLWNvbWJvIGFzIGEgYmdwLXdpZGUgY29tbXVuaXR5IG9mIENv bnRhaW5lciB0eXBlIDEgd2l0aCBhbiBhdG9tIG9mIEJHUCBGbG93IFNwZWNpZmljYXRpb24gb3Jk ZXJpbmcuIEhvd2V2ZXIsICB0aGlzIGRyYWZ0IGlzIGluY2x1ZGVkIGluIHRoZSBsaXN0IHRvIGJl IGFibGUgdG8gdXBkYXRlIHRoZSBtZWNoYW5pc20gZnJvbSB0aGlzIGRyYWZ0IGludG8gdGhhdCBj b250ZXh0Lg0KPg0KPiBUaGUgeWFuZyBtb2RlbCBmb3IgQkdQIEZsb3cgc3BlY2lmaWNhdGlvbiBp cyBhbHNvIGluY2x1ZGVkIGluIHRoaXMgd29yayBpdGVtIGFzIGl0IHdpbGwgbmVlZCB0byBiZSBt b2RpZmllZCBiYXNlZCBvbiB0aGUgYXBwcm9hY2hlcy4gIFRoZSB5YW5nIG1vZGVsIGlzIGluIGRy YWZ0LXd1LWlkci1mbG93c3BlYy15YW5nLWNmZy4gIEluIHlvdXIgY29tbWVudHMsIHBsZWFzZSBp bmRpY2F0ZSBpZiB5b3UgZmVlbCB0aGVzZSBkcmFmdHMgb3Igb3RoZXIgZHJhZnRzLg0KPg0KPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBJZHIgbWFp bGluZyBsaXN0DQo+IElkckBpZXRmLm9yZzxtYWlsdG86SWRyQGlldGYub3JnPiA8bWFpbHRvOklk ckBpZXRmLm9yZz4NCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZHIN Cg== --_000_4A95BA014132FF49AE685FAB4B9F17F657E33505dfweml501mbs_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Support.

 

Linda Dunbar

=  

=B7=A2=BC=FE=C8=CB: Idr [mailto:idr-bo= unces@ietf.org] =B4=FA=B1=ED Huaimo Chen<= br> =B7=A2=CB=CD=CA=B1=BC=E4: 2016=C4=EA= 3= =D4=C213<= span lang=3D"ZH-CN" style=3D"font-size:10.0pt;font-family:SimSun">=C8=D5 6:06
=CA=D5=BC=FE=C8=CB: idr@ietf.org
=B3=AD=CB=CD: Susan= Hares
=D6=F7=CC=E2: Re: [= Idr] WG Work item call - Opinions on work items (3/5/2016 to 3/17/2016) and adoption of draft-hares-idr-flowspec-combo-01.txt

 

I read draft-hares-idr-flowspec-combo-01.txt and support it. The work desc= ribed in the draft is useful and well fit in BGP. Regarding to option 1 and= option 2, in the current stage, I support working on both. In the long run, I think option 2 is better.

 

Best Regards,

Huaimo

 

> On 05 Mar 2016, at 23:48, Susan Hares <shares@ndzh.com> wrote:

>

> The interim on 3/7/2016 will have a discussion of revisions to the BG= P Flow specification (BGP-FS) to add more features.  There are two sug= gested options:

> 1)      A minimal features to existing BGP-F= S (option 1)

> Add a few new match filters to the BGP-FS NLRI and few new actions to= the BGP-FS actions (in Extended communities).  Actions would need to = be done in a defined order. Each new actions would need to define conflicts with existing actions.  

> 

> Best use case:  DoS attack prevention

> 

> 2)      Create a BGP-FS version 2 (option 2)

> Create a new BGP-FS NLRI (v2) with a field that indicates the orderin= g of the BGP NLRI.  Add new BGP-FS actions with an order field in the = BGP Wide Communities.  Filters are done in the order defined in the filter.  Actions are done in the order defined i= n the actions.   Order numbers that tie are handled in a defined = order.

> 

> Best use case: SDN/NFV filter management

> 

> A write-up on the issues and proposed solutions is contained in:

> draft-hares-idr-flowspec-combo-01.txt.  <https://datatracke= r.ietf.org/doc/draft-hares-idr-flowspec-combo/>   The WG can select both option 1 and option 2.  This is a WG work item= call for input to the chairs on the scope of the WG item.  In you dis= cussion of this topics, the chairs would appreciate if you would indicate i= f you would support IDR working on option 1, option 2 or both option 1 and 2.  This WG call items also includes= a call for draft-hares-idr-flowspec-combo-01.txt as a write-up of the work= -item options.  The WG may wish to split this draft into multiple draf= ts.

> 

> The following drafts are being consider for either option:

> 1)      draft-eddy-idr-flowspec-packet-rate<= o:p>

> 2)      draft-hao-idr-flowspec-nv03

> 3)      draft-hao-idr-flowspec-label

> 4)      draft-liang-idr-bgp-flowspec-time

> 5)      draft-litowski-idr-flowspec-interfac= eset

> 6)      draft-vandevelde-idr-flowspec-path-r= edirect

> 7)      draft-li-idr-flowspec-rpd-01.txt

> 8)      draft-wu-idr-flowspec-yang.cfg.

> 

> If you wish to comment on any of these drafts, we will

> 

> We will conclude the Call for WG opinions on 3/17/2016 so these autho= rs can have a day to revise and submit their drafts before the draft deadli= ne.

> 

> Sue Hares and John Scudder

> 

> PS:

> draft-li-idr-flowspec-rpd discusses limits on the distribution of the= policy which has been recast in draft-hares-idr-flowspec-combo as a bgp-wi= de community of Container type 1 with an atom of BGP Flow Specification ordering. However,  this draft is incl= uded in the list to be able to update the mechanism from this draft into th= at context. 

> 

> The yang model for BGP Flow specification is also included in this wo= rk item as it will need to be modified based on the approaches.  The y= ang model is in draft-wu-idr-flowspec-yang-cfg.  In your comments, please indicate if you feel these drafts or other drafts= . 

> 

> _______________________________________________

> Idr mailing list

> Idr@ietf.org <mailto:Idr@ietf.org>

> https://www.ietf.org/mailman/listinfo/idr

--_000_4A95BA014132FF49AE685FAB4B9F17F657E33505dfweml501mbs_-- From nobody Mon Mar 14 08:51:00 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3AE012DC46 for ; Mon, 14 Mar 2016 08:50:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 sclQKwprDKFq for ; Mon, 14 Mar 2016 08:50:50 -0700 (PDT) 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 4319812DCC0 for ; Mon, 14 Mar 2016 08:46:16 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CFZ67670; Mon, 14 Mar 2016 15:46:13 +0000 (GMT) Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 14 Mar 2016 15:46:12 +0000 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0235.001; Mon, 14 Mar 2016 23:46:05 +0800 From: "Dongjie (Jimmy)" To: Susan Hares , "idr@ietf.org" Thread-Topic: [Idr] WG Work item call - Opinions on work items (3/5/2016 to 3/17/2016) and adoption of draft-hares-idr-flowspec-combo-01.txt Thread-Index: AdF3MOvE/JSvgLOkQ3a9MB8GleM7AQG1d2Ag Date: Mon, 14 Mar 2016 15:46:04 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C92774E3EF6C@NKGEML515-MBX.china.huawei.com> References: <000b01d17731$29d17230$7d745690$@ndzh.com> In-Reply-To: <000b01d17731$29d17230$7d745690$@ndzh.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.42.117] Content-Type: multipart/alternative; boundary="_000_76CD132C3ADEF848BD84D028D243C92774E3EF6CNKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.56E6DCC6.01C9, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 6eb7aa2b2a1d00889ae7baafd8839466 Archived-At: Subject: [Idr] =?gb2312?b?tPC4tDogIFdHIFdvcmsgaXRlbSBjYWxsIC0gT3BpbmlvbnMg?= =?gb2312?b?b24gd29yayBpdGVtcyAoMy81LzIwMTYgdG8gMy8xNy8yMDE2KSBhbmQgYWRv?= =?gb2312?b?cHRpb24gb2YgZHJhZnQtaGFyZXMtaWRyLWZsb3dzcGVjLWNvbWJvLTAxLnR4?= =?gb2312?b?dA==?= X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2016 15:50:58 -0000 --_000_76CD132C3ADEF848BD84D028D243C92774E3EF6CNKGEML515MBXchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksDQoNCklNTyBpbiBzaG9ydCB0ZXJtIHdlIG5lZWQgdG8gd29yayBvbiBvcHRpb24xLCBpbiB3 aGljaCBvcmRlcmluZyBhbmQgY29tYmluYXRpb24gcnVsZXMgbmVlZCB0byBiZSBzcGVjaWZpZWQu DQoNCkFzIGZvciBvcHRpb24gMiwgd2UgbWF5IG5lZWQgdG8gdGFrZSB0aGUgY2hhcmFjdGVyaXN0 aWNzIG9mIEJHUCBpbnRvIGNvbnNpZGVyYXRpb24gYW5kIGlkZW50aWZ5IHRoZSBhcHByb3ByaWF0 ZSB1c2UgY2FzZXMgZm9yIEJHUC1GUywgdGhlbiBtYWtlIHRoZSBwcm90b2NvbCBleHRlbnNpb24g YWNjb3JkaW5nbHkuDQoNCkJlc3QgcmVnYXJkcywNCkppZQ0KDQq3orz+yMs6IElkciBbbWFpbHRv Omlkci1ib3VuY2VzQGlldGYub3JnXSC0+rHtIFN1c2FuIEhhcmVzDQq3osvNyrG85DogMjAxNsTq M9TCNsjVIDY6NDkNCsrVvP7IyzogaWRyQGlldGYub3JnDQrW98ziOiBbSWRyXSBXRyBXb3JrIGl0 ZW0gY2FsbCAtIE9waW5pb25zIG9uIHdvcmsgaXRlbXMgKDMvNS8yMDE2IHRvIDMvMTcvMjAxNikg YW5kIGFkb3B0aW9uIG9mIGRyYWZ0LWhhcmVzLWlkci1mbG93c3BlYy1jb21iby0wMS50eHQNCg0K VGhlIGludGVyaW0gb24gMy83LzIwMTYgd2lsbCBoYXZlIGEgZGlzY3Vzc2lvbiBvZiByZXZpc2lv bnMgdG8gdGhlIEJHUCBGbG93IHNwZWNpZmljYXRpb24gKEJHUC1GUykgdG8gYWRkIG1vcmUgZmVh dHVyZXMuICBUaGVyZSBhcmUgdHdvIHN1Z2dlc3RlZCBvcHRpb25zOg0KDQoNCjEpICAgICAgQSBt aW5pbWFsIGZlYXR1cmVzIHRvIGV4aXN0aW5nIEJHUC1GUyAob3B0aW9uIDEpDQoNCkFkZCBhIGZl dyBuZXcgbWF0Y2ggZmlsdGVycyB0byB0aGUgQkdQLUZTIE5MUkkgYW5kIGZldyBuZXcgYWN0aW9u cyB0byB0aGUgQkdQLUZTIGFjdGlvbnMgKGluIEV4dGVuZGVkIGNvbW11bml0aWVzKS4gIEFjdGlv bnMgd291bGQgbmVlZCB0byBiZSBkb25lIGluIGEgZGVmaW5lZCBvcmRlci4gRWFjaCBuZXcgYWN0 aW9ucyB3b3VsZCBuZWVkIHRvIGRlZmluZSBjb25mbGljdHMgd2l0aCBleGlzdGluZyBhY3Rpb25z Lg0KDQoNCg0KQmVzdCB1c2UgY2FzZTogIERvUyBhdHRhY2sgcHJldmVudGlvbg0KDQoNCg0KMikg ICAgICBDcmVhdGUgYSBCR1AtRlMgdmVyc2lvbiAyIChvcHRpb24gMikNCg0KQ3JlYXRlIGEgbmV3 IEJHUC1GUyBOTFJJICh2Mikgd2l0aCBhIGZpZWxkIHRoYXQgaW5kaWNhdGVzIHRoZSBvcmRlcmlu ZyBvZiB0aGUgQkdQIE5MUkkuICBBZGQgbmV3IEJHUC1GUyBhY3Rpb25zIHdpdGggYW4gb3JkZXIg ZmllbGQgaW4gdGhlIEJHUCBXaWRlIENvbW11bml0aWVzLiAgRmlsdGVycyBhcmUgZG9uZSBpbiB0 aGUgb3JkZXIgZGVmaW5lZCBpbiB0aGUgZmlsdGVyLiAgQWN0aW9ucyBhcmUgZG9uZSBpbiB0aGUg b3JkZXIgZGVmaW5lZCBpbiB0aGUgYWN0aW9ucy4gICBPcmRlciBudW1iZXJzIHRoYXQgdGllIGFy ZSBoYW5kbGVkIGluIGEgZGVmaW5lZCBvcmRlci4NCg0KDQoNCkJlc3QgdXNlIGNhc2U6IFNETi9O RlYgZmlsdGVyIG1hbmFnZW1lbnQNCg0KQSB3cml0ZS11cCBvbiB0aGUgaXNzdWVzIGFuZCBwcm9w b3NlZCBzb2x1dGlvbnMgaXMgY29udGFpbmVkIGluOg0KZHJhZnQtaGFyZXMtaWRyLWZsb3dzcGVj LWNvbWJvLTAxLnR4dC4gPGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWhh cmVzLWlkci1mbG93c3BlYy1jb21iby8+ICAgIFRoZSBXRyBjYW4gc2VsZWN0IGJvdGggb3B0aW9u IDEgYW5kIG9wdGlvbiAyLiAgVGhpcyBpcyBhIFdHIHdvcmsgaXRlbSBjYWxsIGZvciBpbnB1dCB0 byB0aGUgY2hhaXJzIG9uIHRoZSBzY29wZSBvZiB0aGUgV0cgaXRlbS4gIEluIHlvdSBkaXNjdXNz aW9uIG9mIHRoaXMgdG9waWNzLCB0aGUgY2hhaXJzIHdvdWxkIGFwcHJlY2lhdGUgaWYgeW91IHdv dWxkIGluZGljYXRlIGlmIHlvdSB3b3VsZCBzdXBwb3J0IElEUiB3b3JraW5nIG9uIG9wdGlvbiAx LCBvcHRpb24gMiBvciBib3RoIG9wdGlvbiAxIGFuZCAyLiAgVGhpcyBXRyBjYWxsIGl0ZW1zIGFs c28gaW5jbHVkZXMgYSBjYWxsIGZvciBkcmFmdC1oYXJlcy1pZHItZmxvd3NwZWMtY29tYm8tMDEu dHh0IGFzIGEgd3JpdGUtdXAgb2YgdGhlIHdvcmstaXRlbSBvcHRpb25zLiAgVGhlIFdHIG1heSB3 aXNoIHRvIHNwbGl0IHRoaXMgZHJhZnQgaW50byBtdWx0aXBsZSBkcmFmdHMuDQoNClRoZSBmb2xs b3dpbmcgZHJhZnRzIGFyZSBiZWluZyBjb25zaWRlciBmb3IgZWl0aGVyIG9wdGlvbjoNCg0KMSkg ICAgICBkcmFmdC1lZGR5LWlkci1mbG93c3BlYy1wYWNrZXQtcmF0ZQ0KDQoyKSAgICAgIGRyYWZ0 LWhhby1pZHItZmxvd3NwZWMtbnYwMw0KDQozKSAgICAgIGRyYWZ0LWhhby1pZHItZmxvd3NwZWMt bGFiZWwNCg0KNCkgICAgICBkcmFmdC1saWFuZy1pZHItYmdwLWZsb3dzcGVjLXRpbWUNCg0KNSkg ICAgICBkcmFmdC1saXRvd3NraS1pZHItZmxvd3NwZWMtaW50ZXJmYWNlc2V0DQoNCjYpICAgICAg ZHJhZnQtdmFuZGV2ZWxkZS1pZHItZmxvd3NwZWMtcGF0aC1yZWRpcmVjdA0KDQo3KSAgICAgIGRy YWZ0LWxpLWlkci1mbG93c3BlYy1ycGQtMDEudHh0DQoNCjgpICAgICAgZHJhZnQtd3UtaWRyLWZs b3dzcGVjLXlhbmcuY2ZnLg0KDQpJZiB5b3Ugd2lzaCB0byBjb21tZW50IG9uIGFueSBvZiB0aGVz ZSBkcmFmdHMsIHdlIHdpbGwNCg0KV2Ugd2lsbCBjb25jbHVkZSB0aGUgQ2FsbCBmb3IgV0cgb3Bp bmlvbnMgb24gMy8xNy8yMDE2IHNvIHRoZXNlIGF1dGhvcnMgY2FuIGhhdmUgYSBkYXkgdG8gcmV2 aXNlIGFuZCBzdWJtaXQgdGhlaXIgZHJhZnRzIGJlZm9yZSB0aGUgZHJhZnQgZGVhZGxpbmUuDQoN ClN1ZSBIYXJlcyBhbmQgSm9obiBTY3VkZGVyDQoNClBTOg0KZHJhZnQtbGktaWRyLWZsb3dzcGVj LXJwZCBkaXNjdXNzZXMgbGltaXRzIG9uIHRoZSBkaXN0cmlidXRpb24gb2YgdGhlIHBvbGljeSB3 aGljaCBoYXMgYmVlbiByZWNhc3QgaW4gZHJhZnQtaGFyZXMtaWRyLWZsb3dzcGVjLWNvbWJvIGFz IGEgYmdwLXdpZGUgY29tbXVuaXR5IG9mIENvbnRhaW5lciB0eXBlIDEgd2l0aCBhbiBhdG9tIG9m IEJHUCBGbG93IFNwZWNpZmljYXRpb24gb3JkZXJpbmcuIEhvd2V2ZXIsICB0aGlzIGRyYWZ0IGlz IGluY2x1ZGVkIGluIHRoZSBsaXN0IHRvIGJlIGFibGUgdG8gdXBkYXRlIHRoZSBtZWNoYW5pc20g ZnJvbSB0aGlzIGRyYWZ0IGludG8gdGhhdCBjb250ZXh0Lg0KDQpUaGUgeWFuZyBtb2RlbCBmb3Ig QkdQIEZsb3cgc3BlY2lmaWNhdGlvbiBpcyBhbHNvIGluY2x1ZGVkIGluIHRoaXMgd29yayBpdGVt IGFzIGl0IHdpbGwgbmVlZCB0byBiZSBtb2RpZmllZCBiYXNlZCBvbiB0aGUgYXBwcm9hY2hlcy4g IFRoZSB5YW5nIG1vZGVsIGlzIGluIGRyYWZ0LXd1LWlkci1mbG93c3BlYy15YW5nLWNmZy4gIElu IHlvdXIgY29tbWVudHMsIHBsZWFzZSBpbmRpY2F0ZSBpZiB5b3UgZmVlbCB0aGVzZSBkcmFmdHMg b3Igb3RoZXIgZHJhZnRzLg0KDQo= --_000_76CD132C3ADEF848BD84D028D243C92774E3EF6CNKGEML515MBXchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi,

 

IMO in short term we need to work on option1, in which ordering a= nd combination rules need to be specified.

 

As for option 2, we may need to take the characteristics of BGP i= nto consideration and identify the appropriate use cases for BGP-FS, then m= ake the protocol extension accordingly.

 

Best regards,

Jie

 

=B7=A2=BC=FE=C8=CB: Idr [ma= ilto:idr-bounces@ietf.org] =B4=FA= =B1=ED Susan Hares
=B7=A2= =CB=CD=CA=B1=BC=E4: 2016=C4=EA3=D4=C26=C8=D5 6:49
=CA=D5=BC=FE=C8=CB: idr@ietf.org
=D6=F7=CC=E2: [Idr] WG Work item call - Opinions on work items (3/5/2016 to 3/17/2016) = and adoption of draft-hares-idr-flowspec-combo-01.txt

 

The interim on 3/7/2016 will ha= ve a discussion of revisions to the BGP Flow specification (BGP-FS) to add = more features.  There are two suggested options:

 

1) &nbs= p;    A minimal features to e= xisting BGP-FS (option 1)

Add a few new match filt= ers to the BGP-FS NLRI and few new actions to the BGP-FS actions (in Extend= ed communities).  Actions would need to be done in a defined order. Ea= ch new actions would need to define conflicts with existing actions.   

 =

Best use case:  DoS= attack prevention

 =

2) &nbs= p;    Create a BGP-FS version= 2 (option 2)

Create a new BGP-FS NLRI= (v2) with a field that indicates the ordering of the BGP NLRI.  Add n= ew BGP-FS actions with an order field in the BGP Wide Communities.  Fi= lters are done in the order defined in the filter.  Actions are done in the order defined in the actions.   Order nu= mbers that tie are handled in a defined order.

 =

Best use case: SDN/NFV f= ilter management

 

A write-up on the issues and pr= oposed solutions is contained in:

draft-hares-idr-flowspec-comb= o-01.txt.    The WG can select both option 1 and option 2.  T= his is a WG work item call for input to the chairs on the scope of the WG i= tem.  In you discussion of this topics, the chairs would appreciate if= you would indicate if you would support IDR working on option 1, option 2 or both option 1 and 2.  This WG call items also includes= a call for draft-hares-idr-flowspec-combo-01.txt as a write-up of the work= -item options.  The WG may wish to split this draft into multiple draf= ts.

 

The following drafts are being = consider for either option:

1) &nbs= p;    draft-eddy-idr-flowspec= -packet-rate

2) &nbs= p;    draft-hao-idr-flowspec-= nv03

3) &nbs= p;    draft-hao-idr-flowspec-= label

4) &nbs= p;    draft-liang-idr-bgp-flo= wspec-time

5) &nbs= p;    draft-litowski-idr-flow= spec-interfaceset

6) &nbs= p;    draft-vandevelde-idr-fl= owspec-path-redirect

7) &nbs= p;    draft-li-idr-flowspec-r= pd-01.txt

8) &nbs= p;    draft-wu-idr-flowspec-y= ang.cfg.

 

If you wish to comment on any o= f these drafts, we will

 

We will conclude the Call for W= G opinions on 3/17/2016 so these authors can have a day to revise and submi= t their drafts before the draft deadline.

 

Sue Hares and John Scudder

 

PS:

draft-li-idr-flowspec-rpd discu= sses limits on the distribution of the policy which has been recast in draf= t-hares-idr-flowspec-combo as a bgp-wide community of Container type 1 with= an atom of BGP Flow Specification ordering. However,  this draft is included in the list to be able to update the= mechanism from this draft into that context.  

 

The yang model for BGP Flow spe= cification is also included in this work item as it will need to be modifie= d based on the approaches.  The yang model is in draft-wu-idr-flowspec= -yang-cfg.  In your comments, please indicate if you feel these drafts or other drafts. 

 

--_000_76CD132C3ADEF848BD84D028D243C92774E3EF6CNKGEML515MBXchi_-- From nobody Mon Mar 14 10:54:58 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB32112D67E; Mon, 14 Mar 2016 10:54:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 74s43K0CD16r; Mon, 14 Mar 2016 10:54:54 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F3D212D5D4; Mon, 14 Mar 2016 10:54:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11872; q=dns/txt; s=iport; t=1457978094; x=1459187694; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=eSg7lZh7HlXsgs0dUYpejBVo6goPuEHheivRutZpxYI=; b=d+ZnxuQ6O3qH7YxZj4egS63so/K6MTtYviZWTSIeH+kHkdv7LAhH+pSX 8c0/8nzQOozb/r97yfb0l3EWpQistgoo3X9C4rWS0TWDJfNWxE0fZ+q+g /6pz6yL3j6hK2PnsUOoR2FoClv2KOcXhN9Gufb3sOzPExMmOCz4AV4fJh U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A3AgBN+uZW/4gNJK1XBoJ6TFJtBrowA?= =?us-ascii?q?Q2BcCOFagKBMDgUAQEBAQEBAWQnhEEBAQEELUwQAgEIEQMBAQEoBzIUCQgCBAE?= =?us-ascii?q?NBYgPAxIOu1QBAQEBAQEBAQEBAQEBAQEBAQEBAQERBIYYhEKCPYFeAQENMA0Jh?= =?us-ascii?q?AQFkwOESAGFbYgSjwWOfAEeAQFCggMZgUhqAYkwNH4BAQE?= X-IronPort-AV: E=Sophos;i="5.24,336,1454976000"; d="scan'208,217";a="247401816" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Mar 2016 17:54:53 +0000 Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u2EHsqa0025008 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 14 Mar 2016 17:54:52 GMT Received: from xch-rtp-012.cisco.com (64.101.220.152) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 14 Mar 2016 13:54:52 -0400 Received: from xch-rtp-012.cisco.com ([64.101.220.152]) by XCH-RTP-012.cisco.com ([64.101.220.152]) with mapi id 15.00.1104.009; Mon, 14 Mar 2016 13:54:52 -0400 From: "Gaurav Dawra (gdawra)" To: "Tomotaki, Luis M" , Susan Hares , "idr@ietf.org" Thread-Topic: [Idr] WG LC missed IPR Statements - 1 WG LC for IPR Thread-Index: AQHRfhqbAfiD7ZsxuUiiIufsHz0Kew== Date: Mon, 14 Mar 2016 17:54:52 +0000 Message-ID: References: <002401d16050$5cba52e0$162ef8a0$@ndzh.com> <467340A77F13C944919805BFF3B8ACFC30119EA786@FHDP1LUMXC7V91.us.one.verizon.com> In-Reply-To: <467340A77F13C944919805BFF3B8ACFC30119EA786@FHDP1LUMXC7V91.us.one.verizon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.0.151221 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.35.69.86] Content-Type: multipart/alternative; boundary="_000_D30C48F513E08Agdawraciscocom_" MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-idr-sla-exchange@ietf.org" Subject: Re: [Idr] WG LC missed IPR Statements - 1 WG LC for IPR X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2016 17:54:56 -0000 --_000_D30C48F513E08Agdawraciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support. Regards, -Gaurav From: Idr > on behalf of = "Tomotaki, Luis M" > Date: Monday, February 8, 2016 at 11:32 AM To: Susan Hares >, "idr@ietf.org" > Cc: "draft-ietf-idr-sla-exchange@ietf.org" > Subject: Re: [Idr] WG LC missed IPR Statements - 1 WG LC for IPR Susan, No, I am not aware of any IPR related to this document that has not alrea= dy been disclosed. Luis Tomotaki From: Susan Hares [mailto:shares@ndzh.com] Sent: Friday, February 05, 2016 2:04 PM To: idr@ietf.org Cc: 'Shitanshu Shah (svshah)'; draft-ietf-idr-sla-exchange@ietf.org; 'Alvaro Retana (aretana)'; 'John G. = Scudder' Subject: WG LC missed IPR Statements - 1 WG LC for IPR After a long review/edit cycle after WG LC, draft-ietf-idr-sla-exchange-07.= txt is ready to go to the IESG. You can see the resulting text at: https://datatracker.ietf.org/doc/draft-ietf-idr-sla-exchange/ However, in checking the IPR statements the IDR chairs missed two steps in = the process: Step 1: There was IPR declared in the mail message regarding draft-ietf-i= dr-sla-exchange-03: https://mailarchive.ietf.org/arch/msg/idr/rPvMVsFcM4xO= m1Vz_HNdAM3P250 This IPR is unusual in that the holder of the patent is not one of the auth= ors of the draft as the link shows: https://datatracker.ietf.org/ipr/search/?id=3Ddraft-ietf-idr-sla-exchange&s= ubmit=3Ddraft As a WG Chairs, we must ask again if the WG wants to approve the draft in t= he face of this patent. This begins a 1 Week IPR LC where the WG must send= positive indications they wish to send this document to WG LC. This messa= ge was sent prior to the WG LC (1/19/2015 to 2/5/2015), but no specific men= tion was made. Due to IPR policy, we must get a positive affirmation that = the WG LC wants to adopt this work. All authors to the draft MUST respond = to this IPR call or we cannot forward this to the IESG for publication. Details on these implementations of draft-ietf-idr-sla-exchange are at: https://trac.tools.ietf.org/wg/idr/trac/wiki/draft-ietf-idr-sla-exchange%20= implementations Step 2: three of the authors did not declare IPR on-list: Keyur Patel, S= . Bajaj, L. Tomotaki These authors need to declare if they know if additional IPR. Thank you for your patience, Sue Hares and John Scudder --_000_D30C48F513E08Agdawraciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Support.

Regards,

-Gaurav

From: Idr <idr-bounces@ietf.org> on behalf of "Tomotaki= , Luis M" <luis.tomota= ki@verizon.com>
Date: Monday, February 8, 2016 at 1= 1:32 AM
To: Susan Hares <shares@ndzh.com>, "idr@ietf.org" <idr@ietf= .org>
Cc: "draft-ietf-idr-sla-exchange@ietf.org&quo= t; <draft-ietf-i= dr-sla-exchange@ietf.org>
Subject: Re: [Idr] WG LC missed IPR= Statements - 1 WG LC for IPR

Susan,

  = No, I am not aware of any IPR related to this document that has not already= been disclosed.

&n= bsp;

Luis To= motaki

 

From: Susan Hares [ma= ilto:shares@ndzh.com]
Sent: Friday, February 05, 2016 2:04 PM
To: idr@ietf.org
Cc: 'Shitanshu Shah (svshah)'; draft-ietf-idr-sla-exchange@ietf.org; 'Alvaro Retana (aretana)'; 'John = G. Scudder'
Subject: WG LC missed IPR Statements - 1 WG LC for IPR

 

After a long review/edit cycle after WG LC, draft-ie= tf-idr-sla-exchange-07.txt is ready to go to the IESG.   You can = see the resulting text at:

 https://datatracker.ietf.org/doc/draft-ietf-idr= -sla-exchange/

 

However, in checking the IPR statements the IDR chai= rs missed two steps in the process:

 

Step 1:  There was IPR declared in the mail mes= sage regarding  draft-ietf-idr-sla-exchange-03:  https://mailarchive.ietf.org/arch/msg/idr/rPvMVsFcM4xOm1Vz_HNdAM3P25= 0

 

This IPR is unusual in that the holder of the patent= is not one of the authors of the draft as the link shows:

https://datatracker.ie= tf.org/ipr/search/?id=3Ddraft-ietf-idr-sla-exchange&submit=3Ddraft<= o:p>

 

As a WG Chairs, we must ask again if the WG wants to= approve the draft in the face of this patent.  This begins a 1 Week I= PR LC where the WG must send positive indications they wish to send this do= cument to WG LC.  This message was sent prior to the WG LC (1/19/2015 to 2/5/2015), but no specific mention was ma= de.  Due to IPR policy, we must get a positive affirmation that the WG= LC wants to adopt this work.  All authors to the draft MUST respond t= o this IPR call or we cannot forward this to the IESG for publication.

 

Details on these implementations of draft-ietf-idr-s= la-exchange are at:

https://trac.tools.ietf.= org/wg/idr/trac/wiki/draft-ietf-idr-sla-exchange%20implementations=

 

 

Step 2:  three of the authors did not declare I= PR on-list:  Keyur Patel,  S. Bajaj,  L. Tomotaki=

 

These authors need to declare if they know if additi= onal IPR.

 

Thank you for your patience,

 

Sue Hares and John Scudder  

 --_000_D30C48F513E08Agdawraciscocom_-- From nobody Mon Mar 14 10:57:14 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C159512DC54; Mon, 14 Mar 2016 10:57:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 i1L4w-pL8NQW; Mon, 14 Mar 2016 10:57:11 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F12E912D67E; Mon, 14 Mar 2016 10:57:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11533; q=dns/txt; s=iport; t=1457978231; x=1459187831; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Kp4rwZEiFY7jx0Gjfe6UHPhnHvGF0HVs2QVXtg8v1DI=; b=I1gow9GRIsUskPJLFtv7clbT59HLM4S1Y/Guqb8jy9U2Ox57UcDd+RDt /dizrYrv+/0724QxGL7y5Vi0ZHxjW2NeIO/w2VFbRmRZNgztGwzfWOliV W//wuKhaC0iT24soBzvdJ6sxK2tFajZQkdEF0EVK0cKPS1HSeP26XVeio E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A3AgBN+uZW/5NdJa1XBoJ6TFJtBrowA?= =?us-ascii?q?Q2BcCOFagKBMDgUAQEBAQEBAWQnhEEBAQEELUwQAgEIEQMBAQEoBzIUCQgBAQQ?= =?us-ascii?q?BDQWIDwMSDrtUAQEBAQEBAQEBAQEBAQEBAQEBAQEBEQSGGIRCgj2BXgEBDTANC?= =?us-ascii?q?YQEBZMDhEgBhW2IEo8FjnwBHgEBQoIDGYFIagGJMDR+AQEB?= X-IronPort-AV: E=Sophos; i="5.24,336,1454976000"; d="scan'208,217"; a="80602566" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Mar 2016 17:57:10 +0000 Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u2EHv9tc005914 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 14 Mar 2016 17:57:10 GMT Received: from xch-rtp-012.cisco.com (64.101.220.152) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 14 Mar 2016 13:57:09 -0400 Received: from xch-rtp-012.cisco.com ([64.101.220.152]) by XCH-RTP-012.cisco.com ([64.101.220.152]) with mapi id 15.00.1104.009; Mon, 14 Mar 2016 13:57:09 -0400 From: "Anoop Kapoor (ankapoor)" To: "Tomotaki, Luis M" , Susan Hares , "idr@ietf.org" Thread-Topic: [Idr] WG LC missed IPR Statements - 1 WG LC for IPR Thread-Index: AdFgTvATc4xhvDpqSdanGhK2hw1rbACTy0rgBueBbgD//5wLgA== Date: Mon, 14 Mar 2016 17:57:09 +0000 Message-ID: References: <002401d16050$5cba52e0$162ef8a0$@ndzh.com> <467340A77F13C944919805BFF3B8ACFC30119EA786@FHDP1LUMXC7V91.us.one.verizon.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.8.151023 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.154.57.125] Content-Type: multipart/alternative; boundary="_000_D30C493A16EFB4ankapoorciscocom_" MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-idr-sla-exchange@ietf.org" Subject: Re: [Idr] WG LC missed IPR Statements - 1 WG LC for IPR X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2016 17:57:14 -0000 --_000_D30C493A16EFB4ankapoorciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support. Anoop From: Idr > on behalf of = "Tomotaki, Luis M" > Date: Monday, February 8, 2016 at 11:32 AM To: Susan Hares >, "idr@ietf.org" > Cc: "draft-ietf-idr-sla-exchange@ietf.org" > Subject: Re: [Idr] WG LC missed IPR Statements - 1 WG LC for IPR Susan, No, I am not aware of any IPR related to this document that has not alrea= dy been disclosed. Luis Tomotaki From: Susan Hares [mailto:shares@ndzh.com] Sent: Friday, February 05, 2016 2:04 PM To: idr@ietf.org Cc: 'Shitanshu Shah (svshah)'; draft-ietf-idr-sla-exchange@ietf.org; 'Alvaro Retana (aretana)'; 'John G. = Scudder' Subject: WG LC missed IPR Statements - 1 WG LC for IPR After a long review/edit cycle after WG LC, draft-ietf-idr-sla-exchange-07.= txt is ready to go to the IESG. You can see the resulting text at: https://datatracker.ietf.org/doc/draft-ietf-idr-sla-exchange/ However, in checking the IPR statements the IDR chairs missed two steps in = the process: Step 1: There was IPR declared in the mail message regarding draft-ietf-i= dr-sla-exchange-03: https://mailarchive.ietf.org/arch/msg/idr/rPvMVsFcM4xO= m1Vz_HNdAM3P250 This IPR is unusual in that the holder of the patent is not one of the auth= ors of the draft as the link shows: https://datatracker.ietf.org/ipr/search/?id=3Ddraft-ietf-idr-sla-exchange&s= ubmit=3Ddraft As a WG Chairs, we must ask again if the WG wants to approve the draft in t= he face of this patent. This begins a 1 Week IPR LC where the WG must send= positive indications they wish to send this document to WG LC. This messa= ge was sent prior to the WG LC (1/19/2015 to 2/5/2015), but no specific men= tion was made. Due to IPR policy, we must get a positive affirmation that = the WG LC wants to adopt this work. All authors to the draft MUST respond = to this IPR call or we cannot forward this to the IESG for publication. Details on these implementations of draft-ietf-idr-sla-exchange are at: https://trac.tools.ietf.org/wg/idr/trac/wiki/draft-ietf-idr-sla-exchange%20= implementations Step 2: three of the authors did not declare IPR on-list: Keyur Patel, S= . Bajaj, L. Tomotaki These authors need to declare if they know if additional IPR. Thank you for your patience, Sue Hares and John Scudder --_000_D30C493A16EFB4ankapoorciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Support.

Anoop
From: Idr <idr-bounces@ietf.org> on behalf of "Tomotaki= , Luis M" <luis.tomota= ki@verizon.com>
Date: Monday, February 8, 2016 at 1= 1:32 AM
To: Susan Hares <shares@ndzh.com>, "idr@ietf.org" <idr@ietf= .org>
Cc: "draft-ietf-idr-sla-exchange@ietf.org&quo= t; <draft-ietf-i= dr-sla-exchange@ietf.org>
Subject: Re: [Idr] WG LC missed IPR= Statements - 1 WG LC for IPR

Susan,

  = No, I am not aware of any IPR related to this document that has not already= been disclosed.

&n= bsp;

Luis To= motaki

 

From: Susan Hares [ma= ilto:shares@ndzh.com]
Sent: Friday, February 05, 2016 2:04 PM
To: idr@ietf.org
Cc: 'Shitanshu Shah (svshah)'; draft-ietf-idr-sla-exchange@ietf.org; 'Alvaro Retana (aretana)'; 'John = G. Scudder'
Subject: WG LC missed IPR Statements - 1 WG LC for IPR

 

After a long review/edit cycle after WG LC, draft-ie= tf-idr-sla-exchange-07.txt is ready to go to the IESG.   You can = see the resulting text at:

 https://datatracker.ietf.org/doc/draft-ietf-idr= -sla-exchange/

 

However, in checking the IPR statements the IDR chai= rs missed two steps in the process:

 

Step 1:  There was IPR declared in the mail mes= sage regarding  draft-ietf-idr-sla-exchange-03:  https://mailarchive.ietf.org/arch/msg/idr/rPvMVsFcM4xOm1Vz_HNdAM3P25= 0

 

This IPR is unusual in that the holder of the patent= is not one of the authors of the draft as the link shows:

https://datatracker.ie= tf.org/ipr/search/?id=3Ddraft-ietf-idr-sla-exchange&submit=3Ddraft<= o:p>

 

As a WG Chairs, we must ask again if the WG wants to= approve the draft in the face of this patent.  This begins a 1 Week I= PR LC where the WG must send positive indications they wish to send this do= cument to WG LC.  This message was sent prior to the WG LC (1/19/2015 to 2/5/2015), but no specific mention was ma= de.  Due to IPR policy, we must get a positive affirmation that the WG= LC wants to adopt this work.  All authors to the draft MUST respond t= o this IPR call or we cannot forward this to the IESG for publication.

 

Details on these implementations of draft-ietf-idr-s= la-exchange are at:

https://trac.tools.ietf.= org/wg/idr/trac/wiki/draft-ietf-idr-sla-exchange%20implementations=

 

 

Step 2:  three of the authors did not declare I= PR on-list:  Keyur Patel,  S. Bajaj,  L. Tomotaki=

 

These authors need to declare if they know if additi= onal IPR.

 

Thank you for your patience,

 

Sue Hares and John Scudder  

 --_000_D30C493A16EFB4ankapoorciscocom_-- From nobody Mon Mar 14 11:36:48 2016 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 D4EE812DD5F; Fri, 11 Mar 2016 15:05:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.16.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160311230519.15028.2136.idtracker@ietfa.amsl.com> Date: Fri, 11 Mar 2016 15:05:19 -0800 Archived-At: X-Mailman-Approved-At: Mon, 14 Mar 2016 11:36:46 -0700 Cc: idr@ietf.org Subject: [Idr] idr - Requested session has been scheduled for IETF 95 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2016 23:05:20 -0000 Dear Susan Hares, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. idr Session 1 (2:30:00) Tuesday, Morning Session I 1000-1230 Room Name: Buen Ayre B size: 125 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Inter-Domain Routing Area Name: Routing Area Session Requester: Susan Hares Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 75 Conflicts to Avoid: First Priority: i2rs trill spring i2nsf rtgwg Second Priority: bess isis nvo3 ospf sidr rtgarea sfc teas l3sm Third Priority: mpls nmlrg nfvrg sdnrg supa nmrg Special Requests: --------------------------------------------------------- From nobody Mon Mar 14 11:38:01 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61FA312D712 for ; Mon, 14 Mar 2016 11:37:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 jBSwwI10pbxv for ; Mon, 14 Mar 2016 11:37:56 -0700 (PDT) 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 DAF2912DB71 for ; Mon, 14 Mar 2016 11:37:54 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CKO72388; Mon, 14 Mar 2016 18:37:52 +0000 (GMT) Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 14 Mar 2016 18:37:51 +0000 Received: from DFWEML501-MBS.china.huawei.com ([10.193.5.222]) by dfweml705-chm ([10.193.5.142]) with mapi id 14.03.0235.001; Mon, 14 Mar 2016 11:37:43 -0700 From: Lucy yong To: "Dongjie (Jimmy)" , Susan Hares , "idr@ietf.org" Thread-Topic: [Idr] ??: WG Work item call - Opinions on work items (3/5/2016 to 3/17/2016) and adoption of draft-hares-idr-flowspec-combo-01.txt Thread-Index: AdF3MOvE/JSvgLOkQ3a9MB8GleM7AQG1d2AgAAZgGfA= Date: Mon, 14 Mar 2016 18:37:43 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D5725FB7A@dfweml501-mbs> References: <000b01d17731$29d17230$7d745690$@ndzh.com> <76CD132C3ADEF848BD84D028D243C92774E3EF6C@NKGEML515-MBX.china.huawei.com> In-Reply-To: <76CD132C3ADEF848BD84D028D243C92774E3EF6C@NKGEML515-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.175] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D5725FB7Adfweml501mbs_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.56E70501.0061, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 1e92d668f8023ddd5ccc617b54791fc0 Archived-At: Subject: Re: [Idr] ??: WG Work item call - Opinions on work items (3/5/2016 to 3/17/2016) and adoption of draft-hares-idr-flowspec-combo-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2016 18:37:59 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D5725FB7Adfweml501mbs_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 c3VwcG9ydCBKaWWhr3Mgc3VnZ2VzdGlvbi4NCg0KTHVjeQ0KDQpGcm9tOiBJZHIgW21haWx0bzpp ZHItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIERvbmdqaWUgKEppbW15KQ0KU2VudDog TW9uZGF5LCBNYXJjaCAxNCwgMjAxNiAxMDo0NiBBTQ0KVG86IFN1c2FuIEhhcmVzOyBpZHJAaWV0 Zi5vcmcNClN1YmplY3Q6IFtJZHJdID8/OiBXRyBXb3JrIGl0ZW0gY2FsbCAtIE9waW5pb25zIG9u IHdvcmsgaXRlbXMgKDMvNS8yMDE2IHRvIDMvMTcvMjAxNikgYW5kIGFkb3B0aW9uIG9mIGRyYWZ0 LWhhcmVzLWlkci1mbG93c3BlYy1jb21iby0wMS50eHQNCg0KSGksDQoNCklNTyBpbiBzaG9ydCB0 ZXJtIHdlIG5lZWQgdG8gd29yayBvbiBvcHRpb24xLCBpbiB3aGljaCBvcmRlcmluZyBhbmQgY29t YmluYXRpb24gcnVsZXMgbmVlZCB0byBiZSBzcGVjaWZpZWQuDQoNCkFzIGZvciBvcHRpb24gMiwg d2UgbWF5IG5lZWQgdG8gdGFrZSB0aGUgY2hhcmFjdGVyaXN0aWNzIG9mIEJHUCBpbnRvIGNvbnNp ZGVyYXRpb24gYW5kIGlkZW50aWZ5IHRoZSBhcHByb3ByaWF0ZSB1c2UgY2FzZXMgZm9yIEJHUC1G UywgdGhlbiBtYWtlIHRoZSBwcm90b2NvbCBleHRlbnNpb24gYWNjb3JkaW5nbHkuDQoNCkJlc3Qg cmVnYXJkcywNCkppZQ0KDQq3orz+yMs6IElkciBbbWFpbHRvOmlkci1ib3VuY2VzQGlldGYub3Jn XSC0+rHtIFN1c2FuIEhhcmVzDQq3osvNyrG85DogMjAxNsTqM9TCNsjVIDY6NDkNCsrVvP7Iyzog aWRyQGlldGYub3JnPG1haWx0bzppZHJAaWV0Zi5vcmc+DQrW98ziOiBbSWRyXSBXRyBXb3JrIGl0 ZW0gY2FsbCAtIE9waW5pb25zIG9uIHdvcmsgaXRlbXMgKDMvNS8yMDE2IHRvIDMvMTcvMjAxNikg YW5kIGFkb3B0aW9uIG9mIGRyYWZ0LWhhcmVzLWlkci1mbG93c3BlYy1jb21iby0wMS50eHQNCg0K VGhlIGludGVyaW0gb24gMy83LzIwMTYgd2lsbCBoYXZlIGEgZGlzY3Vzc2lvbiBvZiByZXZpc2lv bnMgdG8gdGhlIEJHUCBGbG93IHNwZWNpZmljYXRpb24gKEJHUC1GUykgdG8gYWRkIG1vcmUgZmVh dHVyZXMuICBUaGVyZSBhcmUgdHdvIHN1Z2dlc3RlZCBvcHRpb25zOg0KDQoNCjEpICAgICAgQSBt aW5pbWFsIGZlYXR1cmVzIHRvIGV4aXN0aW5nIEJHUC1GUyAob3B0aW9uIDEpDQoNCkFkZCBhIGZl dyBuZXcgbWF0Y2ggZmlsdGVycyB0byB0aGUgQkdQLUZTIE5MUkkgYW5kIGZldyBuZXcgYWN0aW9u cyB0byB0aGUgQkdQLUZTIGFjdGlvbnMgKGluIEV4dGVuZGVkIGNvbW11bml0aWVzKS4gIEFjdGlv bnMgd291bGQgbmVlZCB0byBiZSBkb25lIGluIGEgZGVmaW5lZCBvcmRlci4gRWFjaCBuZXcgYWN0 aW9ucyB3b3VsZCBuZWVkIHRvIGRlZmluZSBjb25mbGljdHMgd2l0aCBleGlzdGluZyBhY3Rpb25z Lg0KDQoNCg0KQmVzdCB1c2UgY2FzZTogIERvUyBhdHRhY2sgcHJldmVudGlvbg0KDQoNCg0KMikg ICAgICBDcmVhdGUgYSBCR1AtRlMgdmVyc2lvbiAyIChvcHRpb24gMikNCg0KQ3JlYXRlIGEgbmV3 IEJHUC1GUyBOTFJJICh2Mikgd2l0aCBhIGZpZWxkIHRoYXQgaW5kaWNhdGVzIHRoZSBvcmRlcmlu ZyBvZiB0aGUgQkdQIE5MUkkuICBBZGQgbmV3IEJHUC1GUyBhY3Rpb25zIHdpdGggYW4gb3JkZXIg ZmllbGQgaW4gdGhlIEJHUCBXaWRlIENvbW11bml0aWVzLiAgRmlsdGVycyBhcmUgZG9uZSBpbiB0 aGUgb3JkZXIgZGVmaW5lZCBpbiB0aGUgZmlsdGVyLiAgQWN0aW9ucyBhcmUgZG9uZSBpbiB0aGUg b3JkZXIgZGVmaW5lZCBpbiB0aGUgYWN0aW9ucy4gICBPcmRlciBudW1iZXJzIHRoYXQgdGllIGFy ZSBoYW5kbGVkIGluIGEgZGVmaW5lZCBvcmRlci4NCg0KDQoNCkJlc3QgdXNlIGNhc2U6IFNETi9O RlYgZmlsdGVyIG1hbmFnZW1lbnQNCg0KQSB3cml0ZS11cCBvbiB0aGUgaXNzdWVzIGFuZCBwcm9w b3NlZCBzb2x1dGlvbnMgaXMgY29udGFpbmVkIGluOg0KZHJhZnQtaGFyZXMtaWRyLWZsb3dzcGVj LWNvbWJvLTAxLnR4dC4gPGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWhh cmVzLWlkci1mbG93c3BlYy1jb21iby8+ICAgIFRoZSBXRyBjYW4gc2VsZWN0IGJvdGggb3B0aW9u IDEgYW5kIG9wdGlvbiAyLiAgVGhpcyBpcyBhIFdHIHdvcmsgaXRlbSBjYWxsIGZvciBpbnB1dCB0 byB0aGUgY2hhaXJzIG9uIHRoZSBzY29wZSBvZiB0aGUgV0cgaXRlbS4gIEluIHlvdSBkaXNjdXNz aW9uIG9mIHRoaXMgdG9waWNzLCB0aGUgY2hhaXJzIHdvdWxkIGFwcHJlY2lhdGUgaWYgeW91IHdv dWxkIGluZGljYXRlIGlmIHlvdSB3b3VsZCBzdXBwb3J0IElEUiB3b3JraW5nIG9uIG9wdGlvbiAx LCBvcHRpb24gMiBvciBib3RoIG9wdGlvbiAxIGFuZCAyLiAgVGhpcyBXRyBjYWxsIGl0ZW1zIGFs c28gaW5jbHVkZXMgYSBjYWxsIGZvciBkcmFmdC1oYXJlcy1pZHItZmxvd3NwZWMtY29tYm8tMDEu dHh0IGFzIGEgd3JpdGUtdXAgb2YgdGhlIHdvcmstaXRlbSBvcHRpb25zLiAgVGhlIFdHIG1heSB3 aXNoIHRvIHNwbGl0IHRoaXMgZHJhZnQgaW50byBtdWx0aXBsZSBkcmFmdHMuDQoNClRoZSBmb2xs b3dpbmcgZHJhZnRzIGFyZSBiZWluZyBjb25zaWRlciBmb3IgZWl0aGVyIG9wdGlvbjoNCg0KMSkg ICAgICBkcmFmdC1lZGR5LWlkci1mbG93c3BlYy1wYWNrZXQtcmF0ZQ0KDQoyKSAgICAgIGRyYWZ0 LWhhby1pZHItZmxvd3NwZWMtbnYwMw0KDQozKSAgICAgIGRyYWZ0LWhhby1pZHItZmxvd3NwZWMt bGFiZWwNCg0KNCkgICAgICBkcmFmdC1saWFuZy1pZHItYmdwLWZsb3dzcGVjLXRpbWUNCg0KNSkg ICAgICBkcmFmdC1saXRvd3NraS1pZHItZmxvd3NwZWMtaW50ZXJmYWNlc2V0DQoNCjYpICAgICAg ZHJhZnQtdmFuZGV2ZWxkZS1pZHItZmxvd3NwZWMtcGF0aC1yZWRpcmVjdA0KDQo3KSAgICAgIGRy YWZ0LWxpLWlkci1mbG93c3BlYy1ycGQtMDEudHh0DQoNCjgpICAgICAgZHJhZnQtd3UtaWRyLWZs b3dzcGVjLXlhbmcuY2ZnLg0KDQpJZiB5b3Ugd2lzaCB0byBjb21tZW50IG9uIGFueSBvZiB0aGVz ZSBkcmFmdHMsIHdlIHdpbGwNCg0KV2Ugd2lsbCBjb25jbHVkZSB0aGUgQ2FsbCBmb3IgV0cgb3Bp bmlvbnMgb24gMy8xNy8yMDE2IHNvIHRoZXNlIGF1dGhvcnMgY2FuIGhhdmUgYSBkYXkgdG8gcmV2 aXNlIGFuZCBzdWJtaXQgdGhlaXIgZHJhZnRzIGJlZm9yZSB0aGUgZHJhZnQgZGVhZGxpbmUuDQoN ClN1ZSBIYXJlcyBhbmQgSm9obiBTY3VkZGVyDQoNClBTOg0KZHJhZnQtbGktaWRyLWZsb3dzcGVj LXJwZCBkaXNjdXNzZXMgbGltaXRzIG9uIHRoZSBkaXN0cmlidXRpb24gb2YgdGhlIHBvbGljeSB3 aGljaCBoYXMgYmVlbiByZWNhc3QgaW4gZHJhZnQtaGFyZXMtaWRyLWZsb3dzcGVjLWNvbWJvIGFz IGEgYmdwLXdpZGUgY29tbXVuaXR5IG9mIENvbnRhaW5lciB0eXBlIDEgd2l0aCBhbiBhdG9tIG9m IEJHUCBGbG93IFNwZWNpZmljYXRpb24gb3JkZXJpbmcuIEhvd2V2ZXIsICB0aGlzIGRyYWZ0IGlz IGluY2x1ZGVkIGluIHRoZSBsaXN0IHRvIGJlIGFibGUgdG8gdXBkYXRlIHRoZSBtZWNoYW5pc20g ZnJvbSB0aGlzIGRyYWZ0IGludG8gdGhhdCBjb250ZXh0Lg0KDQpUaGUgeWFuZyBtb2RlbCBmb3Ig QkdQIEZsb3cgc3BlY2lmaWNhdGlvbiBpcyBhbHNvIGluY2x1ZGVkIGluIHRoaXMgd29yayBpdGVt IGFzIGl0IHdpbGwgbmVlZCB0byBiZSBtb2RpZmllZCBiYXNlZCBvbiB0aGUgYXBwcm9hY2hlcy4g IFRoZSB5YW5nIG1vZGVsIGlzIGluIGRyYWZ0LXd1LWlkci1mbG93c3BlYy15YW5nLWNmZy4gIElu IHlvdXIgY29tbWVudHMsIHBsZWFzZSBpbmRpY2F0ZSBpZiB5b3UgZmVlbCB0aGVzZSBkcmFmdHMg b3Igb3RoZXIgZHJhZnRzLg0KDQo= --_000_2691CE0099834E4A9C5044EEC662BB9D5725FB7Adfweml501mbs_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

support Jie=A1=AFs = suggestion.

 

Lucy

 

From: Idr [mai= lto:idr-bounces@ietf.org] On Behalf Of Dongjie (Jimmy)
Sent: Monday, March 14, 2016 10:46 AM
To: Susan Hares; idr@ietf.org
Subject: [Idr] ??: WG Work item call - Opinions on work items (3/5/2= 016 to 3/17/2016) and adoption of draft-hares-idr-flowspec-combo-01.txt

 

Hi, <= o:p>

=  

IMO i= n short term we need to work on option1, in which ordering and combination = rules need to be specified.

=  

As fo= r option 2, we may need to take the characteristics of BGP into considerati= on and identify the appropriate use cases for BGP-FS, then make the protoco= l extension accordingly.

=  

Best = regards,

Jie

=  

=B7=A2=BC=FE=C8=CB: Idr [mailto:idr-bo= unces@ietf.org] =B4=FA=B1=ED Susan Hares<= br> =B7=A2=CB=CD=CA=B1=BC=E4: 2016=C4=EA= 3= =D4=C26=C8=D5 6:49
=CA=D5=BC=FE=C8=CB: idr@ietf.org
=D6=F7=CC=E2: [Idr]= WG Work item call - Opinions on work items (3/5/2016 to 3/17/2016) and adoption of draft-hares-idr-flowspec-combo-01.txt

 

The interim on 3/7/2016 will have a discussion of re= visions to the BGP Flow specification (BGP-FS) to add more features.  = There are two suggested options:

 

1)      A minimal features to existing BGP-FS (option 1)

Add a few new match filters to the BGP-FS NLR= I and few new actions to the BGP-FS actions (in Extended communities). &nbs= p;Actions would need to be done in a defined order. Each new actions would = need to define conflicts with existing actions.   

 

Best use case:  DoS attack prevention

 

2)      Create a BGP-FS version 2 (option 2)

Create a new BGP-FS NLRI (v2) with a field th= at indicates the ordering of the BGP NLRI.  Add new BGP-FS actions wit= h an order field in the BGP Wide Communities.  Filters are done in the= order defined in the filter.  Actions are done in the order defined in the actions.   Order numbers that tie ar= e handled in a defined order.

 

Best use case: SDN/NFV filter management

 

A write-up on the issues and proposed solutions is c= ontained in:

draft-hares-idr-flowspec-combo-01.txt.    The WG can select both option 1 and option 2.  T= his is a WG work item call for input to the chairs on the scope of the WG i= tem.  In you discussion of this topics, the chairs would appreciate if= you would indicate if you would support IDR working on option 1, option 2 or both option 1 and 2.  This WG call items also includes= a call for draft-hares-idr-flowspec-combo-01.txt as a write-up of the work= -item options.  The WG may wish to split this draft into multiple draf= ts.

 

The following drafts are being consider for either o= ption:

1)      draft-eddy-idr-flowspec-packet-rate

2)      draft-hao-idr-flowspec-nv03

3)      draft-hao-idr-flowspec-label

4)      draft-liang-idr-bgp-flowspec-time

5)      draft-litowski-idr-flowspec-interfaceset

6)      draft-vandevelde-idr-flowspec-path-redirect

7)      draft-li-idr-flowspec-rpd-01.txt

8)      draft-wu-idr-flowspec-yang.cfg.

 

If you wish to comment on any of these drafts, we wi= ll

 

We will conclude the Call for WG opinions on 3/17/20= 16 so these authors can have a day to revise and submit their drafts before= the draft deadline.

 

Sue Hares and John Scudder

 

PS:

draft-li-idr-flowspec-rpd discusses limits on the di= stribution of the policy which has been recast in draft-hares-idr-flowspec-= combo as a bgp-wide community of Container type 1 with an atom of BGP Flow = Specification ordering. However,  this draft is included in the list to be able to update the mechanism from= this draft into that context.  

 

The yang model for BGP Flow specification is also in= cluded in this work item as it will need to be modified based on the approa= ches.  The yang model is in draft-wu-idr-flowspec-yang-cfg.  In y= our comments, please indicate if you feel these drafts or other drafts. 

 

--_000_2691CE0099834E4A9C5044EEC662BB9D5725FB7Adfweml501mbs_-- From nobody Mon Mar 14 11:52:19 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32A9212D705; Mon, 14 Mar 2016 11:52:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 LteO6K-X3NHY; Mon, 14 Mar 2016 11:52:13 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9473D12D6FA; Mon, 14 Mar 2016 11:52:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8158; q=dns/txt; s=iport; t=1457981533; x=1459191133; h=from:to:cc:subject:date:message-id:mime-version; bh=JQ8ObAx8YMg/S2QEowONXn8N878lNi3//hkesQ99fcU=; b=blt5CyrbYdn5kbArV/j5Bviv7MejAz7/jtItdDfNjXZqmcjG7h4olEIU yGOVPzYQEamA1ZG6D5gQvsziulWuBqT+fDaRxVUnLssrKwfUTjoSchcpU 5FdC7vAqmkoXMu0wA0kv3ZoQRNFXLz49A4RhViZKKyD7chj1pu/qYvBbz A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A3AgANCOdW/5tdJa1XBoJ6TFJtBrowA?= =?us-ascii?q?Q2BcCOFagKBMTgUAQEBAQEBAWQnhEEBAQEEeRIBCBEDAQEBKDkUCQoEAQ0FiA8?= =?us-ascii?q?DEg67fAEBAQEBAQEBAQEBAQEBAQEBAQEBAREEhhiEQoI9gV4BAQ0whBoFl0sBh?= =?us-ascii?q?W2IEo8FjnwBHgEBQoIDGYFIagGJMDR+AQEB?= X-IronPort-AV: E=Sophos; i="5.24,337,1454976000"; d="scan'208,217"; a="86303239" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Mar 2016 18:51:59 +0000 Received: from XCH-RTP-020.cisco.com (xch-rtp-020.cisco.com [64.101.220.160]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u2EIpx9o010019 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 14 Mar 2016 18:51:59 GMT Received: from xch-rtp-019.cisco.com (64.101.220.159) by XCH-RTP-020.cisco.com (64.101.220.160) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 14 Mar 2016 14:51:58 -0400 Received: from xch-rtp-019.cisco.com ([64.101.220.159]) by XCH-RTP-019.cisco.com ([64.101.220.159]) with mapi id 15.00.1104.009; Mon, 14 Mar 2016 14:51:58 -0400 From: "Mohammed Mirza (mohamirz)" To: "idr-bounces@ietf.org" , "shares@ndzh.com" Thread-Topic: [Idr] WG LC missed IPR Statements - 1 WG LC for IPR Thread-Index: AQHRfiKWazIj6afW7UWFqOzagurcXw== Date: Mon, 14 Mar 2016 18:51:58 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.9.151119 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.154.56.244] Content-Type: multipart/alternative; boundary="_000_D30C565A10377mohamirzciscocom_" MIME-Version: 1.0 Archived-At: Cc: "idr@ietf.org" , "Keyur Patel \(keyupate\)" , "draft-ietf-idr-sla-exchange@ietf.org" Subject: Re: [Idr] WG LC missed IPR Statements - 1 WG LC for IPR X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2016 18:52:16 -0000 --_000_D30C565A10377mohamirzciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Susan, +1, I'm not aware of any IPR related to this document that has not alread= y been disclosed. Mohammed From: Idr > on behalf of = "Tomotaki, Luis M" > Date: Monday, February 8, 2016 at 11:32 AM To: Susan Hares >, "idr@ietf.org" > Cc: "draft-ietf-idr-sla-exchange@ietf.org" > Subject: Re: [Idr] WG LC missed IPR Statements - 1 WG LC for IPR Susan, No, I am not aware of any IPR related to this document that has not alrea= dy been disclosed. Luis Tomotaki From: Susan Hares [mailto:shares@ndzh.com] Sent: Friday, February 05, 2016 2:04 PM To: idr@ietf.org Cc: 'Shitanshu Shah (svshah)'; draft-ietf-idr-sla-exchange@ietf.org; 'Alvaro Retana (aretana)'; 'John G. = Scudder' Subject: WG LC missed IPR Statements - 1 WG LC for IPR After a long review/edit cycle after WG LC, draft-ietf-idr-sla-exchange-07.= txt is ready to go to the IESG. You can see the resulting text at: https://datatracker.ietf.org/doc/draft-ietf-idr-sla-exchange/ However, in checking the IPR statements the IDR chairs missed two steps in = the process: Step 1: There was IPR declared in the mail message regarding draft-ietf-i= dr-sla-exchange-03: https://mailarchive.ietf.org/arch/msg/idr/rPvMVsFcM4xO= m1Vz_HNdAM3P250 This IPR is unusual in that the holder of the patent is not one of the auth= ors of the draft as the link shows: https://datatracker.ietf.org/ipr/search/?id=3Ddraft-ietf-idr-sla-exchange&s= ubmit=3Ddraft As a WG Chairs, we must ask again if the WG wants to approve the draft in t= he face of this patent. This begins a 1 Week IPR LC where the WG must send= positive indications they wish to send this document to WG LC. This messa= ge was sent prior to the WG LC (1/19/2015 to 2/5/2015), but no specific men= tion was made. Due to IPR policy, we must get a positive affirmation that = the WG LC wants to adopt this work. All authors to the draft MUST respond = to this IPR call or we cannot forward this to the IESG for publication. Details on these implementations of draft-ietf-idr-sla-exchange are at: https://trac.tools.ietf.org/wg/idr/trac/wiki/draft-ietf-idr-sla-exchange%20= implementations Step 2: three of the authors did not declare IPR on-list: Keyur Patel, S= . Bajaj, L. Tomotaki These authors need to declare if they know if additional IPR. Thank you for your patience, Sue Hares and John Scudder --_000_D30C565A10377mohamirzciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable 
=
Susan,
  +1, I'm not aware of any IPR related to this document that has not al=
ready been disclosed.


Mohammed


From: Idr <idr-bounces@ietf.org<mailt=
o:idr-bounces@ietf.org>> on behalf of "Tomotaki, Luis M" &l=
t;luis.tomotaki@verizon.com<mailto:luis.tomotaki@verizon.com>>
Date: Monday, February 8, 2016 at 11:32 AM
To: Susan Hares <shares@ndzh.com<mailto:shares@ndzh.com>>, &quo=
t;idr@ietf.org<mailto:idr@ietf.org>" <idr@ietf.org<mailto:=
idr@ietf.org>>
Cc: "draft-ietf-idr-sla-exchange@ietf.org<mailto:draft-ietf-idr-sla=
-exchange@ietf.org>" <draft-ietf-idr-sla-exchange@ietf.org<ma=
ilto:draft-ietf-idr-sla-exchange@ietf.org>>
Subject: Re: [Idr] WG LC missed IPR Statements - 1 WG LC for IPR

Susan,
  No, I am not aware of any IPR related to this document that has not alrea=
dy been disclosed.

Luis Tomotaki

From: Susan Hares [mailto:shares@ndzh.com]
Sent: Friday, February 05, 2016 2:04 PM
To: idr@ietf.org<mailto:idr@ietf.org>
Cc: 'Shitanshu Shah (svshah)'; draft-ietf-idr-sla-exchange@ietf.org<mail=
to:draft-ietf-idr-sla-exchange@ietf.org>; 'Alvaro Retana (aretana)'; 'Jo=
hn G. Scudder'
Subject: WG LC missed IPR Statements - 1 WG LC for IPR

After a long review/edit cycle after WG LC, draft-ietf-idr-sla-exchange-07.=
txt is ready to go to the IESG.   You can see the resulting text at:
 https://datatracker.ietf.org/doc/draft-ietf-idr-sla-exchange/

However, in checking the IPR statements the IDR chairs missed two steps in =
the process:

Step 1:  There was IPR declared in the mail message regarding  draft-ietf-i=
dr-sla-exchange-03:  https://mailarchive.ietf.org/arch/msg/idr/rPvMVsFcM4xO=
m1Vz_HNdAM3P250

This IPR is unusual in that the holder of the patent is not one of the auth=
ors of the draft as the link shows:
https://datatracker.ietf.org/ipr/search/?id=3Ddraft-ietf-idr-sla-exchange&a=
mp;submit=3Ddraft

As a WG Chairs, we must ask again if the WG wants to approve the draft in t=
he face of this patent.  This begins a 1 Week IPR LC where the WG must send=
 positive indications they wish to send this document to WG LC.  This messa=
ge was sent prior to the WG LC (1/19/2015 to 2/5/2015), but no specific men=
tion was made.  Due to IPR policy, we must get a positive affirmation that =
the WG LC wants to adopt this work.  All authors to the draft MUST respond =
to this IPR call or we cannot forward this to the IESG for publication.

Details on these implementations of draft-ietf-idr-sla-exchange are at:
https://trac.tools.ietf.org/wg/idr/trac/wiki/draft-ietf-idr-sla-exchange%20=
implementations


Step 2:  three of the authors did not declare IPR on-list:  Keyur Patel,  S=
. Bajaj,  L. Tomotaki

These authors need to declare if they know if additional IPR.

Thank you for your patience,

Sue Hares and John Scudder
--_000_D30C565A10377mohamirzciscocom_-- From nobody Mon Mar 14 11:56:28 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE4E612DC8C; Mon, 14 Mar 2016 11:56:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 jIwqMnjRsAvi; Mon, 14 Mar 2016 11:56:24 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E596912DC6B; Mon, 14 Mar 2016 11:56:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11306; q=dns/txt; s=iport; t=1457981777; x=1459191377; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=YG9flZnc2OIhkei8X8T6yya5lZYqddfbIJF5NcJzjw4=; b=SMtmlDt0VcGppLmx3hwVEJXwVGPDqaGzVloggsSk3GL3AkPRUuo4TQ4K 0nv7kURyMHqShdfq6sa15o11x/WrdqJiAatT5k7C8bmE1KXV8U8sdrl0u LAczC/ZHwLBce/HDN94OPNk87aYHZcFNSFcsz1r6aVJuFB01k4cIljrcL k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A3AgAYCedW/5xdJa1XBoJ6TFJtBrowA?= =?us-ascii?q?Q2BcCOFagKBMTgUAQEBAQEBAWQnhEEBAQEELUwQAgEIEQMBAQEoBzIUCQgBAQQ?= =?us-ascii?q?BDQWIDwMSDrt9AQEBAQEBAQEBAQEBAQEBAQEBAQEBEQSGGIRCgj2BXgEBDTANC?= =?us-ascii?q?YQEBZMDhEgBhW2IEo8FjnwBHgEBQoIDGYFIagGJMDR+AQEB?= X-IronPort-AV: E=Sophos;i="5.24,337,1454976000"; d="scan'208,217";a="249386521" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Mar 2016 18:56:02 +0000 Received: from XCH-RCD-020.cisco.com (xch-rcd-020.cisco.com [173.37.102.30]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u2EIu2P9009395 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 14 Mar 2016 18:56:02 GMT Received: from xch-aln-020.cisco.com (173.36.7.30) by XCH-RCD-020.cisco.com (173.37.102.30) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 14 Mar 2016 13:56:01 -0500 Received: from xch-aln-020.cisco.com ([173.36.7.30]) by XCH-ALN-020.cisco.com ([173.36.7.30]) with mapi id 15.00.1104.009; Mon, 14 Mar 2016 13:56:01 -0500 From: "Steven Cheung (stecheun)" To: "Tomotaki, Luis M" , Susan Hares , "idr@ietf.org" Thread-Topic: [Idr] WG LC missed IPR Statements - 1 WG LC for IPR Thread-Index: AdFgTvATc4xhvDpqSdanGhK2hw1rbACTy0rgBt8q/AA= Date: Mon, 14 Mar 2016 18:56:01 +0000 Message-ID: References: <002401d16050$5cba52e0$162ef8a0$@ndzh.com> <467340A77F13C944919805BFF3B8ACFC30119EA786@FHDP1LUMXC7V91.us.one.verizon.com> In-Reply-To: <467340A77F13C944919805BFF3B8ACFC30119EA786@FHDP1LUMXC7V91.us.one.verizon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.1.160122 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.75.234.95] Content-Type: multipart/alternative; boundary="_000_D30C57456B89Fstecheunciscocom_" MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-idr-sla-exchange@ietf.org" Subject: Re: [Idr] WG LC missed IPR Statements - 1 WG LC for IPR X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2016 18:56:27 -0000 --_000_D30C57456B89Fstecheunciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support. -Steven From: Idr > on behalf of = "Tomotaki, Luis M" > Date: Monday, February 8, 2016 at 10:32 AM To: Susan Hares >, "idr@ietf.org" > Cc: "draft-ietf-idr-sla-exchange@ietf.org" > Subject: Re: [Idr] WG LC missed IPR Statements - 1 WG LC for IPR Susan, No, I am not aware of any IPR related to this document that has not alrea= dy been disclosed. Luis Tomotaki From: Susan Hares [mailto:shares@ndzh.com] Sent: Friday, February 05, 2016 2:04 PM To: idr@ietf.org Cc: 'Shitanshu Shah (svshah)'; draft-ietf-idr-sla-exchange@ietf.org; 'Alvaro Retana (aretana)'; 'John G. = Scudder' Subject: WG LC missed IPR Statements - 1 WG LC for IPR After a long review/edit cycle after WG LC, draft-ietf-idr-sla-exchange-07.= txt is ready to go to the IESG. You can see the resulting text at: https://datatracker.ietf.org/doc/draft-ietf-idr-sla-exchange/ However, in checking the IPR statements the IDR chairs missed two steps in = the process: Step 1: There was IPR declared in the mail message regarding draft-ietf-i= dr-sla-exchange-03: https://mailarchive.ietf.org/arch/msg/idr/rPvMVsFcM4xO= m1Vz_HNdAM3P250 This IPR is unusual in that the holder of the patent is not one of the auth= ors of the draft as the link shows: https://datatracker.ietf.org/ipr/search/?id=3Ddraft-ietf-idr-sla-exchange&s= ubmit=3Ddraft As a WG Chairs, we must ask again if the WG wants to approve the draft in t= he face of this patent. This begins a 1 Week IPR LC where the WG must send= positive indications they wish to send this document to WG LC. This messa= ge was sent prior to the WG LC (1/19/2015 to 2/5/2015), but no specific men= tion was made. Due to IPR policy, we must get a positive affirmation that = the WG LC wants to adopt this work. All authors to the draft MUST respond = to this IPR call or we cannot forward this to the IESG for publication. Details on these implementations of draft-ietf-idr-sla-exchange are at: https://trac.tools.ietf.org/wg/idr/trac/wiki/draft-ietf-idr-sla-exchange%20= implementations Step 2: three of the authors did not declare IPR on-list: Keyur Patel, S= . Bajaj, L. Tomotaki These authors need to declare if they know if additional IPR. Thank you for your patience, Sue Hares and John Scudder --_000_D30C57456B89Fstecheunciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <30451F635F2D484DBCEFE6A6842577E1@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Support.

-Steven

From: Idr <idr-bounces@ietf.org> on behalf of "Tomotaki= , Luis M" <luis.tomota= ki@verizon.com>
Date: Monday, February 8, 2016 at 1= 0:32 AM
To: Susan Hares <shares@ndzh.com>, "idr@ietf.org" <idr@ietf= .org>
Cc: "draft-ietf-idr-sla-exchange@ietf.org&quo= t; <draft-ietf-i= dr-sla-exchange@ietf.org>
Subject: Re: [Idr] WG LC missed IPR= Statements - 1 WG LC for IPR

Susan,

  = No, I am not aware of any IPR related to this document that has not already= been disclosed.

&n= bsp;

Luis To= motaki

 

From: Susan Hares [ma= ilto:shares@ndzh.com]
Sent: Friday, February 05, 2016 2:04 PM
To: idr@ietf.org
Cc: 'Shitanshu Shah (svshah)'; draft-ietf-idr-sla-exchange@ietf.org; 'Alvaro Retana (aretana)'; 'John = G. Scudder'
Subject: WG LC missed IPR Statements - 1 WG LC for IPR

 

After a long review/edit cycle after WG LC, draft-ie= tf-idr-sla-exchange-07.txt is ready to go to the IESG.   You can = see the resulting text at:

 https://datatracker.ietf.org/doc/draft-ietf-idr= -sla-exchange/

 

However, in checking the IPR statements the IDR chai= rs missed two steps in the process:

 

Step 1:  There was IPR declared in the mail mes= sage regarding  draft-ietf-idr-sla-exchange-03:  https://mailarchive.ietf.org/arch/msg/idr/rPvMVsFcM4xOm1Vz_HNdAM3P25= 0

 

This IPR is unusual in that the holder of the patent= is not one of the authors of the draft as the link shows:

https://datatracker.ie= tf.org/ipr/search/?id=3Ddraft-ietf-idr-sla-exchange&submit=3Ddraft<= o:p>

 

As a WG Chairs, we must ask again if the WG wants to= approve the draft in the face of this patent.  This begins a 1 Week I= PR LC where the WG must send positive indications they wish to send this do= cument to WG LC.  This message was sent prior to the WG LC (1/19/2015 to 2/5/2015), but no specific mention was ma= de.  Due to IPR policy, we must get a positive affirmation that the WG= LC wants to adopt this work.  All authors to the draft MUST respond t= o this IPR call or we cannot forward this to the IESG for publication.

 

Details on these implementations of draft-ietf-idr-s= la-exchange are at:

https://trac.tools.ietf.= org/wg/idr/trac/wiki/draft-ietf-idr-sla-exchange%20implementations=

 

 

Step 2:  three of the authors did not declare I= PR on-list:  Keyur Patel,  S. Bajaj,  L. Tomotaki=

 

These authors need to declare if they know if additi= onal IPR.

 

Thank you for your patience,

 

Sue Hares and John Scudder  

 --_000_D30C57456B89Fstecheunciscocom_-- From nobody Mon Mar 14 18:05:41 2016 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 AF39512D6A2; Mon, 14 Mar 2016 18:05:39 -0700 (PDT) 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.16.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160315010539.25840.6299.idtracker@ietfa.amsl.com> Date: Mon, 14 Mar 2016 18:05:39 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-ext-opt-param-04.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 01:05:40 -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 of the IETF. Title : Extended Optional Parameters Length for BGP OPEN Message Authors : Enke Chen John Scudder Filename : draft-ietf-idr-ext-opt-param-04.txt Pages : 5 Date : 2016-03-14 Abstract: The Optional Parameters in the BGP OPEN message as defined in the base BGP specification are limited to 255 octets due to a one-octet length field. BGP Capabilities are carried in this field and may foreseeably exceed 255 octets in the future, leading to concern about this limitation. In this document we extend the BGP OPEN length field in a backward- compatible manner. The Parameter Length field of individual Optional Parameters is similarly extended. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-ext-opt-param/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-ext-opt-param-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-ext-opt-param-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 Mon Mar 14 18:27:43 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F329712D83B for ; Mon, 14 Mar 2016 18:27:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 t0JBo3X4v_ID for ; Mon, 14 Mar 2016 18:27:40 -0700 (PDT) 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 A1B3712D57C for ; Mon, 14 Mar 2016 18:27:39 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CGA03385; Tue, 15 Mar 2016 01:27:37 +0000 (GMT) Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml705-cah.china.huawei.com (10.201.5.168) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 15 Mar 2016 01:27:36 +0000 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.56]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0235.001; Tue, 15 Mar 2016 09:27:28 +0800 From: Haoweiguo To: Lucy yong , "Dongjie (Jimmy)" , Susan Hares , "idr@ietf.org" Thread-Topic: [Idr] ??: WG Work item call - Opinions on work items (3/5/2016 to 3/17/2016) and adoption of draft-hares-idr-flowspec-combo-01.txt Thread-Index: AQHRfiCuRQ9G7jXD9UaABi7gYSPm5p9ZtuK3 Date: Tue, 15 Mar 2016 01:27:28 +0000 Message-ID: References: <000b01d17731$29d17230$7d745690$@ndzh.com> <76CD132C3ADEF848BD84D028D243C92774E3EF6C@NKGEML515-MBX.china.huawei.com>, <2691CE0099834E4A9C5044EEC662BB9D5725FB7A@dfweml501-mbs> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D5725FB7A@dfweml501-mbs> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.135.23.94] Content-Type: multipart/alternative; boundary="_000_DD5FC8DE455C3348B94340C0AB5517335029B363nkgeml513mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.56E7650A.0060, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.56, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: dfa475444e825431eaf4962e3a88600a Archived-At: Subject: Re: [Idr] ??: WG Work item call - Opinions on work items (3/5/2016 to 3/17/2016) and adoption of draft-hares-idr-flowspec-combo-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 01:27:43 -0000 --_000_DD5FC8DE455C3348B94340C0AB5517335029B363nkgeml513mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SSBhbHNvIGFncmVlIHdpdGggSmllJ3Mgc3VnZ2VzdGlvbi4NCndlaWd1bw0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCkZyb206IElkciBbaWRyLWJvdW5jZXNAaWV0Zi5vcmddIG9u IGJlaGFsZiBvZiBMdWN5IHlvbmcgW2x1Y3kueW9uZ0BodWF3ZWkuY29tXQ0KU2VudDogVHVlc2Rh eSwgTWFyY2ggMTUsIDIwMTYgMjozNw0KVG86IERvbmdqaWUgKEppbW15KTsgU3VzYW4gSGFyZXM7 IGlkckBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtJZHJdID8/OiBXRyBXb3JrIGl0ZW0gY2FsbCAt IE9waW5pb25zIG9uIHdvcmsgaXRlbXMgKDMvNS8yMDE2IHRvIDMvMTcvMjAxNikgYW5kIGFkb3B0 aW9uIG9mIGRyYWZ0LWhhcmVzLWlkci1mbG93c3BlYy1jb21iby0wMS50eHQNCg0Kc3VwcG9ydCBK aWWhr3Mgc3VnZ2VzdGlvbi4NCg0KTHVjeQ0KDQpGcm9tOiBJZHIgW21haWx0bzppZHItYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIERvbmdqaWUgKEppbW15KQ0KU2VudDogTW9uZGF5LCBN YXJjaCAxNCwgMjAxNiAxMDo0NiBBTQ0KVG86IFN1c2FuIEhhcmVzOyBpZHJAaWV0Zi5vcmcNClN1 YmplY3Q6IFtJZHJdID8/OiBXRyBXb3JrIGl0ZW0gY2FsbCAtIE9waW5pb25zIG9uIHdvcmsgaXRl bXMgKDMvNS8yMDE2IHRvIDMvMTcvMjAxNikgYW5kIGFkb3B0aW9uIG9mIGRyYWZ0LWhhcmVzLWlk ci1mbG93c3BlYy1jb21iby0wMS50eHQNCg0KSGksDQoNCklNTyBpbiBzaG9ydCB0ZXJtIHdlIG5l ZWQgdG8gd29yayBvbiBvcHRpb24xLCBpbiB3aGljaCBvcmRlcmluZyBhbmQgY29tYmluYXRpb24g cnVsZXMgbmVlZCB0byBiZSBzcGVjaWZpZWQuDQoNCkFzIGZvciBvcHRpb24gMiwgd2UgbWF5IG5l ZWQgdG8gdGFrZSB0aGUgY2hhcmFjdGVyaXN0aWNzIG9mIEJHUCBpbnRvIGNvbnNpZGVyYXRpb24g YW5kIGlkZW50aWZ5IHRoZSBhcHByb3ByaWF0ZSB1c2UgY2FzZXMgZm9yIEJHUC1GUywgdGhlbiBt YWtlIHRoZSBwcm90b2NvbCBleHRlbnNpb24gYWNjb3JkaW5nbHkuDQoNCkJlc3QgcmVnYXJkcywN CkppZQ0KDQq3orz+yMs6IElkciBbbWFpbHRvOmlkci1ib3VuY2VzQGlldGYub3JnXSC0+rHtIFN1 c2FuIEhhcmVzDQq3osvNyrG85DogMjAxNsTqM9TCNsjVIDY6NDkNCsrVvP7IyzogaWRyQGlldGYu b3JnPG1haWx0bzppZHJAaWV0Zi5vcmc+DQrW98ziOiBbSWRyXSBXRyBXb3JrIGl0ZW0gY2FsbCAt IE9waW5pb25zIG9uIHdvcmsgaXRlbXMgKDMvNS8yMDE2IHRvIDMvMTcvMjAxNikgYW5kIGFkb3B0 aW9uIG9mIGRyYWZ0LWhhcmVzLWlkci1mbG93c3BlYy1jb21iby0wMS50eHQNCg0KVGhlIGludGVy aW0gb24gMy83LzIwMTYgd2lsbCBoYXZlIGEgZGlzY3Vzc2lvbiBvZiByZXZpc2lvbnMgdG8gdGhl IEJHUCBGbG93IHNwZWNpZmljYXRpb24gKEJHUC1GUykgdG8gYWRkIG1vcmUgZmVhdHVyZXMuICBU aGVyZSBhcmUgdHdvIHN1Z2dlc3RlZCBvcHRpb25zOg0KDQoNCjEpICAgICAgQSBtaW5pbWFsIGZl YXR1cmVzIHRvIGV4aXN0aW5nIEJHUC1GUyAob3B0aW9uIDEpDQoNCkFkZCBhIGZldyBuZXcgbWF0 Y2ggZmlsdGVycyB0byB0aGUgQkdQLUZTIE5MUkkgYW5kIGZldyBuZXcgYWN0aW9ucyB0byB0aGUg QkdQLUZTIGFjdGlvbnMgKGluIEV4dGVuZGVkIGNvbW11bml0aWVzKS4gIEFjdGlvbnMgd291bGQg bmVlZCB0byBiZSBkb25lIGluIGEgZGVmaW5lZCBvcmRlci4gRWFjaCBuZXcgYWN0aW9ucyB3b3Vs ZCBuZWVkIHRvIGRlZmluZSBjb25mbGljdHMgd2l0aCBleGlzdGluZyBhY3Rpb25zLg0KDQoNCg0K QmVzdCB1c2UgY2FzZTogIERvUyBhdHRhY2sgcHJldmVudGlvbg0KDQoNCg0KMikgICAgICBDcmVh dGUgYSBCR1AtRlMgdmVyc2lvbiAyIChvcHRpb24gMikNCg0KQ3JlYXRlIGEgbmV3IEJHUC1GUyBO TFJJICh2Mikgd2l0aCBhIGZpZWxkIHRoYXQgaW5kaWNhdGVzIHRoZSBvcmRlcmluZyBvZiB0aGUg QkdQIE5MUkkuICBBZGQgbmV3IEJHUC1GUyBhY3Rpb25zIHdpdGggYW4gb3JkZXIgZmllbGQgaW4g dGhlIEJHUCBXaWRlIENvbW11bml0aWVzLiAgRmlsdGVycyBhcmUgZG9uZSBpbiB0aGUgb3JkZXIg ZGVmaW5lZCBpbiB0aGUgZmlsdGVyLiAgQWN0aW9ucyBhcmUgZG9uZSBpbiB0aGUgb3JkZXIgZGVm aW5lZCBpbiB0aGUgYWN0aW9ucy4gICBPcmRlciBudW1iZXJzIHRoYXQgdGllIGFyZSBoYW5kbGVk IGluIGEgZGVmaW5lZCBvcmRlci4NCg0KDQoNCkJlc3QgdXNlIGNhc2U6IFNETi9ORlYgZmlsdGVy IG1hbmFnZW1lbnQNCg0KQSB3cml0ZS11cCBvbiB0aGUgaXNzdWVzIGFuZCBwcm9wb3NlZCBzb2x1 dGlvbnMgaXMgY29udGFpbmVkIGluOg0KZHJhZnQtaGFyZXMtaWRyLWZsb3dzcGVjLWNvbWJvLTAx LnR4dC4gPGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWhhcmVzLWlkci1m bG93c3BlYy1jb21iby8+ICAgIFRoZSBXRyBjYW4gc2VsZWN0IGJvdGggb3B0aW9uIDEgYW5kIG9w dGlvbiAyLiAgVGhpcyBpcyBhIFdHIHdvcmsgaXRlbSBjYWxsIGZvciBpbnB1dCB0byB0aGUgY2hh aXJzIG9uIHRoZSBzY29wZSBvZiB0aGUgV0cgaXRlbS4gIEluIHlvdSBkaXNjdXNzaW9uIG9mIHRo aXMgdG9waWNzLCB0aGUgY2hhaXJzIHdvdWxkIGFwcHJlY2lhdGUgaWYgeW91IHdvdWxkIGluZGlj YXRlIGlmIHlvdSB3b3VsZCBzdXBwb3J0IElEUiB3b3JraW5nIG9uIG9wdGlvbiAxLCBvcHRpb24g MiBvciBib3RoIG9wdGlvbiAxIGFuZCAyLiAgVGhpcyBXRyBjYWxsIGl0ZW1zIGFsc28gaW5jbHVk ZXMgYSBjYWxsIGZvciBkcmFmdC1oYXJlcy1pZHItZmxvd3NwZWMtY29tYm8tMDEudHh0IGFzIGEg d3JpdGUtdXAgb2YgdGhlIHdvcmstaXRlbSBvcHRpb25zLiAgVGhlIFdHIG1heSB3aXNoIHRvIHNw bGl0IHRoaXMgZHJhZnQgaW50byBtdWx0aXBsZSBkcmFmdHMuDQoNClRoZSBmb2xsb3dpbmcgZHJh ZnRzIGFyZSBiZWluZyBjb25zaWRlciBmb3IgZWl0aGVyIG9wdGlvbjoNCg0KMSkgICAgICBkcmFm dC1lZGR5LWlkci1mbG93c3BlYy1wYWNrZXQtcmF0ZQ0KDQoyKSAgICAgIGRyYWZ0LWhhby1pZHIt Zmxvd3NwZWMtbnYwMw0KDQozKSAgICAgIGRyYWZ0LWhhby1pZHItZmxvd3NwZWMtbGFiZWwNCg0K NCkgICAgICBkcmFmdC1saWFuZy1pZHItYmdwLWZsb3dzcGVjLXRpbWUNCg0KNSkgICAgICBkcmFm dC1saXRvd3NraS1pZHItZmxvd3NwZWMtaW50ZXJmYWNlc2V0DQoNCjYpICAgICAgZHJhZnQtdmFu ZGV2ZWxkZS1pZHItZmxvd3NwZWMtcGF0aC1yZWRpcmVjdA0KDQo3KSAgICAgIGRyYWZ0LWxpLWlk ci1mbG93c3BlYy1ycGQtMDEudHh0DQoNCjgpICAgICAgZHJhZnQtd3UtaWRyLWZsb3dzcGVjLXlh bmcuY2ZnLg0KDQpJZiB5b3Ugd2lzaCB0byBjb21tZW50IG9uIGFueSBvZiB0aGVzZSBkcmFmdHMs IHdlIHdpbGwNCg0KV2Ugd2lsbCBjb25jbHVkZSB0aGUgQ2FsbCBmb3IgV0cgb3BpbmlvbnMgb24g My8xNy8yMDE2IHNvIHRoZXNlIGF1dGhvcnMgY2FuIGhhdmUgYSBkYXkgdG8gcmV2aXNlIGFuZCBz dWJtaXQgdGhlaXIgZHJhZnRzIGJlZm9yZSB0aGUgZHJhZnQgZGVhZGxpbmUuDQoNClN1ZSBIYXJl cyBhbmQgSm9obiBTY3VkZGVyDQoNClBTOg0KZHJhZnQtbGktaWRyLWZsb3dzcGVjLXJwZCBkaXNj dXNzZXMgbGltaXRzIG9uIHRoZSBkaXN0cmlidXRpb24gb2YgdGhlIHBvbGljeSB3aGljaCBoYXMg YmVlbiByZWNhc3QgaW4gZHJhZnQtaGFyZXMtaWRyLWZsb3dzcGVjLWNvbWJvIGFzIGEgYmdwLXdp ZGUgY29tbXVuaXR5IG9mIENvbnRhaW5lciB0eXBlIDEgd2l0aCBhbiBhdG9tIG9mIEJHUCBGbG93 IFNwZWNpZmljYXRpb24gb3JkZXJpbmcuIEhvd2V2ZXIsICB0aGlzIGRyYWZ0IGlzIGluY2x1ZGVk IGluIHRoZSBsaXN0IHRvIGJlIGFibGUgdG8gdXBkYXRlIHRoZSBtZWNoYW5pc20gZnJvbSB0aGlz IGRyYWZ0IGludG8gdGhhdCBjb250ZXh0Lg0KDQpUaGUgeWFuZyBtb2RlbCBmb3IgQkdQIEZsb3cg c3BlY2lmaWNhdGlvbiBpcyBhbHNvIGluY2x1ZGVkIGluIHRoaXMgd29yayBpdGVtIGFzIGl0IHdp bGwgbmVlZCB0byBiZSBtb2RpZmllZCBiYXNlZCBvbiB0aGUgYXBwcm9hY2hlcy4gIFRoZSB5YW5n IG1vZGVsIGlzIGluIGRyYWZ0LXd1LWlkci1mbG93c3BlYy15YW5nLWNmZy4gIEluIHlvdXIgY29t bWVudHMsIHBsZWFzZSBpbmRpY2F0ZSBpZiB5b3UgZmVlbCB0aGVzZSBkcmFmdHMgb3Igb3RoZXIg ZHJhZnRzLg0KDQo= --_000_DD5FC8DE455C3348B94340C0AB5517335029B363nkgeml513mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
I also agree with Jie's su= ggestion.
weiguo
From: Idr [idr-bounces@ietf.org] on behal= f of Lucy yong [lucy.yong@huawei.com]
Sent: Tuesday, March 15, 2016 2:37
To: Dongjie (Jimmy); Susan Hares; idr@ietf.org
Subject: Re: [Idr] ??: WG Work item call - Opinions on work items (3= /5/2016 to 3/17/2016) and adoption of draft-hares-idr-flowspec-combo-01.txt=

support Jie=A1=AFs = suggestion.

 

Lucy

 

From: Idr [m= ailto:idr-bounces@ietf.org] On Behalf Of Dongjie (Jimmy)
Sent: Monday, March 14, 2016 10:46 AM
To: Susan Hares; idr@ietf.org
Subject: [Idr] ??: WG Work item call - Opinions on work items (3/5/2= 016 to 3/17/2016) and adoption of draft-hares-idr-flowspec-combo-01.txt

 

Hi, =

&nbs= p;

IMO = in short term we need to work on option1, in which ordering and combination= rules need to be specified.

&nbs= p;

As f= or option 2, we may need to take the characteristics of BGP into considerat= ion and identify the appropriate use cases for BGP-FS, then make the protoc= ol extension accordingly.

&nbs= p;

Best= regards,

Jie<= /span>

&nbs= p;

=B7=A2=BC=FE=C8=CB: Idr [mailto:idr-bounces@ietf.org] =B4=FA=B1=ED Susan Hares=
=B7=A2=CB=CD=CA=B1=BC=E4: 2016=C4=EA3=D4=C26= =C8=D5 6:49
=CA=D5=BC=FE=C8=CB: idr@ietf.org
=D6=F7=CC=E2: [I= dr] WG Work item call - Opinions on work items (3/5/2016 to 3/17/2016) and adoption of draft-hares-idr-flowspec-combo-01.txt=

 

The interim on 3/7/2016 will have a discussion of re= visions to the BGP Flow specification (BGP-FS) to add more features.  = There are two suggested options:

 

1)   = ;   A minimal features to existing BGP-FS (option 1)

Add a few new match filters to the BGP-FS NLR= I and few new actions to the BGP-FS actions (in Extended communities). &nbs= p;Actions would need to be done in a defined order. Each new actions would = need to define conflicts with existing actions.   

 

Best use case:  DoS attack prevention

 

2)   = ;   Create a BGP-FS version 2 (option 2)

Create a new BGP-FS NLRI (v2) with a field th= at indicates the ordering of the BGP NLRI.  Add new BGP-FS actions wit= h an order field in the BGP Wide Communities.  Filters are done in the= order defined in the filter.  Actions are done in the order defined in the actions.   Order numbers that tie ar= e handled in a defined order.

 

Best use case: SDN/NFV filter management

 

A write-up on the issues and proposed solutions is c= ontained in:

draft-hares-idr-flowspec-combo-0= 1.txt.    The WG can select both option 1 and option 2.  T= his is a WG work item call for input to the chairs on the scope of the WG i= tem.  In you discussion of this topics, the chairs would appreciate if= you would indicate if you would support IDR working on option 1, option 2 or both option 1 and 2.  This WG call items also includes= a call for draft-hares-idr-flowspec-combo-01.txt as a write-up of the work= -item options.  The WG may wish to split this draft into multiple draf= ts.

 

The following drafts are being consider for either o= ption:

1)   = ;   draft-eddy-idr-flowspec-packet-rate

2)   = ;   draft-hao-idr-flowspec-nv03

3)   = ;   draft-hao-idr-flowspec-label

4)   = ;   draft-liang-idr-bgp-flowspec-time

5)   = ;   draft-litowski-idr-flowspec-interfaceset

6)   = ;   draft-vandevelde-idr-flowspec-path-redirect

7)   = ;   draft-li-idr-flowspec-rpd-01.txt

8)   = ;   draft-wu-idr-flowspec-yang.cfg.

 

If you wish to comment on any of these drafts, we wi= ll

 

We will conclude the Call for WG opinions on 3/17/20= 16 so these authors can have a day to revise and submit their drafts before= the draft deadline.

 

Sue Hares and John Scudder

 

PS:

draft-li-idr-flowspec-rpd discusses limits on the di= stribution of the policy which has been recast in draft-hares-idr-flowspec-= combo as a bgp-wide community of Container type 1 with an atom of BGP Flow = Specification ordering. However,  this draft is included in the list to be able to update the mechanism from= this draft into that context.  

 

The yang model for BGP Flow specification is also in= cluded in this work item as it will need to be modified based on the approa= ches.  The yang model is in draft-wu-idr-flowspec-yang-cfg.  In y= our comments, please indicate if you feel these drafts or other drafts. 

 

--_000_DD5FC8DE455C3348B94340C0AB5517335029B363nkgeml513mbxchi_-- From nobody Mon Mar 14 18:58:00 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB5B312D5C0 for ; Mon, 14 Mar 2016 18:57:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 NQ1zaqzMcveN for ; Mon, 14 Mar 2016 18:57:56 -0700 (PDT) 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 6AA8A12D679 for ; Mon, 14 Mar 2016 18:57:55 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CGA05045; Tue, 15 Mar 2016 01:57:53 +0000 (GMT) Received: from DFWEML706-CHM.china.huawei.com (10.193.5.225) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 15 Mar 2016 01:57:52 +0000 Received: from DFWEML501-MBS.china.huawei.com ([10.193.5.222]) by dfweml706-chm ([10.193.5.225]) with mapi id 14.03.0235.001; Mon, 14 Mar 2016 18:57:43 -0700 From: Linda Dunbar To: Lucy yong , "Dongjie (Jimmy)" , Susan Hares , "idr@ietf.org" Thread-Topic: [Idr] ??: WG Work item call - Opinions on work items (3/5/2016 to 3/17/2016) and adoption of draft-hares-idr-flowspec-combo-01.txt Thread-Index: AQHRfiCyfCtp6JGAvka7/CdZeD+5gp9Zv9NA Date: Tue, 15 Mar 2016 01:57:43 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657E37AE1@dfweml501-mbs> References: <000b01d17731$29d17230$7d745690$@ndzh.com> <76CD132C3ADEF848BD84D028D243C92774E3EF6C@NKGEML515-MBX.china.huawei.com> <2691CE0099834E4A9C5044EEC662BB9D5725FB7A@dfweml501-mbs> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D5725FB7A@dfweml501-mbs> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.153.46] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657E37AE1dfweml501mbs_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.56E76C21.0103, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: dfa475444e825431eaf4962e3a88600a Archived-At: Subject: Re: [Idr] ??: WG Work item call - Opinions on work items (3/5/2016 to 3/17/2016) and adoption of draft-hares-idr-flowspec-combo-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 01:57:59 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F657E37AE1dfweml501mbs_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 KzEuDQoNCkxpbmRhDQoNCkZyb206IElkciBbbWFpbHRvOmlkci1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YgTHVjeSB5b25nDQpTZW50OiBNb25kYXksIE1hcmNoIDE0LCAyMDE2IDE6Mzgg UE0NClRvOiBEb25namllIChKaW1teSk7IFN1c2FuIEhhcmVzOyBpZHJAaWV0Zi5vcmcNClN1Ympl Y3Q6IFJlOiBbSWRyXSA/PzogV0cgV29yayBpdGVtIGNhbGwgLSBPcGluaW9ucyBvbiB3b3JrIGl0 ZW1zICgzLzUvMjAxNiB0byAzLzE3LzIwMTYpIGFuZCBhZG9wdGlvbiBvZiBkcmFmdC1oYXJlcy1p ZHItZmxvd3NwZWMtY29tYm8tMDEudHh0DQoNCnN1cHBvcnQgSmlloa9zIHN1Z2dlc3Rpb24uDQoN Ckx1Y3kNCg0KRnJvbTogSWRyIFttYWlsdG86aWRyLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBEb25namllIChKaW1teSkNClNlbnQ6IE1vbmRheSwgTWFyY2ggMTQsIDIwMTYgMTA6NDYg QU0NClRvOiBTdXNhbiBIYXJlczsgaWRyQGlldGYub3JnPG1haWx0bzppZHJAaWV0Zi5vcmc+DQpT dWJqZWN0OiBbSWRyXSA/PzogV0cgV29yayBpdGVtIGNhbGwgLSBPcGluaW9ucyBvbiB3b3JrIGl0 ZW1zICgzLzUvMjAxNiB0byAzLzE3LzIwMTYpIGFuZCBhZG9wdGlvbiBvZiBkcmFmdC1oYXJlcy1p ZHItZmxvd3NwZWMtY29tYm8tMDEudHh0DQoNCkhpLA0KDQpJTU8gaW4gc2hvcnQgdGVybSB3ZSBu ZWVkIHRvIHdvcmsgb24gb3B0aW9uMSwgaW4gd2hpY2ggb3JkZXJpbmcgYW5kIGNvbWJpbmF0aW9u IHJ1bGVzIG5lZWQgdG8gYmUgc3BlY2lmaWVkLg0KDQpBcyBmb3Igb3B0aW9uIDIsIHdlIG1heSBu ZWVkIHRvIHRha2UgdGhlIGNoYXJhY3RlcmlzdGljcyBvZiBCR1AgaW50byBjb25zaWRlcmF0aW9u IGFuZCBpZGVudGlmeSB0aGUgYXBwcm9wcmlhdGUgdXNlIGNhc2VzIGZvciBCR1AtRlMsIHRoZW4g bWFrZSB0aGUgcHJvdG9jb2wgZXh0ZW5zaW9uIGFjY29yZGluZ2x5Lg0KDQpCZXN0IHJlZ2FyZHMs DQpKaWUNCg0Kt6K8/sjLOiBJZHIgW21haWx0bzppZHItYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBT dXNhbiBIYXJlcw0Kt6LLzcqxvOQ6IDIwMTbE6jPUwjbI1SA2OjQ5DQrK1bz+yMs6IGlkckBpZXRm Lm9yZzxtYWlsdG86aWRyQGlldGYub3JnPg0K1vfM4jogW0lkcl0gV0cgV29yayBpdGVtIGNhbGwg LSBPcGluaW9ucyBvbiB3b3JrIGl0ZW1zICgzLzUvMjAxNiB0byAzLzE3LzIwMTYpIGFuZCBhZG9w dGlvbiBvZiBkcmFmdC1oYXJlcy1pZHItZmxvd3NwZWMtY29tYm8tMDEudHh0DQoNClRoZSBpbnRl cmltIG9uIDMvNy8yMDE2IHdpbGwgaGF2ZSBhIGRpc2N1c3Npb24gb2YgcmV2aXNpb25zIHRvIHRo ZSBCR1AgRmxvdyBzcGVjaWZpY2F0aW9uIChCR1AtRlMpIHRvIGFkZCBtb3JlIGZlYXR1cmVzLiAg VGhlcmUgYXJlIHR3byBzdWdnZXN0ZWQgb3B0aW9uczoNCg0KDQoxKSAgICAgIEEgbWluaW1hbCBm ZWF0dXJlcyB0byBleGlzdGluZyBCR1AtRlMgKG9wdGlvbiAxKQ0KDQpBZGQgYSBmZXcgbmV3IG1h dGNoIGZpbHRlcnMgdG8gdGhlIEJHUC1GUyBOTFJJIGFuZCBmZXcgbmV3IGFjdGlvbnMgdG8gdGhl IEJHUC1GUyBhY3Rpb25zIChpbiBFeHRlbmRlZCBjb21tdW5pdGllcykuICBBY3Rpb25zIHdvdWxk IG5lZWQgdG8gYmUgZG9uZSBpbiBhIGRlZmluZWQgb3JkZXIuIEVhY2ggbmV3IGFjdGlvbnMgd291 bGQgbmVlZCB0byBkZWZpbmUgY29uZmxpY3RzIHdpdGggZXhpc3RpbmcgYWN0aW9ucy4NCg0KDQoN CkJlc3QgdXNlIGNhc2U6ICBEb1MgYXR0YWNrIHByZXZlbnRpb24NCg0KDQoNCjIpICAgICAgQ3Jl YXRlIGEgQkdQLUZTIHZlcnNpb24gMiAob3B0aW9uIDIpDQoNCkNyZWF0ZSBhIG5ldyBCR1AtRlMg TkxSSSAodjIpIHdpdGggYSBmaWVsZCB0aGF0IGluZGljYXRlcyB0aGUgb3JkZXJpbmcgb2YgdGhl IEJHUCBOTFJJLiAgQWRkIG5ldyBCR1AtRlMgYWN0aW9ucyB3aXRoIGFuIG9yZGVyIGZpZWxkIGlu IHRoZSBCR1AgV2lkZSBDb21tdW5pdGllcy4gIEZpbHRlcnMgYXJlIGRvbmUgaW4gdGhlIG9yZGVy IGRlZmluZWQgaW4gdGhlIGZpbHRlci4gIEFjdGlvbnMgYXJlIGRvbmUgaW4gdGhlIG9yZGVyIGRl ZmluZWQgaW4gdGhlIGFjdGlvbnMuICAgT3JkZXIgbnVtYmVycyB0aGF0IHRpZSBhcmUgaGFuZGxl ZCBpbiBhIGRlZmluZWQgb3JkZXIuDQoNCg0KDQpCZXN0IHVzZSBjYXNlOiBTRE4vTkZWIGZpbHRl ciBtYW5hZ2VtZW50DQoNCkEgd3JpdGUtdXAgb24gdGhlIGlzc3VlcyBhbmQgcHJvcG9zZWQgc29s dXRpb25zIGlzIGNvbnRhaW5lZCBpbjoNCmRyYWZ0LWhhcmVzLWlkci1mbG93c3BlYy1jb21iby0w MS50eHQuIDxodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1oYXJlcy1pZHIt Zmxvd3NwZWMtY29tYm8vPiAgICBUaGUgV0cgY2FuIHNlbGVjdCBib3RoIG9wdGlvbiAxIGFuZCBv cHRpb24gMi4gIFRoaXMgaXMgYSBXRyB3b3JrIGl0ZW0gY2FsbCBmb3IgaW5wdXQgdG8gdGhlIGNo YWlycyBvbiB0aGUgc2NvcGUgb2YgdGhlIFdHIGl0ZW0uICBJbiB5b3UgZGlzY3Vzc2lvbiBvZiB0 aGlzIHRvcGljcywgdGhlIGNoYWlycyB3b3VsZCBhcHByZWNpYXRlIGlmIHlvdSB3b3VsZCBpbmRp Y2F0ZSBpZiB5b3Ugd291bGQgc3VwcG9ydCBJRFIgd29ya2luZyBvbiBvcHRpb24gMSwgb3B0aW9u IDIgb3IgYm90aCBvcHRpb24gMSBhbmQgMi4gIFRoaXMgV0cgY2FsbCBpdGVtcyBhbHNvIGluY2x1 ZGVzIGEgY2FsbCBmb3IgZHJhZnQtaGFyZXMtaWRyLWZsb3dzcGVjLWNvbWJvLTAxLnR4dCBhcyBh IHdyaXRlLXVwIG9mIHRoZSB3b3JrLWl0ZW0gb3B0aW9ucy4gIFRoZSBXRyBtYXkgd2lzaCB0byBz cGxpdCB0aGlzIGRyYWZ0IGludG8gbXVsdGlwbGUgZHJhZnRzLg0KDQpUaGUgZm9sbG93aW5nIGRy YWZ0cyBhcmUgYmVpbmcgY29uc2lkZXIgZm9yIGVpdGhlciBvcHRpb246DQoNCjEpICAgICAgZHJh ZnQtZWRkeS1pZHItZmxvd3NwZWMtcGFja2V0LXJhdGUNCg0KMikgICAgICBkcmFmdC1oYW8taWRy LWZsb3dzcGVjLW52MDMNCg0KMykgICAgICBkcmFmdC1oYW8taWRyLWZsb3dzcGVjLWxhYmVsDQoN CjQpICAgICAgZHJhZnQtbGlhbmctaWRyLWJncC1mbG93c3BlYy10aW1lDQoNCjUpICAgICAgZHJh ZnQtbGl0b3dza2ktaWRyLWZsb3dzcGVjLWludGVyZmFjZXNldA0KDQo2KSAgICAgIGRyYWZ0LXZh bmRldmVsZGUtaWRyLWZsb3dzcGVjLXBhdGgtcmVkaXJlY3QNCg0KNykgICAgICBkcmFmdC1saS1p ZHItZmxvd3NwZWMtcnBkLTAxLnR4dA0KDQo4KSAgICAgIGRyYWZ0LXd1LWlkci1mbG93c3BlYy15 YW5nLmNmZy4NCg0KSWYgeW91IHdpc2ggdG8gY29tbWVudCBvbiBhbnkgb2YgdGhlc2UgZHJhZnRz LCB3ZSB3aWxsDQoNCldlIHdpbGwgY29uY2x1ZGUgdGhlIENhbGwgZm9yIFdHIG9waW5pb25zIG9u IDMvMTcvMjAxNiBzbyB0aGVzZSBhdXRob3JzIGNhbiBoYXZlIGEgZGF5IHRvIHJldmlzZSBhbmQg c3VibWl0IHRoZWlyIGRyYWZ0cyBiZWZvcmUgdGhlIGRyYWZ0IGRlYWRsaW5lLg0KDQpTdWUgSGFy ZXMgYW5kIEpvaG4gU2N1ZGRlcg0KDQpQUzoNCmRyYWZ0LWxpLWlkci1mbG93c3BlYy1ycGQgZGlz Y3Vzc2VzIGxpbWl0cyBvbiB0aGUgZGlzdHJpYnV0aW9uIG9mIHRoZSBwb2xpY3kgd2hpY2ggaGFz IGJlZW4gcmVjYXN0IGluIGRyYWZ0LWhhcmVzLWlkci1mbG93c3BlYy1jb21ibyBhcyBhIGJncC13 aWRlIGNvbW11bml0eSBvZiBDb250YWluZXIgdHlwZSAxIHdpdGggYW4gYXRvbSBvZiBCR1AgRmxv dyBTcGVjaWZpY2F0aW9uIG9yZGVyaW5nLiBIb3dldmVyLCAgdGhpcyBkcmFmdCBpcyBpbmNsdWRl ZCBpbiB0aGUgbGlzdCB0byBiZSBhYmxlIHRvIHVwZGF0ZSB0aGUgbWVjaGFuaXNtIGZyb20gdGhp cyBkcmFmdCBpbnRvIHRoYXQgY29udGV4dC4NCg0KVGhlIHlhbmcgbW9kZWwgZm9yIEJHUCBGbG93 IHNwZWNpZmljYXRpb24gaXMgYWxzbyBpbmNsdWRlZCBpbiB0aGlzIHdvcmsgaXRlbSBhcyBpdCB3 aWxsIG5lZWQgdG8gYmUgbW9kaWZpZWQgYmFzZWQgb24gdGhlIGFwcHJvYWNoZXMuICBUaGUgeWFu ZyBtb2RlbCBpcyBpbiBkcmFmdC13dS1pZHItZmxvd3NwZWMteWFuZy1jZmcuICBJbiB5b3VyIGNv bW1lbnRzLCBwbGVhc2UgaW5kaWNhdGUgaWYgeW91IGZlZWwgdGhlc2UgZHJhZnRzIG9yIG90aGVy IGRyYWZ0cy4NCg0K --_000_4A95BA014132FF49AE685FAB4B9F17F657E37AE1dfweml501mbs_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

+1.

 

Linda

 

From: Idr [mai= lto:idr-bounces@ietf.org] On Behalf Of Lucy yong
Sent: Monday, March 14, 2016 1:38 PM
To: Dongjie (Jimmy); Susan Hares; idr@ietf.org
Subject: Re: [Idr] ??: WG Work item call - Opinions on work items (3= /5/2016 to 3/17/2016) and adoption of draft-hares-idr-flowspec-combo-01.txt=

 

support Jie=A1=AFs = suggestion.

 

Lucy

 

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Dongjie (Jimmy)
Sent: Monday, March 14, 2016 10:46 AM
To: Susan Hares; idr@ietf.org Subject: [Idr] ??: WG Work item call - Opinions on work items (3/5/2= 016 to 3/17/2016) and adoption of draft-hares-idr-flowspec-combo-01.txt

 

Hi, <= o:p>

=  

IMO i= n short term we need to work on option1, in which ordering and combination = rules need to be specified.

=  

As fo= r option 2, we may need to take the characteristics of BGP into considerati= on and identify the appropriate use cases for BGP-FS, then make the protoco= l extension accordingly.

=  

Best = regards,

Jie

=  

=B7=A2=BC=FE=C8=CB: Idr [mailto:idr-bo= unces@ietf.org] =B4=FA=B1=ED Susan Hares
=B7=A2=CB=CD=CA=B1=BC=E4: 2016=C4=EA3=D4=C26=C8=D5 6:49
=CA=D5=BC=FE=C8=CB: idr@ietf.org
=D6=F7=CC=E2: [Idr] WG Work item call - = Opinions on work items (3/5/2016 to 3/17/2016) and adoption of draft-hares-= idr-flowspec-combo-01.txt

 

The interim on 3/7/2016 will have a discussion of re= visions to the BGP Flow specification (BGP-FS) to add more features.  = There are two suggested options:

 

1)      A minimal features to existing BGP-FS (option 1)

Add a few new match filters to the BGP-FS NLR= I and few new actions to the BGP-FS actions (in Extended communities). &nbs= p;Actions would need to be done in a defined order. Each new actions would = need to define conflicts with existing actions.   

 

Best use case:  DoS attack prevention

 

2)      Create a BGP-FS version 2 (option 2)

Create a new BGP-FS NLRI (v2) with a field th= at indicates the ordering of the BGP NLRI.  Add new BGP-FS actions wit= h an order field in the BGP Wide Communities.  Filters are done in the= order defined in the filter.  Actions are done in the order defined in the actions.   Order numbers that tie ar= e handled in a defined order.

 

Best use case: SDN/NFV filter management

 

A write-up on the issues and proposed solutions is c= ontained in:

draft-hares-idr-flowspec-combo-01.txt.    The WG can select both option 1 and option 2.  T= his is a WG work item call for input to the chairs on the scope of the WG i= tem.  In you discussion of this topics, the chairs would appreciate if= you would indicate if you would support IDR working on option 1, option 2 or both option 1 and 2.  This WG call items also includes= a call for draft-hares-idr-flowspec-combo-01.txt as a write-up of the work= -item options.  The WG may wish to split this draft into multiple draf= ts.

 

The following drafts are being consider for either o= ption:

1)      draft-eddy-idr-flowspec-packet-rate

2)      draft-hao-idr-flowspec-nv03

3)      draft-hao-idr-flowspec-label

4)      draft-liang-idr-bgp-flowspec-time

5)      draft-litowski-idr-flowspec-interfaceset

6)      draft-vandevelde-idr-flowspec-path-redirect

7)      draft-li-idr-flowspec-rpd-01.txt

8)      draft-wu-idr-flowspec-yang.cfg.

 

If you wish to comment on any of these drafts, we wi= ll

 

We will conclude the Call for WG opinions on 3/17/20= 16 so these authors can have a day to revise and submit their drafts before= the draft deadline.

 

Sue Hares and John Scudder

 

PS:

draft-li-idr-flowspec-rpd discusses limits on the di= stribution of the policy which has been recast in draft-hares-idr-flowspec-= combo as a bgp-wide community of Container type 1 with an atom of BGP Flow = Specification ordering. However,  this draft is included in the list to be able to update the mechanism from= this draft into that context.  

 

The yang model for BGP Flow specification is also in= cluded in this work item as it will need to be modified based on the approa= ches.  The yang model is in draft-wu-idr-flowspec-yang-cfg.  In y= our comments, please indicate if you feel these drafts or other drafts. 

 

--_000_4A95BA014132FF49AE685FAB4B9F17F657E37AE1dfweml501mbs_-- From nobody Mon Mar 14 20:28:27 2016 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 EA24912D570; Mon, 14 Mar 2016 20:28:22 -0700 (PDT) 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.16.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160315032822.16795.73974.idtracker@ietfa.amsl.com> Date: Mon, 14 Mar 2016 20:28:22 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-route-leak-detection-mitigation-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 03:28:23 -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 of the IETF. Title : Methods for Detection and Mitigation of BGP Route Leaks Authors : Kotikalapudi Sriram Doug Montgomery Brian Dickson Keyur Patel Andrei Robachevsky Filename : draft-ietf-idr-route-leak-detection-mitigation-02.txt Pages : 19 Date : 2016-03-14 Abstract: In [I-D.ietf-grow-route-leak-problem-definition], the authors have provided a definition of the route leak problem, and also enumerated several types of route leaks. In this document, we first examine which of those route-leak types are detected and mitigated by the existing origin validation (OV) [RFC 6811]. It is recognized that OV offers a limited detection and mitigation capability against route leaks. This document proposes an enhancement that significantly extends the route-leak detection and mitigation capabilities of BGP. The solution involves carrying a per-hop route-leak protection (RLP) field in BGP updates. The RLP field is proposed be carried in an optional transitive path attribute. The solution is meant to be initially implemented as an enhancement of BGP without requiring BGPsec [I-D.ietf-sidr-bgpsec-protocol]. However, when BGPsec is deployed in the future, the solution can be incorporated in BGPsec, enabling cryptographic protection for the RLP field. That would be one way of implementing the proposed solution in a secure way. It is not claimed that the solution detects all possible types of route leaks but it detects several types, especially considering some significant route-leak occurrences that have been observed in recent years. The document also includes a stopgap method for detection and mitigation of route leaks for an intermediate phase when OV is deployed but BGP protocol on the wire is unchanged. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-route-leak-detection-mitigation/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-route-leak-detection-mitigation-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-route-leak-detection-mitigation-02 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 Mar 15 04:48:33 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A565112D998; Tue, 15 Mar 2016 04:48:30 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com 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 zGhQ1H0mXA76; Tue, 15 Mar 2016 04:48:28 -0700 (PDT) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0100.outbound.protection.outlook.com [23.103.200.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 900E712D511; Tue, 15 Mar 2016 04:48:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=09//Z5yXT0Z6ln8u8S7gRHjCQmbWU/uM6QoQvVIUNAA=; b=UUVwlvjLi5pbsy+RB3eiqw7xQCni6DxFaeClVfM5KvIklRYOBAIHVrldcm2dJjMcICss/DQzpZSifO+LBFsu+HjVYb1d5CHGg8/hSK+6lRabjFgruLKUjz4IVhLnRS/CKyZoYB9DixYvuWukljntWN+H1ZrOhBCVQcJTTqNMj3g= Received: from CY1PR09MB0793.namprd09.prod.outlook.com (10.163.43.143) by CY1PR09MB0796.namprd09.prod.outlook.com (10.163.43.146) with Microsoft SMTP Server (TLS) id 15.1.434.16; Tue, 15 Mar 2016 11:48:27 +0000 Received: from CY1PR09MB0793.namprd09.prod.outlook.com ([10.163.43.143]) by CY1PR09MB0793.namprd09.prod.outlook.com ([10.163.43.143]) with mapi id 15.01.0434.016; Tue, 15 Mar 2016 11:48:27 +0000 From: "Sriram, Kotikalapudi (Fed)" To: IDR , sidr wg list Thread-Topic: New Version Notification for draft-ietf-idr-route-leak-detection-mitigation-02.txt Thread-Index: AQHRfmq9jR1rsDByzU2rfNRIdonxmp9aYi5W Date: Tue, 15 Mar 2016 11:48:27 +0000 Message-ID: References: <20160315032823.16795.31687.idtracker@ietfa.amsl.com> In-Reply-To: <20160315032823.16795.31687.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nist.gov; x-originating-ip: [129.6.222.4] x-ms-office365-filtering-correlation-id: 0331b740-d91b-4031-5a58-08d34cc7b8f0 x-microsoft-exchange-diagnostics: 1; CY1PR09MB0796; 5:NkM5vrAY1HhbYQz1x/AiDp2eQ8rQLZ2e3essb2/jaRKrakUec5qEfUOhNsjZ5+j0bZd/np9HEw2M033ilIX3VtfDIuPMyjZELm+oPSnOtgKalH6VrcDY2yQoDH146qb/N7A//VGpLRt1i46SIdxmsg==; 24:jBryFVIJiy+VV+gkPw96ga5yN8UTYrd0rAtuLq983or/J9jy/17j8olNTStACJXovVk0fgx3ehB5hj7RqWZ1bU1mjkUTBtsSXF//Mmo4x8U= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR09MB0796; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:CY1PR09MB0796; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0796; x-forefront-prvs: 08828D20BC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(377424004)(1096002)(54356999)(5008740100001)(3846002)(2900100001)(15975445007)(74316001)(5004730100002)(11100500001)(230783001)(107886002)(50986999)(2950100001)(15650500001)(450100001)(10400500002)(102836003)(1220700001)(77096005)(6116002)(2906002)(76176999)(122556002)(586003)(81166005)(33656002)(106116001)(5001770100001)(3280700002)(76576001)(5003600100002)(87936001)(3660700001)(19580405001)(66066001)(3900700001)(5002640100001)(99286002)(92566002)(19580395003)(189998001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0796; H:CY1PR09MB0793.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Mar 2016 11:48:27.2927 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0796 Archived-At: Subject: [Idr] Fw: New Version Notification for draft-ietf-idr-route-leak-detection-mitigation-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 11:48:30 -0000 Cross posting this message on IDR and SIDR lists. This submission ( https://tools.ietf.org/html/draft-ietf-idr-route-leak-det= ection-mitigation-02 ) is an updated version and it reflects the following changes: 1. It is now synced up with the revised set of route-leak types in the lat= est definition draft [draft-ietf-grow-route-leak-problem-definition-04]. See: https://tools.ietf.org/html/draft-ietf-grow-route-leak-problem-definit= ion-04 =20 2. Thought it would be useful to comment on combining the results of route-leak detection, origin validation, and BGPsec (path) v= alidation (when BGPsec is used in the future) for path selection decision. Hence, added the new subsection 5.2 under =93Design Rationale and Discussio= n=94 section. 3. Made editorial changes throughout to improve clarity/presentation. 4. Section 5 continues to capture key comments, questions and discussion. Further comments/suggestions/critique welcome. Sriram =20 ________________________________________ From: internet-drafts@ietf.org Sent: Monday, March 14, 2016 11:28 PM To: Brian Dickson; Montgomery, Douglas (Fed); Keyur Patel; Andrei Robachevs= ky; Sriram, Kotikalapudi (Fed) Subject: New Version Notification for draft-ietf-idr-route-leak-detection-m= itigation-02.txt A new version of I-D, draft-ietf-idr-route-leak-detection-mitigation-02.txt has been successfully submitted by Kotikalapudi Sriram and posted to the IETF repository. Name: draft-ietf-idr-route-leak-detection-mitigation Revision: 02 Title: Methods for Detection and Mitigation of BGP Route Leaks Document date: 2016-03-14 Group: idr Pages: 19 URL: https://www.ietf.org/internet-drafts/draft-ietf-idr-route-l= eak-detection-mitigation-02.txt Status: https://datatracker.ietf.org/doc/draft-ietf-idr-route-leak-= detection-mitigation/ Htmlized: https://tools.ietf.org/html/draft-ietf-idr-route-leak-detec= tion-mitigation-02 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-route-le= ak-detection-mitigation-02 Abstract: In [I-D.ietf-grow-route-leak-problem-definition], the authors have provided a definition of the route leak problem, and also enumerated several types of route leaks. In this document, we first examine which of those route-leak types are detected and mitigated by the existing origin validation (OV) [RFC 6811]. It is recognized that OV offers a limited detection and mitigation capability against route leaks. This document proposes an enhancement that significantly extends the route-leak detection and mitigation capabilities of BGP. The solution involves carrying a per-hop route-leak protection (RLP) field in BGP updates. The RLP field is proposed be carried in an optional transitive path attribute. The solution is meant to be initially implemented as an enhancement of BGP without requiring BGPsec [I-D.ietf-sidr-bgpsec-protocol]. However, when BGPsec is deployed in the future, the solution can be incorporated in BGPsec, enabling cryptographic protection for the RLP field. That would be one way of implementing the proposed solution in a secure way. It is not claimed that the solution detects all possible types of route leaks but it detects several types, especially considering some significant route-leak occurrences that have been observed in recent years. The document also includes a stopgap method for detection and mitigation of route leaks for an intermediate phase when OV is deployed but BGP protocol on the wire is unchanged. From nobody Tue Mar 15 05:55:19 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D339712D9F2 for ; Tue, 15 Mar 2016 05:55:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com 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 4JbCZM6jYWJM for ; Tue, 15 Mar 2016 05:55:15 -0700 (PDT) Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (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 7112312D572 for ; Tue, 15 Mar 2016 05:55:15 -0700 (PDT) Received: from pps.filterd (m0044010.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u2FCpj0N003591; Tue, 15 Mar 2016 05:55:13 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fb.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=xUO35ZVBZO/r71g1iqgjbvPeQ53ckH7IFtacidjeOQU=; b=QM/m7BASPSx/hbc/LLjChQqwG9Avj+nEixKImGQDkyJ4c54snkBq2KK9v9NyPASre1W6 7Ng0zIgBGJOAWWHI4maZwv5IyUnfMufdy7JoMohzv7JTEjjSHpmMp/wdVYh1eF8SETfA FzR3ijqGhE9KUClKoT4bppwX+Xr5z186TW0= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0a-00082601.pphosted.com with ESMTP id 21pbk41mv1-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Tue, 15 Mar 2016 05:55:13 -0700 Received: from PRN-MBX01-2.TheFacebook.com ([169.254.3.204]) by PRN-CHUB04.TheFacebook.com ([fe80::7ded:c10e:ef04:80d8%12]) with mapi id 14.03.0248.002; Tue, 15 Mar 2016 05:55:13 -0700 From: Petr Lapukhov To: "Jakob Heitz (jheitz)" , "idr@ietf.org" Thread-Topic: draft-lapukhov-bgp-opaque-signaling Thread-Index: AdF8nS8FQTTx9jiyQtWM4z1Bl2FmugABRu++AABFuBAAPFwa0ABI9jVQ Date: Tue, 15 Mar 2016 12:55:12 +0000 Message-ID: <3F437107848A5140A6A19222EFFB3481200E8833@PRN-MBX01-2.TheFacebook.com> References: <2d12cade49ac4ec19a7f2c80aee3b72d@XCH-ALN-014.cisco.com> <3F437107848A5140A6A19222EFFB3481200E2389@PRN-MBX01-2.TheFacebook.com> <976fb2df5f974b298a04b547afb917b7@XCH-ALN-014.cisco.com>, <82489e182ab34b74a29cea2f5e3866bf@XCH-ALN-014.cisco.com> In-Reply-To: <82489e182ab34b74a29cea2f5e3866bf@XCH-ALN-014.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.52.123] Content-Type: multipart/alternative; boundary="_000_3F437107848A5140A6A19222EFFB3481200E8833PRNMBX012TheFac_" MIME-Version: 1.0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-03-15_04:, , signatures=0 Archived-At: Subject: Re: [Idr] draft-lapukhov-bgp-opaque-signaling X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 12:55:19 -0000 --_000_3F437107848A5140A6A19222EFFB3481200E8833PRNMBX012TheFac_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Jakob, So I was hoping to make the minimal amount of requirements needed to get th= is working. Using new AFI/SAFI already creates some burden, though it's not= that hard to enable in a datacenter, once code supports it (e.g. it could = be deployed to just one pod). A new transitive attribute with existing AFI (IPv4/IPv6) is another option,= as Robert suggested, but I feel uneasy about mixing routing and non-routin= g data: even though this approach allows for transparent data tunneling ove= r existing BGP clouds. Using new AFI/SAFI, on the other hand, allows for fi= xing the contiguous distribution topology only to devices that are willing = to support it. RTC or other extended communities are definitely a great option to constrai= n information flooding, but I decided to leave any filtering requirements u= p to the implementation - e.g. either automated RT filtering or ORF could b= e possibly used, depending on system capabilities. Simplest case, everythin= g could be flooded everywhere, if the user wishes to. Re: precedence. The proposal merge conflict resolution is to be done by usi= ng BGP best-path selection process. Therefore, to set precedences a user is= required to manipulate the usual attributes (e.g. bumping local-preference= ). IGP cost, obviously, does not exist, but this haven't been a problem in = the best for eBGP tie-breaking. AS_PATH still has topological meaning, expo= sing path to the data-source, which I find useful for debugging purposes. Regards. Petr ________________________________ From: Jakob Heitz (jheitz) [jheitz@cisco.com] Sent: Sunday, March 13, 2016 9:37 PM To: Petr Lapukhov; idr@ietf.org Subject: RE: draft-lapukhov-bgp-opaque-signaling I was thinking more of how a service provider would use this with different customers that don't know about each other, like preventing ships in the ni= ght from crashing into each other. However, it could work in private. Without a route target, any data sent will go everywhere and be stored in e= very router. You probably don't want that. This new AFI should require a route target. That means an update message wi= thout an RT must be dropped. BGP treats all updates the same. Once the floodgates are open to generic data, you might want to invent a pr= ecedence attribute. Thanks, Jakob. From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jakob Heitz (jheitz) Sent: Saturday, March 12, 2016 1:12 PM To: Petr Lapukhov ; idr@ietf.org Subject: Re: [Idr] draft-lapukhov-bgp-opaque-signaling Without this problem solved, the proposal is not useful. Everybody using it must stick to the eventual solution to ensure interopera= bility. Therefore, it should be inside the scope. Actually, BGP already has a way to distinguish applicationd: AFI and SAFI. Jakob. From: Petr Lapukhov [mailto:petr@fb.com] Sent: Saturday, March 12, 2016 1:06 PM To: Jakob Heitz (jheitz) ; idr@ietf.org Subject: RE: draft-lapukhov-bgp-opaque-signaling Hi Jakob, There is an ongoing discussion around avoiding NLRI (key) collisions. For n= ow, the plan is to externally generate unique key prefix per application, e= .g. application name, or UUID or some other globally unique string. Ensurin= g the uniqueness of those prefixes is outside the scope of the proposal, th= ough - it's more of a deployment consideration. Regards, Petr ________________________________ From: Idr [idr-bounces@ietf.org] on behalf of Jakob Heitz (jheitz) [jheitz@= cisco.com] Sent: Saturday, March 12, 2016 12:26 PM To: idr@ietf.org Subject: [Idr] [WARNING : A/V UNSCANNABLE] draft-lapukhov-bgp-opaque-signal= ing I read http://www.ietf.org/id/draft-lapukhov-bgp-opaque-signaling-01.txt Is this intended for any and multiple applications to use? If so, how do independent applications guarantee no duplication in NLRI? If not, what is the target application? Thanks Jakob. --_000_3F437107848A5140A6A19222EFFB3481200E8833PRNMBX012TheFac_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Jakob,

So I was hoping to make the minimal amount of requirements needed to g= et this working. Using new AFI/SAFI already creates some burden, though it'= s not that hard to enable in a datacenter, once code supports it (e.g. it c= ould be deployed to just one pod). 

A new transitive attribute with existing AFI (IPv4/IPv6) is another op= tion, as Robert suggested, but I feel uneasy about mixing routing and non-r= outing data: even though this approach allows for transparent data tunnelin= g over existing BGP clouds. Using new AFI/SAFI, on the other hand, allows for fixing the contiguous distribu= tion topology only to devices that are willing to support it. 

RTC or other extended communities are definitely a great option to constrai= n information flooding, but I decided to leave any filtering requirements u= p to the implementation - e.g. either automated RT filtering or ORF could b= e possibly used, depending on system capabilities. Simplest case, everything could be flooded everywhere, if th= e user wishes to.

Re: precedence. The proposal merge conflict resolution is to be done b= y using BGP best-path selection process. Therefore, to set precedences a us= er is required to manipulate the usual attributes (e.g. bumping local-prefe= rence). IGP cost, obviously, does not exist, but this haven't been a problem in the best for eBGP tie-breaki= ng. AS_PATH still has topological meaning, exposing path to the data-source= , which I find useful for debugging purposes.

Regards.

Petr

From: Jakob Heitz (jheitz) [jheitz@cisco.c= om]
Sent: Sunday, March 13, 2016 9:37 PM
To: Petr Lapukhov; idr@ietf.org
Subject: RE: draft-lapukhov-bgp-opaque-signaling

I was thinking more of how a servi= ce provider would use this with different

customers that don't know about ea= ch other, like preventing ships in the night from

crashing into each other. However,= it could work in private.

 

Without a route target, any data s= ent will go everywhere and be stored in every router.

You probably don't want that.

This new AFI should require a rout= e target. That means an update message without an RT must be dropped.

 

BGP treats all updates the same.

Once the floodgates are open to ge= neric data, you might want to invent a precedence attribute.

 

Thanks,

Jakob.

 

 =

From: Idr [mailto:idr-bounces@ietf.org] On= Behalf Of Jakob Heitz (jheitz)
Sent: Saturday, March 12, 2016 1:12 PM
To: Petr Lapukhov <petr@fb.com>; idr@ietf.org
Subject: Re: [Idr] draft-lapukhov-bgp-opaque-signaling

 

Without this problem solved, the p= roposal is not useful.

Everybody using it must stick to t= he eventual solution to ensure interoperability.

Therefore, it should be inside the= scope.

 

Actually, BGP already has a way to= distinguish applicationd: AFI and SAFI.

 

Jakob.

 

From: Petr Lapukhov [mailto:petr@fb.com]
Sent: Saturday, March 12, 2016 1:06 PM
To: Jakob Heitz (jheitz) <jheitz@cisco.com>; idr@ietf.org
Subject: RE: draft-lapukhov-bgp-opaque-signaling

 

Hi Jakob,

 

There is an ongoing discussion around = avoiding NLRI (key) collisions. For now, the plan is to externally generate= unique key prefix per application, e.g. application name, or UUID or some other globally unique string. Ensuring the uniq= ueness of those prefixes is outside the scope of the proposal, though - it'= s more of a deployment consideration.

 

Regards,

 

Petr

 

From= : Idr [idr-bounces@ietf.org] on behalf of Jakob Heitz (jheitz) [jheitz@cisco.com]
Sent: Saturday, March 12, 2016 12:26 PM
To: idr@ietf.org
Subject: [Idr] [WARNING : A/V UNSCANNABLE] draft-lapukhov-bgp-opaque= -signaling

I read

http://www.ietf.org/id/draft-lapukhov-bgp-opaque-sig= naling-01.txt

 

Is this intended for any and multi= ple applications to use?

If so, how do independent applicat= ions guarantee no duplication in NLRI?

If not, what is the target applica= tion?

 

Thanks

Jakob.

--_000_3F437107848A5140A6A19222EFFB3481200E8833PRNMBX012TheFac_-- From nobody Tue Mar 15 07:05:25 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9123412DA6B for ; Tue, 15 Mar 2016 07:05:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 cAFpK0ITJG9i for ; Tue, 15 Mar 2016 07:05:15 -0700 (PDT) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::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 D337A12DA9A for ; Tue, 15 Mar 2016 07:04:04 -0700 (PDT) Received: by mail-lb0-x230.google.com with SMTP id oe12so24275075lbc.0 for ; Tue, 15 Mar 2016 07:04:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=4OOS/ZAGRRn90Ghk2zCyMKPYkqiwhGo2kgr/CMGlKOc=; b=xJcgRuq8TEDQ4GZCqPymqC6q6FLOupXd3g2wabZ7nF50exuf8uiFvT/1g0lJ7Mb9dC y2B+Jat0I0cYhHau8A8myb0SQz0KKLtw4a8GyaOC0H/h0UK/ZSrckcvYTG1E2xHd6/Mq BnPImlUeagzw4JRCwjC7iI4NtKGj/+XjknslX/THiN4Qxl70Vqc+sBJI/B9suWZF5NXk kDo1db2CFCCTKE1YSrqSSxqu9M/TsuMUWcmUxPJ7hHUctxdf8WmbWjGJDK/LxfCFAYeq 6pdP6JNXH1z9xVckHQgnO209+8UfPxCWrC5IohoMsFPLzMel5esaPLS2WAdhJ95HD5lr z9PA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=4OOS/ZAGRRn90Ghk2zCyMKPYkqiwhGo2kgr/CMGlKOc=; b=jKRAndNqEG4w97mUpBlAVnMefzEeZcLoEVa35oyOEg/wZ3O+7IcJ5eLceuiG0wTrkf Wnv78Te7WCF/LA31sTXZFqIMK12JoHyVm0Ebvu3jOmCsF035m/OwFTIPQhTHHkmtuL5l TPDvJ+zOvhMDPdwM8epf9rJNq1MrH/qZIq4xGYLbbb4PLsMCPs7rN6e/RPoa3ZW7QtYs MU29FMoKySu93wX6LJnNnv/ic5FXB4B3HkQX3RhjQcQELpEpXfN+KK+WUarfnyGjHOX8 +YJ6NwKbYpY7cVPxuviUySoO5T680tJd7t/I1ky7MIO9EJIxatZLs9vgXzJ0frMgD8sY BEog== X-Gm-Message-State: AD7BkJI5R92Zj6SeMfhMnCUyO0t1kzAWRY8yGgNjm/MZ2WLF7LBUa9L+czkvHcgti8MRVg7ZqLKH4pdCxSdCog== MIME-Version: 1.0 X-Received: by 10.112.170.68 with SMTP id ak4mr7819555lbc.94.1458050642994; Tue, 15 Mar 2016 07:04:02 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.25.136.133 with HTTP; Tue, 15 Mar 2016 07:04:02 -0700 (PDT) In-Reply-To: <3F437107848A5140A6A19222EFFB3481200E8833@PRN-MBX01-2.TheFacebook.com> References: <2d12cade49ac4ec19a7f2c80aee3b72d@XCH-ALN-014.cisco.com> <3F437107848A5140A6A19222EFFB3481200E2389@PRN-MBX01-2.TheFacebook.com> <976fb2df5f974b298a04b547afb917b7@XCH-ALN-014.cisco.com> <82489e182ab34b74a29cea2f5e3866bf@XCH-ALN-014.cisco.com> <3F437107848A5140A6A19222EFFB3481200E8833@PRN-MBX01-2.TheFacebook.com> Date: Tue, 15 Mar 2016 10:04:02 -0400 X-Google-Sender-Auth: RkALjKrLHTa1Vt1cXxwzTtBFgFk Message-ID: From: Robert Raszuk To: Petr Lapukhov Content-Type: multipart/alternative; boundary=001a11c259a8a3f20c052e16de18 Archived-At: Cc: "idr@ietf.org" Subject: Re: [Idr] draft-lapukhov-bgp-opaque-signaling X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 14:05:23 -0000 --001a11c259a8a3f20c052e16de18 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Petr, > Simplest case, everything could be flooded everywhere, if the user wishes to. And if the user does not wish so how in your model sender may scope the distribution ? All tools (RTC, ORF etc) are rather receiver dependent. Of course you may assume user is both sender and receiver and he can control (or rather drop) unwanted data at the application layer, but is this really the right design model for opaque (to routing) information distribution architecture ? Many thx, R. On Tue, Mar 15, 2016 at 8:55 AM, Petr Lapukhov wrote: > Jakob, > > So I was hoping to make the minimal amount of requirements needed to get > this working. Using new AFI/SAFI already creates some burden, though it's > not that hard to enable in a datacenter, once code supports it (e.g. it > could be deployed to just one pod). > > A new transitive attribute with existing AFI (IPv4/IPv6) is another > option, as Robert suggested, but I feel uneasy about mixing routing and > non-routing data: even though this approach allows for transparent data > tunneling over existing BGP clouds. Using new AFI/SAFI, on the other hand= , > allows for fixing the contiguous distribution topology only to devices th= at > are willing to support it. > > RTC or other extended communities are definitely a great option to > constrain information flooding, but I decided to leave any filtering > requirements up to the implementation - e.g. either automated RT filterin= g > or ORF could be possibly used, depending on system capabilities. Simplest > case, everything could be flooded everywhere, if the user wishes to. > > Re: precedence. The proposal merge conflict resolution is to be done by > using BGP best-path selection process. Therefore, to set precedences a us= er > is required to manipulate the usual attributes (e.g. bumping > local-preference). IGP cost, obviously, does not exist, but this haven't > been a problem in the best for eBGP tie-breaking. AS_PATH still has > topological meaning, exposing path to the data-source, which I find usefu= l > for debugging purposes. > > Regards. > > Petr > > ------------------------------ > *From:* Jakob Heitz (jheitz) [jheitz@cisco.com] > *Sent:* Sunday, March 13, 2016 9:37 PM > *To:* Petr Lapukhov; idr@ietf.org > *Subject:* RE: draft-lapukhov-bgp-opaque-signaling > > I was thinking more of how a service provider would use this with differe= nt > > customers that don't know about each other, like preventing ships in the > night from > > crashing into each other. However, it could work in private. > > > > Without a route target, any data sent will go everywhere and be stored in > every router. > > You probably don't want that. > > This new AFI should require a route target. That means an update message > without an RT must be dropped. > > > > BGP treats all updates the same. > > Once the floodgates are open to generic data, you might want to invent a > precedence attribute. > > > > Thanks, > > Jakob. > > > > > > *From:* Idr [mailto:idr-bounces@ietf.org] *On Behalf Of *Jakob Heitz > (jheitz) > *Sent:* Saturday, March 12, 2016 1:12 PM > *To:* Petr Lapukhov ; idr@ietf.org > *Subject:* Re: [Idr] draft-lapukhov-bgp-opaque-signaling > > > > Without this problem solved, the proposal is not useful. > > Everybody using it must stick to the eventual solution to ensure > interoperability. > > Therefore, it should be inside the scope. > > > > Actually, BGP already has a way to distinguish applicationd: AFI and SAFI= . > > > > Jakob. > > > > *From:* Petr Lapukhov [mailto:petr@fb.com] > *Sent:* Saturday, March 12, 2016 1:06 PM > *To:* Jakob Heitz (jheitz) ; idr@ietf.org > *Subject:* RE: draft-lapukhov-bgp-opaque-signaling > > > > Hi Jakob, > > > > There is an ongoing discussion around avoiding NLRI (key) collisions. For > now, the plan is to externally generate unique key prefix per application= , > e.g. application name, or UUID or some other globally unique > string. Ensuring the uniqueness of those prefixes is outside the scope of > the proposal, though - it's more of a deployment consideration. > > > > Regards, > > > > Petr > > > ------------------------------ > > *From:* Idr [idr-bounces@ietf.org] on behalf of Jakob Heitz (jheitz) [ > jheitz@cisco.com] > *Sent:* Saturday, March 12, 2016 12:26 PM > *To:* idr@ietf.org > *Subject:* [Idr] [WARNING : A/V UNSCANNABLE] > draft-lapukhov-bgp-opaque-signaling > > I read > > http://www.ietf.org/id/draft-lapukhov-bgp-opaque-signaling-01.txt > > > > > Is this intended for any and multiple applications to use? > > If so, how do independent applications guarantee no duplication in NLRI? > > If not, what is the target application? > > > > Thanks > > Jakob. > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > --001a11c259a8a3f20c052e16de18 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Petr,

> Simplest case, everything could be flooded everywh= ere, if the user wishes to.

And if the user does not wish so how in your model sende= r may scope the distribution ?=C2=A0

All tools (RTC, ORF etc) are rather receiver depende= nt.=C2=A0

<= span style=3D"color:rgb(0,0,0);font-family:Tahoma;font-size:13.3333px">Of c= ourse you may assume user is both sender and receiver and he can control (o= r rather drop) unwanted data at the application layer, but is this really t= he right design model for opaque (to routing) information distribution arch= itecture ?=C2=A0

Many thx,
R.
= =C2= =A0
=C2=A0

On Tue, Mar 15, 2016 at 8:55 AM, Pe= tr Lapukhov <petr@fb.com> wrote:
Jakob,

So I was hoping to make the minimal amount of requirements needed to g= et this working. Using new AFI/SAFI already creates some burden, though it&= #39;s not that hard to enable in a datacenter, once code supports it (e.g. = it could be deployed to just one pod).=C2=A0

A new transitive attribute with existing AFI (IPv4/IPv6) is another op= tion, as Robert suggested, but I feel uneasy about mixing routing and non-r= outing data: even though this approach allows for transparent data tunnelin= g over existing BGP clouds. Using new AFI/SAFI, on the other hand, allows for fixing the contiguous distribu= tion topology only to devices that are willing to support it.=C2=A0

RTC or other extended communities are definitely a great option to constrai= n information flooding, but I decided to leave any filtering requirements u= p to the implementation - e.g. either automated RT filtering or ORF could b= e possibly used, depending on system capabilities. Simplest case, everything could be flooded everywhere, if th= e user wishes to.

Re: precedence. The proposal merge conflict resolution is to be done b= y using BGP best-path selection process. Therefore, to set precedences a us= er is required to manipulate the usual attributes (e.g. bumping local-prefe= rence). IGP cost, obviously, does not exist, but this haven't been a problem in the best for eBGP tie-br= eaking. AS_PATH still has topological meaning, exposing path to the data-so= urce, which I find useful for debugging purposes.

Regards.

Petr

From: Jakob Heitz (jheitz) [jheitz@cisco.com]
Sent: Sunday, March 13, 2016 9:37 PM
To: Petr Lapukhov; idr@ietf.org
Subject: RE: draft-lapukhov-bgp-opaque-signaling

I was thinking more of how a service= provider would use this with different

customers that don't know about = each other, like preventing ships in the night from

crashing into each other. However, i= t could work in private.

=C2=A0

Without a route target, any data sen= t will go everywhere and be stored in every router.

You probably don't want that.

This new AFI should require a route = target. That means an update message without an RT must be dropped.<= /p>

=C2=A0

BGP treats all updates the same.

Once the floodgates are open to gene= ric data, you might want to invent a precedence attribute.

=C2=A0

Thanks,

Jakob.

=C2=A0

=C2=A0

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jakob Heitz (jheitz)
Sent: Saturday, March 12, 2016 1:12 PM
To: Petr Lapukhov <petr@fb.com>; i= dr@ietf.org
Subject: Re: [Idr] draft-lapukhov-bgp-opaque-signaling

=C2=A0

Without this problem solved, the pro= posal is not useful.

Everybody using it must stick to the= eventual solution to ensure interoperability.

Therefore, it should be inside the s= cope.

=C2=A0

Actually, BGP already has a way to d= istinguish applicationd: AFI and SAFI.

=C2=A0

Jakob.

=C2=A0

From: Petr Lapukhov [mailto:petr@fb.com]
Sent: Saturday, March 12, 2016 1:06 PM
To: Jakob Heitz (jheitz) <jheitz@cisco.com>; idr@ietf.org
Subject: RE: draft-lapukhov-bgp-opaque-signaling

=C2=A0

Hi Jakob,

=C2=A0

There is an ongoing discussion around av= oiding NLRI (key) collisions. For now, the plan is to externally generate u= nique key prefix per application, e.g. application name, or UUID or some other globally unique string.=C2=A0Ensuring the uniq= ueness of those prefixes is outside the scope of the proposal, though - it&= #39;s more of a deployment consideration.

=C2=A0

Regards,

=C2=A0

Petr

=C2=A0

From:<= /span> Idr [idr-bounces@ietf.org] on behalf of Jakob Heitz (jheitz) [jheitz@cisco.com]
Sent: Saturday, March 12, 2016 12:26 PM
To: idr@ietf.org
Subject: [Idr] [WARNING : A/V UNSCANNABLE] draft-lapukhov-bgp-opaque= -signaling

I read<= /span>

= http://www.ietf.org/id/draft-lapukhov-bgp-opaque-signaling-01.txt

=C2=A0

Is this intended for any and multipl= e applications to use?

If so, how do independent applicatio= ns guarantee no duplication in NLRI?

If not, what is the target applicati= on?

=C2=A0

Thanks

Jakob.


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


--001a11c259a8a3f20c052e16de18-- From nobody Tue Mar 15 14:21:30 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D586912DDA9 for ; Tue, 15 Mar 2016 14:21:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 Aw4nSOFTDEgS for ; Tue, 15 Mar 2016 14:21:22 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 919E012DDAF for ; Tue, 15 Mar 2016 14:21:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=32341; q=dns/txt; s=iport; t=1458076879; x=1459286479; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=EvXW/WoBJWxzSZ2akPKkXbuj4FqkrnbZYZPW1xailY0=; b=P+N1Xk3E1bmR6A6dojtfQSxbtTQxJzp2riHhx7WZEb436rfkHh/eogdT Z2jGMf3BXHrwU1vQthSayj2mmc3fS2NaIgmLDOGo45H70ICo4/cXTpfej UL94UDlt9cEry7Yt7nViRma4eTOEIwSFi8tUVUDK/KdJcUErZwZIAxAwq 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CxBAAZfOhW/xbLJq1egnqBIG4GvEUXA?= =?us-ascii?q?QmFbAIcgW8BAQEBAQFlJ4RBAQEBBAEBARoGSwsQAgEIEQMBAiEDBAMCAgIlCxQ?= =?us-ascii?q?JCAEBBAENBRQHiAwOrxuPUAEBAQEBAQEBAQEBAQEBAQEBAQEBAREEiV5+hFsNg?= =?us-ascii?q?lOBOgWXTwGFboJyhSCBZYRJiFeGCoh0AWKCMIE1aollfgEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,341,1454976000"; d="scan'208,217";a="636280409" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Mar 2016 21:21:17 +0000 Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u2FLLGNW011110 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 15 Mar 2016 21:21:17 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 15 Mar 2016 17:21:15 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.009; Tue, 15 Mar 2016 17:21:16 -0400 From: "Acee Lindem (acee)" To: Gunter Van De Velde , Susan Hares Thread-Topic: [Idr] WG Work item call - Opinions on work items (3/5/2016 to 3/17/2016) and adoption of draft-hares-idr-flowspec-combo-01.txt Thread-Index: AdF3MOvE/JSvgLOkQ3a9MB8GleM7AQAjLYsAAdLWJYA= Date: Tue, 15 Mar 2016 21:21:16 +0000 Message-ID: References: <000b01d17731$29d17230$7d745690$@ndzh.com> In-Reply-To: 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.116.152.196] Content-Type: multipart/alternative; boundary="_000_D30DF3F7514CCaceeciscocom_" MIME-Version: 1.0 Archived-At: Cc: "idr@ietf.org" Subject: Re: [Idr] WG Work item call - Opinions on work items (3/5/2016 to 3/17/2016) and adoption of draft-hares-idr-flowspec-combo-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 21:21:28 -0000 --_000_D30DF3F7514CCaceeciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmXZlIGxpc3RlbmVkIHRoZSB0byB0aGUgSURSIEludGVyaW0gV2ViRXggcmVjb3JkaW5nIGFu ZCBteSBvcGluaW9uIGlzIGNvbnNpc3RlbnQgd2l0aCBHdW50ZXIuIEkgYmVsaWV2ZSB3ZSBzaG91 bGQgbW92ZSBmb3J3YXJkIHdpdGggb3B0aW9uIDEgYW5kIG5vdCBlbWJhcmsgb24gb3B0aW9uIDIg dW50aWwgdGhlIHJlcXVpcmVtZW50cyBhcmUgY2xlYXIgQU5EIHdlIHJlYWNoIGNvbnNlbnN1cyB0 aGF0IHdlIHdhbnQgdG8gdXNlIEJHUCBGbG93LVNwZWMgZm9yIFNETiBwb2xpY3kgZGlzdHJpYnV0 aW9uLg0KVGhhbmtzLA0KQWNlZQ0KDQpGcm9tOiBJZHIgPGlkci1ib3VuY2VzQGlldGYub3JnPG1h aWx0bzppZHItYm91bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBHdW50ZXIgVmFuIERlIFZl bGRlIDxndW50ZXJ2YW5kZXZlbGRlY2NAaWNsb3VkLmNvbTxtYWlsdG86Z3VudGVydmFuZGV2ZWxk ZWNjQGljbG91ZC5jb20+Pg0KRGF0ZTogU3VuZGF5LCBNYXJjaCA2LCAyMDE2IGF0IDQ6MzQgQU0N ClRvOiBTdXNhbiBIYXJlcyA8c2hhcmVzQG5kemguY29tPG1haWx0bzpzaGFyZXNAbmR6aC5jb20+ Pg0KQ2M6IElEUiBMaXN0IDxpZHJAaWV0Zi5vcmc8bWFpbHRvOmlkckBpZXRmLm9yZz4+DQpTdWJq ZWN0OiBSZTogW0lkcl0gV0cgV29yayBpdGVtIGNhbGwgLSBPcGluaW9ucyBvbiB3b3JrIGl0ZW1z ICgzLzUvMjAxNiB0byAzLzE3LzIwMTYpIGFuZCBhZG9wdGlvbiBvZiBkcmFmdC1oYXJlcy1pZHIt Zmxvd3NwZWMtY29tYm8tMDEudHh0DQoNCk15IGNvbnNlcm4gd2l0aCB0aGUgY29uY2VwdCBvZiBC R1AtRlMgdmVyc2lvbiAyIGlzIHRoYXQgaXQgbWVhbnMganVtcGluZyB0byBzb2x1dGlvbiBzcGFj ZSwgZXZlbiBiZWZvcmUgaGF2aW5nIGEgcm91Z2ggYWdyZWVtZW50IG9uIHRoZSByZXF1aXJlbWVu dHMgYW5kIHNjb3BlIGZvciBhIFNETiBwb2xpY3kgZGlzdHJpYnV0aW9uIG1lY2hhbmlzbS4NCkFu IGFkZGl0aW9uYWwgY29uY2VybiBpcyBhYm91dCB1c2luZyBCR1AgZm9yIE5GViBtYW5hZ2VtZW50 IGFzIHRoZXJlIG1heSBiZSBtb3JlIGFwcHJvcHJpYXRlIG1lY2hhbmlzbXMgYXZhaWxhYmxlIChv dXRzaWRlIEJHUCkuDQoNCklmIHRoZSBpbnRlbnQgaXMgdG8gdHJ1bHkgdXNlIEJHUCBhcyBhIG1l Y2hhbmlzbSB0byBkaXN0cmlidXRlIFNETiBwb2xpY2llcyBhbmQgYW5kIHJlbGF0ZWQgbWFuYWdl bWVudCBpbmZvcm1hdGlvbiwgdGhlbiB3aGF0IGRvZXMgdGhhdCBtZWFuIGV4YWN0bHk/IHdoYXQg ZG9lcyBzdWNoIHByb3RvY29sIGV4dGVuc2lvbg0KZXhwb3NlIGFzIGNhcGFiaWxpdGllcz8gV2hh dCBhcmUgdGhlIHVzZS1jYXNlcyB0aGF0IGRyaXZlIHRoZSBuZWVkIGZvciBleGlzdGVuY2Ugb2Yg c3VjaCB0ZWNobm9sb2d5PyBJbiB0aGF0IGNhc2UgaXQgbWF5IGJlIGJldHRlciB0byBjb25zdHJ1 Y3QgYSB0YWlsb3IgZGVzaWduZWQgQkdQIFBvbGljeSBEaXN0cmlidXRpb24gZnJhbWV3b3JrIHZl cnNpb24gMSAoQkdQLVBEIHZlcnNpb24gMSkNCg0KSSBiZWxpZXZlIGluIGtlZXBpbmcgY2hhbmdl cyB0byBSRkM1NTc1IHRvIGEgbWluaW11bSwgYW5kIG9ubHkgZXh0ZW5kIHRvIHNpbXBsZSBtYXRj aC9hY3Rpb24gY2FwYWJpbGl0aWVzIHRoYXQgImRyaXZlIGluZGlyZWN0aW9uIiBhbmQgIm5ldHdv cmsgd2lkZSIgcnVsZXMuDQpJIGFsc28gYmVsaWV2ZSB0aGF0IGJlZm9yZSB0cnlpbmcgdG8gZG9j dW1lbnQgYSBzb2x1dGlvbiBzcGFjZSBmb3IgQkdQIGJhc2VkIFNETiBwb2xpY3kgZGlzdHJpYnV0 aW9uLCB0aGF0IGJvdGggdGhlIHByb2JsZW0gc3BhY2UgYW5kIGludGVuZGVkIHByb3RvY29sIHBy b3BlcnRpZXMgZXhwb3NlZCBhcyBjb25zdW1hYmxlIFNETiBBUEnigJlzIG5lZWQgdG8gYmUgZGlz Y3Vzc2VkIGFuZCBhZ3JlZWQgdXBvbi4gSW4gdGhhdCBsaWdodCBpIGZlZWwgdGhhdCB0aGUgY29u Y2VwdCBvZiBhIEJHUC1GUyB2ZXJzaW9uIDIgaXMgbm90IHRoZSByaWdodCBhcHByb2FjaC4NCg0K Ry8NCg0KDQoNCg0KDQoNCg0KT24gMDUgTWFyIDIwMTYsIGF0IDIzOjQ4LCBTdXNhbiBIYXJlcyA8 c2hhcmVzQG5kemguY29tPG1haWx0bzpzaGFyZXNAbmR6aC5jb20+PiB3cm90ZToNCg0KVGhlIGlu dGVyaW0gb24gMy83LzIwMTYgd2lsbCBoYXZlIGEgZGlzY3Vzc2lvbiBvZiByZXZpc2lvbnMgdG8g dGhlIEJHUCBGbG93IHNwZWNpZmljYXRpb24gKEJHUC1GUykgdG8gYWRkIG1vcmUgZmVhdHVyZXMu ICBUaGVyZSBhcmUgdHdvIHN1Z2dlc3RlZCBvcHRpb25zOg0KMSkgICAgICBBIG1pbmltYWwgZmVh dHVyZXMgdG8gZXhpc3RpbmcgQkdQLUZTIChvcHRpb24gMSkNCkFkZCBhIGZldyBuZXcgbWF0Y2gg ZmlsdGVycyB0byB0aGUgQkdQLUZTIE5MUkkgYW5kIGZldyBuZXcgYWN0aW9ucyB0byB0aGUgQkdQ LUZTIGFjdGlvbnMgKGluIEV4dGVuZGVkIGNvbW11bml0aWVzKS4gIEFjdGlvbnMgd291bGQgbmVl ZCB0byBiZSBkb25lIGluIGEgZGVmaW5lZCBvcmRlci4gRWFjaCBuZXcgYWN0aW9ucyB3b3VsZCBu ZWVkIHRvIGRlZmluZSBjb25mbGljdHMgd2l0aCBleGlzdGluZyBhY3Rpb25zLg0KDQpCZXN0IHVz ZSBjYXNlOiAgRG9TIGF0dGFjayBwcmV2ZW50aW9uDQoNCjIpICAgICAgQ3JlYXRlIGEgQkdQLUZT IHZlcnNpb24gMiAob3B0aW9uIDIpDQpDcmVhdGUgYSBuZXcgQkdQLUZTIE5MUkkgKHYyKSB3aXRo IGEgZmllbGQgdGhhdCBpbmRpY2F0ZXMgdGhlIG9yZGVyaW5nIG9mIHRoZSBCR1AgTkxSSS4gIEFk ZCBuZXcgQkdQLUZTIGFjdGlvbnMgd2l0aCBhbiBvcmRlciBmaWVsZCBpbiB0aGUgQkdQIFdpZGUg Q29tbXVuaXRpZXMuICBGaWx0ZXJzIGFyZSBkb25lIGluIHRoZSBvcmRlciBkZWZpbmVkIGluIHRo ZSBmaWx0ZXIuICBBY3Rpb25zIGFyZSBkb25lIGluIHRoZSBvcmRlciBkZWZpbmVkIGluIHRoZSBh Y3Rpb25zLiAgIE9yZGVyIG51bWJlcnMgdGhhdCB0aWUgYXJlIGhhbmRsZWQgaW4gYSBkZWZpbmVk IG9yZGVyLg0KDQpCZXN0IHVzZSBjYXNlOiBTRE4vTkZWIGZpbHRlciBtYW5hZ2VtZW50DQoNCkEg d3JpdGUtdXAgb24gdGhlIGlzc3VlcyBhbmQgcHJvcG9zZWQgc29sdXRpb25zIGlzIGNvbnRhaW5l ZCBpbjoNCmRyYWZ0LWhhcmVzLWlkci1mbG93c3BlYy1jb21iby0wMS50eHQuIDxodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1oYXJlcy1pZHItZmxvd3NwZWMtY29tYm8vPiAg ICBUaGUgV0cgY2FuIHNlbGVjdCBib3RoIG9wdGlvbiAxIGFuZCBvcHRpb24gMi4gIFRoaXMgaXMg YSBXRyB3b3JrIGl0ZW0gY2FsbCBmb3IgaW5wdXQgdG8gdGhlIGNoYWlycyBvbiB0aGUgc2NvcGUg b2YgdGhlIFdHIGl0ZW0uICBJbiB5b3UgZGlzY3Vzc2lvbiBvZiB0aGlzIHRvcGljcywgdGhlIGNo YWlycyB3b3VsZCBhcHByZWNpYXRlIGlmIHlvdSB3b3VsZCBpbmRpY2F0ZSBpZiB5b3Ugd291bGQg c3VwcG9ydCBJRFIgd29ya2luZyBvbiBvcHRpb24gMSwgb3B0aW9uIDIgb3IgYm90aCBvcHRpb24g MSBhbmQgMi4gIFRoaXMgV0cgY2FsbCBpdGVtcyBhbHNvIGluY2x1ZGVzIGEgY2FsbCBmb3IgZHJh ZnQtaGFyZXMtaWRyLWZsb3dzcGVjLWNvbWJvLTAxLnR4dCBhcyBhIHdyaXRlLXVwIG9mIHRoZSB3 b3JrLWl0ZW0gb3B0aW9ucy4gIFRoZSBXRyBtYXkgd2lzaCB0byBzcGxpdCB0aGlzIGRyYWZ0IGlu dG8gbXVsdGlwbGUgZHJhZnRzLg0KDQpUaGUgZm9sbG93aW5nIGRyYWZ0cyBhcmUgYmVpbmcgY29u c2lkZXIgZm9yIGVpdGhlciBvcHRpb246DQoxKSAgICAgIGRyYWZ0LWVkZHktaWRyLWZsb3dzcGVj LXBhY2tldC1yYXRlDQoyKSAgICAgIGRyYWZ0LWhhby1pZHItZmxvd3NwZWMtbnYwMw0KMykgICAg ICBkcmFmdC1oYW8taWRyLWZsb3dzcGVjLWxhYmVsDQo0KSAgICAgIGRyYWZ0LWxpYW5nLWlkci1i Z3AtZmxvd3NwZWMtdGltZQ0KNSkgICAgICBkcmFmdC1saXRvd3NraS1pZHItZmxvd3NwZWMtaW50 ZXJmYWNlc2V0DQo2KSAgICAgIGRyYWZ0LXZhbmRldmVsZGUtaWRyLWZsb3dzcGVjLXBhdGgtcmVk aXJlY3QNCjcpICAgICAgZHJhZnQtbGktaWRyLWZsb3dzcGVjLXJwZC0wMS50eHQNCjgpICAgICAg ZHJhZnQtd3UtaWRyLWZsb3dzcGVjLXlhbmcuY2ZnLg0KDQpJZiB5b3Ugd2lzaCB0byBjb21tZW50 IG9uIGFueSBvZiB0aGVzZSBkcmFmdHMsIHdlIHdpbGwNCg0KV2Ugd2lsbCBjb25jbHVkZSB0aGUg Q2FsbCBmb3IgV0cgb3BpbmlvbnMgb24gMy8xNy8yMDE2IHNvIHRoZXNlIGF1dGhvcnMgY2FuIGhh dmUgYSBkYXkgdG8gcmV2aXNlIGFuZCBzdWJtaXQgdGhlaXIgZHJhZnRzIGJlZm9yZSB0aGUgZHJh ZnQgZGVhZGxpbmUuDQoNClN1ZSBIYXJlcyBhbmQgSm9obiBTY3VkZGVyDQoNClBTOg0KZHJhZnQt bGktaWRyLWZsb3dzcGVjLXJwZCBkaXNjdXNzZXMgbGltaXRzIG9uIHRoZSBkaXN0cmlidXRpb24g b2YgdGhlIHBvbGljeSB3aGljaCBoYXMgYmVlbiByZWNhc3QgaW4gZHJhZnQtaGFyZXMtaWRyLWZs b3dzcGVjLWNvbWJvIGFzIGEgYmdwLXdpZGUgY29tbXVuaXR5IG9mIENvbnRhaW5lciB0eXBlIDEg d2l0aCBhbiBhdG9tIG9mIEJHUCBGbG93IFNwZWNpZmljYXRpb24gb3JkZXJpbmcuIEhvd2V2ZXIs ICB0aGlzIGRyYWZ0IGlzIGluY2x1ZGVkIGluIHRoZSBsaXN0IHRvIGJlIGFibGUgdG8gdXBkYXRl IHRoZSBtZWNoYW5pc20gZnJvbSB0aGlzIGRyYWZ0IGludG8gdGhhdCBjb250ZXh0Lg0KDQpUaGUg eWFuZyBtb2RlbCBmb3IgQkdQIEZsb3cgc3BlY2lmaWNhdGlvbiBpcyBhbHNvIGluY2x1ZGVkIGlu IHRoaXMgd29yayBpdGVtIGFzIGl0IHdpbGwgbmVlZCB0byBiZSBtb2RpZmllZCBiYXNlZCBvbiB0 aGUgYXBwcm9hY2hlcy4gIFRoZSB5YW5nIG1vZGVsIGlzIGluIGRyYWZ0LXd1LWlkci1mbG93c3Bl Yy15YW5nLWNmZy4gIEluIHlvdXIgY29tbWVudHMsIHBsZWFzZSBpbmRpY2F0ZSBpZiB5b3UgZmVl bCB0aGVzZSBkcmFmdHMgb3Igb3RoZXIgZHJhZnRzLg0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KSWRyIG1haWxpbmcgbGlzdA0KSWRyQGlldGYub3Jn PG1haWx0bzpJZHJAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2lkcg0KDQo= --_000_D30DF3F7514CCaceeciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5J4oCZdmUgbGlz dGVuZWQgdGhlIHRvIHRoZSBJRFIgSW50ZXJpbSBXZWJFeCByZWNvcmRpbmcgYW5kIG15IG9waW5p b24gaXMgY29uc2lzdGVudCB3aXRoIEd1bnRlci4gSSBiZWxpZXZlIHdlIHNob3VsZCBtb3ZlIGZv cndhcmQgd2l0aCBvcHRpb24gMSBhbmQgbm90IGVtYmFyayBvbiBvcHRpb24gMiB1bnRpbCB0aGUg cmVxdWlyZW1lbnRzIGFyZSBjbGVhciBBTkQgd2UgcmVhY2ggY29uc2Vuc3VzIHRoYXQgd2Ugd2Fu dCB0byB1c2UgQkdQIEZsb3ctU3BlYw0KIGZvciBTRE4gcG9saWN5IGRpc3RyaWJ1dGlvbi4mbmJz cDs8L2Rpdj4NCjxkaXY+VGhhbmtzLDwvZGl2Pg0KPGRpdj5BY2VlJm5ic3A7PC9kaXY+DQo8ZGl2 Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxkaXYgc3R5 bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7IGZvbnQtc2l6ZToxMXB0OyB0ZXh0LWFsaWduOmxlZnQ7 IGNvbG9yOmJsYWNrOyBCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9uZTsgQk9SREVSLUxFRlQ6IG1l ZGl1bSBub25lOyBQQURESU5HLUJPVFRPTTogMGluOyBQQURESU5HLUxFRlQ6IDBpbjsgUEFERElO Ry1SSUdIVDogMGluOyBCT1JERVItVE9QOiAjYjVjNGRmIDFwdCBzb2xpZDsgQk9SREVSLVJJR0hU OiBtZWRpdW0gbm9uZTsgUEFERElORy1UT1A6IDNwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWln aHQ6Ym9sZCI+RnJvbTogPC9zcGFuPklkciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlkci1ib3VuY2Vz QGlldGYub3JnIj5pZHItYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IG9uIGJlaGFsZiBvZiBHdW50 ZXIgVmFuIERlIFZlbGRlICZsdDs8YSBocmVmPSJtYWlsdG86Z3VudGVydmFuZGV2ZWxkZWNjQGlj bG91ZC5jb20iPmd1bnRlcnZhbmRldmVsZGVjY0BpY2xvdWQuY29tPC9hPiZndDs8YnI+DQo8c3Bh biBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RGF0ZTogPC9zcGFuPlN1bmRheSwgTWFyY2ggNiwg MjAxNiBhdCA0OjM0IEFNPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOiA8 L3NwYW4+U3VzYW4gSGFyZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpzaGFyZXNAbmR6aC5jb20iPnNo YXJlc0BuZHpoLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQi PkNjOiA8L3NwYW4+SURSIExpc3QgJmx0OzxhIGhyZWY9Im1haWx0bzppZHJAaWV0Zi5vcmciPmlk ckBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1 YmplY3Q6IDwvc3Bhbj5SZTogW0lkcl0gV0cgV29yayBpdGVtIGNhbGwgLSBPcGluaW9ucyBvbiB3 b3JrIGl0ZW1zICgzLzUvMjAxNiB0byAzLzE3LzIwMTYpIGFuZCBhZG9wdGlvbiBvZiBkcmFmdC1o YXJlcy1pZHItZmxvd3NwZWMtY29tYm8tMDEudHh0PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwv ZGl2Pg0KPGJsb2NrcXVvdGUgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUi IHN0eWxlPSJCT1JERVItTEVGVDogI2I1YzRkZiA1IHNvbGlkOyBQQURESU5HOjAgMCAwIDU7IE1B UkdJTjowIDAgMCA1OyI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3Jk OyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hp dGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+TXkgY29uc2VybiB3aXRoIHRoZSBj b25jZXB0IG9mIEJHUC1GUyB2ZXJzaW9uIDIgaXMgdGhhdCBpdCBtZWFucyBqdW1waW5nIHRvIHNv bHV0aW9uIHNwYWNlLCBldmVuIGJlZm9yZSBoYXZpbmcgYSByb3VnaCBhZ3JlZW1lbnQgb24gdGhl IHJlcXVpcmVtZW50cyBhbmQgc2NvcGUgZm9yIGEgU0ROIHBvbGljeSBkaXN0cmlidXRpb24gbWVj aGFuaXNtLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5BbiBhZGRpdGlvbmFsIGNvbmNlcm4gaXMgYWJv dXQgdXNpbmcgQkdQIGZvciBORlYgbWFuYWdlbWVudCBhcyB0aGVyZSBtYXkgYmUgbW9yZSBhcHBy b3ByaWF0ZSBtZWNoYW5pc21zIGF2YWlsYWJsZSAob3V0c2lkZSBCR1ApLiZuYnNwOzwvZGl2Pg0K PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SWYgdGhl IGludGVudCBpcyB0byB0cnVseSB1c2UgQkdQIGFzIGEgbWVjaGFuaXNtIHRvIGRpc3RyaWJ1dGUg U0ROIHBvbGljaWVzIGFuZCBhbmQgcmVsYXRlZCBtYW5hZ2VtZW50IGluZm9ybWF0aW9uLCB0aGVu IHdoYXQgZG9lcyB0aGF0IG1lYW4gZXhhY3RseT8gd2hhdCBkb2VzIHN1Y2ggcHJvdG9jb2wgZXh0 ZW5zaW9uJm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPmV4cG9zZSBhcyBjYXBhYmlsaXRpZXM/ IFdoYXQgYXJlIHRoZSB1c2UtY2FzZXMgdGhhdCBkcml2ZSB0aGUgbmVlZCBmb3IgZXhpc3RlbmNl IG9mIHN1Y2ggdGVjaG5vbG9neT8gSW4gdGhhdCBjYXNlIGl0IG1heSBiZSBiZXR0ZXIgdG8gY29u c3RydWN0IGEgdGFpbG9yIGRlc2lnbmVkIEJHUCBQb2xpY3kgRGlzdHJpYnV0aW9uIGZyYW1ld29y ayB2ZXJzaW9uIDEgKEJHUC1QRCB2ZXJzaW9uIDEpPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5JIGJlbGlldmUgaW4ga2VlcGluZyBjaGFu Z2VzIHRvIFJGQzU1NzUgdG8gYSBtaW5pbXVtLCBhbmQgb25seSBleHRlbmQgdG8gc2ltcGxlIG1h dGNoL2FjdGlvbiBjYXBhYmlsaXRpZXMgdGhhdCAmcXVvdDtkcml2ZSBpbmRpcmVjdGlvbiZxdW90 OyBhbmQgJnF1b3Q7bmV0d29yayB3aWRlJnF1b3Q7IHJ1bGVzLjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij5JIGFsc28gYmVsaWV2ZSB0aGF0IGJlZm9yZSB0cnlpbmcgdG8gZG9jdW1lbnQgYSBzb2x1dGlv biBzcGFjZSBmb3IgQkdQIGJhc2VkIFNETiBwb2xpY3kgZGlzdHJpYnV0aW9uLCB0aGF0IGJvdGgg dGhlIHByb2JsZW0gc3BhY2UgYW5kIGludGVuZGVkIHByb3RvY29sIHByb3BlcnRpZXMgZXhwb3Nl ZCBhcyBjb25zdW1hYmxlIFNETiBBUEnigJlzIG5lZWQgdG8gYmUgZGlzY3Vzc2VkIGFuZCBhZ3Jl ZWQgdXBvbi4gSW4gdGhhdCBsaWdodA0KIGkgZmVlbCB0aGF0IHRoZSBjb25jZXB0IG9mIGEgQkdQ LUZTIHZlcnNpb24gMiBpcyBub3QgdGhlIHJpZ2h0IGFwcHJvYWNoLjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Ry88L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxiciBjbGFzcz0i Ij4NCjxkaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9 IiI+T24gMDUgTWFyIDIwMTYsIGF0IDIzOjQ4LCBTdXNhbiBIYXJlcyAmbHQ7PGEgaHJlZj0ibWFp bHRvOnNoYXJlc0BuZHpoLmNvbSIgY2xhc3M9IiI+c2hhcmVzQG5kemguY29tPC9hPiZndDsgd3Jv dGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBj bGFzcz0iIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSIgc3R5bGU9InBhZ2U6IFdvcmRTZWN0 aW9uMTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxl OiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0 ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4 dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7 IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lk dGg6IDBweDsiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNp emU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQpU aGUgaW50ZXJpbSBvbiAzLzcvMjAxNiB3aWxsIGhhdmUgYSBkaXNjdXNzaW9uIG9mIHJldmlzaW9u cyB0byB0aGUgQkdQIEZsb3cgc3BlY2lmaWNhdGlvbiAoQkdQLUZTKSB0byBhZGQgbW9yZSBmZWF0 dXJlcy4gJm5ic3A7VGhlcmUgYXJlIHR3byBzdWdnZXN0ZWQgb3B0aW9uczo8bzpwIGNsYXNzPSIi PjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250 LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+ DQo8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGlu IDAuMDAwMXB0IDAuNWluOyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBz YW5zLXNlcmlmOyB0ZXh0LWluZGVudDogLTAuMjVpbjsiIGNsYXNzPSIiPg0KPHNwYW4gY2xhc3M9 IiI+MSk8c3BhbiBzdHlsZT0iZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1h bDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgZm9udC1zaXplOiA3cHQ7IGxpbmUtaGVpZ2h0OiBub3Jt YWw7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsiIGNsYXNzPSIiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj48L3NwYW4+PC9zcGFuPkEgbWluaW1hbCBmZWF0dXJlcyB0bw0KIGV4aXN0aW5n IEJHUC1GUyAob3B0aW9uIDEpPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5i c3A7PC9zcGFuPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46 IDBpbiAwaW4gMC4wMDAxcHQgMC41aW47IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENh bGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCkFkZCBhIGZldyBuZXcgbWF0Y2ggZmlsdGVy cyB0byB0aGUgQkdQLUZTIE5MUkkgYW5kIGZldyBuZXcgYWN0aW9ucyB0byB0aGUgQkdQLUZTIGFj dGlvbnMgKGluIEV4dGVuZGVkIGNvbW11bml0aWVzKS4gJm5ic3A7QWN0aW9ucyB3b3VsZCBuZWVk IHRvIGJlIGRvbmUgaW4gYSBkZWZpbmVkIG9yZGVyLiBFYWNoIG5ldyBhY3Rpb25zIHdvdWxkIG5l ZWQgdG8gZGVmaW5lIGNvbmZsaWN0cyB3aXRoIGV4aXN0aW5nIGFjdGlvbnMuICZuYnNwOyZuYnNw OzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4g MC4wMDAxcHQgMC41aW47IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNh bnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8 ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQgMC41aW47IGZvbnQtc2l6ZTogMTFw dDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCkJlc3QgdXNl IGNhc2U6Jm5ic3A7IERvUyBhdHRhY2sgcHJldmVudGlvbjxzcGFuIGNsYXNzPSJBcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRp diBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0IDAuNWluOyBmb250LXNpemU6IDExcHQ7 IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNz PSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAw MXB0IDAuNWluOyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNl cmlmOyB0ZXh0LWluZGVudDogLTAuMjVpbjsiIGNsYXNzPSIiPg0KPHNwYW4gY2xhc3M9IiI+Mik8 c3BhbiBzdHlsZT0iZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9u dC13ZWlnaHQ6IG5vcm1hbDsgZm9udC1zaXplOiA3cHQ7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZv bnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsiIGNsYXNzPSIiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj48L3NwYW4+PC9zcGFuPkNyZWF0ZSBhIEJHUC1GUyB2ZXJzaW9uDQogMiAob3B0aW9uIDIp PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxvOnAgY2xh c3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQg MC41aW47IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7 IiBjbGFzcz0iIj4NCkNyZWF0ZSBhIG5ldyBCR1AtRlMgTkxSSSAodjIpIHdpdGggYSBmaWVsZCB0 aGF0IGluZGljYXRlcyB0aGUgb3JkZXJpbmcgb2YgdGhlIEJHUCBOTFJJLiZuYnNwOyBBZGQgbmV3 IEJHUC1GUyBhY3Rpb25zIHdpdGggYW4gb3JkZXIgZmllbGQgaW4gdGhlIEJHUCBXaWRlIENvbW11 bml0aWVzLiZuYnNwOyBGaWx0ZXJzIGFyZSBkb25lIGluIHRoZSBvcmRlciBkZWZpbmVkIGluIHRo ZSBmaWx0ZXIuJm5ic3A7IEFjdGlvbnMgYXJlIGRvbmUgaW4gdGhlIG9yZGVyIGRlZmluZWQgaW4N CiB0aGUgYWN0aW9ucy4mbmJzcDsmbmJzcDsgT3JkZXIgbnVtYmVycyB0aGF0IHRpZSBhcmUgaGFu ZGxlZCBpbiBhIGRlZmluZWQgb3JkZXIuPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJt YXJnaW46IDBpbiAwaW4gMC4wMDAxcHQgMC41aW47IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1p bHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7 PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQgMC41aW47 IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFz cz0iIj4NCkJlc3QgdXNlIGNhc2U6IFNETi9ORlYgZmlsdGVyIG1hbmFnZW1lbnQ8c3BhbiBjbGFz cz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PG86cCBjbGFzcz0iIj48L286 cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXpl OiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPG86 cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBp biAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1z ZXJpZjsiIGNsYXNzPSIiPg0KQSB3cml0ZS11cCBvbiB0aGUgaXNzdWVzIGFuZCBwcm9wb3NlZCBz b2x1dGlvbnMgaXMgY29udGFpbmVkIGluOjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0i bWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBD YWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8YSBocmVmPSJodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1oYXJlcy1pZHItZmxvd3NwZWMtY29tYm8vIiBzdHlsZT0i Y29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj5kcmFm dC1oYXJlcy1pZHItZmxvd3NwZWMtY29tYm8tMDEudHh0LjxzcGFuIGNsYXNzPSJBcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2E+Jm5ic3A7Jm5ic3A7Jm5ic3A7VGhlIFdHIGNh biBzZWxlY3QgYm90aCBvcHRpb24gMSBhbmQNCiBvcHRpb24gMi4gJm5ic3A7VGhpcyBpcyBhIFdH IHdvcmsgaXRlbSBjYWxsIGZvciBpbnB1dCB0byB0aGUgY2hhaXJzIG9uIHRoZSBzY29wZSBvZiB0 aGUgV0cgaXRlbS4gJm5ic3A7SW4geW91IGRpc2N1c3Npb24gb2YgdGhpcyB0b3BpY3MsIHRoZSBj aGFpcnMgd291bGQgYXBwcmVjaWF0ZSBpZiB5b3Ugd291bGQgaW5kaWNhdGUgaWYgeW91IHdvdWxk IHN1cHBvcnQgSURSIHdvcmtpbmcgb24gb3B0aW9uIDEsIG9wdGlvbiAyIG9yIGJvdGggb3B0aW9u IDEgYW5kIDIuDQogJm5ic3A7VGhpcyBXRyBjYWxsIGl0ZW1zIGFsc28gaW5jbHVkZXMgYSBjYWxs IGZvciBkcmFmdC1oYXJlcy1pZHItZmxvd3NwZWMtY29tYm8tMDEudHh0IGFzIGEgd3JpdGUtdXAg b2YgdGhlIHdvcmstaXRlbSBvcHRpb25zLiZuYnNwOyBUaGUgV0cgbWF5IHdpc2ggdG8gc3BsaXQg dGhpcyBkcmFmdCBpbnRvIG11bHRpcGxlIGRyYWZ0cy48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYg c3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZh bWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJz cDs8L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9u dC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIi Pg0KVGhlIGZvbGxvd2luZyBkcmFmdHMgYXJlIGJlaW5nIGNvbnNpZGVyIGZvciBlaXRoZXIgb3B0 aW9uOjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpw IGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAw MXB0IDAuNWluOyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNl cmlmOyB0ZXh0LWluZGVudDogLTAuMjVpbjsiIGNsYXNzPSIiPg0KPHNwYW4gY2xhc3M9IiI+MSk8 c3BhbiBzdHlsZT0iZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9u dC13ZWlnaHQ6IG5vcm1hbDsgZm9udC1zaXplOiA3cHQ7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZv bnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsiIGNsYXNzPSIiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj48L3NwYW4+PC9zcGFuPmRyYWZ0LWVkZHktaWRyLWZsb3dzcGVjLXBhY2tldC1yYXRlPG86 cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAw MDFwdCAwLjVpbjsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1z ZXJpZjsgdGV4dC1pbmRlbnQ6IC0wLjI1aW47IiBjbGFzcz0iIj4NCjxzcGFuIGNsYXNzPSIiPjIp PHNwYW4gc3R5bGU9ImZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZv bnQtd2VpZ2h0OiBub3JtYWw7IGZvbnQtc2l6ZTogN3B0OyBsaW5lLWhlaWdodDogbm9ybWFsOyBm b250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbic7IiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+PC9zcGFuPjwvc3Bhbj5kcmFmdC1oYW8taWRyLWZsb3dzcGVjLW52MDM8bzpwIGNsYXNz PSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0IDAu NWluOyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyB0 ZXh0LWluZGVudDogLTAuMjVpbjsiIGNsYXNzPSIiPg0KPHNwYW4gY2xhc3M9IiI+Myk8c3BhbiBz dHlsZT0iZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWln aHQ6IG5vcm1hbDsgZm9udC1zaXplOiA3cHQ7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFt aWx5OiAnVGltZXMgTmV3IFJvbWFuJzsiIGNsYXNzPSIiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOzxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48 L3NwYW4+PC9zcGFuPmRyYWZ0LWhhby1pZHItZmxvd3NwZWMtbGFiZWw8bzpwIGNsYXNzPSIiPjwv bzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0IDAuNWluOyBm b250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyB0ZXh0LWlu ZGVudDogLTAuMjVpbjsiIGNsYXNzPSIiPg0KPHNwYW4gY2xhc3M9IiI+NCk8c3BhbiBzdHlsZT0i Zm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5v cm1hbDsgZm9udC1zaXplOiA3cHQ7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiAn VGltZXMgTmV3IFJvbWFuJzsiIGNsYXNzPSIiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OzxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+ PC9zcGFuPmRyYWZ0LWxpYW5nLWlkci1iZ3AtZmxvd3NwZWMtdGltZTxvOnAgY2xhc3M9IiI+PC9v OnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQgMC41aW47IGZv bnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IHRleHQtaW5k ZW50OiAtMC4yNWluOyIgY2xhc3M9IiI+DQo8c3BhbiBjbGFzcz0iIj41KTxzcGFuIHN0eWxlPSJm b250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9y bWFsOyBmb250LXNpemU6IDdwdDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6ICdU aW1lcyBOZXcgUm9tYW4nOyIgY2xhc3M9IiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48 L3NwYW4+ZHJhZnQtbGl0b3dza2ktaWRyLWZsb3dzcGVjLWludGVyZmFjZXNldDxzcGFuIGNsYXNz PSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpwIGNsYXNzPSIiPjwvbzpw PjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0IDAuNWluOyBmb250 LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyB0ZXh0LWluZGVu dDogLTAuMjVpbjsiIGNsYXNzPSIiPg0KPHNwYW4gY2xhc3M9IiI+Nik8c3BhbiBzdHlsZT0iZm9u dC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1h bDsgZm9udC1zaXplOiA3cHQ7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiAnVGlt ZXMgTmV3IFJvbWFuJzsiIGNsYXNzPSIiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxz cGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PC9z cGFuPmRyYWZ0LXZhbmRldmVsZGUtaWRyLWZsb3dzcGVjLXBhdGgtcmVkaXJlY3Q8bzpwIGNsYXNz PSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0IDAu NWluOyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyB0 ZXh0LWluZGVudDogLTAuMjVpbjsiIGNsYXNzPSIiPg0KPHNwYW4gY2xhc3M9IiI+Nyk8c3BhbiBz dHlsZT0iZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWln aHQ6IG5vcm1hbDsgZm9udC1zaXplOiA3cHQ7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFt aWx5OiAnVGltZXMgTmV3IFJvbWFuJzsiIGNsYXNzPSIiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOzxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48 L3NwYW4+PC9zcGFuPmRyYWZ0LWxpLWlkci1mbG93c3BlYy1ycGQtMDEudHh0PHNwYW4gY2xhc3M9 IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxvOnAgY2xhc3M9IiI+PC9vOnA+ PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQgMC41aW47IGZvbnQt c2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IHRleHQtaW5kZW50 OiAtMC4yNWluOyIgY2xhc3M9IiI+DQo8c3BhbiBjbGFzcz0iIj44KTxzcGFuIHN0eWxlPSJmb250 LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFs OyBmb250LXNpemU6IDdwdDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6ICdUaW1l cyBOZXcgUm9tYW4nOyIgY2xhc3M9IiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNw YW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48L3Nw YW4+ZHJhZnQtd3UtaWRyLWZsb3dzcGVjLXlhbmcuY2ZnLjxzcGFuIGNsYXNzPSJBcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRp diBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQt ZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZu YnNwOzwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBm b250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9 IiI+DQpJZiB5b3Ugd2lzaCB0byBjb21tZW50IG9uIGFueSBvZiB0aGVzZSBkcmFmdHMsIHdlIHdp bGw8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PG86cCBj bGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFw dDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNs YXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1h cmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2Fs aWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KV2Ugd2lsbCBjb25jbHVkZSB0aGUgQ2FsbCBm b3IgV0cgb3BpbmlvbnMgb24gMy8xNy8yMDE2IHNvIHRoZXNlIGF1dGhvcnMgY2FuIGhhdmUgYSBk YXkgdG8gcmV2aXNlIGFuZCBzdWJtaXQgdGhlaXIgZHJhZnRzIGJlZm9yZSB0aGUgZHJhZnQgZGVh ZGxpbmUuPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxv OnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4w MDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7 IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxl PSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6 IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NClN1ZSBIYXJlcyBhbmQgSm9obiBTY3Vk ZGVyPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxvOnAg Y2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAx cHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBj bGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJt YXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENh bGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NClBTOjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9k aXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFw dDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCmRyYWZ0LWxp LWlkci1mbG93c3BlYy1ycGQgZGlzY3Vzc2VzIGxpbWl0cyBvbiB0aGUgZGlzdHJpYnV0aW9uIG9m IHRoZSBwb2xpY3kgd2hpY2ggaGFzIGJlZW4gcmVjYXN0IGluIGRyYWZ0LWhhcmVzLWlkci1mbG93 c3BlYy1jb21ibyBhcyBhIGJncC13aWRlIGNvbW11bml0eSBvZiBDb250YWluZXIgdHlwZSAxIHdp dGggYW4gYXRvbSBvZiBCR1AgRmxvdyBTcGVjaWZpY2F0aW9uIG9yZGVyaW5nLiBIb3dldmVyLCZu YnNwOyB0aGlzIGRyYWZ0IGlzIGluY2x1ZGVkDQogaW4gdGhlIGxpc3QgdG8gYmUgYWJsZSB0byB1 cGRhdGUgdGhlIG1lY2hhbmlzbSBmcm9tIHRoaXMgZHJhZnQgaW50byB0aGF0IGNvbnRleHQuICZu YnNwOzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAw aW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMt c2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8ZGl2 IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1m YW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NClRoZSB5YW5nIG1vZGVsIGZv ciBCR1AgRmxvdyBzcGVjaWZpY2F0aW9uIGlzIGFsc28gaW5jbHVkZWQgaW4gdGhpcyB3b3JrIGl0 ZW0gYXMgaXQgd2lsbCBuZWVkIHRvIGJlIG1vZGlmaWVkIGJhc2VkIG9uIHRoZSBhcHByb2FjaGVz LiZuYnNwOyBUaGUgeWFuZyBtb2RlbCBpcyBpbiBkcmFmdC13dS1pZHItZmxvd3NwZWMteWFuZy1j ZmcuICZuYnNwO0luIHlvdXIgY29tbWVudHMsIHBsZWFzZSBpbmRpY2F0ZSBpZiB5b3UgZmVlbCB0 aGVzZSBkcmFmdHMgb3Igb3RoZXIgZHJhZnRzLiZuYnNwOzxzcGFuIGNsYXNzPSJBcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRp diBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQt ZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZu YnNwOzwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZl dGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDog bm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBo YW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFu c2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFj aW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRp c3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+X19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTog SGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJp YW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7 IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0 LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3Jk LXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+ DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBm b250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9y bWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBz dGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNl OiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1z dHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50 OyIgY2xhc3M9IiI+SWRyDQogbWFpbGluZyBsaXN0PC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1p bHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQt dmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9y bWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsg dGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsg d29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNz PSIiPg0KPGEgaHJlZj0ibWFpbHRvOklkckBpZXRmLm9yZyIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7 IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250 LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZv bnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87 IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9u ZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsg LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+SWRyQGlldGYub3JnPC9h PjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250 LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFs OyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFy dDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBu b3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJv a2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9pZHIiIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRp b246IHVuZGVybGluZTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBm b250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9y bWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBz dGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNl OiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1z dHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vaWRyPC9hPjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9zcGFuPg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_D30DF3F7514CCaceeciscocom_-- From nobody Tue Mar 15 14:34:28 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58BE912DDB3 for ; Tue, 15 Mar 2016 14:34:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.739 X-Spam-Level: * X-Spam-Status: No, score=1.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RDNS_NONE=0.793] autolearn=no autolearn_force=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 75UY00JPMNBp for ; Tue, 15 Mar 2016 14:34:22 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 0E67E12D568 for ; Tue, 15 Mar 2016 14:34:21 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.30; From: "Susan Hares" To: "'Acee Lindem \(acee\)'" , "'Gunter Van De Velde'" References: <000b01d17731$29d17230$7d745690$@ndzh.com> In-Reply-To: Date: Tue, 15 Mar 2016 17:33:47 -0400 Message-ID: <00ee01d17f02$5c49d620$14dd8260$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00EF_01D17EE0.D539BCC0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGcwDBIhMS4vQbRNdLW21dU5JTRjQI/zGpmAjNigDmfoOnggA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: idr@ietf.org Subject: Re: [Idr] WG Work item call - Opinions on work items (3/5/2016 to 3/17/2016) and adoption of draft-hares-idr-flowspec-combo-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 21:34:24 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00EF_01D17EE0.D539BCC0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Acee:=20 =20 Thank you for letting me know your opinion. =20 =20 At this point, I think we have rough consensus that we can move forward = with option 1, and interest in option 2 with mixed reviews on whether we = are ready to embark on option 2. This call last for 2 more days = =E2=80=93 so we will see if that brings clarity on option 2. =20 =20 I think we can begin to do a WG adoption call for drafts for option 1.=20 =20 Sue=20 =20 From: Acee Lindem (acee) [mailto:acee@cisco.com]=20 Sent: Tuesday, March 15, 2016 5:21 PM To: Gunter Van De Velde; Susan Hares Cc: idr@ietf.org Subject: Re: [Idr] WG Work item call - Opinions on work items (3/5/2016 = to 3/17/2016) and adoption of draft-hares-idr-flowspec-combo-01.txt =20 I=E2=80=99ve listened the to the IDR Interim WebEx recording and my = opinion is consistent with Gunter. I believe we should move forward with = option 1 and not embark on option 2 until the requirements are clear AND = we reach consensus that we want to use BGP Flow-Spec for SDN policy = distribution.=20 Thanks, Acee=20 =20 From: Idr on behalf of Gunter Van De Velde = Date: Sunday, March 6, 2016 at 4:34 AM To: Susan Hares Cc: IDR List Subject: Re: [Idr] WG Work item call - Opinions on work items (3/5/2016 = to 3/17/2016) and adoption of draft-hares-idr-flowspec-combo-01.txt =20 My consern with the concept of BGP-FS version 2 is that it means jumping = to solution space, even before having a rough agreement on the = requirements and scope for a SDN policy distribution mechanism. An additional concern is about using BGP for NFV management as there may = be more appropriate mechanisms available (outside BGP).=20 =20 If the intent is to truly use BGP as a mechanism to distribute SDN = policies and and related management information, then what does that = mean exactly? what does such protocol extension=20 expose as capabilities? What are the use-cases that drive the need for = existence of such technology? In that case it may be better to construct = a tailor designed BGP Policy Distribution framework version 1 (BGP-PD = version 1) =20 I believe in keeping changes to RFC5575 to a minimum, and only extend to = simple match/action capabilities that "drive indirection" and "network = wide" rules. I also believe that before trying to document a solution space for BGP = based SDN policy distribution, that both the problem space and intended = protocol properties exposed as consumable SDN API=E2=80=99s need to be = discussed and agreed upon. In that light i feel that the concept of a = BGP-FS version 2 is not the right approach. =20 G/ =20 =20 =20 =20 =20 =20 =20 On 05 Mar 2016, at 23:48, Susan Hares wrote: =20 The interim on 3/7/2016 will have a discussion of revisions to the BGP = Flow specification (BGP-FS) to add more features. There are two = suggested options: 1) A minimal features to existing BGP-FS (option 1)=20 Add a few new match filters to the BGP-FS NLRI and few new actions to = the BGP-FS actions (in Extended communities). Actions would need to be = done in a defined order. Each new actions would need to define conflicts = with existing actions. =20 =20 Best use case: DoS attack prevention=20 =20 2) Create a BGP-FS version 2 (option 2)=20 Create a new BGP-FS NLRI (v2) with a field that indicates the ordering = of the BGP NLRI. Add new BGP-FS actions with an order field in the BGP = Wide Communities. Filters are done in the order defined in the filter. = Actions are done in the order defined in the actions. Order numbers = that tie are handled in a defined order.=20 =20 Best use case: SDN/NFV filter management=20 =20 A write-up on the issues and proposed solutions is contained in:=20 = draft-hares-idr-flowspec-combo-01.txt. The WG can select both option = 1 and option 2. This is a WG work item call for input to the chairs on = the scope of the WG item. In you discussion of this topics, the chairs = would appreciate if you would indicate if you would support IDR working = on option 1, option 2 or both option 1 and 2. This WG call items also = includes a call for draft-hares-idr-flowspec-combo-01.txt as a write-up = of the work-item options. The WG may wish to split this draft into = multiple drafts.=20 =20 The following drafts are being consider for either option:=20 1) draft-eddy-idr-flowspec-packet-rate 2) draft-hao-idr-flowspec-nv03 3) draft-hao-idr-flowspec-label 4) draft-liang-idr-bgp-flowspec-time 5) draft-litowski-idr-flowspec-interfaceset=20 6) draft-vandevelde-idr-flowspec-path-redirect 7) draft-li-idr-flowspec-rpd-01.txt=20 8) draft-wu-idr-flowspec-yang.cfg.=20 =20 If you wish to comment on any of these drafts, we will=20 =20 We will conclude the Call for WG opinions on 3/17/2016 so these authors = can have a day to revise and submit their drafts before the draft = deadline.=20 =20 Sue Hares and John Scudder=20 =20 PS: draft-li-idr-flowspec-rpd discusses limits on the distribution of the = policy which has been recast in draft-hares-idr-flowspec-combo as a = bgp-wide community of Container type 1 with an atom of BGP Flow = Specification ordering. However, this draft is included in the list to = be able to update the mechanism from this draft into that context. =20 =20 The yang model for BGP Flow specification is also included in this work = item as it will need to be modified based on the approaches. The yang = model is in draft-wu-idr-flowspec-yang-cfg. In your comments, please = indicate if you feel these drafts or other drafts. =20 =20 _______________________________________________ Idr mailing list Idr@ietf.org = https://www.ietf.org/mailman/listinfo/idr =20 ------=_NextPart_000_00EF_01D17EE0.D539BCC0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Acee:

 

Thank you for letting me know your opinion. = =C2=A0

 

At this point, I think we have rough consensus that we can move = forward with option 1, and interest in option 2 with mixed reviews on = whether we are ready to embark on option 2.=C2=A0 =C2=A0This call last = for 2 more days =E2=80=93 so we will see if that brings clarity on = option 2.=C2=A0

 

I think we can begin to do a WG adoption call for drafts for option = 1.

 

Sue

 

From:= = Acee Lindem (acee) [mailto:acee@cisco.com]
Sent: Tuesday, = March 15, 2016 5:21 PM
To: Gunter Van De Velde; Susan = Hares
Cc: idr@ietf.org
Subject: Re: [Idr] WG Work = item call - Opinions on work items (3/5/2016 to 3/17/2016) and adoption = of = draft-hares-idr-flowspec-combo-01.txt

 

I=E2=80=99ve listened the to the IDR Interim WebEx recording and my = opinion is consistent with Gunter. I believe we should move forward with = option 1 and not embark on option 2 until the requirements are clear AND = we reach consensus that we want to use BGP Flow-Spec for SDN policy = distribution. 

Thanks,

Acee 

 

From: Idr <idr-bounces@ietf.org> on = behalf of Gunter Van De Velde <guntervandeveldecc@icloud.c= om>
Date: Sunday, March 6, 2016 at 4:34 AM
To: = Susan Hares <shares@ndzh.com>
Cc: = IDR List <idr@ietf.org>
Subject: Re: = [Idr] WG Work item call - Opinions on work items (3/5/2016 to 3/17/2016) = and adoption of = draft-hares-idr-flowspec-combo-01.txt

 

My consern with the concept of BGP-FS version 2 is that it means = jumping to solution space, even before having a rough agreement on the = requirements and scope for a SDN policy distribution = mechanism.

An additional concern is about using BGP for NFV management as there = may be more appropriate mechanisms available (outside = BGP). 

 

If the intent is to truly use BGP as a mechanism to distribute SDN = policies and and related management information, then what does that = mean exactly? what does such protocol = extension 

expose as capabilities? What are the use-cases that drive the need for = existence of such technology? In that case it may be better to construct = a tailor designed BGP Policy Distribution framework version 1 (BGP-PD = version 1)

 

I believe in keeping changes to RFC5575 to a minimum, and only extend = to simple match/action capabilities that "drive indirection" = and "network wide" rules.

I also believe that before trying to document a solution space for BGP = based SDN policy distribution, that both the problem space and intended = protocol properties exposed as consumable SDN API=E2=80=99s need to be = discussed and agreed upon. In that light i feel that the concept of a = BGP-FS version 2 is not the right = approach.

 

G/

 

 

 

 

 

 

 

On 05 Mar 2016, at 23:48, Susan Hares <shares@ndzh.com> = wrote:

 

The interim on 3/7/2016 will have a discussion of revisions to the BGP = Flow specification (BGP-FS) to add more features.  There are two = suggested options:

1)      A minimal features to existing BGP-FS (option 1) 

Add a few new match filters to the BGP-FS NLRI and few new actions to = the BGP-FS actions (in Extended communities).  Actions would need = to be done in a defined order. Each new actions would need to define = conflicts with existing actions. =   

 

Best use case:  DoS attack prevention 

 

2)      Create a BGP-FS version 2 (option 2) 

Create a new BGP-FS NLRI (v2) with a field that indicates the ordering = of the BGP NLRI.  Add new BGP-FS actions with an order field in the = BGP Wide Communities.  Filters are done in the order defined in the = filter.  Actions are done in the order defined in the = actions.   Order numbers that tie are handled in a defined = order. 

 

Best use case: SDN/NFV filter management 

 

A write-up on the issues and proposed solutions is contained in: 

draft-hares-idr-flowspec-combo-01.txt.    T= he WG can select both option 1 and option 2.  This is a WG work = item call for input to the chairs on the scope of the WG item.  In = you discussion of this topics, the chairs would appreciate if you would = indicate if you would support IDR working on option 1, option 2 or both = option 1 and 2.  This WG call items also includes a call for = draft-hares-idr-flowspec-combo-01.txt as a write-up of the work-item = options.  The WG may wish to split this draft into multiple = drafts. 

 

The following drafts are being consider for either option: 

1)      draft-eddy-idr-flowspec-packet-rate

2)      draft-hao-idr-flowspec-nv03

3)      draft-hao-idr-flowspec-label

4)      draft-liang-idr-bgp-flowspec-time

5)      draft-litowski-idr-flowspec-interfaceset 

6)      draft-vandevelde-idr-flowspec-path-redirect

<= div style=3D'margin-left:.5in'>

7)      draft-li-idr-flowspec-rpd-01.txt 

8)      draft-wu-idr-flowspec-yang.cfg. 

 

If you wish to comment on any of these drafts, we will 

 

We will conclude the Call for WG opinions on 3/17/2016 so these authors = can have a day to revise and submit their drafts before the draft = deadline. 

 

Sue Hares and John Scudder 

 

PS:

draft-li-idr-flowspec-rpd discusses limits on the distribution of the = policy which has been recast in draft-hares-idr-flowspec-combo as a = bgp-wide community of Container type 1 with an atom of BGP Flow = Specification ordering. However,  this draft is included in the = list to be able to update the mechanism from this draft into that = context.  

 

The yang model for BGP Flow specification is also included in this work = item as it will need to be modified based on the approaches.  The = yang model is in draft-wu-idr-flowspec-yang-cfg.  In your comments, = please indicate if you feel these drafts or other drafts.  

 

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

 

------=_NextPart_000_00EF_01D17EE0.D539BCC0-- From nobody Wed Mar 16 02:53:36 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34FE612D8C2 for ; Wed, 16 Mar 2016 02:53:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 4_IwRdMoReGO for ; Wed, 16 Mar 2016 02:53:32 -0700 (PDT) Received: from BLU004-OMC3S29.hotmail.com (blu004-omc3s29.hotmail.com [65.55.116.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FA8E12D514 for ; Wed, 16 Mar 2016 02:53:29 -0700 (PDT) Received: from BLU437-SMTP38 ([65.55.116.72]) by BLU004-OMC3S29.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Wed, 16 Mar 2016 02:52:27 -0700 X-TMN: [gkvLedZC578LNPTekAPbTE5ONdnuCeLJ938wt//hyHo=] X-Originating-Email: [li_zhenqiang@hotmail.com] Message-ID: Date: Wed, 16 Mar 2016 17:59:52 +0800 From: "li_zhenqiang@hotmail.com" To: idr X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7, 2, 7, 26[cn] MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_001_NextPart211871536540_=----" X-OriginalArrivalTime: 16 Mar 2016 09:52:20.0729 (UTC) FILETIME=[88685E90:01D17F69] Archived-At: Subject: [Idr] Fw: New Version Notification for draft-li-idr-congestion-status-extended-community-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 09:53:34 -0000 ------=_001_NextPart211871536540_=---- Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGksIElEUiBleHBlcnRzLA0KDQpBIG5ldyBkcmFmdCBoYXMgYmVlbiBwb3N0ZWQsIHBsZWFzZSBz ZWUgdGhlIGluZm9ybWF0aW9uIGJlbG93IGFuZCBjb21tZW50Lg0KDQpBbiBleHRlbmRlZCBjb21t dW5pdHkgaXMgc3VnZ2VzdGVkIGluIHRoaXMgZG9jIHRvIGNhcnJ5IGNvbmdlc3Rpb24gc3RhdHVz IGluZm9ybWF0aW9uIG9mIHRoZSBleGl0IGxpbmsgdG8gb3RoZXIgQkdQIHBlZXJzLiBCeSBkZXBs b3lpbmcgcm91dGUgcG9saWN5LCB0aGUgQkdQIHBlZXJzIGNhbiB1c2UgdGhlIGNvbmdlc3Rpb24g c3RhdHVzIHRvIHN0ZWVyIHRoZSB0cmFmZmljIGdvaW5nIG91dCBpdHMgQVMuDQoNCg0KDQpsaV96 aGVucWlhbmdAaG90bWFpbC5jb20NCiANCkZyb206IGludGVybmV0LWRyYWZ0cw0KRGF0ZTogMjAx Ni0wMy0xNSAxOTowNQ0KVG86IEppZSBEb25nOyBaaGVucWlhbmcgTGkNClN1YmplY3Q6IE5ldyBW ZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbGktaWRyLWNvbmdlc3Rpb24tc3RhdHVzLWV4 dGVuZGVkLWNvbW11bml0eS0wMC50eHQNCiANCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1s aS1pZHItY29uZ2VzdGlvbi1zdGF0dXMtZXh0ZW5kZWQtY29tbXVuaXR5LTAwLnR4dA0KaGFzIGJl ZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBaaGVucWlhbmcgTGkgYW5kIHBvc3RlZCB0byB0 aGUNCklFVEYgcmVwb3NpdG9yeS4NCiANCk5hbWU6IGRyYWZ0LWxpLWlkci1jb25nZXN0aW9uLXN0 YXR1cy1leHRlbmRlZC1jb21tdW5pdHkNClJldmlzaW9uOiAwMA0KVGl0bGU6IENhcnJ5IGNvbmdl c3Rpb24gc3RhdHVzIGluIEJHUCBleHRlbmRlZCBjb21tdW5pdHkNCkRvY3VtZW50IGRhdGU6IDIw MTYtMDMtMTUNCkdyb3VwOiBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOiA3DQpVUkw6ICAg ICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWxpLWlk ci1jb25nZXN0aW9uLXN0YXR1cy1leHRlbmRlZC1jb21tdW5pdHktMDAudHh0DQpTdGF0dXM6ICAg ICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbGktaWRyLWNvbmdl c3Rpb24tc3RhdHVzLWV4dGVuZGVkLWNvbW11bml0eS8NCkh0bWxpemVkOiAgICAgICBodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbGktaWRyLWNvbmdlc3Rpb24tc3RhdHVzLWV4dGVu ZGVkLWNvbW11bml0eS0wMA0KIA0KIA0KQWJzdHJhY3Q6DQogICBBIG5ldyBleHRlbmRlZCBjb21t dW5pdHkgaXMgaW50cm9kdWNlZCBpbiB0aGlzIGRvY3VtZW50IHRvIGNhcnJ5IHRoZQ0KICAgbGlu ayBjb25nZXN0aW9uIHN0YXR1cywgZXNwZWNpYWxseSBmb3IgdGhlIGV4aXQgbGluayBvZiBvbmUg QVMuICBXZQ0KICAgY2FsbCB0aGlzIGV4dGVuZGVkIGNvbW11bml0eSBjb25nZXN0aW9uIHN0YXR1 cyBjb21tdW5pdHksIHdoaWNoIGNhbg0KICAgYmUgdXNlZCBieSB0aGUgQkdQIHJvdXRlcnMgdG8g c3RlZXIgdGhlIEludGVybmV0LWFjY2VzcyB0cmFmZmljIGFtb25nDQogICB0aGUgZXhpdCBsaW5r cyBieSBkZXBsb3lpbmcgcG9saWN5IHJvdXRpbmcuDQogDQogDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgDQogDQogDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1p bnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVy c2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KIA0KVGhlIElF VEYgU2VjcmV0YXJpYXQNCiANCiANCg== ------=_001_NextPart211871536540_=---- Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0A
Hi, IDR experts,
=

A new draft has been posted, please see the informatio= n below and comment.

An extended community is sug= gested in this doc to carry congestion status information of the exit link= to other BGP peers. By deploying route policy, the BGP peers can use the = congestion status to steer the traffic going out its AS.
=0A

=
=0A
li_zhenqiang@hotmail.com
=0A
 
From:&nb= sp;internet-drafts
Date: 2016-03-15 19:05
Subject: New Vers= ion Notification for draft-li-idr-congestion-status-extended-community-00.= txt
 
=0A
A new version of I-D, d= raft-li-idr-congestion-status-extended-community-00.txt
=0A
has b= een successfully submitted by Zhenqiang Li and posted to the
=0A
= IETF repository.
=0A
 
=0A
Name: draft-li-idr-cong= estion-status-extended-community
=0A
Revision: 00
=0A
Ti= tle: Carry congestion status in BGP extended community
=0A
Docum= ent date: 2016-03-15
=0A
Group: Individual Submission
=0APages: 7
=0A
URL:       &n= bsp;    https://www.ietf.org/internet-drafts/draft-li-idr-c= ongestion-status-extended-community-00.txt
=0A
Status:  = ;       https://datatracker.ietf.org/doc/dra= ft-li-idr-congestion-status-extended-community/
=0A
Htmlized:&nbs= p;      https://tools.ietf.org/html/draft-li-idr-= congestion-status-extended-community-00
=0A
 
=0A
&= nbsp;
=0A
Abstract:
=0A
   A new extended comm= unity is introduced in this document to carry the
=0A
  = ; link congestion status, especially for the exit link of one AS.  We=
=0A
   call this extended community congestion status = community, which can
=0A
   be used by the BGP routers = to steer the Internet-access traffic among
=0A
   the e= xit links by deploying policy routing.
=0A
 
=0A
&n= bsp;
=0A
         &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;            =           
=0A =0A
 
=0A
Please note that it may take a co= uple of minutes from the time of submission
=0A
until the htmlize= d version and diff are available at tools.ietf.org.
=0A
 =0A
The IETF Secretariat
=0A
 
=0A
 =0A
=0A ------=_001_NextPart211871536540_=------ From nobody Wed Mar 16 10:37:05 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F1A112DA4F for ; Wed, 16 Mar 2016 10:37:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com 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 4LbtW31gn7x2 for ; Wed, 16 Mar 2016 10:37:02 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0134.outbound.protection.outlook.com [65.55.169.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EDB412DA50 for ; Wed, 16 Mar 2016 10:36:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=6CI5P0pCZuvGNzQaYhAIudNbrboHwvExebSYjAlYTi0=; b=XFpANyld26/Nc0G13MBQVR5NtTyEq/ehsDfKuy/52iWXY15KdrS5hizjjJ+h49ugD5uVDItJ+0ThmAPr1zp0POgCdODgADt1tX5itGgoOunZIBI0xE5hEOSLnhioRthdk7T7CD9BMiftIqi2DtJAwWOE/nPrHMvgVke/Z0wuZeE= Received: from CO2PR05MB700.namprd05.prod.outlook.com (10.141.229.22) by CO2PR05MB697.namprd05.prod.outlook.com (10.141.229.12) with Microsoft SMTP Server (TLS) id 15.1.434.16; Wed, 16 Mar 2016 17:36:23 +0000 Received: from CO2PR05MB700.namprd05.prod.outlook.com ([10.141.229.22]) by CO2PR05MB700.namprd05.prod.outlook.com ([10.141.229.22]) with mapi id 15.01.0434.016; Wed, 16 Mar 2016 17:36:22 +0000 From: John Scudder To: "idr@ietf. org" Thread-Topic: [Idr] IETF-95 agenda topics Thread-Index: AQHRf6pbwD0unrHOT0eG1DHfd7zerg== Date: Wed, 16 Mar 2016 17:36:22 +0000 Message-ID: <4F251A6B-3F9D-4164-9B3D-EDF3C3828018@juniper.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ndzh.com; dkim=none (message not signed) header.d=none;ndzh.com; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.246.4] x-ms-office365-filtering-correlation-id: 2fc620d0-4805-4e54-f2ee-08d34dc17e14 x-microsoft-exchange-diagnostics: 1; CO2PR05MB697; 5:ty959H+CBVd/obKawCmOsNddceLO7YXOKWP9CHPCwDspFL1wQTNW55WtnAPIvEyFsRjEypeRzPfyM1MC71RsiDOS9U1C0x8EaNm0VW9fmgoF0dHpqC0u2YlwNGmwOQRdTII+/NR+HOqqsO2M0ghdqw==; 24:kCmvHtK+SfgwxMeAs5kzsR1gjJK1Ky8KrFI0Mq6WKyBqC+6LkAxkpQBqghUmTow28lJ8xEOqKoRvCWEvNoLoDMYU88H0rN4LU1WZEJbOsL4= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR05MB697; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:CO2PR05MB697; BCL:0; PCL:0; RULEID:; SRVR:CO2PR05MB697; x-forefront-prvs: 08831F51DC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(54014002)(24454002)(164054003)(82746002)(86362001)(122556002)(5002640100001)(36756003)(83716003)(189998001)(92566002)(586003)(110136002)(3846002)(102836003)(33656002)(77096005)(2950100001)(87936001)(1220700001)(6116002)(2900100001)(1096002)(54356999)(19580405001)(5008740100001)(15975445007)(19580395003)(4326007)(2906002)(66066001)(10400500002)(5004730100002)(99286002)(3660700001)(76176999)(81166005)(50986999)(3280700002)(106116001)(42262002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR05MB697; H:CO2PR05MB700.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: <0F960F9F1DFE4C459AA8BA2060825603@junipernetworks.onmicrosoft.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Mar 2016 17:36:22.7294 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR05MB697 Archived-At: Cc: Hares Susan Subject: Re: [Idr] IETF-95 agenda topics X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 17:37:04 -0000 Reminder, requests by day after tomorrow please.=20 Thanks, --John On Mar 9, 2016, at 9:06 AM, John G.Scudder wrote: >=20 > Folks, >=20 > IDR will meet at IETF-95 on Tuesday, April 5 from 10 a.m. to 12:30 p.m.. = Please forward any IDR agenda items you might have to Sue and me. The dea= dline is March 18 (a week from Friday) by 10:00 U.S. Eastern Time. Priority= will be given to those who get their requests in by the deadline, though i= f agenda space permits it we will consider requests gotten in before March = 28 at 10:00 U.S. Eastern Time. >=20 > If you have previously presented on your topic at an IDR meeting, please = explain in your request what you hope to achieve with your presentation thi= s time. If you have requested to present the same work at multiple WGs, ple= ase note this so that we can coordinate as needed. >=20 > If you plan to make a presentation, please keep in mind the IDR tradition= , "no Internet Draft - no time slot". You should also plan to send your sl= ides to Sue and me no later than 24 hours prior to the meeting, though agai= n, earlier is better. If we don't have your slides by the deadline, you may= lose your slot. Please number your slides for the benefit of remote attend= ees, and if you plan to use any fancy builds or transitions you must arrang= e this with us in advance -- otherwise you should assume your slides may be= converted to PDF and presented from the PDF. >=20 > Finally, if you request an agenda slot, please do so by replying to this = message, making sure to include both Sue and me in the To: or Cc: and don't= change the subject line. Please include the name of the person who will be= presenting and give an estimate for how much time you think you'll need (i= ncluding Q/A). >=20 > There is a checklist for presenting at IDR: https://trac.tools.ietf.org/w= g/idr/trac/wiki/Checklist%20for%20presenting%20at%20an%20IDR%20meeting. Pot= ential presenters, please take a look. Suggestions for improvements to the = chairs, please, or just edit the wiki directly. >=20 > Thanks, >=20 > --John & Sue >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Wed Mar 16 15:57:38 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31A2A12D71F; Wed, 16 Mar 2016 15:57:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.903 X-Spam-Level: X-Spam-Status: No, score=-106.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=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 OTEOV66Ev6nP; Wed, 16 Mar 2016 15:57:35 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D7B012D591; Wed, 16 Mar 2016 15:57:35 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id AF4CD180094; Wed, 16 Mar 2016 15:56:56 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20160316225656.AF4CD180094@rfc-editor.org> Date: Wed, 16 Mar 2016 15:56:56 -0700 (PDT) Archived-At: Cc: drafts-update-ref@iana.org, idr@ietf.org, rfc-editor@rfc-editor.org Subject: [Idr] RFC 7752 on North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 22:57:37 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7752 Title: North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP Author: H. Gredler, Ed., J. Medved, S. Previdi, A. Farrel, S. Ray Status: Standards Track Stream: IETF Date: March 2016 Mailbox: hannes@gredler.at, jmedved@cisco.com, sprevidi@cisco.com, adrian@olddog.co.uk, raysaikat@gmail.com Pages: 48 Characters: 113130 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-idr-ls-distribution-13.txt URL: https://www.rfc-editor.org/info/rfc7752 DOI: http://dx.doi.org/10.17487/RFC7752 In a number of environments, a component external to a network is called upon to perform computations based on the network topology and current state of the connections within the network, including Traffic Engineering (TE) information. This is information typically distributed by IGP routing protocols within the network. This document describes a mechanism by which link-state and TE information can be collected from networks and shared with external components using the BGP routing protocol. This is achieved using a new BGP Network Layer Reachability Information (NLRI) encoding format. The mechanism is applicable to physical and virtual IGP links. The mechanism described is subject to policy control. Applications of this technique include Application-Layer Traffic Optimization (ALTO) servers and Path Computation Elements (PCEs). This document is a product of the Inter-Domain Routing Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Wed Mar 16 17:32:23 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9778A12D7E9 for ; Wed, 16 Mar 2016 17:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.738 X-Spam-Level: * X-Spam-Status: No, score=1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, RDNS_NONE=0.793] autolearn=no autolearn_force=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 zXF3XxV4s2Jv for ; Wed, 16 Mar 2016 17:32:20 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 387D312D7A2 for ; Wed, 16 Mar 2016 17:32:20 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.30; From: "Susan Hares" To: References: <20160316225656.AF4CD180094@rfc-editor.org> In-Reply-To: <20160316225656.AF4CD180094@rfc-editor.org> Date: Wed, 16 Mar 2016 20:31:47 -0400 Message-ID: <040c01d17fe4$64a808e0$2df81aa0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIIEZjqPSYn516/0ZltcMoD16GH9Z7vpVSg Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: [Idr] FW: RFC 7752 on North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 00:32:22 -0000 Congratulations to Hannes, Jan, Stefano, Adrian and Saikat .. Thanks for all the hard work! Sue -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of rfc-editor@rfc-editor.org Sent: Wednesday, March 16, 2016 6:57 PM To: ietf-announce@ietf.org; rfc-dist@rfc-editor.org Cc: drafts-update-ref@iana.org; idr@ietf.org; rfc-editor@rfc-editor.org Subject: [Idr] RFC 7752 on North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP A new Request for Comments is now available in online RFC libraries. RFC 7752 Title: North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP Author: H. Gredler, Ed., J. Medved, S. Previdi, A. Farrel, S. Ray Status: Standards Track Stream: IETF Date: March 2016 Mailbox: hannes@gredler.at, jmedved@cisco.com, sprevidi@cisco.com, adrian@olddog.co.uk, raysaikat@gmail.com Pages: 48 Characters: 113130 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-idr-ls-distribution-13.txt URL: https://www.rfc-editor.org/info/rfc7752 DOI: http://dx.doi.org/10.17487/RFC7752 In a number of environments, a component external to a network is called upon to perform computations based on the network topology and current state of the connections within the network, including Traffic Engineering (TE) information. This is information typically distributed by IGP routing protocols within the network. This document describes a mechanism by which link-state and TE information can be collected from networks and shared with external components using the BGP routing protocol. This is achieved using a new BGP Network Layer Reachability Information (NLRI) encoding format. The mechanism is applicable to physical and virtual IGP links. The mechanism described is subject to policy control. Applications of this technique include Application-Layer Traffic Optimization (ALTO) servers and Path Computation Elements (PCEs). This document is a product of the Inter-Domain Routing Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From nobody Thu Mar 17 14:15:55 2016 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 22AC212D688; Thu, 17 Mar 2016 14:15:53 -0700 (PDT) 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.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160317211553.10442.71452.idtracker@ietfa.amsl.com> Date: Thu, 17 Mar 2016 14:15:53 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-vandevelde-idr-flowspec-path-redirect-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 21:15:53 -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 of the IETF. Title : Flowspec Indirection-id Redirect Authors : Gunter Van de Velde Wim Henderickx Keyur Patel Arjun Sreekantiah Filename : draft-vandevelde-idr-flowspec-path-redirect-02.txt Pages : 10 Date : 2016-03-17 Abstract: Flow-spec is an extension to BGP that allows for the dissemination of traffic flow specification rules. This has many possible applications but the primary one for many network operators is the distribution of traffic filtering actions for DDoS mitigation. The flow-spec standard RFC5575 [2] defines a redirect-to-VRF action for policy-based forwarding but this mechanism is not always sufficient, particular if the redirected traffic needs to be steered into an engineered path or into a service plane. This document defines a new redirect-to-INDIRECTION_ID (32-bit or 128-bit) flow-spec action to provide advanced redirection capabilities. When activated, the flowspec Indirection-id is used to identify the next-hop redirect information within a router locallized Indirection-id table. This allows a flowspec controller to signal redirection towards a next-hop IP address, a shortest path tunnel, a traffic engineered tunnel or a next-next-hop engineered tunnel interface. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-vandevelde-idr-flowspec-path-redirect/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-vandevelde-idr-flowspec-path-redirect-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-vandevelde-idr-flowspec-path-redirect-02 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 Mar 18 11:59:28 2016 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 9326E12D59B; Fri, 18 Mar 2016 11:59:24 -0700 (PDT) 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.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160318185924.17546.90672.idtracker@ietfa.amsl.com> Date: Fri, 18 Mar 2016 11:59:24 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-hao-idr-flowspec-redirect-tunnel-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2016 18:59:24 -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 of the IETF. Title : BGP Flow-Spec Redirect to Tunnel Action Authors : Weiguo Hao Zhenbin Li Lucy Yong Filename : draft-hao-idr-flowspec-redirect-tunnel-01.txt Pages : 9 Date : 2016-03-18 Abstract: This draft defines a new flow-spec action, Redirect-to-Tunnel, and a new sub-TLV for Redirect-to-Tunnel extended community. A BGP UPDATE for a flow-spec NLRI can contain the extended community. When activated, the corresponding flow packets will be encapsulated and carried via a tunnel. The redirect tunnel information is encoded in BGP Path Attribute or extended community [TUNNELENCAPS][MPP] that is carried in the BGP flow-spec UPDATE. The draft expends the tunnel encapsulation attribute [TUNNELENCAPS] to apply to flow-spec SAFI, i.e., 133 and 134. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-hao-idr-flowspec-redirect-tunnel/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-hao-idr-flowspec-redirect-tunnel-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-hao-idr-flowspec-redirect-tunnel-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 Sat Mar 19 12:40:34 2016 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 D085112D59B; Sat, 19 Mar 2016 12:40:30 -0700 (PDT) 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.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160319194030.18968.75936.idtracker@ietfa.amsl.com> Date: Sat, 19 Mar 2016 12:40:30 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-flow-spec-v6-07.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Mar 2016 19:40:31 -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 of the IETF. Title : Dissemination of Flow Specification Rules for IPv6 Authors : Danny McPherson Robert Raszuk Burjiz Pithawala Andy Karch Susan Hares Filename : draft-ietf-idr-flow-spec-v6-07.txt Pages : 10 Date : 2016-03-19 Abstract: Dissemination of Flow Specification Rules [RFC5575] provides a protocol extension for propagation of traffic flow information for the purpose of rate limiting or filtering. The [RFC5575] specifies those extensions for IPv4 protocol data packets. This specification extends the current [RFC5575] and defines changes to the original document in order to make it also usable and applicable to IPv6 data packets. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-flow-spec-v6/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-flow-spec-v6-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-flow-spec-v6-07 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 Sun Mar 20 05:34:23 2016 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 17B7412D5D8; Sun, 20 Mar 2016 05:34:20 -0700 (PDT) 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.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160320123420.6828.96797.idtracker@ietfa.amsl.com> Date: Sun, 20 Mar 2016 05:34:20 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-ls-trill-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Mar 2016 12:34:20 -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 of the IETF. Title : Distribution of TRILL Link-State using BGP Authors : Weiquo Hao Donald E. Eastlake Susan Hares Sujay Gupta Muhammad Durrani Yizhou Li Filename : draft-ietf-idr-ls-trill-01.txt Pages : 13 Date : 2016-03-20 Abstract: This draft describes a TRILL link state and MAC address reachability information distribution mechanism using a BGP LS extension. External components such as an SDN Controller can use the information for topology visibility, troubleshooting, network automation, etc. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-ls-trill/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-ls-trill-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-ls-trill-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 Sun Mar 20 11:18:52 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47B6E12D7F3 for ; Sun, 20 Mar 2016 11:18:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.438 X-Spam-Level: **** X-Spam-Status: No, score=4.438 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DOS_OUTLOOK_TO_MX=2.845, RDNS_NONE=0.793] autolearn=no autolearn_force=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 iRH7PeN6pPfe for ; Sun, 20 Mar 2016 11:18:50 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 1BEAA12D7C9 for ; Sun, 20 Mar 2016 11:18:50 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.77; From: "Susan Hares" To: "'John G.Scudder'" , "'idr@ietf. org'" References: In-Reply-To: Date: Sun, 20 Mar 2016 14:18:09 -0400 Message-ID: <02e301d182d4$dbefab90$93cf02b0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQMK/YYA2r373vk0uZ5gYiF5ji5//Zzvredg Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] IETF-95 agenda topics X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Mar 2016 18:18:51 -0000 The agenda for IDR for IETF-95 has be uploaded. Please let John and I know (by responding to this email) if you asked for a presentation slot, and we did not include you in the agenda. Updates to existing drafts = 3 minutes New drafts = 10 max (gladly take less). A few update slots and 2+ presentation slots are still open. Sue and John -----Original Message----- From: John G.Scudder [mailto:jgs@juniper.net] Sent: Wednesday, March 09, 2016 12:07 PM To: idr@ietf. org Cc: Hares Susan Subject: IETF-95 agenda topics Folks, IDR will meet at IETF-95 on Tuesday, April 5 from 10 a.m. to 12:30 p.m.. Please forward any IDR agenda items you might have to Sue and me. The deadline is March 18 (a week from Friday) by 10:00 U.S. Eastern Time. Priority will be given to those who get their requests in by the deadline, though if agenda space permits it we will consider requests gotten in before March 28 at 10:00 U.S. Eastern Time. If you have previously presented on your topic at an IDR meeting, please explain in your request what you hope to achieve with your presentation this time. If you have requested to present the same work at multiple WGs, please note this so that we can coordinate as needed. If you plan to make a presentation, please keep in mind the IDR tradition, "no Internet Draft - no time slot". You should also plan to send your slides to Sue and me no later than 24 hours prior to the meeting, though again, earlier is better. If we don't have your slides by the deadline, you may lose your slot. Please number your slides for the benefit of remote attendees, and if you plan to use any fancy builds or transitions you must arrange this with us in advance -- otherwise you should assume your slides may be converted to PDF and presented from the PDF. Finally, if you request an agenda slot, please do so by replying to this message, making sure to include both Sue and me in the To: or Cc: and don't change the subject line. Please include the name of the person who will be presenting and give an estimate for how much time you think you'll need (including Q/A). There is a checklist for presenting at IDR: https://trac.tools.ietf.org/wg/idr/trac/wiki/Checklist%20for%20presenting%20 at%20an%20IDR%20meeting. Potential presenters, please take a look. Suggestions for improvements to the chairs, please, or just edit the wiki directly. Thanks, --John & Sue From nobody Mon Mar 21 00:45:11 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CCAA12D6C2 for ; Mon, 21 Mar 2016 00:45:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 i9JgTJGF01od for ; Mon, 21 Mar 2016 00:45:08 -0700 (PDT) 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 B473A12D6BE for ; Mon, 21 Mar 2016 00:45:07 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CLA90210; Mon, 21 Mar 2016 07:45:05 +0000 (GMT) Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 21 Mar 2016 07:45:04 +0000 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.56]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0235.001; Mon, 21 Mar 2016 15:44:53 +0800 From: Qin Wu To: "Stefano Previdi (sprevidi)" , Dhruv Dhody Thread-Topic: [Idr] New Version Notification for draft-previdi-idr-bgpls-te-metric-extensions-00.txt Thread-Index: AQHRcwm7vRpqbvT9R0279KDswNEGUZ9joXUQ Date: Mon, 21 Mar 2016 07:44:53 +0000 Message-ID: References: <20160229103504.4611.47204.idtracker@ietfa.amsl.com> <2E563E2C-6F86-434D-B952-3E03F6136671@cisco.com> <43F9DF2C-9EB6-425B-B3EC-4D944F87E4D7@cisco.com> In-Reply-To: <43F9DF2C-9EB6-425B-B3EC-4D944F87E4D7@cisco.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.78.34] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0201.56EFA682.0037, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.56, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 7530743a99a9070bd17da9ff3e3ab8e5 Archived-At: Cc: idr wg , Dhruv Dhody Subject: Re: [Idr] New Version Notification for draft-previdi-idr-bgpls-te-metric-extensions-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 07:45:10 -0000 SGksIFN0ZWZhbm86DQpZZXMsIGl0IGdvdCBleHBpcmVkIGZvciBhIHdoaWxlLiBXZSBqdXN0IHBh cmsgaXQgdGhlcmUgdG8gd2FpdCBmb3IgYmFzZSB3b3JrIFJGQzc3NTIgdG8gZ28gZm9yIHB1Ymxp Y2F0aW9uLg0KSSBhbSBmaW5lIHdpdGggbWVyZ2luZyB0aGVzZSB0d28uIEJ1dCBJIGFtIG5vdCBz dXJlIHdlIHNob3VsZCBnbyB0aHJvdWdoIGFub3RoZXIgV0cgcHJvY2VzcyBmb3IgaXQuDQoNCi1R aW4NCi0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCuWPkeS7tuS6ujogSWRyIFttYWlsdG86aWRyLWJv dW5jZXNAaWV0Zi5vcmddIOS7o+ihqCBTdGVmYW5vIFByZXZpZGkgKHNwcmV2aWRpKQ0K5Y+R6YCB 5pe26Ze0OiAyMDE25bm0MuaciDI55pelIDIzOjU2DQrmlLbku7bkuro6IERocnV2IERob2R5DQrm ioTpgIE6IGlkciB3ZzsgRGhydXYgRGhvZHkNCuS4u+mimDogUmU6IFtJZHJdIE5ldyBWZXJzaW9u IE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtcHJldmlkaS1pZHItYmdwbHMtdGUtbWV0cmljLWV4dGVu c2lvbnMtMDAudHh0DQoNCkhpIERocnV2LA0KDQpzb3JyeS4gSSBkaWRu4oCZdCBmaW5kIHRoZSBy ZWZlcmVuY2UgdG8gdGhhdCBkcmFmdCBhbmQgaXQgaGFzIGV4cGlyZWQgYSBsb25nIHdoaWxlIGFn by4NCg0KRmluZSBieSBtZSB0byByZS1hY3RpdmF0ZSBpdCBhbmQgbWVyZ2UgdGhlIHR3byAoYXQg dGhpcyBzdGFnZSBpdCB3b3VsZCBtZWFuIG1lcmdlIHRoZSBhdXRob3LigJlzIGxpc3QpLg0KDQpz Lg0KDQoNCj4gT24gRmViIDI5LCAyMDE2LCBhdCA0OjUwIFBNLCBEaHJ1diBEaG9keSA8ZGhydXYu aWV0ZkBnbWFpbC5jb20+IHdyb3RlOg0KPiANCj4gSGkgU3RlZmFubywNCj4gDQo+IFdoYXQgaGFw ZW5zIHRvIGV4aXN0aW5nIFdHIGRyYWZ0IFtodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtaWV0Zi1pZHItdGUtcG0tYmdwLTAyXSB3aGljaCB5b3UgYXJlIGFsc28gYSBjby1hdXRob3I/ IA0KPiANCj4gRGhydXYNCj4gDQo+IE9uIE1vbiwgRmViIDI5LCAyMDE2IGF0IDQ6MTUgUE0sIFN0 ZWZhbm8gUHJldmlkaSAoc3ByZXZpZGkpIDxzcHJldmlkaUBjaXNjby5jb20+IHdyb3RlOg0KPiBI aSwNCj4gDQo+IHRoaXMgZHJhZnQgaXMgYWJvdXQgQkdQTFMgZXh0ZW5zaW9ucyBmb3IgUkZDNzQ3 MSBhbmQgZHJhZnQtaWV0Zi1pc2lzLXRlLW1ldHJpYy1leHRlbnNpb25zLg0KPiANCj4gVGhhbmtz Lg0KPiANCj4gcy4NCj4gDQo+IA0KPiA+IEJlZ2luIGZvcndhcmRlZCBtZXNzYWdlOg0KPiA+DQo+ ID4gRnJvbTogPGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4NCj4gPiBTdWJqZWN0OiBOZXcgVmVy c2lvbiBOb3RpZmljYXRpb24gZm9yIA0KPiA+IGRyYWZ0LXByZXZpZGktaWRyLWJncGxzLXRlLW1l dHJpYy1leHRlbnNpb25zLTAwLnR4dA0KPiA+IERhdGU6IEZlYnJ1YXJ5IDI5LCAyMDE2IGF0IDEx OjM1OjA0IEFNIEdNVCsxDQo+ID4gVG86IENsYXJlbmNlIEZpbHNmaWxzIDxjZmlsc2ZpbEBjaXNj by5jb20+LCBMZXMgR2luc2JlcmcgDQo+ID4gPGdpbnNiZXJnQGNpc2NvLmNvbT4sIFN0ZWZhbm8g UHJldmlkaSA8c3ByZXZpZGlAY2lzY28uY29tPg0KPiA+DQo+ID4NCj4gPiBBIG5ldyB2ZXJzaW9u IG9mIEktRCwgDQo+ID4gZHJhZnQtcHJldmlkaS1pZHItYmdwbHMtdGUtbWV0cmljLWV4dGVuc2lv bnMtMDAudHh0DQo+ID4gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBTdGVmYW5v IFByZXZpZGkgYW5kIHBvc3RlZCB0byB0aGUgDQo+ID4gSUVURiByZXBvc2l0b3J5Lg0KPiA+DQo+ ID4gTmFtZTogICAgICAgICBkcmFmdC1wcmV2aWRpLWlkci1iZ3Bscy10ZS1tZXRyaWMtZXh0ZW5z aW9ucw0KPiA+IFJldmlzaW9uOiAgICAgMDANCj4gPiBUaXRsZTogICAgICAgICAgICAgICAgQkdQ LUxTIFRyYWZmaWMgRW5naW5lZXJpbmcgKFRFKSBNZXRyaWMgRXh0ZW5zaW9ucw0KPiA+IERvY3Vt ZW50IGRhdGU6ICAgICAgICAyMDE2LTAyLTI5DQo+ID4gR3JvdXA6ICAgICAgICAgICAgICAgIElu ZGl2aWR1YWwgU3VibWlzc2lvbg0KPiA+IFBhZ2VzOiAgICAgICAgICAgICAgICA5DQo+ID4gVVJM OiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1w cmV2aWRpLWlkci1iZ3Bscy10ZS1tZXRyaWMtZXh0ZW5zaW9ucy0wMC50eHQNCj4gPiBTdGF0dXM6 ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtcHJldmlkaS1p ZHItYmdwbHMtdGUtbWV0cmljLWV4dGVuc2lvbnMvDQo+ID4gSHRtbGl6ZWQ6ICAgICAgIGh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1wcmV2aWRpLWlkci1iZ3Bscy10ZS1tZXRyaWMt ZXh0ZW5zaW9ucy0wMA0KPiA+DQo+ID4NCj4gPiBBYnN0cmFjdDoNCj4gPiAgIFRoaXMgZG9jdW1l bnQgZGVmaW5lcyBuZXcgQkdQLUxTIFRMVnMgaW4gb3JkZXIgdG8gY2FycnkgdGhlIElHUA0KPiA+ ICAgVHJhZmZpYyBFbmdpbmVlcmluZyBFeHRlbnNpb25zIGRlZmluZWQgaW4gSVMtSVMgYW5kIE9T UEYgcHJvdG9jb2xzLg0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gPiBQbGVhc2Ugbm90ZSB0 aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiANCj4g PiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFp bGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQo+ID4NCj4gPiBUaGUgSUVURiBTZWNyZXRhcmlhdA0K PiA+DQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiBJZHIgbWFpbGluZyBsaXN0DQo+IElkckBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkcg0KPiANCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCklkciBtYWlsaW5nIGxpc3QNCklkckBpZXRmLm9yZw0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZHINCg== From nobody Mon Mar 21 04:45:43 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC45A12D50B for ; Mon, 21 Mar 2016 04:45:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.738 X-Spam-Level: * X-Spam-Status: No, score=1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, RDNS_NONE=0.793] autolearn=no autolearn_force=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 3oVuGPE2U8eG for ; Mon, 21 Mar 2016 04:45:40 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 26F1812D562 for ; Mon, 21 Mar 2016 04:45:40 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.77; From: "Susan Hares" To: "'idr@ietf. org'" References: <20160321114248.31929.98395.idtracker@ietfa.amsl.com> In-Reply-To: <20160321114248.31929.98395.idtracker@ietfa.amsl.com> Date: Mon, 21 Mar 2016 07:44:57 -0400 Message-ID: <019e01d18367$1805d2c0$48117840$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJv8blmVNrk57di7Df600F5I0mdtZ4m6iAQ Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: [Idr] FW: New Version Notification for draft-yong-idr-flowspec-mpls-match-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 11:45:42 -0000 We welcome comments on this BGP flow specification match based on MPLS.=20 Sue, Lucy, Qiandeng, and Jianjie =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D A new version of I-D, draft-yong-idr-flowspec-mpls-match-00.txt has been successfully submitted by Susan Hares and posted to the IETF = repository. Name: draft-yong-idr-flowspec-mpls-match Revision: 00 Title: BGP Flow Specification Filter for MPLS Label Document date: 2016-03-21 Group: Individual Submission Pages: 8 URL: = https://www.ietf.org/internet-drafts/draft-yong-idr-flowspec-mpls-match-0= 0.txt Status: = https://datatracker.ietf.org/doc/draft-yong-idr-flowspec-mpls-match/ Htmlized: = https://tools.ietf.org/html/draft-yong-idr-flowspec-mpls-match-00 Abstract: This draft proposes BGP flow specification rules that are used to filter MPLS labeled packets. = =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. The IETF Secretariat From nobody Mon Mar 21 08:02:47 2016 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 7261C12D50E; Mon, 21 Mar 2016 08:02:46 -0700 (PDT) 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.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160321150246.31959.88273.idtracker@ietfa.amsl.com> Date: Mon, 21 Mar 2016 08:02:46 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgpls-segment-routing-epe-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 15:02:46 -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 of the IETF. Title : Segment Routing BGP 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-03.txt Pages : 19 Date : 2016-03-21 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 peering node topology information (including its peers, interfaces and peering ASs) in a way that is exploitable in order to compute efficient BGP Peering 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-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgpls-segment-routing-epe-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 21 08:53:49 2016 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 4B9E312D891; Mon, 21 Mar 2016 08:53:45 -0700 (PDT) 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.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160321155345.31924.89128.idtracker@ietfa.amsl.com> Date: Mon, 21 Mar 2016 08:53:45 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgp-flowspec-oid-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 15:53:45 -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 of the IETF. Title : Revised Validation Procedure for BGP Flow Specifications Authors : James Uttaro Clarence Filsfils David Smith Juan Alcaide Pradosh Mohapatra Filename : draft-ietf-idr-bgp-flowspec-oid-03.txt Pages : 9 Date : 2016-03-21 Abstract: This document describes a modification to the validation procedure defined in RFC 5575 for the dissemination of BGP flow specifications. RFC 5575 requires that the originator of the flow specification matches the originator of the best-match unicast route for the destination prefix embedded in the flow specification. This allows only BGP speakers within the data forwarding path (such as autonomous system border routers) to originate BGP flow specifications. Though it is possible to disseminate such flow specifications directly from border routers, it may be operationally cumbersome in an autonomous system with a large number of border routers having complex BGP policies. The modification proposed herein enables flow specifications to be originated from a centralized BGP route controller. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-flowspec-oid/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-bgp-flowspec-oid-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-flowspec-oid-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 21 11:28:22 2016 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 D571012D9CF; Mon, 21 Mar 2016 11:28:18 -0700 (PDT) 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.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160321182818.31984.66542.idtracker@ietfa.amsl.com> Date: Mon, 21 Mar 2016 11:28:18 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-liang-idr-bgp-flowspec-label-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 18:28:19 -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 of the IETF. Title : Carrying Label Information for BGP FlowSpec Authors : Qiandeng Liang Susan Hares Jianjie You Robert Raszuk Dan Ma Filename : draft-liang-idr-bgp-flowspec-label-02.txt Pages : 9 Date : 2016-03-21 Abstract: This document specifies a method in which the label mapping information for a particular FlowSpec rule is piggybacked in the same Border Gateway Protocol (BGP) Update message that is used to distribute the FlowSpec rule. Based on the proposed method, the Label Switching Routers (LSRs) (except the ingress LSR) on the Label Switched Path (LSP) can use label to indentify the traffic matching a particular FlowSpec rule; this facilitates monitoring and traffic statistics for FlowSpec rules. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-liang-idr-bgp-flowspec-label/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-liang-idr-bgp-flowspec-label-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-liang-idr-bgp-flowspec-label-02 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 Mar 21 16:38:37 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1660812D1A0; Mon, 21 Mar 2016 16:38:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=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 FpGLP7ADd7n8; Mon, 21 Mar 2016 16:38:29 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 648F212D194; Mon, 21 Mar 2016 16:38:29 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1ai9P2-00085H-8R; Mon, 21 Mar 2016 23:38:28 +0000 Date: Tue, 22 Mar 2016 08:38:27 +0900 Message-ID: From: Randy Bush To: idr wg list , sidr wg list User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: [Idr] New Version Notification for draft-ymbk-idr-bgp-open-policy-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 23:38:31 -0000 A new version of I-D, draft-ymbk-idr-bgp-open-policy-00.txt has been successfully submitted by Randy Bush and posted to the IETF repository. Name: draft-ymbk-idr-bgp-open-policy Revision: 00 Title: Route Leak Detection and Filtering using Roles in Update and Open messages Document date: 2016-03-21 Group: Individual Submission Pages: 8 URL: https://www.ietf.org/internet-drafts/draft-ymbk-idr-bgp-open-policy-00.txt Status: https://datatracker.ietf.org/doc/draft-ymbk-idr-bgp-open-policy/ Htmlized: https://tools.ietf.org/html/draft-ymbk-idr-bgp-open-policy-00 Abstract: Route Leaks are propagation of BGP prefixes which violate assumptions of BGP topology relationships; e.g. passing a route learned from one peer to another peer or to a transit provider, passing a route learned from one transit provider to another transit provider or to a peer. Today, approaches to leak prevention rely on marking routes according to some configuration options without any check of the configuration corresponds to that of the BGP neighbor, or enforcement that the two BGP speakers agree on the relationship. This document enhances BGP Open to establish agreement of the (peer, customer, provider, internal) relationship of two BGP neighboring speakers to enforce appropriate configuration on both sides. Propagated routes are then marked with a flag according to agreed relationship allowing detection and mitigation of route leaks. From nobody Thu Mar 24 08:33:28 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B1DC12DC90; Thu, 24 Mar 2016 08:33:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.929 X-Spam-Level: X-Spam-Status: No, score=-1.929 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=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 5o9BdvnhvD03; Thu, 24 Mar 2016 08:33:23 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor34.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4D5012DD87; Thu, 24 Mar 2016 08:17:33 -0700 (PDT) Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id 56A1740699; Thu, 24 Mar 2016 16:17:32 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.60]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id E3F041A0081; Thu, 24 Mar 2016 16:17:31 +0100 (CET) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM7F.corporate.adroot.infra.ftgroup ([fe80::c1d7:e278:e357:11ad%19]) with mapi id 14.03.0279.002; Thu, 24 Mar 2016 16:17:31 +0100 From: To: Eric C Rosen Thread-Topic: [bess] draft-rosen-mpls-rfc3107bis Thread-Index: AdGF3GeY7oYpWXlDQPavaGqQ0wDeuQ== Date: Thu, 24 Mar 2016 15:17:30 +0000 Message-ID: <3515_1458832652_56F4050B_3515_774_1_53C29892C857584299CBF5D05346208A0F819B1E@OPEXCLILM21.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "idr@ietf.org" , BESS , "mpls@ietf.org" Subject: Re: [Idr] [bess] draft-rosen-mpls-rfc3107bis X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2016 15:33:25 -0000 Hi Eric, Thanks for your reply. Very much appreciated. Sorry for the delay in responding, but I wanted more time to think about it= .=20 I'm fine with all your point, except one. Please see inline [Bruno]. > From: Eric C Rosen [mailto:erosen@juniper.net] > Sent: Friday, January 15, 2016 7:01 PM > To: DECRAENE Bruno IMT/OLN > Cc: idr@ietf.org; BESS; mpls@ietf.org > Subject: Re: [bess] draft-rosen-idr-rfc3107bis-00 >=20 > Bruno, >=20 > Thanks for reviewing the draft! > >> - RFC 3107 provides an encoding that allows BGP to assign multiple > labels > > Upfront, the current issue is that implementations, which claim > compliance with RFC 3107, are just non-compliant. So the draft is proposi= ng > to change the specification to make such implementations compliant, while > another option would be to fix implementation (to be compliant with the > RFC they claim to support). > I think the best approach is to try to write 3107bis in such a way that > the existing deployed implementations are compliant to it. [Bruno] I understand that we have a different perspective on this. Nothing wrong, b= ut please find below mine. On my side, I think that the best approach is to have a 3107bis which is ba= ckward compatible with RFC3107. I don't see why the IEFT would want to create a bis which is not compatible= with the original RFC, especially since this incompatibility may be very d= isruptive in existing networks. > > The main issue I have, is that this draft is not backward compatible wi= th > RFC 3107 (as a RFC 3107 speaker will never notice that its peer has not s= end > the new capability, and may still send multiple labels). Plus in case of = error > due to this incompatibility, the error handling behavior is likely to be = "BGP > session shutdown" (as the NLRI "cannot" be correctly parsed) which is > disruptive. Plus the implementation A not supporting multiple labels, will > claim that the implementation B supporting multiple labels is "not > compliant" with rfc3107bis, while I would rather argue that this is > implementation A which is not compliant with RFC 3107. > Luckily, the existing deployed implementations, as far as I know, do not > support multiple labels. [Bruno] I'm sorry, but I would need more facts on this. In particular which are the= implementations that are known to be incapable of sending multiple labels,= today and in the foreseeable future. And even with such data, there is no guaranty as there may be implementatio= n that we don't know about. Therefore, creating this incompatibility is ris= ky. (Especially for network operator which are the ones which bare the risk) > If a new implementation were to send multiple > labels to an old implementation, we would likely experience the > disruptive behavior you describe. 3107bis tries to prevent this > disruption. 1) again, I appreciate the work being done to handle the fact that some imp= lementations are not compliant with RFC 3107. 2) I think you mean :s/old implementation/non compliant RFC 3107 implementa= tion. As of today "old implementation" are "existing implementations" = and they are supposed to be compliant with RFC 3107. 3) "As far as I know" all the implementations claims to be compliant with R= FC 3107, i.e. are expected to be able to receive multiple labels. And for t= he ones which we are using, they may have written this as part of a contrac= tual agreement. So before considering making a 3107bis which is non backwar= d compatible with RFC 3107, I would like to have the list of those implemen= tations. In the absence of this, I assume that current implementations are = indeed compliant with RFC 3107, just as they claim. Thanks -- Bruno > > > > I'd propose one change: > > - Capability means: I don't support receiving multiple labels, hence you > SHOULD not send that to me. > > - Even if the capability is not advertised by both peers, and hence a s= ingle > label is expected, all implementations MUST check that the "S" bit (in th= is > first label) is set to 1. If the bit is cleared, the Prefix MUST be ident= ified as > per RFC 3107/this document and treated as withdraw as defined in RFC > 7606. > > > > This means more work for rfc3107bis speakers, but we can't ask existing > speakers to do the job. Especially since they were compliant with RFC 310= 7. > If only a single label is expected, there is no real reason to check the > S bit. I'm not sure that all existing implementations actually set the > S bit, so requiring new implementations to check for it would just > introduce a possible backwards compatibility problem. > > Plus very minor comments > > - From an editorial standpoint, I'd personally favor removing =A72.2 and > saying in 2.3(or elsewhere) that if the capability is not exchanged, a si= ngle > label may be encoded. (IMHO duplicating the text is less easy to read and > more error prone. And I believe this would be enough to address your poin= t). > I went back and forth on this issue, and I'd welcome more opinions on > this from the WG. >=20 > You are right that it is generally a bad practice to have so much > duplicated text in a specification, but I thought the intention would be > clearer if the encoding for multiple labels were described separately > from the encoding for single labels. >=20 > > - In Figure 2 (=A72.3), 2 labels are indicated. Do you think there is a= need to > indicate which one is the first (Label 1) and which one is the k th (Labe= l k). > Indeed, the order of the labels is significant when the router will need = to > push them in the dataplane. Or a sentence could be added to make this > explicit. > This is mentioned in the "Data Plane" section, but I think you're right, = it > should be mentioned in section 2.3 as well. >=20 > > - In =A74, there is a possible case which is not described: > > S1 receives L11, L12,... L1k > > S1 sends L21, L12,... L1k > > S1 programs in the data plane: L21 swap L11 > > Compared to sending a single label (L21), S1 avoids having to push k la= bels > in its dataplane, which it may be incapable of. > > - In =A74 > > "While this may be useful in certain scenarios, it may provide unintend= ed > results in other scenarios." I fail to see when this can be useful as N1 = or > downstream LSR will receive packets with labels there are not aware of > (L22...L2k). Out of curiosity, I'm be curious to know the useful scenario= that > you have in mind. > Actually, I was thinking of the case you just described above, but I want= ed to > formulate it in a more general way. For all we know, may be > domain-wide unique labels ;-), or S1 may have some other way of knowing > L21 will get the packet to a node that will be able to understand > . > > - in =A75 " It is possible that a BGP speaker will receive both a SAFI-= 1 route > > for prefix P and a SAFI-4 route for prefix P. The significance of > > this is a matter of local policy." > > For 6PE (rfc4798), may be this should not be a local policy but be spec= ified > as a priori SAFI-1 and SAFI-4 prefix should be comparable. Ideally rfc4798 > could have specified this but I haven't check if it's done. Alternatively= =A75 > could reference this case. > > (Same point for propagation between SAFI-1 and SAFI-4) > In 3107bis, I just tried to capture the fact that different implementatio= ns > handle this differently. If a particular application needs to mandate a > particular behavior, that should be part of the spec for that application. >=20 > Eric ___________________________________________________________________________= ______________________________________________ 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, Orange decline toute responsabilite si ce message a ete altere, 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 authorisation. 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, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Thu Mar 24 11:14:31 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03CEF12D77A; Thu, 24 Mar 2016 11:14:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com 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 bPkud36Ocul4; Thu, 24 Mar 2016 11:14:16 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0107.outbound.protection.outlook.com [207.46.100.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E54B512D7B4; Thu, 24 Mar 2016 11:14:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=3eWGFMTqZBO5se86P8Is8rvLx187jMrIaIOni/jAeyg=; b=KcPjVmaavCW8338V/aOdxvrYE2KRNmPgfTndEyq4cI+HPSKKh6lQ30jfCsXUscFvCo7ypCz2MSw/1QjqN5RShLFgxq76VGXgQTDO4AX/S+iBA1I/ZaWCR3F3kKaeBOoUVZCdEpmmtc7wMa+XAI9dYvV+8UFU1fwhRzcP8kxNv48= Authentication-Results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=juniper.net; Received: from [172.29.32.216] (66.129.241.14) by BLUPR05MB785.namprd05.prod.outlook.com (10.141.209.141) with Microsoft SMTP Server (TLS) id 15.1.443.12; Thu, 24 Mar 2016 18:14:14 +0000 To: References: <3515_1458832652_56F4050B_3515_774_1_53C29892C857584299CBF5D05346208A0F819B1E@OPEXCLILM21.corporate.adroot.infra.ftgroup> From: Eric C Rosen Message-ID: <56F42E71.9020201@juniper.net> Date: Thu, 24 Mar 2016 14:14:09 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <3515_1458832652_56F4050B_3515_774_1_53C29892C857584299CBF5D05346208A0F819B1E@OPEXCLILM21.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [66.129.241.14] X-ClientProxiedBy: DM3PR19CA0007.namprd19.prod.outlook.com (25.164.243.145) To BLUPR05MB785.namprd05.prod.outlook.com (10.141.209.141) X-MS-Office365-Filtering-Correlation-Id: 39a91bfa-fd5f-4f76-38ab-08d354101b95 X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB785; 2:GQbkHMSj4hIrsoxl3A02rnUtzfB7noqcFMFYaY6a3kcvwQ3Pl9hY19YyxC789A8QgVpmfE6pJJYQEt2Ar9tg4fDAEXU07wl2e95xbmZ+7qNnWjeM7D4TLET0aTgeBcJdEDoqscFz3rkCmkR07RJcxI3OYXF7dEL8QNb61+pmgGA8ZF+4e4mNB4o4ITDumAEK; 3:3uyZfemuohwP3UnvdHDDex+c8aHXtYTXEEsyQGgpTx5BAZrH4nRXl5yo5lXawIR7foryvzvRZgRsu6yEbD5lE0Rv35kLiPHh5E7dWe7LdDP5vTJnOYGUObq0cCdwfpKP; 25:KXlOFyPtYsNNY1+8t4c8lrPt5yAWw7RkkkT8LlRcCRGnIsNArwpEFkUDc3ZQtGShld28gIyEgnbg05kc97YRIoARTRqcedKOruLyZkBHssA0bXSzgwzNMAB8DTWaYM+4rI1YgVE/VFBhQRtUvXvfkh2ESo0aHnuaGoB6c0awoF3Xhpxvm42dCz4O4TnUSVKBt20p+iucJz1KH3LjU8yUl9FnjPAY7Jk82MLAK3xf0LLiw7ic7GPeHKcwRHQXA5Qq4Hiwli5eU7kSyHa4Sj6VcOoFxFCB4DIB+tj0jn05U59Sz5HtyPeTHl34oEIl9IrpyWTJlm71//E0xpIPg+lF6O40PAWbv5cSH+gqsD4x8/EcoP9kq3Wt9SPvJzu6eNuqzeIsWT6Uk7HoYxfKw5fJV6gnyLKam+Vm3Uz2EjvUdTu/skR55zVewI7JjBYWWEe0iYb0lqYdaQ9nQhUW5YwXrmCIF5axzbMFUk5ebxJEzRorZKLbfKZ/S/k7upSM4Y9bIeyOpi5rbPq28elQSMigdg== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB785; X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB785; 20:zChs4R39RkyoN8XDF+Sn56izFuo9u6YdP3DLot+lPBQgLiCq7tqO9MfJJoQTPhZzS9M425SdfFqu85HyFUkc1LjPoZ59j7wLrmoFWIyBUkG2fuxHN8UWseS3ax0oj6x1MCwxN4oCKe8ehVubxPvWmrVVOj3XVICGWeA2PDDoQ8yHY50rscGQCCJTtQBoqfw8SjzGajskeQ4RUXT3jXnyJasvMqRw4w28A+NAcHCzQrLSPGSU2BxWFMb2TIESgyDGIS4Cns5ykVOXv7kBSKL8YK7MQxVSipt0vPJ3RGfyg7jjXpBxrMDvWHfE1IPluarKzD335hYCJgzkv3Jes4eLarhSQx8GgLNHxohHyQoS/rZ7+48Zuu+AMomY1UIT2yFOiEV2wANq9RvMBjDutYOROMHwXSxx4ui9wQV3gP4zDlxQFCMK+ZCdeZrGeTSyGl8GHoY2OvHEp3qhCx10/4spmlTIAzbV699YRKtGqZDbbPLMjxublZ11wfAjfj8V3iFS; 4:ecId2KPyClgTgK9TRU7GwD8dVrq4ZIvZPCwqVSCWXTKOdBBIVofvHf1Xm8arMHJvMm8sJTmeeArzg90TaRAkWRc6/ztO2NwC1OZhyS5+BuCIuaK6MTyb01cHwIle319/DJsw63pcLEwCGATye2pM1s3eE8oVN/SMu07bGx9jbrp4QwkvRLsxuZ5C8wSvHT1XKYe1N3v+x87g6xwB1kA7acpXGf2WAaXpbRMz7I3XvDjREC+wMKS0irWVntXyyCsWoeIVj7SLmYjVTUovjSAsJnOT4lBjy7OTQ4nnE+nQfR9dgIJRbhIPvDdUCJqCpf9Z1ng0k/VMhjGuhD2H3J7Rq0KvcXq67+gM44AP8huHXLDYzcOlmkkf9ZVNWd7kfqy3 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:BLUPR05MB785; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB785; X-Forefront-PRVS: 0891BC3F3D X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(377454003)(24454002)(4001350100001)(2351001)(6116002)(586003)(42186005)(23746002)(77096005)(2950100001)(3846002)(4326007)(189998001)(50466002)(5004730100002)(19580405001)(19580395003)(1096002)(36756003)(86362001)(92566002)(83506001)(5008740100001)(65956001)(64126003)(110136002)(47776003)(66066001)(230700001)(33656002)(65816999)(54356999)(87266999)(65806001)(50986999)(59896002)(2906002)(76176999)(230783001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB785; H:[172.29.32.216]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; BLUPR05MB785; 23:UNj+P0S8G9VStfuKVxbUJ/L6SUgU+jmwFQSaT3?= =?Windows-1252?Q?fw41IQc5oOXEt2FGiG3VhGD+X+lrL8wcyGOACJ+edDqLnLEwp71Y6wcj?= =?Windows-1252?Q?RfPKqKxxkKM9THIekSbkbfTdtoZ0DsYjPW/VCSGtztZAoAwMjnHYuUfe?= =?Windows-1252?Q?HHMlrzKzy21dkhwGa72hb+mC1sdaJXPuH4sLRxD0akyX7oyN/HF9JM65?= =?Windows-1252?Q?vGkA4/Oz/IXsX68YDv/2zPUsmFXgGkYzQRwcC1VpgAOsbhHYGPOg/ZUn?= =?Windows-1252?Q?ZoV8p3UNlH6vb0ocm4theU7jkgSB4HnvWs/umLXbrbqXUMHXqLMOgo+W?= =?Windows-1252?Q?K5uZwA6IJBotNxnyUTksUwVRhqGzS0m98rXAcYiQAId2ZG26SmwPptIc?= =?Windows-1252?Q?lRqju/0OLyW5oBXWX1Nsy5JpDbCbNqTUMfhKZTlEDFggW5fN1X+bZ6t6?= =?Windows-1252?Q?vRtzaWBo5Xq4FB2THWZSIksxbZKvZt4ud8sAbN02ngN2Rr8S/9ZqicL4?= =?Windows-1252?Q?dsGMqGf+YBQUyNPqys+xMdFJsSIHLbTGbYHclz0ioCxDbC3LRCXci9rH?= =?Windows-1252?Q?Ek++EPMiZSQ1wu9N9+bnZHXNFG0bveL4aa3Eafx+M9HvwEuASrMr4g6K?= =?Windows-1252?Q?V8gMrFW/Ou3AHTJACqhLADgOBmmukMoFUtDR4HKLtA8vS8ZXxeXhpegO?= =?Windows-1252?Q?v7DvXweWVpNBKCUd/NNtQkMNL33yb/3HQiDwAAI+bX5ggR/78LX1n36I?= =?Windows-1252?Q?sOZIUqmAgGmufHV+N/uHBgdUJkcYdl24pYQq4eoqM1CJhO/alGwvhpV4?= =?Windows-1252?Q?oHicTPDg++Ou8TBTUuONGQYpk+nEVEpu2hhO/6fh9F1eC0EE6g0Ynk+V?= =?Windows-1252?Q?5fOBi8yrIM+JHaybDSXiswu6Ep9JObWM/NbJFF6RVe4nPpwVaZZbPnW6?= =?Windows-1252?Q?Bp3IKpOSbjwLUb4hdK0nDukjHzlMZ1AQ8tSL5pIABne07L0umS5mG3vH?= =?Windows-1252?Q?u0QCmv69tV9qEHWtYJwv/DIhyPiYVOJJ0GTWemFcCehxOWTl9QNG0Rui?= =?Windows-1252?Q?zb0497sW4aURf5N63oxWpyXR5RQ+f3RXCeT48ydHWgq9auvslfiGyWRo?= =?Windows-1252?Q?hbBI5wR+Juhz4d/bgepFRBDaGNRePNF5CZMSYF8mp25W2QstEAy/WrdZ?= =?Windows-1252?Q?nDdc0rcg=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB785; 5:ieu+zdNsIn/nJXPSxj6jZlXMCaf8+vQ+FSKx/NaNdzR3t4rRjJjUIgCqOfC+/E+KqjzkCQQZcFzqz6KYS0yTnmZVhk3hoaiyXfZY2h3Uto4AcVgMuDn67zOlCErPmigQKu59rNJ7m0cN4zfrsN9SFQ==; 24:TRe5cHgMdZatRLpB/cmD2XXQ16RvZDHgQe7eE+zXj5hUI7/mWziAESkTSGwQ/VhwAr23DUL2WZXvizTB6N5UouwQ3Syj50t0nhjNbfLpg2Q= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Mar 2016 18:14:14.0064 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB785 Archived-At: Cc: "idr@ietf.org" , BESS , "mpls@ietf.org" Subject: Re: [Idr] [bess] draft-rosen-mpls-rfc3107bis X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2016 18:14:27 -0000 On 3/24/2016 11:17 AM, bruno.decraene@orange.com wrote: > I don't see why the IETF would want to create a bis which is not compatible with the original RFC, It's typical in a bis draft to remove features that haven't been used. > especially since this incompatibility may be very disruptive in existing networks. My belief is that existing deployments don't use or support the multiple labels feature, and that any attempt to use it as specified in RFC3107 will itself be disruptive to existing networks, because it will have interoperability issues and unpredictable results. Adding the "multiple labels" capability is a way to make the feature deployable without causing disruption. > "As far as I know" all the implementations claim to be compliant with RFC 3107, i.e. are expected to be able to receive multiple labels. I'm quite sure you have deployed implementations, from several prominent vendors, that will not properly handle this case. If you do have a deployed implementation that can receive multiple labels, what would you expect it to do with those labels? RFC 3107 doesn't say anything about what to do in this case, it just provides an encoding. Have you ever tried to use the "multiple labels" feature? From nobody Fri Mar 25 04:26:09 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FBC412D66E; Fri, 25 Mar 2016 04:26:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=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 Mgw_HTrG2kF2; Fri, 25 Mar 2016 04:26:01 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15B5912D68D; Fri, 25 Mar 2016 04:26:01 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 6981D22C750; Fri, 25 Mar 2016 12:25:59 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.31]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 3C66523805C; Fri, 25 Mar 2016 12:25:59 +0100 (CET) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM22.corporate.adroot.infra.ftgroup ([fe80::8c90:f4e9:be28:2a1%19]) with mapi id 14.03.0279.002; Fri, 25 Mar 2016 12:25:58 +0100 From: To: Eric C Rosen Thread-Topic: [bess] draft-rosen-mpls-rfc3107bis Thread-Index: AQHRhfj17oYpWXlDQPavaGqQ0wDeuZ9p2nRA Date: Fri, 25 Mar 2016 11:25:58 +0000 Message-ID: <9656_1458905159_56F52047_9656_7014_1_53C29892C857584299CBF5D05346208A0F81AAA7@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <3515_1458832652_56F4050B_3515_774_1_53C29892C857584299CBF5D05346208A0F819B1E@OPEXCLILM21.corporate.adroot.infra.ftgroup> <56F42E71.9020201@juniper.net> In-Reply-To: <56F42E71.9020201@juniper.net> Accept-Language: fr-FR, en-US Content-Language: fr-FR 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 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.3.25.103616 Archived-At: Cc: "idr@ietf.org" , BESS , "mpls@ietf.org" Subject: Re: [Idr] [bess] draft-rosen-mpls-rfc3107bis X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2016 11:26:03 -0000 > From: Eric C Rosen [mailto:erosen@juniper.net] > Sent: Thursday, March 24= , 2016 7:14 PM > On 3/24/2016 11:17 AM, bruno.decraene@orange.com wrote: > > I don't see why the IETF would want to create a bis which is not > compatible with the original RFC, >=20 > It's typical in a bis draft to remove features that haven't been used. - Not by making it non backward compatible with the current RFC, in a way w= hich is very disruptive (BGP session shut and the session will stay down or= keep cycling) - On a side note, rfc3107bis does not remove the feature to advertise multi= ple labels.=20 =20 > > especially since this incompatibility may be very disruptive in existing > networks. >=20 > My belief is that existing deployments don't use or support the multiple > labels feature, Do you have data that support this? i.e. there are no deployments and no si= ngle implementation which advertise multiple labels? That sounds very hard = to prove. Hence there will be a risk, and this risk is bared by network ope= rators. I don't see a reason why I would take that risk.=20 > and that any attempt to use it as specified in RFC3107 > will itself be disruptive to existing networks, IMHO RFC3107 is clear enough with respect to the encoding of multiple label= s inside the BGP UPDATE. I fail to see which point would not be clear to so= meone. But this is a theoretical discussion since so far, AFAIK, no major implemen= tation has stated that they would not be able to understand NLRI received w= ith multiple labels, and hence would shutdown the BGP session. So I'm waiting for those hypothetical implementations to declare themselves= . Then we'll see if they are compliant with RFC 3107 or if this is rather a= n implementation issue. > because it will have > interoperability issues and unpredictable results. Any non-compliant implementation may create interoperability issues and unp= redictable results. >From an IETF standpoint, the question is whether a RFC 3107 implementation = would create interoperability issues, up to shutting down the BGP session. > Adding the "multiple > labels" capability is a way to make the feature deployable without > causing disruption. I agree with this point. (although one could also discuss this, at it seems a way to accommodate non= -compliant implementation) =20 > > "As far as I know" all the implementations claim to be compliant with R= FC > 3107, i.e. are expected to be able to receive multiple labels. > I'm quite sure you have deployed implementations, from several > prominent vendors, that will not properly handle this case. I'm waiting for this/these implementation(s) to make a public statement in = this thread / IETF WGs. Then we can discuss whether the issue comes from RF= CF3107 or from the implementation. If none make a public statement, we should assume that all implementations = are capable of receiving multiple labels, as per RFC 3107. And hence there = is no need to make a 3107bis which is non backward compatible with RFC 3107. =20 > If you do have a deployed implementation that can receive multiple > labels, what would you expect it to do with those labels?=20 A priori, the sender said "For FEC X, uses this label stack", so any behavi= or compliant with this information e.g. what is described in your bis draft= https://tools.ietf.org/html/draft-rosen-idr-rfc3107bis-00#section-4 > RFC 3107 > doesn't say anything about what to do in this case, it just provides an > encoding. RFC3107 describes the BGP encoding, aka "bits on the wire". It does describe how to send and receive multiple labels from a BGP standpo= int. This does not involve shutting down the BGP session when multiple labe= ls are received. =20 > Have you ever tried to use the "multiple labels" feature? If you mean by following RFC 3107, I'm not seeing why the BGP session would= need to be shutdown. If you mean that some non-compliant implementation do not work, well let's = fix them. And I don't see how making a rfc3107bis non backward compatible with RFC 31= 07 would improve the situation. ___________________________________________________________________________= ______________________________________________ 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, Orange decline toute responsabilite si ce message a ete altere, 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 authorisation. 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, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Fri Mar 25 05:32:36 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85A8B12D6F5; Fri, 25 Mar 2016 05:32:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.139 X-Spam-Level: *** X-Spam-Status: No, score=3.139 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RDNS_NONE=0.793] autolearn=no autolearn_force=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 4hqmXrzQUAgD; Fri, 25 Mar 2016 05:32:34 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 F19E812D6BE; Fri, 25 Mar 2016 05:32:30 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.77; From: "Susan Hares" To: "'idr@ietf. org'" Date: Fri, 25 Mar 2016 08:32:00 -0400 Message-ID: <001f01d18692$54baf1e0$fe30d5a0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0020_01D18670.CDAAD880" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdGGkWHgka5xz/bfSjaesECLoF/rwQ== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: draft-ietf-idr-route-oscillation-stop@ietf.org Subject: [Idr] draft-ietf-idr-route-oscillation-stop - Shepherd's review X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2016 12:32:35 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0020_01D18670.CDAAD880 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Daniel, Alvaro, Enke, John: This is a shepherd's review for draft-ietf-idr-route-oscillation-stop. Apparently, I missed sending the shepherd's report during the first call. I apologize for the delay, but I was waiting for an update for the add-path-guidelines which failed WG LC. At this point, that draft will go back in the queue as WG draft, and we will not hold up these valuable drafts. Sue Hares ================= Status: ready to go to IESG Major/Minor comments: None Editorial comments: Nits Abstract: Old /In this document we present/ New/ This document presents/ [why: Not standard language. ] Section 5.1 and section 5.2 would be clearer to the average reader if you would: Replace in section 5.1 Old /2 or 3 in the ADD-PATH / New/ 2 (send multiple paths) or 3 (send/receive multiple paths) in the ADD-PATH/ Old /1 or 3 for the same/ New /1 (receive multiple paths) or 3 (send/receive multiple paths for the same/ Replace in section 5.2 Old /2 or 3 in the ADD-PATH / New/ 2 (send multiple paths) or 3 (send/receive multiple paths) in the ADD-PATH/ Old /1 or 3 for the same/ New /1 (receive multiple paths) or 3 (send/receive multiple paths for the same/ ------=_NextPart_000_0020_01D18670.CDAAD880 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Daniel, = Alvaro, Enke, John:

 

This is a = shepherd’s review for draft-ietf-idr-route-oscillation-stop. =  Apparently, I missed sending the shepherd’s report during = the first call.

 

I apologize = for the delay, but I was waiting for an update for the = add-path-guidelines which failed WG LC.  At this point, that draft = will go back in the queue as WG draft, and we will not hold up these = valuable drafts.

 

Sue = Hares

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

Status: ready to go to IESG

 

Major/Minor = comments: None

 

Editorial = comments: Nits

 

Abstract: =

Old /In this document we present/ =

New/ This document presents/ =

 

[why:  Not standard language. ]

 

 

Section 5.1 = and section 5.2 would be clearer to the average reader if you = would:

 

Replace in section 5.1

Old /2 or 3 in the ADD-PATH /

New/ 2 (send multiple paths)  or 3 (send/receive = multiple paths) in the ADD-PATH/

 

Old /1 or 3 = for the same/

New /1 (receive = multiple paths) or 3 (send/receive multiple paths for the = same/

 

Replace in section 5.2

 Old /2 or 3 in the ADD-PATH /

New/ 2 (send multiple paths)  or 3 (send/receive = multiple paths) in the ADD-PATH/

 

 

Old /1 or 3 = for the same/

New /1 (receive = multiple paths) or 3 (send/receive multiple paths for the = same/

 

 

------=_NextPart_000_0020_01D18670.CDAAD880-- From nobody Fri Mar 25 05:41:07 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1119012D6DF; Fri, 25 Mar 2016 05:41:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.739 X-Spam-Level: * X-Spam-Status: No, score=1.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RDNS_NONE=0.793] autolearn=no autolearn_force=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 TSC0i0VRcYRC; Fri, 25 Mar 2016 05:41:03 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 3282D12D6BE; Fri, 25 Mar 2016 05:34:24 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.77; From: "Susan Hares" To: "'idr@ietf. org'" References: <001f01d18692$54baf1e0$fe30d5a0$@ndzh.com> In-Reply-To: <001f01d18692$54baf1e0$fe30d5a0$@ndzh.com> Date: Fri, 25 Mar 2016 08:33:54 -0400 Message-ID: <003201d18692$9835b9a0$c8a12ce0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0033_01D18671.112726E0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJwHADPowyCG80nMJCeGXCz75cO6Z4s7PZA Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: draft-ietf-idr-route-oscillation-stop@ietf.org Subject: Re: [Idr] draft-ietf-idr-route-oscillation-stop - Shepherd's review X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2016 12:41:05 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0033_01D18671.112726E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Missed one more nit. Added below. From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Friday, March 25, 2016 8:32 AM To: 'idr@ietf. org' Cc: draft-ietf-idr-route-oscillation-stop@ietf.org Subject: [Idr] draft-ietf-idr-route-oscillation-stop - Shepherd's review Daniel, Alvaro, Enke, John: This is a shepherd's review for draft-ietf-idr-route-oscillation-stop. Apparently, I missed sending the shepherd's report during the first call. I apologize for the delay, but I was waiting for an update for the add-path-guidelines which failed WG LC. At this point, that draft will go back in the queue as WG draft, and we will not hold up these valuable drafts. Sue Hares ================= Status: ready to go to IESG Major/Minor comments: None Editorial comments: Nits Abstract: Old /In this document we present/ New/ This document presents/ [why: Not standard language. ] Section 5.1 and section 5.2 would be clearer to the average reader if you would: Replace in section 5.1 Old /2 or 3 in the ADD-PATH / New/ 2 (send multiple paths) or 3 (send/receive multiple paths) in the ADD-PATH/ Old /1 or 3 for the same/ New /1 (receive multiple paths) or 3 (send/receive multiple paths for the same/ Replace in section 5.2 Old /2 or 3 in the ADD-PATH / New/ 2 (send multiple paths) or 3 (send/receive multiple paths) in the ADD-PATH/ Old /1 or 3 for the same/ New /1 (receive multiple paths) or 3 (send/receive multiple paths for the same/ NITS claim: There are 1 instance of lines with non-RFC5735-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Please fix. ------=_NextPart_000_0033_01D18671.112726E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Missed one more nit.  Added below. =

 

From:= = Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan = Hares
Sent: Friday, March 25, 2016 8:32 AM
To: = 'idr@ietf. org'
Cc: = draft-ietf-idr-route-oscillation-stop@ietf.org
Subject: [Idr] = draft-ietf-idr-route-oscillation-stop - Shepherd's = review

 

Daniel, = Alvaro, Enke, John:

 

This is a = shepherd’s review for draft-ietf-idr-route-oscillation-stop. =  Apparently, I missed sending the shepherd’s report during = the first call.

 

I apologize = for the delay, but I was waiting for an update for the = add-path-guidelines which failed WG LC.  At this point, that draft = will go back in the queue as WG draft, and we will not hold up these = valuable drafts.

 

Sue = Hares

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

Status: ready to go to IESG

 

Major/Minor = comments: None

 

Editorial = comments: Nits

 

Abstract: =

Old /In this document we present/ =

New/ This document presents/ =

 

[why:  Not standard language. ]

 

 

Section 5.1 = and section 5.2 would be clearer to the average reader if you = would:

 

Replace in section 5.1

Old /2 or 3 in the ADD-PATH /

New/ 2 (send multiple paths)  or 3 (send/receive = multiple paths) in the ADD-PATH/

 

Old /1 or 3 = for the same/

New /1 (receive = multiple paths) or 3 (send/receive multiple paths for the = same/

 

Replace in section 5.2

 Old /2 or 3 in the ADD-PATH /

New/ 2 (send multiple paths)  or 3 (send/receive = multiple paths) in the ADD-PATH/

 

 

Old /1 or 3 = for the same/

New /1 (receive = multiple paths) or 3 (send/receive multiple paths for the = same/

 

NITS claim: =

There = are 1 instance of lines with non-RFC5735-compliant IPv4 = addresses

in the = document.  If these are example addresses, they should be = changed.

Please = fix.

 

 

------=_NextPart_000_0033_01D18671.112726E0-- From nobody Fri Mar 25 05:59:47 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90C0112D72E for ; Fri, 25 Mar 2016 05:59:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.638 X-Spam-Level: *** X-Spam-Status: No, score=3.638 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RDNS_NONE=0.793] autolearn=no autolearn_force=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 Ku0TY06spraM for ; Fri, 25 Mar 2016 05:59:44 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 899F312D69E for ; Fri, 25 Mar 2016 05:59:43 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.77; From: "Susan Hares" To: "'John Scudder'" , "'Enke Chen \(enkechen\)'" Date: Fri, 25 Mar 2016 08:59:11 -0400 Message-ID: <005101d18696$20c89e10$6259da30$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0052_01D18674.99B79A50" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdGGlgShINwiF6cCTlepl/rUL17a+g== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: "'idr@ietf. org'" Subject: [Idr] Missing on-list IPR statements for draft-ietf-idr-route-oscillation-stop X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2016 12:59:45 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0052_01D18674.99B79A50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit John and Enke: In reviewing the draft-ietf-idr-route-oscillation-stop draft, I cannot find an IPR statement sent to the list. The IESG desires to have the IPR statement sent to the list. Please take a moment and indicate if you know of any IPR relating to this draft. I cannot forward this to the IESG without these statements. Sue Hares ------=_NextPart_000_0052_01D18674.99B79A50 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

John and = Enke:

 

In reviewing the draft-ietf-idr-route-oscillation-stop = draft, I cannot find an IPR statement sent to the list.   The = IESG desires to have the IPR statement sent to the list.  Please = take a moment and indicate if you know of any IPR relating to this = draft.

 

I cannot forward this to the IESG without these = statements.

 

Sue Hares

------=_NextPart_000_0052_01D18674.99B79A50-- From nobody Fri Mar 25 06:58:26 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCC0112DA57; Fri, 25 Mar 2016 06:58:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.53 X-Spam-Level: X-Spam-Status: No, score=-14.53 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 iOLC9lTZAnq8; Fri, 25 Mar 2016 06:58:23 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30ABB12D8A5; Fri, 25 Mar 2016 06:58:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3575; q=dns/txt; s=iport; t=1458914303; x=1460123903; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=d5DQKSyhY7WDIUHurRlRt9JCFQ1MzUJ/bcYiMDtmTOg=; b=LXogfWxhm3rXfA/fkso/c7NMx1bQJt7SI2A52ypkXhYoXt90aGNJW4uf pXwEV6nAwRoQkckHC97Zzz+HCRuqdrMITeaZNt2MsUV+Ni1nK2Hk4ukYd 0W7jcUWs3/FXd9ckZc4e/JiauD+5fA3w5qkBEtN0an3nKlcnXWk7tnQaq E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AYAgCmQ/VW/4QNJK1dgmJMU30GtWiEb?= =?us-ascii?q?gENgXCGDQKBMDgUAQEBAQEBAWQnhEIBAQQtTBACAQgECjEHMhQRAQEEAQ0FiCf?= =?us-ascii?q?CAwEBAQEBAQEBAQEBAQEBAQEBAQEBARWGHoREihIBBI10hRKEWgGOA4FmjSWGD?= =?us-ascii?q?4h6AR4BAUKDZWyIH34BAQE?= X-IronPort-AV: E=Sophos; i="5.24,391,1454976000"; d="scan'208,217"; a="90180324" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 Mar 2016 13:58:01 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u2PDw0uB001796 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 25 Mar 2016 13:58:00 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 25 Mar 2016 08:58:00 -0500 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, 25 Mar 2016 08:57:59 -0500 From: "Alvaro Retana (aretana)" To: Susan Hares , "'idr@ietf. org'" Thread-Topic: draft-ietf-idr-route-oscillation-stop - Shepherd's review Thread-Index: AdGGkWHgka5xz/bfSjaesECLoF/rwQAFVHyA Date: Fri, 25 Mar 2016 13:57:59 +0000 Message-ID: References: <001f01d18692$54baf1e0$fe30d5a0$@ndzh.com> In-Reply-To: <001f01d18692$54baf1e0$fe30d5a0$@ndzh.com> 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.4] Content-Type: multipart/alternative; boundary="_000_D31ABBD711A2FAaretanaciscocom_" MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-idr-route-oscillation-stop@ietf.org" Subject: Re: [Idr] draft-ietf-idr-route-oscillation-stop - Shepherd's review X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2016 13:58:25 -0000 --_000_D31ABBD711A2FAaretanaciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On 3/25/16, 8:32 AM, "Susan Hares" = > wrote: [Author hat on.] Sue: Hi! This is a shepherd's review for draft-ietf-idr-route-oscillation-stop. App= arently, I missed sending the shepherd's report during the first call. Thanks for the review! I'll post an update when the submission window ope= ns up again. Thanks! Alvaro. --_000_D31ABBD711A2FAaretanaciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
On 3/25/16, 8:32 AM, "Susan Hares" <shares@ndzh.com> wrote:

[Author hat on.]

Sue:

Hi!

This is a shepherd’s review for draft-ietf-idr-route-o= scillation-stop.  Apparently, I missed sending the shepherd’s re= port during the first call.

Thanks for the review!   I'll post an update when the submission = window opens up again.

Thanks!

Alvaro.
--_000_D31ABBD711A2FAaretanaciscocom_-- From nobody Fri Mar 25 07:30:07 2016 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 9F76D12DABA; Fri, 25 Mar 2016 07:30:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160325143005.17967.32459.idtracker@ietfa.amsl.com> Date: Fri, 25 Mar 2016 07:30:05 -0700 Archived-At: Subject: [Idr] The IDR WG has placed draft-yong-idr-flowspec-mpls-match in state "Candidate for WG Adoption" X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2016 14:30:05 -0000 The IDR WG has placed draft-yong-idr-flowspec-mpls-match in state Candidate for WG Adoption (entered by Susan Hares) The document is available at https://datatracker.ietf.org/doc/draft-yong-idr-flowspec-mpls-match/ From nobody Fri Mar 25 07:37:52 2016 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 BF2DC12DABC; Fri, 25 Mar 2016 07:37:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 6.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160325143750.18014.25807.idtracker@ietfa.amsl.com> Date: Fri, 25 Mar 2016 07:37:50 -0700 Archived-At: Subject: [Idr] The IDR WG has placed draft-li-idr-flowspec-redirect-generalized-sid in state "Candidate for WG Adoption" X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2016 14:37:51 -0000 The IDR WG has placed draft-li-idr-flowspec-redirect-generalized-sid in state Candidate for WG Adoption (entered by Susan Hares) The document is available at https://datatracker.ietf.org/doc/draft-li-idr-flowspec-redirect-generalized-sid/ From nobody Fri Mar 25 07:40:08 2016 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 CA14F12DABE; Fri, 25 Mar 2016 07:40:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160325144007.18027.81347.idtracker@ietfa.amsl.com> Date: Fri, 25 Mar 2016 07:40:07 -0700 Archived-At: Subject: [Idr] The IDR WG has placed draft-litkowski-idr-flowspec-interfaceset in state "Candidate for WG Adoption" X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2016 14:40:07 -0000 The IDR WG has placed draft-litkowski-idr-flowspec-interfaceset in state Candidate for WG Adoption (entered by Susan Hares) The document is available at https://datatracker.ietf.org/doc/draft-litkowski-idr-flowspec-interfaceset/ From nobody Fri Mar 25 07:56:11 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F2AC12D665 for ; Fri, 25 Mar 2016 07:56:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.739 X-Spam-Level: * X-Spam-Status: No, score=1.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RDNS_NONE=0.793] autolearn=no autolearn_force=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 ZnetjkIwZmLd for ; Fri, 25 Mar 2016 07:56:04 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 126DB12D1D7 for ; Fri, 25 Mar 2016 07:47:46 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.77; From: "Susan Hares" To: "'idr@ietf. org'" Date: Fri, 25 Mar 2016 10:47:14 -0400 Message-ID: <000401d186a5$38fac760$aaf05620$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01D18683.B1EAAE00" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdGGpJY5wzIcQ0EdQtuQOi1AWSw1Wg== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: [Idr] WG Adoption call for drafts for Flow Specification option 1 (RFC5575 additions (filters/actions) 3/25 to 4/8/2016 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2016 14:56:10 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0005_01D18683.B1EAAE00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit IDR WG: This begins a 2 week WG Call (3/25 to 4/8/2016) for the set of drafts to be considered in RFC5575 additions. These options are filters, actions or critical security additions. The flow specification work has been a part of the interims since IETF 94 https://www.ietf.org/proceedings/interim/2016/02/08/idr/proceedings.html https://www.ietf.org/proceedings/interim/2016/03/07/idr/proceedings.html There will be a brief flow specification presentation at IETF 95, and the email list has select to start with option 1 - extending RFC5575. We also will be gathering details on the SDN/NFV use case for option 2 (new NLRI and Wide Communities support). This is a group call for the drafts to be considered in the flow specification work. For each of the drafts you wish to be considered Option 1, please indicate: 1) If this option is valuable for the DDoS deployments or another critical deployments, 2) Do you feel this draft is useful, but not ready for adoption, 3) Do you feel this draft is a good start for this work. The drafts to consider are: https://datatracker.ietf.org/doc/draft-eddy-idr-flowspec-packet-rate/ https://datatracker.ietf.org/doc/draft-hao-idr-flowspec-nvo3/ https://datatracker.ietf.org/doc/draft-hao-idr-flowspec-redirect-tunnel/ https://datatracker.ietf.org/doc/draft-li-idr-flowspec-redirect-generalized- sid/ https://datatracker.ietf.org/doc/draft-liang-idr-bgp-flowspec-label/ https://datatracker.ietf.org/doc/draft-litkowski-idr-flowspec-interfaceset/ https://datatracker.ietf.org/doc/draft-vandevelde-idr-flowspec-path-redirect / https://datatracker.ietf.org/doc/draft-yong-idr-flowspec-mpls-match/ And for the ordering of these filters and actions drafts - the Option 1 section out of this https://datatracker.ietf.org/doc/draft-hares-idr-flowspec-combo/ (A revised draft with just Option 1 will be posted) Sue Hares and John Scudder ------=_NextPart_000_0005_01D18683.B1EAAE00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

IDR WG: =

 

This begins a 2 week WG Call (3/25 to 4/8/2016) for = the set of drafts to be considered in RFC5575 additions. These options = are filters, actions or critical security additions.  The flow = specification work has been a part of the interims since IETF = 94

https://www.ietf.org/proceedings/interim/2016/02/08/idr/proceedi= ngs.html

https://www.ietf.org/proceedings/interim/2016/03/07/idr/proceedi= ngs.html

 

There will be a brief flow specification presentation = at IETF 95, and the email list has select to start with option 1 – = extending RFC5575.  We also will be gathering details on the = SDN/NFV use case for option 2 (new NLRI and Wide Communities support). =

 

This is a group call for the drafts to be considered = in the flow specification work.  For each of the drafts you wish to = be considered Option 1, please indicate:

 

1)      = If this option is valuable for the DDoS = deployments or another critical deployments,  

2)      = Do you feel this draft is useful, but not ready = for adoption,

3)      = Do you feel this draft is a good start for this = work.

 

The drafts to consider are:

https://datatracker.ietf.org/doc/draft-eddy-idr-flowspec-packet-rat= e/

ht= tps://datatracker.ietf.org/doc/draft-hao-idr-flowspec-nvo3/

https://datatracker.ietf.org/doc/draft-hao-idr-flowspec-redirect= -tunnel/

https://datatracker.ietf.org/doc/draft-li-idr-flowspec-r= edirect-generalized-sid/

https://datatracker.ietf.org/doc/draft-liang-idr-bgp-flowspec-label/=

https://datatracker.ietf.org/doc/draft-litkowski-idr-flowspec= -interfaceset/

https://datatracker.ietf.org/doc/draft-vandevelde-idr-flows= pec-path-redirect/

https://datatracker.ietf.org/doc/draft-yong-idr-flowspec-mpls-match/=

 

And for the ordering of these filters and actions = drafts – the Option 1 section out of this

https://datatracker.ietf.org/doc/draft-hares-idr-flowspec-combo/

(A revised draft with just Option 1 will = be posted)

 

Sue Hares and John Scudder

 

 

 

------=_NextPart_000_0005_01D18683.B1EAAE00-- From nobody Fri Mar 25 08:25:55 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B831712DAFA for ; Fri, 25 Mar 2016 08:25:54 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com 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 lq_nDSLUdVv4 for ; Fri, 25 Mar 2016 08:25:53 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0734.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:734]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F36712DB92 for ; Fri, 25 Mar 2016 08:25:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Ij0OAphUW2YEvYcr7kr+HuXybXpOhoFEdod/slVd4ms=; b=IVd4C7avqRfeADpKJZZgUkU+IQy9RaDB0ZyV/0tFXnTSmyrMEFOZaKNfeckH0KYZtaSTL34e0sjp1HqmLcJ26Jz83asJdGgI0wwjBSyph22w/XfITBoM6PE0D74oMS9Im9iqWgCCV3lk/vCc+vM8jA83b3zgxAGJ0DtVx+clNP8= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; Received: from [172.29.33.135] (66.129.241.14) by BL2PR05MB193.namprd05.prod.outlook.com (10.242.198.143) with Microsoft SMTP Server (TLS) id 15.1.443.12; Fri, 25 Mar 2016 15:25:34 +0000 From: "John G. Scudder" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: <39EE14CE-8B69-4DD6-883F-0700C25A605B@juniper.net> Date: Fri, 25 Mar 2016 11:20:18 -0400 To: idr wg MIME-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) X-Originating-IP: [66.129.241.14] X-ClientProxiedBy: BLUPR14CA0054.namprd14.prod.outlook.com (25.163.209.150) To BL2PR05MB193.namprd05.prod.outlook.com (10.242.198.143) X-MS-Office365-Filtering-Correlation-Id: ebb330fd-8c89-4d1d-9f6b-08d354c1b615 X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB193; 2:vthVoA0RZ72RCsWMZEY7RvIFe3ILUXFIDZAHDcfg0kiOc3LMI8Zk4YV2i3z58waija+mSD1ehD9cD0mibvxd7ygrIksGCbcV9ZAb2MHxl/vXoiuDmQW8rUyo6vmHITGzFBGsKGJUD4U7sDCXiYnuXzPBdv07PVrj2wAM2rnRcGaxxbebpk47ySA19pjcikCk; 3:nmayPWwG4AKV2R+Mc23GEl6EoBrC0BzN+ExERd9Mu4qslVDXDSts/4JkBY88+kqPGlqD6OY6rD4XN5MSosijEV4P3PvdZXwUItyvQcQNYcfw3HghvZ29fZZo3i7PW3sH X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2PR05MB193; X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB193; 25:GZS9B+PN9N+WL8gESZpdEtDrQufGRQn6R17nhahJEbzhAZSiaOzCChgPyVzfR0v20POMzxG7HcJOmvBrrdofgEszmw/hjej+cwWee2dzv50lDZ+Q3dWZhwLd9DHpz83G17SM1PKWbJM+61qDHC7JJaPqqeUA2DuJbD0SOAy/73hhworZOMsRWxJ969YOlm9wuTXig1atKpcfEOFW57iR8RveavicGVmWTpQdC2lxtu/KTSJ7us0AlKfr0xDuFrelPr9kZ255/FuyE3Dt8a0voRJklSLMMOLF8Nrfb1sU6QRCyogBFDTBMECFUmYPoA1U0nPhSnILsNzb75yE4o4vUCQ6thnKhFlt0iYFKkuRazMWnobOjRqmcNFsYAutLq8r1nPK3pHDv7R7ta+UV2inj4RYFH2afnbyaZchZN/o4XXu8mLVDItlpJR4Wh9sPDz0J64H+WbzjyAiG6vBSXdcwakTywTgHT/oY2zhqJbEqWn72D3d4oz928ouEosV/CJMVC+RvOiJ7JOB7zL5XdQKTfTDQYQVDSK7PoB3X91iQoGLbUNSni7Kin3z5yTnUn8qDq3Whg0SWfRb4ddnSriu2SnEonpTNpCD27sYjVHkrw+bPwO/B/KMRV1k8xdEQmd/XMB63fU/nGfxZybuc9y6uD4ElckeuRT/SCUR/u9ZfDA= X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB193; 20:JGgnIVzyu5Bp1yBsjNtXlZIFtdEqnAc4cic7dNZA1Nosx7EGd0hV4KnjN9USFmSpAPoeVbrBu5eN47JNQPQx8Q2Uh96YskO0T0I8goznq/xvCXe6km8DEHwsjNG9xYL0dqXMNYyLHafxGSMXpt3pOScOLa8rJ1c4MHOOYY7NxZQYQmCb4J9BMa48PQQi0aL2z7eI/78zm4H6UaWH/C4xg/E/seDaRo++ihVDOIX0reRXHvZRM+Wr2t9yr/xJH714w+M6nh3P0G1LD+aV61aaOaGYUSVi8J9cXrWwOELpVQ2QHnpPO+MfEjOub5JDknuQneEamcprQQewU4Z5EhzwuMQSWRaXn5cNtpiS4iB5x1mg/98E3FtXJ2FikRGJCQh8eG2khXDC+99FK596ERDFt69M4039Y00itTt6UapfGI+OylYweatcJrE9z1XSY6h1SHT2I39pzM+AY+ew1TL0P582CDkkW0xus9GcMYuD/DGpeTbiND80JEFnYiQfRI+U; 4:ceirWqDZpaWylL+bwmkGXO3qdkCDnjBACfY7XKhn11jR0yM28QK5oenoKkPB5o9eDkh2/wjBux0t+LlLTjcESzv1aazRpc8oyXbhjv/osnU1Xbeclbnu98ZXCaMrtz/VcqPef9AElqr+e4Ef3KcMvEEUGDkvy33nwuKIY50flcTyQhFjsNwYUXgINWMjwco6Mvio7alJGvOMFdoM6IzMcgSa43eoKMlNQeex97Z2nfvQj8Of7ICWoRZLCBJtybHMZS59g3pYyR6e/zhZPle3KJ8HAizgfgjd02rqEfo79qXt+2AQm6m7bMw1nP9PwzkUdW2jwwCMfTCw3pvMDHRKlrAyCh4EkovJqeI85csM6id/zETKAXw16ra7XwVmAMo/ X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:BL2PR05MB193; BCL:0; PCL:0; RULEID:; SRVR:BL2PR05MB193; X-Forefront-PRVS: 0892FA9A88 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(51874003)(53754006)(52044002)(92566002)(450100001)(586003)(1096002)(66066001)(5008740100001)(6116002)(110136002)(81166005)(23726003)(107886002)(42186005)(50466002)(33656002)(5004730100002)(229853001)(50226001)(15975445007)(3846002)(97756001)(189998001)(50986999)(19580395003)(77096005)(2906002)(36756003)(46406003)(47776003)(82746002)(93376004)(57306001)(86362001)(230783001)(83716003)(42262002)(104396002)(15302535012); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR05MB193; H:[172.29.33.135]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BL2PR05MB193; 23:XwFuerQCSlvu9wKJRpQu7Gw6x1O8K/XTvXUzBac15o?= =?us-ascii?Q?7LCpc7EUPnDrffPtrMqGTomJUl11ceE3NuCTSi+HEA4UlpxOOP0QY0CwuAZY?= =?us-ascii?Q?ifVRPN1DDD/Xe/GM0IJS7kkMMMai2dEB/YNgGHQh5DxajIYx08vPa1HthFE3?= =?us-ascii?Q?TMgra0Z9i4U3lEjW/Yzrk8O7j6ZCXW2yNzEjjXGBcH7q8Qof73xWIwdXPVtO?= =?us-ascii?Q?5qSxg6TlxAxYarULjVJcb5Ny3ku2KGN47PF9DxCvghtUOSQvX9c1iy0sWel2?= =?us-ascii?Q?H5/wGGceddYU9tTlUFN4XE6iXFRS3H1BKns2BnyK987qcLD/VSS/2uUrNSDB?= =?us-ascii?Q?dMCrsPb1x5Umy730JyHY/ZieOKCAgGEnXalqgF0G2dhTjt9xKqgR0kE+lNl2?= =?us-ascii?Q?Z9NG7pT50gV7FjZ91l1kH0ztHp/KM/a0c9DfHYTDuXUUCgjTvftDCSxDXSex?= =?us-ascii?Q?0fDDp0rVyfgP633ZH4KlvpiXrquHbjCr9LcOWvu4oaWgZG9sPvHkbxgPmBAa?= =?us-ascii?Q?Mtq+H8QnIRRun8PPUecmBtnlTmMmxZhxB96H1XpiRT/gfl5lU1xGwXkJqaTB?= =?us-ascii?Q?ZlEI/s3pC642/Us/y/m/WjkU0kDS5+ueW7Hx9Q9d8W2KKejz3l8fRTyvmkhC?= =?us-ascii?Q?P2qCSCFsy0YNU08perOVmgdP4gUOmkn7LQUm0Fp8YYzcSNp/+jXeXBcZL6UV?= =?us-ascii?Q?wYBMX9RFsbFvQ7zuaoj2Apk6DeN8ejNKMwWGhgkc53PdOc3Zz6vbufgAYzMx?= =?us-ascii?Q?jrwXB1SJRSjkoaGvKvDmTuLnaGDC/d6IVnegbw0yk3Q1Wd1eYozdEhAcPU94?= =?us-ascii?Q?hI63Ykd6X6jYPCIoDQY0+pdYpvjdQvPGvbDZ0NuYcVNO5bDcHKW1e1cjMoNP?= =?us-ascii?Q?YENcQlUwWXsj+Chx+3srk2aH6bbMvYRCF91tNAcXwYY4mOlVQB2tCaILfx7c?= =?us-ascii?Q?QpwQTpV6kWLjQTI3jLq6n+DUyhh3xwG1jU9TcBzzinDCbZ9nbs0hN4lDZ9TI?= =?us-ascii?Q?cHLION04k5OgfjMNk8QXACbYAhsSwbW0oquJvjyJdx7zX6G/5GVaRWNtmHlM?= =?us-ascii?Q?0DcGzqRu0aUcBsydcLw0apj1miSwrwdiv7VEaGbrO2HKjdhlg8XpsuW2lBWx?= =?us-ascii?Q?pLT25RjcI=3D?= X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB193; 5:bjEOQ2cFcsNfXQew2QgoKy3P3g57wjSWqErBXedJTMG5ba3D3IaVYM4XQOwEsLGRiSlX1HgJm/xmgPmWxjeiyzLHOA+X6Rd4BGG7AmGAaNy4BnOsOAEbbU/N6rRo5gUaF41YNrXBPLesTi1JoTyoJA==; 24:JatrUsVu7UHOOY/ktJ2lF/kPQdjg4llSSNnKFOHpzPTN+RvsijgDOWXQrnR/xYQ+8ume1aHPNrclteT4XgCwmfhPjdDEJOBB3DtcA0br7JQ= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Mar 2016 15:25:34.5763 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR05MB193 Archived-At: Subject: [Idr] Implementations for draft-ietf-idr-rtc-no-rt-04? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2016 15:25:54 -0000 Hi All, As part of advancing draft-ietf-idr-rtc-no-rt I would like to ask for = anyone with an implementation to tell us about it. The easiest way to do = this is to add to the implementation wiki: = http://trac.tools.ietf.org/wg/idr/trac/wiki/draft-ietf-idr-rtc-no-rt%20imp= lementations (and tell us you've done so). However, if you prefer some = other method, that's OK too -- feel free to email your report to me and = I can paste it into the Wiki, for example. Thanks in advance, --John= From nobody Fri Mar 25 08:50:39 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4EE012DC01 for ; Fri, 25 Mar 2016 08:50:38 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com 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 qBJl5aygvXVT for ; Fri, 25 Mar 2016 08:50:34 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0733.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:733]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43E3D12DAD2 for ; Fri, 25 Mar 2016 08:50:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=qzA1hyu1l4+fEKs0BpiG5JMiN0awHKvwJ/ztFfHUSYk=; b=BEp8fHRwB5WuemXtsS+UkrBkIrxWcl1HiTS4YRgPjgEUvtmay4Zd1Sz3qrIKwF0L3T0/WhllL2koviJ9Tu6coyRtabeI5XNsdmAHNaeQFEAuxparwfWV9WYoINBAW6P2yAlECjrUKl98db35HyC4ynryeCTcGjLOXq47iLy3NpM= Authentication-Results: ndzh.com; dkim=none (message not signed) header.d=none;ndzh.com; dmarc=none action=none header.from=juniper.net; Received: from [172.29.33.135] (66.129.241.14) by BN1PR05MB202.namprd05.prod.outlook.com (10.255.206.18) with Microsoft SMTP Server (TLS) id 15.1.434.16; Fri, 25 Mar 2016 15:50:13 +0000 Content-Type: multipart/alternative; boundary="Apple-Mail=_CDF4E201-59EF-49BE-AFE6-EB3F7F63CFA2" MIME-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: "John G. Scudder" In-Reply-To: <005101d18696$20c89e10$6259da30$@ndzh.com> Date: Fri, 25 Mar 2016 11:50:04 -0400 Message-ID: <60DB0B31-981A-484D-BBCD-229C692AF7A9@juniper.net> References: <005101d18696$20c89e10$6259da30$@ndzh.com> To: Susan Hares , "Enke Chen (enkechen)" X-Mailer: Apple Mail (2.2104) X-Originating-IP: [66.129.241.14] X-ClientProxiedBy: SN2PR80CA019.lamprd80.prod.outlook.com (10.141.39.157) To BN1PR05MB202.namprd05.prod.outlook.com (10.255.206.18) X-MS-Office365-Filtering-Correlation-Id: c3c03585-fce7-4d97-daf2-08d354c5293c X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB202; 2:nMIFEZcKgyFLWCPEZHxTivyklp0voe6lWMidzI7eOjStJYhopjQ2z5uFoI9bJu4Jj9qu9rQUna74+UADOUofyjQawQ4kcZIOfxqq25u0RLYMc51dL5sDirrEbIlGajh+pu9nzl8VIe0hP1RJ+KHmBhqMd5+OCGsxnqmxdhpLF+Y9LzMPEeB0OVd4t38PsQa0; 3:7KGZhdwNdFGEJsTaJoEANqlkYuwLJWAgCW9VeVM/e9OR+QwRes3j6vk+UkPjEbD9A0gkLD5b2xLyb2jMs2OJHo11nUfpRiV4quCc2ttIWp/kap+2/Nz+wWlxYOcJMNBR X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB202; X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB202; 25:JIjEdqm5jybb9Tnmq0X/+z4h/ERJTkSAAEq9D5xoWnqCjLzHBV4GiTbdZTmIa+zrUQhKFvsI2ooC/BoC2pcJlpOxtNs7tKV8XaMlaLzUg7IY2YVT4lpHhzCGogB5Hmj+U5fK8R8P3KvSoCdRLHDxz1wJhptAFqGZfjp7ZAoov4s9DjQuUkLQWQAK6DJjZfVUhqroOmFRfUozxZxrwAv7Lzctlb4xmqRQT837b6jwvHWAbe/jbtUF+ZYaV02y8O5xjEMJHQ/l1Gl5xSKqbYySGirFzUhA156RUiQuUvyjrb+zT0Sd/5EeIuzsPwRwxlL+q06imUhDXxTITRg6sbtIV1R6GF4rroSX1yqIRv2Dj+RkR86Cj3btP1W1sM5lAbmLzITu7JXQB/HgSt6EzILpYFSaFecjqKYWqUrmh0beIs/C0sNTEmk4yqoHdM417fD0KcXWrTKMufdNd8umB/yYbMnhWox1A0dfMyO7+81Qy9+vfQ5JZhUJhN6CjfsmmtI1RxjyzHek++u8qwKGP3LSBmNIMtNvuWt9MJop5gO1IiPtKLG9xLOiApagnJCJxSgAuOhXCHUQU3nCTCx6n6VfZgWxvUxrpjcdDQoVBkMwCNmv7CpYoZ2POPl+sP/oe47z0e9OKdCPKDI1RydGi+573VLgBxBGf3FYlcFWLZo7nPmV21BwocQSsKnlIdKZ8hVx X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB202; 20:TFUnXeFSoJu4hEePoWWSlcrf7R3oBHiE0SZdbNnWOKNSnRHCmRbo+/8SCX/dMtuS8hukjxK2HQDFZVxFgyB2t2Qz9WoIxN5/MHcW7eWq1vX6s0/OrCLvaBxBaSB1K4LIc4H8i/vAK4VqpDt+gIaQRbJBOwm5zEYfSDOBN8nY19JzhExu2I49B0guChxdNImh6oZ2HjyReAYT+V914aVX04aEesT4GYhCE/jbKT+wyQwfw9tVbFw8Ou0oO/yddfKYGuguJy0w8nTy+xs7YM1YZuPfhBad9iSTLoYn3+dkK1ji6SW2PGBJyHwF3w+nudiykJJ58SMjyEEuFqTI5ykkxWeiBZahCZGNYKvfu8gvrk03bVO3a22HQLCNlxITgt/TQ/xkujV7i4BpvyQtMxgH38Xwz0sXzNe4nY4Bf+2ZFe4jDDT9WyGYbUZDST54qpF5C/Is0VQtCrByX6hGyrcKr2lTYuFQuv68yp5ZF1UUR5G7pvn4/v5N+PDnw959Hu99; 4:AemUoO2Wyi9bRILp5wQB6hbcn+9/Hs5kuQKkF3eOa47eodpzn0So2ySs2RQX2ITwusMKe5SDP4veFhg7dcH5MDMnvFheQVGw6/HyGIU8ST8CTbk4VxVDKrrLeB61RoRO0L/R3ezDULd2FgNjELEAw+FbAvpfKPjISCFp+zTOu+w7M3CM2hMgE9LIH+qJDE8eYy05ve2RmWM6P8mceEt1Ur1z5DlVd8Tvwf7eQ5d+5q0IoauXW5ibL6vv/7RWHAR7jLPtMJdoKnRLtzAXlNfJbSTBZ6uN/USCkRDIhFCvy+PnrLTdQwUnA9trwcrG8oTem0DPoURNR3yqVYEk+Qw+UuqGpm2UsrIlModXFP7ystoRocjcTvzTDiuePUsunBVR X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:BN1PR05MB202; BCL:0; PCL:0; RULEID:; SRVR:BN1PR05MB202; X-Forefront-PRVS: 0892FA9A88 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(377454003)(24454002)(164054003)(260700001)(4326007)(92566002)(50986999)(81166005)(1096002)(586003)(50226001)(2906002)(3846002)(36756003)(5001770100001)(83716003)(19580405001)(19580395003)(57306001)(86362001)(5008740100001)(82746002)(6116002)(77096005)(42186005)(5004730100002)(2950100001)(189998001)(512954002)(66066001)(230783001)(69556001)(33656002)(76176999)(84326002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB202; H:[172.29.33.135]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN1PR05MB202; 23:nqBBcpcGYrzLoYcDWqXo072nxDx1nu/4AxC/WZ/LLR?= =?us-ascii?Q?7V+ejUu3ccWvXjKrJqSycApUudG/7mhD8evw2zMKDa/rFIN9YUg5D760vf7X?= =?us-ascii?Q?/AbRz8W2v5vYRFkUdAcQf8rOV/DHmsY6qEpn+HpM8a+drUxiAvS1Yk4GUITm?= =?us-ascii?Q?VUIwIxVDDoC5ov7BbXv6bQPgzfIPar9mSuKG/AiHd16etWPfjkbQLmZqyUuP?= =?us-ascii?Q?G3ThLAjOVVm5YUtYYM3rwPoBRKoPv+7+2cAWdPjFxarnOfr64DGVKGKmTVm9?= =?us-ascii?Q?0+L69vorohajng8+WY3I4pcC7eLiadBlnvuYm3SvOo/Winbk0uIPW+VDTbWQ?= =?us-ascii?Q?LCYnlUgdrCAH1qWAGanxAaAwEPYmDVfh/m6QKwiXnbv76aF5S6T4xk2jYLvy?= =?us-ascii?Q?NZtfl3FlUlLb4wf+2valvptnlZex0fLWBnZJ6scVdq+Q+yxF9hznZOpnl+CV?= =?us-ascii?Q?FdmjynPLd6zbT55vKZ4dGjyur387YjBBQ8XU+3jSFvT4i8vB631T05Xy0QRa?= =?us-ascii?Q?r4TjmT1orsI8xS/MGRcHZaqfCoYwowaCtptvfr8SL2Sx26SZkN8h4lKOEt2+?= =?us-ascii?Q?L+76+a4G6d8JGGACqgzsJRVrIeh4kpkZiC4J055dHWQbhFVRIPsY/YFXD57A?= =?us-ascii?Q?uuw3fJoHGja5ebGO8E6y7easgyGZLGljFoLBXyVS/RCHjRXgYWt8hQaFcYRa?= =?us-ascii?Q?sgGAR0zdFqONbSWPHpBm2dUm/QSqCzVLIH3OFHvspCmP0z0n+Ig8Ec7E4wzz?= =?us-ascii?Q?efvM0hkGMKk9/tElM+BwHFKAdik06TLcVNEAqtHMlvU6iXb3n/92LE/vRNPz?= =?us-ascii?Q?oPOYBFnL60/k52OJ3PKEOVFkvssn38bZFb48DBawP9dkQFRsx2S1sjU1/Jjh?= =?us-ascii?Q?ZMa8qyFZ1Wz/k2s3UcBK4iOidBRSHVVkLQm8muK9DZ8CcqqMzA+JD98St7vR?= =?us-ascii?Q?wP/z/XAHvUrbueDjdbYQawaFgrzm7Y8b+N0UI2Sxf6crKCWwNDH18htOGom7?= =?us-ascii?Q?jf0m+wCvxBtOsPJ8Hb9Hb2cTA8ph8/47SErmTcjiHKjg=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB202; 5:kZvELSPJwhF5wBMhckdqVPEzWj5KNmcwSkfd5tXgtcg3TfJn3fq5gbaiLInW9cpvlc9cYAyT4Mi+qQur7Vp8Xr9CobJklMViRYME2M9tkakeopBTRGmZuCFK36fezTwerwB+MrqXMruxlwI4nvztTA==; 24:4+90GXTNoKPqDNoXd184NgTe/vMZyBye0gaBwig+KrNWB1LoC8xu1vX1C13OeNqtykWxmBXG6tgdZgD8eAD7nvq+WAMfjsQxnI4avMiCcIs= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Mar 2016 15:50:13.9060 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB202 Archived-At: Cc: "idr@ietf. org" Subject: Re: [Idr] Missing on-list IPR statements for draft-ietf-idr-route-oscillation-stop X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2016 15:50:39 -0000 --Apple-Mail=_CDF4E201-59EF-49BE-AFE6-EB3F7F63CFA2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" I'm not aware of any IPR relevant to = draft-ietf-idr-route-oscillation-stop. Thanks, --John > On Mar 25, 2016, at 8:59 AM, Susan Hares wrote: >=20 > John and Enke:=20 > =20 > In reviewing the draft-ietf-idr-route-oscillation-stop draft, I cannot = find an IPR statement sent to the list. The IESG desires to have the = IPR statement sent to the list. Please take a moment and indicate if = you know of any IPR relating to this draft.=20 > =20 > I cannot forward this to the IESG without these statements.=20 > =20 > Sue Hares=20 --Apple-Mail=_CDF4E201-59EF-49BE-AFE6-EB3F7F63CFA2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii" I'm not aware of any IPR relevant to = draft-ietf-idr-route-oscillation-stop.

Thanks,

--John

On = Mar 25, 2016, at 8:59 AM, Susan Hares <shares@ndzh.com> = wrote:

John and = Enke: 
 
In = reviewing the draft-ietf-idr-route-oscillation-stop draft, I cannot find = an IPR statement sent to the list.   The IESG desires to have = the IPR statement sent to the list.  Please take a moment and = indicate if you know of any IPR relating to this draft. 
 
I cannot = forward this to the IESG without these statements. 
 
Sue = Hares 

= --Apple-Mail=_CDF4E201-59EF-49BE-AFE6-EB3F7F63CFA2-- From nobody Fri Mar 25 09:30:37 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30C5F12D90B for ; Fri, 25 Mar 2016 09:30:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.53 X-Spam-Level: X-Spam-Status: No, score=-14.53 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 DvGRoTViKvQD for ; Fri, 25 Mar 2016 09:30:33 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CD5C12DC35 for ; Fri, 25 Mar 2016 09:30:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4955; q=dns/txt; s=iport; t=1458923433; x=1460133033; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=BRqG8N5NYYYM0F32D5C1UTXYA1KRJA5oEph87lT96Ag=; b=CtvcdY/nYV8UrdbhjMZv5zEmfBdKmSvgBh0tE/8C+JaWAqCSa1e3Jt1C LMH5/OfBpl+9B/BQn7irlKooxB5E13iaDc7LA1mFz8BVG9btrmhgysdRi i84EssO7IHUqztrZKIGmzPGYHpsLko3A8Fb0J87jNeX+WD52tRy61gjNB g=; X-IronPort-AV: E=Sophos;i="5.24,391,1454976000"; d="scan'208,217";a="252134886" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Mar 2016 16:30:32 +0000 Received: from [10.24.126.148] ([10.24.126.148]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u2PGUV9A006816; Fri, 25 Mar 2016 16:30:32 GMT To: "John G. Scudder" , Susan Hares References: <005101d18696$20c89e10$6259da30$@ndzh.com> <60DB0B31-981A-484D-BBCD-229C692AF7A9@juniper.net> From: Enke Chen Message-ID: <56F567A8.8080709@cisco.com> Date: Fri, 25 Mar 2016 09:30:32 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <60DB0B31-981A-484D-BBCD-229C692AF7A9@juniper.net> Content-Type: multipart/alternative; boundary="------------010501060709060103060408" Archived-At: Cc: "idr@ietf. org" Subject: Re: [Idr] Missing on-list IPR statements for draft-ietf-idr-route-oscillation-stop X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2016 16:30:35 -0000 This is a multi-part message in MIME format. --------------010501060709060103060408 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit I am not aware of any IPR relevant to draft-ietf-idr-route-oscillation-stop. Thanks. -- Enke On 3/25/16 8:50 AM, John G. Scudder wrote: > I'm not aware of any IPR relevant to > draft-ietf-idr-route-oscillation-stop. > > Thanks, > > --John > >> On Mar 25, 2016, at 8:59 AM, Susan Hares > > wrote: >> >> John and Enke: >> In reviewing the draft-ietf-idr-route-oscillation-stop draft, I >> cannot find an IPR statement sent to the list. The IESG desires to >> have the IPR statement sent to the list. Please take a moment and >> indicate if you know of any IPR relating to this draft. >> I cannot forward this to the IESG without these statements. >> Sue Hares > --------------010501060709060103060408 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit I am not aware of any IPR relevant to draft-ietf-idr-route-oscillation-stop.

Thanks.    -- Enke

On 3/25/16 8:50 AM, John G. Scudder wrote:
I'm not aware of any IPR relevant to draft-ietf-idr-route-oscillation-stop.

Thanks,

--John

On Mar 25, 2016, at 8:59 AM, Susan Hares <shares@ndzh.com> wrote:

John and Enke: 
 
In reviewing the draft-ietf-idr-route-oscillation-stop draft, I cannot find an IPR statement sent to the list.   The IESG desires to have the IPR statement sent to the list.  Please take a moment and indicate if you know of any IPR relating to this draft. 
 
I cannot forward this to the IESG without these statements. 
 
Sue Hares 


--------------010501060709060103060408-- From nobody Fri Mar 25 10:41:33 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8E2E12D0DC for ; Fri, 25 Mar 2016 10:41:29 -0700 (PDT) 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, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 fQpUS2cpxakG for ; Fri, 25 Mar 2016 10:41:27 -0700 (PDT) Received: from sz.tsinghua.edu.cn (mail.sz.tsinghua.edu.cn [219.223.190.136]) by ietfa.amsl.com (Postfix) with ESMTP id 901BF12D0FF for ; Fri, 25 Mar 2016 10:41:26 -0700 (PDT) Received: by ajax-webmail-sz.tsinghua.edu.cn (Coremail) ; Sat, 26 Mar 2016 01:39:15 +0800 (GMT+08:00) Date: Sat, 26 Mar 2016 01:39:15 +0800 (GMT+08:00) From: =?GBK?B?0e7K9Q==?= To: idr@ietf.org Message-ID: <66c0c89b.64a6.153aedbd503.Coremail.yang.shu@sz.tsinghua.edu.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=GBK Content-Transfer-Encoding: 7bit X-Originating-IP: [116.7.107.45] X-Priority: 3 X-Mailer: Coremail Webmail Server Version 4.0.8 dev build 20140527(27298.6429.6128) Copyright (c) 2002-2016 www.mailtech.cn sz X-SendMailWithSms: false X-CM-TRANSID: iL7f2wAXqVjEd_VWWpcVAA--.5817W X-CM-SenderInfo: p1dqwhxvkxq232ow2x5qjk3toohg3hdfq/1tbiAQEFDVSatohNbAA AsZ X-Coremail-Antispam: 1Ur529EdanIXcx71UUUUU7IcSsGvfJ3iIAIbVAYjsxI4VW5Jw CS07vEb4IE77IF4wCS07vE1I0E4x80FVAKz4kxMIAIbVAFxVCaYxvI4VCIwcAKzIAtYxBI daVFxhVjvjDU= Archived-At: Cc: fred@cisco.com, shares@ndzh.com, xmw@cernet.edu.cn Subject: [Idr] =?gbk?q?Review_request_for_=22Source/Destination_Routing_Us?= =?gbk?q?ing_BGP-4=A1=B1?= X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2016 17:41:30 -0000 Dear all, We are looking for your comments on the new draft "Source/Destination Routing Using BGP-4". There is active work in rtgwg and homenet about src/dst routing, e.g., https://datatracker.ietf.org/doc/draft-ietf-rtgwg-dst-src-routing, https://datatracker.ietf.org/doc/draft-lamparter-homenet-isis-profile, https://datatracker.ietf.org/doc/draft-ietf-homenet-hncp, https://datatracker.ietf.org/doc/draft-ietf-homenet-dncp. We believe that src/dst routing is also useful in inter-domain routing, for TE, security and policy routing. This document describes source/destination routing using bgp, which add a source prefix into the bgp update message. We would really appreciate any comments and questions about the document. Best Regards, Shu Yang From nobody Fri Mar 25 10:47:13 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A55612D547 for ; Fri, 25 Mar 2016 10:47:12 -0700 (PDT) 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, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 3TT1ZBfyESof for ; Fri, 25 Mar 2016 10:47:10 -0700 (PDT) Received: from sz.tsinghua.edu.cn (mail.sz.tsinghua.edu.cn [219.223.190.136]) by ietfa.amsl.com (Postfix) with ESMTP id 85FB312D527 for ; Fri, 25 Mar 2016 10:47:09 -0700 (PDT) Received: by ajax-webmail-sz.tsinghua.edu.cn (Coremail) ; Sat, 26 Mar 2016 01:45:14 +0800 (GMT+08:00) Date: Sat, 26 Mar 2016 01:45:14 +0800 (GMT+08:00) From: =?GBK?B?0e7K9Q==?= To: idr@ietf.org Message-ID: <538e653f.64aa.153aee14e17.Coremail.yang.shu@sz.tsinghua.edu.cn> In-Reply-To: <66c0c89b.64a6.153aedbd503.Coremail.yang.shu@sz.tsinghua.edu.cn> References: <66c0c89b.64a6.153aedbd503.Coremail.yang.shu@sz.tsinghua.edu.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=GBK Content-Transfer-Encoding: quoted-printable X-Originating-IP: [116.7.107.45] X-Priority: 3 X-Mailer: Coremail Webmail Server Version 4.0.8 dev build 20140527(27298.6429.6128) Copyright (c) 2002-2016 www.mailtech.cn sz X-SendMailWithSms: false X-CM-TRANSID: iL7f2wCnrxMqefVWiJcVAA--.717W X-CM-SenderInfo: p1dqwhxvkxq232ow2x5qjk3toohg3hdfq/1tbiAQEFDVSatohNbQA AsY X-Coremail-Antispam: 1Ur529EdanIXcx71UUUUU7IcSsGvfJ3iIAIbVAYjsxI4VWUCw CS07vEb4IE77IF4wCS07vE1I0E4x80FVAKz4kxMIAIbVAFxVCaYxvI4VCIwcAKzIAtYxBI daVFxhVjvjDU= Archived-At: Subject: Re: [Idr] =?gbk?q?Review_request_for_=22Source/Destination_Routing_Us?= =?gbk?q?ing_BGP-4=A1=B1?= X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2016 17:47:12 -0000 The url is: https://www.ietf.org/internet-drafts/draft-xu-src-dst-bgp-00.tx= t Shu Yang > -----=D4=AD=CA=BC=D3=CA=BC=FE----- > =B7=A2=BC=FE=C8=CB: "=D1=EE=CA=F5" > =B7=A2=CB=CD=CA=B1=BC=E4: 2016=C4=EA3=D4=C226=C8=D5 =D0=C7=C6=DA=C1=F9 > =CA=D5=BC=FE=C8=CB: idr@ietf.org > =B3=AD=CB=CD: fred@cisco.com, shares@ndzh.com, xmw@cernet.edu.cn > =D6=F7=CC=E2: [Idr] Review request for "Source/Destination Routing Using = BGP-4=A1=B1 >=20 > Dear all, > =20 > We are looking for your comments on the new draft "Source/Destination Rou= ting Using BGP-4". >=20 > There is active work in rtgwg and homenet about src/dst routing, e.g., ht= tps://datatracker.ietf.org/doc/draft-ietf-rtgwg-dst-src-routing, https://da= tatracker.ietf.org/doc/draft-lamparter-homenet-isis-profile, https://datatr= acker.ietf.org/doc/draft-ietf-homenet-hncp, https://datatracker.ietf.org/do= c/draft-ietf-homenet-dncp. We believe that src/dst routing is also useful i= n inter-domain routing, for TE, security and policy routing. >=20 > This document describes source/destination routing using bgp, which add a= source prefix into the bgp update message.=20 >=20 > We would really appreciate any comments and questions about the document. > =20 > Best Regards, >=20 > Shu Yang >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Fri Mar 25 11:23:32 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7864F12D5B4 for ; Fri, 25 Mar 2016 11:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 djRLt1lfByUI for ; Fri, 25 Mar 2016 11:23:28 -0700 (PDT) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (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 AD87012D580 for ; Fri, 25 Mar 2016 11:23:27 -0700 (PDT) Received: by mail-lb0-x22b.google.com with SMTP id qe11so51842670lbc.3 for ; Fri, 25 Mar 2016 11:23:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=LsmUlq+yuT4sLVhV67fK+18/3kX5mXZVkwsSmz70s8Y=; b=iV9T4ZVJbh82HglGyHFOCBi5un+UVBD3sjggZjZfalwfWkUJQZwOKIj/v+suml0JcZ rMzB302JWr7OaHHExBm/Zj45wPU+sqeC4YbOZRxa4xUCejHdHe2ihAukTWR5gyc76Hdl fDUVZr0Ace+ym1VTOxkBn73Q9XYqPYo1AdN0omWPSjplSZ81XpUSKE3v49iQWb3tyO++ UF0CEXDtSaGWh3TufBKQIBf0DkWT2uUJHWD+A+YAeZVpKcLF8hw4TfNcRC/GVpX7EFiI gUCQB/rGAKbJ5JBfgDgkcoEz7DdeDxenIOK9f4zk4Qzz4/Z7Ppf6Rbe03/GoKG4jH07J B8Sw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=LsmUlq+yuT4sLVhV67fK+18/3kX5mXZVkwsSmz70s8Y=; b=WLrT73W+pzzlV7jvP6CwOTvsoGYyHP6BfDKOXxjTrxqonCV9sWW6XtIdhNnXvgrSiB iF17EyIzTQy+y6L5w9FVe2SKe5zBiuoOR4mkOMoT7LwtY8hNmqBpRQsv3IY0akOHITPK 61bXfb7HmfuV0Sm75fyCnaV/xEEsS3X/Aa1uMuU34z0Gv5Zr+ExttAg9/j5VXLeqacrP 1a7UlaeJZ2eG20Xs8ytgVWXb7jhqhcoatUB4Cjz4vHydsC5EH/4ekPbpEh75alrzEHX5 cclqqFE4GMXyhNLdniH90ZphqIw5EQM3R6wBpt95l0UuYV4i4uv1LRlaAfqRn6pzpFCn 3TTQ== X-Gm-Message-State: AD7BkJJjpjfIq3agmdON7gVjgicZkbgfKZez9dE5VOOZqVuJyIaMkH+QiVmLSUFx3y7lWcbOAG5n4fiacd9eXQ== MIME-Version: 1.0 X-Received: by 10.112.89.36 with SMTP id bl4mr5990552lbb.37.1458930205770; Fri, 25 Mar 2016 11:23:25 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.25.136.133 with HTTP; Fri, 25 Mar 2016 11:23:25 -0700 (PDT) In-Reply-To: <538e653f.64aa.153aee14e17.Coremail.yang.shu@sz.tsinghua.edu.cn> References: <66c0c89b.64a6.153aedbd503.Coremail.yang.shu@sz.tsinghua.edu.cn> <538e653f.64aa.153aee14e17.Coremail.yang.shu@sz.tsinghua.edu.cn> Date: Fri, 25 Mar 2016 19:23:25 +0100 X-Google-Sender-Auth: mmL9cO3IUt-xvx4r6gq7NL8sXUU Message-ID: From: Robert Raszuk To: =?UTF-8?B?5p2o5pyv?= Content-Type: multipart/alternative; boundary=001a11c378e4aacb99052ee3a8b3 Archived-At: Cc: idr wg Subject: Re: [Idr] =?utf-8?q?Review_request_for_=22Source/Destination_Routing_?= =?utf-8?q?Using_BGP-4=E2=80=9D?= X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2016 18:23:30 -0000 --001a11c378e4aacb99052ee3a8b3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Shu, I am afraid "prepending" new TLV to existing NLRI within MP_REACH_NLRI attribute may not work that well within existing SAFIs both protocol as well as implementation wise. Instead I would recommend to consider reusing Type 1 and Type 2 of already defined Flow_Spec NLRI see RFC5575. That along with draft-ietf-idr-flowspec-redirect-ip-02.txt provides all required BGP protocol mechanism to distribute src-dst based reachability within BGP-4. Best regards, R. On Fri, Mar 25, 2016 at 6:45 PM, =E6=9D=A8=E6=9C=AF wrote: > The url is: > https://www.ietf.org/internet-drafts/draft-xu-src-dst-bgp-00.txt > > Shu Yang > --001a11c378e4aacb99052ee3a8b3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Shu,

I am afraid "prepending" new TLV to existin= g NLRI within MP_REACH_NLRI attribute may not work that well within existin= g SAFIs both protocol as well as implementation wise.=C2=A0

Instead I would recommend to consider= reusing Type 1 and Type 2 of already defined Flow_Spec NLRI see RFC5575.

That along with=C2=A0draft-ietf-idr-flowspec-redirect-i= p-02.txt=C2=A0provides all required BGP protocol mechanism to distri= bute src-dst based reachability within BGP-4.=C2=A0

Best regards,
R.


On Fri, Mar 25, 2016 at 6:45 PM, =E6=9D=A8=E6=9C=AF <yang.shu@sz.tsinghua.edu.cn> wrote:
The url is: htt= ps://www.ietf.org/internet-drafts/draft-xu-src-dst-bgp-00.txt

Shu Yang
--001a11c378e4aacb99052ee3a8b3-- From nobody Sat Mar 26 01:24:44 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E57D512D18E for ; Sat, 26 Mar 2016 01:24:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 pmX1Z_WJX7pp for ; Sat, 26 Mar 2016 01:24:39 -0700 (PDT) Received: from sz.tsinghua.edu.cn (mail.sz.tsinghua.edu.cn [219.223.190.136]) by ietfa.amsl.com (Postfix) with ESMTP id A20D412D157 for ; Sat, 26 Mar 2016 01:24:38 -0700 (PDT) Received: by ajax-webmail-sz.tsinghua.edu.cn (Coremail) ; Sat, 26 Mar 2016 16:22:37 +0800 (GMT+08:00) Date: Sat, 26 Mar 2016 16:22:37 +0800 (GMT+08:00) From: =?UTF-8?B?5p2o5pyv?= To: "Robert Raszuk" Message-ID: <70ad2c84.6514.153b204a279.Coremail.yang.shu@sz.tsinghua.edu.cn> In-Reply-To: References: <66c0c89b.64a6.153aedbd503.Coremail.yang.shu@sz.tsinghua.edu.cn> <538e653f.64aa.153aee14e17.Coremail.yang.shu@sz.tsinghua.edu.cn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_84393_569500483.1458980557086" X-Originating-IP: [183.54.80.170] X-Priority: 3 X-Mailer: Coremail Webmail Server Version 4.0.8 dev build 20140527(27298.6429.6128) Copyright (c) 2002-2016 www.mailtech.cn sz X-SendMailWithSms: false X-CM-TRANSID: iL7f2wAXqVjRRvZWKtcVAA--.5840W X-CM-SenderInfo: p1dqwhxvkxq232ow2x5qjk3toohg3hdfq/1tbiAQEGDVSatohPuQA AsN X-Coremail-Antispam: 1Ur529EdanIXcx71UUUUU7IcSsGvfJ3iIAIbVAYjsxI4VWxJw CS07vEb4IE77IF4wCS07vE1I0E4x80FVAKz4kxMIAIbVAFxVCaYxvI4VCIwcAKzIAtYxBI daVFxhVjvjDU= Archived-At: Cc: idr wg Subject: Re: [Idr] =?utf-8?q?Review_request_for_=22Source/Destination_Routing_?= =?utf-8?q?Using_BGP-4=E2=80=9D?= X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2016 08:24:43 -0000 ------=_Part_84393_569500483.1458980557086 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 RGVhciBSb2JlcnQsCgoKVGhhbmsgeW91IGZvciB5b3VyIHN1Z2dlc3Rpb25zLiAgV2Ugd291bGQg dGFrZSB0aGVtIGludG8gY29uc2lkZXJhdGlvbnMgaW4gdGhlIG5leHQgdmVyc2lvbi4KCgpCZXN0 LAoKClNodSBZYW5nCgoKLS0tLS3ljp/lp4vpgq7ku7YtLS0tLQrlj5Hku7bkuro6ICJSb2JlcnQg UmFzenVrIiA8cm9iZXJ0QHJhc3p1ay5uZXQ+CuWPkemAgeaXtumXtDogMjAxNuW5tDPmnIgyNuaX pSDmmJ/mnJ/lha0K5pS25Lu25Lq6OiAi5p2o5pyvIiA8eWFuZy5zaHVAc3oudHNpbmdodWEuZWR1 LmNuPgrmioTpgIE6ICJpZHIgd2ciIDxpZHJAaWV0Zi5vcmc+CuS4u+mimDogUmU6IFtJZHJdIFJl dmlldyByZXF1ZXN0IGZvciAiU291cmNlL0Rlc3RpbmF0aW9uIFJvdXRpbmcgVXNpbmcgQkdQLTTi gJ0KCgpIaSBTaHUsCgoKSSBhbSBhZnJhaWQgInByZXBlbmRpbmciIG5ldyBUTFYgdG8gZXhpc3Rp bmcgTkxSSSB3aXRoaW4gTVBfUkVBQ0hfTkxSSSBhdHRyaWJ1dGUgbWF5IG5vdCB3b3JrIHRoYXQg d2VsbCB3aXRoaW4gZXhpc3RpbmcgU0FGSXMgYm90aCBwcm90b2NvbCBhcyB3ZWxsIGFzIGltcGxl bWVudGF0aW9uIHdpc2UuIAoKCkluc3RlYWQgSSB3b3VsZCByZWNvbW1lbmQgdG8gY29uc2lkZXIg cmV1c2luZyBUeXBlIDEgYW5kIFR5cGUgMiBvZiBhbHJlYWR5IGRlZmluZWQgRmxvd19TcGVjIE5M Ukkgc2VlIFJGQzU1NzUuCgoKVGhhdCBhbG9uZyB3aXRoIGRyYWZ0LWlldGYtaWRyLWZsb3dzcGVj LXJlZGlyZWN0LWlwLTAyLnR4dCBwcm92aWRlcyBhbGwgcmVxdWlyZWQgQkdQIHByb3RvY29sIG1l Y2hhbmlzbSB0byBkaXN0cmlidXRlIHNyYy1kc3QgYmFzZWQgcmVhY2hhYmlsaXR5IHdpdGhpbiBC R1AtNC4gCgoKQmVzdCByZWdhcmRzLApSLgoKCgoKT24gRnJpLCBNYXIgMjUsIDIwMTYgYXQgNjo0 NSBQTSwg5p2o5pyvIDx5YW5nLnNodUBzei50c2luZ2h1YS5lZHUuY24+IHdyb3RlOgpUaGUgdXJs IGlzOiBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQteHUtc3JjLWRz dC1iZ3AtMDAudHh0CgpTaHUgWWFuZwo= ------=_Part_84393_569500483.1458980557086 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 RGVhciBSb2JlcnQsPGRpdj48YnI+PC9kaXY+PGRpdj5UaGFuayB5b3UgZm9yIHlvdXIgc3VnZ2Vz dGlvbnMuICZuYnNwO1dlIHdvdWxkIHRha2UgdGhlbSBpbnRvIGNvbnNpZGVyYXRpb25zIGluIHRo ZSBuZXh0IHZlcnNpb24uPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5CZXN0LDwvZGl2PjxkaXY+ PGJyPjwvZGl2PjxkaXY+U2h1IFlhbmc8YnI+PGJyPjxicj48YmxvY2txdW90ZSBuYW1lPSJyZXBs eUNvbnRlbnQiIHN0eWxlPSJwYWRkaW5nLWxlZnQ6NXB4O21hcmdpbi1sZWZ0OjVweDtib3JkZXIt bGVmdDojYjZiNmI2IDJweCBzb2xpZDttYXJnaW4tcmlnaHQ6MCI+LS0tLS3ljp/lp4vpgq7ku7Yt LS0tLTxicj4KPGI+5Y+R5Lu25Lq6OjwvYj4gIlJvYmVydCBSYXN6dWsiICZsdDtyb2JlcnRAcmFz enVrLm5ldCZndDs8YnI+CjxiPuWPkemAgeaXtumXtDo8L2I+IDIwMTblubQz5pyIMjbml6Ug5pif 5pyf5YWtPGJyPgo8Yj7mlLbku7bkuro6PC9iPiAi5p2o5pyvIiAmbHQ7eWFuZy5zaHVAc3oudHNp bmdodWEuZWR1LmNuJmd0Ozxicj4KPGI+5oqE6YCBOjwvYj4gImlkciB3ZyIgJmx0O2lkckBpZXRm Lm9yZyZndDs8YnI+CjxiPuS4u+mimDo8L2I+IFJlOiBbSWRyXSBSZXZpZXcgcmVxdWVzdCBmb3Ig IlNvdXJjZS9EZXN0aW5hdGlvbiBSb3V0aW5nIFVzaW5nIEJHUC004oCdPGJyPjxicj48ZGl2IGRp cj0ibHRyIj48ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJp YWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsIj5IaSBTaHUsPC9kaXY+PGRp diBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGlj YSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+PGJyPjwvZGl2PjxkaXYgY2xhc3M9ImdtYWls X2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjtm b250LXNpemU6c21hbGwiPkkgYW0gYWZyYWlkICJwcmVwZW5kaW5nIiBuZXcgVExWIHRvIGV4aXN0 aW5nIE5MUkkgd2l0aGluIE1QX1JFQUNIX05MUkkgYXR0cmlidXRlIG1heSBub3Qgd29yayB0aGF0 IHdlbGwgd2l0aGluIGV4aXN0aW5nIFNBRklzIGJvdGggcHJvdG9jb2wgYXMgd2VsbCBhcyBpbXBs ZW1lbnRhdGlvbiB3aXNlLiZuYnNwOzwvZGl2PjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0 eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNpemU6c21h bGwiPjxicj48L2Rpdj48ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1p bHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsIj5JbnN0ZWFkIEkg d291bGQgcmVjb21tZW5kIHRvIGNvbnNpZGVyIHJldXNpbmcgVHlwZSAxIGFuZCBUeXBlIDIgb2Yg YWxyZWFkeSBkZWZpbmVkIEZsb3dfU3BlYyBOTFJJIHNlZSBSRkM1NTc1LjwvZGl2PjxkaXYgY2xh c3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fu cy1zZXJpZjtmb250LXNpemU6c21hbGwiPjxicj48L2Rpdj48ZGl2IGNsYXNzPSJnbWFpbF9kZWZh dWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1z aXplOnNtYWxsIj5UaGF0IGFsb25nIHdpdGgmbmJzcDs8c3BhbiBzdHlsZT0iZm9udC1zaXplOjFl bTtsaW5lLWhlaWdodDowcHQ7Zm9udC13ZWlnaHQ6Ym9sZDt0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO2ZvbnQtZmFtaWx5OmFyaWFsLHNhbnMtc2VyaWYiPmRyYWZ0LWlldGYtaWRyLWZsb3dzcGVj LXJlZGlyZWN0LWlwLTAyLnR4dDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjFlbTtsaW5l LWhlaWdodDowcHQ7Zm9udC1mYW1pbHk6YXJpYWwsc2Fucy1zZXJpZiI+Jm5ic3A7cHJvdmlkZXMg YWxsIHJlcXVpcmVkIEJHUCBwcm90b2NvbCBtZWNoYW5pc20gdG8gZGlzdHJpYnV0ZSBzcmMtZHN0 IGJhc2VkIHJlYWNoYWJpbGl0eSB3aXRoaW4gQkdQLTQuJm5ic3A7PC9zcGFuPjwvZGl2PjxkaXYg Y2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Es c2Fucy1zZXJpZjtmb250LXNpemU6c21hbGwiPjxicj48L2Rpdj48ZGl2IGNsYXNzPSJnbWFpbF9k ZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9u dC1zaXplOnNtYWxsIj5CZXN0IHJlZ2FyZHMsPC9kaXY+PGRpdiBjbGFzcz0iZ21haWxfZGVmYXVs dCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6 ZTpzbWFsbCI+Ui48L2Rpdj48ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1m YW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsIj48YnI+PC9k aXY+PGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPjxicj48ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+ T24gRnJpLCBNYXIgMjUsIDIwMTYgYXQgNjo0NSBQTSwg5p2o5pyvIDxzcGFuIGRpcj0ibHRyIj4m bHQ7PGEgaHJlZj0ibWFpbHRvOnlhbmcuc2h1QHN6LnRzaW5naHVhLmVkdS5jbiIgdGFyZ2V0PSJf YmxhbmsiPnlhbmcuc2h1QHN6LnRzaW5naHVhLmVkdS5jbjwvYT4mZ3Q7PC9zcGFuPiB3cm90ZTo8 YnI+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44 ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+VGhlIHVybCBp czogPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXh1 LXNyYy1kc3QtYmdwLTAwLnR4dCIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXh1LXNyYy1kc3QtYmdwLTAw LnR4dDwvYT48YnI+Cjxicj4KU2h1IFlhbmc8YnI+PC9ibG9ja3F1b3RlPjwvZGl2PjwvZGl2Pjwv ZGl2Pgo8L2Jsb2NrcXVvdGU+PC9kaXY+ ------=_Part_84393_569500483.1458980557086-- From nobody Mon Mar 28 14:58:23 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9B8512D0A1 for ; Mon, 28 Mar 2016 14:58:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.23 X-Spam-Level: X-Spam-Status: No, score=-4.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 3NuwyrfiUM6N for ; Mon, 28 Mar 2016 14:58:20 -0700 (PDT) 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 2332612D0C1 for ; Mon, 28 Mar 2016 14:58:19 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CGR06380; Mon, 28 Mar 2016 21:58:17 +0000 (GMT) Received: from DFWEML701-CHM.china.huawei.com (10.193.5.50) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 28 Mar 2016 22:58:16 +0100 Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by dfweml701-chm ([10.193.5.50]) with mapi id 14.03.0235.001; Mon, 28 Mar 2016 14:58:08 -0700 From: Lucy yong To: "'idr@ietf. org'" Thread-Topic: BGP FS for MPLS Thread-Index: AdGJPN/nE+xMMFy+S2KBp+w3bSrBqg== Date: Mon, 28 Mar 2016 21:58:08 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D5726CD45@dfweml501-mbb> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.246.147] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D5726CD45dfweml501mbb_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.56F9A8FA.011F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: e86464d8def3b5b483373d016f4fceb2 Archived-At: Subject: [Idr] BGP FS for MPLS X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2016 21:58:23 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D5726CD45dfweml501mbb_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Here are two drafts that address BGP FS for MPLS. We like to get community = feedback on the proposals. https://datatracker.ietf.org/doc/draft-yong-idr-flowspec-mpls-match/ https://datatracker.ietf.org/doc/draft-liang-idr-bgp-flowspec-label/ Look forward to discussing this in Buenos Aires. Lucy --_000_2691CE0099834E4A9C5044EEC662BB9D5726CD45dfweml501mbb_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Here are two drafts that address BGP FS for MPLS. We= like to get community feedback on the proposals.

 

https://datatracker.ietf.org/doc/draft-yong-id= r-flowspec-mpls-match/

https://datatracker.ietf.org/doc/draft-liang-i= dr-bgp-flowspec-label/

 

Look forward to discussing this in Buenos Aires.

 

Lucy

 

--_000_2691CE0099834E4A9C5044EEC662BB9D5726CD45dfweml501mbb_-- From nobody Mon Mar 28 15:26:23 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D548812D55D for ; Mon, 28 Mar 2016 15:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.426 X-Spam-Level: X-Spam-Status: No, score=-0.426 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FAKE_REPLY_C=1.486, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 H1531qpkwWCi for ; Mon, 28 Mar 2016 15:26:21 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 7892C12D0BD for ; Mon, 28 Mar 2016 15:26:21 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id B55B81E83C; Mon, 28 Mar 2016 18:30:17 -0400 (EDT) Date: Mon, 28 Mar 2016 18:30:17 -0400 From: Jeffrey Haas To: Petr Lapukhov Message-ID: <20160328223017.GL2966@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F437107848A5140A6A19222EFFB3481200E2839@PRN-MBX01-2.TheFacebook.com> <3F437107848A5140A6A19222EFFB3481200E2855@PRN-MBX01-2.TheFacebook.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: idr wg , Robert Raszuk Subject: Re: [Idr] Use of BGP for Opaque Signaling X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2016 22:26:23 -0000 On Sun, Mar 13, 2016 at 01:02:15AM +0000, Petr Lapukhov wrote: > Keyur had some suggestions to make this more "domain-unique", I hope he > can comment here as well. I think it's pretty common to feel awkward about > flat name-space, but in general there are way to independently generate > unique identifiers and distribute them out of band. Since there is so many > of them, it is probably better not to include them in specification... While I'd echo some of Robert's comments about Wide communities being a possible fit, I can buy into the argument that it's not quite the right mechanism for the application. That said, Wide communities would certainly help some of the scoping and security considerations. Comments for the draft: For key and value lengths, make them two octets in length. You'll want something bigger than 255 bytes at some point. For the key, consider a consistent leading field prior to the key of 4-byte AS#. This will let you disambiguate your key space across the Internet at least. You might consider a 2 byte "local" value as well, permitting multiple applications within a given AS to work. The leading AS# also provides the ability to easily do some simple policy on key spaces in "interdomain" applications. The general purpose distribution graph problem is ugly as noted elsehwere, but for DC applications I'm not bothered. This may motivate further discussion in that problem space at some point. -- Jeff From nobody Mon Mar 28 15:38:35 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 380C112D587 for ; Mon, 28 Mar 2016 15:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 uuEGtTuiWNo5 for ; Mon, 28 Mar 2016 15:38:23 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 6E03512D57C for ; Mon, 28 Mar 2016 15:38:22 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id CFE161E83C; Mon, 28 Mar 2016 18:42:18 -0400 (EDT) Date: Mon, 28 Mar 2016 18:42:18 -0400 From: Jeffrey Haas To: Susan Hares Message-ID: <20160328224218.GM2966@pfrc.org> References: <20160321114248.31929.98395.idtracker@ietfa.amsl.com> <019e01d18367$1805d2c0$48117840$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <019e01d18367$1805d2c0$48117840$@ndzh.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "'idr@ietf. org'" Subject: Re: [Idr] FW: New Version Notification for draft-yong-idr-flowspec-mpls-match-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2016 22:38:34 -0000 Authors, On Mon, Mar 21, 2016 at 07:44:57AM -0400, Susan Hares wrote: > We welcome comments on this BGP flow specification match based on MPLS. [Note that I'm intentionally avoiding the "which rev of flowspec does this go in" discussion.] For your operator actions: 'e' needs clarification when there is more than one of these set. 'a' is ambiguous when both 'e' and 'a' are set. 'i' may be problematic to implement on some vendors and thus may lead to interoperability issues. This is due to many vendors implementing their firewalling as a ingress-only operation. pos - is this intended to match the magic reserved labels or do you mean this is reserved for future use? I think one of the cases I would have hoped to see is basically an indexed operation. For example, for purposes of matching specific target tunnel endpoints, matching the second from top label (which might *not* be the bottom label) is sometimes interesting, especially for LDP over RSVP. Similarly, it helps spring applications. It seems a little unusual that you've chosen to separate the fate of matching ToS bits from the label itself and are only examining the top label's bits. Any particular reason? -- Jeff From nobody Tue Mar 29 14:56:21 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8320A12D821 for ; Tue, 29 Mar 2016 14:56:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.231 X-Spam-Level: X-Spam-Status: No, score=-4.231 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 LeVcEXqAqG5l for ; Tue, 29 Mar 2016 14:56:17 -0700 (PDT) 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 6060E12D85E for ; Tue, 29 Mar 2016 14:56:15 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CLJ67417; Tue, 29 Mar 2016 21:56:13 +0000 (GMT) Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml708-cah.china.huawei.com (10.201.5.202) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 29 Mar 2016 22:56:12 +0100 Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by dfweml705-chm ([10.193.5.142]) with mapi id 14.03.0235.001; Tue, 29 Mar 2016 14:56:00 -0700 From: Lucy yong To: Jeffrey Haas , Susan Hares Thread-Topic: [Idr] FW: New Version Notification for draft-yong-idr-flowspec-mpls-match-00.txt Thread-Index: AQHRg2bNcXuabPdx30axpCdXw0Weep9vfmwhgAF9mEA= Date: Tue, 29 Mar 2016 21:56:00 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D5726E458@dfweml501-mbb> References: <20160321114248.31929.98395.idtracker@ietfa.amsl.com> <019e01d18367$1805d2c0$48117840$@ndzh.com> <20160328224218.GM2966@pfrc.org> In-Reply-To: <20160328224218.GM2966@pfrc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.184] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.56FAF9FD.0296, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 10599dfe844b12414e367dcb722c497b Archived-At: Cc: "'idr@ietf. org'" Subject: Re: [Idr] FW: New Version Notification for draft-yong-idr-flowspec-mpls-match-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2016 21:56:19 -0000 Hi Jeff, Thank you very much for the comment and suggestion. The draft is for the wo= rk initiative and need to work in the WG to specify them properly. Please s= ee inline below. -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jeffrey Haas Sent: Monday, March 28, 2016 5:42 PM To: Susan Hares Cc: 'idr@ietf. org' Subject: Re: [Idr] FW: New Version Notification for draft-yong-idr-flowspec= -mpls-match-00.txt Authors, On Mon, Mar 21, 2016 at 07:44:57AM -0400, Susan Hares wrote: > We welcome comments on this BGP flow specification match based on MPLS.=20 [Note that I'm intentionally avoiding the "which rev of flowspec does this = go in" discussion.] For your operator actions: 'e' needs clarification when there is more than one of these set. [[Lucy]] OK. this bit indicates the last on the list.=20 'a' is ambiguous when both 'e' and 'a' are set. [[Lucy]] When both 'e' and 'a' are set, means that both the label in previo= us pair and the label value in last pair need to be matched. 'i' may be problematic to implement on some vendors and thus may lead to in= teroperability issues. This is due to many vendors implementing their fire= walling as a ingress-only operation. [[Lucy]] understand. if we have use cases for both, i.e., matching before a= nd after label stack operation, protocol need to support it. If not, no ne= ed to be complex. pos - is this intended to match the magic reserved labels or do you mean th= is is reserved for future use? [[Lucy]] this is another one for WG thinking a bit. I am not sure we need s= pecial indication for magic reserved labels. Pos:00 with a reserved label value serves the purpose too. Maybe valuable t= o fast filter for magic reserved label? I think one of the cases I would have hoped to see is basically an indexed = operation. For example, for purposes of matching specific target tunnel en= dpoints, matching the second from top label (which might *not* be the botto= m label) is sometimes interesting, especially for LDP over RSVP. Similarly, it helps spring applications. [[Lucy]] Good suggestion. We can add this in next version. However, the ind= ex may be easy to prune an operation error as pop/push operation along the = path. It needs to be specific. It seems a little unusual that you've chosen to separate the fate of matchi= ng ToS bits from the label itself and are only examining the top label's bi= ts. Any particular reason? [[Lucy]] Initial thought is that they mean differently, FlowSpec may want t= o monitor traffic per label(s) or per QoS class. If true, this way will is = operation simpler. Like to hear the community feedback on this. Thanks, Lucy=20 -- Jeff _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From nobody Thu Mar 31 11:22:13 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93D5812D710 for ; Thu, 31 Mar 2016 11:22:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.53 X-Spam-Level: X-Spam-Status: No, score=-14.53 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 bythu729RmBx for ; Thu, 31 Mar 2016 11:22:10 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B691112D0F4 for ; Thu, 31 Mar 2016 11:22:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14106; q=dns/txt; s=iport; t=1459448529; x=1460658129; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=Sc3TTDL/mRJ9wkTCeG61g00Rf9mizHtmxheJ5esrrXY=; b=Ss8UTDES1zeLwzPxQaJzTcwSJJBtqyJwC+7Ffi5fwZtAJyhouOksxw+m nMgI8WXQMWPjCZtYm6TKGHATOFsK8xT6FCGZqj6Ruhy4dnU4i9hkOkGsI a1NfsUDek43B24H/hFFv5f8E1SN3lmyqNYTHeOkpeYM7XjoK/25rubbpK Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DQAQBuaf1W/xbLJq1dgmiBH30GhT+1U?= =?us-ascii?q?QENgXEjhBOBVwKBexQBAQEBAQEBZSeEQQEBAQQdEFwCAQgOAwMBAiQEBzIUCQg?= =?us-ascii?q?BAQQBEhSIEw7CbgEBAQEBAQEBAQEBAQEBAQEBAQEBAREEhh6ERoE3glcRAT4Nh?= =?us-ascii?q?SkFjX+JcwGFcogVgWaETYhajxQBHgEBQoIEDQwVgTVsAYc4Nn4BAQE?= X-IronPort-AV: E=Sophos;i="5.24,423,1454976000"; d="scan'208,217";a="676463004" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Mar 2016 18:22:07 +0000 Received: from XCH-RTP-019.cisco.com (xch-rtp-019.cisco.com [64.101.220.159]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u2VIM6Sf028044 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 31 Mar 2016 18:22:07 GMT Received: from xch-rtp-019.cisco.com (64.101.220.159) by XCH-RTP-019.cisco.com (64.101.220.159) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 31 Mar 2016 14:22:05 -0400 Received: from xch-rtp-019.cisco.com ([64.101.220.159]) by XCH-RTP-019.cisco.com ([64.101.220.159]) with mapi id 15.00.1104.009; Thu, 31 Mar 2016 14:22:05 -0400 From: "Mohammed Mirza (mohamirz)" To: Susan Hares , "'idr@ietf. org'" Thread-Topic: [Idr] WG Adoption call for drafts for Flow Specification option 1 (RFC5575 additions (filters/actions) 3/25 to 4/8/2016 Thread-Index: AdGGpJY5wzIcQ0EdQtuQOi1AWSw1WgEvHxWA Date: Thu, 31 Mar 2016 18:22:05 +0000 Message-ID: References: <000401d186a5$38fac760$aaf05620$@ndzh.com> In-Reply-To: <000401d186a5$38fac760$aaf05620$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.9.151119 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.154.56.226] Content-Type: multipart/alternative; boundary="_000_D322B1D311D83mohamirzciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] WG Adoption call for drafts for Flow Specification option 1 (RFC5575 additions (filters/actions) 3/25 to 4/8/2016 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2016 18:22:12 -0000 --_000_D322B1D311D83mohamirzciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Sue, John, Support: https://datatracker.ietf.org/doc/draft-vandevelde-idr-flowspec-pat= h-redirect/ I support the above draft that proposes use of a newly defined BGP extended= Indirection_ID community. This new ext-comm looks like a good alternate to= the "redirect-to-VRF" action for redirecting traffic towards an alternate = destination and thus facilitating policy-based forwarding defined in flow-s= pec standard RFC5575. Thanks, Mohammed From: Idr > on behalf of = Susan Hares > Date: Friday, March 25, 2016 at 7:47 AM To: "'idr@ietf. org'" > Subject: [Idr] WG Adoption call for drafts for Flow Specification option 1 = (RFC5575 additions (filters/actions) 3/25 to 4/8/2016 IDR WG: This begins a 2 week WG Call (3/25 to 4/8/2016) for the set of drafts to be= considered in RFC5575 additions. These options are filters, actions or cri= tical security additions. The flow specification work has been a part of t= he interims since IETF 94 https://www.ietf.org/proceedings/interim/2016/02/08/idr/proceedings.html https://www.ietf.org/proceedings/interim/2016/03/07/idr/proceedings.html There will be a brief flow specification presentation at IETF 95, and the e= mail list has select to start with option 1 - extending RFC5575. We also w= ill be gathering details on the SDN/NFV use case for option 2 (new NLRI and= Wide Communities support). This is a group call for the drafts to be considered in the flow specificat= ion work. For each of the drafts you wish to be considered Option 1, pleas= e indicate: 1) If this option is valuable for the DDoS deployments or another crit= ical deployments, 2) Do you feel this draft is useful, but not ready for adoption, 3) Do you feel this draft is a good start for this work. The drafts to consider are: https://datatracker.ietf.org/doc/draft-eddy-idr-flowspec-packet-rate/ https://datatracker.ietf.org/doc/draft-hao-idr-flowspec-nvo3/ https://datatracker.ietf.org/doc/draft-hao-idr-flowspec-redirect-tunnel/ https://datatracker.ietf.org/doc/draft-li-idr-flowspec-redirect-generalized= -sid/ https://datatracker.ietf.org/doc/draft-liang-idr-bgp-flowspec-label/ https://datatracker.ietf.org/doc/draft-litkowski-idr-flowspec-interfaceset/ https://datatracker.ietf.org/doc/draft-vandevelde-idr-flowspec-path-= redirect/ https://datatracker.ietf.org/doc/draft-yong-idr-flowspec-mpls-match/ And for the ordering of these filters and actions drafts - the Option 1 sec= tion out of this https://datatracker.ietf.org/doc/draft-hares-idr-flowspec-combo/ (A revised draft with just Option 1 will be posted) Sue Hares and John Scudder --_000_D322B1D311D83mohamirzciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <017E0B7024935C41AF1169D964B0488F@emea.cisco.com> Content-Transfer-Encoding: quoted-printable

I support the above draft that proposes use of a newly defined BGP ext= ended Indirection_ID community. This new ext-comm looks like a good alterna= te to the "redirect-to-VRF" action for redirecting traffic toward= s an alternate destination and thus facilitating policy-based forwarding defined in flow-spec standard RFC5575.

Thanks,
Mohammed



From: Idr <idr-bounces@ietf.org> on behalf of Susan Hares &l= t;shares@ndzh.com>
Date: Friday, March 25, 2016 at 7:4= 7 AM
To: "'idr@ietf. org'" <= ;idr@ietf.org>
Subject: [Idr] WG Adoption call for= drafts for Flow Specification option 1 (RFC5575 additions (filters/actions= ) 3/25 to 4/8/2016

IDR WG:

 

This begins a 2 week WG Call (3/25 to 4/8/2016) for = the set of drafts to be considered in RFC5575 additions. These options are = filters, actions or critical security additions.  The flow specificati= on work has been a part of the interims since IETF 94

https://www.ietf.org/proceedings/interim/2= 016/02/08/idr/proceedings.html

https://www.ietf.org/proceedings/interim/2= 016/03/07/idr/proceedings.html

 

There will be a brief flow specification presentatio= n at IETF 95, and the email list has select to start with option 1 – = extending RFC5575.  We also will be gathering details on the SDN/NFV u= se case for option 2 (new NLRI and Wide Communities support).

 

This is a group call for the drafts to be considered= in the flow specification work.  For each of the drafts you wish to b= e considered Option 1, please indicate:

 

1) &nbs= p;    If this option is valuable for the DDoS deploym= ents or another critical deployments,  

2) &nbs= p;    Do you feel this draft is useful, but not ready= for adoption,

3) &nbs= p;    Do you feel this draft is a good start for this= work.

 

The drafts to consider are:

https://datatracker.ietf.org/doc/draft-eddy-i= dr-flowspec-packet-rate/

https://datatracker.ietf.org/doc/draft-hao-idr-flowsp= ec-nvo3/

https://datatracker.ietf.org/doc/draft-hao= -idr-flowspec-redirect-tunnel/

https://datatracker.ietf.org/doc/d= raft-li-idr-flowspec-redirect-generalized-sid/

https://datatracker.ietf.org/doc/draft-liang-i= dr-bgp-flowspec-label/

https://datatracker.ietf.org/doc/draft-= litkowski-idr-flowspec-interfaceset/

https://datatra= cker.ietf.org/doc/draft-vandevelde-idr-flowspec-path-redirect/

https://datatracker.ietf.org/doc/draft-yong-id= r-flowspec-mpls-match/

 

And for the ordering of these filters and actions dr= afts – the Option 1 section out of this

https://datatracker.ietf.org/doc/draft-hares-idr-f= lowspec-combo/

(A revised draft with just Option 1 will be posted) =

 

Sue Hares and John Scudder

 

 

 

 --_000_D322B1D311D83mohamirzciscocom_-- From nobody Thu Mar 31 11:53:38 2016 Return-Path: <7riw77@gmail.com> X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4E9612D6D0 for ; Thu, 31 Mar 2016 11:53:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Y0_p7K6rWLxA for ; Thu, 31 Mar 2016 11:53:35 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::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 EC2FE12D74C for ; Thu, 31 Mar 2016 11:53:34 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id g3so109305189ywa.3 for ; Thu, 31 Mar 2016 11:53:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=knEgs8MqyBFuXNJ7d0qWercEX8vZxLY1wirmAzwAlyY=; b=IYw/kDDs5YQoZ/EwTlaMAJFb1ZHb2le0T76zssMmK0lDN+tvNaCTXQqLHoziEfsuVF dlRe+9EaX9dYWmGPssNnoozDefXBhuPOds4636783asFspcKnU7qYDK+TA+Of1GgeHAn 4hDZYKlQCTUsOjSNlnYZMLokUZyxmESLO68cPgPys1vw/x+EoW2GZyu0OfNJ+qmvEU3N TSo8X/SPGo01ABP6FIRbxVX9/BGmfqJVO0kKYtaLJo+j8sErcmJe98aDJPHmJ1USPt+I W8tX2Dtcp59pH63jbGoEV5+Va6b5YU7ZYICUdqDp6dA7r4Q9smM7P104CKJfP43fyZ6+ y4qQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=knEgs8MqyBFuXNJ7d0qWercEX8vZxLY1wirmAzwAlyY=; b=b628b14ap29HcguyS9LQqBlECexYc6hK9KT+ZKQdaItM5GxGpsA/DuTPQKFapA7Wgg 0gQFLVbxUXj+tBwyWLSifk8M9STaIa/kLOD8hi/xcI9b+qlBSeQ3OkmE9rlH56VYPg0/ THbhOd+M70J7JCQlGdQVMe4JrkIMuZ2LN03DIrGVL4tfY6n5BI5GYEaG+ke1frbLTY1p yj9GgVWT/2nq+KvAUzy4PZbzJ+oflVTTBUQGYXopkZvMvpGJlt1qLdeR2mftYJ4dpUlc TelDuWazCOeTy2pHv4Xi8UkXzs7yD/tWq2nn187UsZPj+fIqOopbO3+eAv3WQHziJj+s PBOg== X-Gm-Message-State: AD7BkJIpciwmVdLTjD9lOqNgmRfW8Igp91fVAzbfmJZcHUxb7t+bFYRzM9JK+syP4tpusw== X-Received: by 10.37.1.86 with SMTP id 83mr834024ybb.171.1459450414263; Thu, 31 Mar 2016 11:53:34 -0700 (PDT) Received: from Russ (162-229-180-77.lightspeed.rlghnc.sbcglobal.net. [162.229.180.77]) by smtp.gmail.com with ESMTPSA id x64sm6379776ywe.31.2016.03.31.11.53.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 31 Mar 2016 11:53:33 -0700 (PDT) From: "Russ White" <7riw77@gmail.com> To: "'Susan Hares'" , "'idr@ietf. org'" References: <000401d186a5$38fac760$aaf05620$@ndzh.com> In-Reply-To: <000401d186a5$38fac760$aaf05620$@ndzh.com> Date: Thu, 31 Mar 2016 14:53:32 -0400 Message-ID: <02b801d18b7e$9f8fda00$deaf8e00$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQK70ORPhcSvFaBBkJVzSCfrhkxPup2fWN5A Content-Language: en-us Archived-At: Subject: Re: [Idr] WG Adoption call for drafts for Flow Specification option 1 (RFC5575 additions (filters/actions) 3/25 to 4/8/2016 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2016 18:53:37 -0000 > https://datatracker.ietf.org/doc/draft-eddy-idr-flowspec-packet-rate/ Support -- seems useful for DDoS protection. > https://datatracker.ietf.org/doc/draft-hao-idr-flowspec-nvo3/ Support. > https://datatracker.ietf.org/doc/draft-li-idr-flowspec-redirect-general > ized-sid/ Support. > https://datatracker.ietf.org/doc/draft-liang-idr-bgp-flowspec-label/ Support. > https://datatracker.ietf.org/doc/draft-litkowski-idr-flowspec-interface > set/ Support. > lized-sid/> Support. > https://datatracker.ietf.org/doc/draft-vandevelde-idr-flowspec-path-redi > rect/ Support. > https://datatracker.ietf.org/doc/draft-yong-idr-flowspec-mpls-match/ Support. > https://datatracker.ietf.org/doc/draft-hao-idr-flowspec-redirect-tunnel This one seems a little dangerous to me... Do we have actual use cases for this? What protection would there be against forming permanent, stable, routing loops when using this -- which would be particularly bad in the case of copied packets looping back to the point of copy, and being recopied? I guess there's always TTL, but... This one I would need to think about more before supporting in full. /R From nobody Thu Mar 31 12:12:23 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C790B12D770 for ; Thu, 31 Mar 2016 12:12:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.53 X-Spam-Level: X-Spam-Status: No, score=-14.53 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 WjDxtT6OsR98 for ; Thu, 31 Mar 2016 12:12:19 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E842112D107 for ; Thu, 31 Mar 2016 12:12:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13955; q=dns/txt; s=iport; t=1459451539; x=1460661139; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=FP4CdFzKtIKBHCBlFBn96vDk4IpCOnRDQyBAxUxLoNs=; b=XPaWqSLwU2P6G3i5hr9mALsPVYaI+g5zieQPmJ263dZW+X6QlyR9E+jP p6IXLoEgdcwcBcG+nBhRJk25t/3+BpBX7Kp7Y3pD+qrWnd9ICr/KLm4Vw JJXE5t3Coc2+soMF8wRGCtvlIbIWHWOLVSLZk8hJmv9D5fVpzmNG3FWXg o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ACAgDHdf1W/4QNJK1dgmhMU30GhT+1U?= =?us-ascii?q?AENgXEjhBOBVwKBQzgUAQEBAQEBAWUnhEEBAQEEHRBcAgEIDgMDAQIkBAcyFAk?= =?us-ascii?q?IAQEEARKIJw7CfgEBAQEBAQEBAQEBAQEBAQEBAQEBAREEimSBN4JXEQE+DYUpB?= =?us-ascii?q?Y1/iXMBhXKIFYFmhE2IWo8UAR4BAUKCBA0MFYE1bAGHODZ+AQEB?= X-IronPort-AV: E=Sophos;i="5.24,423,1454976000"; d="scan'208,217";a="254037791" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 31 Mar 2016 19:12:17 +0000 Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u2VJCHOD007695 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 31 Mar 2016 19:12:17 GMT Received: from xch-rcd-007.cisco.com (173.37.102.17) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 31 Mar 2016 14:12:10 -0500 Received: from xch-rcd-007.cisco.com ([173.37.102.17]) by XCH-RCD-007.cisco.com ([173.37.102.17]) with mapi id 15.00.1104.009; Thu, 31 Mar 2016 14:12:10 -0500 From: "Dongling Duan (duan)" To: Susan Hares , "'idr@ietf. org'" Thread-Topic: [Idr] WG Adoption call for drafts for Flow Specification option 1 (RFC5575 additions (filters/actions) 3/25 to 4/8/2016 Thread-Index: AdGGpJY5wzIcQ0EdQtuQOi1AWSw1WgEvHxWAAAPYhQA= Date: Thu, 31 Mar 2016 19:12:10 +0000 Message-ID: References: <000401d186a5$38fac760$aaf05620$@ndzh.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.6.141106 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.154.36.115] Content-Type: multipart/alternative; boundary="_000_D322C45147C82duanciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] WG Adoption call for drafts for Flow Specification option 1 (RFC5575 additions (filters/actions) 3/25 to 4/8/2016 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2016 19:12:22 -0000 --_000_D322C45147C82duanciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Support https://datatracker.ietf.org/doc/draft-vandevelde-idr-flowspec-path-redire= ct/ Dongling duan Thx From: Idr > on behalf of = Susan Hares > Date: Friday, March 25, 2016 at 7:47 AM To: "'idr@ietf. org'" > Subject: [Idr] WG Adoption call for drafts for Flow Specification option 1 = (RFC5575 additions (filters/actions) 3/25 to 4/8/2016 IDR WG: This begins a 2 week WG Call (3/25 to 4/8/2016) for the set of drafts to be= considered in RFC5575 additions. These options are filters, actions or cri= tical security additions. The flow specification work has been a part of t= he interims since IETF 94 https://www.ietf.org/proceedings/interim/2016/02/08/idr/proceedings.html https://www.ietf.org/proceedings/interim/2016/03/07/idr/proceedings.html There will be a brief flow specification presentation at IETF 95, and the e= mail list has select to start with option 1 - extending RFC5575. We also w= ill be gathering details on the SDN/NFV use case for option 2 (new NLRI and= Wide Communities support). This is a group call for the drafts to be considered in the flow specificat= ion work. For each of the drafts you wish to be considered Option 1, pleas= e indicate: 1) If this option is valuable for the DDoS deployments or another crit= ical deployments, 2) Do you feel this draft is useful, but not ready for adoption, 3) Do you feel this draft is a good start for this work. The drafts to consider are: https://datatracker.ietf.org/doc/draft-eddy-idr-flowspec-packet-rate/ https://datatracker.ietf.org/doc/draft-hao-idr-flowspec-nvo3/ https://datatracker.ietf.org/doc/draft-hao-idr-flowspec-redirect-tunnel/ https://datatracker.ietf.org/doc/draft-li-idr-flowspec-redirect-generalized= -sid/ https://datatracker.ietf.org/doc/draft-liang-idr-bgp-flowspec-label/ https://datatracker.ietf.org/doc/draft-litkowski-idr-flowspec-interfaceset/ https://datatracker.ietf.org/doc/draft-vandevelde-idr-flowspec-path-= redirect/ https://datatracker.ietf.org/doc/draft-yong-idr-flowspec-mpls-match/ And for the ordering of these filters and actions drafts - the Option 1 sec= tion out of this https://datatracker.ietf.org/doc/draft-hares-idr-flowspec-combo/ (A revised draft with just Option 1 will be posted) Sue Hares and John Scudder --_000_D322C45147C82duanciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
 
Support


Dongling duan
Thx

From: Idr <idr-bounces@ietf.org> on behalf of Susan Hares &l= t;shares@ndzh.com>
Date: Friday, March 25, 2016 at 7:4= 7 AM
To: "'idr@ietf. org'" <= ;idr@ietf.org>
Subject: [Idr] WG Adoption call for= drafts for Flow Specification option 1 (RFC5575 additions (filters/actions= ) 3/25 to 4/8/2016

IDR WG:

 

This begins a 2 week WG Call (3/25 to 4/8/2016) for = the set of drafts to be considered in RFC5575 additions. These options are = filters, actions or critical security additions.  The flow specificati= on work has been a part of the interims since IETF 94

https://www.ietf.org/proceedings/interim/2= 016/02/08/idr/proceedings.html

https://www.ietf.org/proceedings/interim/2= 016/03/07/idr/proceedings.html

 

There will be a brief flow specification presentatio= n at IETF 95, and the email list has select to start with option 1 – = extending RFC5575.  We also will be gathering details on the SDN/NFV u= se case for option 2 (new NLRI and Wide Communities support).

 

This is a group call for the drafts to be considered= in the flow specification work.  For each of the drafts you wish to b= e considered Option 1, please indicate:

 

1) &nbs= p;    If this option is valuable for the DDoS deploym= ents or another critical deployments,  

2) &nbs= p;    Do you feel this draft is useful, but not ready= for adoption,

3) &nbs= p;    Do you feel this draft is a good start for this= work.

 

The drafts to consider are:

https://datatracker.ietf.org/doc/draft-eddy-i= dr-flowspec-packet-rate/

https://datatracker.ietf.org/doc/draft-hao-idr-flowsp= ec-nvo3/

https://datatracker.ietf.org/doc/draft-hao= -idr-flowspec-redirect-tunnel/

https://datatracker.ietf.org/doc/d= raft-li-idr-flowspec-redirect-generalized-sid/

https://datatracker.ietf.org/doc/draft-liang-i= dr-bgp-flowspec-label/

https://datatracker.ietf.org/doc/draft-= litkowski-idr-flowspec-interfaceset/

https://datatra= cker.ietf.org/doc/draft-vandevelde-idr-flowspec-path-redirect/

https://datatracker.ietf.org/doc/draft-yong-id= r-flowspec-mpls-match/

 

And for the ordering of these filters and actions dr= afts – the Option 1 section out of this

https://datatracker.ietf.org/doc/draft-hares-idr-f= lowspec-combo/

(A revised draft with just Option 1 will be posted) =

 

Sue Hares and John Scudder

 

 

 

 --_000_D322C45147C82duanciscocom_--
r.