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

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

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 <yakov@juniper.net> 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
>> Idr@ietf.org
>> https://www1.ietf.org/mailman/listinfo/idr
> 
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www1.ietf.org/mailman/listinfo/idr
> 

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www1.ietf.org/mailman/listinfo/idr