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

[David Ward <[e-mail]>]

Yakov -


On 8/27/06 11:44 AM, "Yakov Rekhter" <[e-mail]> wrote:

> Dave,
> 
>> Yakov -
>> 
>> Please note that we have to solve the scenarios that include tunnel
>> encapsulation aka non-MPLS deployments.
> 
> By "non-MPLS deployment" do you mean that the tunnels can not be LSPs,
> or do you mean that there should be no MPLS at all, even at the edges
> (PEs) ?
> 

The tunnels cannot be LSPs in all scenarios. The Softwires framework (under
evolution) states  that VPNs and non VPNs must be allowed to be present (as
well as mcast and secure solutions). The point is definitely NOT to dictate
that the entire network MUST be MPLS-free. We want our cake and eat it too.

>> Therefore, the AF/SAF needs some reinterpretation.
> 
> You still did not answer my question. Namely, which of the AFI/SAFIs
> currently defined by IETF need "some reinterpretation" ?
> 

As discussed earlier, it appears that the 6PE solution applies in a
particular scenario. Also, I mentioned the upcoming softwires interim
meeting where we are working to further pull together a framework that will
describe in more detail the applicability of NH reinterpretation.

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.


The last piece we can work through in our WGs as the softwires framework
becomes more mature. If you feel it would help, I'd be willing to attempt to
draft some clarity as our thread isn't a good mechanism of archiving any
conclusions we have reached.

My second goal w/ softwires is not to create an upheaval in massive
deployments of existing technology. Where there are cases of emerging
technology (softwires, unseen Bonica draft, multiple NH in BGP), the WGs can
discuss if "length assumptions|addr translation" works in all cases or, if
an extension is appropriate to clearly state semantics of the protocol. I
bring up the multiple-NH issue as it is another case where NH semantics may
need reinterpretation. Since there are multiple discussions on NH semantics
in BGP, I don't think we can avoid clarification and eventual resolution.

Unfort our discusson may have been of little use for the review of the 6PE
draft. We have been discussing a tangential issue. The only point is that
the 6PE solution (addr translation) is not a universal solution to the
softwires problem and does not solve all our scenarios. Should my comments
in any way prevent the draft from progressing? At the very least, it may
cause a draft to be written that clarifies BGP NH semantics and
interpretation techniques in different scenarios.

-DWard



> Yakov. 
> 
>> 
>> 
>> Thanks
>> 
>> -DWard
>> 
>> 
>> On 8/25/06 3:17 PM, "Yakov Rekhter" <[e-mail]> wrote:
>> 
>>> Dave,
>>> 
>>>> Yakov, Bill -
>>>> 
>>>> Since we allow the route to an X-prefix to have a Y-address as its next ho
> p,
>>>> we still need an SOFTWIRE|IDR document to specify  how to do that.  For th
> e
>>>> 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, ...
>>>   
>>>> In addition, we need to handle the  "X is VPN-IPv4 and Y is IPv6" case,
>>> 
>>> See e-mail from Ron Bonica on this.
>>> 
>>>> as  well as the case where X is IPv4 and Y is IPv6 and the case
>>>> where X is IPv6 and Y is IPv4.
>>> 
>>> X is IPv6 and Y is IPv4 is done (6PE).
>>> 
>>> The only item from your list above for which the IETF does not have
>>> a solution is the case where X is IPv4 and Y is IPv6. With this in
>>> mind, why would not the softwires WG take the existing 6PE as the
>>> base and modify it to cover the case where X is IPv4 and Y is IPv6 ?
>>> 
>>>> 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 the interpretation of MP_REACH/MP_UNREACH depends on a combination
>>> of AFI/SAFI, and since IPv4 or IPv6 only define AFI, which of the
>>> currently defined SAFIs need the reinterpretation ?
>>> 
>>> Yakov.


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