Subject: [Softwires] 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, 4 Sep 2006 17:57:06 +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

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

---

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

On 9/14/06 5:21 AM, "Francois Le Faucheur" <[email-masked]> wrote:

> Hi Robert,
> 
> On 14 Sep 2006, at 10:54, Robert Raszuk wrote:
> 
>> 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 :-) ?
>> 
> 
> 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
> 
>> 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.
>> 
>>> On 14 Sep 2006, at 10:14, Robert Raszuk wrote:
>>> 
>>>> Francois,
>>>> 
>>>>> 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 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 :) ?
>>>> 
>>> 
>>> 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.
>>> 
>>> 
>>>> 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.
>>>> 
>>>> 
>>>>> Hi Robert,
>>>>> 
>>>>> On 14 Sep 2006, at 09:54, Robert Raszuk wrote:
>>>>> 
>>>>>> 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.
>>>>>> 
>>>>> 
>>>>> The text says:
>>>>> 
>>>>> "
>>>>> Address Family Identifier (AFI):
>>>>> 
>>>>>          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
>>>>> 
>>>>> 
>>>>>> Cheers,
>>>>>> R.
>> 
>>

---

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

Robert,

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

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.