Re: [Idr] Advertising Multiple Next Hop Routes in BGP

[Yakov Rekhter <[e-mail]>]

Robert,

> Hi Yakov,
> 
> > You could use a different <AFI, SAFI>. But you can also use the
> > same <AFI, SAFI>, and distinguish between IPv6 and IPv4 PE by using
> > the nexthop length.
> 
> One could also observe that what you indicated is exactly the approach
> we took when defining new AFI/SAFI NLRI & NH for RT-Constrain.
> 
> http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-rt-constrain-02.txt

You are absolutely correct. Thanks for pointing this out.

Yakov.

> 
> Cheers,
> R.
> 
> 
> 
> > Glen,
> > 
> >> Yakov,
> >>
> >> Certainly one can do this by creating new AFI and SAFI types.
> >>
> >> But then that tuple <AFI, SAFI> can only be used for that particular
> >> nexthop and NLRI set. So each time we require a new permutation we
> >> need to request IANA for getting more code points.
> > 
> > Using a distinct <AFI, SAFI> for a particular nexthop and NLRI set
> > is one possible way, but *not* the only one possible (more on this
> > below).
> >   
> >> Taking your own example, if the PE uses IPv6 then i would need a
> >> different AFI, SAFI to convey the information.
> > 
> > You could use a different <AFI, SAFI>. But you can also use the
> > same <AFI, SAFI>, and distinguish between IPv6 and IPv4 PE by using
> > the nexthop length.
> > 
> > Yakov.
> > 
> >> But Yes, it will work with the existing mechanisms.
> >>
> >> Affably,
> >> Glen
> >>
> >> On 8/15/06, Yakov Rekhter <[e-mail]> wrote:
> >>> Glen,
> >>>
> >>> [clipped...]
> >>>
> >>>> All right, this would work. Thanks for the explanation.
> >>>>
> >>>> Looking at this in another light leads me to think that its now kinda
> >>>> possible to disassociate the AFI-SAFI (or simply the network layer
> >>>> protocol) of the next-hop with that of the NLRI in a more elegant and
> >>>> a scalable way.
> >>>>
> >>>> I have in the past expressed my displeasure at how we pad NULL RDs in
> >>>> 2547 when filling the next-hop information in the mp-reach-nlri path
> >>>> attribute. To me mp-reach-nlri/2547 is a big kludge and i dont see a
> >>>> reason why we need to restrict the network layer address family of the
> >>>> next-hop to be the same as that of the NLRI.
> >>> draft-ietf-idr-rfc2858bis-10.txt does *not* restrict the network
> >>> layer address family of the next hop to be the same as that of the NLRI.
> >>> Quoting from the spec (draft-ietf-idr-rfc2858bis-10.txt):
> >>>
> >>>  Address Family Identifier:
> >>>
> >>>     This field in combination with the Subsequent Address Family
> >>>     Identifier field identifies the Network Layer protocol associated
> >>>     with the Network Address of Next Hop and the semantics of
> >>>     the Network Layer Reachability Information that follows.
> >>>
> >>> In other words, the same (afi, safi) tuple defines two things: (1)
> >>> the network layer protocol associated with the Network Address of
> >>> Next Hop, and (2) the encoding/semantics of NLRI.
> >>>
> >>> Nowhere in the spec there is a requirement that the encoding/semantics
> >>> of Next Hop be the same as NLRI. For example let's look at
> >>> VPLS auto-discovery with BGP (draft-ietf-l2vpn-signaling-08.txt).
> >>> Quoting from the spec:
> >>>
> >>>   In summary, the BGP advertisement for a particular VSI at a given PE
> >>>   will contain:
> >>>
> >>>   o  an NLRI of AFI = L2VPN, SAFI = TBA, encoded as RD:PE_addr
> >>>
> >>>   o  a BGP next hop equal to the loopback address of the PE
> >>>
> >>> Here you have AFI = L2VPN, yet the next hop contains a plain IPv4
> >>> address.
> >>>
> >>> So, clearly for a given (afi,safi) one could place a plain IPv4
> >>> address in the Next Hop, yet carry some non IPv4 NLRI, and use AFI
> >>> that is not the IPv4 AFI.
> >>>
> >>> Yakov.
> >>>
> >> _______________________________________________
> >> Idr mailing list
> >> [e-mail]
> >> https://www1.ietf.org/mailman/listinfo/idr
> > 
> > _______________________________________________
> > Idr mailing list
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/idr
> > 

_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr