Re: [Lsr] Warren Kumari's No Objection on draft-ietf-ospf-mpls-elc-13: (with COMMENT)

Warren Kumari <warren@kumari.net> Fri, 15 May 2020 21:09 UTC

Return-Path: <warren@kumari.net>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DDB93A0984 for <lsr@ietfa.amsl.com>; Fri, 15 May 2020 14:09:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com
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 IMxsJzCGh8_C for <lsr@ietfa.amsl.com>; Fri, 15 May 2020 14:08:57 -0700 (PDT)
Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (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 9AC7F3A0980 for <lsr@ietf.org>; Fri, 15 May 2020 14:08:57 -0700 (PDT)
Received: by mail-lj1-x22f.google.com with SMTP id e25so3725003ljg.5 for <lsr@ietf.org>; Fri, 15 May 2020 14:08:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qcuCdPPKEvqs2oiXSvUFpWnI8LparfLOQNnqZDcWRkw=; b=dzzf5P+CQNV9e6K4izNzfRKsAeBOjbOKmExgbkd2tELuB0Lmgcic+73ZZSw+/RwWF1 ThXz4Y1Iaj1eB9GEknvTv1rGzmyAeJP/vQ9BeyTLAtBiCtZLl1qDjvzieob+DkBE2lAb 2VD1EEUKqrZJ4qaZsoZ4BMD5dKXyWa/bzQJxzACopxWaEQ/YM/1ZMwGoCXuQF0LFpvpn YRPkqxWHE8IFHWPqhPEPD9zydWhv3G7/t7PEkL5tEIyFBmLzkau/139XfThGRGpAmz2u cNOvSyaxxU8Bo6K+0M+VectIW5J8EYB1Z3ThqO+uDoS4VilfgKakJxJ18iWI1cvRnPG8 6e5w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qcuCdPPKEvqs2oiXSvUFpWnI8LparfLOQNnqZDcWRkw=; b=WAGKHGW7jGWAPIfBEdBb1zWYyS+DMcv4IeIe7yZ/l8kjdvaAAiYhpCQ7GwT8cp7GQV 7p/1PXe7hiaXEcYDAmF2V6C1aE0JzWnauynt2GbSjniyuibJizio9ENHTIK51pERUKM1 LZbnCU4ZQWw0xzAplqURvg3LqQ4dmN+OEhD9gZ3mqd4uLNvPoNBr49jWZFoEhE8IAPaL 6GTJQPA0VknHAHy/MQmOohL6rQOnWhpDmbjRLmGxSkQucPS5Bf8JZ0kS3AAo6Oz7VqA9 +KzwMMlhcb27wICOL0neWR66Un6L+s5slvJC42EDEmmRN1mIorjMnVdyF9eVr4rUUshM 88qg==
X-Gm-Message-State: AOAM533sPwucOu4c8sO0uH3hqVd25MhaqFOf3tOOOD/MpcZLIxPt16d6 zD+am/QnHLjc6lXp64t4OFZTSjVY5si3qWJWFvoEwA==
X-Google-Smtp-Source: ABdhPJwYwuWQJn6IqFLo+z4ItS2Tg1FaWPFIfvsxKppPrRzo9Ga10XP9GiHqqG+/yuPkPbWVg0Xboxj6ydPfZi3+9tY=
X-Received: by 2002:a2e:9896:: with SMTP id b22mr3490862ljj.276.1589576935406; Fri, 15 May 2020 14:08:55 -0700 (PDT)
MIME-Version: 1.0
References: <158950595036.5639.14249690264747935521@ietfa.amsl.com> <c463544f-0397-bc06-a65a-e6c42a1cadcd@cisco.com> <CAHw9_iL2v74h2fgDGxRu4UoZRPUMnGHvyG7kpE37rR9vvp9jqw@mail.gmail.com> <AE27DFF2-B2F1-460F-8A30-EC7D233A14DD@cisco.com>
In-Reply-To: <AE27DFF2-B2F1-460F-8A30-EC7D233A14DD@cisco.com>
From: Warren Kumari <warren@kumari.net>
Date: Fri, 15 May 2020 17:08:18 -0400
Message-ID: <CAHw9_i+=p-8JTu_mcYTVZ636+BquMOmbFR4z6jqG_2vSYgyZXQ@mail.gmail.com>
To: "Acee Lindem (acee)" <acee@cisco.com>
Cc: "Peter Psenak (ppsenak)" <ppsenak@cisco.com>, The IESG <iesg@ietf.org>, "draft-ietf-ospf-mpls-elc@ietf.org" <draft-ietf-ospf-mpls-elc@ietf.org>, "lsr-chairs@ietf.org" <lsr-chairs@ietf.org>, "lsr@ietf.org" <lsr@ietf.org>, Alvaro Retana <aretana.ietf@gmail.com>
Content-Type: multipart/alternative; boundary="00000000000095463b05a5b63810"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/PrbF_xz5NIQiOaXZaSH5cBIKRco>
Subject: Re: [Lsr] Warren Kumari's No Objection on draft-ietf-ospf-mpls-elc-13: (with COMMENT)
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 May 2020 21:09:01 -0000

On Fri, May 15, 2020 at 1:34 PM Acee Lindem (acee) <acee@cisco.com> wrote:

> Hi Warren,
>
>
>
> *From: *Warren Kumari <warren@kumari.net>
> *Date: *Friday, May 15, 2020 at 1:25 PM
> *To: *"Peter Psenak (ppsenak)" <ppsenak@cisco.com>
> *Cc: *The IESG <iesg@ietf.org>, "draft-ietf-ospf-mpls-elc@ietf.org" <
> draft-ietf-ospf-mpls-elc@ietf.org>, "lsr-chairs@ietf.org" <
> lsr-chairs@ietf.org>, "lsr@ietf.org" <lsr@ietf.org>, Acee Lindem <
> acee@cisco.com>, Alvaro Retana <aretana.ietf@gmail.com>
> *Subject: *Re: Warren Kumari's No Objection on
> draft-ietf-ospf-mpls-elc-13: (with COMMENT)
> *Resent-From: *<alias-bounces@ietf.org>
> *Resent-To: *Acee Lindem <acee@cisco.com>, Yingzhen Qu <
> yingzhen.ietf@gmail.com>, Christian Hopps <chopps@chopps.org>
> *Resent-Date: *Friday, May 15, 2020 at 1:25 PM
>
>
>
>
>
>
>
> On Fri, May 15, 2020 at 7:28 AM Peter Psenak <ppsenak@cisco.com> wrote:
>
> Hi Warren,
>
> On 15/05/2020 03:25, Warren Kumari via Datatracker wrote:
> > Warren Kumari has entered the following ballot position for
> > draft-ietf-ospf-mpls-elc-13: No Objection
> >
> > When responding, please keep the subject line intact and reply to all
> > email addresses included in the To and CC lines. (Feel free to cut this
> > introductory paragraph, however.)
> >
> >
> > Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-ospf-mpls-elc/
> >
> >
> >
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > Nit: “ When an OSPF Autonomous System Boundary Router (ASBR)
> redistributes a
> > prefix from another instance of the OSPF or from some other protocol,
>  it
> > SHOULD preserve the ELC signaling for the prefix.“
> >
> > S/the /OSPF/OSPF/.
>
> fixed.
>
>
>
> thanks!
>
>
> >
> > S/for the prefix/for the prefix (if it exists)/ — some protocols will
> not have
> > / carry the ELC.
>
> fixed.
>
>
>
> thanks!
>
>
> >
> > Apologies if I missed it, but I didn’t see discussion on *exporting* ELC
> into
> > other protocols...
>
> what do you mean by "exporting"?
>
>
>
> Sorry -- the above discusses : "When an OSPF Autonomous System Boundary
> Router (ASBR) redistributes a prefix ... FROM some other protocol,  "
> (imports), but presumably you would also like to be able to do "When an
> OSPF Autonomous System Boundary Router (ASBR) redistributes a prefix
> **INTO** some other protocol,  ..." (exports). Yes, the "other protocol"
> document should describe this in detail, but I think that it is worth
> mentioning the topic here -- we may be helpful for implementers to keep in
> mind that this may occur, and so the data should be reachable
> (likely through the RIB).
>
>
>
> Can you suggest some text? Do you realize that in the Routing Area, route
> redistribution (aka, route import/export) has always been considered an
> implementation matter and is not formally specified. It would hard to
> standardize this now (other than Routing Policy YANG model) due to
> differences between implementations.
>

Sure -- how about something like:
   When an OSPF Autonomous System Boundary Router (ASBR) redistributes a
   prefix from another instance of the OSPF or from some other protocol,
   it SHOULD preserve the ELC signaling for the prefix.
  **In addition ASBRs should allow the
  ELC signaling for the prefix to be preserved when redistributing
to another instance of OSPF or to some other protocol**

(Addition in asterisks).
Note that this is just a suggestion / not a hill I care to die on -- as an
ops person, when I read "you should be able to preserve X when importing
into Y", I automatically start wondering how / if I can preserve X when
exporting from Y.

But, 'm also fine if y'all don't want to address this,
W



>
>
> Thanks,
> Acee
>
>
>
> W
>
>
>
>
> thanks,
> Peter
>
> >
> >
> >
> >
> >
>
>
>
>
> --
>
> I don't think the execution is relevant when it was obviously a bad idea
> in the first place.
> This is like putting rabid weasels in your pants, and later expressing
> regret at having chosen those particular rabid weasels and that pair of
> pants.
>    ---maf
>


-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf