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

From: Francois Le Faucheur <[email-masked]>
Date: Mon, 11 Sep 2006 15:00:23 +0200

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

---

From: David Ward <[email-masked]>
Date: Thu, 14 Sep 2006 00:32:14 -0500

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

---

From: Francois Le Faucheur <[email-masked]>
Date: Thu, 14 Sep 2006 09:17:49 +0200

Hello David,

On 14 Sep 2006, at 07:32, David Ward wrote:

> NH are required vs a bit of a tweak.

I think so too and am not questioning that.

What I am saying is that one paragraph of rfc2858bis (which is at a  
very late stage  ie in RFC Editor queue) _seems_ to unnecessarily  
preclude some of the potential "set of rules" which are being  
considered as candidate solutions (eg "use Length" as proposed in rt- 
constrain).
So I am asking whether (i) I am mis-reading this text or (ii) it  
wouldn't be wise to add 3 words to the rfc2858bis text so it no  
longer precludes this candidate "set of rule", in case it is decided  
that it is a desirable approach.

Yes, it would be better to solve the meta-problem in its entirety  
first. But I thought it may be worth deciding asap if we want to  
tweak rfc2858bis (because it's about to be completely frozen, if it  
is not already).

> The meta-problem is existing precedents

Yes. And again, it seemed to me that the current rfc2858bis text may  
actually not be quite in line with some of these precedents.

> developed and deployed; I hope that it isn't delayed any further as  

I hope so too.
BTW, I see the 6PE approach as in line with current rfc2858bis text,  
so 6PE is not concerned with the point I am raising here.
We will post a new rev of 6PE shortly addressing the few comments we  
got from AD/IESG review so it can move forward.

Cheers

Francois

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 14 Sep 2006 00:54:34 -0700

Francois,

IMHO the AFI and SAFI paragraphs from rfc2858bis you are proposing to
edit talk about NLRIs to AFI/SAFI associations and not indicate
characteristics of the next hop itself.

Cheers,
R.

---

From: Francois Le Faucheur <[email-masked]>
Date: Thu, 14 Sep 2006 10:04:37 +0200

Hi Robert,

> characteristics of the next hop itself.

The text says:

"
Address Family Identifier (AFI):

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

so in particular AFI/SAFI "identifies the network layer protocol  
associated with the network address of Next Hop".

This seems to be clearly defining associations between AFI/SAFI and  
Next Hop. And it seems to be implying that only one type of Next Hop  
can be asociated with a AFI/SAFI pair.
What am I missing?

Francois

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 14 Sep 2006 01:14:59 -0700

Francois,

> can be associated with a AFI/SAFI pair.

And I think this is fine as only one next hop can be present in MP_REACH
 attribute today. How can you associate set to a single next hop :) ?

Also note that the text you are proposing to edit is by itself not
perfect already in the different angle. NH length is allowed to be zero
- and that is good - but once we make the length = 0 a lot of text in
this rfc would need to be rewritten.

Cheers,
R.

> This seems to be clearly defining associations between AFI/SAFI and Next
> Hop. And it seems to be implying that only one type of Next Hop can be
> asociated with a AFI/SAFI pair.
> What am I missing?
> 
> Francois
> 
> 
>> Cheers,
>> R.
>>
>>
>>
>>
>>
>

---

From: Francois Le Faucheur <[email-masked]>
Date: Thu, 14 Sep 2006 10:36:26 +0200

On 14 Sep 2006, at 10:14, Robert Raszuk wrote:

> And I think this is fine
> as only one next hop can be present in MP_REACH

So, first, I think we now agree that rfc2858bis does talk about  
association between AFI/SAFI value and Next Hop Protocol.

The point is that if the Next Hop protocol is _identified_ by the AFI/ 
SAFI value, then, for a given NLRI format , you would need to  
systematically standardise two different AFI/SAFI pairs: one AFI/SAFI  
to advertise that NLRI format with an IPv4 Next Hop and another AFI/ 
SAFI pair to advertise that same NLRI with an IPv6 Next Hop (not in  
same MP_REACH of course, but possibly in different MP_REACH or simply  
in different networks). While this has been mentioned as potential  
approach, there has been arguments as to why this is not necessarily  
the best approach.

For example, the rt-constrain draft you co-authored currently defines  
a single AFI/SAFI pair (1/132) to advertise a Route Target membership  
NLRI, whether it is advertised with an IPv4 Next Hop or an IPv6 Next  
Hop. And then you use the Length to decide whether the Next Hop is  
IPv4 or IPv6. It seems to me that this somewhat contradicts the  
rfc2858bis statement saying that "the AFI/SAFI identifies the Next  
Hop protocol". It precisely does not, since it is instead identified  
by the Length.

Again, at this stage I am not trying close the debate as to which  
approach is best, I just want to make sure rfc2858bis is kept open to  
the candidate/existing approaches.

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 14 Sep 2006 01:54:10 -0700

Hey Francois,

Ok so you proved that the text describing AFI/SAFI is poorly written and
does not even reflect implementations reality (for example as you said:
rt-constrain).

I don't think that adding your change will make a huge difference and
will make the spec perfect.

So since you have started what do you propose ? Are you volunteering to
clean-up/fix rfc2858bis to reflect needs and reality a bit more -
provided this is not too late now :-) ?

What I would propose to make existing implementations happy would be to
add a paragraph that if length is equal to 255 Next Hop will be present
in a separate NH attribute. That should sufficiently address a couple of
 today's requirements.

Cheers,
R.

> The point is that if the Next Hop protocol is _identified_ by the
> AFI/SAFI value, then, for a given NLRI format , you would need to
> systematically standardise two different AFI/SAFI pairs: one AFI/SAFI to
> advertise that NLRI format with an IPv4 Next Hop and another AFI/SAFI
> pair to advertise that same NLRI with an IPv6 Next Hop (not in same
> MP_REACH of course, but possibly in different MP_REACH or simply in
> different networks). While this has been mentioned as potential
> approach, there has been arguments as to why this is not necessarily the
> best approach.
> 
> For example, the rt-constrain draft you co-authored currently defines a
> single AFI/SAFI pair (1/132) to advertise a Route Target membership
> Hop. And then you use the Length to decide whether the Next Hop is IPv4
> or IPv6. It seems to me that this somewhat contradicts the rfc2858bis
> statement saying that "the AFI/SAFI identifies the Next Hop protocol".
> It precisely does not, since it is instead identified by the Length.
>

---

From: Francois Le Faucheur <[email-masked]>
Date: Thu, 14 Sep 2006 12:21:35 +0200

Hi Robert,

> provided this is not too late now :-) ?

Considering 2858bis is in Editor's queue, I am proposing that:
	* asap: if indeed needed, we do the minimum correction of current  
wording in 2858bis to ensure it does not preclude approaches that are  
being defined or under consideration
	* we continue the ongoing discussion on what is the best approach we  
want to have in the long run (in particular for Softwires) and  
specify those outside 2858bis. If those require BGP extensions (eg  
new BGP capabilities, new BGP syntax,...) those don't seem to need to  
be specified in 2858bis nor to hold 2858bis from being published. I  
think the Softwire chairs plan to try make that happen.

Let's hear other thoughts.

Thanks

Francois

>> IPv4

---

From: David Ward <[email-masked]>
Date: Fri, 15 Sep 2006 08:31:38 -0500

R/F, et al -

At the softwires interim meeting today in Barcelona I presented the current
problem, three alternatives (len, new TLV, new SAFI assignment) and a
exposition of pros/cons. I'll send a pointer to the preso as soon as it is
available online. I'd be willing to present this at the IDR WG in San Diego
and hopefully have a suggestion of text for the RFC.

Note that at the IDR meeting in San Diego, it would be great if someone
would also be willing to present the multiple next hop issue and potential
solution set so that the IDR WG has full information.

Thanks

-DWard

---

From: Francois Le Faucheur <[email-masked]>
Date: Fri, 15 Sep 2006 17:29:59 +0200

David,

> and hopefully have a suggestion of text for the RFC.

By "the RFC", you mean 2858bis, right?
If 2858bis (which is currently "In RFC EDitor Queue") is put on hold  
till the NH decision is made (eg in San Diego), that works.
If 2858bis cannot be put on hold till then, then my suggestion is to  
tweak its wording as I proposed earlier just to make sure it does not  
conflict with any of the considered alternatives.

Cheers

Francois

---

From: Yakov Rekhter <[email-masked]>
Date: Fri, 15 Sep 2006 09:20:00 -0700

Robert,

> will make the spec perfect.

While Francois' proposed change may not "make the spec perfect",
it would certainly improve the match between the MP_BGP spec and
some of the existing applications that use MP_BGP (e.g., rt-constrain,
l2vpn).  Whether making this change "will make a huge difference"
is a matter of opinion...

Yakov.

---

From: Yakov Rekhter <[email-masked]>
Date: Fri, 15 Sep 2006 12:01:03 -0700

Francois,

[clipped...]
 
> disambiguated via other means (such as next hop length).

We are talking about the existing IETF standards track documents
(l2vpn, rt-constrain) that for a given (AFI, SAFI) combination allow 
the next hop to be either IPv4 or IPv6, and use the next hop length 
to disambiguate between the two.

>       the Network Layer Reachability Information that follows.

I personally have no problems with your proposal, except that
the same tweaking should also be applied to the text on SAFI.

Yakov.