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

From: "Bocci, Matthew (Nokia - GB)" <[email-masked]>
Date: Wed, 27 Nov 2019 12:36:47 +0000

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/

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 27 Nov 2019 12:39:10 +0000

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

From: BESS <[email-masked]> on behalf of "Bocci, Matthew (Nokia - GB)" <[email-masked]>
Date: Wednesday, November 27, 2019 at 7:37 AM
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: [bess] WG Adoption and IPR Poll for draft-litkowski-bess-rfc5549revision-00

Hello,

Regards,
Matthew

---

From: <[email-masked]>
Date: Wed, 27 Nov 2019 13:48:58 +0100

Support,

I’m not aware of any IPR.

From: BESS <[email-masked] <mailto:[email-masked]> > on behalf of "Bocci, Matthew (Nokia - GB)" <[email-masked] <mailto:[email-masked]> >
Date: Wednesday, November 27, 2019 at 7:37 AM
To: "[email-masked] <mailto:[email-masked]> " <[email-masked] <mailto:[email-masked]> >
Cc: "[email-masked] <mailto:[email-masked]> " <[email-masked] <mailto:[email-masked]> >
Subject: [bess] WG Adoption and IPR Poll for draft-litkowski-bess-rfc5549revision-00

Hello,

Regards,

Matthew

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Wed, 27 Nov 2019 12:55:07 +0000

Support adoption of this document.

Thanks,
Ketan

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

Hello,

Regards,
Matthew

---

From: Zhuangshunwan <[email-masked]>
Date: Wed, 27 Nov 2019 13:12:18 +0000

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

Thanks,
Shunwan

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

Hello,

Regards,
Matthew

---

From: "Serge Krier (sekrier)" <[email-masked]>
Date: Wed, 27 Nov 2019 13:30:45 +0000

Support adoption of this draft.

Regards,
Serge.

Date: Wednesday, 27 November 2019 at 13:37

Hello,

Regards,
Matthew

---

From: "Rabadan, Jorge (Nokia - US/Mountain View)" <[email-masked]>
Date: Wed, 27 Nov 2019 13:49:21 +0000

Support.

Thx
Jorge

Date: Wednesday, November 27, 2019 at 1:37 PM

Hello,

Regards,
Matthew

---

From: "Krishna Muddenahally Ananthamurthy (kriswamy)" <[email-masked]>
Date: Wed, 27 Nov 2019 14:22:42 +0000

Support. I am not aware of any IPR.

Thanks
Krishna

Date: Wednesday, November 27, 2019 at 4:37 AM

Hello,

Regards,
Matthew

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 27 Nov 2019 14:38:31 +0000

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:   [email-masked]

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

Hello,

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.
___________________________________________________________________________

---

From: <[email-masked]>
Date: Wed, 27 Nov 2019 15:56:01 +0100

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 <[email-masked]> 
Sent: mercredi 27 novembre 2019 15:39
To: Bocci, Matthew (Nokia - GB) <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: RE: [bess] WG Adoption and IPR Poll for draft-litkowski-bess-rfc5549revision-00

Matthew and all,

Sasha

Office: +972-39266302

Cell:      +972-549266302

Email:   [email-masked] <mailto:[email-masked]> 

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

Hello,

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>

---

From: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Date: Wed, 27 Nov 2019 16:50:22 +0000

support

From: BESS <[email-masked]> on behalf of Jorge Rabadan <[email-masked]>
Date: Wednesday, 27 November 2019 at 14:49
To: "Bocci, Matthew (Nokia - GB)" <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [bess] WG Adoption and IPR Poll for draft-litkowski-bess-rfc5549revision-00

Support.

Thx
Jorge

Hello,

Regards,
Matthew

---

From: "Kesavan Thiruvenkatasamy (kethiruv)" <[email-masked]>
Date: Wed, 27 Nov 2019 16:54:16 +0000

Support.

Regards,
Kesavan

Hello,

Regards,
Matthew

---

From: Jeff Tantsura <[email-masked]>
Date: Wed, 27 Nov 2019 09:42:11 -0800

Support the adoption, thanks for doing this work!

Regards,
Jeff

> On Nov 27, 2019, at 04:37, Bocci, Matthew (Nokia - GB) <[email-masked]> wrote:
> 
> 
> Hello,
>  
> _______________________________________________
> BESS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bess

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 27 Nov 2019 18:01:22 +0000

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: [email-masked] <[email-masked]>
Sent: Wednesday, November 27, 2019, 16:56
To: Alexander Vainshtein; 'Bocci, Matthew (Nokia - GB)'
Cc: [email-masked]; [email-masked]
Subject: RE: [bess] WG Adoption and IPR Poll for draft-litkowski-bess-rfc5549revision-00

Hi Sasha,

Brgds,

Stephane

Matthew and all,

Office: +972-39266302
Cell:      +972-549266302
Email:   [email-masked]<mailto:[email-masked]>

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

Hello,

Regards,
Matthew

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Wed, 27 Nov 2019 20:25:30 +0000

Support

Thanks,
              Jim Uttaro

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

Support.

Thx
Jorge

From: BESS <[email-masked]<mailto:[email-masked]>> on behalf of "Bocci, Matthew (Nokia - GB)" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, November 27, 2019 at 1:37 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [bess] WG Adoption and IPR Poll for draft-litkowski-bess-rfc5549revision-00

Hello,

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

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 27 Nov 2019 22:18:07 +0100

*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) <
[email-masked]> wrote:

> Hello,
>
>
>
> This email begins a two-weeks WG adoption poll for
> draft-litkowski-bess-rfc5549revision-00 [1] .
>
>
>
> 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.
>
>
>
> 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.
>
>
>

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Thu, 28 Nov 2019 08:57:40 +0000

Hi,

I support the adoption of this document.

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

Hello,

Regards,
Matthew

---

From: Lizhenbin <[email-masked]>
Date: Thu, 28 Nov 2019 12:07:25 +0000

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)

Hello,

Regards,
Matthew

---

From: <[email-masked]>
Date: Thu, 28 Nov 2019 17:40:21 +0100

Hi Robert,

Please see some replies inline.

Brgds,

From: Robert Raszuk <[email-masked]> 
Sent: mercredi 27 novembre 2019 22:18
To: Bocci, Matthew (Nokia - GB) <[email-masked]>
Cc: [email-masked]; [email-masked]
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:   

Proposed text:

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) <[email-masked] <mailto:[email-masked]> > wrote:

Hello,

Regards,

Matthew 

 

_______________________________________________
BESS mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/bess

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 28 Nov 2019 17:56:53 +0100

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 <[email-masked]> wrote:

> *From:* Robert Raszuk <[email-masked]>
> *Sent:* mercredi 27 novembre 2019 22:18
> *To:* Bocci, Matthew (Nokia - GB) <[email-masked]>
> *Cc:* [email-masked]; [email-masked]
> *Subject:* Re: [bess] WG Adoption and IPR Poll for
> draft-litkowski-bess-rfc5549revision-00
>
>
>
> 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.
>
>
>
> [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] 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 -
>
>
>
> [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.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>

---

From: Neeraj Malhotra <[email-masked]>
Date: Thu, 28 Nov 2019 12:08:53 -0800

Hi,

Support adoption.

Thanks,
Neeraj

> On Nov 27, 2019, at 4:36 AM, Bocci, Matthew (Nokia - GB) <[email-masked]> wrote:
> 
> Hello,
>

---

From: <[email-masked]>
Date: Fri, 29 Nov 2019 10:26:45 +0800 (CST)

Support the adoption. This document does make sense.

Thanks,

Sandy

原始邮件

发件人：Bocci,Matthew(Nokia-GB) <[email-masked]>
收件人：[email-masked] <[email-masked]>;
抄送人：[email-masked] <[email-masked]>;
日 期 ：2019年11月27日 20:37
主 题 ：[bess] WG Adoption and IPR Poll fordraft-litkowski-bess-rfc5549revision-00

Hello,

 

 

 

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.

 

 

 

Regards,

Matthew

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Fri, 29 Nov 2019 02:59:49 +0000

I support adoption.

Regards,
Jakob.

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

Hello,

Regards,
Matthew

---

From: <[email-masked]>
Date: Fri, 29 Nov 2019 12:29:28 +0100

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 <[email-masked]> 
Sent: jeudi 28 novembre 2019 17:57
To: [email-masked]
Cc: Bocci, Matthew (Nokia - GB) <[email-masked]>; [email-masked]; [email-masked]
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 <[email-masked] <mailto:[email-masked]> > wrote:

Hi Robert,

Brgds,

From: Robert Raszuk <[email-masked] <mailto:[email-masked]> > 
Sent: mercredi 27 novembre 2019 22:18
To: Bocci, Matthew (Nokia - GB) <[email-masked] <mailto:[email-masked]> >
Cc: [email-masked] <mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]> 
Subject: Re: [bess] WG Adoption and IPR Poll for draft-litkowski-bess-rfc5549revision-00

[SLI]

Point 1 - 

Original RFC sec. 6.2:   

Proposed text:

RD is set to zero

	

 

 

Point 2 - 

Conclusion: 

 

Cheers,

Robert.

 

 

Hello,

Regards,

Matthew