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

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

[bess] I-D Action: draft-ietf-bess-mvpn-yang-02.txt

[internet-drafts]

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

Title   : Yang Data Model for Multicast in MPLS/BGP IP VPNs
Authors : Yisong Liu
  Feng Guo
  Stephane Litkowski
  Xufeng Liu
  Robert Kebler
  Mahesh Sivakumar
Filename: draft-ietf-bess-mvpn-yang-02.txt
Pages   : 39
Date: 2019-12-02

Abstract:
   This document defines a YANG data model that can be used to
   configure and manage multicast in MPLS/BGP IP VPNs.


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

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

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


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

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

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