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

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.

In addition, we need to handle the  "X is VPN-IPv4 and Y is IPv6" case, as
well as the case where X is IPv4 and  Y is IPv6 and the case where X is IPv6
and Y is IPv4.  The necessary document being proposed needs at least the
following components:

- A reinterpretation of IPv4 AFI/SAFI  and IPv6 AFI/SAFI which allows the NH
  to  be of  a  different  AF than  the  NLRI.  Since  we  are changing  the
  interpretation of the existing AFI/SAFIs, we could define a capability
  (see earlier suggestion - below in thread).

- 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.

I am willing to write the document which will attempt to preserve and
clarify legacy techniques as well as specify the solution to the the issues
listed above to make progress. Thoughts?

-DWard

On 8/25/06 1:28 PM, "Yakov Rekhter" <yakov@juniper.net> wrote:

> David,
> 
>> Yakov, Bill -
>> 
>> Having read the document I have some initial comments. First, 6PE is an
>> excellent solution. Overstating the obvious (perhaps my greatest talent),
>> this is a solution for the subset of softwire problems that would be used
>> for 6-over-4 when the encaps policy is "always use MPLS" and there are no
>> security requirements. I will leave the question of 'no security
>> requirements' for this solution to others.
>> 
>> The major deficiency from a softwires vantage point is that the v4 NH  gets
>> encoded in a  v6 format, but semantically it's  v4 and this encoding trick
>> doesn't work when you're doing v6 over v4. This is not to say the solution
>> doesn't work but, since softwires has to solve both v4 over v6 and v6 over
>> v4 (and variants including VPNs); I strongly urge that we don't have
>> multiple techniques to derive the AF of the NH.
> 
> As we move forward, I agree with the goal of having a single technique
> to derive AF of the NH within the context of MP_REACH/MP_UNREACH.
>   
>> The current advancement of multiple techniques that require either encoding
>> or length-check should be cleared up and made obvious and consistent.
>> 
>> I recommend some number of bits (or a byte) be used to state clearly what the
>> AF of the NH is and leave in original encoding. A capability can be added to
>> make sure that a peer can understand the new bits. Of course, I am looking
>> for the minimal change to the doc and to BGP but, this matter needs to be
>> discussed. The assumptions becoming embedded in the techniques of how to
>> figure out what the actual AF of the NH could be easily cleared up w/ the
>> suggestion of just very small number of bits and a capability in BGP.
> 
> While having "new bits" may be sufficient, it is by no means
> necessary. This is because the current/original encoding already
> provides a way to distinguish between IPv4 and IPv6 addresses in
> the NH of MP_REACH/MP_UNREACH. I am referring to the approach
> already used in several documents approved by the IETF (e.g.,
> draft-ietf-l2vpn-signaling, draft-ietf-l3vpn-rt-constrain,
> draft-ietf-l2vpn-vpls-bgp) where the NH Length field is used
> to distinguish between IPv4 and IPv6 as the NH.
> 
> And just for completeness, the current/original encoding provides
> yet another way to distingush between IPv4 and IPv6 as the NH
> addresses - use two different SAFIs to distinguish between IPv4 and
> IPv6 as the NH. However, I am not aware of any IETF technologies
> that use this approach.
>  
> Yakov.

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