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

Alia Atlas <akatlas@gmail.com> Thu, 24 September 2015 18:53 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 AB2251A8757; Thu, 24 Sep 2015 11:53:48 -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 Es8FtCHMO9bi; Thu, 24 Sep 2015 11:53:43 -0700 (PDT)
Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) (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 644FF1A874B; Thu, 24 Sep 2015 11:53:43 -0700 (PDT)
Received: by obbbh8 with SMTP id bh8so65390197obb.0; Thu, 24 Sep 2015 11:53:42 -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=8IrVWft3djkrfTeVksGKzWc9nCZ4fxGCWwMGXORdJVw=; b=xZ7XJ2ekL59BPEUiMkYl59IEx7n6m46Ic6L3GLkFBzJrB19XA3gsTYWK+mtYuxzht+ 9B9jms5s8UzMdJ0Uod/fNomj/1sn1b/4NFYr1Q+TFSBvO9/DkpdF7vMrXelAefZxkVvt mWQDfOanIHMBWrv3OW/PaPjMqoL8uxLTqx6g+jxyv2294fJD4NyOfC4uz7pZAbUfuzDJ 9bGob0phdihQFQovH1mHMeYAUgXHwTzZdH7/V7R25bGhoyMswkYMwdT0hXKNsibbcKtU PJBOhX/bpNFwUpxf1ARYtKoMMPQd1o2hTxg/vX8W68ZFdZ2R6PVe6XG77p0rn7QrwO/D iSeQ==
MIME-Version: 1.0
X-Received: by 10.60.131.244 with SMTP id op20mr819174oeb.24.1443120822487; Thu, 24 Sep 2015 11:53:42 -0700 (PDT)
Received: by 10.60.55.170 with HTTP; Thu, 24 Sep 2015 11:53:42 -0700 (PDT)
In-Reply-To: <D2296445.3297C%acee@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>
Date: Thu, 24 Sep 2015 14:53:42 -0400
Message-ID: <CAG4d1rd1MCy1Z+L0r0fX4QJ+kAcj0Vb0x=eth5tog9y09htNig@mail.gmail.com>
From: Alia Atlas <akatlas@gmail.com>
To: "Acee Lindem (acee)" <acee@cisco.com>
Content-Type: multipart/alternative; boundary=047d7b47274efe0f72052082bff3
Archived-At: <http://mailarchive.ietf.org/arch/msg/ospf/9W1gTUEtgMWaolHDzG6ysMfQHLk>
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 18:53:48 -0000

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) <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:draft-ietf-ospf-rfc4970bis@i
> >>etf.org>"
> >><draft-ietf-ospf-rfc4970bis@ietf.org<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
>
>