Re: [Lsr] AD Review of draft-ietf-lsr-isis-srv6-extensions-11

Alvaro Retana <aretana.ietf@gmail.com> Tue, 16 March 2021 20:34 UTC

Return-Path: <aretana.ietf@gmail.com>
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 9648F3A0D55; Tue, 16 Mar 2021 13:34:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 STHnVObC_5mR; Tue, 16 Mar 2021 13:33:59 -0700 (PDT)
Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com [IPv6:2a00:1450:4864:20::62b]) (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 771113A0D52; Tue, 16 Mar 2021 13:33:59 -0700 (PDT)
Received: by mail-ej1-x62b.google.com with SMTP id c10so74300509ejx.9; Tue, 16 Mar 2021 13:33:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc:content-transfer-encoding; bh=NTPkdSdFkUb+R6s47q+ZclKIJLos3CeeQnKm6s+5Apw=; b=nUWYbhUFPZbLKJOPnjTwXv31tdQ+q5NqEU05ropTUhr7ujRE0nw/TkY4OP6CjlEWnB 2gmBlYRpVxq5ePqQ0wAcoMAoi9AFyynQsbrsLRfgFoxwhagvh4LGV267bmD7snLMMs97 KQchQ+VGxMNbw8XEbSGQLoicWCiPYQNfxclu3nIVc0TEEvVH5kH2jThMbNCOTpGjDvE+ arm0PjF9or61PBAULVcgV3iQ56gTAZYRFfDChEZ39wpug7yGf5b/Wpnl17+Yl3x3Nyqz kXEadJOaViN6T8Hhqw6ooY6AT498Xh21+HeB0dOEQtXjPQlW1jcaIWRsYAeIftFxOwC0 89fw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc:content-transfer-encoding; bh=NTPkdSdFkUb+R6s47q+ZclKIJLos3CeeQnKm6s+5Apw=; b=f93SYaincI/CcQFgBTisOVoKLW3x9o97JTSMKP1fyMOjQt6z3ATShMesm0RaizmFQx L+I0WXxu/VHrM05GtFqM+FtUO0uHDJtt/ifsbVsZsEsHoo9+/D+uQlaQ+YpdfiDOGbbK cSVT4cJle/9YuvOuC9+IU4RMtPn8TRl8vIq1xpotjhwB+ofMmwW+Q7O/fMTP0zzypzTe v8HKVH7fFg/npnk4y1FfKuq1SiyM3YEMDGqyT0bw1dbOMMkxutYsbqrKK/yRDssTbNRF 746za5lrr8EfUM1zzhmCFgLbDI0qeZ9DK0/7cmIQGw44cTtpnCYrwELHjq208gVshyhG XjEw==
X-Gm-Message-State: AOAM5332Npx+rJ0McWkIM5BIDk2t2DqJF1I29Nuv0MbSZe4ua6y0KtJW umqa4LvrVzjA+CbO4Q9CvFhvFu0wdu6Pu5QYcRM=
X-Google-Smtp-Source: ABdhPJzo3CpaXonn9BDt5iHngNR4KNWZQdgvbTF3kuRwLCSeafMxUIC1RROOVUwQCRMrUXDo6rlfPXhvZyAQgpNMMi8=
X-Received: by 2002:a17:907:20f5:: with SMTP id rh21mr31584416ejb.27.1615926835691; Tue, 16 Mar 2021 13:33:55 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 16 Mar 2021 13:33:55 -0700
From: Alvaro Retana <aretana.ietf@gmail.com>
In-Reply-To: <836ca254-1273-7339-4c7d-f92d5e17315f@cisco.com>
References: <CAMMESswF4GiLTRAYeLfhkC4w9tsr2J5YaMNFSG=979Bh2tmULw@mail.gmail.com> <836ca254-1273-7339-4c7d-f92d5e17315f@cisco.com>
MIME-Version: 1.0
Date: Tue, 16 Mar 2021 13:33:54 -0700
Message-ID: <CAMMESszNithwE6cGy9pkyb7Zxso=BTqwyO9oza-Ascz-5dU=jg@mail.gmail.com>
To: Peter Psenak <ppsenak@cisco.com>, draft-ietf-lsr-isis-srv6-extensions@ietf.org
Cc: John Scudder <jgs@juniper.net>, "lsr-chairs@ietf.org" <lsr-chairs@ietf.org>, lsr@ietf.org, Christian Hopps <chopps@chopps.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/ni0GPWy9mDfK2bZRFHDFmeIJPVM>
Subject: Re: [Lsr] AD Review of draft-ietf-lsr-isis-srv6-extensions-11
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: Tue, 16 Mar 2021 20:34:02 -0000

On March 11, 2021 at 5:46:51 AM, Peter Psenak wrote:


Peter:

Hi!

> thanks for the review, please see inline (##PP):

It looks like you didn't get the whole review (Outlook bug).  Take a
look at it here:
https://mailarchive.ietf.org/arch/msg/lsr/a4a4I4fP73DyfKsdKnRw_tRuStQ/



...
> > Just one high-level comment: It is not clear to me why all the
> > behaviors from rfc8986 are not covered in this document. If some are
> > not applicable, or are covered elsewhere, please explain in the text.
>
> ##PP
> not all behaviors from rfc8986 are applicable to IGPs. Section 10
> ("Advertising Endpoint Behaviors") lists the ones that are applicable to
> ISIS.

I understand that -- other readers may not.

Also, §8.1/rfc8986 talks about what is expected to be carried in the
IGP.  End.T is not included in this document.


...
> > 148 2. SRv6 Capabilities sub-TLV
> >
> > 150 A node indicates that it supports the SR Segment Endpoint Node
> > 151 functionality as specified in [RFC8754] by advertising a new SRv6
> > 152 Capabilities sub-TLV of the router capabilities TLV [RFC7981].
...
> > [minor] "router capabilities TLV [RFC7981]" What should be the
> > flooding scope of the TLV that includes this new sub-TLV?
>
> ##PP
> It's up to the originator to set the S bit or not. We are not limiting
> it here.

But if the originator doesn't set the correct flooding scope then the
information will not make it to where is has to.  I would like to see
some guidance on the setting of the bit -- I'm assuming that most of
the cases require the S bit to be set, right?


...
> > 200 4.1. Maximum Segments Left MSD Type
...
> > 208 If no value is advertised the supported value is assumed to be 0.
> >
> > [major] What exactly does this MSD type signal? Is this the
> > expectation that the SL will be <= the value when received at the
> > advertiser? Is there an example of its use? I'm having a hard time
> > picturing when (for non PSP behaviors) the SL would be more than 0.
> >
>
> ##PP
>
> Yes, you are correct. As described in the paragraph right above it, this
> MSD type specifies what is the maximum value of the "Segments Left"
> field in the received SRH that this node is capable of processing.
> A simple example: an ingress PE encapsulates a packet with a new IPv6
> and SRH. The SRH contains three segments. The Segments Left value of
> that SRH is set as per RFC8754 4.1, which in this case is equal to 2.
> The router processing the first segment in the segment list, must
> support as a minimum an SRH Max SL MSD value of 2 in order to be able to
> process such packet.

I see.  It would be very nice if the text said somewhere that the MSD
applies not just to the final endpoint but also to intermediate nodes.


...
> > 252 5. SRv6 SIDs and Reachability
...
> > 280 In cases where a locator advertisement is received in both a Prefix
> > 281 Reachability TLV and an SRv6 Locator TLV, the Prefix Reachability
> > 282 advertisement MUST be preferred when installing entries in the
> > 283 forwarding plane. This is to prevent inconsistent forwarding entries
> > 284 between SRv6 capable and SRv6 incapable routers.
...
> > [major] "locator advertisement is received in both a Prefix
> > Reachability TLV and an SRv6 Locator TLV" What information results in
> > these being an advertisement for the same locator? Is only the
> > locator (prefix length, etc.) considered, or should the algorithm,
> > metric, etc. also match?
>
> ##PP
> it's just prefix/mask. I added some text to clarify that.

So...even if the MT-ID and algorithms are different, the
advertisements are considered the same?   I don't have a specific case
right now, but it sounds to me that this could result in some type of
incongruency.   I'll think more about this later -- no further action
needed.


...
> > [major] The SRv6 Locator TLV is a new TLV. If no Prefix Reachability
> > TLVs are present, how should the new TLV be used for route
> > calculation/installation? The text above suggests its use, but there
> > is no specification.
>
> #PP
> The locator TLV advertises the prefix, same way as the Prefix
> Reachability. The calculation and installation of the prefix
> reachability is equal to what is done for regular Prefix Reachability.
> I added the following text to one of the above paragraphs:
>
> "The processing of the prefix advertised in the SRv6 Locator TLV,
> the calculation of its reachability and the installation in the
> forwarding plane is similar to one used for Prefix Reachability TLV (236
> or 237)."

s/is similar to one used for Prefix Reachability TLV (236 or
237)./follows the process defined for the Prefix Reachability TLV (236
or 237) [rfc5308].

Would that be ok?



> > 291 SRv6 SIDs are not directly routable and MUST NOT be installed in the
> > 292 forwarding plane. Reachability to SRv6 SIDs depends upon the
> > 293 existence of a covering locator.
> >
> > [major] "MUST NOT be installed" This action depends on how the SIDs
> > are advertised. For example, if they are included in a Prefix
> > Reachability TLV then the receiver will install them. IOW, this
> > action should be specified from the point of view of the sender;
>
> ##PP
> This section talks about received SRv6 SIDs, not locators. SIDs are not
> advertised in Prefix Reachability TLV. Remote SIDs are never installed
> in the forwarding.
>
> I updated the text to say "SRv6 SIDs received from other nodes..."
>
> for
> > example, "SIDs MUST be advertised in the sub-TLVs...[or maybe]...MUST
> > NOT be advertised in another TLV...".
>
> ##PP
> the previous section talks about how SIDs are advertised, which is the
> only way.

Just to make sure we're talking about the same thing.  The SIDs are
covered by the LOC, which is routable, installed in the RIB/FIB, etc.

There's nothing in this document or rfc8986 that prevents a SID to
have the same value as the IP address on a link (see below).  Then
that link address could be advertised using normal (non-SR-related)
mechanisms.

In this case, the receiver would know the address is also a SID.
Should that result in "MUST NOT be installed"?   Not even the MUSTs
that I suggested could prevent this situation.


> > [major] If some SIDs are advertised as "sub-TLVs in TLVs 22, 23, 222,
> > 223, and 141", how can the "MUST NOT be installed" be satisfied?
>
> ##PP
> above is the only way how SIDs are advertised.

This is the text from -11:

   SRv6 SIDs are advertised as sub-TLVs in the SRv6 Locator TLV except
   for SRv6 End.X SIDs/LAN End.X SIDs which are associated with a
   specific Neighbor/Link and are therefore advertised as sub-TLVs in
   TLVs 22, 23, 222, 223, and 141.

   SRv6 SIDs are not directly routable and MUST NOT be installed in the
   forwarding plane.  Reachability to SRv6 SIDs depends upon the
   existence of a covering locator.

The text says that there is more than one way to advertise SIDs, *and*
that they "MUST NOT be installed".


Thanks!

Alvaro.