Re: [bess] IPR Disclosure Huawei Technologies Co., Ltd's Statement about IPR related to draft-ietf-bess-nsh-bgp-control-plane

[UTTARO, JAMES]

None that I am aware of

Thanks,
Jim Uttaro

-Original Message-
From: IETF Secretariat [mailto:ietf-...@ietf.org] 
Sent: Wednesday, November 28, 2018 10:39 AM
To: draft-ietf-bess-nsh-bgp-control-pl...@ietf.org
Cc: ipr-annou...@ietf.org; bess@ietf.org
Subject: IPR Disclosure Huawei Technologies Co., Ltd's Statement about IPR 
related to draft-ietf-bess-nsh-bgp-control-plane

Dear Adrian Farrel, John Drake, Eric C. Rosen, Jim Uttaro, Luay Jalil:


An IPR disclosure that pertains to your Internet-Draft entitled "BGP
Control Plane for NSH SFC" (draft-ietf-bess-nsh-bgp-control-plane) was
submitted to the IETF Secretariat on  and has been posted on the "IETF Page
of Intellectual Property Rights Disclosures"
(https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_ipr_3347_=DwICaQ=LFYZ-o9_HUMeMTSQicvjIg=3qhKphE8RnwJQ6u8MrAGeA=xqeXEnvJFt7KGraKxUKhn8CA8XzUmnF0HkpMGUv2dSg=r5REH4JewO3L5H_FPOS8wG7dBgHt7MCFZo6VuPbA6iA=).
 The title of the IPR disclosure is
"Huawei Technologies Co.,Ltd's Statement about IPR related to
draft-ietf-bess-nsh-bgp-control-plane"


Thank you

IETF Secretariat
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-mvpn-fast-failover

[Robert Kebler]

Hi,
I'm not aware of any undisclosed IPR related to this draft.

We have an implementation of this draft.

Thanks,
Bob



From: BESS  On Behalf Of stephane.litkow...@orange.com
Sent: Thursday, November 22, 2018 2:54 AM
To: bess@ietf.org
Cc: bess-cha...@ietf.org
Subject: [bess] WGLC, IPR and implementation poll for 
draft-ietf-bess-mvpn-fast-failover


Hello Working Group,



This email starts a two-week Working Group Last Call on 
draft-ietf-bess-mvpn-fast-failover-04  [1]



This poll runs until *the 6th of December*.



We are also polling for knowledge of any undisclosed IPR that applies to this 
Document, to ensure that IPR has been disclosed in compliance with IETF IPR 
rules (see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as an Author or a Contributor of this Document please respond 
to this email and indicate whether or not you are aware of any relevant 
undisclosed IPR. The Document won't progress without answers from all the 
Authors and Contributors.



Currently two IPRs have been disclosed against this Document.



If you are not listed as an Author or a Contributor, then please explicitly 
respond only if you are aware of any IPR that has not yet been disclosed in 
conformance with IETF rules.



We are also polling for any existing implementation as per [2].



Thank you,

Stephane & Matthew



[1] 
https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-fast-failover/



[2] 
https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw




_



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.
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Mirja Kühlewind's Discuss on draft-ietf-bess-mvpn-expl-track-12: (with DISCUSS and COMMENT)

[Eric Rosen]

Mirja,

I believe draft-ietf-bess-mvpn-expl-track-13 addresses your issues. I 
have expanded the Security Considerations section per your suggestions, 
which IMO are all very reasonable.

Please let me know whether this is satisfactory.

Thanks.

Eric

On 11/26/2018 9:03 AM, Mirja Kuehlewind (IETF) wrote:
> Hi Eric,
>
> thanks for your detailed reply. Please see below.
>
>> Am 15.11.2018 um 19:07 schrieb Eric Rosen :
>>
>> On 10/24/2018 8:28 AM, Mirja Kühlewind wrote:
>>> -
>>> DISCUSS:
>>> --
>>>
>>> In section 9 (security considerations):
>>> Thanks for discussing network load here! However, I find this sentence a bit
>>> unsatisfactory:
>>> „The specification of counter-measures for this problem is outside the 
>>> scope
>>> of this document.“
>>> Isn’t there any easy way to make some more recommendations for counter 
>>> measures
>>> that could be discussed here? E.g. implement some rate limiting or 
>>> filtering.
>>> Or only accept LIR-PF request from preconfigured hosts (given that LIR-PF
>>> support must anyway be pre-configured)? I’m not an expert on this topic and
>>> therefore don’t know if any of such recommendations make sense, however, I
>>> would quickly like to discuss if it is potentially possible to say more than
>>> what’s current said. Thanks!
>> These particular suggestions don't really work in this context.
>>
>> - The set of Provider Edge routers (PEs) that attach to a given VPN is
>> always auto-discovered, never pre-configured.  That's an important part
>> of the L3VPN value proposition.   There are already mechanisms in place
>> to ensure that the S-PMSI A-D route gets sent only to the proper set of
>> egress PEs.  Also, a properly functioning egress PE will only respond
>> with a Leaf A-D route if it has already auto-discovered the ingress PE.
>> (You might want to question the security of the L3VPN mechanisms, but
>> that would certainly be outside the scope of this document .)
>>
>> - Rate limiting the generation of Leaf A-D routes wouldn't work, because
>> the problem is not that one PE generates too many, but that too many PEs
>> may generate them.  Rate limiting the processing of received Leaf A-D
>> routes is also problematic.  In normal operation, you might correctly
>> get a whole bunch of them in quick succession, and if you don't process
>> them in a timely manner, the customers will see a high multicast "join
>> latency".
>>
>> In the particular sort of attack mentioned in the Security
>> Considerations section, an ingress PE originates an S-PMSI A-D route
>> with LIR-pF clear, but somehow the bit gets set before the route is
>> received by the egress PEs.   As Alvaro has suggested, if an attacker
>> can modify the control messages, quite a bit of havoc can result, and
>> the particular attack under discussion is just one of many that can
>> occur if the control plane is not secure.  I can certainly put in a
>> reference to RFCS 6192 and 7454 (as Alvaro suggests), if you think that
>> is helpful.  Properly protecting the control plane should prevent this
>> kind of attack.
> Okay, then I would simply suggest to say this ("Properly protecting the 
> control plane should prevent this kind of attack“) instead of just calling it 
> out of scope.
>
>> In the event such an attack occurs, mitigating it is unfortunately not
>> very straightforward.  The ingress node can take note of the fact that
>> it is getting Leaf A-D routes with LIR-pF set, in response to an S-PMSI
>> A-D route with LIR-pF clear.  Withdrawing the S-PMSI A-D route could put
>> a stop to the attack.  However, there are a few problems with this:
>>
>> - Under normal operation, there are some race conditions that may cause
>> the ingress node to think it is being attacked, when in fact it is not.
>>
>> - If some egress nodes have a bug that causes them to set LIR-pF when it
>> should be clear, withdrawing the S-PMSI A-D route will stop the flow of
>> multicast data traffic to all the egress nodes, causing an unnecessary
>> customer-visible disruption.
>>
>> - The same situation that caused the S-PMSI A-D route to be originated
>> in the first place will still exist after the S-PMSI A-D route is
>> withdrawn, so the route will just be re-originated.
>>
>> In other words, any action that would ameliorate the effects of this
>> sort of attack would have a negative effect during normal operation.
>> Therefore it is really better to rely on security mechanisms that
>> protect the control plane generally, rather than having a mechanism that
>> is focused on this one particular type of attack.
> This suggest that there is no good counter measure which would be more 
> appropriate  to say instead of calling it out of scope. I think it could even 
> be helpful to add some of your explanation above to the security 
> consideration section (instead of leaving this as an 

Re: [bess] Suresh Krishnan's Discuss on draft-ietf-bess-mvpn-expl-track-12: (with DISCUSS)

[Suresh Krishnan]

Hi Eric,
  Yes. It does. I have cleared.

Regards
Suresh

> On Nov 28, 2018, at 11:35 AM, Eric Rosen  wrote:
> 
> Suresh,
> 
> I believe draft-ietf-bess-mvpn-expl-track-13 addresses your issues. 
> Please let me know.
> 
> Eric
> 
> On 10/25/2018 9:14 AM, Suresh Krishnan wrote:
>> Hi Martin,
>> 
>> 
>>> On Oct 25, 2018, at 4:31 AM, Vigoureux, Martin (Nokia - FR/Paris-Saclay) 
>>>  wrote:
>>> 
>>> Hello Suresh,
>>> 
>>> thank you for your review.
>>> This NLRI is in fact defined in 6514 and the determination of the length
>>> of the IP address field is clarified in 6515, section 2 item 3.
>> That makes more sense but this is not clear from the draft at all. The only 
>> prelude to the format says
>> 
>> "The "route key" field of the NLRI will have the following format:”
>> 
>> with no further explanations that this format is simply repeated from 
>> RFC6514(I am guessing it is the S-PMSI A-D Route defined in Section 4.3). 
>> Additionally, the draft does not even have a reference to RFC6515. I think 
>> it would be really good to put some pointers into this draft. Suggest 
>> something like this
>> 
>> OLD:
>> 
>> The "route key" field of the NLRI will have
>>the following format:
>> 
>> NEW:
>> 
>> The "route key" field of the NLRI uses
>>the following format as defined in Section 4.3 of [RFC6514]:
>> 
>> 
>> OLD:
>> 
>>o  The "ingress PE" address is taken from the "originating router"
>>   field of the NLRI of the S-PMSI A-D route that is the match for
>>   tracking.
>> 
>> NEW:
>> 
>>o  The "ingress PE" address is taken from the "originating router"
>>   field of the NLRI of the S-PMSI A-D route that is the match for
>>   tracking. The length of the Ingress PE's IP address is computed
>>   using the procedure described in Section 2 Item 3 of [RFC6515]
>> 
>> Thanks
>> Suresh
>> 
> 

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

[bess] Suresh Krishnan's No Objection on draft-ietf-bess-mvpn-expl-track-13: (with COMMENT)

[Suresh Krishnan]

Suresh Krishnan has entered the following ballot position for
draft-ietf-bess-mvpn-expl-track-13: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-expl-track/



--
COMMENT:
--

Thanks for addressing my DISCUSS


___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-mvpn-fast-failover => NEED your FEEDBACK

[Muley, Praveen (Nokia - US/Mountain View)]

Not aware of any IPR related to this draft other than the one that was 
disclosed.
We have an implementation of some use cases in the draft

-Praveen

From: BESS mailto:bess-boun...@ietf.org>> on behalf of 
"Hassen, Clayton" mailto:clayton.has...@bell.ca>>
Date: Wednesday, 28 November 2018 at 07:30
To: Stephane Litkowski 
mailto:stephane.litkow...@orange.com>>, 
"bess@ietf.org" mailto:bess@ietf.org>>
Subject: Re: [bess] WGLC, IPR and implementation poll for 
draft-ietf-bess-mvpn-fast-failover => NEED your FEEDBACK

I am unaware of any undisclosed IPR’s.

Thanks

--CH


From: "stephane.litkow...@orange.com" 
mailto:stephane.litkow...@orange.com>>
Date: Wednesday, November 28, 2018 at 4:53 AM
To: "raggarw...@yahoo.com" 
mailto:raggarw...@yahoo.com>>, 
"nehal.b...@alcatel-lucent.com" 
mailto:nehal.b...@alcatel-lucent.com>>, Clayton 
Hassen mailto:clayton.has...@bell.ca>>, 
"wim.henderi...@alcatel-lucent.com" 
mailto:wim.henderi...@alcatel-lucent.com>>, 
"pradeep.j...@alcatel-lucent.com" 
mailto:pradeep.j...@alcatel-lucent.com>>, 
"jayant.kotal...@alcatel-lucent.com" 
mailto:jayant.kotal...@alcatel-lucent.com>>,
 "praveen.mu...@alcatel-lucent.com" 
mailto:praveen.mu...@alcatel-lucent.com>>, 
"r...@juniper.net" 
mailto:r...@juniper.net>>, 
"kanwar.si...@alcatel-lucent.com" 
mailto:kanwar.si...@alcatel-lucent.com>>, 
"rkeb...@juniper.net" 
mailto:rkeb...@juniper.net>>
Subject: FW: [bess] WGLC, IPR and implementation poll for 
draft-ietf-bess-mvpn-fast-failover => NEED your FEEDBACK

Hi,

You are listed as contributor or co-author of this draft. Could you please 
respond to the IPR poll as soon as possible ? Please reply to the BESS WG list. 
If you are aware of an implementation, please also let us know.

Thank you

Brgds,

From: Greg Mirsky [mailto:gregimir...@gmail.com]
Sent: Monday, November 26, 2018 03:47
To: LITKOWSKI Stephane OBS/OINIS
Cc: BESS; bess-cha...@ietf.org
Subject: Re: [bess] WGLC, IPR and implementation poll for 
draft-ietf-bess-mvpn-fast-failover

Hi Stephane, et al.,
I'm not aware of any IPR related to this draft other than already disclosed.

RE: implementation status
In Q1 of 2019, ZTE will release a product that includes support of this draft.

Regards,
Greg

On Wed, Nov 21, 2018 at 11:54 PM 
mailto:stephane.litkow...@orange.com>> wrote:

Hello Working Group,



This email starts a two-week Working Group Last Call on 
draft-ietf-bess-mvpn-fast-failover-04  [1]



This poll runs until *the 6th of December*.



We are also polling for knowledge of any undisclosed IPR that applies to this 
Document, to ensure that IPR has been disclosed in compliance with IETF IPR 
rules (see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as an Author or a Contributor of this Document please respond 
to this email and indicate whether or not you are aware of any relevant 
undisclosed IPR. The Document won't progress without answers from all the 
Authors and Contributors.



Currently two IPRs have been disclosed against this Document.



If you are not listed as an Author or a Contributor, then please explicitly 
respond only if you are aware of any IPR that has not yet been disclosed in 
conformance with IETF rules.



We are also polling for any existing implementation as per [2].



Thank you,

Stephane & Matthew



[1] https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-fast-failover/



[2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw




_



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.
___
BESS mailing list
BESS@ietf.org

Re: [bess] Suresh Krishnan's Discuss on draft-ietf-bess-mvpn-expl-track-12: (with DISCUSS)

[Eric Rosen]

Suresh,

I believe draft-ietf-bess-mvpn-expl-track-13 addresses your issues. 
Please let me know.

Eric

On 10/25/2018 9:14 AM, Suresh Krishnan wrote:
> Hi Martin,
>
>
>> On Oct 25, 2018, at 4:31 AM, Vigoureux, Martin (Nokia - FR/Paris-Saclay) 
>>  wrote:
>>
>> Hello Suresh,
>>
>> thank you for your review.
>> This NLRI is in fact defined in 6514 and the determination of the length
>> of the IP address field is clarified in 6515, section 2 item 3.
> That makes more sense but this is not clear from the draft at all. The only 
> prelude to the format says
>
> "The "route key" field of the NLRI will have the following format:”
>
> with no further explanations that this format is simply repeated from 
> RFC6514(I am guessing it is the S-PMSI A-D Route defined in Section 4.3). 
> Additionally, the draft does not even have a reference to RFC6515. I think it 
> would be really good to put some pointers into this draft. Suggest something 
> like this
>
> OLD:
>
> The "route key" field of the NLRI will have
> the following format:
>
> NEW:
>
> The "route key" field of the NLRI uses
> the following format as defined in Section 4.3 of [RFC6514]:
>
>
> OLD:
>
> o  The "ingress PE" address is taken from the "originating router"
>field of the NLRI of the S-PMSI A-D route that is the match for
>tracking.
>
> NEW:
>
> o  The "ingress PE" address is taken from the "originating router"
>field of the NLRI of the S-PMSI A-D route that is the match for
>tracking. The length of the Ingress PE's IP address is computed
>using the procedure described in Section 2 Item 3 of [RFC6515]
>
> Thanks
> Suresh
>

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Benjamin Kaduk's Discuss on draft-ietf-bess-mvpn-expl-track-12: (with DISCUSS and COMMENT)

[Eric Rosen]

Benjamin,

I believe draft-ietf-bess-mvpn-expl-track-13 addresses your issues.

Please let me know whether this is the case.

And thank you for doing such a careful review.

Eric


On 10/22/2018 9:41 PM, Benjamin Kaduk wrote:
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-bess-mvpn-expl-track-12: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_iesg_statement_discuss-2Dcriteria.html=DwICaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo=_As6D3lr-KYW2BdIKLvT4bjw3HDCFWJBsOFYObf1E_0=UWa2_MZELEQCZBxgLuEXDrhFGiFhDaSLecKezEgQJSk=
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dbess-2Dmvpn-2Dexpl-2Dtrack_=DwICaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo=_As6D3lr-KYW2BdIKLvT4bjw3HDCFWJBsOFYObf1E_0=Zs4cZ41OK1XktcOKuVjcsMkGQmpuzOc9fWuTjx1HQZY=
>
>
>
> --
> DISCUSS:
> --
>
> This document places normative requirements on new tunnel types but does
> not indicate this in a way that someone specifying a new tunnel type would
> be forced to see.  This occurs both in Section 5.2:
>
> o  When additional tunnel types are defined, the specification for
>how MVPN is to use those tunnel types must also specify how to
>construct the PTA of a Leaf A-D route that is originated in
>response to the LIR-pF flag.  As an example, see [BIER-MVPN].
>
> and in Section 6:
>
> If L's PTA specifies a tunnel type not mentioned above, the
> specification for how MVPN uses that tunnel type must specify the
> actions that N is to take upon receiving L.  As an example, see
> [BIER-MVPN].
>
> I think the best way to do this would be to have IANA Considerations
> updating the registration procedure for
> P-Multicast Service Interface (PMSI) Tunnel Type codepoints to note that
> new registrations must include this information.  It might also suffice to
> call out the existence of these requirements in the portion of the
> Introduction that discusses how this document Updates RFC 6514 (though, per
> the COMMENT section, this portion of the Introduction doesn't exist in a
> good form yet).
>
> Thank you for providing the BIER example, though -- it is helpful to see
> how the requirement plays out in practice!
>
>
> --
> COMMENT:
> --
>
> Section 1
>
> This document clarifies the procedures for originating and receiving
> S-PMSI A-D routes and Leaf A-D routes.  This document also adds new
> procedures to allow more efficient explicit tracking.  The procedures
> being clarified and/or extended are discussed in multiple places in
> the documents being updated.
>
> This is in effect saying to the reader, "you must read the updated
> document(s) in their entirety and decide for yourself whether a procedure
> being updated is described", which is perhaps not the most friendly thing
> to be doing.
>
> Section 2
>
> If the LIR-pF flag is set in the PTA of an S-PMSI A-D route, the LIR
> flag of that PTA MUST also be set.
>
> What do I do if I receive a PTA in violation of the MUST?
>
> Note that support for the LIR-pF flag is OPTIONAL.  This flag SHOULD
> NOT be set unless it is known that all the PEs that are to receive
> the route carrying the PTA support the flag.  How this is known is
> outside the scope of this document.
>
> Maybe remind us what a PE that doesn't support this flag will do if it
> happens to receive a PTA with it set?  (I see discussion below of the state
> at the ingress node in this case, but not an explicit confirmation of what
> egress nodes do.)  It would also be nice to give non-normative examples of
> how a sender might know that receivers support the flag.
>
> Section 3
>
> The rules for finding a "match for reception" in [RFC6625] are hereby
> modified as follows:
>
> Maybe give a section reference too?  (Especially since 6625 does not use
> the abbreviated version we define here, and instead writes "Finding the
> Match for Data Reception".)
>
>For a given C-flow ((C-S,C-G) or (C-*,C-G)) the "match for
>tracking" is chosen as follows.  Ignore any S-PMSI A-D route that
>has no PTA.  Also ignore any S-PMSI A-D route whose PTA specifies
>"no tunnel information present", but does not have either LIR or
>

[bess] I-D Action: draft-ietf-bess-mvpn-expl-track-13.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the BGP Enabled ServiceS WG of the IETF.

Title   : Explicit Tracking with Wild Card Routes in Multicast 
VPN
Authors : Andrew Dolganow
  Jayant Kotalwar
  Eric C. Rosen
  Zhaohui Zhang
Filename: draft-ietf-bess-mvpn-expl-track-13.txt
Pages   : 21
Date: 2018-11-28

Abstract:
   The Multicast VPN (MVPN) specifications provide procedures to allow a
   multicast ingress node to invoke "explicit tracking" for a multicast
   flow or set of flows, thus learning the egress nodes for that flow or
   set of flows.  However, the specifications are not completely clear
   about how the explicit tracking procedures work in certain scenarios.
   This document provides the necessary clarifications.  It also
   specifies a new, optimized explicit tracking procedure.  This new
   procedure allows an ingress node, by sending a single message, to
   request explicit tracking of each of a set of flows, where the set of
   flows is specified using a wildcard mechanism.  This document updates
   RFCs 6514, 6625, 7524, 7582, and 7900.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-expl-track/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-bess-mvpn-expl-track-13
https://datatracker.ietf.org/doc/html/draft-ietf-bess-mvpn-expl-track-13

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-mvpn-expl-track-13


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-mvpn-fast-failover => NEED your FEEDBACK

[Henderickx, Wim (Nokia - BE/Antwerp)]

I am not aware of IPR related to this draft other than the one that was 
disclosed.
We have an implementation of some use cases in the draft

From: BESS  on behalf of "Hassen, Clayton" 

Date: Wednesday, 28 November 2018 at 07:30
To: Stephane Litkowski , "bess@ietf.org" 

Subject: Re: [bess] WGLC, IPR and implementation poll for 
draft-ietf-bess-mvpn-fast-failover => NEED your FEEDBACK

I am unaware of any undisclosed IPR’s.

Thanks

--CH


From: "stephane.litkow...@orange.com" 
Date: Wednesday, November 28, 2018 at 4:53 AM
To: "raggarw...@yahoo.com" , 
"nehal.b...@alcatel-lucent.com" , Clayton Hassen 
, "wim.henderi...@alcatel-lucent.com" 
, "pradeep.j...@alcatel-lucent.com" 
, "jayant.kotal...@alcatel-lucent.com" 
, "praveen.mu...@alcatel-lucent.com" 
, "r...@juniper.net" , 
"kanwar.si...@alcatel-lucent.com" , 
"rkeb...@juniper.net" 
Subject: FW: [bess] WGLC, IPR and implementation poll for 
draft-ietf-bess-mvpn-fast-failover => NEED your FEEDBACK

Hi,

You are listed as contributor or co-author of this draft. Could you please 
respond to the IPR poll as soon as possible ? Please reply to the BESS WG list. 
If you are aware of an implementation, please also let us know.

Thank you

Brgds,

From: Greg Mirsky [mailto:gregimir...@gmail.com]
Sent: Monday, November 26, 2018 03:47
To: LITKOWSKI Stephane OBS/OINIS
Cc: BESS; bess-cha...@ietf.org
Subject: Re: [bess] WGLC, IPR and implementation poll for 
draft-ietf-bess-mvpn-fast-failover

Hi Stephane, et al.,
I'm not aware of any IPR related to this draft other than already disclosed.

RE: implementation status
In Q1 of 2019, ZTE will release a product that includes support of this draft.

Regards,
Greg

On Wed, Nov 21, 2018 at 11:54 PM 
mailto:stephane.litkow...@orange.com>> wrote:

Hello Working Group,



This email starts a two-week Working Group Last Call on 
draft-ietf-bess-mvpn-fast-failover-04  [1]



This poll runs until *the 6th of December*.



We are also polling for knowledge of any undisclosed IPR that applies to this 
Document, to ensure that IPR has been disclosed in compliance with IETF IPR 
rules (see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as an Author or a Contributor of this Document please respond 
to this email and indicate whether or not you are aware of any relevant 
undisclosed IPR. The Document won't progress without answers from all the 
Authors and Contributors.



Currently two IPRs have been disclosed against this Document.



If you are not listed as an Author or a Contributor, then please explicitly 
respond only if you are aware of any IPR that has not yet been disclosed in 
conformance with IETF rules.



We are also polling for any existing implementation as per [2].



Thank you,

Stephane & Matthew



[1] https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-fast-failover/



[2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw




_



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.
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

_



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, 

[bess] IPR Disclosure Huawei Technologies Co., Ltd's Statement about IPR related to draft-ietf-bess-nsh-bgp-control-plane

[IETF Secretariat]

Dear Adrian Farrel, John Drake, Eric C. Rosen, Jim Uttaro, Luay Jalil:


An IPR disclosure that pertains to your Internet-Draft entitled "BGP
Control Plane for NSH SFC" (draft-ietf-bess-nsh-bgp-control-plane) was
submitted to the IETF Secretariat on  and has been posted on the "IETF Page
of Intellectual Property Rights Disclosures"
(https://datatracker.ietf.org/ipr/3347/). The title of the IPR disclosure is
"Huawei Technologies Co.,Ltd's Statement about IPR related to
draft-ietf-bess-nsh-bgp-control-plane"


Thank you

IETF Secretariat

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-mvpn-fast-failover => NEED your FEEDBACK

[Hassen, Clayton]

I am unaware of any undisclosed IPR’s.

Thanks

--CH


From: "stephane.litkow...@orange.com" 
Date: Wednesday, November 28, 2018 at 4:53 AM
To: "raggarw...@yahoo.com" , 
"nehal.b...@alcatel-lucent.com" , Clayton Hassen 
, "wim.henderi...@alcatel-lucent.com" 
, "pradeep.j...@alcatel-lucent.com" 
, "jayant.kotal...@alcatel-lucent.com" 
, "praveen.mu...@alcatel-lucent.com" 
, "r...@juniper.net" , 
"kanwar.si...@alcatel-lucent.com" , 
"rkeb...@juniper.net" 
Subject: FW: [bess] WGLC, IPR and implementation poll for 
draft-ietf-bess-mvpn-fast-failover => NEED your FEEDBACK

Hi,

You are listed as contributor or co-author of this draft. Could you please 
respond to the IPR poll as soon as possible ? Please reply to the BESS WG list. 
If you are aware of an implementation, please also let us know.

Thank you

Brgds,

From: Greg Mirsky [mailto:gregimir...@gmail.com]
Sent: Monday, November 26, 2018 03:47
To: LITKOWSKI Stephane OBS/OINIS
Cc: BESS; bess-cha...@ietf.org
Subject: Re: [bess] WGLC, IPR and implementation poll for 
draft-ietf-bess-mvpn-fast-failover

Hi Stephane, et al.,
I'm not aware of any IPR related to this draft other than already disclosed.

RE: implementation status
In Q1 of 2019, ZTE will release a product that includes support of this draft.

Regards,
Greg

On Wed, Nov 21, 2018 at 11:54 PM 
mailto:stephane.litkow...@orange.com>> wrote:

Hello Working Group,



This email starts a two-week Working Group Last Call on 
draft-ietf-bess-mvpn-fast-failover-04  [1]



This poll runs until *the 6th of December*.



We are also polling for knowledge of any undisclosed IPR that applies to this 
Document, to ensure that IPR has been disclosed in compliance with IETF IPR 
rules (see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as an Author or a Contributor of this Document please respond 
to this email and indicate whether or not you are aware of any relevant 
undisclosed IPR. The Document won't progress without answers from all the 
Authors and Contributors.



Currently two IPRs have been disclosed against this Document.



If you are not listed as an Author or a Contributor, then please explicitly 
respond only if you are aware of any IPR that has not yet been disclosed in 
conformance with IETF rules.



We are also polling for any existing implementation as per [2].



Thank you,

Stephane & Matthew



[1] https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-fast-failover/



[2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw




_



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.
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

_



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.
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess