IETF Logo Mail Archive

Re: [spring] [Lsr] Adjacency SID and Passive Interface

Jeff Tantsura <jefftant.ietf@gmail.com> Fri, 10 May 2019 15:43 UTC

Return-Path: <jefftant.ietf@gmail.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ABCF12016D; Fri, 10 May 2019 08:43:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 XVQTICcnLeRz; Fri, 10 May 2019 08:43:08 -0700 (PDT)
Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0:4864:20::529]) (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 5F71B120139; Fri, 10 May 2019 08:43:08 -0700 (PDT)
Received: by mail-pg1-x529.google.com with SMTP id e6so3208468pgc.4; Fri, 10 May 2019 08:43:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=scuAFnkO2nAZsufBkQ+jT12qJgFL2rWlONdNFhw+NUA=; b=BsadeqAqIoZtk9OgW28aKDuXn142UnSEY/qpgsob9WDRxPIiVGITsyHEwJgBSamZNC /GdySRmyze609AB4zEwcmQPA74V7Cmtyr+i3hgv7YmH5RGje3ZmcXvOzxvcq1rlv2QNs cL8SraGV98YgBzTX/HaNUhYWNNr7YbO/mEnU7rRSgbzyv8Z0kVGAi3p9eMD5oz9SquUb XTVB0clql2ox5V/qn9+lyQ8iqtqKPETCyz1d+qkBxTIXeb4QKbZx1QGbRpomZVjj5O2v z+eTQq8gH40IueOY5eIWjZNPwyERZSJGfS3DdHyYbeSoIOD0hLkGD/fwrnXHhXRD+7FZ gjsQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=scuAFnkO2nAZsufBkQ+jT12qJgFL2rWlONdNFhw+NUA=; b=A4qamcCaQwRfrc5i2gfnPDJ7HeZFI09LZqI+kYk/sjPLhOgKnGG+55QiPHVb0gDCzw pqe6bZ+c3dHAnTR/G+TsSFHlB+FA9DcXYeAYg9uXZTlLSn2NA4lMIjP2Ih/+QYxLUntD QK53yuFdAepP5uyq4/znID+voDcwffLQcgeSXNLkdhiweenkPsmJXnlUvN4ID/KTpn3l bC8lcyEMuvLMGVJRSHYbRKtLLi+/1SlHn3823393AOnCbP+TGRGt1ctUxZ74kNP3GtMl YXXTneMyDYzy1iwAh7lwclwTBzBKXVsvpQqdKX0LkZq8GNxoAUUPd8Kqqon+xyOOmOI0 iY8w==
X-Gm-Message-State: APjAAAUGRFnbZcJNaWrXBS2usdtA1Nt35cvBAwxVE1LnqfI8foNJFjRP WP38M6wnR1K0ndWn89R1JE+3yDD5
X-Google-Smtp-Source: APXvYqzu/kY0tpEg+tYX86gOtj+tQig5lUw0zkZUhpZNRTU7abLztBK37ldEzCKsgDEt+qY8XC98Hw==
X-Received: by 2002:aa7:9203:: with SMTP id 3mr15244343pfo.123.1557502987468; Fri, 10 May 2019 08:43:07 -0700 (PDT)
Received: from [192.168.1.5] (c-73-189-13-44.hsd1.ca.comcast.net. [73.189.13.44]) by smtp.gmail.com with ESMTPSA id v40sm18161540pgn.17.2019.05.10.08.43.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 May 2019 08:43:06 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (1.0)
From: Jeff Tantsura <jefftant.ietf@gmail.com>
X-Mailer: iPhone Mail (16E227)
In-Reply-To: <SN6PR11MB28452557B301185C57C45134C10C0@SN6PR11MB2845.namprd11.prod.outlook.com>
Date: Fri, 10 May 2019 08:43:05 -0700
Cc: "Acee Lindem (acee)" <acee@cisco.com>, Christian Franke <chris@opensourcerouting.org>, "olivier.dugeon@orange.com" <olivier.dugeon@orange.com>, SPRING <spring@ietf.org>, LSR <lsr@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <965F65AB-48FF-4E0C-85DD-53B5A530D684@gmail.com>
References: <13318_1557475082_5CD52F0A_13318_76_1_e581409b-8272-9b7b-df11-941f4325413d@orange.com> <e78e6735-059c-a563-d657-244696b904ff@opensourcerouting.org> <55B16264-3C65-4D4A-B9E1-5BA406FE64FA@cisco.com> <SN6PR11MB28452557B301185C57C45134C10C0@SN6PR11MB2845.namprd11.prod.outlook.com>
To: "Ketan Talaulikar (ketant)" <ketant@cisco.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/oMCKn78gRtvYIXCsfE4-9OHfwi4>
Subject: Re: [spring] [Lsr] Adjacency SID and Passive Interface
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 May 2019 15:43:12 -0000

+1

Regards,
Jeff

> On May 10, 2019, at 05:22, Ketan Talaulikar (ketant) <ketant@cisco.com> wrote:
> 
> +1
> 
> Hi Oliver,
> 
> Technically Adj-SID refers to an IGP adjacency between two nodes as per RFC8402 semantics. I don't think a passive (stub) link falls under that category. It would be better to define a passive link separately (somewhat on lines of what was done for inter-AS TE) so that it does not get mixed up with the classical IGP links. I would think a new draft would be apt for such an extension.
> 
> Thanks,
> Ketan
> 
> -----Original Message-----
> From: Lsr <lsr-bounces@ietf.org> On Behalf Of Acee Lindem (acee)
> Sent: 10 May 2019 17:39
> To: Christian Franke <chris@opensourcerouting.org>; olivier.dugeon@orange.com; SPRING <spring@ietf.org>; LSR <lsr@ietf.org>
> Subject: Re: [Lsr] Adjacency SID and Passive Interface
> 
> Hi Chris, Olivier, 
> 
> On 5/10/19, 4:41 AM, "Lsr on behalf of Christian Franke" <lsr-bounces@ietf.org on behalf of chris@opensourcerouting.org> wrote:
> 
>>    On 5/10/19 9:58 AM, olivier.dugeon@orange.com wrote:
>> In the current state of Segment Routing drafts, do you think it is possible to advertise
>> Adjacency SID on such passive or inter-domain interfaces or do we need to specify this behaviour
>> in a new draft ?
>> 
>> For me I don't see anything in the drafts that prohibits this kind of advertisement, but perhaps I'm wrong.
> 
>    My understanding is that the SID is specific to an adjacency and
>    advertised in IS-IS in either TLV 22, 222, 23, 223.
> 
>    As adjacencies will not be formed on a passive interface, an adjacency
>    SID should not be advertised for the passive interface.
> 
> I agree with Chris. We shouldn't reuse the existing Adj-SID when there will never be an adjacency and the current semantics require this. If we need advertisement of SIDs for passive interfaces, it would definitely be a new draft that clearly articulates the use case and designates a new type of SID that has different semantics. Also note that while passive interfaces are very useful in order to include a stub network in the topologies, they are not part of the OSPF specifications. I haven't done an exhaustive search on IS-IS. 
> 
> Thanks,
> Acee
> 
> 
>    I might also be wrong here, though.
> 
>    All Best,
>    Chris
> 
>    _______________________________________________
>    Lsr mailing list
>    Lsr@ietf.org
>    https://www.ietf.org/mailman/listinfo/lsr
> 
> 
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

v2.23.0 | Report a Bug | By Email