[Lsr] Q&A for OSPF Transport Instance
Yingzhen Qu <yingzhen.ietf@gmail.com> Mon, 24 May 2021 21:46 UTC
Return-Path: <yingzhen.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 A7B823A0C17 for <lsr@ietfa.amsl.com>; Mon, 24 May 2021 14:46:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, 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 HVuD-WplFlSN for <lsr@ietfa.amsl.com>; Mon, 24 May 2021 14:46:35 -0700 (PDT)
Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0:4864:20::42b]) (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 14F283A0C06 for <lsr@ietf.org>; Mon, 24 May 2021 14:46:34 -0700 (PDT)
Received: by mail-pf1-x42b.google.com with SMTP id c17so21951418pfn.6 for <lsr@ietf.org>; Mon, 24 May 2021 14:46:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=CVmAutGZ1mM2E5IGAljbeZPszdeDuHovLwdCIAr1Ux4=; b=UwFfkxEMnFCkb2wVgJIObPjbOG9xlBIAms4DgJJEE9cMFFt0Yh9XhZVIP9o2sYThc1 FZw6gxa112LQV2GdsdCs02lvOlJEm7fekGSw0rQnD9xc9eMNAujPtVxDN4tfgQ9Uy4gD W1uRAaoPXAM7ElFduI1HRmrTof3TN0zzqQ06n0q8B4ipfS6E6Hz/h4GL9J3DeKCPMVm5 zUQ7RY85h+KLknvX9cTCCJeUPJ3JGc+swoqgYDj++CNGX+cUL8qbWlVs4gZvZxRDHs7G XiE/w+tYfozuuCKMMryH3oq5Oa84tHfRY3EqyEpLYa6LN/dsUgxTrkT6MMjYMASr3pqn bPvg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=CVmAutGZ1mM2E5IGAljbeZPszdeDuHovLwdCIAr1Ux4=; b=SZCKbXI9sMUvaQwe32RHK+Sc2wpCn3yJDZTCz0X8D+cneqr2qBfF1fXXh1mp0P/cQR fYcP77Q+kCgj6ILwBGcSYxgo8JYq6pDdmm/a/Iqdaxn58H4xccJwZ4O8UeP79nq7goo0 NrQTE/7i126hkV5sMTWJygbdaVT9A0JKmXS3Z3TPfjbOgqP6GIh1g681z0lar4F/1gTq 9DS6IUBEXrrYK59zXV2OQAFBPmcBUqAHR+9B9kfrKNwyq/Cs9B/Ioz9JdKjBKifTkN7c OSJ3hWHx0bpqCSXRP5nj+LNBog5ktA6AJPrbMy0tqBFQ/990o08BiyQ1sQfH81M32YCg e1lg==
X-Gm-Message-State: AOAM531B9cMNx+4hWn/sAeH+QfYRWUByxAZCVBCZZGBLrSjor+p3gcWh ou4lXHwOzyX4k8j8JX0fYxQg11Tbylcf
X-Google-Smtp-Source: ABdhPJwveiufS6t8xRH0JCoQRnNZCBmlLVLaXyAhQx0QnjAZeq7O3NwW8o30U1ZTZ05apmcJSJ+hig==
X-Received: by 2002:a63:4553:: with SMTP id u19mr15515903pgk.323.1621892793324; Mon, 24 May 2021 14:46:33 -0700 (PDT)
Received: from ?IPv6:2601:646:9702:c61:4d06:d018:9e56:c1b5? ([2601:646:9702:c61:4d06:d018:9e56:c1b5]) by smtp.gmail.com with ESMTPSA id c7sm12319496pga.4.2021.05.24.14.46.32 for <lsr@ietf.org> (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 24 May 2021 14:46:32 -0700 (PDT)
From: Yingzhen Qu <yingzhen.ietf@gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\))
Message-Id: <794DE862-CCA1-4263-BD90-B44DB9DCA679@gmail.com>
Date: Mon, 24 May 2021 14:46:31 -0700
To: lsr@ietf.org
X-Mailer: Apple Mail (2.3654.40.0.2.32)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/_v2JY_k1L8CiO2jKLavpcVeBYWc>
Subject: [Lsr] Q&A for OSPF Transport Instance
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: Mon, 24 May 2021 21:46:40 -0000
Hi, On behalf of co-authors, thanks for the support of WG adoption of this draft. There were some questions asked, and we’ve compiled them together into this Q&A. Comments and questions are welcome. Thanks, Yingzhen Q: In section 4.3 of this draft, it says: "The OSPF transport instance is not dependent on any other OSPF instance. It does, however, have much of the same as topology information must be advertised to satisfy the "condition of reachability". Then, this transport instance should also advertise the topology information. Right? But in section 4.5, the advertisement of inter-area information is omitted(Summary-LSA for OSPFv2/inter-area-prefix-LSA for OSPFv3). So, how to transfer the non-routing information across different areas? Using the remote OSPF neighbor? A: OSPF transport instance is not dependent on any other OSPF instance. It’s possible that you run OSPF transport instance without regular OSPF instance. The topology information advertised by OSPF transport instance is to satisfy the "condition of reachability", not for routing table/RIB update. We'll clarify in OSPFv2 this will include the type-4 summaries related to the transport instance topology. Q: The reason that we use the IGP to transfer the non-routing information is that the IGP assures the reachability/dissemination of such information. Using independent transport instance, the operator need again the design and deployment of the distributed topology. And most important, the correlation between the routing information and non-routing information is not solved or covered within the current draft, which is the merit of other solutions. There should be solutions/considerations to the possible problem as that described in https://datatracker.ietf.org/doc/html/draft-bowers-lsr-isis-gen-info-clarifi cations-00 for IS-IS. A: The topology of OSPF transport instance may or may not be the same as the regular OSPF instance, and it's up to the applications that uses OSPF transport instance. The support of sparse topology and remote neighbor makes it possible for only some routers in the network get the application info. It is expected the applications in the transport instance will advertise non-routing information and, hence, there will be no requirement for correlation between route routing and non-routing instance. Q: Section 4.7 described the "Non-Routing Sparse Topologies". It requires again the careful design and deployment. Is it more straightforward to let the IGP routers relay such information and only the necessary nodes to store/utilize it? A: As mentioned above, sparse topologies make it possible for only routers interested in certain applications get involved, and this doesn't impact other routes and routing calculations in regular OSPF instance. I don't understand your suggestion of only necessary nodes to store/utilize it. This seems not consistent with the idea of link state protocol. Q: Add a section on how to advertise information in a transport instance if an application requires, per-link resource information to be advertised in transport instance. A: This is dependent on the application and while it may be better for some applications to advertise separate LSAs per link, for others, it may make sense to have a lists of interfaces in a single LSA. Q: Some applications may require to co-relate the information in transport instance to a specific routing-instance. This requirement to be addressed. A: This should be addressed by the application draft when using OSPF transport instance. Again, it is expected that routing information will be in the routing instance. Q: There may be cases when application information gets associated with prefixes rather than nodes. We should allow advertisement of Extended Prefix-LSA and E-Intra-area-Prefix-LSA/E-Inter-Area-Prefix-LSA Advertisements inside transport instance. A: While an application could define prefix-level information with semantics identical to these LSAs, it would not use these LSAs. There are for routing information. Q: It seems like we could reuse RI-LSA and originate RI-LSA in transport instance with application-ID TLV. What is the Need to define yet another opaque LSA? A: so we have a clear cut of application data, and hopefully this can simplify implementations.
- [Lsr] Q&A for OSPF Transport Instance Yingzhen Qu
- Re: [Lsr] Q&A for OSPF Transport Instance Aijun Wang