Re: [Lsr] New Version Notification for draft-xu-lsr-flooding-reduction-in-clos-01.txt

[Les Ginsberg (ginsberg)]

Xiaohu –

I also point out that there are at least two existing drafts which specifically 
address IS-IS flooding reduction in CLOS networks and do so in greater detail 
and with more robustness than what is in your draft:

https://datatracker.ietf.org/doc/draft-ietf-lsr-distoptflood/

https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-spine-leaf-ext/

I do not see a need for yet another draft specifically aimed at CLOS networks.

Note that work on draft-ietf-lsr-isis-spine-leaf-ext was suspended due to lack 
of interest in deploying an IGP solution in CLOS networks.
You are suggesting in draft-xu-lsr-fare that AI is going to change this. Well, 
maybe, but if so I think we should return to the solutions already available 
and prioritize work on them.

   Les


From: Lsr  On Behalf Of Tony Li
Sent: Thursday, November 23, 2023 8:39 AM
To: xuxiaohu_i...@hotmail.com
Cc: lsr@ietf.org
Subject: Re: [Lsr] New Version Notification for 
draft-xu-lsr-flooding-reduction-in-clos-01.txt

Hi,

What you’re proposing is already described in IS-IS Mesh Groups 
(https://www.rfc-editor.org/rfc/rfc2973.html) and improved upon in Dynamic 
Flooding 
(https://datatracker.ietf.org/doc/html/draft-ietf-lsr-dynamic-flooding).

Regards,
Tony



On Nov 23, 2023, at 8:29 AM, 
xuxiaohu_i...@hotmail.com wrote:

Hi all,

Any comments or suggestions are welcome.

Best regards,
Xiaohu

发件人: internet-dra...@ietf.org 
mailto:internet-dra...@ietf.org>>
日期: 星期三, 2023年11月22日 11:37
收件人: Xiaohu Xu mailto:xuxiaohu_i...@hotmail.com>>
主题: New Version Notification for draft-xu-lsr-flooding-reduction-in-clos-01.txt
A new version of Internet-Draft draft-xu-lsr-flooding-reduction-in-clos-01.txt
has been successfully submitted by Xiaohu Xu and posted to the
IETF repository.

Name: draft-xu-lsr-flooding-reduction-in-clos
Revision: 01
Title:Flooding Reduction in CLOS Networks
Date: 2023-11-22
Group:Individual Submission
Pages:6
URL:  
https://www.ietf.org/archive/id/draft-xu-lsr-flooding-reduction-in-clos-01.txt
Status:   
https://datatracker.ietf.org/doc/draft-xu-lsr-flooding-reduction-in-clos/
HTMLized: 
https://datatracker.ietf.org/doc/html/draft-xu-lsr-flooding-reduction-in-clos
Diff: 
https://author-tools.ietf.org/iddiff?url2=draft-xu-lsr-flooding-reduction-in-clos-01

Abstract:

   In a CLOS topology, an OSPF (or ISIS) router may receive identical
   copies of an LSA (or LSP) from multiple OSPF (or ISIS) neighbors.
   Moreover, two OSPF (or ISIS) neighbors may exchange the same LSA (or
   LSP) simultaneously.  This results in unnecessary flooding of link-
   state information, which wastes the precious resources of OSPF (or
   ISIS) routers.  Therefore, this document proposes extensions to OSPF
   (or ISIS) to reduce this flooding within CLOS networks.  The
   reduction of OSPF (or ISIS) flooding is highly beneficial for
   improving the scalability of CLOS networks.



The IETF Secretariat

___
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

Re: [Lsr] draft-pkaneria-lsr-multi-tlv

[Les Ginsberg (ginsberg)]

Bruno –

You began your comments in the context of the adoption thread (Subject: RE: 
[Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 - 
12/09/2023)).
I note that you subsequently started a new thread with new (Subject: 
draft-pkaneria-lsr-multi-tlv).
But as the new thread continued the discussion of the comments which began in 
the previous thread, you might understand why we missed the distinction and 
assumed the discussion was in the context of WG adoption call.

OK – I get it now – you don’t want to comment on WG adoption – you just want to 
make comments on the draft.

The draft is almost 2 years old, has undergone multiple revisions of 
significance – partly in response to comments we received on the list.
The authors will certainly continue to listen to comments and incorporate them 
in the document based on discussion.
However, given that WG adoption is in progress, it would be pointless for us to 
continue to produce new versions of the document if the WG were to decide NOT 
to adopt the draft. So, I hope you can understand why we are waiting for the 
question of adoption to be settled before proceeding with further work.
This doesn’t obligate you to voice an opinion on WG adoption, but it certainly 
would be helpful if you did – and I encourage you to do so.

Many of your comments deserve further discussion – and that will certainly 
happen if work on the document continues, but for now I only want to respond to 
one remark you made:


It seems that there are existing implementations and just like they did not 
consult the WG to enable this non-compatible feature, they will not change 
whatever one might say (not even change the control to enable this mechanism.


What multiple vendors did is try to address a problem that has resulted from 
the additional features that have been defined in recent RFCs – specifically 
(but not exclusively) Segment Routing and Flex Algo. These already standardized 
and deployed protocol extensions resulted in scenarios where it is necessary to 
send more than 255 bytes for IS Neighbors and Prefix Reachability TLVs – which 
in turn resulted in unpredictable behavior from implementations which did not 
know how to deal with such cases. Note that we did not define new extensions 
which were not standardized – we simply tried to deal with the requirements 
which came from protocol extensions which have already been standardized. In 
doing so, we followed the model which has been explicitly defined (and 
deployed) for some existing TLVs (such as Router Capability). In the process of 
doing so, we also clearly saw the problems associated with partial deployment – 
sending MP TLVs in the presence of nodes which don’t support them causes 
serious problems. We looked for solutions that allowed for safe partial 
deployment – but found there are none. Subsequent discussion in the WG has 
confirmed that. We then began work on draft-pkaneria-lsr-multi-tlv so that the 
full community was aware of the issues.

In short, we have not created a problem – we are trying to address a problem 
that already exists and which is going to be encountered with increasing 
frequency as greater scale is deployed.

I see this as a good thing – even being proactive – and I would have thought 
operators like yourself would be appreciative of this effort. But it seems this 
has made you angry – you seem to think the vendors involved are rogues who care 
nothing for operational stability. Which strikes me as “shooting the messenger” 
behavior.
Should we have done nothing and simply waited for operators to encounter 
problems – networks falling over in surprising ways?

Also, regarding your statement that the vendors who have tried to be proactive 
will ignore any recommendations that are placed in the draft – I am frankly 
offended by this statement. Speaking on behalf of one vendor, I can tell you we 
have already modified our implementation to conform to the best practices 
defined in the draft – and will continue to monitor the progress of the draft 
and make further changes as needed. Has your experience of vendor/operator 
interaction over the past decades really been so bad that your expectations are 
so low?? That is concerning if true.

   Les


From: bruno.decra...@orange.com 
Sent: Thursday, November 23, 2023 1:35 AM
To: Tony Li 
Cc: draft-pkaneria-lsr-multi-...@ietf.org; lsr 
Subject: RE: draft-pkaneria-lsr-multi-tlv

Hi Tony,



Orange Restricted
From: Tony Li mailto:tony1ath...@gmail.com>> On Behalf 
Of Tony Li
Sent: Wednesday, November 22, 2023 5:03 PM
To: DECRAENE Bruno INNOV/NET 
mailto:bruno.decra...@orange.com>>
Cc: 
draft-pkaneria-lsr-multi-...@ietf.org;
 lsr mailto:lsr@ietf.org>>
Subject: Re: draft-pkaneria-lsr-multi-tlv


Hi Bruno,

We are still waiting to hear whether or not you are in favor of adopting this 
document.

Thank you (I guess). But where is this coming from?
I understand that:

  *   You are waiting 

Re: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 - 12/09/2023)

[Les Ginsberg (ginsberg)]

Huaimo -

Every statement you make below is false.
These points have been discussed - in WG meetings, on the mailing list, and in 
private conversations.
But you persist in repeating false claims.
This is not helpful.

You are, of course, entitled to have whatever opinion you choose regarding MP 
vs Big-TLV, but making false claims does not help the WG discussion.
Please stop.

I have taken some time to respond to each point inline below, explaining why it 
is false.
As I have suggested to you in the past, if you took the time to implement a 
prototype of your draft and tested against legacy systems (as has been done 
with MP), you would easily see the truth. The fact that you have not done this 
- but write a draft that you intend other people to implement - is a failing on 
your part.

Please see inline.

From: Huaimo Chen 
Sent: Friday, November 24, 2023 5:37 AM
To: Yingzhen Qu ; 
draft-pkaneria-lsr-multi-...@ietf.org; lsr 
Subject: RE: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 
- 12/09/2023)

Hi Everyone,

The solution in draft-pkaneria-lsr-multi-tlv has the following issues:


  1.  Not backward compatible. Unpredictable behavior with partial deployment, 
which is stated in both IETF 117 and IETF 118 slides of 
draft-pkaneria-lsr-multi-tlv
IETF118: 
https://datatracker.ietf.org/meeting/118/materials/slides-118-lsr-03-1-mptlv-00
IETF117: 
https://datatracker.ietf.org/meeting/117/materials/slides-117-lsr-2-isis-mptlv-00
The unpredictable behaviors include inconsistent LSDBs and routing loops.

  1.  Not general. When any TLV is bigger than 255 bytes and multi-part-TLVs 
are used for the TLV, a key must be selected by people (LSR WG) for the TLV and 
some special code/enhancement is required for determining the key.
  2.  Big overhead. For the first multi-part-TLV example in Section 4.1 of 
draft-pkaneria-lsr-multi-tlv-02, the overhead will be 46 (= 7 + 3 + 18 + 18) 
bytes when IPv6 addresses are used and 22 bytes when IPv4 addresses are used.
  3.  Extra operations/configurations for network operators.

These issues are resolved by the proposal in draft-chen-lsr-isis-big-tlv. The 
proposal is


  1.  Backward compatible. No unpredictable behavior with partial deployment.
[LES:] Given a network where some nodes do not support Big-TLV, assume that a 
node which does support Big-TLV is required to advertise an additional link 
attribute (e.g. delay) in support of a given Flex-Algo - say algo 130.
Since that node is already advertising 255 bytes of information about that 
link, it puts the delay sub-TLV into a Big-TLV.
The nodes which support Big-TLV will correctly process that information and use 
it in their algo 130 SPFs.
But the legacy nodes which are configured to support algo 130, will ignore 
Big-TLV and so will not have the delay information as input to their algo 130 
SPFs.
Because of this inconsistency, there is a possibility of loops and/or 
blackholes for algo 130 paths.
Therefore, the statement that there is "no unpredictable behavior with partial 
deployment" is FALSE.
Just as with MP, it is not safe to use Big-TLV in the presence of legacy nodes.


  1.  General. Neither key selection nor special code/enhancement is required 
for any TLV when it is bigger than 255 bytes.
[LES:] Support for Big-TLV requires new code to be written. And that code has 
to be done for each TLV for which you wish to support the use of Big-TLV. The 
fact that an implementation has added code to use Big-TLV for IS Neighbor 
advertisements does not mean that you get the same support for Prefix 
Reachability TLVs for free. You also have to modify the code which supports 
prefix reachability to use Big-TLV when appropriate. And so on for other TLVs...
Again, this would be obvious if you actually tried to implement Big-TLV support.

This is no different than MP - as has been discussed, MP support is per TLV.



  1.  Small overhead. The overhead will be 2 bytes.
[LES:] What you are referring to here are the use of link endpoint identifiers, 
whether they be IPv4 addresses, IPv6 addresses, or Link IDs in an IS Neighbor 
advertisement. To
understand why they are needed, let's use the example below:

++   ++
||   ||
| A  |10.1.1.1---10.1.1.2| B  |
||11.1.1.1---11.1.1.2||
||   ||
++   ++


There are two links between A-B with IPv4 addresses as shown.

An IS-Neighbor advertisement consists of:
TLV
Length
Neighbor system-id
Metric
Length of sub-TLVs
Sub-TLVs

If a link endpoint identifier is NOT included among the sub-TLVs, then it is 
not possible to tell whether the link attribute sub-TLVs apply to the link 
(10.1.1.1/10.1.1.2) or the link (11.1.1.1/11.1.1.2). The neighbor system-id 
alone is ambiguous.
This is key for many link attributes e.g., all of the TE attributes, adjacency 
SIDs.

When using MP, it is necessary to include link endpoint identifiers in each of 
the TLVs associated with that 

[Lsr] Rtgdir last call review of draft-ietf-lsr-isis-sr-vtn-mt-05

[Daniele Ceccarelli via Datatracker]

Reviewer: Daniele Ceccarelli
Review result: Has Issues

- General: The term and concept of Enhanced VPN is being discussed in TEAS as
part of the WG last call. I suggest to follow that thread and align the draft
with whatever output will be agreed. - General: i would suggest to change the
title into "Applicability" rather than using. Per my understanding this
document describes how to use existing mechanisms to achieve something new (the
status is correctly informational) - Abstract: "enhanced isolation". i checked
if it was defined in the framework for Enhanced VPNs in TEAS, but i couldn't
find a definition there nor in this draft. What does it mean? - VTN: is this a
new term to identify a set of existing items? E.g. an ACTN VN, NRP, a set of
RSVP-TE tunnel, a topology built with flex algo...are they cases of VTN or the
VTN is a different thing? - Intro: s/than that can be provided/than the ones
that can be provided - "Another possible approach is to create a set of
point-to-point paths, each with a set of network resources reserved along the
path, such paths are called Virtual Transport Path (VTP)". In what is this
different from an ACTN VN member? See RFC 8453. - Introduction: "In some
network scenarios, the required number of VTNs could be small, and it is
assumed that each VTN is associated with an independent topology and has a set
of dedicated or shared network resources. This document describes a simplified
mechanism to build SR based VTNs in those scenarios." I don't understand, is
there the need for a specific mechanisms (different from existing ones) only
for particular cases in which the number of VTNs is small (smaller than other
scenarios)? - Section 3.1 "The usage of other TE attributes in
topology-specific TLVs is for further study." The draft is pretty simple and
small, can't the usage of other TE attributes be described here as well?



___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] 答复: I-D Action: draft-wang-lsr-stub-link-attributes-07.txt

[Aijun Wang]

Hi, Acee:

 

I have uploaded the updated version of draft, to address your concerns.

 

The major update contents are the followings:

1) Separate the OSPF and IS-IS protocol extension for stub-link attributes, 
redefines the relevant Sub-TLVs to conform the current OSPF/IS-IS format.

2) Change some descriptions for scenario A.3, from "Optimized BGP Next-hop 
Selection" to "Egress Engineering for the path to BGP Next-hop".

3) Updates the graph for scenario A.2, let it more general.

 

Detail replies are inline below.

Please let me know whether you have other issues or not, for the scenario, for 
the solution, for the encoding etc.

 

 

Best Regards

 

Aijun Wang

China Telecom

 

-邮件原件-

发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] 代表 Acee 
Lindem

发送时间: 2023年11月16日 3:56

收件人: Aijun Wang 

抄送: Christian Hopps ; Yingzhen Qu ; 
draft-wang-lsr-stub-link-attribu...@ietf.org; Lsr 

主题: Re: [Lsr] I-D Action: draft-wang-lsr-stub-link-attributes-07.txt

 

Speaking as WG member: 

 

Hi Aijun, 

 

See inline. I’ve added the co-authors and LSR to the discussion - lest we don’t 
need to repeat it. 

 

> On Nov 14, 2023, at 21:52, Aijun Wang  wrote:

> 

> Hi, Acee:

> 

> I explained in detail inline below to your comments. 

> Wish they can address your concerns.

> If you have any further questions, please let me know.

> 

> -邮件原件-

> 发件人: Acee Lindem [mailto:acee.i...@gmail.com]

> 发送时间: 2023年11月15日 6:07

> 收件人: Aijun Wang 

> 抄送: Christian Hopps ; Yingzhen Qu 

> 

> 主题: Re: [Lsr] I-D Action: draft-wang-lsr-stub-link-attributes-07.txt

> 

> And for inter-AS use case, we already have: 

> 

> https://datatracker.ietf.org/doc/rfc5392/

> 

> I’m sure there is something similar for IS-IS. Why do we need anything more? 

> 

> 【WAJ】: Actually, we have explained the reason briefly at 
> https://datatracker.ietf.org/doc/html/draft-wang-lsr-stub-link-attributes-07#section-3.
>  There are scenarios that inter-AS scenario can't cover. And even for 
> inter-AS scenario, to apply RFC 5392(OSPF), or RFC 5316(IS-IS, now is 
> obsoleted by RFC9346), it requires every inter-AS link be configured with 
> "remote AS", and "IPv6/IPv4 Remote ASBR Identifier", which is inefficient.

 

In the use case, given that there is an active BGP session between the routers, 
it would seem that the remote AS is known. 

 

【WAJ】: It is not only AS number, but also the "IPv6/IPv4 Remote ASBR 
Identifier" for each link. The operator must manually identify them if we use 
the current solution.

 

> 

> Thanks,

> Acee

> 

> 

>> On Nov 14, 2023, at 16:40, Acee Lindem  wrote:

>> 

>> Hi Aijun,

>> 

>> I have the following comments: 

>> 

>>  1. What would be the purpose of an unnumbered stub link - if the link 
>> doesn’t go anywhere and doesn’t have an address, it doesn’t seem to serve 
>> any purpose. However, see comment #5 as this would imply the links aren’t 
>> really stubs.

> 【WAJ】The information carried within the stub link will be flooding across the 
> IGP domain, and each of them have an address, and also the prefix.  The 
> scenario described in A.1-A.3 explain the use case of such information.

 

But unnumbered links don’t have a unique address. 

【WAJ】For unnumbered stub link, as explained and stated in the draft, they must 
be identified and labeled specially. And we should know that unnumbered 
interface is seldom used within the network now.  To include them is just for 
the integrity of the standard. 

 

> 

>>  2. For IS-IS, the TLVs and sub-TLVs have 1 octet type/length.

> 【WAJ】There is already the discussion about the limitation of 1 octet length, 
> should we avoid it happen again? And 
> https://www.rfc-editor.org/rfc/rfc7356.htm defines also the Extended TLVs and 
> Extended Sub-TLVs which use the 16bit type and 16 bit length.

 

Given the constraints of extend TLV/sub-TLVs in RFC 7356, they wouldn’t seem to 
apply to your area scope use cases. 

【WAJ】Have updated draft to address your concerns 

 

> 

> 

>>  3. For the prefix sub-TLVs, the first length in the sub-TLV is the length 
>> of the value in the TLV. It cannot double as the prefix length.

> 【WAJ】The length value in the container TLV is the sum of attached sub-TLV; 
> the length field in the sub-TLV is the length of each sub-TLV. What's the 
> meaning of "it cannot double as the prefix length”?

 

In sections 4.3 and 4.4 there is only one length and it should be the sub-TLV 
length, not the prefix length. 

【WAJ】Have updated draft to address your concerns

 

> 

>>  4. The Appendix A.2 use case is already typically done with prefix 
>> advertisements.

> 【WAJ】There is no existing sub-TLV to encode the prefix information of the 
> stub link and there is also no way to advertise such prefix information. All 
> the works are proposed in our draft.

 

I’m saying that anycast address selection is already being facilitated using 
prefix advertisements. For example, with OSPFv2 Extended Prefix 

[Lsr] Rtgdir last call review of draft-ietf-isis-sr-yang-17

[Shuping Peng via Datatracker]

Reviewer: Shuping Peng
Review result: Has Issues

Hello,

I have been selected as the Routing Directorate reviewer for this draft. The
Routing Directorate seeks to review all routing or routing-related drafts as
they pass through IETF last call and IESG review, and sometimes on special
request. The purpose of the review is to provide assistance to the Routing ADs.
For more information about the Routing Directorate, please see
​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it would
be helpful if you could consider them along with any other IETF Last Call
comments that you receive, and strive to resolve them through discussion or by
updating the draft.

Document: draft-ietf-isis-sr-yang
Reviewer: Shuping Peng
Review Date: 2023-11-24
IETF LC End Date: 2023-11-30
Intended Status: Standards

Summary:
I have some minor concerns about this document that I think should be resolved
before publication.

Major Issues:
 "No major issues found."

Minor Issues:
1. Page 3, when configure adjacency-sid, do we need to indicate the neighbor's
systemid or IP in order to differentiate the different neighbors in the case of
having multiple neighbors?

augment /rt:routing/rt:control-plane-protocols
  /rt:control-plane-protocol/isis:isis/isis:interfaces
  /isis:interface:
+--rw segment-routing
   +--rw adjacency-sid
  +--rw adj-sids* [value]
  |  +--rw value-type?   enumeration
  |  +--rw value uint32
  |  +--rw protected?boolean

2. Page 4, since LFA, RLFA and TI-LFA are the three algorithm for computing
backup paths, why they are not in sibling relationship?

  augment /rt:routing/rt:control-plane-protocols
  /rt:control-plane-protocol/isis:isis/isis:interfaces
  /isis:interface/isis:fast-reroute:
+--rw ti-lfa {ti-lfa}?
   +--rw enable?   boolean
  augment /rt:routing/rt:control-plane-protocols
  /rt:control-plane-protocol/isis:isis/isis:interfaces
  /isis:interface/isis:fast-reroute/isis:lfa/isis:remote-lfa:
+--rw use-segment-routing-path?   boolean {remote-lfa-sr}?

3. Page 4, the keys of the global-block and local-block are not clear.

  augment /rt:routing/rt:control-plane-protocols
  /rt:control-plane-protocol/isis:isis/isis:database
  /isis:levels/isis:lsp/isis:router-capabilities:
+--ro sr-capability
|  +--ro sr-capability
|  |  +--ro sr-capability-bits*   identityref
|  +--ro global-blocks
| +--ro global-block* []
|+--ro range-size?uint32
|+--ro sid-sub-tlv
|   +--ro sid?   uint32
+--ro sr-algorithms
|  +--ro sr-algorithm*   uint8
+--ro local-blocks
|  +--ro local-block* []
| +--ro range-size?uint32
| +--ro sid-sub-tlv
|+--ro sid?   uint32
+--ro srms-preference
   +--ro preference?   uint8

4. Currently there is no configuration node for the micro loop avoidance
(https://datatracker.ietf.org/doc/draft-bashandy-rtgwg-segment-routing-uloop/),
any thoughts or plan on it?



___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] I-D Action: draft-wang-lsr-stub-link-attributes-08.txt

[internet-drafts]

Internet-Draft draft-wang-lsr-stub-link-attributes-08.txt is now available. It
is a work item of the Link State Routing (LSR) WG of the IETF.

   Title:   Advertisement of Stub Link Attributes
   Authors: Aijun Wang
Zhibo Hu
Gyan S. Mishra
Jinsong Sun
   Name:draft-wang-lsr-stub-link-attributes-08.txt
   Pages:   14
   Dates:   2023-11-24

Abstract:

   This document describes the mechanism that can be used to advertise
   the stub link attributes within the IS-IS or OSPF domain.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-wang-lsr-stub-link-attributes/

There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-wang-lsr-stub-link-attributes-08

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-wang-lsr-stub-link-attributes-08

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] 答复: WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 - 12/09/2023)

[Aijun Wang]

Do not support its adoption.

 

The draft just enumerate the requirements of MP-TLV support for relevant TLVs, 
it is not the general solution to the issue.

 

There is no practical way in the draft to assure the current and future 
implementation conforms to the newly defined explicit requirements, because the 
MP-TLV Support sub-TLV is not per-TLV basis, and as stated in the draft, one 
implementation declares support “MP-TLV” can’t assure it supports all relevant 
TLVs. --“It is understood that in reality, a given implementation might 
limit MP-TLV support to particular TLVs based on the needs of the deployment 
scenarios in which it is used”-Will there be many interoperability issues 
arises then? And also varies loop accidents within the network when all of 
vendors declare they support “MP-TLV” but not all of the relevant TLVs?

 

Best Regards

 

Aijun Wang

China Telecom

 

发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] 代表 
Yingzhen Qu
发送时间: 2023年11月18日 1:24
收件人: draft-pkaneria-lsr-multi-...@ietf.org; lsr 
主题: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 - 
12/09/2023)

 

Hi,

 

This begins a WG adoption call for draft-pkaneria-lsr-multi-tlv: 
draft-pkaneria-lsr-multi-tlv-04 - Multi-part TLVs in IS-IS (ietf.org) 
 

 

Please send your support or objection to the list before December 9th, 2023. An 
extra week is allowed for the US Thanksgiving holiday.

 

Thanks,

Yingzhen 

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr