Re: [Last-Call] Genart last call review of draft-ietf-ospf-te-link-attr-reuse-12
"Scott O. Bradner" <sob@sobco.com> Mon, 01 June 2020 17:04 UTC
Return-Path: <sob@sobco.com>
X-Original-To: last-call@ietfa.amsl.com
Delivered-To: last-call@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83ACF3A1290; Mon, 1 Jun 2020 10:04:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.107
X-Spam-Level:
X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 hR-w8qvH6D9j; Mon, 1 Jun 2020 10:04:31 -0700 (PDT)
Received: from sobco.sobco.com (unknown [136.248.127.164]) by ietfa.amsl.com (Postfix) with ESMTP id E82663A12A8; Mon, 1 Jun 2020 10:04:29 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by sobco.sobco.com (Postfix) with ESMTP id 800EB3785C58; Mon, 1 Jun 2020 13:04:28 -0400 (EDT)
X-Virus-Scanned: amavisd-new at sobco.com
Received: from sobco.sobco.com ([127.0.0.1]) by localhost (sobco.sobco.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9-EzBE-eADB8; Mon, 1 Jun 2020 13:04:23 -0400 (EDT)
Received: from golem.sobco.com (golem.sobco.com [136.248.127.162]) by sobco.sobco.com (Postfix) with ESMTPSA id 8ADF23785C45; Mon, 1 Jun 2020 13:04:23 -0400 (EDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: "Scott O. Bradner" <sob@sobco.com>
In-Reply-To: <23b697ab-b773-b781-5e84-15c64f008907@cisco.com>
Date: Mon, 01 Jun 2020 13:04:23 -0400
Cc: Linda Dunbar <linda.dunbar@futurewei.com>, "gen-art@ietf.org" <gen-art@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, "draft-ietf-ospf-te-link-attr-reuse.all@ietf.org" <draft-ietf-ospf-te-link-attr-reuse.all@ietf.org>, "lsr@ietf.org" <lsr@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <DFE57A47-88CA-49DD-8AF8-315C398A672E@sobco.com>
References: <159068537978.29606.17882487660677527802@ietfa.amsl.com> <be900a0e-2f9f-e9f9-ad87-63121ae9703c@cisco.com> <SN6PR13MB2334975577CB640D7812E816858F0@SN6PR13MB2334.namprd13.prod.outlook.com> <dffb293d-2b95-9e89-eba3-567de72b8ae0@cisco.com> <SN6PR13MB23347E70A4C0DDA9BBA2E618858A0@SN6PR13MB2334.namprd13.prod.outlook.com> <23b697ab-b773-b781-5e84-15c64f008907@cisco.com>
To: Peter Psenak <ppsenak=40cisco.com@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/LGYpBt0grIoRCC88VZJlW7Rg6iA>
Subject: Re: [Last-Call] Genart last call review of draft-ietf-ospf-te-link-attr-reuse-12
X-BeenThere: last-call@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Last Calls <last-call.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/last-call>, <mailto:last-call-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/last-call/>
List-Post: <mailto:last-call@ietf.org>
List-Help: <mailto:last-call-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/last-call>, <mailto:last-call-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Jun 2020 17:04:34 -0000
that works for me - thanks Scott > On Jun 1, 2020, at 12:01 PM, Peter Psenak <ppsenak=40cisco.com@dmarc.ietf.org> wrote: > > Hi Linda, > > > On 01/06/2020 17:30, Linda Dunbar wrote: >> Peter, >> You said: >> /“//the problem with existing advertisement is that RSVP-TE will use it, even if it was not intended to be used by RSVP-TE.//”/ >> What is the problem if RSVP-TE use the advertisement? What specific attributes that RSVP-TE shouldn’t use? > > Following text has been added to the draft based on comments from Scott. > > "An example where this ambiguity causes problem is a network which has RSVP-TE enabled on one subset of links, and SRTE enabled on a different subset. A link attribute is advertised for the purpose of some other application (e.g. SRTE) for a link that is not enabled for RSV-TE. As soon as the router that is an RSVP-TE head-end sees the link attribute being advertised for such link, it assumes RSVP-TE is enabled on that link, even though in reality, RSVP-TE is not enabled on it. If such RSVP-TE head-end router tries to setup an RSVP-TE path via link where RSVP-TE is not enabled it will result in the path setup failure." > > Hope it makes it clear and addresses your question. > > thanks, > Peter > > > > > >> Linda Dunbar >> -----Original Message----- >> From: Peter Psenak <ppsenak@cisco.com> >> Sent: Friday, May 29, 2020 10:00 AM >> To: Linda Dunbar <linda.dunbar@futurewei.com>; gen-art@ietf.org >> Cc: last-call@ietf.org; lsr@ietf.org; draft-ietf-ospf-te-link-attr-reuse.all@ietf.org >> Subject: Re: Genart last call review of draft-ietf-ospf-te-link-attr-reuse-12 >> Linda, >> On 29/05/2020 16:52, Linda Dunbar wrote: >>> Peter, >>> You said: >>> /we are not defining any new attributes./ /We are allowing an existing link attributes to be used by other applications, including, but not limited to SRTE./ What prevent a node (or an application on the node) receiving the LSA from using the attributes carried by the LSA? >> the problem with existing advertisement is that RSVP-TE will use it, even if it was not intended to be used by RSVP-TE. >> We are providing a way to explicitly advertised apps that are allowed to use the advertised attributes. >>> If no new attributes are >>> to be added, then why need a new ASLA sub-TLV? >> to be able to use the existing attributes for new apps, other than RSVP-TE. >> thanks, >> Peter >>> Linda >>> -----Original Message----- >>> From: Peter Psenak <ppsenak@cisco.com <mailto:ppsenak@cisco.com>> >>> Sent: Friday, May 29, 2020 5:51 AM >>> To: Linda Dunbar <linda.dunbar@futurewei.com <mailto:linda.dunbar@futurewei.com>>; >> gen-art@ietf.org <mailto:gen-art@ietf.org> >>> Cc: last-call@ietf.org <mailto:last-call@ietf.org>; lsr@ietf.org >> <mailto:lsr@ietf.org>; >>> draft-ietf-ospf-te-link-attr-reuse.all@ietf.org >> <mailto:draft-ietf-ospf-te-link-attr-reuse.all@ietf.org> >>> Subject: Re: Genart last call review of >>> draft-ietf-ospf-te-link-attr-reuse-12 >>> Hi Linda, >>> On 28/05/2020 19:02, Linda Dunbar via Datatracker wrote: >>>> Reviewer: Linda Dunbar >>>> Review result: Not Ready >>>> I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. >>>> For more information, please see the FAQ at >>>> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.ietf.org%2Ftrac%2Fgen%2Fwiki%2FGenArtfaq&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C34b141b11fe6484fc65208d803e0e851%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637263611798933480&sdata=hXIX5xyAiXcFdymKVyg%2BVuQZAznQKJV5Il7U9OOdVv0%3D&reserved=0>. >>>> Document: draft-ietf-ospf-te-link-attr-reuse-?? >>>> Reviewer: Linda Dunbar >>>> Review Date: 2020-05-28 >>>> IETF LC End Date: 2020-05-29 >>>> IESG Telechat date: Not scheduled for a telechat >>>> Summary: this document introduces a new link attribute advertisement in OSPFv2 and OSPFv3 to address general link properties needed for new applications, such as Segment Routing. >>>> Major issues: >>>> The document has good description on the TLV structure of the Application specific Advertisements, but fails to describe what are the NEW Link attributes needed by Segment Routing. Page 7 (section 5) has a really good description on all the link properties added to OSFP (RFC4203, RFC 7308, RFC7471, RFC3630) to achieve TE. I can see Segment Routing would need each node to advertise its own SID and the SIDs of adjacent nodes. Can't they be encoded (or extended) in OSPF's NODE ID? >>> we are not defining any new attributes. >>> We are allowing an existing link attributes to be used by other applications, including, but not limited to SRTE. >>> thanks, >>> Peter >>>> Minor issues: >>>> Nits/editorial comments: >>>> Best regards, >>>> Linda Dunbar > > -- > last-call mailing list > last-call@ietf.org > https://www.ietf.org/mailman/listinfo/last-call
- [Last-Call] Genart last call review of draft-ietf… Linda Dunbar via Datatracker
- Re: [Last-Call] Genart last call review of draft-… Peter Psenak
- Re: [Last-Call] Genart last call review of draft-… Linda Dunbar
- Re: [Last-Call] Genart last call review of draft-… Peter Psenak
- Re: [Last-Call] Genart last call review of draft-… Linda Dunbar
- Re: [Last-Call] Genart last call review of draft-… Peter Psenak
- Re: [Last-Call] Genart last call review of draft-… Scott O. Bradner
- Re: [Last-Call] Genart last call review of draft-… Linda Dunbar
- Re: [Last-Call] Genart last call review of draft-… Peter Psenak
- Re: [Last-Call] Genart last call review of draft-… Acee Lindem (acee)
- Re: [Last-Call] Genart last call review of draft-… Linda Dunbar
- Re: [Last-Call] Genart last call review of draft-… Peter Psenak
- Re: [Last-Call] Genart last call review of draft-… Linda Dunbar
- Re: [Last-Call] [Lsr] Genart last call review of … Peter Psenak
- Re: [Last-Call] [Lsr] Genart last call review of … Linda Dunbar