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

From: The IESG <[email-masked]>
Date: Wed, 09 Aug 2006 15:08:54 -0400

The IESG has received a request from the Inter-Domain Routing WG to consider 
the following document:

- 'Connecting IPv6 Islands over IPv4 MPLS using IPv6 Provider Edge Routers 
   (6PE) '
   <draft-ooms-v6ops-bgp-tunnel-06.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[email-masked] or [email-masked] mailing lists by 2006-08-23.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ooms-v6ops-bgp-tunnel-06.txt

Implementation Report can be accessed at
http://www.ietf.org/IESG/Implementations/Implementation_draft-levy-idr-6pe-survey.txt

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

---

From: Bill Fenner <[email-masked]>
Date: Fri, 11 Aug 2006 17:04:06 -0700

>But it is v6ops, not idr, that has the overview of
>IPv4/IPv6 coexistence solutions.

Brian,

  In 2004, the v6ops WG had consensus to go forward with this solution,
and asked idr to progress with it because v6ops didn't have the
BGP expertise.

  Bill

---

From: Bill Fenner <[email-masked]>
Date: Thu, 24 Aug 2006 04:38:44 -0700

>How does this interact with softwires?

Sam,

  This protocol fits into more or less the Mesh problem of softwires
(section 3.1 of draft-ietf-softwire-problem-statement).  The problem
statement says:

>   It should also be noted that the mesh problem can be considered as a
>   derivative of L3VPN, where the core provides transit in one address
>   family and the islands are connected via L3VPN of another address
>   family.

And indeed, the draft-ooms document is more or less an application of the
L3VPN technology to the IPv6 address family.

  I don't know what the softwires participants' position is with respect
to this draft, but it predates the softwires work [at least, by that
name] by about 5 years.

  Bill

---

From: Yakov Rekhter <[email-masked]>
Date: Fri, 25 Aug 2006 06:49:21 -0700

Bill,

> to this draft, but it predates the softwires work [at least, by that

I think it would be very useful to get the softwires participatns'
position with respect to this draft. Specifically, if the draft
does solve their problem, then the softwires WG should document it
as a solution, and if not, then again the softwires WG should
document it with an explanation on why it does not solve their
problem.

Yakov.

---

From: David Ward <[email-masked]>
Date: Fri, 25 Aug 2006 10:14:41 -0500

I will take this to our list  and we will additionally discuss at our
interim meeting (mid Sept). In all likelihood (without having gone over the
entire draft with a fine toothed comb), it will satisfy one item in our
problem space. 

If for some reason the softwires WG finds deficiencies, we will explain
ourselves.

-DWard

---

From: David Ward <[email-masked]>
Date: Fri, 25 Aug 2006 10:14:41 -0500

-DWard

---

From: David Ward <[email-masked]>
Date: Fri, 25 Aug 2006 12:33:49 -0500

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.

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.

Flames? You know where to send them ... ;-)

-DWard

---

From: Yakov Rekhter <[email-masked]>
Date: Fri, 25 Aug 2006 11:28:15 -0700

David,

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

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.

---

From: David Ward <[email-masked]>
Date: Fri, 25 Aug 2006 14:13:31 -0500

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

---

From: Yakov Rekhter <[email-masked]>
Date: Fri, 25 Aug 2006 13:17:57 -0700

Dave,

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

---

From: Pekka Savola <[email-masked]>
Date: Sat, 26 Aug 2006 00:33:51 +0300 (EEST)

> If for some reason the softwires WG finds deficiencies, we will explain

Just to shed some light to the background, as I was a v6ops co-chair 
at the time, this draft _specifically_ removed support for 
tunnel-based encapsulation as the draft's applicability was geared at 
MPLS deployment.

I'm not sure if I'd want to have it added back.  Of course, this WG is 
free to build on existing work to do its deliverables.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: David Ward <[email-masked]>
Date: Fri, 25 Aug 2006 17:43:04 -0500

Yakov -

Please note that we have to solve the scenarios that include tunnel
encapsulation aka non-MPLS deployments. Therefore, the AF/SAF needs some
reinterpretation.

Thanks

-DWard

---

From: Yakov Rekhter <[email-masked]>
Date: Sun, 27 Aug 2006 09:44:18 -0700

Dave,

> 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) ?

> 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" ?

Yakov.

---

From: David Ward <[email-masked]>
Date: Sun, 27 Aug 2006 12:56:36 -0500

Yakov -

> or do you mean that there should be no MPLS at all, even at the edges

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.

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