[Lsr] 【Please extend the adoption call for one more week】答复: WG Adoption Call - draft-wang-lsr-stub-link-attributes (01/05/2024 - 01/19/2024)

[Aijun Wang]

Hi, LSR chairs:

 

Along the adoption call procedure, I think we all noticed that there are some 
limitations for the p2p(RFC9346/RFC5392) based existing solutions for the 
potential scenarios(A.1-A.3) that mentioned in the draft.

Then we want to apply for extending the adoption call for one week or more, to 
confirm these limitations and also the values of proposed draft.

 

The limitation for the p2p (RFC9346/RFC5392) based solutions are the followings:

1) Scalability: 

Within the operator’s network, there are always tens/hundreds of the links 
between any two ASBRs.  It is very challenge to get/validate the information of 
other end of the inter-AS links, that is required by the existing solutions. 

We should find some scalable solutions to solve the issue.

 

2) Coverage:

RFC9346/RFC5392 cover only p2p link, it doesn’t support the broadcast network, 
also the P2MP network. 

If these types of network are represented by individual P2P link(as Les 
suggested), then the following two additional questions should be answered:

2-1) whether one interface can be appointed to different neighbor? Will the 
latter override the former? 

2-2) The efficiency. The total neighbor information will be O(N*N), the 
operator must get and verify them manually(no automatic method,  not relevant 
to the NMS management), where if we use the subnet instead, the operator needs 
only confirm one information—-the shared subnet/prefix.

Should we find some efficient way to cover more types of network then?

 

3) Flexibility:

RFC 9346/RFC5392 requires the remote AS number and the IPv4/IPv6  Remote ASBR 
sub-TLVs must be presented in the advertisement, but in some scenarios(non 
inter-as scenario, for example A.2 in the draft), they are not exists or not 
necessary, stick to these standards lead the solution very rigid and can’t be 
deployed.

 

Actually, “Stub Link” is one more general concept than the “inter-AS link”, we 
can pair them(form the inter-as link), or not(act independently) upon our 
demands.

We all should know that the components are more flexible than the compounds.

 

The actual pair methods can be refined later to meet the various 
requirements/scenarios(for example, unnumbered scenario, VRF scenario(as Robert 
mentioned) etc.)

 

Then, if the LSR experts agree the above limitations of the existing solutions, 
we expect to forward this draft to solve these limitations. 

Or else, we expect to discuss them further and more deeper in the coming times.

 

As operators, we expect to find one more attractive solution.

 

Best Regards

 

Aijun Wang

China Telecom

 

 

 

发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] 代表 
Yingzhen Qu
发送时间: 2024年1月6日 8:23
收件人: lsr ; lsr-chairs 
主题: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes (01/05/2024 - 
01/19/2024)

 

Hi,

 

This begins a 2 week WG Adoption Call for the following draft:
 
  
https://datatracker.ietf.org/doc/draft-wang-lsr-stub-link-attributes/
 
Please indicate your support or objections by January 19th, 2024.
 
Authors, please respond to the list indicating whether you are aware of any IPR 
that applies to the draft.

*** Please note that this is the second WG adoption poll of the draft. The 
first one was tried two years ago and you can see the discussions in the 
archive:

[Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02 (ietf.org) 
 

 

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

[Lsr] 答复: WG Adoption Call - draft-wang-lsr-stub-link-attributes (01/05/2024 - 01/19/2024)

[Aijun Wang]

Hi, Les:

 

Let’s top post my responses to your specific questions:

 

1)  LAN partitioning can occur. So R1 and R2 may be able to talk to each 
and R3 and R4 may be able to talk to each – but the two partitions have no 
connectivity. Yet all nodes will advertise the LAN subnet – which in your world 
means that you think you have full connectivity when you do not. 

[WAJ] If the partition is occurred by design, then R1-R4 should not declare the 
same subnet; if the partition is occurred by the switch faulty, it needs other 
OAM tools to detect. This is also true for the P2P based existing 
solutions(RFC9346/RFC5392).

 

2)  Your draft says: “It will be help for the router R0, to know the 
attributes of the stub links and select the optimal Anycast server to serve the 
customer's application.”.

Given that you don’t actually know which of the anycast servers each of the 
border routers can reach (you just “assume” it is all of them) the ability of 
R0 to make a correct decision is compromised.

[WAJ] Here, “the optimal Anycast server” refer to the “the optimal path(exits) 
to Anycast server”.  The reason that we use Anycast is that all these servers 
can provide the same services. The difference is that the path 
attributes(internal links and stub link) to them.

 

Wish the above explanations can address your concerns.

 

 

Best Regards

 

Aijun Wang

China Telecom

 

发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] 代表 Les 
Ginsberg (ginsberg)
发送时间: 2024年1月19日 0:51
收件人: Aijun Wang 
抄送: 'Christian Hopps' ; 'Huzhibo' ; 
'Acee Lindem' ; 'Yingzhen Qu' ; 
lsr@ietf.org
主题: Re: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes 
(01/05/2024 - 01/19/2024)

 

Aijun –

 

Frankly, I have a limited tolerance for these exchanges because your responses 
to specific points are evasive.

You are like a boxer whose main goal is to avoid any punch thrown by your 
opponent from landing directly. This is a pretty useful skill in a boxing ring, 
but pretty tiresome when trying to have a frank exchange of views on the 
technical points of a draft.

I am unlikely to respond further after this – but please find some responses 
inline. See [LES2:].

 

From: Aijun Wang mailto:wangai...@tsinghua.org.cn> 
> 
Sent: Thursday, January 18, 2024 1:29 AM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com> >
Cc: 'Christian Hopps' mailto:cho...@chopps.org> >; 
'Huzhibo' mailto:huzh...@huawei.com> >; 'Acee Lindem' 
mailto:acee.i...@gmail.com> >; 'Yingzhen Qu' 
mailto:yingzhen.i...@gmail.com> >; lsr@ietf.org 
 
Subject: 答复: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes 
(01/05/2024 - 01/19/2024)

 

Hi, Les:

 

发件人: forwardingalgori...@ietf.org   
[mailto:forwardingalgori...@ietf.org] 代表 Les Ginsberg (ginsberg)
发送时间: 2024年1月18日 0:16
收件人: Aijun Wang mailto:wangai...@tsinghua.org.cn> >
抄送: Christian Hopps mailto:cho...@chopps.org> >; Huzhibo 
mailto:huzh...@huawei.com> >; Acee Lindem 
mailto:acee.i...@gmail.com> >; Yingzhen Qu 
mailto:yingzhen.i...@gmail.com> >; lsr@ietf.org 
 
主题: Re: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes 
(01/05/2024 - 01/19/2024)

 

Aijun -

 

From: Aijun Wang mailto:wangai...@tsinghua.org.cn> 
> 
Sent: Tuesday, January 16, 2024 10:56 PM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com> >
Cc: Christian Hopps mailto:cho...@chopps.org> >; Huzhibo 
mailto:huzh...@huawei.com> >; Acee Lindem 
mailto:acee.i...@gmail.com> >; Yingzhen Qu 
mailto:yingzhen.i...@gmail.com> >; lsr@ietf.org 
 
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)

 

[WAJ] If one of the ports on the switch is faulty, then the router that 
connected is disconnected from the subnet. The topology recovery will not 

Re: [Lsr] I-D Action: draft-ietf-isis-sr-yang-19.txt

[Yingzhen Qu]

Hi Tom,

Thanks for the review. Version -20 includes the fixes. Please see my
answers below inline.

Thanks,
Yingzhen

On Thu, Jan 18, 2024 at 4:13 AM tom petch  wrote:

> This I-D changes the names of some bits in the identity cf RFC8667.  I
> think that the description clause should then give the mapping to the
> RFC8667 name.  I see this for
> lo-bit
> pe-bit
> af-bit
> These may be excellent names but they are not what RFC8667 specifies!
>

[Yingzhen]: Unfortunately YANG doesn't allow the same identity name with
different bases. For example, l-flag is defined with base
"prefix-sid-flag", so we can't define 'l-flag" again with base
"adj-sid-flag", so I changed it to "lo-flag".

>
> As the YANG doctor review says, the description should reference RFC and
> section thereof for all identity such as r-bit.
>

[Yingzhen]: fixed.

>
> The I-D refences
> RFC8102
> draft-ietf-rtgwg-segment-routing-ti-lfa
>
> which need adding to the I-D References
>
> [Yingzhen]: Added.


> Perhaps in the YANG augment
> OLD
>  "This augments ISIS protocol configuration
>   with segment routing.";
> NEW
>  "This augments ISIS protocol configuration
>   with segment routing for the MPLS data plane.";
>
> [Yingzhen]: fixed. same for OSPF.

> Tom Petch
>
>
> 
> From: Lsr  on behalf of internet-dra...@ietf.org <
> internet-dra...@ietf.org>
> Sent: 31 December 2023 06:30
> To: i-d-annou...@ietf.org
> Cc: lsr@ietf.org
> Subject: [Lsr] I-D Action: draft-ietf-isis-sr-yang-19.txt
>
> Internet-Draft draft-ietf-isis-sr-yang-19.txt is now available. It is a
> work
> item of the Link State Routing (LSR) WG of the IETF.
>
>Title:   A YANG Data Model for IS-IS Segment Routing for the MPLS Data
> Plane
>Authors: Stephane Litkowski
> Yingzhen Qu
> Pushpasis Sarkar
> Ing-Wher Chen
> Jeff Tantsura
>Name:draft-ietf-isis-sr-yang-19.txt
>Pages:   31
>Dates:   2023-12-30
>
> Abstract:
>
>This document defines a YANG data module that can be used to
>configure and manage IS-IS Segment Routing for MPLS data plane.
>
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-isis-sr-yang/
>
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-isis-sr-yang-19.html
>
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-isis-sr-yang-19
>
> 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 mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Yangdoctors last call review of draft-ietf-isis-sr-yang-19

[Yingzhen Qu]

HI Reshad,

Thanks for the review. I've uploaded version -20 to address your comments.
Details below inline.

Thanks,
Yingzhen

On Sat, Jan 13, 2024 at 4:24 PM Reshad Rahman via Datatracker <
nore...@ietf.org> wrote:

> Reviewer: Reshad Rahman
> Review result: Ready with Issues
>
> Hi all,
>
> This is my YANG Doctor review of -19. Thanks to the authors for making the
> effort to align with draft-ietf-ospf-yang (as previously requested).
>
> Comments
> 
>
> Section 3 (YANG Tree)
>
> - There are a few instances of perfix-sid-flags, should bd prefix-sid-flags
>

[Yingzhen]: fixed.

>
> - For the list below, can there be overlaps between different entries? If
> not,
> this should be documented (ideally should have been documented in RFC9020)
>
>+--rw protocol-srgb {sr-mpls:protocol-srgb}?
>   +--rw srgb* [lower-bound upper-bound]
>  +--rw lower-bounduint32
>  +--rw upper-bounduint32
>
> [Yingzhen]: There should not be overlaps. Agreed with you, this should
have been documented in RFC 9020.


> YANG Model
>
> - The identities such as r-bit, n-bit etc should all have a reference (not
> just
> the document but also the section)
>

[Yingzhen]: I added reference to each base identity.

>
> - All those identities are called x-bit but the description says flag.
> Which
> terminology is typically used in IS-IS?
>
> [Yingzhen]: changed to -flag.


> - Leaf Sid, how do we know whether it’s a 32-bit SID or a 20-bit label (not
> sure if we need to know)?
>

[Yingzhen]: Same as ospf-sr-mpls.yang, added length, and updated sid
description.


> - For global-blocks and local-blocks, a reference would help.
>
> [Yingzhen]: Done.


> - In grouping sid-sub-tlv, is the container sid-sub-tlv needed?
>
> [Yingzhen]: A container would help to identify the boundary of a TLV. In
an ISIS LSP, there are multiple TLVs and sub-tlvs.


> - In grouping srlb , can there be an overlap of the advertised local
> blocks?
> Need some enhanced description here iMO.  Same question for sr-capability
> and
> global blocks.
>
> [Yingzhen]: please see the above answers.

- In list global-block, why not add a key? I’m assuming the sid would be
> unique? Same comment for local-block.
>

[Yingzhen]:  SRGB is defined in RFC 9020, which is common for both OSPF and
ISIS. Here, we're defining protocol specific SRGB, and the key is defined
in the grouping in the ietf-segment-routing-common.yang. SRLB is defined in
RFC 9020, which applies to all protocols.

>
> - In grouping srms-preference, leaf preference, no need for the range
> 0..255
> since it is a uint8.
>
> [Yingzhen]: fixed.


> - Nit: a few instances of “This group …”, it should be “This grouping …”
>
> [Yingzhen]: fixed.


> - Leaf ‘af’, nit/suggestion: I would rename to address-family.
>
> [Yingzhen] : Done.


> - In grouping segment-routing-binding-tlv, leaf range, is that description
> accurate?
>
> [Yingzhen]: Thanks for catching this. I've updated the description.


> - Augment with neighbor-system-id, should the leaf node be mandatory?
>
> [Yingzhen]: added "mandatory true". Also did the same for ospf.

- Container selection-tie-breakers, can both protection types be enabled
> simultaneously?
>
> [Yingzhen]: yes, it's possible to enable both of them, one or none.


> There should be an appendix with a fairly complete config example and also
> an
> operational state example.
>
> [Yingzhen]: Operational state is not easy to do with the IGP database
since we don't have an implementation yet.


> Regards,
> Reshad.
>
>
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] I-D Action: draft-ietf-ospf-sr-yang-30.txt

[internet-drafts]

Internet-Draft draft-ietf-ospf-sr-yang-30.txt is now available. It is a work
item of the Link State Routing (LSR) WG of the IETF.

   Title:   A YANG Data Model for OSPF Segment Routing for the MPLS Data Plane
   Authors: Yingzhen Qu
Acee Lindem
Jeffrey Zhang
Ing-Wher Chen
   Name:draft-ietf-ospf-sr-yang-30.txt
   Pages:   49
   Dates:   2024-01-18

Abstract:

   This document defines a YANG data module that can be used to
   configure and manage OSPF Extensions for Segment Routing for the MPLS
   data plane.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-ospf-sr-yang/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-ospf-sr-yang-30.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-ospf-sr-yang-30

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] I-D Action: draft-ietf-isis-sr-yang-20.txt

[internet-drafts]

Internet-Draft draft-ietf-isis-sr-yang-20.txt is now available. It is a work
item of the Link State Routing (LSR) WG of the IETF.

   Title:   A YANG Data Model for IS-IS Segment Routing for the MPLS Data Plane
   Authors: Stephane Litkowski
Yingzhen Qu
Pushpasis Sarkar
Ing-Wher Chen
Jeff Tantsura
   Name:draft-ietf-isis-sr-yang-20.txt
   Pages:   33
   Dates:   2024-01-18

Abstract:

   This document defines a YANG data module that can be used to
   configure and manage IS-IS Segment Routing for MPLS data plane.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-isis-sr-yang/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-isis-sr-yang-20.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-isis-sr-yang-20

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] Roman Danyliw's No Objection on draft-ietf-lsr-isis-area-proxy-12: (with COMMENT)

[Roman Danyliw via Datatracker]

Roman Danyliw has entered the following ballot position for
draft-ietf-lsr-isis-area-proxy-12: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-area-proxy/



--
COMMENT:
--

Thank you for addressing my COMMENT and DISCUSS feedback.



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

Re: [Lsr] Roman Danyliw's Discuss on draft-ietf-lsr-isis-area-proxy-10: (with DISCUSS and COMMENT)

[Tony Li]

Hi Roman,


>>> -- What are the relevant pointers to IS-IS security considerations?
>> 
>> 
>> AFAIK, there is no overall document for IS-IS’ security architecture. The 
>> only
>> pointers I can suggest are to RFC 5304 and 5310.  I will happily add 
>> references
>> to these if folks feel that’s helpful.
> 
> 
> Thanks for this explanation.  I clear on this point.  Adding those references 
> to the SecCons would be helpful.


Added.

Tony

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

[Lsr] Fwd: New Version Notification for draft-ietf-lsr-isis-area-proxy-12.txt

[Tony Li]

Another update addressing IESG comments.

T


> Begin forwarded message:
> 
> From: internet-dra...@ietf.org
> Subject: New Version Notification for draft-ietf-lsr-isis-area-proxy-12.txt
> Date: January 18, 2024 at 10:40:00 AM PST
> To: "Gyan S. Mishra" , "Gyan Mishra" 
> , "Sarah Chen" , "Tony Li" 
> , "Vivek Ilangovan" 
> 
> A new version of Internet-Draft draft-ietf-lsr-isis-area-proxy-12.txt has been
> successfully submitted by Tony Li and posted to the
> IETF repository.
> 
> Name: draft-ietf-lsr-isis-area-proxy
> Revision: 12
> Title:Area Proxy for IS-IS
> Date: 2024-01-18
> Group:lsr
> Pages:20
> URL:  
> https://www.ietf.org/archive/id/draft-ietf-lsr-isis-area-proxy-12.txt
> Status:   https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-area-proxy/
> HTMLized: https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-area-proxy
> Diff: 
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-lsr-isis-area-proxy-12
> 
> Abstract:
> 
>   Link state routing protocols have hierarchical abstraction already
>   built into them.  However, when lower levels are used for transit,
>   they must expose their internal topologies to each other, leading to
>   scale issues.
> 
>   To avoid this, this document discusses extensions to the IS-IS
>   routing protocol that allow level 1 areas to provide transit, yet
>   only inject an abstraction of the level 1 topology into level 2.
>   Each level 1 area is represented as a single level 2 node, thereby
>   enabling greater scale.
> 
> 
> 
> The IETF Secretariat
> 
> 

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

[Lsr] I-D Action: draft-ietf-lsr-isis-area-proxy-12.txt

[internet-drafts]

Internet-Draft draft-ietf-lsr-isis-area-proxy-12.txt is now available. It is a
work item of the Link State Routing (LSR) WG of the IETF.

   Title:   Area Proxy for IS-IS
   Authors: Tony Li
Sarah Chen
Vivek Ilangovan
Gyan S. Mishra
   Name:draft-ietf-lsr-isis-area-proxy-12.txt
   Pages:   20
   Dates:   2024-01-18

Abstract:

   Link state routing protocols have hierarchical abstraction already
   built into them.  However, when lower levels are used for transit,
   they must expose their internal topologies to each other, leading to
   scale issues.

   To avoid this, this document discusses extensions to the IS-IS
   routing protocol that allow level 1 areas to provide transit, yet
   only inject an abstraction of the level 1 topology into level 2.
   Each level 1 area is represented as a single level 2 node, thereby
   enabling greater scale.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-area-proxy/

There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-area-proxy-12

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-lsr-isis-area-proxy-12

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

Re: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes (01/05/2024 - 01/19/2024)

[Les Ginsberg (ginsberg)]

Aijun –

Frankly, I have a limited tolerance for these exchanges because your responses 
to specific points are evasive.
You are like a boxer whose main goal is to avoid any punch thrown by your 
opponent from landing directly. This is a pretty useful skill in a boxing ring, 
but pretty tiresome when trying to have a frank exchange of views on the 
technical points of a draft.
I am unlikely to respond further after this – but please find some responses 
inline. See [LES2:].

From: Aijun Wang 
Sent: Thursday, January 18, 2024 1:29 AM
To: Les Ginsberg (ginsberg) 
Cc: 'Christian Hopps' ; 'Huzhibo' ; 
'Acee Lindem' ; 'Yingzhen Qu' ; 
lsr@ietf.org
Subject: 答复: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes 
(01/05/2024 - 01/19/2024)

Hi, Les:

发件人: forwardingalgori...@ietf.org 
[mailto:forwardingalgori...@ietf.org] 代表 Les Ginsberg (ginsberg)
发送时间: 2024年1月18日 0:16
收件人: Aijun Wang mailto:wangai...@tsinghua.org.cn>>
抄送: Christian Hopps mailto:cho...@chopps.org>>; Huzhibo 
mailto:huzh...@huawei.com>>; Acee Lindem 
mailto:acee.i...@gmail.com>>; Yingzhen Qu 
mailto:yingzhen.i...@gmail.com>>; 
lsr@ietf.org
主题: Re: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes 
(01/05/2024 - 01/19/2024)

Aijun -

From: Aijun Wang mailto:wangai...@tsinghua.org.cn>>
Sent: Tuesday, January 16, 2024 10:56 PM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Cc: Christian Hopps mailto:cho...@chopps.org>>; Huzhibo 
mailto:huzh...@huawei.com>>; Acee Lindem 
mailto:acee.i...@gmail.com>>; Yingzhen Qu 
mailto:yingzhen.i...@gmail.com>>; 
lsr@ietf.org
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)

[WAJ] If one of the ports on the switch is faulty, then the router that 
connected is disconnected from the subnet. The topology recovery will not 
include this router.

[LES2:] You have missed the point. LAN partitioning can occur. So R1 and R2 may 
be able to talk to each and R3 and R4 may be able to talk to each – but the two 
partitions have no connectivity. Yet all nodes will advertise the LAN subnet – 
which in your world means that you think you have full connectivity when you do 
not.

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?
[WAJ] 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.
[WAJ] For A.2, the aim is not topology discovery, the aim is to select the 
optimal path(or exits) that to the anycast server, based not only the internal 
link information, but also the stub link information that connects to the 
server.

[LES2:]  Your draft says: “It will be help for the router R0, to know the 
attributes of the stub links and select the optimal Anycast server to serve the 
customer's application.”.
Given that you don’t actually know which of the anycast servers each of the 
border routers can reach (you just “assume” it is all of them) the ability of 
R0 to make a correct decision is compromised.

   Les

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 

[Lsr] Roman Danyliw's Discuss on draft-ietf-lsr-isis-area-proxy-11: (with DISCUSS and COMMENT)

[Roman Danyliw via Datatracker]

Roman Danyliw has entered the following ballot position for
draft-ietf-lsr-isis-area-proxy-11: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-area-proxy/



--
DISCUSS:
--

** Section 4.3.  Do all the candidates need the Area Proxy System Identifier
TLVs need the same system identifier?

-- Section 4.2 says “For consistency, all Area Leader candidates SHOULD be
configured with the same Proxy System ID, Proxy Hostname, and any other
information that may be inserted into the Proxy LSP.”

-- Section 4.3.1 says: “All candidates advertising the Area Proxy System
Identifier TLV MUST be advertising the same system identifier.”

The first statement suggests that consistency might not always be required, but
the second statement is clear that it always must be the same identifier.

Per our discussion on
https://mailarchive.ietf.org/arch/msg/lsr/HbpEgfX4p7rSMr490kylMyy5pFA, I
believe the agreed resolution is to s/MUST/SHOULD/ in Section 4.3.1.


--
COMMENT:
--

Thank you to Alexey Melnikov for the SECDIR review.

** Section 8.

8.  Security Considerations

   This document introduces no new security issues.  Security of routing
   within a domain is already addressed as part of the routing protocols
   themselves.  This document proposes no changes to those security
   architectures.

-- What are the relevant pointers to IS-IS security considerations?

Per https://mailarchive.ietf.org/arch/msg/lsr/HbpEgfX4p7rSMr490kylMyy5pFA/,
please consider adding references to RFC 5304 and 5310.



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

Re: [Lsr] Roman Danyliw's Discuss on draft-ietf-lsr-isis-area-proxy-10: (with DISCUSS and COMMENT)

[Roman Danyliw]

Hi Tony!

Thanks for the explanation.  See below.

> -Original Message-
> From: Tony Li  On Behalf Of Tony Li
> Sent: Tuesday, January 9, 2024 5:31 PM
> To: Roman Danyliw 
> Cc: The IESG ; draft-ietf-lsr-isis-area-pr...@ietf.org; 
> lsr-chairs
> ; lsr ; Christian Hopps 
> Subject: Re: Roman Danyliw's Discuss on draft-ietf-lsr-isis-area-proxy-10: 
> (with
> DISCUSS and COMMENT)
> 
> Warning: External Sender - do not click links or open attachments unless you
> recognize the sender and know the content is safe.
> 
> 
> Hi Roman, Alexy,
> 
> Thank you for your comments.
> 
> > --
> > DISCUSS:
> > --
> >
> > ** Section 4.3.  Do all the candidates need the Area Proxy System
> > Identifier TLVs need the same system identifier?
> 
> 
> I’m not sure I understand the question. Let me prattle on a bit and please let
> me know if I do not address the question.
> 
> Vanilla IS-IS requires that each node in the routing domain have a unique
> system identifier.
> This is unchanged.
> 
> Area Proxy extends this by requiring an additional system identifier for the
> Area Proxy. This is the Area Proxy System Identifier. This is normally 
> advertised
> by the Area Leader so that all Interior Nodes know the value and it’s used by
> Interior Edge Nodes.  It’s a good idea to have multiple candidates for Area
> Leader for resiliency, and having them all configured with the same Area Proxy
> System Identifier is strongly preferred out of consistency. However, it is NOT
> required. It is not an error for there to be multiple different candidate Area
> Proxy System Identifiers.  In fact, this situation might happen if someone has
> decided to change the Area Proxy System Identifier and is in the midst of
> reconfiguring part of the routing domain.
> 
> This does not cause confusion because Area Leader election is going to elect a
> single leader and all systems will use the Area Proxy System Identifier that 
> the
> leader is advertising.
> 
> Yes, if there is a change in leader, there may be a transient change in the 
> Area
> Proxy System Identifier. This would cause a set of adjacency flaps, just as
> changing any regular system identifier would.
> 
> 
> > -- Section 4.2 says “For consistency, all Area Leader candidates
> > SHOULD be configured with the same Proxy System ID, Proxy Hostname,
> > and any other information that may be inserted into the Proxy LSP.”
> 
> 
> The rationale is similar to the above. Is there a separate question?
> 
> 
> > -- Section 4.3.1 says: “All candidates advertising the Area Proxy
> > System Identifier TLV MUST be advertising the same system identifier.”
> 
> 
> I will relax this to a SHOULD.
> 
> 
> > The first statement suggests that consistency might not always be
> > required, but the second statement is clear that it always must be the same
> identifier.

I very much appreciate the explanation.  The bottom line issue was the 
inconsistency between the two statements highlighted by the "--" bullets.  The 
proposed change to SHOULD in Section 4.3.1 addressed my feedback.

> > ** Section 8.  The following statement doesn’t appear to be accurate.
> >
> > 8.  Security Considerations
> >
> >   This document introduces no new security issues.  Security of routing
> >   within a domain is already addressed as part of the routing protocols
> >   themselves.  This document proposes no changes to those security
> >   architectures.
> >
> > -- Aren’t a few the filtering activities described in Section 5.2
> > security-related?
> 
> 
> No. These are key for ensuring the benefits of Area Proxy, most especially
> scalability, but if they are violated, it is not necessarily catastrophic.
> 
> Some examples:
> 
> - If the L1 LSP of an Inside Router is leaked outside of the area, then it 
> would be
> a protocol error, but other routers should recognize that they are not part of
> that area and ignore the LSP.
> 
> - If the L2 LSP of an Inside Router is leaked outside of the area, then it 
> would be
> accepted by other routers, but it would have no two-way adjacencies with
> anything else in L2 and effectively be disconnected from the topology.
> 
> - Incorrect PSNP or CSNPs would prompt the receiving system to send PSNPs
> for Inside LSPs, but this would not per se cause problems.
> 
> 
> > -- What are the relevant pointers to IS-IS security considerations?
> 
> 
> AFAIK, there is no overall document for IS-IS’ security architecture. The only
> pointers I can suggest are to RFC 5304 and 5310.  I will happily add 
> references
> to these if folks feel that’s helpful.


Thanks for this explanation.  I clear on this point.  Adding those references 
to the SecCons would be helpful.

> 
> > --
> > COMMENT:
> > --
> >
> > Thank you to 

Re: [Lsr] I-D Action: draft-ietf-isis-sr-yang-19.txt

[tom petch]

This I-D changes the names of some bits in the identity cf RFC8667.  I think 
that the description clause should then give the mapping to the RFC8667 name.  
I see this for 
lo-bit
pe-bit
af-bit
These may be excellent names but they are not what RFC8667 specifies!

As the YANG doctor review says, the description should reference RFC and 
section thereof for all identity such as r-bit.

The I-D refences 
RFC8102
draft-ietf-rtgwg-segment-routing-ti-lfa

which need adding to the I-D References

Perhaps in the YANG augment
OLD
 "This augments ISIS protocol configuration
  with segment routing.";
NEW
 "This augments ISIS protocol configuration
  with segment routing for the MPLS data plane.";

Tom Petch



From: Lsr  on behalf of internet-dra...@ietf.org 

Sent: 31 December 2023 06:30
To: i-d-annou...@ietf.org
Cc: lsr@ietf.org
Subject: [Lsr] I-D Action: draft-ietf-isis-sr-yang-19.txt

Internet-Draft draft-ietf-isis-sr-yang-19.txt is now available. It is a work
item of the Link State Routing (LSR) WG of the IETF.

   Title:   A YANG Data Model for IS-IS Segment Routing for the MPLS Data Plane
   Authors: Stephane Litkowski
Yingzhen Qu
Pushpasis Sarkar
Ing-Wher Chen
Jeff Tantsura
   Name:draft-ietf-isis-sr-yang-19.txt
   Pages:   31
   Dates:   2023-12-30

Abstract:

   This document defines a YANG data module that can be used to
   configure and manage IS-IS Segment Routing for MPLS data plane.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-isis-sr-yang/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-isis-sr-yang-19.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-isis-sr-yang-19

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 mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] 答复: WG Adoption Call - draft-wang-lsr-stub-link-attributes (01/05/2024 - 01/19/2024)

[Aijun Wang]

And, for broadcast networks, if you can only encode them via the p2p link style, there are still the following questions:1) whether one interface can be appointed to different neighbor? Will the latter override the former? 2) The efficiency. The total neighbor information will be O(N*N), the operator must get and verify them manually(no automatic method,  not relevant to the NMS management), where if we use the subnet instead, the operator needs only confirm one information—-the shared subnet/prefix.Then, should we find some more efficient way to accomplish the goal, instead of sticking to the most onerous one?Aijun WangChina TelecomOn Jan 18, 2024, at 17:29, Aijun Wang  wrote:Hi, Les: 发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] 代表 Les Ginsberg (ginsberg)发送时间: 2024年1月18日 0:16收件人: Aijun Wang 抄送: Christian Hopps ; Huzhibo ; Acee Lindem ; Yingzhen Qu ; lsr@ietf.org主题: Re: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes (01/05/2024 - 01/19/2024) Aijun - From: Aijun Wang  Sent: Tuesday, January 16, 2024 10:56 PMTo: Les Ginsberg (ginsberg) Cc: Christian Hopps ; Huzhibo ; Acee Lindem ; Yingzhen Qu ; lsr@ietf.orgSubject: 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) [WAJ] If one of the ports on the switch is faulty, then the router that connected is disconnected from the subnet. The topology recovery will not include this router.  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?[WAJ] 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.[WAJ] For A.2, the aim is not topology discovery, the aim is to select the optimal path(or exits) that to the anycast server, based not only the internal link information, but also the stub link information that connects to the server. 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.[WAJ]: If you have any scenario, that the proposed solution can’t give the actual topology, please illustrate it or them. Les  Aijun WangChina Telecom On Jan 17, 2024, at 00:57, Les Ginsberg (ginsberg)  wrote: Aijun – Please see inline. From: Aijun Wang  Sent: Tuesday, January 16, 2024 12:18 AMTo: Les Ginsberg (ginsberg) ; 'Christian Hopps' ; 'Huzhibo' Cc: 'Acee Lindem' ; 'Yingzhen Qu' ; lsr@ietf.orgSubject: 答复: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes (01/05/2024 - 01/19/2024) Hi, Les: -邮件原件-发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] 代表 Les Ginsberg (ginsberg)发送时间: 

[Lsr] 答复: WG Adoption Call - draft-wang-lsr-stub-link-attributes (01/05/2024 - 01/19/2024)

[Aijun Wang]

Hi, Les:

 

发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] 代表 Les 
Ginsberg (ginsberg)
发送时间: 2024年1月18日 0:16
收件人: Aijun Wang 
抄送: Christian Hopps ; Huzhibo ; Acee 
Lindem ; Yingzhen Qu ; 
lsr@ietf.org
主题: Re: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes 
(01/05/2024 - 01/19/2024)

 

Aijun -

 

From: Aijun Wang mailto:wangai...@tsinghua.org.cn> 
> 
Sent: Tuesday, January 16, 2024 10:56 PM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com> >
Cc: Christian Hopps mailto:cho...@chopps.org> >; Huzhibo 
mailto:huzh...@huawei.com> >; Acee Lindem 
mailto:acee.i...@gmail.com> >; Yingzhen Qu 
mailto:yingzhen.i...@gmail.com> >; lsr@ietf.org 
 
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)

 

[WAJ] If one of the ports on the switch is faulty, then the router that 
connected is disconnected from the subnet. The topology recovery will not 
include this router.

 

 

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?

[WAJ] 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.

[WAJ] For A.2, the aim is not topology discovery, the aim is to select the 
optimal path(or exits) that to the anycast server, based not only the internal 
link information, but also the stub link information that connects to the 
server.

 

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.

[WAJ]: If you have any scenario, that the proposed solution can’t give the 
actual topology, please illustrate it or them.

 

Les

 

 

Aijun Wang

China Telecom

 

On Jan 17, 2024, at 00:57, Les Ginsberg (ginsberg) 
mailto:ginsberg=40cisco@dmarc.ietf.org> > wrote:

 

Aijun –

 

Please see inline.

 

From: Aijun Wang mailto:wangai...@tsinghua.org.cn> 
> 
Sent: Tuesday, January 16, 2024 12:18 AM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com> >; 
'Christian Hopps' mailto:cho...@chopps.org> >; 'Huzhibo' 
mailto:huzh...@huawei.com> >
Cc: 'Acee Lindem' mailto:acee.i...@gmail.com> >; 
'Yingzhen Qu' mailto:yingzhen.i...@gmail.com> >; 
lsr@ietf.org  
Subject: 答复: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes 
(01/05/2024 - 01/19/2024)

 

Hi, Les:

 

-邮件原件-
发件人: forwardingalgori...@ietf.org   
[mailto:forwardingalgori...@ietf.org] 代表 Les Ginsberg (ginsberg)
发送时间: 2024年1月16日 0:16
收件人: Christian Hopps mailto:cho...@chopps.org> >; Huzhibo 
mailto:huzhibo=40huawei@dmarc.ietf.org> >
抄送: Acee Lindem mailto:acee.i...@gmail.com> >; Yingzhen 
Qu mailto:yingzhen.i...@gmail.com> >; lsr@ietf.org 
 
主题: Re: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes 

[Lsr] 答复: WG Adoption Call - draft-wang-lsr-stub-link-attributes (01/05/2024 - 01/19/2024)

[Aijun Wang]

Hi, Robert: 

 

For VRF interface, we can treat it specially, similar as the unnumbered 
interface in the draft. (Add one “V” bit to identify them and attach the remote 
identifier manually---there is no other automatic way to accomplish the 
topology recovery )

But for other non-VRF interfaces, the proposed solution is more efficient that 
the existing solution. The operator can omit many onerous work.

 

And, the proposed solution is not only for topology recovery, it can also cover 
other use cases(for example A.2/A.3)

 

Best Regards

 

Aijun Wang

China Telecom

 

发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] 代表 
Robert Raszuk
发送时间: 2024年1月17日 16:33
收件人: Aijun Wang 
抄送: Les Ginsberg (ginsberg) ; Christian 
Hopps ; Huzhibo ; Acee Lindem 
; Yingzhen Qu ; lsr@ietf.org
主题: Re: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes 
(01/05/2024 - 01/19/2024)

 

Aijun,

 

> And, if the interfaces share the same prefixes, they are in the same IP 
> subnet.

 

That is unfortunately a wrong assumption. 

 

In number of deployments all external links can share the same IP addresses as 
they are terminated in VRFs and on the other side belong to completely 
different peers. 

 

So unless you add an RD to those prefixes and make them domain wide unique I am 
afraid your proposal has serious issue. As Les said when we define a protocol 
extension the most important is to review how it will work in all deployment 
cases - not to pick just a few and declare a success. 

 

Regards,

Robert

 

 

 

On Wed, Jan 17, 2024 at 7:56 AM Aijun Wang mailto:wangai...@tsinghua.org.cn> > wrote:

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? 

2) How the inter-AS based solutions solve the non inter-AS scenario 
requirements(A.2)?

 

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. 

 

 

 

Aijun Wang

China Telecom





On Jan 17, 2024, at 00:57, Les Ginsberg (ginsberg) 
mailto:40cisco@dmarc.ietf.org> > 
wrote:

 

Aijun –

 

Please see inline.

 

From: Aijun Wang <  
wangai...@tsinghua.org.cn> 
Sent: Tuesday, January 16, 2024 12:18 AM
To: Les Ginsberg (ginsberg) <  ginsb...@cisco.com>; 
'Christian Hopps' <  cho...@chopps.org>; 'Huzhibo' < 
 huzh...@huawei.com>
Cc: 'Acee Lindem' <  acee.i...@gmail.com>; 
'Yingzhen Qu' <  yingzhen.i...@gmail.com>;  
 lsr@ietf.org
Subject: 答复: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes 
(01/05/2024 - 01/19/2024)

 

Hi, Les:

 

-邮件原件-
发件人: forwardingalgori...@ietf.org   
[mailto:forwardingalgori...@ietf.org] 代表 Les Ginsberg (ginsberg)
发送时间: 2024年1月16日 0:16
收件人: Christian Hopps mailto:cho...@chopps.org> >; Huzhibo 
mailto:huzhibo=40huawei@dmarc.ietf.org> >
抄送: Acee Lindem mailto:acee.i...@gmail.com> >; Yingzhen 
Qu mailto:yingzhen.i...@gmail.com> >; lsr@ietf.org 
 
主题: 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=stub+link=0=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.