Aijun -
From: Aijun Wang <[email protected]>
Sent: Tuesday, January 16, 2024 10:56 PM
To: Les Ginsberg (ginsberg) <[email protected]>
Cc: Christian Hopps <[email protected]>; Huzhibo <[email protected]>; Acee
Lindem <[email protected]>; Yingzhen Qu <[email protected]>;
[email protected]
Subject: Re: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes
(01/05/2024 - 01/19/2024)
Hi, Les:
Let’s keep the discussions simple.
Please answer the following two questions that you haven’t responsed directly
in previous mail:
1) How the existing point-to-point based solution(RFC9346/RFC5392) solve
the broadcast(LAN, A.1 Figure2) inter-AS topology recovery scenario---There are
multiple neighbors on one interfaces, which are located in different AS. How to
encode the information within one inter-AS reachability TLV?
[LES:] In the absence of the existence of an advertisement of the LAN itself
(the “pseudonode” in IS-IS), a LAN is represented as a set of P2P links between
each of the nodes connected to the LAN.
Less scaleable but just as functional.
You, however, think you can get away with “If R1 advertises connectivity to the
LAN subnet and R2 and R3 also advertise connectivity to the same subnet that we
can assume that they are all connected” – which is an assumption that works
some of the time – but is not guaranteed.
It is easy to imagine this case if there is a switch and one of the ports on
the switch is faulty. (Other failure scenarios exist)
2) How the inter-AS based solutions solve the non inter-AS scenario
requirements(A.2)?
[LES:] An interesting question given that you haven’t addressed this yourself.
What does it mean to advertise reachability to an anycast address (as you
propose to do)?
Does that tell you if you are connected to one of anycast servers? Some of the
anycast servers? All of the anycast servers?
You don’t know – you are just assuming.
But since your goal is “topology discovery” it is important to actually know
whether you have a link to a particular anycast server or not.
You don’t know – you just assume.
One point that I want to remind for your misunderstanding: the proposed
Stub-link TLV can contain other attributes sub-TLVs of the link.
And, if the interfaces share the same prefixes, they are in the same IP subnet.
Is there any ambiguously for the IP topology recovery?
What I want to emphasize is that the existing solutions are suitable for
inter-AS point-to-point TE, the proposed solutions are suitable(more
efficient)for inter-AS topology recovery(p2p, p2mp and broadcast etc.) and also
other non inter-as traffic optimization scenarios. They are not contrary.
[LES:] AFAICT, your sole aim is efficiency – and you have given no thought to
validating the actual topology.
Les
Aijun Wang
China Telecom
On Jan 17, 2024, at 00:57, Les Ginsberg (ginsberg)
<[email protected]<mailto:[email protected]>>
wrote:
Aijun –
Please see inline.
From: Aijun Wang <[email protected]<mailto:[email protected]>>
Sent: Tuesday, January 16, 2024 12:18 AM
To: Les Ginsberg (ginsberg) <[email protected]<mailto:[email protected]>>;
'Christian Hopps' <[email protected]<mailto:[email protected]>>; 'Huzhibo'
<[email protected]<mailto:[email protected]>>
Cc: 'Acee Lindem' <[email protected]<mailto:[email protected]>>; 'Yingzhen
Qu' <[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>
Subject: 答复: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes
(01/05/2024 - 01/19/2024)
Hi, Les:
-----邮件原件-----
发件人: [email protected]<mailto:[email protected]>
[mailto:[email protected]] 代表 Les Ginsberg (ginsberg)
发送时间: 2024年1月16日 0:16
收件人: Christian Hopps <[email protected]<mailto:[email protected]>>; Huzhibo
<[email protected]<mailto:[email protected]>>
抄送: Acee Lindem <[email protected]<mailto:[email protected]>>; Yingzhen Qu
<[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>
主题: Re: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes
(01/05/2024 - 01/19/2024)
I respect that individuals may have different opinions - but it is important to
distinguish what is factual from what is not.
Opinions based upon false information are clearly compromised.
Please do heed Chris's (as WG chair) admonition to review the first WG adoption
thread. That will reveal to you what the substantive objections were.
https://mailarchive.ietf.org/arch/msg/lsr/Li7wJsaY68gzJ8mXxff7K-Fy_nw/
https://www.mail-archive.com/search?l=lsr%40ietf.org&q=stub+link&x=0&y=0
Please also do examine the delta between the previous version which was put up
for WG adoption (V3) and the current version (V8) so you can see what has
changed.
https://author-tools.ietf.org/iddiff?url1=draft-wang-lsr-stub-link-attributes-03&url2=draft-wang-lsr-stub-link-attributes-08&difftype=--html
Some facts:
The substantive objections raised during the first adoption call had nothing to
do with use cases - they had to do with:
a)The use of a prefix to identify a link between two nodes is a flawed concept.
It is not robust enough to be used in cases of unnumbered or Pt-2-MP.
[WAJ] Current encoding has covered the unnumbered scenario. For Pt-2-MP
scenario, they share also the same subnet, please see our previous discussion
at https://mailarchive.ietf.org/arch/msg/lsr/molRRoWXOBhaHFc5GPAPmvVISDs/
[LES:] I have no idea why you think the email you point to resolved the issue.
It was an early email in a very long thread, the lack of support for unnumbered
etc. continued to be discussed in subsequent emails by multiple participants
and has been raised again by multiple participants in this second adoption call
thread.
The minor changes you made to the encoding of Stub Link advertisement does
nothing to resolve the issue.
The fundamental issue is that the same prefix can be associated with multiple
links, so what you have defined is ambiguous in some cases.
Either you don’t understand this or don’t think this is important – I am not
sure which – but many of us do believe this is important.
b)Existing mechanisms (RFC 9346/was RFC 5316 and RFC 5392) fully cover the
potential use cases and do so more robustly than the Stub-link proposal.
[WAJ] If you make such claims, then please give the encoding example for A.1
Figures 2(LAN scenario). How to configure/encode the several neighbors that
located in different AS in one inter-AS reachability TLV?
[LES:] RFC 9346/RFC 5362 provide a robust way to uniquely identify inter-AS
links, verify two-way connectivity, and optionally advertise additional link
attributes if desired. (Apply this portion of the response to your other
comments below.)
You apparently think this is too onerous and you propose a different mechanism
that isn’t robust, does not allow two-way connectivity verification, and
doesn’t support link attribute advertisement.
But because you see it as “simpler” you think you have sufficient justification
to overlook its flaws.
I don’t agree.
The long-lived success of the IGPs has happened because we have worked
diligently to provide robust solutions – not settle for solutions that only
work some of the time.
Les
The latest version of the draft makes no substantive changes to the stub link
concept or its advertisement.
The only substantive change in the latest version is a reorganization of the
presentation of use cases.
But lack of clarity in the use cases was not the basis on which first WG
adoption call was rejected.
In this thread (the second WG adoption call), the authors have asserted that
they have addressed the concerns raised in the previous adoption call.
They have not. The concept and mechanism to identify a stub link has not
changed.
In this thread the authors continue to assert that RFC 9346/RFC 5392 cannot
address the use cases.
This is FALSE.
As has been pointed out repeatedly, the existing mechanisms provide a robust
means to uniquely identify inter-AS links using endpoint identifiers - be they
IPv4/IPv6 addresses or Link IDs.
[WAJ] And, please give the solution for the non inter-AS scenario(A.2). Please
do not mention the bogus AS again
This addresses all cases - numbered and unnumbered.
There is therefore no need for a new mechanism.
[WAJ] Repeat again. The requirements of inter-AS TE solution are different from
the requirements of inter-AS topology recovery. We should find more efficient
solution to solve the latter scenario.
The inefficiency of existing solutions for inter-AS topology recovery lies in
that it requires the operators to get the other end information for every
inter-as links manually, this is very challenge and error-prone, as that also
indicated in RFC9346 and RFC5392 themselves.
No fact-based argument has been made to justify reconsideration of WG adoption.
I hope when people post their opinions, that they consider the facts.
Les
> -----Original Message-----
> From: Lsr <[email protected]<mailto:[email protected]>> On Behalf Of
> Christian Hopps
> Sent: Wednesday, January 10, 2024 2:17 AM
> To: Huzhibo
> <[email protected]<mailto:[email protected]>>
> Cc: Acee Lindem <[email protected]<mailto:[email protected]>>; Yingzhen Qu
> <[email protected]<mailto:[email protected]>>;
> [email protected]<mailto:[email protected]>
> Subject: Re: [Lsr] WG Adoption Call -
> draft-wang-lsr-stub-link-attributes
> (01/05/2024 - 01/19/2024)
>
> [As WG Co-Chair]
>
> Hi Folks,
>
> Before posting support reasons please read and considerl
> *all* the email in the archive covering the first failed
> adoption call.
>
> https://mailarchive.ietf.org/arch/msg/lsr/Li7wJsaY68gzJ8mXxff7K-Fy_nw/
> https://www.mail-
> archive.com/search?l=lsr%40ietf.org&q=stub+link&x=0&y=0
>
> This adoption call should be considering if the changes
> made to the document since it failed to be adopted the
> first time, are sufficient to reverse the WGs previous
> decision.
>
_______________________________________________
Lsr mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
