Re: [Idr] fixing wording in 2858bis

[Pekka Savola <[e-mail]>]

On Tue, 7 Nov 2006, Yakov Rekhter wrote:
> 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.

Does this require revisiting the implementation report for 2858bis?

> ------- Forwarded Message
> 
> Date:    Mon, 06 Nov 2006 14:11:37 -0800
> From:    Francois Le Faucheur <[e-mail]>
> To:      [e-mail]
> 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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/idr
> 
> ------- End of Forwarded Message
> 
> 
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/idr
> 

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

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