Re: [OSPF] AD review of draft-ietf-ospf-rfc4970bis-02

[Alia Atlas <[e-mail]>]

Acee,

I just took a quick look at this version and the IANA section looks much
better.
I don't see an extra paragraph talking about backwards compatibility...

I'd like to get this out for IETF Last Call today, if you can spin a quick
version.

Thanks,
Alia

On Thu, Sep 24, 2015 at 8:28 AM, Acee Lindem (acee) <[e-mail]> wrote:

> Hi Tom,
>
> I believe the 04 update addresses your comments and will make IANA’s job a
> lot easier.
>
> A new version of I-D, draft-ietf-ospf-rfc4970bis-04.txt
> has been successfully submitted by Acee Lindem and posted to the
> IETF repository.
>
> Name:           draft-ietf-ospf-rfc4970bis
> Revision:       04
> Title:          Extensions to OSPF for Advertising Optional Router
> Capabilities
> Document date:  2015-09-24
> Group:          ospf
> Pages:          15
> URL:
> https://www.ietf.org/internet-drafts/draft-ietf-ospf-rfc4970bis-04.txt
> Status:
> https://datatracker.ietf.org/doc/draft-ietf-ospf-rfc4970bis/
> Htmlized:       https://tools.ietf.org/html/draft-ietf-ospf-rfc4970bis-04
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-rfc4970bis-04
>
> Abstract:
>    It is useful for routers in an OSPFv2 or OSPFv3 routing domain to
>    know the capabilities of their neighbors and other routers in the
>    routing domain.  This document proposes extensions to OSPFv2 and
>    OSPFv3 for advertising optional router capabilities.  The Router
>    Information (RI) Link State Advertisement (LSA) is defined for this
>    purpose.  In OSPFv2, the RI LSA will be implemented with an opaque
>    LSA type ID.  In OSPFv3, the RI LSA will be implemented with a unique
>    LSA type function code.  In both protocols, the RI LSA can be
>    advertised at any of the defined flooding scopes (link, area, or
>    autonomous system (AS)).  This document obsoletes RFC 4970 by
>    providing a revised specification including support for advertisement
>    of multiple instances of the RI LSA and a TLV for functional
>    capabilities.
>
>
>
> Thanks,
> Acee
>
> On 9/24/15, 7:31 AM, "OSPF on behalf of Acee Lindem (acee)"
> <[e-mail] on behalf of [e-mail]> wrote:
>
> >Hi Tom,
> >
> >On 9/24/15, 6:02 AM, "t.petch" <[e-mail]> wrote:
> >
> >>Acee
> >>
> >>Alia having alerted me to the IANA Considerations :-( two further
> >>thoughts.
> >>
> >>Jeff Haas has written an excellent I-D recommending that the first and
> >>last points of a numeric registry should be reserved, which I agree
> >>with. In that light, I suggest reserving 8191 in OSPFv3 LSA Function
> >>Codes
> >
> >I must admit that I thought this whole discussion was much ado about
> >nothing but I’m certainly not opposed to reserving the last function code.
> >If we run into a situation where we use the whole OSPFv3 LSA Function Code
> >space, it will mean that OSPFv3 has been wildly successful!
> >
> >>
> >>Second, 5226bis proposes a cleaner terminology, replacing top-level
> >>registry, registry, sub-registry, sub-sub registry etc with Registry
> >>within Group.  (OSPF has eleven Groups, BGP but one).  I see that OSPFv3
> >>LSA Function Codes is in the Open Shortest Path First v3 (OSPFv3)
> >>Parameters Group.  I think that you are implying that IANA should update
> >>some but not all the references for that Registry.  Thus the reference
> >>for the Registry as a whole should be for this new I-D but the reference
> >>for individual entries for the most part do not change except where they
> >>are to RFC4970(?).
> >
> >Yes - Are you suggesting I state the registry is unchanged from RFC 4970
> >other than the change to the reservation policy and the reservation of
> >8192?
> >
> >
> >>
> >>Likewise for OSPF RI TLVs  which is in the Open Shortest Path First v2
> >>(OSPFv2) Parameters Group, some references will need updating, others
> >>will not, and I think that that needs specifying in the I-D.
> >
> >Yes - are you suggesting any change of text?
> >
> >
> >>
> >>OSPF Router Informational Capability Bits I think is another Registry
> >>within the same Group while OSPF Router Functional Capability Bits I
> >>think is a new Registry; I don't know which Group it fits best with but
> >>I think that that should be specified.
> >
> >This new registry should go in the "Open Shortest Path First v2 (OSPFv2)
> >Parameters" group the same as the existing "OSPF Router Informational
> >Capability Bits”.
> >
> >Thanks,
> >Acee
> >
> >
> >>
> >>Tom Petch
> >>
> >>
> >>----- Original Message -----
> >>From: "Acee Lindem (acee)" <[e-mail]>
> >>To: "Alia Atlas" <[e-mail]>; "OSPF List" <[e-mail]>;
> >><[e-mail]>
> >>Sent: Wednesday, September 23, 2015 3:37 PM
> >>Subject: Re: [OSPF] AD review of draft-ietf-ospf-rfc4970bis-02
> >>
> >>
> >>> Hi Alia,
> >>>
> >>> From: Alia Atlas <[e-mail]<mailto:[e-mail]>>
> >>> Date: Tuesday, September 22, 2015 at 6:00 PM
> >>> To: OSPF WG List <[e-mail]<mailto:[e-mail]>>,
> >>"[e-mail]<mailto:draft-ietf-ospf-rfc4970bis@i
> >>etf.org>"
> >><[e-mail]<mailto:draft-ietf-ospf-rfc4970bis@i
> >>etf.org>>
> >>> Subject: AD review of draft-ietf-ospf-rfc4970bis-02
> >>>
> >>> As is customary, I have done my AD review of
> >>draft-ietf-ospf-rfc4970bis-02.  First, let me thank Acee for his work on
> >>this draft.
> >>>
> >>> I have two major concerns before asking for an IETF Last Call.  I
> >>would like to have them
> >>> resolved by this Thursday so that the draft can make the Oct 15 IESG
> >>telechat.
> >>>
> >>> First, from a process concern, I do not see any active discussion on
> >>the OSPF mailing list - even to simply say "yes - go forward".  I don't
> >>see anything about this draft or discussion in minutes for IETF 92 or
> >>IETF 93.   I'd prefer some indication besides silence and lack of
> >>opposition.  I do realize that there are some process or
> >>protocol-tidying drafts where there isn't
> >>> much interest.  However, I am particularly concerned because this is
> >>changing RFC4970 is a way that should be backwards compatible but might
> >>trigger issues.   I would encourage WG participants to PLEASE RESPOND!
> >>>
> >>> Second, I can see the intent that by creating an Opaque ID and
> >>creating a special meaning for 0, the draft is making efforts to
> >>preserve backwards compatibility.  Please add a paragraph or subsection
> >>that articulates how and why backwards compatibility isn't an issue.
> >>>
> >>> I will add more on this.
> >>>
> >>>   For extra credit, what happens if the same TLV information is
> >>advertised in multiple RI LSAs (as part of moving it from one RI LSA to
> >>another)?
> >>>
> >>> This depends on the context of the TLV. In some cases the router
> >>information is additive and in others conflicts need to be resolved.
> >>>
> >>>
> >>>
> >>> Are there any implementations of this draft?  Has backwards
> >>compatibility been verified at all?
> >>>
> >>> Many implementations of RFC 4970. I don’t know of any implementations
> >>that originate multiple RI LSAs. However, with all the proposed OSPF RI
> >>LSA usages, I can see them coming.
> >>>
> >>>
> >>>
> >>> My minor issue is around the IANA considerations; I have detailed
> >>comments below.
> >>>
> >>> Here are additional comments.
> >>>
> >>> 1) In Sec 2: "The first Opaque ID, i.e., 0, should always contain the
> >>Router
> >>>    Informational Capabilities TLV and, if advertised, the Router
> >>>    Functional Capabilities TLV."  and Sec 2.2 "The first instance ID,
> >>i.e., 0,
> >>>    should always contain the Router Informational Capabilities TLV
> >>and,
> >>>    if advertised, the Router Functional Capabilities TLV."
> >>>
> >>>    Since I assume this is important for backwards compatibility,
> >>should those
> >>>    be SHOULD instead of should?
> >>>
> >>> Yes.
> >>>
> >>>
> >>>
> >>>
> >>> 2) In Sec 2.3: "The first defined TLV in the body of an RI LSA is the
> >>Router
> >>>    Informational Capabilities TLV."
> >>>
> >>>    Surely that is only for the first Opaque ID=0?  Does each
> >>subsequent RI LSA
> >>>    also need to contain a Router Informational Capabilities TLV??
> >>>
> >>> No. Will clarify this.
> >>>
> >>>
> >>>
> >>> 3) In Sec 4 IANA Considerations:  This section is defining the
> >>different IANA policies;
> >>> when RFC4970 was written, RFC5226 didn't exist.  But since you're
> >>doing a bis,
> >>> perhaps you can align to the policies in RFC5226 and remove the
> >>unnecessary text??
> >>>
> >>> Yes. I think of already done this.
> >>>
> >>>
> >>> 4) In Sec 4 IANA Considerations:  The registry for OSPFv3 LSA Function
> >>Codes can
> >>> be found at
> >>http://www.iana.org/assignments/ospfv3-parameters/ospfv3-parameters.xhtm
> >>l#ospfv3-parameters-3 and what is in the draft doesn't match up.  I'd
> >>settle for defining the ranges, and value 12 - but it's up to you and
> >>IANA on the preferences.  Would it make sense to change the policy from
> >>Standards Action to IETF Review here also?
> >>>
> >>> Yes - I think this draft should change the policy for OSPFv3 LSA
> >>Functions codes since RFC 4970 initially created the registry. If were
> >>going to change the policy (and I think we want to do this), it makes
> >>sense to do it here from a continuity standpoint.
> >>>
> >>>
> >>>
> >>> Same thing applies to the OSPF RI TLVS
> >>(http://www.iana.org/assignments/ospfv2-parameters/ospfv2-parameters.xht
> >>ml#ospfv2-parameters-9 )   Also here, I think there
> >>> was agreement among the 4 of us who commented on the WG mailing list
> >>to change this
> >>> from Standards Action to IETF Review.
> >>>
> >>> Yes.
> >>>
> >>>
> >>> 5) In Sec 4 IANA Considerations: "All Router Functional Capability TLV
> >>>        additions are to be assigned through standards action."   Given
> >>the discussion
> >>> about IETF Review vs. Standards Action for other registries, are you
> >>sure you want
> >>> Standards Action?
> >>>
> >>> No  - I will change this.
> >>>
> >>>
> >>> I'm sure that we'll get this moving along quickly.
> >>>
> >>> Great - will work on this today in preparation for the tomorrow’s
> >>telechat.
> >>>
> >>> Thanks,
> >>> Acee
> >>>
> >>>
> >>>
> >>> Thanks again!
> >>> Alia
> >>>
> >>
> >>
> >>------------------------------------------------------------------------
> >>--------
> >>
> >>
> >>> _______________________________________________
> >>> OSPF mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/ospf
> >>>
> >>
> >
> >_______________________________________________
> >OSPF mailing list
> >[e-mail]
> >https://www.ietf.org/mailman/listinfo/ospf
>
>