[Idr] fixing wording in 2858bis

Yakov Rekhter <yakov@juniper.net> Tue, 07 November 2006 17:08 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhURS-0003cz-U3; Tue, 07 Nov 2006 12:08:54 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhURR-0003cL-OG for idr@ietf.org; Tue, 07 Nov 2006 12:08:53 -0500
Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhURP-0004ma-5h for idr@ietf.org; Tue, 07 Nov 2006 12:08:53 -0500
Received: from magenta.juniper.net (magenta.juniper.net [172.17.28.122]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id kA7H8mX56717 for <idr@ietf.org>; Tue, 7 Nov 2006 09:08:50 -0800 (PST) (envelope-from yakov@juniper.net)
Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id kA7H8hE66516 for <idr@ietf.org>; Tue, 7 Nov 2006 09:08:43 -0800 (PST) (envelope-from yakov@juniper.net)
Message-Id: <200611071708.kA7H8hE66516@magenta.juniper.net>
To: idr@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <46874.1162919323.1@juniper.net>
Date: Tue, 07 Nov 2006 09:08:43 -0800
From: Yakov Rekhter <yakov@juniper.net>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 187ae6c2eea74946c0ab707161f6256d
Subject: [Idr] fixing wording in 2858bis
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
Errors-To: idr-bounces@ietf.org

Folks,

The goal of the text proposed by Francois below is to clarify the
initial intent and more accurately reflect the current use of 2858bis.
In other words the goal of this change is to eliminate a mismatch
between the current of use 2858bis (as specified in such documents
as draft-ietf-l2vpn-signaling, draft-ietf-l3vpn-rt-constrain, and
draft-ietf-l2vpn-vpls-bgp, RFC4659, and draft-ooms-v6ops-bgp-tunnel)
and the current text of 2858bis.

Please comment on the proposed wording. The deadline for comments
is Nov 17,2006.

Yakov.
------- Forwarded Message

Date:    Mon, 06 Nov 2006 14:11:37 -0800
From:    Francois Le Faucheur <flefauch@cisco.com>
To:      idr@ietf.org
Subject: Re: [Idr] Re: Last Call: 'Connecting IPv6 Islands over IPv4 MPLS using
	   IPv6 Provider Edge Routers (6PE)' to Proposed Standard

Hello,

In order to help reach closure on that one, below is a proposal (that  
a few of us converged on) for tweaking the wording of 2858bis:

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

with:

>       Address Family Identifier (AFI):
>
> 	 This field in combination with the Subsequent Address
> 	 Family Identifier field identifies the set of Network Layer
> 	 protocols to which the address carried in the Next Hop field
> 	 must belong, the way in which the address of the next hop
> 	 is encoded, and the semantics of the Network Layer
> 	 Reachability Information that follows. If the Next Hop is
> 	 allowed to be from more than one Network Layer protocol,
> 	 the encoding of the Next Hop MUST provide a way to determine
> 	 its Network Layer protocol.


Replace:
>
>       Subsequent Address Family Identifier (SAFI):
>
>          This field in combination with the Address Family Identifier
>          field identifies the Network Layer protocol associated  
>          with the
>          Network Address of the Next Hop and the semantics of the
>          Network Layer Reachability Information that follows.

With:

>       Subsequent Address Family Identifier (SAFI):
>
> 	 This field in combination with the Address Family Identifier
> 	 field identifies the set of Network Layer protocols to which
> 	 the address carried in the Next Hop must belong, the way
> 	 in which the address of the next hop is encoded, and the
> 	 semantics of the Network Layer Reachability Information
> 	 that follows. If the Next Hop is allowed to be from more
> 	 than one Network Layer protocol, the encoding of the Next
> 	 Hop MUST provide a way to determine its Network Layer
> 	 protocol.


Cheers

Francois




On 14 Sep 2006, at 03:21, Francois Le Faucheur 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.
>>
>>
>

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www1.ietf.org/mailman/listinfo/idr

------- End of Forwarded Message


_______________________________________________
Idr mailing list
Idr@ietf.org
https://www1.ietf.org/mailman/listinfo/idr