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> 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] On Behalf Of > Vigoureux, Martin (Nokia - FR/Paris-Saclay) > Sent: Thursday, June 27, 2019 6:37 PM > To: Xiejingrong <xiejingr...@huawei.com>; Alexander Okonnikov < > alexander.okonni...@gmail.com>; Robert Raszuk <rob...@raszuk.net>; > bess@ietf.org > Cc: softwi...@ietf.org; 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] > > *Sent:* Wednesday, June 26, 2019 9:38 PM > > *To:* Robert Raszuk <rob...@raszuk.net> > > *Cc:* UTTARO, JAMES <ju1...@att.com>; Xiejingrong > > <xiejingr...@huawei.com>; softwi...@ietf.org; i...@ietf.org; > > ian.far...@telekom.de; bess@ietf.org; 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 > > https://www.ietf.org/mailman/listinfo/idr > > > _______________________________________________ > Softwires mailing list > softwi...@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess >
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
