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>>, "Bocci, Matthew 
(Nokia - GB)" mailto:matthew.bo...@nokia.com>>, 
"bess-cha...@ietf.org" 
mailto:bess-cha...@ietf.org>>, 
"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>>, "Bocci, Matthew 
(Nokia - GB)" mailto:matthew.bo...@nokia.com>>, 
"bess-cha...@ietf.org" 
mailto:bess-cha...@ietf.org>>, 
"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

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" , "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 de

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>>, "Bocci, Matthew 
(Nokia - GB)" mailto:matthew.bo...@nokia.com>>, 
"bess-cha...@ietf.org" 
mailto:bess-cha...@ietf.org>>, 
"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>>
Cc: "Bocci, Matthew (Nokia - GB)" 
mailto:matthew.bo...@nokia.com>>, 
"bess-cha...@ietf.org" 
mailto:bess-cha...@ietf.org>>, 
"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 rec

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 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 specif

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>>
Cc: "Bocci, Matthew (Nokia - GB)" 
mailto:matthew.bo...@nokia.com>>, 
"bess-cha...@ietf.org" 
mailto:bess-cha...@ietf.org>>, 
"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; 
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

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>>
Cc: "Bocci, Matthew (Nokia - GB)" 
mailto:matthew.bo...@nokia.com>>, 
"bess-cha...@ietf.org" 
mailto:bess-cha...@ietf.org>>, 
"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; 
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  Networ