Re: [RTG-DIR] Routing Directorate Early Review of draft-li-arch-sat-04.txt - "A Routing Architecture for Satellite Networks"

Tony Li <tony.li@tony.li> Fri, 09 February 2024 17:55 UTC

Return-Path: <tony1athome@gmail.com>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21D1AC14F698 for <rtg-dir@ietfa.amsl.com>; Fri, 9 Feb 2024 09:55:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.508
X-Spam-Level:
X-Spam-Status: No, score=-6.508 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6pRnf6nnPZOT for <rtg-dir@ietfa.amsl.com>; Fri, 9 Feb 2024 09:55:02 -0800 (PST)
Received: from mail-pf1-x432.google.com (mail-pf1-x432.google.com [IPv6:2607:f8b0:4864:20::432]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9E46C14F61F for <rtg-dir@ietf.org>; Fri, 9 Feb 2024 09:55:02 -0800 (PST)
Received: by mail-pf1-x432.google.com with SMTP id d2e1a72fcca58-6e09ea155c5so316180b3a.2 for <rtg-dir@ietf.org>; Fri, 09 Feb 2024 09:55:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1707501302; x=1708106102; darn=ietf.org; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:sender:from:to:cc:subject:date:message-id:reply-to; bh=XxZ2G0232p5IOM2kzqvZPb2H1r6lN9FGGl5yZGMw6oM=; b=AD/TjM3v0F3a5c/696vX/q/QN2/pGh0Hm6JTm0mm9Adx8JZaFbI1EGOPaz1IiebhGa lIRO4+SrbgnAZRZm37W02QMInuMMOY3x2imGLq75/Wvv0DszFS0URDhOKtQfVHF7ml91 VZt0kjPeoqAWbcoQHC0xwUXojZPVUsxMdkJtAdDEWs46MOyRFW7adnt3jNz/MNekTy/1 b8iygeTq3q82RPshqz2r1F011a0kQDZ9TnwIBnnZhI0mnEJw+og34TCnqb9mZHFdD4z4 LqnFc4hkZAUvj5z57T1Ro49fvRNl/Cle1X/sRs2M0Pqls3QQtJrUzpaPRxlOUqPv6VEZ 8fRw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707501302; x=1708106102; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=XxZ2G0232p5IOM2kzqvZPb2H1r6lN9FGGl5yZGMw6oM=; b=F/pnNMtaWMfmR8MD0LOB/gPdPFFlnCTpLfyPU+x6zPATTX4CodYjALGh1g6WHj7ZWD Mk2RX/uyBGNgUC8is2alv7a5+Nn2djUQ4qMly5Fs5XWG5ZwXhC2qRreOreZzXECAGUYV gOz16ZYHzYYflPL1otpmq7hC7QnYh/gHWZsXjPi3uObbhlkTMVYGKFrtGfegTt0kU2v1 E4VewxNveR2zSUQSR8y0Fnm8rI/W36ngM9PgK4tTSResLMQcEEsogynMvHh8roxVJXcl pohRAYlDIBu+V9td5j3Zk+88f7x2B8wKG4MJFotBIp0WBfocmLAOLnm3rYLhNYZnoqOV r2Bg==
X-Gm-Message-State: AOJu0YzSQvRKUace/E7YUXcuJqRVU7RdlbpWSYnri0MTjcCBquEB0Y+E Cp67f4oUxmiNf8X622ZwQLfBWNHKw3DZ7qV4srgDGpir7j84C5ir
X-Google-Smtp-Source: AGHT+IEzHxUnuqauxhvgF3OqnHzeO5LRa5EU2ZdDjJ0BCqfLJGV70EFiru6NJycbHUMDhJVYFPn7Gg==
X-Received: by 2002:a05:6a20:d044:b0:19c:a48b:300a with SMTP id hv4-20020a056a20d04400b0019ca48b300amr2359157pzb.37.1707501302054; Fri, 09 Feb 2024 09:55:02 -0800 (PST)
X-Forwarded-Encrypted: i=1; AJvYcCWl8f3A+Z4uQert+VTVqWTUZ3JkfodJBRULQHr1Y309zYJgkiJ2fYWACzNWlWbqGlG+GPCWmXN0b8ch+b8=
Received: from smtpclient.apple (c-73-158-206-100.hsd1.ca.comcast.net. [73.158.206.100]) by smtp.gmail.com with ESMTPSA id o20-20020a056a001b5400b006e051fcc0f4sm808189pfv.47.2024.02.09.09.55.01 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Feb 2024 09:55:01 -0800 (PST)
Sender: Tony Li <tony1athome@gmail.com>
From: Tony Li <tony.li@tony.li>
Message-Id: <B00EEF02-3E2B-4B50-AB29-F5C67F361FCF@tony.li>
Content-Type: multipart/alternative; boundary="Apple-Mail=_A42EFF4D-A086-449E-85CF-E15D7AE4FA18"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.400.31\))
Date: Fri, 09 Feb 2024 09:54:50 -0800
In-Reply-To: <9DCE375B-8676-4CAE-86D7-A056AB982ABA@gmail.com>
Cc: Routing Directorate <rtg-dir@ietf.org>, Eliot Lear <lear@lear.ch>
To: Acee Lindem <acee.ietf@gmail.com>
References: <ADC1D0F8-C1FF-4B61-A8EC-6C97196B1223@gmail.com> <FA0CA27A-DBBB-4ACF-9CD4-6F292052601D@tony.li> <1C5E0F5F-2F1A-46C2-BD22-52643081C349@gmail.com> <C0453869-6B6F-45AB-8993-2B11594506D0@tony.li> <9DCE375B-8676-4CAE-86D7-A056AB982ABA@gmail.com>
X-Mailer: Apple Mail (2.3774.400.31)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/zU7qQN13oby8nfJweQdyhn2p8D8>
Subject: Re: [RTG-DIR] Routing Directorate Early Review of draft-li-arch-sat-04.txt - "A Routing Architecture for Satellite Networks"
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Feb 2024 17:55:04 -0000

Hi Acee,


> I think I understand what you are saying. An IS-IS L1L2 adjacency provides  a more natural way for an L1 area to provide transit for inter-area traffic. In OSPF, you’d need to use virtual links. 


Exactly.


>> Ah. The distinction here is that I’m assuming that the overall connectedness of the stripe is stable, not that any given ISL is stable.  I think I can clarify this a bit.
> 
> That would be good - you’re saying that the stripe is designed such that the probability of the L1 area partitioning is very low even though there will be inter-area link changes. 


Exactly.


>> As stated, each inter-area L2 adjacency should be listed.  So if an inter-area link changes, both of the proxy LSPs that are relevant for that link would change.  Again, this seems tolerable.
> 
> Ok - I guess the L2 link costs stay constant independent of L1 area  changes? 


Yes.  At this point, you’ll observe that this effectively makes the L2 metric for any area 0.  This is absolutely correct. In this architecture, this isn’t an issue as we’re doing everything by traffic engineering anyways.


> No - I think it is valuable. I was just suggesting to explain why this is the case. 


Ok, I will try to do that.

Tony