IETF Logo Mail Archive

Re: [Lsr] Reg Question regarding ietf-lsr-igp-ureach-prefix-announce

Peter Psenak <ppsenak@cisco.com> Fri, 22 March 2024 13:29 UTC

Return-Path: <ppsenak@cisco.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 5DF3CC1D5C49 for <lsr@ietfa.amsl.com>; Fri, 22 Mar 2024 06:29:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.597
X-Spam-Level:
X-Spam-Status: No, score=-9.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_HELO_PERMERROR=0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P3PaIPigSUkc for <lsr@ietfa.amsl.com>; Fri, 22 Mar 2024 06:28:57 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5D8AC1D4A9E for <lsr@ietf.org>; Fri, 22 Mar 2024 06:28:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.com; i=@cisco.com; l=5300; q=dns/txt; s=iport; t=1711114136; x=1712323736; h=message-id:date:mime-version:subject:to:references:from: in-reply-to; bh=ySw9DZy2OpLV3xepY3BYqDC4KRR7qwgFrLc4SNTn2D8=; b=f76we9P1aNAwWY4onseRXriwG6/IFVBQ2/etw9Ewa98QLryJ5W+/R/iW dArdQmfwO277Tcn7GRf/guPTgzMRK/we94WA/t/JOCRESoU2/GQo4Pbn7 B7ZoM55UtN4lN7XGajRpXIYVAgpqr77tTui9pO/iKIkPkv42aEYaFtkJA k=;
X-CSE-ConnectionGUID: otxFpLwuQYeFy8M6nmLN6g==
X-CSE-MsgGUID: EB7cgfw/Qsm+mN7cEUfKjQ==
X-IPAS-Result: A0AiAQDahv1llxbLJq1aHAEBAQEBAQcBARIBAQQEAQGCD4M1A1JCSIRViHyIPi0DlzaITw8BAQEPLgEKCwQBAYUGAogDJzgTAQIEAQEBAQMCAwEBAQEBAQEBBgEBBQEBAQIBBwUUAQEBAQEBAQE3BQ43hWwNhk4BAQEBAgEBASFLGwsYKgICJjAGARICAQGCfAGCPCMDEbA6eoEygQGzMoFkBoFIiCYBgVIChAUchDxCgUlEgRQoC4J4PoJhAQGFO4JoBIUhKZ9RVHkiA30IBFoNGxAeNxEQEw0DCG4dAjE6AwUDBDIKEgwLHwUSQgNDBkgLAwIaBQMDBIEsBQ0aAhAaBgwmAwMSSQIQFAM4AwMGAwoxLlNBDFADZB8xCTwPDBoCGxQNJCMCLD4DCQoQAhYDHRYEMBEJCyYDKgY2AhIMBgYGXCAHDwkEJQMIBAMrJwMgchEDBBoECwd2ggCBPQQTRAMQgTSFN4RkDIF9gTaBdymBEYMuAxkrHUACAQttPTUJCxsGIgEfozMMbgGDS1MvIQsgClkLAlKTU7IWhB2EbJxCBg8EL5dKkgFkkw2FUiCoXYF7Iy2BLjMaCBsVO4JnUhkPjjmIdYpmRTI7AgcBCgEBAwmKaAEB
IronPort-Data: A9a23:wiT6zaj9dA4etS7/0hB2p26dX161BxAKZh0ujC45NGQN5FlHY01je htvUTyFaKrfMWb9foolbIzl8UgA6sPcm4AyQQc6q382Q3hjpJueD7x1DKtf0wB+jyHnZBg6h ynLQoCYdKjYdleF+1H1dOCn9CEgvU2xbuKUIPbePSxsThNTRi4kiBZy88Y0mYcAbeKRW2thg vus5ZWAULOZ82QsaD5MsPjZ8EkHUMna4Vv0gHRvPZing3eG/5UlJMp3Db28KXL+Xr5VEoaSL woU5Ojklo9x105F5uKNyt4XQGVTKlLhFVTmZk5tZkSXqkMqShrefUoMHKF0hU9/011llj3qo TlHncTYpQwBZsUglAmBOvVVO3kWAEFIxFPICX+joeKL61LbSkrh7eQ+KR8wOKk+pOkiVAmi9 dRAQNwMRhmOnae9x6i2D7QqjcU4J86tN4Qa0p1i5WiGVrB9EdaZG/6Mv4UwMDQY3qiiGd7Gf 9EUbzNsRB/BeBZIfFwQDfrSmc/x3yOkLWMJ9jp5o4IayTfYwwJul4H2NZnQXIOBaPhbvUSh8 zeuE2PRWUxCa4fFllJp6EmEgvTVtSL2RIxUE6e3ntZph0Ge3WxVCRAKW3O0pPC4jgi1XNc3F qAP0iMjt+0z7EuxUpz7VgH+q3+ftRlaUN1VewEn1O2T4q3I8yiBIncZdw9MRs12kZEwQBgMi FDcyrsFGgdTmLGSTHuc8JKdojWzJTUZIAc+icksE1BtDz7L/ttbs/7fcuuPBpJZmfXTPVnNL 9G2QMoW2ul7YS0jjvnTEbX7b9SE/MehoukdvFy/Y45dxlklDLNJnqTxgbQh0d5OLZyCUn6Kt 2Uels6V4YgmVM7UzXTRHbVTTOj2vJ5p1QEwZ3YxRvHNEBzwqxaekXx4vVmS2W8wa5lUJ2W1C KMtkVwKvPe/w0dGnYcsPtruUJ51pUQRPd/kTfvTJsFfeYR8cRTP/SdlIyatM5PFziARfVUEE c7DK66EVC9CYYw+lWbeegvo+eJyrszI7TiIHs6TItXO+ef2WUN5vp9fbwPfMbhmtf/UyOgXm v4GX/a3J9xkeLWWSkHqHUQ7dDjm8VBT6UjKlvFq
IronPort-HdrOrdr: A9a23:ymoP2K1C6OFoB+ecYSu6vAqjBLckLtp133Aq2lEZdPUnSKylfq GV9sjzuiWZtN98YgBEpTnEAtjlfZq+z/FICOsqUItKNTOO0ACVxcNZnOnfKlbbehEWmNQttp uIP5IRNDU1ZmIK6/oTJ2KDYrEd/OU=
X-Talos-CUID: 9a23:7kfmu2g8d/JURK/rh8utIrBs9zJudWHN4m/0PFKBOGtHWe2wF1mV3IU6nJ87
X-Talos-MUID: 9a23:R6/sqAZJWx+8kOBTmhWzjz5sK4BR+KHtDWZSmrg7teqGDHkl
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="6.07,146,1708387200"; d="scan'208,217";a="11236696"
Received: from aer-iport-nat.cisco.com (HELO aer-core-5.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Mar 2024 13:28:54 +0000
Received: from [10.209.197.4] ([10.209.197.4]) by aer-core-5.cisco.com (8.15.2/8.15.2) with ESMTP id 42MDSsPq099044; Fri, 22 Mar 2024 13:28:54 GMT
Content-Type: multipart/alternative; boundary="------------C48zoU1umK4gs6dOC2jGtv7E"
Message-ID: <66ab7049-e899-4773-91aa-b3249ec3deab@cisco.com>
Date: Fri, 22 Mar 2024 14:28:54 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: Kotesh Chundu <kotesh.ietf@gmail.com>, lsr@ietf.org
References: <CAMJ2TteCrLCVkeM7ZSpG6-OdFswCnZw0w8ZYUs+3A4C+LrMYKA@mail.gmail.com>
From: Peter Psenak <ppsenak@cisco.com>
In-Reply-To: <CAMJ2TteCrLCVkeM7ZSpG6-OdFswCnZw0w8ZYUs+3A4C+LrMYKA@mail.gmail.com>
X-Outbound-SMTP-Client: 10.209.197.4, [10.209.197.4]
X-Outbound-Node: aer-core-5.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/qJUNAhAWHWKAXN6OBQL9v0bHPRU>
Subject: Re: [Lsr] Reg Question regarding ietf-lsr-igp-ureach-prefix-announce
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.39
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, 22 Mar 2024 13:29:02 -0000

Kotesh,

On 19/03/2024 12:44, Kotesh Chundu wrote:
> Hi,
>
>   I have one query regarding the following content from the IGP UPA draft.
>
> <snip>
> As UPA advertisements in IS-IS are advertised in existing Link State
>     PDUs (LSPs) and the unit of flooding in IS-IS is an LSP,*it is recommended that, when possible, UPAs are advertised in LSPs 
> dedicated to this type of advertisement. This will minimize the number 
> of LSPs which need to be updated when UPAs are advertised and withdrawn.*
> </snip>
> What is meant by LSPs dedicated to this type of advertisement in the 
> above highlighted text? My understanding is that we have only one ISIS 
> LSP for all the content. If a given LSP can not fit into one packet, 
> then it is put into multiple fragments.

a node can generate up to 255 LSPs in the L1 area, or in  L2 backbone. 
Sometimes these are referred to as fragments, but these are independent 
LSPs.


>
> Does it refer to some enhancement where UPA prefixes are separately 
> put into separate ISIS fragments dedicated for UPA prefixes? Or any 
> other enhancement where we define a separate LSP type for UPA? Can 
> somebody clarify this?

the recommendation is that UPAs may be sent in a separate LSP, because 
they are short lived. This avoids the receiving nodes to go over the 
unchanged content of the LSP, if UPAs are mixed with other information. 
Note that it is an optional behavior and is not needed for the UPA 
functionality.


thanks,
Peter

>
> Does any vendor support this kind of enhancement for UPA or any other 
> ISIS feature?
>
> Regards,
> Kotesh
>
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

v2.23.0 | Report a Bug | By Email