Re: [Idr] Fw: Re: New Version Notification for draft-xie-idr-mpbgp-extention-4map6-00.txt

[Robert Raszuk <[e-mail]>]

Hi Jeff,

If edge nodes do not carry IPv4 routes don't we have number of solutions
already as well like pseudowires or EPE which could provide a pipe model
through the transit network not doing any lookup ?

Let's note that that not doing IPv4 lookup on the ingress/egress here is
very deployment limiting too especially if number of sites you are
interconnecting grows.

Kind regards,
R.




On Mon, Nov 6, 2023 at 10:31 AM Jeffrey Haas <[e-mail]> wrote:

> [Note - very old thread]
>
> Robert,
>
> As part of IDR chairs' discussion on draft-xie-idr-mpbgp-extension-4map6, I
> was reviewing prior emails on the draft.  Since the points you raised are
> likely to be raised during adoption discussions of the draft, I wanted to
> add some comments.
>
> I have retained the full message for appropriate context.
>
> On Sat, Jan 28, 2023 at 03:23:10PM +0100, Robert Raszuk wrote:
> > The crux is that to realize connectivity of IPv4 sites over only IPv6
> core
> > (or set of domains) all you need to get is the remote encapsulation
> > information carried in Tunnel Attribute. That should be already supported
> > and shipping by multiple implementations.
> >
> > Then to meet BGP requirements you need a valid next hop hence you need to
> > use extensions described in RFC5549 to add it to SAFI 1/1. RFC8950 is not
> > actually playing any role here as it clearly says that it augments only
> the
> > scenario for SAFI 128/129 respectively.
> >
> > So the fundamental point is that you do not need to create and carry
> > IPv4mappedIPv6 address at all. It is not needed for network elements as
> > their FIBs will still only use vanilla IPv6 and IPv4 addresses
> separately.
> > Even if you extend protocol and carry IPv4 mapped IPv6 address the
> ingress
> > FIB from IPv4 site will still do the dst lookup on IPv4 address.
>
> I think the primary operational difference with using RFC 5549
> methodologies
> is that you are still concerned with where the IPv4 unicast routes need to
> be distributed.
>
> For the example topology in the draft-xie draft, intermediate routers or
> BGP
> autonomous systems are not necessarily carrying IPv4 unicast routes.  They
> may be IPv6-only.
>
> If the desire is to use RFC 5549 in such a case, carrying the IPv4 routing
> would likely need to be distributed using multihop eBGP.  However, such
> sessions would have to be built-up between ASes on a pair-wise basis rather
> than simply using standard BGP peering relationships.  This is the usual
> problem of any meshed tunnel mechanism.
>
> So, I think the comparison of "RFC 5549 solves this fine" is unfair.  That
> said, I think being able to carry the mapping database as proposed in this
> draft in a similar fashion in the tunnel encapsulation attribute might be a
> useful addition to a similar proposal.  I.e. "what's the same mapping that
> should be carried in the TEA?"
>
> A point made in another message in this old thread that is worth
> highlighting is that route scale potentially *is* impacted:
> Presume "x" number of ASes providing Internet-scale mapping using this
> mechanism.  This means for Internet route scale "n" that instead of having
> n
> specific IPv4 destinations in a common RIB undergoing common route
> selection, we have x * n distinct IPv6 destinations to carry the IPv4
> routing table.
>
> An operational point to discuss is the mapping database replaces BGP route
> selection for the IPv4 routing table with its own selection method.  How
> problematic this might be for loop purposes is unclear to me at this point
> of consideration.
>
> With the changes in recent versions of the document where the BGP
> properties
> of the tunneled IPv4 route carried in the attr-set, it is possible to
> locally create an ipv4 route and run normal bgp route selection.  However,
> that's not in the current proposal - but perhaps that's a good point of
> discussion.
>
> -- Jeff
>
> >
> > That lookup will result in IPv6 encapsulation with src and dst address
> > being locally computed (algorithm is well know as we already established
> > before).
> >
> > Then IPv6 packet will happily travel via single or many domains.
> >
> > On the egress side once you decapsulate again you do a lookup on plain
> IPv4
> > FIB to determine which site the packet should be forwarded to.
> >
> > So in no moment of the packet life through this single or multi domain
> > journey you need to have to propagate IPv4mappedIPv6 address anywhere.
> >
> > I hope this clarify the point I was making all along this little thread.
> >
> > Kind regards,
> > Robert
> >
> >
> >
> >
> >
> >
> >
> >
> > On Sat, Jan 28, 2023 at 1:07 PM Xiejingrong (Jingrong) <
> > [e-mail]> wrote:
> >
> > > Hi Robert,
> > >
> > >
> > >
> > > I think it is a valid option to use existing SAFI such as those
> > > (SAFI-1/128) described in RFC5549/8950.
> > >
> > >
> > >
> > > But I don’t understand this sentence “It does not even require any new
> > > software upgrade to existing routers if they
> > > already support RFC5549+RFC9012.”
> > >
> > >
> > >
> > > My understanding of the overall 4map6 solution is in my previous mail
> [*],
> > > and I think the main requirement for the BGP extension in the solution
> is
> > > an “IPv4/IPv6 Prefix” information in an TLV/Sub-TLV/Sub-sub-TLV of
> some BGP
> > > Attribute.
> > >
> > >
> > >
> > > [*]
> https://mailarchive.ietf.org/arch/msg/idr/fUMnsJpSwoU3Vz-3NrcUCQqggfY/
> > >
> > >
> > >
> > > But I failed to find a TLV or Sub-TLV that can carry an IPv4/IPv6
> Prefix
> > > after reading RFC9012 quickly.
> > >
> > >
> > >
> > > Can you please clarify on that ?
> > >
> > >
> > >
> > > Regards,
> > >
> > > Jingrong
> > >
> > >
> > >
> > >
> > >
> 本邮件及其附件可能含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
> > > This e-mail and its attachments may contain confidential information
> from
> > > HUAWEI, which is intended only for the person or entity whose address
> is
> > > listed above. Any use of the information contained herein in any way
> > > (including, but not limited to, total or partial disclosure,
> reproduction,
> > > or dissemination) by persons other than the intended recipient(s) is
> > > prohibited. If you receive this e-mail in error, please notify the
> sender
> > > by phone or email immediately and delete it!
> > >
> > >
> > >
> > > *From:* Idr [mailto:[e-mail]] *On Behalf Of *Robert Raszuk
> > > *Sent:* Saturday, January 28, 2023 6:55 PM
> > > *To:* Chongfeng Xie <[e-mail]>
> > > *Cc:* [e-mail]; idr <[e-mail]>; xing <
> [e-mail]>
> > > *Subject:* Re: [Idr] Fw: Re: New Version Notification for
> > > draft-xie-idr-mpbgp-extention-4map6-00.txt
> > >
> > >
> > >
> > > Chongfeng,
> > >
> > >
> > >
> > > 【*Chongfeng*】: I agree with you, introducing IPv4 routes into IPv6
> domain
> > > will increase the size of control plane, but I think this is normal,
> you
> > > have mentioned RFC5549/8950 several times, RFC5549/8950  also adopts
> new
> > > SAFI value
> > >
> > >
> > >
> > > I do not recall ever mentioning RFC8950, but it DOES NOT introduce new
> > > SAFI. Please read section 3 of either RFC5549 or RFC8950.
> > >
> > >
> > >
> > > I mentioned RFC5549 with RFC9012 which requires new capability not a
> > > new SAFI- that's all. It does not even require any new software
> upgrade to
> > > existing routers if they already support RFC5549+RFC9012.
> > >
> > >
> > >
> > > All that is needed is just a few lines of configuration - that's all.
> > >
> > >
> > >
> > > Regards,
> > >
> > > R.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > , and specifies the extensions necessary to allow the advertising of
> IPv4
> > > NLRI with a next-hop IPv6 address, herein 128-bits of next IPv6 address
> > > will be used for all IPv4 routes. My proposal is basically the same as
> > > RFC5549/8950 in terms of the scale, the difference is that my draft use
> > > IPv6 mapping prefix instead of specific next-hop IPv6 address.  In
> > > addition, my draft is about IPv6-only deployment for the network.
> IPv6-only
> > > will run after dual-stack as a whole. At that time, IPv6 will be the
> main
> > > stream, and the use of IPv4 will be less, and the overall quantity of
> IPv4
> > > routes may be reduced hopefully.
> > >
> > >
> > >
> > > Furthermore, the forwarding of IPv4 services in P routers will be
> based on IPv6 FIB, the size of which is
> > >
> > > In all cases forwarding in P routers will be based on IPv6 FIB so I do
> not
> > > understand why you are highlighting it here.
> > >
> > > *[Chongfeng]:  * You mentioned the cost issue before, and IPv6-only in
> > > multi-domain networks can reduce the cost of data forwarding, so I
> > > highlighted it.  BTW, What does "in all cases" here mean?
> > >
> > >
> > >
> > >
> > >
> > > Your statement sounded like what I am describing would not be forwarded
> > > based on IPv6 FIB so I commented on it.
> > >
> > > 【Chongfeng】：OK
> > >
> > >
> > >
> > > *[Chongfeng]: * In large-scale networks, it is not enough to achieve
> > > IPv4/IPv6 packet conversion only through local algorithmic computing.
> To
> > > convert an IPv4 address to an IPv6 address in PE, it needs to obtain
> the
> > > IPv6 address prefix of remote-end to identify the location of the IPv4
> > > address block in the IPv6 network in advance.
> > >
> > > In addition, I think the/96 prefix you mentioned is about the choice of
> > > prefix length, which can be considered in the future.
> > >
> > >
> > >
> > >
> > >
> > > I disagree. Irrespective of network scale you can algorithmically and
> > > consistently insert a bit string into a packet.
> > >
> > >
> > >
> > > And the algorithm we are talking about it well know so there is no
> issue
> > > what so ever.
> > >
> > > 【*Chongfeng*】： Can you tell me which RFC the algorithm is in?
> > > MAP-T/MAP-E?  or something else?
> > >
> > >
> > >
> > > I am not talking about some local domain mapping.
> > >
> > >
> > >
> > > Thx,
> > >
> > > R.
> > >
> > >
> > >
> > > Thanks!
> > >
> > > Chongfeng
> > >
> > >
>