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

Alia Atlas <akatlas@gmail.com> Thu, 24 September 2015 19:12 UTC

Return-Path: <akatlas@gmail.com>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DF191A87A9; Thu, 24 Sep 2015 12:12:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.999
X-Spam-Level:
X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OqJI0G3P6utY; Thu, 24 Sep 2015 12:12:08 -0700 (PDT)
Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E2D91A87A0; Thu, 24 Sep 2015 12:12:07 -0700 (PDT)
Received: by oiev17 with SMTP id v17so46794435oie.1; Thu, 24 Sep 2015 12:12:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XReWIzKb4mCwoz+1KsVeOO7P5rbCluNX9qODMQ613M4=; b=AsZNwcyfxR1Vqqi8xPMia89ayBwZJ/mpjJyhpW8JVtBPLNPIux5fLx5oNZh6Ep6bG9 2HzbQj5wL8XFoOVbXeYE8t8xCy+LUR206uJMvQ+l0MOgRPI6mIDN/6uhJGbje+X7wX5i fLwHmkfc5fJSLOz1LpqdzfkQ6/IPo/rPW7+t9Ep+F0oBAI9FzJe4iIKFb1Yxw6kibjXN wpbTBPJSST4BrPZyW5WgWVbqM/AQXec/vgyY8C9IiV0ff8hTlqxpF7KhW5uiNwe1ZJkB TIBV7EjHqrFewcDVooNI9YkvjhLX108z3TZiZu8kE2WeFHEJUj90JpKVxO5OMG8rbD/k jndQ==
MIME-Version: 1.0
X-Received: by 10.202.175.88 with SMTP id y85mr813980oie.22.1443121926750; Thu, 24 Sep 2015 12:12:06 -0700 (PDT)
Received: by 10.60.55.170 with HTTP; Thu, 24 Sep 2015 12:12:06 -0700 (PDT)
In-Reply-To: <004EF2D7-DCB9-4469-B088-E66169F4A598@cisco.com>
References: <CAG4d1rf+MsJXVy+G8W8vWjD=P_126cpjAFjr9e-+eCw=KLZzjQ@mail.gmail.com> <D2282E26.3225B%acee@cisco.com> <036301d0f6b0$54e4c460$4001a8c0@gateway.2wire.net> <D22953F6.3290C%acee@cisco.com> <D2296445.3297C%acee@cisco.com> <CAG4d1rd1MCy1Z+L0r0fX4QJ+kAcj0Vb0x=eth5tog9y09htNig@mail.gmail.com> <004EF2D7-DCB9-4469-B088-E66169F4A598@cisco.com>
Date: Thu, 24 Sep 2015 15:12:06 -0400
Message-ID: <CAG4d1rfSs4T-N0bastvRuFEu7h97pwOb-JvBdBTxCOFurpNF0Q@mail.gmail.com>
From: Alia Atlas <akatlas@gmail.com>
To: "Acee Lindem (acee)" <acee@cisco.com>
Content-Type: multipart/alternative; boundary=001a113ce4c8cfc7440520830179
Archived-At: <http://mailarchive.ietf.org/arch/msg/ospf/oNdd6FnwrurbO1UQuyR3l465q-k>
Cc: OSPF List <ospf@ietf.org>, "draft-ietf-ospf-rfc4970bis@ietf.org" <draft-ietf-ospf-rfc4970bis@ietf.org>
Subject: Re: [OSPF] AD review of draft-ietf-ospf-rfc4970bis-02
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ospf/>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 Sep 2015 19:12:12 -0000

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) <acee@cisco.com> wrote:

> Hi Alia,
>
> On Sep 24, 2015, at 2:53 PM, Alia Atlas <akatlas@gmail.com> 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) <acee@cisco.com>
> 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)"
>> <ospf-bounces@ietf.org on behalf of acee@cisco.com> wrote:
>>
>> >Hi Tom,
>> >
>> >On 9/24/15, 6:02 AM, "t.petch" <ietfc@btconnect.com> 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)" <acee@cisco.com>
>> >>To: "Alia Atlas" <akatlas@gmail.com>om>; "OSPF List" <ospf@ietf.org>rg>;
>> >><draft-ietf-ospf-rfc4970bis@ietf.org>
>> >>Sent: Wednesday, September 23, 2015 3:37 PM
>> >>Subject: Re: [OSPF] AD review of draft-ietf-ospf-rfc4970bis-02
>> >>
>> >>
>> >>> Hi Alia,
>> >>>
>> >>> From: Alia Atlas <akatlas@gmail.com<mailto:akatlas@gmail.com>>
>> >>> Date: Tuesday, September 22, 2015 at 6:00 PM
>> >>> To: OSPF WG List <ospf@ietf.org<mailto:ospf@ietf.org>>,
>> >>"draft-ietf-ospf-rfc4970bis@ietf.org<mailto.org<mailto:
>> draft-ietf-ospf-rfc4970bis@i
>> >>etf.org>"
>> >><draft-ietf-ospf-rfc4970bis@ietf.org<mailtorg<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
>> >>> OSPF@ietf.org
>> >>> https://www.ietf.org/mailman/listinfo/ospf
>> >>>
>> >>
>> >
>> >_______________________________________________
>> >OSPF mailing list
>> >OSPF@ietf.org
>> >https://www.ietf.org/mailman/listinfo/ospf
>>
>>
>
>