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 <softwires-boun...@ietf.org> on behalf of Robert Raszuk <rras...@gmail.com> Date: Thursday, 27. June 2019 at 13:53 To: Zhuangshunwan <zhuangshun...@huawei.com> Cc: "i...@ietf.org" <i...@ietf.org>, Alexander Okonnikov <alexander.okonni...@gmail.com>, "softwires@ietf.org" <softwires@ietf.org>, "Vigoureux, Martin (Nokia - FR/Paris-Saclay)" <martin.vigour...@nokia.com>, "b...@ietf.org" <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 <zhuangshun...@huawei.com<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 <xiejingr...@huawei.com<mailto:xiejingr...@huawei.com>>; Alexander Okonnikov <alexander.okonni...@gmail.com<mailto:alexander.okonni...@gmail.com>>; Robert Raszuk <rob...@raszuk.net<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. > > <draft-dawra-bess-srv6-services-00> 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 <draft-dawra-bess-srv6-services-00> 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 <rob...@raszuk.net<mailto:rob...@raszuk.net>> > *Cc:* UTTARO, JAMES <ju1...@att.com<mailto:ju1...@att.com>>; Xiejingrong > <xiejingr...@huawei.com<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 Core in RFC5549 > > Hi Robert, > > Sorry, I was not so precise :-) Of course, RD part in Next Hop is not > copied from RD of NLRI, but zeroed. I was trying to explain why Next > Hop field in RFC 4364 and RFC 4659 has format RD:IP (VPNvX address) > rather than just IP. > > Thank you! > > > > > > _______________________________________________ > Idr mailing list > i...@ietf.org<mailto:i...@ietf.org> > https://www.ietf.org/mailman/listinfo/idr > _______________________________________________ Softwires mailing list Softwires@ietf.org<mailto:Softwires@ietf.org> https://www.ietf.org/mailman/listinfo/softwires _______________________________________________ BESS mailing list b...@ietf.org<mailto:b...@ietf.org> https://www.ietf.org/mailman/listinfo/bess
_______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
