Re: [bess] WG Adoption and IPR Poll for draft-litkowski-bess-rfc5549revision-00

[Bocci, Matthew (Nokia - GB)]

WG

This email closes the poll for adoption. I believe there is consensus to adopt 
this draft.

As noted in the discussion, I will be running an implementation poll as a part 
of the working group last call, as is our practice in BESS. As a reminder, the 
policy is described here:

 https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw

Authors: please upload a new version of the draft named 
draft-ietf-bess-rfc5549revision-00.

Best regards

Matthew

From: "Bocci, Matthew (Nokia - GB)" 
Date: Wednesday, 27 November 2019 at 12:36
To: "bess@ietf.org" 
Cc: "bess-cha...@ietf.org" 
Subject: WG Adoption and IPR Poll for draft-litkowski-bess-rfc5549revision-00

Hello,

This email begins a two-weeks WG adoption poll for 
draft-litkowski-bess-rfc5549revision-00 [1] .

Please review the draft and post any comments to the BESS working group list.

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, copying the BESS mailing list. The document won't progress 
without answers from all the authors and contributors.

Currently, there are no IPR disclosures 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.

This poll for adoption closes on Wednesday 11th December 2019.

Regards,
Matthew

[1] https://datatracker.ietf.org/doc/draft-litkowski-bess-rfc5549revision/



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

Re: [bess] WG Adoption and IPR Poll for draft-litkowski-bess-rfc5549revision-00

[Qin Wu]

Support adoption of this work.

-Qin
发件人: BESS [mailto:bess-boun...@ietf.org] 代表 Bocci, Matthew (Nokia - GB)
发送时间: 2019年11月27日 20:37
收件人: bess@ietf.org
抄送: bess-cha...@ietf.org
主题: [bess] WG Adoption and IPR Poll for draft-litkowski-bess-rfc5549revision-00

Hello,

This email begins a two-weeks WG adoption poll for 
draft-litkowski-bess-rfc5549revision-00 [1] .

Please review the draft and post any comments to the BESS working group list.

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, copying the BESS mailing list. The document won't progress 
without answers from all the authors and contributors.

Currently, there are no IPR disclosures 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.

This poll for adoption closes on Wednesday 11th December 2019.

Regards,
Matthew

[1] 
https://datatracker.ietf.org/doc/draft-litkowski-bess-rfc5549revision/



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

Re: [bess] WG Adoption and IPR Poll for draft-litkowski-bess-rfc5549revision-00

[Gyan Mishra]

I fully support the draft. The draft is well written and covers all the
critical points of multiprotocol BGP where the IPv6 next hop can carry IPv4
NLRI.

Thank you

Gyan S. Mishra

IT Network Engineering & Technology

Verizon Communications Inc. (VZ)

13101 Columbia Pike FDC1 3rd Floor

Silver Spring, MD 20904

United States

Phone: 301 502-1347

Email: gyan.s.mis...@verizon.com

www.linkedin.com/in/networking-technologies-consultant

On Thu, Nov 28, 2019 at 1:15 AM Wanghaibo (Rainsword) <
rainsword.w...@huawei.com> wrote:

> Support adoption of this draft.
>
>
>
> Regards,
>
> Haibo
>
>
>
> *发件人:* BESS [mailto:bess-boun...@ietf.org] *代表 *Bocci, Matthew (Nokia -
> GB)
> *发送时间:* 2019年11月27日 20:37
> *收件人:* bess@ietf.org
> *抄送:* bess-cha...@ietf.org
> *主题:* [bess] WG Adoption and IPR Poll for
> draft-litkowski-bess-rfc5549revision-00
>
>
>
> Hello,
>
>
>
> This email begins a two-weeks WG adoption poll for
> draft-litkowski-bess-rfc5549revision-00 [1] .
>
>
>
> Please review the draft and post any comments to the BESS working group
> list.
>
>
>
> 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, copying the BESS mailing list. The document won't
> progress without answers from all the authors and contributors.
>
>
>
> Currently, there are no IPR disclosures 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.
>
>
>
> This poll for adoption closes on Wednesday 11th December 2019.
>
>
>
> Regards,
>
> Matthew
>
>
>
> [1] https://datatracker.ietf.org/doc/draft-litkowski-bess-rfc5549revision/
>
>
>
>
>
>
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>


-- 

Gyan S. Mishra

IT Network Engineering & Technology

Verizon Communications Inc. (VZ)

13101 Columbia Pike FDC1 3rd Floor

Silver Spring, MD 20904

United States

Phone: 301 502-1347

Email: gyan.s.mis...@verizon.com

www.linkedin.com/in/networking-technologies-consultant
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG Adoption and IPR Poll for draft-litkowski-bess-rfc5549revision-00

[Linda Dunbar]

I support the WG Adoption of this draft.

Regards, Linda Dunbar

发件人: BESS [mailto:bess-boun...@ietf.org] 代表 Bocci, Matthew (Nokia - GB)
发送时间: 2019年11月27日 20:37
收件人: bess@ietf.org
抄送: bess-cha...@ietf.org
主题: [bess] WG Adoption and IPR Poll for draft-litkowski-bess-rfc5549revision-00

Hello,

This email begins a two-weeks WG adoption poll for 
draft-litkowski-bess-rfc5549revision-00 [1] .

Please review the draft and post any comments to the BESS working group list.

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, copying the BESS mailing list. The document won't progress 
without answers from all the authors and contributors.

Currently, there are no IPR disclosures 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.

This poll for adoption closes on Wednesday 11th December 2019.

Regards,
Matthew

[1] 
https://datatracker.ietf.org/doc/draft-litkowski-bess-rfc5549revision/



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

Re: [bess] WG Adoption and IPR Poll for draft-litkowski-bess-rfc5549revision-00

[Satya Mohanty (satyamoh)]

Support.

Thanks,
--Satya

From: BESS  on behalf of "Bocci, Matthew (Nokia - GB)" 

Date: Wednesday, November 27, 2019 at 4:37 AM
To: "bess@ietf.org" 
Cc: "bess-cha...@ietf.org" 
Subject: [bess] WG Adoption and IPR Poll for 
draft-litkowski-bess-rfc5549revision-00

Hello,

This email begins a two-weeks WG adoption poll for 
draft-litkowski-bess-rfc5549revision-00 [1] .

Please review the draft and post any comments to the BESS working group list.

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, copying the BESS mailing list. The document won't progress 
without answers from all the authors and contributors.

Currently, there are no IPR disclosures 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.

This poll for adoption closes on Wednesday 11th December 2019.

Regards,
Matthew

[1] https://datatracker.ietf.org/doc/draft-litkowski-bess-rfc5549revision/



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

Re: [bess] WG Adoption and IPR Poll for draft-litkowski-bess-rfc5549revision-00

[Mankamana Mishra (mankamis)]

Support

From: "Bocci, Matthew (Nokia - GB)" 
Date: Wednesday, November 27, 2019 at 6:07 PM
To: "bess@ietf.org" 
Cc: "bess-cha...@ietf.org" 
Subject: WG Adoption and IPR Poll for draft-litkowski-bess-rfc5549revision-00
Resent-From: 
Resent-To: , , 

Resent-Date: Wednesday, November 27, 2019 at 6:06 PM

Hello,

This email begins a two-weeks WG adoption poll for 
draft-litkowski-bess-rfc5549revision-00 [1] .

Please review the draft and post any comments to the BESS working group list.

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, copying the BESS mailing list. The document won't progress 
without answers from all the authors and contributors.

Currently, there are no IPR disclosures 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.

This poll for adoption closes on Wednesday 11th December 2019.

Regards,
Matthew

[1] https://datatracker.ietf.org/doc/draft-litkowski-bess-rfc5549revision/



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

Re: [bess] WG Adoption and IPR Poll for draft-litkowski-bess-rfc5549revision-00

[Acee Lindem (acee)]

Hi Robert,
Even in the fastidious IDR WG, an implementation report is NOT a requirement 
for WG adoption. Here is the policy for BESS:

https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw

So, there will be a poll at WG last call but not necessarily a formal report 
Wiki.

Hope this helps,
Acee

From: Robert Raszuk 
Date: Tuesday, December 3, 2019 at 11:39 AM
To: Acee Lindem 
Cc: "slitkows.i...@gmail.com" , "Bocci, Matthew (Nokia 
- GB)" , "bess-cha...@ietf.org" 
, "bess@ietf.org" 
Subject: Re: [bess] WG Adoption and IPR Poll for 
draft-litkowski-bess-rfc5549revision-00

Hi Acee,

There is no single vendor mentioned. There is no name of the reporter 
mentioned. This is not an implementation report.

This draft sole reasoning is based on the implementations. I am looking for 
formal implementation report - just like we always do in idr:

https://trac.ietf.org/trac/idr/wiki/Protocol%20implementations%20Reports

Example:

https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-optimal-route-reflection%20implementations

Thx,
R.


On Tue, Dec 3, 2019 at 5:24 PM Acee Lindem (acee) 
mailto:a...@cisco.com>> wrote:
Hi Robert,

From: Robert Raszuk mailto:rob...@raszuk.net>>
Date: Tuesday, December 3, 2019 at 8:25 AM
To: Acee Lindem mailto:a...@cisco.com>>
Cc: "slitkows.i...@gmail.com<mailto:slitkows.i...@gmail.com>" 
mailto:slitkows.i...@gmail.com>>, "Bocci, Matthew 
(Nokia - GB)" mailto:matthew.bo...@nokia.com>>, 
"bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>" 
mailto:bess-cha...@ietf.org>>, 
"bess@ietf.org<mailto:bess@ietf.org>" mailto:bess@ietf.org>>
Subject: Re: [bess] WG Adoption and IPR Poll for 
draft-litkowski-bess-rfc5549revision-00

Hi,

I am not that naive to think that you can do something else here ;)

But can you at least send a pointer to formal implementation report before 
proceeding ?

Here are the slides presented at the Tuesday afternoon BESS WG sessions. The 
results of the implementation survey are included.

https://datatracker.ietf.org/meeting/106/materials/slides-106-bess-sessa-draft-litkowski-bess-vpnv4-ipv6-nh-handling-00-00

Thanks,
Acee

Thx a lot,
R.

On Tue, Dec 3, 2019, 13:17 Acee Lindem (acee) 
mailto:a...@cisco.com>> wrote:
Hi Robert,
My point is that your proposal to save the 8 bytes of RD can be independent of 
correcting RFC 5449. It is pretty much a no-brainer that revising the 
specification to match the de facto standard of all extant implementations is 
preferable to a non-trivial upgrade and migration.

Anyway, I don’t wish to engage in a protracted debate and I don’t believe the 
WG wishes to delay publication of this draft. Your lone objection can be noted 
in the shepherds report.

Thanks,
Acee


From: Robert Raszuk mailto:rob...@raszuk.net>>
Date: Monday, December 2, 2019 at 6:37 PM
To: Acee Lindem mailto:a...@cisco.com>>
Cc: "slitkows.i...@gmail.com<mailto:slitkows.i...@gmail.com>" 
mailto:slitkows.i...@gmail.com>>, "Bocci, Matthew 
(Nokia - GB)" mailto:matthew.bo...@nokia.com>>, 
"bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>" 
mailto:bess-cha...@ietf.org>>, 
"bess@ietf.org<mailto:bess@ietf.org>" mailto:bess@ietf.org>>
Subject: Re: [bess] WG Adoption and IPR Poll for 
draft-litkowski-bess-rfc5549revision-00

Hi Acee,

Please observe that this draft defines encoding for SAFI 129 with IPv6 as next 
hop.

If we are prepend it with zero pls do not forget to also submit the errata to 
RFC 6514 which says
clearly in section 9.2.3.2 that next hop *field* must be set to a routable IP 
address. Not part of the
Next Hop field but the entire *field*.


   When re-advertising an Inter-AS I-PMSI A-D route, the ASBR MUST set

   the Next Hop field of the MP_REACH_NLRI attribute to a routable IP

   address of the ASBR.



And the above is just the tip of the iceberg :)



Bottom line is that instead of publishing the spec which in backwards 
compatible fashion allows

gradually to fix the implementation errors of the past it is just blessing 
them. And we all agree

that pushing to each MP_REACH NH field 64 zeros is completely unnecessary. Not 
a good thing

in my measures.



Best,

R.



PS. And what happens if those 8 octets is not zeros but zero and ones ? Should 
it be accepted and

ignored or is this an invalid attribute ?





On Mon, Dec 2, 2019 at 11:21 PM Acee Lindem (acee) 
mailto:a...@cisco.com>> wrote:
Robert,

What you’re suggesting doesn’t really solve the problem that all the currently 
deployed routers that do not follow RFC 5549. No known implementations follow 
RFC 5549. Were you on the meetecho when this was presented in the BESS meeting 
at IETF 106? There was clear consensus in the meeting.

Anyway,  you can put your ideas in a new draft and let them stand on their own 
merit. That way, if

Re: [bess] WG Adoption and IPR Poll for draft-litkowski-bess-rfc5549revision-00

[Robert Raszuk]

Hi Acee,

There is no single vendor mentioned. There is no name of the reporter
mentioned. This is not an implementation report.

This draft sole reasoning is based on the implementations. I am looking for
formal implementation report - just like we always do in idr:

https://trac.ietf.org/trac/idr/wiki/Protocol%20implementations%20Reports

Example:

https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-optimal-route-reflection%20implementations

Thx,
R.


On Tue, Dec 3, 2019 at 5:24 PM Acee Lindem (acee)  wrote:

> Hi Robert,
>
>
>
> *From: *Robert Raszuk 
> *Date: *Tuesday, December 3, 2019 at 8:25 AM
> *To: *Acee Lindem 
> *Cc: *"slitkows.i...@gmail.com" , "Bocci,
> Matthew (Nokia - GB)" , "bess-cha...@ietf.org" <
> bess-cha...@ietf.org>, "bess@ietf.org" 
> *Subject: *Re: [bess] WG Adoption and IPR Poll for
> draft-litkowski-bess-rfc5549revision-00
>
>
>
> Hi,
>
>
>
> I am not that naive to think that you can do something else here ;)
>
>
>
> But can you at least send a pointer to formal implementation report before
> proceeding ?
>
>
>
> Here are the slides presented at the Tuesday afternoon BESS WG sessions.
> The results of the implementation survey are included.
>
>
>
>
> https://datatracker.ietf.org/meeting/106/materials/slides-106-bess-sessa-draft-litkowski-bess-vpnv4-ipv6-nh-handling-00-00
>
>
>
> Thanks,
>
> Acee
>
>
>
> Thx a lot,
>
> R.
>
>
>
> On Tue, Dec 3, 2019, 13:17 Acee Lindem (acee)  wrote:
>
> Hi Robert,
>
> My point is that your proposal to save the 8 bytes of RD can be
> independent of correcting RFC 5449. It is pretty much a no-brainer that
> revising the specification to match the de facto standard of all extant
> implementations is preferable to a non-trivial upgrade and migration.
>
>
>
> Anyway, I don’t wish to engage in a protracted debate and I don’t believe
> the WG wishes to delay publication of this draft. Your lone objection can
> be noted in the shepherds report.
>
>
>
> Thanks,
> Acee
>
>
>
>
>
> *From: *Robert Raszuk 
> *Date: *Monday, December 2, 2019 at 6:37 PM
> *To: *Acee Lindem 
> *Cc: *"slitkows.i...@gmail.com" , "Bocci,
> Matthew (Nokia - GB)" , "bess-cha...@ietf.org" <
> bess-cha...@ietf.org>, "bess@ietf.org" 
> *Subject: *Re: [bess] WG Adoption and IPR Poll for
> draft-litkowski-bess-rfc5549revision-00
>
>
>
> Hi Acee,
>
>
>
> Please observe that this draft defines encoding for SAFI 129 with IPv6 as
> next hop.
>
>
>
> If we are prepend it with zero pls do not forget to also submit the errata
> to RFC 6514 which says
>
> clearly in section 9.2.3.2 that next hop *field* must be set to a routable
> IP address. Not part of the
>
> Next Hop field but the entire *field*.
>
>
>
>When re-advertising an Inter-AS I-PMSI A-D route, the ASBR MUST set
>
>the Next Hop field of the MP_REACH_NLRI attribute to a routable IP
>
>address of the ASBR.
>
>
>
> And the above is just the tip of the iceberg :)
>
>
>
> Bottom line is that instead of publishing the spec which in backwards 
> compatible fashion allows
>
> gradually to fix the implementation errors of the past it is just blessing 
> them. And we all agree
>
> that pushing to each MP_REACH NH field 64 zeros is completely unnecessary.. 
> Not a good thing
>
> in my measures.
>
>
>
> Best,
>
> R.
>
>
>
> PS. And what happens if those 8 octets is not zeros but zero and ones ? 
> Should it be accepted and
>
> ignored or is this an invalid attribute ?
>
>
>
>
>
>
>
> On Mon, Dec 2, 2019 at 11:21 PM Acee Lindem (acee)  wrote:
>
> Robert,
>
>
>
> What you’re suggesting doesn’t really solve the problem that all the
> currently deployed routers that do not follow RFC 5549. No known
> implementations follow RFC 5549. Were you on the meetecho when this was
> presented in the BESS meeting at IETF 106? There was clear consensus in the
> meeting.
>
>
>
> Anyway,  you can put your ideas in a new draft and let them stand on their
> own merit. That way, if there were consensus, we could save those 8 bytes
> of RD. However, we shouldn’t mix this with the draft revising RFC 5549 to
> reflect the current implementations and deployments.
>
>
>
> Thanks,
>
> Acee
>
>
>
> *From: *BESS  on behalf of Robert Raszuk <
> rob...@raszuk.net>
> *Date: *Thursday, November 28, 2019 at 11:58 AM
> *To: *"slitkows.i...@gmail.com" 
> *Cc: *"Bocci, Matthew (Nokia - GB)" , "
> bess-cha...@ietf.org&

Re: [bess] WG Adoption and IPR Poll for draft-litkowski-bess-rfc5549revision-00

[Acee Lindem (acee)]

Hi Robert,

From: Robert Raszuk 
Date: Tuesday, December 3, 2019 at 8:25 AM
To: Acee Lindem 
Cc: "slitkows.i...@gmail.com" , "Bocci, Matthew (Nokia 
- GB)" , "bess-cha...@ietf.org" 
, "bess@ietf.org" 
Subject: Re: [bess] WG Adoption and IPR Poll for 
draft-litkowski-bess-rfc5549revision-00

Hi,

I am not that naive to think that you can do something else here ;)

But can you at least send a pointer to formal implementation report before 
proceeding ?

Here are the slides presented at the Tuesday afternoon BESS WG sessions. The 
results of the implementation survey are included.

https://datatracker.ietf.org/meeting/106/materials/slides-106-bess-sessa-draft-litkowski-bess-vpnv4-ipv6-nh-handling-00-00

Thanks,
Acee

Thx a lot,
R.

On Tue, Dec 3, 2019, 13:17 Acee Lindem (acee) 
mailto:a...@cisco.com>> wrote:
Hi Robert,
My point is that your proposal to save the 8 bytes of RD can be independent of 
correcting RFC 5449. It is pretty much a no-brainer that revising the 
specification to match the de facto standard of all extant implementations is 
preferable to a non-trivial upgrade and migration.

Anyway, I don’t wish to engage in a protracted debate and I don’t believe the 
WG wishes to delay publication of this draft. Your lone objection can be noted 
in the shepherds report.

Thanks,
Acee


From: Robert Raszuk mailto:rob...@raszuk.net>>
Date: Monday, December 2, 2019 at 6:37 PM
To: Acee Lindem mailto:a...@cisco.com>>
Cc: "slitkows.i...@gmail.com<mailto:slitkows.i...@gmail.com>" 
mailto:slitkows.i...@gmail.com>>, "Bocci, Matthew 
(Nokia - GB)" mailto:matthew.bo...@nokia.com>>, 
"bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>" 
mailto:bess-cha...@ietf.org>>, 
"bess@ietf.org<mailto:bess@ietf.org>" mailto:bess@ietf.org>>
Subject: Re: [bess] WG Adoption and IPR Poll for 
draft-litkowski-bess-rfc5549revision-00

Hi Acee,

Please observe that this draft defines encoding for SAFI 129 with IPv6 as next 
hop.

If we are prepend it with zero pls do not forget to also submit the errata to 
RFC 6514 which says
clearly in section 9.2.3.2 that next hop *field* must be set to a routable IP 
address. Not part of the
Next Hop field but the entire *field*.


   When re-advertising an Inter-AS I-PMSI A-D route, the ASBR MUST set

   the Next Hop field of the MP_REACH_NLRI attribute to a routable IP

   address of the ASBR.



And the above is just the tip of the iceberg :)



Bottom line is that instead of publishing the spec which in backwards 
compatible fashion allows

gradually to fix the implementation errors of the past it is just blessing 
them. And we all agree

that pushing to each MP_REACH NH field 64 zeros is completely unnecessary. Not 
a good thing

in my measures.



Best,

R.



PS. And what happens if those 8 octets is not zeros but zero and ones ? Should 
it be accepted and

ignored or is this an invalid attribute ?





On Mon, Dec 2, 2019 at 11:21 PM Acee Lindem (acee) 
mailto:a...@cisco.com>> wrote:
Robert,

What you’re suggesting doesn’t really solve the problem that all the currently 
deployed routers that do not follow RFC 5549. No known implementations follow 
RFC 5549. Were you on the meetecho when this was presented in the BESS meeting 
at IETF 106? There was clear consensus in the meeting.

Anyway,  you can put your ideas in a new draft and let them stand on their own 
merit. That way, if there were consensus, we could save those 8 bytes of RD. 
However, we shouldn’t mix this with the draft revising RFC 5549 to reflect the 
current implementations and deployments.

Thanks,
Acee

From: BESS mailto:bess-boun...@ietf.org>> on behalf of 
Robert Raszuk mailto:rob...@raszuk.net>>
Date: Thursday, November 28, 2019 at 11:58 AM
To: "slitkows.i...@gmail.com<mailto:slitkows.i...@gmail.com>" 
mailto:slitkows.i...@gmail.com>>
Cc: "Bocci, Matthew (Nokia - GB)" 
mailto:matthew.bo...@nokia.com>>, 
"bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>" 
mailto:bess-cha...@ietf.org>>, 
"bess@ietf.org<mailto:bess@ietf.org>" mailto:bess@ietf.org>>
Subject: Re: [bess] WG Adoption and IPR Poll for 
draft-litkowski-bess-rfc5549revision-00

Stephane,

Adding ability to recognize the length of the next hop to any code is purely 
incremental thing. When vendors were asked I do not even recall if there was a 
question if given implementation can infer next hop format from length or not - 
and that is the key problem/point here.

Just asking if you are prepending zeros or not to NH in some SAFIs and stating 
that if so you do revise 5549 to reflect that is not what we should be doing.

The main reason is that as SAFIs are being defined every now and then and there 
is still no clear document if next hop should match NLRI type or not. Moreover 
4364 is still being developed in few vendors. 

Re: [bess] WG Adoption and IPR Poll for draft-litkowski-bess-rfc5549revision-00

[Robert Raszuk]

Hi,

I am not that naive to think that you can do something else here ;)

But can you at least send a pointer to formal implementation report before
proceeding ?

Thx a lot,
R.

On Tue, Dec 3, 2019, 13:17 Acee Lindem (acee)  wrote:

> Hi Robert,
>
> My point is that your proposal to save the 8 bytes of RD can be
> independent of correcting RFC 5449. It is pretty much a no-brainer that
> revising the specification to match the de facto standard of all extant
> implementations is preferable to a non-trivial upgrade and migration.
>
>
>
> Anyway, I don’t wish to engage in a protracted debate and I don’t believe
> the WG wishes to delay publication of this draft. Your lone objection can
> be noted in the shepherds report.
>
>
>
> Thanks,
> Acee
>
>
>
>
>
> *From: *Robert Raszuk 
> *Date: *Monday, December 2, 2019 at 6:37 PM
> *To: *Acee Lindem 
> *Cc: *"slitkows.i...@gmail.com" , "Bocci,
> Matthew (Nokia - GB)" , "bess-cha...@ietf.org" <
> bess-cha...@ietf.org>, "bess@ietf.org" 
> *Subject: *Re: [bess] WG Adoption and IPR Poll for
> draft-litkowski-bess-rfc5549revision-00
>
>
>
> Hi Acee,
>
>
>
> Please observe that this draft defines encoding for SAFI 129 with IPv6 as
> next hop.
>
>
>
> If we are prepend it with zero pls do not forget to also submit the errata
> to RFC 6514 which says
>
> clearly in section 9.2.3.2 that next hop *field* must be set to a routable
> IP address. Not part of the
>
> Next Hop field but the entire *field*.
>
>
>
>When re-advertising an Inter-AS I-PMSI A-D route, the ASBR MUST set
>
>the Next Hop field of the MP_REACH_NLRI attribute to a routable IP
>
>address of the ASBR.
>
>
>
> And the above is just the tip of the iceberg :)
>
>
>
> Bottom line is that instead of publishing the spec which in backwards 
> compatible fashion allows
>
> gradually to fix the implementation errors of the past it is just blessing 
> them. And we all agree
>
> that pushing to each MP_REACH NH field 64 zeros is completely unnecessary.. 
> Not a good thing
>
> in my measures.
>
>
>
> Best,
>
> R.
>
>
>
> PS. And what happens if those 8 octets is not zeros but zero and ones ? 
> Should it be accepted and
>
> ignored or is this an invalid attribute ?
>
>
>
>
>
>
>
> On Mon, Dec 2, 2019 at 11:21 PM Acee Lindem (acee)  wrote:
>
> Robert,
>
>
>
> What you’re suggesting doesn’t really solve the problem that all the
> currently deployed routers that do not follow RFC 5549. No known
> implementations follow RFC 5549. Were you on the meetecho when this was
> presented in the BESS meeting at IETF 106? There was clear consensus in the
> meeting.
>
>
>
> Anyway,  you can put your ideas in a new draft and let them stand on their
> own merit. That way, if there were consensus, we could save those 8 bytes
> of RD. However, we shouldn’t mix this with the draft revising RFC 5549 to
> reflect the current implementations and deployments.
>
>
>
> Thanks,
>
> Acee
>
>
>
> *From: *BESS  on behalf of Robert Raszuk <
> rob...@raszuk.net>
> *Date: *Thursday, November 28, 2019 at 11:58 AM
> *To: *"slitkows.i...@gmail.com" 
> *Cc: *"Bocci, Matthew (Nokia - GB)" , "
> bess-cha...@ietf.org" , "bess@ietf.org" <
> bess@ietf.org>
> *Subject: *Re: [bess] WG Adoption and IPR Poll for
> draft-litkowski-bess-rfc5549revision-00
>
>
>
> Stephane,
>
>
>
> Adding ability to recognize the length of the next hop to any code is
> purely incremental thing. When vendors were asked I do not even recall if
> there was a question if given implementation can infer next hop format from
> length or not - and that is the key problem/point here.
>
>
>
> Just asking if you are prepending zeros or not to NH in some SAFIs and
> stating that if so you do revise 5549 to reflect that is not what we should
> be doing.
>
>
>
> The main reason is that as SAFIs are being defined every now and then and
> there is still no clear document if next hop should match NLRI type or not.
> Moreover 4364 is still being developed in few vendors. Sure they want to be
> backwards compatible too, but with that let's also give them a chance to do
> the right thing vs just follow legacy.
>
>
>
> So yes if you are opening that box my suggestion is to define an
> additional capability indicating if receiver can process next hop without
> any additional nonsense zero padding. All it takes is one paragraph/section
> and one IANA codepoint.
>
>
>
> Stating that this should be new

Re: [bess] WG Adoption and IPR Poll for draft-litkowski-bess-rfc5549revision-00

[Acee Lindem (acee)]

Hi Robert,
My point is that your proposal to save the 8 bytes of RD can be independent of 
correcting RFC 5449. It is pretty much a no-brainer that revising the 
specification to match the de facto standard of all extant implementations is 
preferable to a non-trivial upgrade and migration.

Anyway, I don’t wish to engage in a protracted debate and I don’t believe the 
WG wishes to delay publication of this draft. Your lone objection can be noted 
in the shepherds report.

Thanks,
Acee


From: Robert Raszuk 
Date: Monday, December 2, 2019 at 6:37 PM
To: Acee Lindem 
Cc: "slitkows.i...@gmail.com" , "Bocci, Matthew (Nokia 
- GB)" , "bess-cha...@ietf.org" 
, "bess@ietf.org" 
Subject: Re: [bess] WG Adoption and IPR Poll for 
draft-litkowski-bess-rfc5549revision-00

Hi Acee,

Please observe that this draft defines encoding for SAFI 129 with IPv6 as next 
hop.

If we are prepend it with zero pls do not forget to also submit the errata to 
RFC 6514 which says
clearly in section 9.2.3.2 that next hop *field* must be set to a routable IP 
address. Not part of the
Next Hop field but the entire *field*.


   When re-advertising an Inter-AS I-PMSI A-D route, the ASBR MUST set

   the Next Hop field of the MP_REACH_NLRI attribute to a routable IP

   address of the ASBR.



And the above is just the tip of the iceberg :)



Bottom line is that instead of publishing the spec which in backwards 
compatible fashion allows

gradually to fix the implementation errors of the past it is just blessing 
them. And we all agree

that pushing to each MP_REACH NH field 64 zeros is completely unnecessary. Not 
a good thing

in my measures.



Best,

R.



PS. And what happens if those 8 octets is not zeros but zero and ones ? Should 
it be accepted and

ignored or is this an invalid attribute ?





On Mon, Dec 2, 2019 at 11:21 PM Acee Lindem (acee) 
mailto:a...@cisco.com>> wrote:
Robert,

What you’re suggesting doesn’t really solve the problem that all the currently 
deployed routers that do not follow RFC 5549. No known implementations follow 
RFC 5549. Were you on the meetecho when this was presented in the BESS meeting 
at IETF 106? There was clear consensus in the meeting.

Anyway,  you can put your ideas in a new draft and let them stand on their own 
merit. That way, if there were consensus, we could save those 8 bytes of RD. 
However, we shouldn’t mix this with the draft revising RFC 5549 to reflect the 
current implementations and deployments.

Thanks,
Acee

From: BESS mailto:bess-boun...@ietf.org>> on behalf of 
Robert Raszuk mailto:rob...@raszuk.net>>
Date: Thursday, November 28, 2019 at 11:58 AM
To: "slitkows.i...@gmail.com<mailto:slitkows.i...@gmail.com>" 
mailto:slitkows.i...@gmail.com>>
Cc: "Bocci, Matthew (Nokia - GB)" 
mailto:matthew.bo...@nokia.com>>, 
"bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>" 
mailto:bess-cha...@ietf.org>>, 
"bess@ietf.org<mailto:bess@ietf.org>" mailto:bess@ietf.org>>
Subject: Re: [bess] WG Adoption and IPR Poll for 
draft-litkowski-bess-rfc5549revision-00

Stephane,

Adding ability to recognize the length of the next hop to any code is purely 
incremental thing. When vendors were asked I do not even recall if there was a 
question if given implementation can infer next hop format from length or not - 
and that is the key problem/point here.

Just asking if you are prepending zeros or not to NH in some SAFIs and stating 
that if so you do revise 5549 to reflect that is not what we should be doing.

The main reason is that as SAFIs are being defined every now and then and there 
is still no clear document if next hop should match NLRI type or not. Moreover 
4364 is still being developed in few vendors. Sure they want to be backwards 
compatible too, but with that let's also give them a chance to do the right 
thing vs just follow legacy.

So yes if you are opening that box my suggestion is to define an additional 
capability indicating if receiver can process next hop without any additional 
nonsense zero padding. All it takes is one paragraph/section and one IANA 
codepoint.

Stating that this should be new separate document again updating 5549 and now 
5549revised is really not the best option.

Best,
Robert

On Thu, Nov 28, 2019 at 5:40 PM 
mailto:slitkows.i...@gmail.com>> wrote:
Hi Robert,

Please see some replies inline.

Brgds,

From: Robert Raszuk mailto:rob...@raszuk.net>>
Sent: mercredi 27 novembre 2019 22:18
To: Bocci, Matthew (Nokia - GB) 
mailto:matthew..bo...@nokia.com>>
Cc: bess@ietf.org<mailto:bess@ietf.org>; 
bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>
Subject: Re: [bess] WG Adoption and IPR Poll for 
draft-litkowski-bess-rfc5549revision-00

I do not support this draft in the current form.

This document instead of improving the original specification makes it actually 
worse.
[SLI]

Point 1 

Re: [bess] WG Adoption and IPR Poll for draft-litkowski-bess-rfc5549revision-00

[Zhuangshunwan]

Hi Robert,

Inline with [Shunwan]

Best Regards,
Shunwan

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Robert Raszuk
Sent: Tuesday, December 03, 2019 7:37 AM
To: Acee Lindem (acee) 
Cc: Bocci, Matthew (Nokia - GB) ; 
bess-cha...@ietf.org; slitkows.i...@gmail.com; bess@ietf.org
Subject: Re: [bess] WG Adoption and IPR Poll for 
draft-litkowski-bess-rfc5549revision-00

Hi Acee,

Please observe that this draft defines encoding for SAFI 129 with IPv6 as next 
hop.
[Shunwan] IMO, the 8-byte ZERO RD plus the IPv4 Address as the Nexthop of 
(AFI=1, SAFI=129) and  the 8-byte ZERO RD plus the IPv6 Address as the Nexthop  
of (AFI=2, SAFI=129)  have been widely deployed for many years.
I think It’s reasonable to encode the 8-byte ZERO RD plus the IPv6 Address as 
the Nexthop  for “IPv4 VPN multicast over IPv6 Core” case.

If we are prepend it with zero pls do not forget to also submit the errata to 
RFC 6514 which says
clearly in section 9.2.3.2 that next hop *field* must be set to a routable IP 
address. Not part of the
Next Hop field but the entire *field*.
[Shunwan] IMO, section 9.2.3.2 is for (AFI=1, SAFI=5) and (AFI=2, SAFI=5), not 
for SAFI 129.


   When re-advertising an Inter-AS I-PMSI A-D route, the ASBR MUST set

   the Next Hop field of the MP_REACH_NLRI attribute to a routable IP

   address of the ASBR.



And the above is just the tip of the iceberg :)



Bottom line is that instead of publishing the spec which in backwards 
compatible fashion allows

gradually to fix the implementation errors of the past it is just blessing 
them. And we all agree

that pushing to each MP_REACH NH field 64 zeros is completely unnecessary. Not 
a good thing

in my measures.



Best,

R.



PS. And what happens if those 8 octets is not zeros but zero and ones ? Should 
it be accepted and

ignored or is this an invalid attribute ?





On Mon, Dec 2, 2019 at 11:21 PM Acee Lindem (acee) 
mailto:a...@cisco.com>> wrote:
Robert,

What you’re suggesting doesn’t really solve the problem that all the currently 
deployed routers that do not follow RFC 5549. No known implementations follow 
RFC 5549. Were you on the meetecho when this was presented in the BESS meeting 
at IETF 106? There was clear consensus in the meeting.

Anyway,  you can put your ideas in a new draft and let them stand on their own 
merit. That way, if there were consensus, we could save those 8 bytes of RD. 
However, we shouldn’t mix this with the draft revising RFC 5549 to reflect the 
current implementations and deployments.

Thanks,
Acee

From: BESS mailto:bess-boun...@ietf.org>> on behalf of 
Robert Raszuk mailto:rob...@raszuk.net>>
Date: Thursday, November 28, 2019 at 11:58 AM
To: "slitkows.i...@gmail.com<mailto:slitkows.i...@gmail.com>" 
mailto:slitkows.i...@gmail.com>>
Cc: "Bocci, Matthew (Nokia - GB)" 
mailto:matthew.bo...@nokia.com>>, 
"bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>" 
mailto:bess-cha...@ietf.org>>, 
"bess@ietf.org<mailto:bess@ietf.org>" mailto:bess@ietf.org>>
Subject: Re: [bess] WG Adoption and IPR Poll for 
draft-litkowski-bess-rfc5549revision-00

Stephane,

Adding ability to recognize the length of the next hop to any code is purely 
incremental thing. When vendors were asked I do not even recall if there was a 
question if given implementation can infer next hop format from length or not - 
and that is the key problem/point here.

Just asking if you are prepending zeros or not to NH in some SAFIs and stating 
that if so you do revise 5549 to reflect that is not what we should be doing.

The main reason is that as SAFIs are being defined every now and then and there 
is still no clear document if next hop should match NLRI type or not. Moreover 
4364 is still being developed in few vendors. Sure they want to be backwards 
compatible too, but with that let's also give them a chance to do the right 
thing vs just follow legacy.

So yes if you are opening that box my suggestion is to define an additional 
capability indicating if receiver can process next hop without any additional 
nonsense zero padding. All it takes is one paragraph/section and one IANA 
codepoint.

Stating that this should be new separate document again updating 5549 and now 
5549revised is really not the best option.

Best,
Robert

On Thu, Nov 28, 2019 at 5:40 PM 
mailto:slitkows.i...@gmail.com>> wrote:
Hi Robert,

Please see some replies inline.

Brgds,

From: Robert Raszuk mailto:rob...@raszuk.net>>
Sent: mercredi 27 novembre 2019 22:18
To: Bocci, Matthew (Nokia - GB) 
mailto:matthew..bo...@nokia.com>>
Cc: bess@ietf.org<mailto:bess@ietf.org>; 
bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>
Subject: Re: [bess] WG Adoption and IPR Poll for 
draft-litkowski-bess-rfc5549revision-00

I do not support this draft in the current form.

This document instead of improving the original specification makes it actually

Re: [bess] WG Adoption and IPR Poll for draft-litkowski-bess-rfc5549revision-00

[Robert Raszuk]

Hi Acee,

Please observe that this draft defines encoding for SAFI 129 with IPv6 as
next hop.

If we are prepend it with zero pls do not forget to also submit the errata
to RFC 6514 which says
clearly in section 9.2.3.2 that next hop *field* must be set to a routable
IP address. Not part of the
Next Hop field but the entire *field*.

   When re-advertising an Inter-AS I-PMSI A-D route, the ASBR MUST set
   the Next Hop field of the MP_REACH_NLRI attribute to a routable IP
   address of the ASBR.


And the above is just the tip of the iceberg :)


Bottom line is that instead of publishing the spec which in backwards
compatible fashion allows

gradually to fix the implementation errors of the past it is just
blessing them. And we all agree

that pushing to each MP_REACH NH field 64 zeros is completely
unnecessary. Not a good thing

in my measures.


Best,

R.

PS. And what happens if those 8 octets is not zeros but zero and ones
? Should it be accepted and
ignored or is this an invalid attribute ?



On Mon, Dec 2, 2019 at 11:21 PM Acee Lindem (acee)  wrote:

> Robert,
>
>
>
> What you’re suggesting doesn’t really solve the problem that all the
> currently deployed routers that do not follow RFC 5549. No known
> implementations follow RFC 5549. Were you on the meetecho when this was
> presented in the BESS meeting at IETF 106? There was clear consensus in the
> meeting.
>
>
>
> Anyway,  you can put your ideas in a new draft and let them stand on their
> own merit. That way, if there were consensus, we could save those 8 bytes
> of RD. However, we shouldn’t mix this with the draft revising RFC 5549 to
> reflect the current implementations and deployments.
>
>
>
> Thanks,
>
> Acee
>
>
>
> *From: *BESS  on behalf of Robert Raszuk <
> rob...@raszuk.net>
> *Date: *Thursday, November 28, 2019 at 11:58 AM
> *To: *"slitkows.i...@gmail.com" 
> *Cc: *"Bocci, Matthew (Nokia - GB)" , "
> bess-cha...@ietf.org" , "bess@ietf.org" <
> bess@ietf.org>
> *Subject: *Re: [bess] WG Adoption and IPR Poll for
> draft-litkowski-bess-rfc5549revision-00
>
>
>
> Stephane,
>
>
>
> Adding ability to recognize the length of the next hop to any code is
> purely incremental thing. When vendors were asked I do not even recall if
> there was a question if given implementation can infer next hop format from
> length or not - and that is the key problem/point here.
>
>
>
> Just asking if you are prepending zeros or not to NH in some SAFIs and
> stating that if so you do revise 5549 to reflect that is not what we should
> be doing.
>
>
>
> The main reason is that as SAFIs are being defined every now and then and
> there is still no clear document if next hop should match NLRI type or not.
> Moreover 4364 is still being developed in few vendors. Sure they want to be
> backwards compatible too, but with that let's also give them a chance to do
> the right thing vs just follow legacy.
>
>
>
> So yes if you are opening that box my suggestion is to define an
> additional capability indicating if receiver can process next hop without
> any additional nonsense zero padding. All it takes is one paragraph/section
> and one IANA codepoint.
>
>
>
> Stating that this should be new separate document again updating 5549 and
> now 5549revised is really not the best option.
>
>
>
> Best,
>
> Robert
>
>
>
> On Thu, Nov 28, 2019 at 5:40 PM  wrote:
>
> Hi Robert,
>
>
>
> Please see some replies inline.
>
>
>
> Brgds,
>
>
>
> *From:* Robert Raszuk 
> *Sent:* mercredi 27 novembre 2019 22:18
> *To:* Bocci, Matthew (Nokia - GB)  >
> *Cc:* bess@ietf.org; bess-cha...@ietf.org
> *Subject:* Re: [bess] WG Adoption and IPR Poll for
> draft-litkowski-bess-rfc5549revision-00
>
>
>
> *I do not support this draft in the current form. *
>
>
>
> This document instead of improving the original specification makes it
> actually worse.
>
> [SLI]
>
>
>
> Point 1 -
>
>
>
> Original RFC sec. 6.2:
>
>
>o  Network Address of Next Hop = IPv6 address of Next Hop
>
>
>
> Proposed text:
>
>
>
>o  Network Address of Next Hop = VPN-IPv6 address of Next Hop whose
>
> RD is set to zero
>
>
>
>
>
> As it has been explained when you negotiate in capability AFI2 as next hop
> it is just 16 octets - not 24.
>
> [SLI] AFI2 means that the nexthop is encoded with a format compliant with
> an AFI2, but does not tell anything about the SAFI. A VPN-IPv6 address is
> still AFI2.
>
>
>
> Next hop never has an RD.
>
> [SLI] We have already discussed about that. RD doesn’t make any sense for
> 

Re: [bess] WG Adoption and IPR Poll for draft-litkowski-bess-rfc5549revision-00

[Acee Lindem (acee)]

Robert,

What you’re suggesting doesn’t really solve the problem that all the currently 
deployed routers that do not follow RFC 5549. No known implementations follow 
RFC 5549. Were you on the meetecho when this was presented in the BESS meeting 
at IETF 106? There was clear consensus in the meeting.

Anyway,  you can put your ideas in a new draft and let them stand on their own 
merit. That way, if there were consensus, we could save those 8 bytes of RD. 
However, we shouldn’t mix this with the draft revising RFC 5549 to reflect the 
current implementations and deployments.

Thanks,
Acee

From: BESS  on behalf of Robert Raszuk 

Date: Thursday, November 28, 2019 at 11:58 AM
To: "slitkows.i...@gmail.com" 
Cc: "Bocci, Matthew (Nokia - GB)" , 
"bess-cha...@ietf.org" , "bess@ietf.org" 
Subject: Re: [bess] WG Adoption and IPR Poll for 
draft-litkowski-bess-rfc5549revision-00

Stephane,

Adding ability to recognize the length of the next hop to any code is purely 
incremental thing. When vendors were asked I do not even recall if there was a 
question if given implementation can infer next hop format from length or not - 
and that is the key problem/point here.

Just asking if you are prepending zeros or not to NH in some SAFIs and stating 
that if so you do revise 5549 to reflect that is not what we should be doing.

The main reason is that as SAFIs are being defined every now and then and there 
is still no clear document if next hop should match NLRI type or not. Moreover 
4364 is still being developed in few vendors. Sure they want to be backwards 
compatible too, but with that let's also give them a chance to do the right 
thing vs just follow legacy.

So yes if you are opening that box my suggestion is to define an additional 
capability indicating if receiver can process next hop without any additional 
nonsense zero padding. All it takes is one paragraph/section and one IANA 
codepoint.

Stating that this should be new separate document again updating 5549 and now 
5549revised is really not the best option.

Best,
Robert

On Thu, Nov 28, 2019 at 5:40 PM 
mailto:slitkows.i...@gmail.com>> wrote:
Hi Robert,

Please see some replies inline.

Brgds,

From: Robert Raszuk mailto:rob...@raszuk.net>>
Sent: mercredi 27 novembre 2019 22:18
To: Bocci, Matthew (Nokia - GB) 
mailto:matthew..bo...@nokia.com>>
Cc: bess@ietf.org<mailto:bess@ietf.org>; 
bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>
Subject: Re: [bess] WG Adoption and IPR Poll for 
draft-litkowski-bess-rfc5549revision-00

I do not support this draft in the current form.

This document instead of improving the original specification makes it actually 
worse.
[SLI]

Point 1 -

Original RFC sec. 6.2:

   o  Network Address of Next Hop = IPv6 address of Next Hop

Proposed text:

   o  Network Address of Next Hop = VPN-IPv6 address of Next Hop whose
RD is set to zero


As it has been explained when you negotiate in capability AFI2 as next hop it 
is just 16 octets - not 24.
[SLI] AFI2 means that the nexthop is encoded with a format compliant with an 
AFI2, but does not tell anything about the SAFI. A VPN-IPv6 address is still 
AFI2.

Next hop never has an RD.
[SLI] We have already discussed about that. RD doesn’t make any sense for a 
nexthop address. No one disagrees on that point. However our legacy 2547bis 
introduced a nexthop encoded as a VPN-IP address, and all VPN unicast SAFIs are 
following this. As RD does not make sense, zeroes are just added to fit the 
size of the address format. In reality, it is just an IP address with 0es 
padded before. Of course,  it would have been cleaner to use only a regular IP 
address instead of a VPN-IP address but again that’s our legacy.

The fact that some implementations are matching length of NLRI with length of 
next hop no where should be made equal that next hop has 8 octet dummy Route 
Distinguisher.
[SLI] Again this is coming from legacy.


If revision is to be made would be to explicitly negotiate capability to infer 
next hop encoding from the length.
[SLI] Are you talking about a new capability or the existing ENH cap ? ENH 
tells you what is the NH AFI, so the only length check required is for the case 
of one or two IPv6 addresses. A new cap means a new solution, and that’s not 
the goal here.


Point 2 -

Addition of section 6.3 and SAFI 129 is fine, but again next hop encoding is 
lightly stating suboptimal.

Conclusion:

As we have discussed on and off line if revision is to be made let's make it 
both backwards compatible, Let's make it applicable to both IPv4 and IPv6 next 
hop addresses and let's allow explicit capability where implementations could 
indicate that it can recognize next hop value from its length. After all we are 
talking about just 4 discrete possible values here.
[SLI] The goal is not to create something new here, but just to reflect how 
RFC5549 has been implemented for the SAFI 128

Re: [bess] WG Adoption and IPR Poll for draft-litkowski-bess-rfc5549revision-00

[Keyur Patel]

+1. Support the adoption. I am not aware of any IPR.

Regards,
Keyur

From: BESS  on behalf of "slitkows.i...@gmail.com" 

Date: Wednesday, November 27, 2019 at 4:49 AM
To: "'Bocci, Matthew (Nokia - GB)'" , "bess@ietf.org" 

Cc: "bess-cha...@ietf.org" 
Subject: Re: [bess] WG Adoption and IPR Poll for 
draft-litkowski-bess-rfc5549revision-00

Support,
I’m not aware of any IPR.

From: BESS mailto:bess-boun...@ietf.org>> on behalf of 
"Bocci, Matthew (Nokia - GB)" 
mailto:matthew.bo...@nokia.com>>
Date: Wednesday, November 27, 2019 at 7:37 AM
To: "bess@ietf.org<mailto:bess@ietf.org>" mailto:bess@ietf.org>>
Cc: "bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>" 
mailto:bess-cha...@ietf.org>>
Subject: [bess] WG Adoption and IPR Poll for 
draft-litkowski-bess-rfc5549revision-00

Hello,

This email begins a two-weeks WG adoption poll for 
draft-litkowski-bess-rfc5549revision-00 [1] .

Please review the draft and post any comments to the BESS working group list.

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, copying the BESS mailing list. The document won't progress 
without answers from all the authors and contributors.

Currently, there are no IPR disclosures 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.

This poll for adoption closes on Wednesday 11th December 2019.

Regards,
Matthew

[1] https://datatracker.ietf.org/doc/draft-litkowski-bess-rfc5549revision/



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

Re: [bess] WG Adoption and IPR Poll for draft-litkowski-bess-rfc5549revision-00

[slitkows.ietf]

Hi Robert,

 

Thinking about future, I’m not sure that using only length of NH is a good 
thing. Of course, with IPv4 vs IPv6, it works. But what happens if in the 
future we have different NH types using a common size ? How do you ensure that 
the NH is correctly encoded ? If you want to be 100% clean, you need a field 
telling how is encoded your NH. This is purely theoretical, but nothing can 
prevent this to happen. This discussion has wider implications. If we just 
brainstorm, we can even wonder if the NH field is really needed when tunnels 
are used and tunnel-encaps may be a solution to replace the NH for some 
AFI/SAFIs.  That’s a different discussion 😊.

 

> The main reason is that as SAFIs are being defined every now and then and 
> there is still no clear document if next hop should match NLRI type or not.

As already discussed offline, I would be happy to see guidelines written in IDR 
to make things better for any new AFI/SAFIs and possibly make all existing 
AFI/SAFIs working with the new guidelines through a capability or whatever 
solution. But again, this is orthogonal.

 

Again the goal here is not to do a revolution, but just accommodating the 
standard to how the implementations of RFC5549 are working. Changing the 
solution is not the goal. 

You can’t force people to change their code just because we did things 
suboptimal from a standard point of view. Codes are working today and are 
deployed.

 

Any new solution could be done in a separate document and then it will be up to 
each vendor to implement it or not and to customers to use it or not.

 

 

Stephane

 

 

 

From: Robert Raszuk  
Sent: jeudi 28 novembre 2019 17:57
To: slitkows.i...@gmail.com
Cc: Bocci, Matthew (Nokia - GB) ; bess@ietf.org; 
bess-cha...@ietf.org
Subject: Re: [bess] WG Adoption and IPR Poll for 
draft-litkowski-bess-rfc5549revision-00

 

Stephane,

 

Adding ability to recognize the length of the next hop to any code is purely 
incremental thing. When vendors were asked I do not even recall if there was a 
question if given implementation can infer next hop format from length or not - 
and that is the key problem/point here. 

 

Just asking if you are prepending zeros or not to NH in some SAFIs and stating 
that if so you do revise 5549 to reflect that is not what we should be doing. 

 

The main reason is that as SAFIs are being defined every now and then and there 
is still no clear document if next hop should match NLRI type or not. Moreover 
4364 is still being developed in few vendors. Sure they want to be backwards 
compatible too, but with that let's also give them a chance to do the right 
thing vs just follow legacy. 

 

So yes if you are opening that box my suggestion is to define an additional 
capability indicating if receiver can process next hop without any additional 
nonsense zero padding. All it takes is one paragraph/section and one IANA 
codepoint. 

 

Stating that this should be new separate document again updating 5549 and now 
5549revised is really not the best option. 

 

Best,

Robert

 

On Thu, Nov 28, 2019 at 5:40 PM mailto:slitkows.i...@gmail.com> > wrote:

Hi Robert,

 

Please see some replies inline.

 

Brgds,

 

From: Robert Raszuk mailto:rob...@raszuk.net> > 
Sent: mercredi 27 novembre 2019 22:18
To: Bocci, Matthew (Nokia - GB) mailto:matthew.bo...@nokia.com> >
Cc: bess@ietf.org <mailto:bess@ietf.org> ; bess-cha...@ietf.org 
<mailto:bess-cha...@ietf.org> 
Subject: Re: [bess] WG Adoption and IPR Poll for 
draft-litkowski-bess-rfc5549revision-00

 

I do not support this draft in the current form. 

 

This document instead of improving the original specification makes it actually 
worse. 

[SLI]

 

Point 1 - 

 

Original RFC sec. 6.2:   



   o  Network Address of Next Hop = IPv6 address of Next Hop

 

Proposed text:

 


   o  Network Address of Next Hop = VPN-IPv6 address of Next Hop whose


RD is set to zero



 



 

As it has been explained when you negotiate in capability AFI2 as next hop it 
is just 16 octets - not 24. 

[SLI] AFI2 means that the nexthop is encoded with a format compliant with an 
AFI2, but does not tell anything about the SAFI. A VPN-IPv6 address is still 
AFI2.

 

Next hop never has an RD. 

[SLI] We have already discussed about that. RD doesn’t make any sense for a 
nexthop address. No one disagrees on that point. However our legacy 2547bis 
introduced a nexthop encoded as a VPN-IP address, and all VPN unicast SAFIs are 
following this. As RD does not make sense, zeroes are just added to fit the 
size of the address format. In reality, it is just an IP address with 0es 
padded before. Of course,  it would have been cleaner to use only a regular IP 
address instead of a VPN-IP address but again that’s our legacy. 

 

The fact that some implementations are matching length of NLRI with length of 
next hop no where should be made equal that next h

Re: [bess] WG Adoption and IPR Poll for draft-litkowski-bess-rfc5549revision-00

[Jakob Heitz (jheitz)]

I support adoption.

Regards,
Jakob.

From: BESS  On Behalf Of Bocci, Matthew (Nokia - GB)
Sent: Wednesday, November 27, 2019 4:37 AM
To: bess@ietf.org
Cc: bess-cha...@ietf.org
Subject: [bess] WG Adoption and IPR Poll for 
draft-litkowski-bess-rfc5549revision-00

Hello,

This email begins a two-weeks WG adoption poll for 
draft-litkowski-bess-rfc5549revision-00 [1] .

Please review the draft and post any comments to the BESS working group list.

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, copying the BESS mailing list. The document won't progress 
without answers from all the authors and contributors.

Currently, there are no IPR disclosures 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.

This poll for adoption closes on Wednesday 11th December 2019.

Regards,
Matthew

[1] https://datatracker.ietf.org/doc/draft-litkowski-bess-rfc5549revision/



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

Re: [bess] WG Adoption and IPR Poll for draft-litkowski-bess-rfc5549revision-00

[Neeraj Malhotra]

Hi,

Support adoption.

Thanks,
Neeraj

> On Nov 27, 2019, at 4:36 AM, Bocci, Matthew (Nokia - GB) 
>  wrote:
> 
> Hello,
>  
> This email begins a two-weeks WG adoption poll for 
> draft-litkowski-bess-rfc5549revision-00 [1] .
>  
> Please review the draft and post any comments to the BESS working group list.
>  
> 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, copying the BESS mailing list. The document won't 
> progress without answers from all the authors and contributors.
>  
> Currently, there are no IPR disclosures 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.
>  
> This poll for adoption closes on Wednesday 11th December 2019.  
>  
> Regards,
> Matthew
>  
> [1] https://datatracker.ietf.org/doc/draft-litkowski-bess-rfc5549revision/
>  
>  
>  
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG Adoption and IPR Poll for draft-litkowski-bess-rfc5549revision-00

[Robert Raszuk]

Stephane,

Adding ability to recognize the length of the next hop to any code is
purely incremental thing. When vendors were asked I do not even recall if
there was a question if given implementation can infer next hop format from
length or not - and that is the key problem/point here.

Just asking if you are prepending zeros or not to NH in some SAFIs and
stating that if so you do revise 5549 to reflect that is not what we should
be doing.

The main reason is that as SAFIs are being defined every now and then and
there is still no clear document if next hop should match NLRI type or not.
Moreover 4364 is still being developed in few vendors. Sure they want to be
backwards compatible too, but with that let's also give them a chance to do
the right thing vs just follow legacy.

So yes if you are opening that box my suggestion is to define an additional
capability indicating if receiver can process next hop without any
additional nonsense zero padding. All it takes is one paragraph/section and
one IANA codepoint.

Stating that this should be new separate document again updating 5549 and
now 5549revised is really not the best option.

Best,
Robert

On Thu, Nov 28, 2019 at 5:40 PM  wrote:

> Hi Robert,
>
>
>
> Please see some replies inline.
>
>
>
> Brgds,
>
>
>
> *From:* Robert Raszuk 
> *Sent:* mercredi 27 novembre 2019 22:18
> *To:* Bocci, Matthew (Nokia - GB) 
> *Cc:* bess@ietf.org; bess-cha...@ietf.org
> *Subject:* Re: [bess] WG Adoption and IPR Poll for
> draft-litkowski-bess-rfc5549revision-00
>
>
>
> *I do not support this draft in the current form. *
>
>
>
> This document instead of improving the original specification makes it
> actually worse.
>
> [SLI]
>
>
>
> Point 1 -
>
>
>
> Original RFC sec. 6.2:
>
>
>o  Network Address of Next Hop = IPv6 address of Next Hop
>
>
>
> Proposed text:
>
>
>
>
>o  Network Address of Next Hop = VPN-IPv6 address of Next Hop whose
>
> RD is set to zero
>
>
>
>
>
> As it has been explained when you negotiate in capability AFI2 as next hop
> it is just 16 octets - not 24.
>
> [SLI] AFI2 means that the nexthop is encoded with a format compliant with
> an AFI2, but does not tell anything about the SAFI. A VPN-IPv6 address is
> still AFI2.
>
>
>
> Next hop never has an RD.
>
> [SLI] We have already discussed about that. RD doesn’t make any sense for
> a nexthop address. No one disagrees on that point. However our legacy
> 2547bis introduced a nexthop encoded as a VPN-IP address, and all VPN
> unicast SAFIs are following this. As RD does not make sense, zeroes are
> just added to fit the size of the address format. In reality, it is just an
> IP address with 0es padded before. Of course,  it would have been cleaner
> to use only a regular IP address instead of a VPN-IP address but again
> that’s our legacy.
>
>
>
> The fact that some implementations are matching length of NLRI with length
> of next hop no where should be made equal that next hop has 8 octet dummy
> Route Distinguisher.
>
> [SLI] Again this is coming from legacy.
>
>
>
>
>
> If revision is to be made would be to explicitly negotiate capability to
> infer next hop encoding from the length.
>
> [SLI] Are you talking about a new capability or the existing ENH cap ? ENH
> tells you what is the NH AFI, so the only length check required is for the
> case of one or two IPv6 addresses. A new cap means a new solution, and
> that’s not the goal here.
>
>
>
>
>
> Point 2 -
>
>
>
> Addition of section 6.3 and SAFI 129 is fine, but again next hop encoding
> is lightly stating suboptimal.
>
>
>
> Conclusion:
>
>
>
> As we have discussed on and off line if revision is to be made let's make
> it both backwards compatible, Let's make it applicable to both IPv4 and
> IPv6 next hop addresses and let's allow explicit capability where
> implementations could indicate that it can recognize next hop value from
> its length. After all we are talking about just 4 discrete possible values
> here.
>
> [SLI] The goal is not to create something new here, but just to reflect
> how RFC5549 has been implemented for the SAFI 128/129 cases. The goal is
> also to minimize running code changes too (and even avoid !). We have to
> deal with what has been shipped and deployed by vendors today. We can still
> create something completely new, with a new cap and new procedures, but I
> think this is orthogonal to “aligning RFC5549 with implementations” as
> RFC5549 is there anyway and we can’t blindly forget it due to the codes
> that are available.
>
>
>
>
>
>
>
> Cheers,
>
> Robert.
>
>
>
>
>
>

Re: [bess] WG Adoption and IPR Poll for draft-litkowski-bess-rfc5549revision-00

[slitkows.ietf]

Hi Robert,

 

Please see some replies inline.

 

Brgds,

 

From: Robert Raszuk  
Sent: mercredi 27 novembre 2019 22:18
To: Bocci, Matthew (Nokia - GB) 
Cc: bess@ietf.org; bess-cha...@ietf.org
Subject: Re: [bess] WG Adoption and IPR Poll for 
draft-litkowski-bess-rfc5549revision-00

 

I do not support this draft in the current form. 

 

This document instead of improving the original specification makes it actually 
worse. 

[SLI]

 

Point 1 - 

 

Original RFC sec. 6.2:   



   o  Network Address of Next Hop = IPv6 address of Next Hop

 

Proposed text:

 





   o  Network Address of Next Hop = VPN-IPv6 address of Next Hop whose


RD is set to zero



 



 

As it has been explained when you negotiate in capability AFI2 as next hop it 
is just 16 octets - not 24. 

[SLI] AFI2 means that the nexthop is encoded with a format compliant with an 
AFI2, but does not tell anything about the SAFI. A VPN-IPv6 address is still 
AFI2.

 

Next hop never has an RD. 

[SLI] We have already discussed about that. RD doesn’t make any sense for a 
nexthop address. No one disagrees on that point. However our legacy 2547bis 
introduced a nexthop encoded as a VPN-IP address, and all VPN unicast SAFIs are 
following this. As RD does not make sense, zeroes are just added to fit the 
size of the address format. In reality, it is just an IP address with 0es 
padded before. Of course,  it would have been cleaner to use only a regular IP 
address instead of a VPN-IP address but again that’s our legacy. 

 

The fact that some implementations are matching length of NLRI with length of 
next hop no where should be made equal that next hop has 8 octet dummy Route 
Distinguisher. 

[SLI] Again this is coming from legacy. 

 

 

If revision is to be made would be to explicitly negotiate capability to infer 
next hop encoding from the length. 

[SLI] Are you talking about a new capability or the existing ENH cap ? ENH 
tells you what is the NH AFI, so the only length check required is for the case 
of one or two IPv6 addresses. A new cap means a new solution, and that’s not 
the goal here. 

 

 

Point 2 - 

 

Addition of section 6.3 and SAFI 129 is fine, but again next hop encoding is 
lightly stating suboptimal. 

 

Conclusion: 

 

As we have discussed on and off line if revision is to be made let's make it 
both backwards compatible, Let's make it applicable to both IPv4 and IPv6 next 
hop addresses and let's allow explicit capability where implementations could 
indicate that it can recognize next hop value from its length. After all we are 
talking about just 4 discrete possible values here. 

[SLI] The goal is not to create something new here, but just to reflect how 
RFC5549 has been implemented for the SAFI 128/129 cases. The goal is also to 
minimize running code changes too (and even avoid !). We have to deal with what 
has been shipped and deployed by vendors today. We can still create something 
completely new, with a new cap and new procedures, but I think this is 
orthogonal to “aligning RFC5549 with implementations” as RFC5549 is there 
anyway and we can’t blindly forget it due to the codes that are available. 

 

 

 

Cheers,

Robert.

 

 

 

 

 

 

 

 

 

On Wed, Nov 27, 2019 at 1:36 PM Bocci, Matthew (Nokia - GB) 
mailto:matthew.bo...@nokia.com> > wrote:

Hello,

 

This email begins a two-weeks WG adoption poll for 
draft-litkowski-bess-rfc5549revision-00 [1] .

 

Please review the draft and post any comments to the BESS working group list.

 

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, copying the BESS mailing list. The document won't progress 
without answers from all the authors and contributors.

 

Currently, there are no IPR disclosures 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.

 

This poll for adoption closes on Wednesday 11th December 2019.  

 

Regards,

Matthew 

 

[1] https://datatracker.ietf.org/doc/draft-litkowski-bess-rfc5549revision/

 

 

 

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

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

Re: [bess] WG Adoption and IPR Poll for draft-litkowski-bess-rfc5549revision-00

[Lizhenbin]

Hi Bocci & WG,
I support the adoption of the draft. There have been multiple implementations 
and the revision is well accepted.


Best Regards,
Zhenbin (Robin)





From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Bocci, Matthew (Nokia - 
GB)
Sent: Wednesday, November 27, 2019 8:37 PM
To: bess@ietf.org
Cc: bess-cha...@ietf.org
Subject: [bess] WG Adoption and IPR Poll for 
draft-litkowski-bess-rfc5549revision-00

Hello,

This email begins a two-weeks WG adoption poll for 
draft-litkowski-bess-rfc5549revision-00 [1] .

Please review the draft and post any comments to the BESS working group list.

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, copying the BESS mailing list. The document won't progress 
without answers from all the authors and contributors.

Currently, there are no IPR disclosures 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.

This poll for adoption closes on Wednesday 11th December 2019.

Regards,
Matthew

[1] https://datatracker.ietf.org/doc/draft-litkowski-bess-rfc5549revision/



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

Re: [bess] WG Adoption and IPR Poll for draft-litkowski-bess-rfc5549revision-00

[Dongjie (Jimmy)]

Hi,

I support the adoption of this document.

Best regards,
Jie
发件人：Bocci, Matthew (Nokia - GB) 
收件人：bess 
抄 送：bess-chairs 
时 间：2019-11-27 20:37:25
主题[bess] WG Adoption and IPR Poll for draft-litkowski-bess-rfc5549revision-00

Hello,

This email begins a two-weeks WG adoption poll for 
draft-litkowski-bess-rfc5549revision-00 [1] .

Please review the draft and post any comments to the BESS working group list.

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, copying the BESS mailing list. The document won't progress 
without answers from all the authors and contributors.

Currently, there are no IPR disclosures 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.

This poll for adoption closes on Wednesday 11th December 2019.

Regards,
Matthew

[1] https://datatracker.ietf.org/doc/draft-litkowski-bess-rfc5549revision/



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

Re: [bess] WG Adoption and IPR Poll for draft-litkowski-bess-rfc5549revision-00

[Wanghaibo (Rainsword)]

Support adoption of this draft.

Regards,
Haibo

发件人: BESS [mailto:bess-boun...@ietf.org] 代表 Bocci, Matthew (Nokia - GB)
发送时间: 2019年11月27日 20:37
收件人: bess@ietf.org
抄送: bess-cha...@ietf.org
主题: [bess] WG Adoption and IPR Poll for draft-litkowski-bess-rfc5549revision-00

Hello,

This email begins a two-weeks WG adoption poll for 
draft-litkowski-bess-rfc5549revision-00 [1] .

Please review the draft and post any comments to the BESS working group list.

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, copying the BESS mailing list. The document won't progress 
without answers from all the authors and contributors.

Currently, there are no IPR disclosures 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.

This poll for adoption closes on Wednesday 11th December 2019.

Regards,
Matthew

[1] https://datatracker.ietf.org/doc/draft-litkowski-bess-rfc5549revision/



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

Re: [bess] WG Adoption and IPR Poll for draft-litkowski-bess-rfc5549revision-00

[Robert Raszuk]

*I do not support this draft in the current form. *

This document instead of improving the original specification makes it
actually worse.

Point 1 -

Original RFC sec. 6.2:

o Network Address of Next Hop = IPv6 address of Next Hop

Proposed text:


o Network Address of Next Hop = VPN-IPv6 address of Next Hop whose
RD is set to zero

As it has been explained when you negotiate in capability AFI2 as next hop
it is just 16 octets - not 24. Next hop never has an RD. The fact that some
implementations are matching length of NLRI with length of next hop no
where should be made equal that next hop has 8 octet dummy Route
Distinguisher.

If revision is to be made would be to explicitly negotiate capability to
infer next hop encoding from the length.

Point 2 -

Addition of section 6.3 and SAFI 129 is fine, but again next hop encoding
is lightly stating suboptimal.

Conclusion:

As we have discussed on and off line if revision is to be made let's make
it both backwards compatible, Let's make it applicable to both IPv4 and
IPv6 next hop addresses and let's allow explicit capability where
implementations could indicate that it can recognize next hop value from
its length. After all we are talking about just 4 discrete possible values
here.

Cheers,
Robert.









On Wed, Nov 27, 2019 at 1:36 PM Bocci, Matthew (Nokia - GB) <
matthew.bo...@nokia.com> wrote:

> Hello,
>
>
>
> This email begins a two-weeks WG adoption poll for
> draft-litkowski-bess-rfc5549revision-00 [1] .
>
>
>
> Please review the draft and post any comments to the BESS working group
> list.
>
>
>
> 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, copying the BESS mailing list. The document won't
> progress without answers from all the authors and contributors.
>
>
>
> Currently, there are no IPR disclosures 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.
>
>
>
> This poll for adoption closes on Wednesday 11th December 2019.
>
>
>
> Regards,
>
> Matthew
>
>
>
> [1] https://datatracker.ietf.org/doc/draft-litkowski-bess-rfc5549revision/
>
>
>
>
>
>
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG Adoption and IPR Poll for draft-litkowski-bess-rfc5549revision-00

[UTTARO, JAMES]

Support

Thanks,
  Jim Uttaro

From: BESS  On Behalf Of Rabadan, Jorge (Nokia - 
US/Mountain View)
Sent: Wednesday, November 27, 2019 8:49 AM
To: Bocci, Matthew (Nokia - GB) ; bess@ietf.org
Cc: bess-cha...@ietf.org
Subject: Re: [bess] WG Adoption and IPR Poll for 
draft-litkowski-bess-rfc5549revision-00

Support.

Thx
Jorge

From: BESS mailto:bess-boun...@ietf.org>> on behalf of 
"Bocci, Matthew (Nokia - GB)" 
mailto:matthew.bo...@nokia.com>>
Date: Wednesday, November 27, 2019 at 1:37 PM
To: "bess@ietf.org<mailto:bess@ietf.org>" mailto:bess@ietf.org>>
Cc: "bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>" 
mailto:bess-cha...@ietf.org>>
Subject: [bess] WG Adoption and IPR Poll for 
draft-litkowski-bess-rfc5549revision-00

Hello,

This email begins a two-weeks WG adoption poll for 
draft-litkowski-bess-rfc5549revision-00 [1] .

Please review the draft and post any comments to the BESS working group list.

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, copying the BESS mailing list. The document won't progress 
without answers from all the authors and contributors.

Currently, there are no IPR disclosures 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.

This poll for adoption closes on Wednesday 11th December 2019.

Regards,
Matthew

[1] 
https://datatracker.ietf.org/doc/draft-litkowski-bess-rfc5549revision/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dlitkowski-2Dbess-2Drfc5549revision_&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=KTZwadYRYczBYkUocf2pWvwTrHSrVmAj3aWNTW3wFjI&s=1cWbexz43qUkDoO49UY3ESa_A6Cmz1oH59AbH3vDzCw&e=>



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

Re: [bess] WG Adoption and IPR Poll for draft-litkowski-bess-rfc5549revision-00

[Alexander Vainshtein]

Stephane,
Lots of thanks for a prompt and very informative response.

Matthew,
I support adoption of this draft.

Get Outlook for Android<https://aka.ms/ghei36>


From: slitkows.i...@gmail.com 
Sent: Wednesday, November 27, 2019, 16:56
To: Alexander Vainshtein; 'Bocci, Matthew (Nokia - GB)'
Cc: bess-cha...@ietf.org; bess@ietf.org
Subject: RE: [bess] WG Adoption and IPR Poll for 
draft-litkowski-bess-rfc5549revision-00

Hi Sasha,

The changes to RFC5549 are:

  *   Changing the NH encoding for AFI/SAFI 1/128
  *   Enable the behavior for AFI/SAFI 1/129 (same as AFI/SAFI 1/128)

The fact of doing it in BESS has been agreed by the ADs (INT and RTG) as we 
only changes the VPN SAFIs.

Martin, our AD, is looking at the right way to proceed and will confirm, but 
this may not be a real bis that obsoletes RFC5549 (that’s why the draft is 
named revision and not bis). One of the opened possibility is to make RFC5549 
historic and not obsolete.

Brgds,

Stephane


From: Alexander Vainshtein 
Sent: mercredi 27 novembre 2019 15:39
To: Bocci, Matthew (Nokia - GB) 
Cc: bess-cha...@ietf.org; bess@ietf.org
Subject: RE: [bess] WG Adoption and IPR Poll for 
draft-litkowski-bess-rfc5549revision-00

Matthew and all,
I have a couple of questions about the draft in question that, if answered, 
would help me to define my position with regard to its adoption:

  1.  The draft is a “bis” draft but it does not contain a section that lists 
the changes vs. RFC 5549 (customary in the “bis” drafts). Am I right to guess 
that the changes introduced by this draft deal exclusively with just the routes 
used with mVPN?
  2.  If the answer to the question above is positive, I would agree that BESS 
(that handles mVPN among other things) is the right home for this document 
(SOFTWIRES WG that has delivered RFC 5549 has concluded). Otherwise, I would 
like to understand why adoption by BESS (and not, say, by the IDR WG) is 
considered?

Regards, and lots of thanks in advance,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   
alexander.vainsht...@ecitele.com<mailto:alexander.vainsht...@ecitele.com>

From: BESS mailto:bess-boun...@ietf.org>> On Behalf Of 
Bocci, Matthew (Nokia - GB)
Sent: Wednesday, November 27, 2019 2:37 PM
To: bess@ietf.org<mailto:bess@ietf.org>
Cc: bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>
Subject: [bess] WG Adoption and IPR Poll for 
draft-litkowski-bess-rfc5549revision-00

Hello,

This email begins a two-weeks WG adoption poll for 
draft-litkowski-bess-rfc5549revision-00 [1] .

Please review the draft and post any comments to the BESS working group list.

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, copying the BESS mailing list. The document won't progress 
without answers from all the authors and contributors.

Currently, there are no IPR disclosures 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.

This poll for adoption closes on Wednesday 11th December 2019.

Regards,
Matthew

[1] 
https://datatracker.ietf.org/doc/draft-litkowski-bess-rfc5549revision/<https://clicktime.symantec.com/375yKLee6q3yvdfTRuJxJrm6H2?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-litkowski-bess-rfc5549revision%2F>




___

This e-mail message is intended for the recipient only and contains information 
which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received 
this
transmission in error, please inform us by e-mail, phone or fax, and then 
delete the original
and all copies thereof.
___


___

This e-mail message is intended for the recipient only and contains information 
which is 
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received 
this 
transmission in error, please inform us by e-mail, phone or fax, and then 
delete the original 
and all copies thereof.
__
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG Adoption and IPR Poll for draft-litkowski-bess-rfc5549revision-00

[Jeff Tantsura]

Support the adoption, thanks for doing this work!

Regards,
Jeff

> On Nov 27, 2019, at 04:37, Bocci, Matthew (Nokia - GB) 
>  wrote:
> 
> 
> Hello,
>  
> This email begins a two-weeks WG adoption poll for 
> draft-litkowski-bess-rfc5549revision-00 [1] .
>  
> Please review the draft and post any comments to the BESS working group list.
>  
> 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, copying the BESS mailing list. The document won't 
> progress without answers from all the authors and contributors.
>  
> Currently, there are no IPR disclosures 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.
>  
> This poll for adoption closes on Wednesday 11th December 2019.  
>  
> Regards,
> Matthew
>  
> [1] https://datatracker.ietf.org/doc/draft-litkowski-bess-rfc5549revision/
>  
>  
>  
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG Adoption and IPR Poll for draft-litkowski-bess-rfc5549revision-00

[Kesavan Thiruvenkatasamy (kethiruv)]

Support.

Regards,
Kesavan


From: BESS  on behalf of "Bocci, Matthew (Nokia - GB)" 

Date: Wednesday, November 27, 2019 at 4:37 AM
To: "bess@ietf.org" 
Cc: "bess-cha...@ietf.org" 
Subject: [bess] WG Adoption and IPR Poll for 
draft-litkowski-bess-rfc5549revision-00

Hello,

This email begins a two-weeks WG adoption poll for 
draft-litkowski-bess-rfc5549revision-00 [1] .

Please review the draft and post any comments to the BESS working group list.

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, copying the BESS mailing list. The document won't progress 
without answers from all the authors and contributors.

Currently, there are no IPR disclosures 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.

This poll for adoption closes on Wednesday 11th December 2019.

Regards,
Matthew

[1] https://datatracker.ietf.org/doc/draft-litkowski-bess-rfc5549revision/



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

Re: [bess] WG Adoption and IPR Poll for draft-litkowski-bess-rfc5549revision-00

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

support

From: BESS  on behalf of Jorge Rabadan 

Date: Wednesday, 27 November 2019 at 14:49
To: "Bocci, Matthew (Nokia - GB)" , "bess@ietf.org" 

Cc: "bess-cha...@ietf.org" 
Subject: Re: [bess] WG Adoption and IPR Poll for 
draft-litkowski-bess-rfc5549revision-00

Support.

Thx
Jorge

From: BESS  on behalf of "Bocci, Matthew (Nokia - GB)" 

Date: Wednesday, November 27, 2019 at 1:37 PM
To: "bess@ietf.org" 
Cc: "bess-cha...@ietf.org" 
Subject: [bess] WG Adoption and IPR Poll for 
draft-litkowski-bess-rfc5549revision-00

Hello,

This email begins a two-weeks WG adoption poll for 
draft-litkowski-bess-rfc5549revision-00 [1] .

Please review the draft and post any comments to the BESS working group list.

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, copying the BESS mailing list. The document won't progress 
without answers from all the authors and contributors.

Currently, there are no IPR disclosures 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.

This poll for adoption closes on Wednesday 11th December 2019.

Regards,
Matthew

[1] https://datatracker.ietf.org/doc/draft-litkowski-bess-rfc5549revision/



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

Re: [bess] WG Adoption and IPR Poll for draft-litkowski-bess-rfc5549revision-00

[slitkows.ietf]

Hi Sasha,

 

The changes to RFC5549 are:

*   Changing the NH encoding for AFI/SAFI 1/128
*   Enable the behavior for AFI/SAFI 1/129 (same as AFI/SAFI 1/128)

 

The fact of doing it in BESS has been agreed by the ADs (INT and RTG) as we 
only changes the VPN SAFIs.

 

Martin, our AD, is looking at the right way to proceed and will confirm, but 
this may not be a real bis that obsoletes RFC5549 (that’s why the draft is 
named revision and not bis). One of the opened possibility is to make RFC5549 
historic and not obsolete.

 

Brgds,


Stephane

 

 

From: Alexander Vainshtein  
Sent: mercredi 27 novembre 2019 15:39
To: Bocci, Matthew (Nokia - GB) 
Cc: bess-cha...@ietf.org; bess@ietf.org
Subject: RE: [bess] WG Adoption and IPR Poll for 
draft-litkowski-bess-rfc5549revision-00

 

Matthew and all,

I have a couple of questions about the draft in question that, if answered, 
would help me to define my position with regard to its adoption:

1.  The draft is a “bis” draft but it does not contain a section that lists 
the changes vs. RFC 5549 (customary in the “bis” drafts). Am I right to guess 
that the changes introduced by this draft deal exclusively with just the routes 
used with mVPN?
2.  If the answer to the question above is positive, I would agree that 
BESS (that handles mVPN among other things) is the right home for this document 
(SOFTWIRES WG that has delivered RFC 5549 has concluded). Otherwise, I would 
like to understand why adoption by BESS (and not, say, by the IDR WG) is 
considered?

 

Regards, and lots of thanks in advance,

Sasha

 

Office: +972-39266302

Cell:  +972-549266302

Email:   alexander.vainsht...@ecitele.com 
<mailto:alexander.vainsht...@ecitele.com> 

 

From: BESS mailto:bess-boun...@ietf.org> > On Behalf Of 
Bocci, Matthew (Nokia - GB)
Sent: Wednesday, November 27, 2019 2:37 PM
To: bess@ietf.org <mailto:bess@ietf.org> 
Cc: bess-cha...@ietf.org <mailto:bess-cha...@ietf.org> 
Subject: [bess] WG Adoption and IPR Poll for 
draft-litkowski-bess-rfc5549revision-00

 

Hello,

 

This email begins a two-weeks WG adoption poll for 
draft-litkowski-bess-rfc5549revision-00 [1] .

 

Please review the draft and post any comments to the BESS working group list.

 

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, copying the BESS mailing list. The document won't progress 
without answers from all the authors and contributors.

 

Currently, there are no IPR disclosures 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.

 

This poll for adoption closes on Wednesday 11th December 2019.  

 

Regards,

Matthew 

 

[1] https://datatracker.ietf.org/doc/draft-litkowski-bess-rfc5549revision/ 
<https://clicktime.symantec.com/375yKLee6q3yvdfTRuJxJrm6H2?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-litkowski-bess-rfc5549revision%2F>
 

 

 

 


___

This e-mail message is intended for the recipient only and contains information 
which is 
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received 
this 
transmission in error, please inform us by e-mail, phone or fax, and then 
delete the original 
and all copies thereof.
___

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

Re: [bess] WG Adoption and IPR Poll for draft-litkowski-bess-rfc5549revision-00

[Alexander Vainshtein]

Matthew and all,
I have a couple of questions about the draft in question that, if answered, 
would help me to define my position with regard to its adoption:

1.   The draft is a “bis” draft but it does not contain a section that 
lists the changes vs. RFC 5549 (customary in the “bis” drafts). Am I right to 
guess that the changes introduced by this draft deal exclusively with just the 
routes used with mVPN?

2.   If the answer to the question above is positive, I would agree that 
BESS (that handles mVPN among other things) is the right home for this document 
(SOFTWIRES WG that has delivered RFC 5549 has concluded). Otherwise, I would 
like to understand why adoption by BESS (and not, say, by the IDR WG) is 
considered?

Regards, and lots of thanks in advance,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   alexander.vainsht...@ecitele.com

From: BESS  On Behalf Of Bocci, Matthew (Nokia - GB)
Sent: Wednesday, November 27, 2019 2:37 PM
To: bess@ietf.org
Cc: bess-cha...@ietf.org
Subject: [bess] WG Adoption and IPR Poll for 
draft-litkowski-bess-rfc5549revision-00

Hello,

This email begins a two-weeks WG adoption poll for 
draft-litkowski-bess-rfc5549revision-00 [1] .

Please review the draft and post any comments to the BESS working group list.

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, copying the BESS mailing list. The document won't progress 
without answers from all the authors and contributors.

Currently, there are no IPR disclosures 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.

This poll for adoption closes on Wednesday 11th December 2019.

Regards,
Matthew

[1] 
https://datatracker.ietf.org/doc/draft-litkowski-bess-rfc5549revision/




___

This e-mail message is intended for the recipient only and contains information 
which is 
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received 
this 
transmission in error, please inform us by e-mail, phone or fax, and then 
delete the original 
and all copies thereof.
___
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG Adoption and IPR Poll for draft-litkowski-bess-rfc5549revision-00

[Krishna Muddenahally Ananthamurthy (kriswamy)]

Support. I am not aware of any IPR.

Thanks
Krishna

From: BESS  on behalf of "Bocci, Matthew (Nokia - GB)" 

Date: Wednesday, November 27, 2019 at 4:37 AM
To: "bess@ietf.org" 
Cc: "bess-cha...@ietf.org" 
Subject: [bess] WG Adoption and IPR Poll for 
draft-litkowski-bess-rfc5549revision-00

Hello,

This email begins a two-weeks WG adoption poll for 
draft-litkowski-bess-rfc5549revision-00 [1] .

Please review the draft and post any comments to the BESS working group list.

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, copying the BESS mailing list. The document won't progress 
without answers from all the authors and contributors.

Currently, there are no IPR disclosures 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.

This poll for adoption closes on Wednesday 11th December 2019.

Regards,
Matthew

[1] https://datatracker.ietf.org/doc/draft-litkowski-bess-rfc5549revision/



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

Re: [bess] WG Adoption and IPR Poll for draft-litkowski-bess-rfc5549revision-00

[Rabadan, Jorge (Nokia - US/Mountain View)]

Support.

Thx
Jorge

From: BESS  on behalf of "Bocci, Matthew (Nokia - GB)" 

Date: Wednesday, November 27, 2019 at 1:37 PM
To: "bess@ietf.org" 
Cc: "bess-cha...@ietf.org" 
Subject: [bess] WG Adoption and IPR Poll for 
draft-litkowski-bess-rfc5549revision-00

Hello,

This email begins a two-weeks WG adoption poll for 
draft-litkowski-bess-rfc5549revision-00 [1] .

Please review the draft and post any comments to the BESS working group list.

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, copying the BESS mailing list. The document won't progress 
without answers from all the authors and contributors.

Currently, there are no IPR disclosures 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.

This poll for adoption closes on Wednesday 11th December 2019.

Regards,
Matthew

[1] https://datatracker.ietf.org/doc/draft-litkowski-bess-rfc5549revision/



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

Re: [bess] WG Adoption and IPR Poll for draft-litkowski-bess-rfc5549revision-00

[Serge Krier (sekrier)]

Support adoption of this draft.

Regards,
Serge.

From: BESS  on behalf of "Bocci, Matthew (Nokia - GB)" 

Date: Wednesday, 27 November 2019 at 13:37
To: "bess@ietf.org" 
Cc: "bess-cha...@ietf.org" 
Subject: [bess] WG Adoption and IPR Poll for 
draft-litkowski-bess-rfc5549revision-00

Hello,

This email begins a two-weeks WG adoption poll for 
draft-litkowski-bess-rfc5549revision-00 [1] .

Please review the draft and post any comments to the BESS working group list.

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, copying the BESS mailing list. The document won't progress 
without answers from all the authors and contributors.

Currently, there are no IPR disclosures 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.

This poll for adoption closes on Wednesday 11th December 2019.

Regards,
Matthew

[1] https://datatracker.ietf.org/doc/draft-litkowski-bess-rfc5549revision/



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

Re: [bess] WG Adoption and IPR Poll for draft-litkowski-bess-rfc5549revision-00

[Zhuangshunwan]

Support adoption of this draft.  This draft reflects current multiple existing 
running implementations.

Thanks,
Shunwan



From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Bocci, Matthew (Nokia - 
GB)
Sent: Wednesday, November 27, 2019 8:37 PM
To: bess@ietf.org
Cc: bess-cha...@ietf.org
Subject: [bess] WG Adoption and IPR Poll for 
draft-litkowski-bess-rfc5549revision-00

Hello,

This email begins a two-weeks WG adoption poll for 
draft-litkowski-bess-rfc5549revision-00 [1] .

Please review the draft and post any comments to the BESS working group list.

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, copying the BESS mailing list. The document won't progress 
without answers from all the authors and contributors.

Currently, there are no IPR disclosures 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.

This poll for adoption closes on Wednesday 11th December 2019.

Regards,
Matthew

[1] https://datatracker.ietf.org/doc/draft-litkowski-bess-rfc5549revision/



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

Re: [bess] WG Adoption and IPR Poll for draft-litkowski-bess-rfc5549revision-00

[Ketan Talaulikar (ketant)]

Support adoption of this document.

Thanks,
Ketan

From: BESS  On Behalf Of Bocci, Matthew (Nokia - GB)
Sent: 27 November 2019 18:07
To: bess@ietf.org
Cc: bess-cha...@ietf.org
Subject: [bess] WG Adoption and IPR Poll for 
draft-litkowski-bess-rfc5549revision-00

Hello,

This email begins a two-weeks WG adoption poll for 
draft-litkowski-bess-rfc5549revision-00 [1] .

Please review the draft and post any comments to the BESS working group list.

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, copying the BESS mailing list. The document won't progress 
without answers from all the authors and contributors.

Currently, there are no IPR disclosures 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.

This poll for adoption closes on Wednesday 11th December 2019.

Regards,
Matthew

[1] https://datatracker.ietf.org/doc/draft-litkowski-bess-rfc5549revision/



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

Re: [bess] WG Adoption and IPR Poll for draft-litkowski-bess-rfc5549revision-00

[slitkows.ietf]

Support,

I’m not aware of any IPR.

 

From: BESS mailto:bess-boun...@ietf.org> > on behalf of 
"Bocci, Matthew (Nokia - GB)" mailto:matthew.bo...@nokia.com> >
Date: Wednesday, November 27, 2019 at 7:37 AM
To: "bess@ietf.org  " mailto:bess@ietf.org> >
Cc: "bess-cha...@ietf.org  " mailto:bess-cha...@ietf.org> >
Subject: [bess] WG Adoption and IPR Poll for 
draft-litkowski-bess-rfc5549revision-00

 

Hello,

 

This email begins a two-weeks WG adoption poll for 
draft-litkowski-bess-rfc5549revision-00 [1] .

 

Please review the draft and post any comments to the BESS working group list.

 

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, copying the BESS mailing list. The document won't progress 
without answers from all the authors and contributors.

 

Currently, there are no IPR disclosures 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.

 

This poll for adoption closes on Wednesday 11th December 2019.  

 

Regards,

Matthew 

 

[1] https://datatracker.ietf.org/doc/draft-litkowski-bess-rfc5549revision/

 

 

 

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

Re: [bess] WG Adoption and IPR Poll for draft-litkowski-bess-rfc5549revision-00

[Acee Lindem (acee)]

I support WG adoption. This is update is desperately needed to reflect current 
implementations and deployments.
Thanks,
Acee

From: BESS  on behalf of "Bocci, Matthew (Nokia - GB)" 

Date: Wednesday, November 27, 2019 at 7:37 AM
To: "bess@ietf.org" 
Cc: "bess-cha...@ietf.org" 
Subject: [bess] WG Adoption and IPR Poll for 
draft-litkowski-bess-rfc5549revision-00

Hello,

This email begins a two-weeks WG adoption poll for 
draft-litkowski-bess-rfc5549revision-00 [1] .

Please review the draft and post any comments to the BESS working group list.

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, copying the BESS mailing list. The document won't progress 
without answers from all the authors and contributors.

Currently, there are no IPR disclosures 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.

This poll for adoption closes on Wednesday 11th December 2019.

Regards,
Matthew

[1] https://datatracker.ietf.org/doc/draft-litkowski-bess-rfc5549revision/



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