Last Call: 'Connecting IPv6 Islands over IPv4 MPLS using IPv6 Provider Edge Routers (6PE)' to Prop

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"
<flefauchcisco.com> 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):
>>>>> 
>>>>>          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
>>>>> 
>>>>> 
>>>>>> Cheers,
>>>>>> R.
>> 
>> 

_______________________________________________
Softwires mailing list
Softwiresietf.org
http
s://www1.ietf.org/mailman/listinfo/softwires

Last Call: 'Connecting IPv6 Islands over IPv4 MPLS using IPv6 Provider Edge Routers (6PE)' to Prop

Thread: Last Call: 'Connecting IPv6 Islands over IPv4 MPLS using IPv6 Provider Edge Routers (6PE)' to Prop