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

[Alia Atlas <[e-mail]>]

Acee,

Sorry- I made the error of looking at the diff and you'd done two quick
versions in succession.

I'll put it in IETF Last Call - but I'd still be much happier hearing from
others in the WG
about support or interest in this draft.

Thanks,
Alia

On Thu, Sep 24, 2015 at 3:09 PM, Acee Lindem (acee) <[e-mail]> wrote:

> Hi Alia,
>
> On Sep 24, 2015, at 2:53 PM, Alia Atlas <[e-mail]> wrote:
>
> 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…
>
>
> Maybe because it is very brief. I wanted to avoid discussion of specific
> existing TLVs.
>
> 3.  Backward Compatibility
>
>    For backward compatibility, previously advertised Router Information
>    TLVs SHOULD continue to be advertised in the first instance, i.e., 0,
>    of the Router Information LSA.  If a Router Information TLV is
>    advertised in multiple Router Information LSA instances and the
>    multiple instance processing is not explicitly specified in the RFC
>    defining that Router Information TLV, the Router Instance TLV in the
>    Router Information LSA with the numerically smallest Instance ID will
>    be used and subsequent instances will be ignored.
>
> Thanks,
> Acee
>
>
> 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
>>
>>
>
>