Re: [Idr] Re: Last Call: 'Connecting IPv6 Islands over IPv4 MPLS using IPv6 Provider Edge Routers (6PE)' to Proposed Standard

Francois -

    I think a clear set of rules for defining NLRI and the relationship to
NH are required vs a bit of a tweak. The meta-problem is existing precedents
never converged on single way to determine the AF of the NH, given that it
is a different AF than the NLRI.

In San Diego, I'd like an opportunity to present the issue at IDR,
relationship to softwires scenarios, potential solution set and hopefully
agreement if one can be reached.

As far as 6PE draft goes, it has been around for _a long time_, widely
developed and deployed; I hope that it isn't delayed any further as the boat
left the port years ago.

-DWard

On 9/11/06 8:00 AM, "Francois Le Faucheur" <flefauch@cisco.com> wrote:

> Yakov, Dave, Eric and all,
> 
> 
> On 25 Aug 2006, at 22:17, Yakov Rekhter wrote:
> 
> 
>> Dave,
>> 
>> 
>>> Yakov, Bill -
>>> 
>>> Since we allow the route to an X-prefix to have a Y-address as its
>>> next hop,
>>> we still need an SOFTWIRE|IDR document to specify  how to do
>>> that.  For the
>>> cases where (a) X is  VPN-IPv4 and Y  is IPv4,  (b) X is  VPN-IPv6
>>> and Y  is
>>> IPv4, (c)  X is VPN-IPv6 and  Y is IPv6, we  have legacy solutions in
>>> deployment which could easily remain valid.
>>> 
>> 
>> We also have "legacy solutions" for the cases where (d) X is IPv6
>> and Y is IPv4, (e) X is L2VPN and Y is IPv4, (f) X is L2VPN and Y
>> is IPv6, (g) X is RT and Y is IPv4, (h) X is RT and Y is IPv6, ...
>> 
> 
> 
> On 27 Aug 2006, at 19:56, David Ward wrote:
> 
>> 
>> 
>> My first goal here was stated in the thread but, it was lost in our
>> exchange:
>> 
>> - A specification of how you tell what the address family of the NH
>> is.
>> 
>> - Rules to specify what address family the NH should be specified
>> in when a
>>   route is advertised.
>> 
>> - A reinterpretation of IPv4 AFI/SAFI  and IPv6 AFI/SAFI which
>> allows the NH
>>   to  be of  a  different  AF than  the  NLRI.  This would include the
>>   requirements for non-MPLS tunneled scenarios.
>> 
> 
> 
> I understand that some of the "legacy" solutions referred to above
> could result in a single <AFI/SAFI> pair being used both when the
> Next Hop is IPv4 and when it is IPv6 (for a given NLRI semantics).
> For example, the "legacy solutions" defined in rt-constrain for (g)
> and (h) seem to propose to use AFI/SAFI=1/132 regardless of whether
> Next Hop is IPv4 or IPv6 (Next Hop protocol is identified by next hop
> length).
> 
> Similarly, other potential solutions to "X over Y" mentioned earlier
> (which may or may not be eventually selected) such as using some
> "bits" in advertisement to convey the Next Hop protocol could involve
> a single AFI/SAFI pair being used for both IPv4 and IPv6 next hop.
> 
> I wonder if the current text of rfc2858bis offers sufficient
> flexibility to allow this. Quoting:
> "
>   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.
> "
> 
> The above text suggests to me that a given AFI/SAFI pair dictates a
> single protocol for the next hop, while we are talking here about
> potentially allowing different next hop protocols which are
> disambiguated via other means (such as next hop length).
> 
> Am I mis-interpreting rfc2858bis text?
> Is it conceivable/wise to tweak this text into something slightly
> more flexible along the lines of:
> "
>   Address Family Identifier:
>       This field in combination with the Subsequent Address Family
>       Identifier field identifies the _set of possible_ Network Layer
> protocol associated
>       with the Network Address of Next Hop and the semantics of
>       the Network Layer Reachability Information that follows.
> "
> 
> Cheers
> 
> Francois
> 
> _______________________________________________
> 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