Re: [Lsvr] Mail regarding draft-ietf-lsvr-bgp-spf

Pushpasis Sarkar <pushpasis.ietf@gmail.com> Thu, 10 October 2019 06:45 UTC

Return-Path: <pushpasis.ietf@gmail.com>
X-Original-To: lsvr@ietfa.amsl.com
Delivered-To: lsvr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE8861201AA for <lsvr@ietfa.amsl.com>; Wed, 9 Oct 2019 23:45:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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, RCVD_IN_DNSWL_NONE=-0.0001, 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=gmail.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 sfYcjvjWwjTR for <lsvr@ietfa.amsl.com>; Wed, 9 Oct 2019 23:45:37 -0700 (PDT)
Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 1AFB4120100 for <lsvr@ietf.org>; Wed, 9 Oct 2019 23:45:37 -0700 (PDT)
Received: by mail-io1-xd2d.google.com with SMTP id q1so11334825ion.1 for <lsvr@ietf.org>; Wed, 09 Oct 2019 23:45:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nFrX5w73JLgmwV1BPYhihQ7AN2C7y19+WjSAOAXyTPc=; b=DeAjh5/BHFXABqZUVU0ayypCVbUNr8z9I1X+hZ05otnGCZxQBOV34hE6dJCeXZtBEv SOe1nb8VrfQ1kMb4l0aOgmVsLY8qWswxmSiK9SExSooIp+W1Q/BjiUdXAkR1dhNMaFz6 2R9tQc3cQPL2uH3UxlBDboqdil/QiOGm754JoW5ozrPbxoACqzrpjtxGL/l/MVrREaD6 M0N9twk1UnccedAlHaHsY9A0BwNE6Aai5l4qMckSSlfxTk0MK+l0uxDKDWT5KTYnwKRN czaWbciIFenFw0RsTzbB/hcZCHlMKkbk/RyPOwoxRFlzBNWEg4LwJVEqk6zDc5fplxrF BVQw==
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=nFrX5w73JLgmwV1BPYhihQ7AN2C7y19+WjSAOAXyTPc=; b=jdrrCjN3zkh02fXVhPOVaNilhe/AMXD9c0xvJDGY+WPls/LcxIx46dXdFISnnxgq3P faUtOQa8qEpluGD94hYJWEytBuvT6uwAszOHvrRuQACczdpc7Ou69G1+oY6R4j4rF/2P El76rIzIPqE6yjlebXEuE8Lo5hcFXbmrg15XAQlLZ+S6Sc5damdAo7UFdpYIQFsAvVnd 9/HzIQSlbiaYAMtnubuHnV9E+qPiG8Qrf7DadBTPWQc4FoSdKtxjvl4ARXizw3hRbd4k 8qQQI1OeI2cPHGHyDdfCzPDgBEDwRvq7J+JKa5rSoZFWkMPvHQRtGgSsZyDo06dGKqiJ u0QA==
X-Gm-Message-State: APjAAAWHCUXlI1y6sNk5Nh9nvyZ+Pzd2LE2nGIhBs4JLlYPYsWA8JK81 SBEWEVau7pFZI9a1+kjhjZR/fDvo+kPaNGUXj8Q=
X-Google-Smtp-Source: APXvYqwFuPB0R8L2RZ0QE0aXRz70vU1cHJ0dnXB3POQpoZ2EGDuPWlINBs1qMzD/v/iRUAAloERf256jAbiU79RihcU=
X-Received: by 2002:a6b:d812:: with SMTP id y18mr8676964iob.151.1570689936353; Wed, 09 Oct 2019 23:45:36 -0700 (PDT)
MIME-Version: 1.0
References: <D2BB4EDE-97FD-4A82-A93D-45203A34A339@cisco.com> <CA0B675FC61D874D8A9EB2C7B5CEA7872B6A7E11@MISOUT7MSGUSRDG.ITServices.sbc.com> <1DBF92B2-D384-4071-9156-B20795F099AB@cisco.com> <CAEFuwki8QBRL=ZXFy46RCgTyUX4ffYvVAeRe-rFwbcqL=zLRLw@mail.gmail.com> <0A1F41E2-AC1E-4724-A8B6-DE855088FDF4@cisco.com> <1B89E943-C2D0-41C9-B8FE-17CA7F0240EA@cisco.com> <CAEFuwkg_dg2ASfjqzo1_MAfOHh+HB6jLecftFgRh0wTaYRJgYA@mail.gmail.com>
In-Reply-To: <CAEFuwkg_dg2ASfjqzo1_MAfOHh+HB6jLecftFgRh0wTaYRJgYA@mail.gmail.com>
From: Pushpasis Sarkar <pushpasis.ietf@gmail.com>
Date: Thu, 10 Oct 2019 12:15:24 +0530
Message-ID: <CAEFuwkhuP4J_1RHNU-JyUReE8ZTLZgendPivHL4zHGOszXkaEw@mail.gmail.com>
To: "Acee Lindem (acee)" <acee@cisco.com>
Cc: "YADLAPALLI, CHAITANYA" <cy098d@att.com>, "lsvr@ietf.org" <lsvr@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b56db0059488bf9a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsvr/3VcuPHsD6VIW69z3whl5YCZ6W5w>
Subject: Re: [Lsvr] Mail regarding draft-ietf-lsvr-bgp-spf
X-BeenThere: lsvr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Vector Routing <lsvr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsvr>, <mailto:lsvr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsvr/>
List-Post: <mailto:lsvr@ietf.org>
List-Help: <mailto:lsvr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsvr>, <mailto:lsvr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Oct 2019 06:45:41 -0000

*Hi Acee, *

*Needed one more clarification  below.*

On Wed, Oct 2, 2019 at 1:03 AM Pushpasis Sarkar <pushpasis.ietf@gmail.com>;
wrote:

> Hi Acee,
>
> Just saw the latest version of the draft. I wanted to understand what is
> the exact difference between the values 1 and 2. Just to clarify my doubt
> let's consider a prefix P that is only originated by node N. Now what will
> be the reachability of prefix P in the two scenarios (first with SPF Status
> TLV value set to 1 vs with SPF Status TLV value set to 2). Will P be
> unreachable in both cases? My understanding is it should still be reachable
> when the value is set to 2.
>
> If my understanding is correct, then perhaps we need more clarifications
> on the following text.. especially for the case there is no next link from
> this node.
>
> "If the current Node NLRI attributes includes the SPF status
>
>           TLV (Section 4.1.2) and the status indicates that the Node
>
>           doesn't support transit, the next link for the current node is
>           processed."
>
*[Pushpasis] This condition applies to all the links originating from this
current node NLRI. So does it mean none of the links origination from the
current node will be processed? If so, the last statement ("the next link
for the current node is processed") part is misleading. We can perhaps
re-work to avoid processing any of the links from the current node NLRI
under such scenario in a different step between step 4 and step 5.*

*Thanks*
*-Pushpasis*


> If the P is unreachable in the later case too (value set to 2), then I
> don't see what is the difference between using the values 1 and 2.
>
> Thanks
> -Pushpasis
>
>
>
>
>
>
> On Sun, Sep 29, 2019 at 12:15 PM Acee Lindem (acee) <acee@cisco.com>;
> wrote:
>
>> After discussion with my co-authors and Pushpasis, we are planning on
>> defining an SPF Status TLV for the Node Attribute NLRI analogous to the one
>> defined for Links and Prefixes. However, for the Node Attribute TLV, the
>> status would have an additional value indicating the node should not be
>> used for transit traffic.
>>
>>
>>
>>                           0 – Reserved
>>
>>                           1 – Node unreachable with respect to BGP SPF
>>
>>                           2 – Node does not support transit with respect
>> to BGP SPF
>>
>>                   3-254 – Undefined
>>
>>                       255 – Reserved
>>
>>
>>
>> Comments?
>>
>>
>>
>> Thanks,
>>
>> Acee
>>
>>
>>
>>
>>
>> *From: *Lsvr <lsvr-bounces@ietf.org>; on behalf of Acee Lindem <
>> acee@cisco.com>;
>> *Date: *Thursday, September 26, 2019 at 10:15 AM
>> *To: *Pushpasis Sarkar <pushpasis.ietf@gmail.com>;
>> *Cc: *"YADLAPALLI, CHAITANYA" <cy098d@att.com>;, "lsvr@ietf.org"; <
>> lsvr@ietf.org>;
>> *Subject: *Re: [Lsvr] Mail regarding draft-ietf-lsvr-bgp-spf
>>
>>
>>
>> Hi Pushpasis,
>>
>> This OSPFv3 R Bit and IS-IS O bit are basically the same functionality.
>> The node is not used for transit but is used for local prefixes.
>>
>> Thanks,
>>
>> Acee
>>
>>
>>
>> *From: *Pushpasis Sarkar <pushpasis.ietf@gmail.com>;
>> *Date: *Thursday, September 26, 2019 at 2:53 AM
>> *To: *Acee Lindem <acee@cisco.com>;
>> *Cc: *"YADLAPALLI, CHAITANYA" <cy098d@att.com>;, "lsvr@ietf.org"; <
>> lsvr@ietf.org>;
>> *Subject: *Re: [Lsvr] Mail regarding draft-ietf-lsvr-bgp-spf
>>
>>
>>
>> Hi Chaitanya and Acee,
>>
>>
>>
>> How about the 'O' bit in Node-Flag-Bits TLV defined in RFC 7752 section
>> 3.3.1.1? I suppose the node can set the 'O' bit when it wants to take
>> itself out from all transit paths. I know the 'O' bit is more related to
>> the scenario when ISIS topology is being exported in BGP-LS. But I suppose
>> we can use that for BGP-LS-SPF as well.
>>
>>
>>
>> Thanks
>>
>> -Pushpasis
>>
>>
>>
>> On Tue, Sep 24, 2019 at 8:35 PM Acee Lindem (acee) <acee@cisco.com>;
>> wrote:
>>
>> Hi Chaitanya,
>>
>> I think this is a good idea and will discuss with my co-authors.
>>
>> Thanks,
>> Acee
>>
>>
>>
>> *From: *"YADLAPALLI, CHAITANYA" <cy098d@att.com>;
>> *Date: *Tuesday, September 24, 2019 at 11:02 AM
>> *To: *Acee Lindem <acee@cisco.com>;, "lsvr@ietf.org"; <lsvr@ietf.org>;
>> *Subject: *RE: [Lsvr] Mail regarding draft-ietf-lsvr-bgp-spf
>>
>>
>>
>> Correct like a R-Bit.
>>
>>
>>
>> I have read this draft and I support it.
>>
>>
>>
>> Thanks,
>>
>> Chaitanya
>>
>>
>>
>>
>>
>> This communication may contain information that is privileged, or
>> confidential. If you are not the intended recipient, please note that any
>> dissemination, distribution or copying of this communication is strictly
>> prohibited.  Anyone who receives this message in error should notify the
>> sender immediately by telephone or by return e-mail and delete it from his
>> or her computer.
>>
>>
>>
>>
>>
>>
>>
>> *From:* Acee Lindem (acee) <acee@cisco.com>;
>> *Sent:* Tuesday, September 24, 2019 10:42 AM
>> *To:* YADLAPALLI, CHAITANYA <cy098d@att.com>;; lsvr@ietf.org
>> *Subject:* Re: [Lsvr] Mail regarding draft-ietf-lsvr-bgp-spf
>>
>>
>>
>> Hi Chaitanya,
>>
>>
>>
>> Exactly what do you mean by node cost out and what use case are you
>> trying to satisfy. If a node wants to remove itself from the topology, it
>> can simply withdraw its link NLRI. However, are you looking for a mechanism
>> similar to the OSPFv3 R-Bit as a Node NLRI SPF Attribute?
>>
>>
>>
>>    R-bit
>>
>>       This bit (the `Router' bit) indicates whether the originator is an
>>
>>       active router.  If the router bit is clear, then routes that
>>
>>       transit the advertising node cannot be computed.  Clearing the
>>
>>       router bit would be appropriate for a multi-homed host that wants
>>
>>       to participate in routing, but does not want to forward non-
>>
>>       locally addressed packets.
>>
>>
>>
>> Thanks,
>> Acee
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *From: *Lsvr <lsvr-bounces@ietf.org>; on behalf of "YADLAPALLI,
>> CHAITANYA" <cy098d@att.com>;
>> *Date: *Tuesday, September 24, 2019 at 10:31 AM
>> *To: *"lsvr@ietf.org"; <lsvr@ietf.org>;
>> *Subject: *[Lsvr] Mail regarding draft-ietf-lsvr-bgp-spf
>>
>>
>>
>> Hi Authors,
>>
>> The draft does not explicitly call out mechanisms for node cost out. It
>> would be good to call out mechanisms to cost out a node explicitly.
>>
>>
>>
>> Thanks,
>>
>> Chaitanya
>>
>>
>>
>>
>>
>> *Chaitanya Yadlapalli*
>>
>> Network Infrastructure And Services
>>
>>
>>
>> *AT&T Services, Inc.*
>>
>> 200 S Laurel Ave, Middletown, NJ 07722
>>
>> o  732.420.7977  |  cy098d@att.com
>>
>>
>>
>> This communication may contain information that is privileged, or
>> confidential. If you are not the intended recipient, please note that any
>> dissemination, distribution or copying of this communication is strictly
>> prohibited.  Anyone who receives this message in error should notify the
>> sender immediately by telephone or by return e-mail and delete it from his
>> or her computer.
>>
>>
>>
>>
>>
>> _______________________________________________
>> Lsvr mailing list
>> Lsvr@ietf.org
>> https://www.ietf.org/mailman/listinfo/lsvr
>>
>>