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 17:25 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 819EC3A0C0B for <lsr@ietfa.amsl.com>; Fri, 15 May 2020 10:25:47 -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=ham 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 Kj90eVmY828m for <lsr@ietfa.amsl.com>; Fri, 15 May 2020 10:25:45 -0700 (PDT)
Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (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 58BC93A0B92 for <lsr@ietf.org>; Fri, 15 May 2020 10:25:45 -0700 (PDT)
Received: by mail-lf1-x134.google.com with SMTP id x27so2366881lfg.9 for <lsr@ietf.org>; Fri, 15 May 2020 10:25:44 -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=yF7e3N6/hUHL2IYYyNggWXOWFKxdA3SNohbaK6dWd6g=; b=YkY6PoG6Sa1SPYUQ0NDZu0GzGmo3v5Ob5zAw/P7ekZy3p25fMc+mfwZJ3ut521R3+t Csony6UB5rbpKL5UKJPk2yt9PoOOERto0Zccu8ywfVk1dMTyr9WKbkBHl78daRfrcnct V3hbfkHwZkGuAQiDlPtk0QpX/urOOfk/S2HFomRUNs6iKHE3tCHBNyopQmPrPMf2brgE t4TTeWivShDpPDx97cnWaTSuR6RNg3gCMSJ/XGeYXo/kZc+BM4I0hX0wza3JhuXUP5EJ 82VoUwWz6YhO8RvnbtrwsbW0/arCyQt3j1r0jr/0dWqtJsVVmqn02YoqqTnteZ7LpgnB vwXQ==
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=yF7e3N6/hUHL2IYYyNggWXOWFKxdA3SNohbaK6dWd6g=; b=diCOepMXLT3wCNG+eZzume7hhzWlK3eZljBej6R7dDqPjXa4EDWGJfKf/ZAc7/RIoj t20JISFvo8TRdfXEoxwK7UCz4dswM/j8Ak0rAMbRx1dpQoUofxfKqwzrj5qNXKspckQ3 9unUaHsqM6okK+AgCJ8VdPqKHX/sDRL0ce49OQPQ7ZnD9wmjJ7N0G3N485sC5norPzvI G/oED1saCT70lz2Zw/ALcSIpfVHKp7dFT6+w9/lZuZ0YzQl0GL8ZJppr8GScbJmBIkfV PM5WVtJoSW4i+Qnol/OPdxkm6gj6hOCzF2f9U58oOa8Qfud/Axb6qNF4y2Wc/iOKp0S2 rMLw==
X-Gm-Message-State: AOAM5308tIaFrO3knpNYTRtYKH1nMg6gkOx9sADweWn8TM6cd/hBMtvq tY+VLwqTFMOMDPPns/r5gwNmRWReACRS/A76Ov9uxw==
X-Google-Smtp-Source: ABdhPJxNECT/qSaRsPO3irrnBO+9ZfkeESxpHEAAXeUCgvLXf82ZISWuekU8rp4aed9ESTzG1Z5NDGn4VKXMKYY3Rfc=
X-Received: by 2002:ac2:57cd:: with SMTP id k13mr3100897lfo.104.1589563543153; Fri, 15 May 2020 10:25:43 -0700 (PDT)
MIME-Version: 1.0
References: <158950595036.5639.14249690264747935521@ietfa.amsl.com> <c463544f-0397-bc06-a65a-e6c42a1cadcd@cisco.com>
In-Reply-To: <c463544f-0397-bc06-a65a-e6c42a1cadcd@cisco.com>
From: Warren Kumari <warren@kumari.net>
Date: Fri, 15 May 2020 13:25:06 -0400
Message-ID: <CAHw9_iL2v74h2fgDGxRu4UoZRPUMnGHvyG7kpE37rR9vvp9jqw@mail.gmail.com>
To: Peter Psenak <ppsenak@cisco.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-ospf-mpls-elc@ietf.org, lsr-chairs@ietf.org, lsr@ietf.org, Acee Lindem <acee@cisco.com>, Alvaro Retana <aretana.ietf@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000005683cd05a5b31af0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/7HdaPtqpV-E5gZOAsUqOsewUves>
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 17:25:48 -0000

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).

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