Hi,
(co-chair hat off)
I also vote to reject this erratum on the following grounds: The erratum text
was raised as:
Section 6.2 says:
Length of Next Hop Network Address = 16 (or 32)
It should say:
Length of Next Hop Network Address = 24 (or 48)
Notes:
The lengths should include the RD length also, right ?
However, RFC5549 specifies in several places that the next-hop address is of
type IPv6 address (Sections 3, 4, 6.1 and 6.2). The use of an IPv6 address as
the next hop was clearly the intention of the author and the document was
reviewed and published as such. The existing text in section 6.2 (Length of
Next Hop Network Address = 16 (or 32)) is consistent with this and changing it
as proposed in the would only introduce an inconsistency.
Thanks,
Ian
From: Softwires on behalf of Robert Raszuk
Date: Thursday, 27. June 2019 at 13:53
To: Zhuangshunwan
Cc: "i...@ietf.org" , Alexander Okonnikov
, "softwires@ietf.org" ,
"Vigoureux, Martin (Nokia - FR/Paris-Saclay)" ,
"b...@ietf.org"
Subject: Re: [Softwires] [bess] [Idr] Regarding the Next Hop Network Address
coding for IPv4 VPN over IPv6 Core in RFC5549
My vote - Reject.
Justification:
Irrespective if we would reject or accept the erratum implementations must be
able to handle 10 years old RFC so must be able to properly recognize the next
hop to be either of length 16 or 24. (I am putting aside the 32/48 invention)..
So that means that next hop length should be used to recognize format of the
next hop. That with the fact that stuffing next hop address with useless 64
zeros in the front leads me to believe that if we are to produce any erratums
it should be the other way around ... we should replace all documents which
call for having next hops full of zeros in the front to normalize it to consist
of just real IPv4 or IPv6 single address.
Thx,
R.
On Thu, Jun 27, 2019 at 1:39 PM Zhuangshunwan
mailto:zhuangshun...@huawei.com>> wrote:
Hi all,
Can the WG reach a conclusion on how to treat that erratum related to RFC5549:
https://www.rfc-editor.org/errata/eid5253
Thanks,
Shunwan
-Original Message-
From: Softwires
[mailto:softwires-boun...@ietf.org<mailto:softwires-boun...@ietf.org>] On
Behalf Of Vigoureux, Martin (Nokia - FR/Paris-Saclay)
Sent: Thursday, June 27, 2019 6:37 PM
To: Xiejingrong mailto:xiejingr...@huawei.com>>;
Alexander Okonnikov
mailto:alexander.okonni...@gmail.com>>; Robert
Raszuk mailto:rob...@raszuk.net>>;
b...@ietf.org<mailto:b...@ietf.org>
Cc: softwires@ietf.org<mailto:softwires@ietf.org>;
i...@ietf.org<mailto:i...@ietf.org>
Subject: Re: [Softwires] [Idr] [bess] Regarding the Next Hop Network Address
coding for IPv4 VPN over IPv6 Core in RFC5549
since we are discussing that topic,
maybe the WG would like to reach a conclusion on how to treat that erratum:
http://www.rfc-editor.org/errata/eid5738
Thanks
-m
Le 2019-06-27 à 11:15, Xiejingrong a écrit :
> Thanks for the RFC historical lessons.
>
> --there was historically some assumption that next hop must be of the
> same AF as prefix.
>
> --RFC 2858 says that Next Hop field should match AFI. On the other
> hand, RFC 4760 says that Next Hop Field should match combination of AFI/SAFI.
>
> --authors of RFC 4364 were trying to make it consistent with 4760.
>
> --Also, drafts of RFC 4364 and RFC 4760 were being developed
> practically at the same time period.
>
> The problem is clear, the nexthop field has been inconsistent between
> different L3VPN/MVPN scenarios and different implementations in the
> long history.
>
> is the latest draft, but it has
> different nexthop in section 3.1 to 3.4, in the year 2019.
>
> Back to my suggestion: implementation should interpret nexthop RD+IPv4
> and nexthop IPv4 the same, and interpret nexthop RD+IPv6 and nexthop
> IPv6 the same.
>
> I think it may be helpful for to
> add the above text, and update RFC4364/4659/4760/5549, to eliminate
> the worries about interoperation. is there any worries about
> interoperation ?
>
> Thanks
>
> Jingrong
>
> *From:*Alexander Okonnikov
> [mailto:alexander.okonni...@gmail.com<mailto:alexander.okonni...@gmail.com>]
> *Sent:* Wednesday, June 26, 2019 9:38 PM
> *To:* Robert Raszuk mailto:rob...@raszuk.net>>
> *Cc:* UTTARO, JAMES mailto:ju1...@att.com>>; Xiejingrong
> mailto:xiejingr...@huawei.com>>;
> softwires@ietf.org<mailto:softwires@ietf.org>;
> i...@ietf.org<mailto:i...@ietf.org>;
> ian.far...@telekom.de<mailto:ian.far...@telekom.de>;
> b...@ietf.org<mailto:b...@ietf.org>;
> ianfar...@gmx.com<mailto:ianfar...@gmx.com>
> *Subject:* Re: [Idr] [bess] [Softwires] Regarding the Next Hop Network
> Address coding for IPv4 VPN over IPv6 Co
