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

[Gyan Mishra]

I support WG adoption.

Gyan


On Fri, Jan 5, 2024 at 7:23 PM Yingzhen Qu  wrote:

> 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 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, Peter:

There is no Remote Identifiers, IPv4 Neighbor address, IPv6 Neighbor address
information on each of these stub links, unless you configure or identify
them manually.
Image there are tens of links between the inter-AS neighbors, what you think
better ways is very inefficient.

There are also other cases(for example, A.2, which is not the inter-AS
scenarios) that can utilize these attributes of the stub links.

Best Regards

Aijun Wang
China Telecom

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

Hi,

I don't believe any of what is being proposed in the draft is necessary.

There are existing mechanism available to advertise an inter-AS link.

Using the prefix advertisement to pair the two ends of the inter-AS link is
a bad idea IMHO. There are better ways of doing it - e.g. 
Local/Remote Identifiers, IPv4 interface address/IPv4 neighbor address,
IPv6 Interface Address/IPv6 Neighbor Address - these are all allowed in the
inter-AS reachability information.

thanks,
Peter


On 06/01/2024 01:23, Yingzhen Qu wrote:
> 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 mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Tony Li]

Hi,

This version addresses the comments from the IESG review.

Other comments?

Regards,
Tony


> Begin forwarded message:
> 
> From: internet-dra...@ietf.org
> Subject: New Version Notification for draft-ietf-lsr-isis-area-proxy-11.txt
> Date: January 9, 2024 at 3:32:24 PM 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-11.txt has been
> successfully submitted by Tony Li and posted to the
> IETF repository.
> 
> Name: draft-ietf-lsr-isis-area-proxy
> Revision: 11
> Title:Area Proxy for IS-IS
> Date: 2024-01-09
> Group:lsr
> Pages:20
> URL:  
> https://www.ietf.org/archive/id/draft-ietf-lsr-isis-area-proxy-11.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-11
> 
> 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-11.txt

[internet-drafts]

Internet-Draft draft-ietf-lsr-isis-area-proxy-11.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-11.txt
   Pages:   20
   Dates:   2024-01-09

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-11

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

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

[Tony Li]

Hi Murray,

Thank you for your comments.

> --
> COMMENT:
> --
> 
> Section 7 creates a registry whose policy is partly Expert Review, but doesn't
> give any particular guidance to the Designated Experts about what qualifying
> criteria might be.  Are there any that should be included?  I also suggest
> removing the names of proposed designated experts; that's appropriate for the
> shepherd writeup or an email and doesn't need to be in the document directly.


Names removed. I’ve got no specific criteria that I’d like to suggest.


> The SHOULD in Section 4.2 is bare.  When might an implementer or operator
> deviate from that advice?  If there's no legitimate condition, maybe it should
> be a MUST, or if it really doesn't matter, a MAY.


In this particular case, the primary reason would be a reconfiguration of the 
domain.

Other than operational consistency, there is no good reason to make this a 
‘MUST’. 
Everything should operate fine if the configurations are inconsistent. The 
information
should be taken from the Area Leader and the remaining information should be 
ignored.


> I actually have the same question about most of the 30+ SHOULDs in this
> document.  I wasn't able to tell just from the text in many cases what damage
> to interoperability I might trigger if I deviate from the advice.  And in the
> aggregate, as an implementer, I could do none of them and still claim I'm
> implementing this specification.  Is that intentional?


Yes. We like to be as liberal as possible.

Regards,
Tony

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

Re: [Lsr] Genart last call review of draft-ietf-lsr-isis-area-proxy-10

[Tony Li]

Hi Peter,

Thank you for your comments.

> Page 4, second paragraph, second sentence: change "MPLS based" to 
> "MPLS-based".


Fixed


> Page 4, section 1.1: in the text version that I read, the boilerplate contains
> the link "(https://tools.ietf.org/html/bcp14)". While this is found as a
> hyperlink in the PDF and HTML versions, I don't believe it should appear in 
> the
> text version. I don't know if this is a tool issue, but recent RFCs that I
> downloaded did not contain it. The hyperlink appears to cause idnits to
> complain about incorrect boilerplate text.


Fixed.


> Page 6, 1st paragraph, 1st sentence: change "i.e.  Ethernets" to "i.e.,
> Ethernets", which is to say, change the first space to a comma.


Fixed.


> Page 9, last paragraph, last sentence: change "implementation-dependent" to
> "implementation dependent”.


Fixed.

Thank you!
Tony




___
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, 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.
> 
> ** 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.


> --
> COMMENT:
> --
> 
> Thank you to Alexey Melnikov for the SECDIR review.
> 
> ** Section 4.3.1
>   However, before withdrawing the Area Proxy
>   System Identifier, an implementation SHOULD protect against
>   unnecessary churn from transients by delaying the withdrawal.  The
>   amount of delay is implementation-dependent.
> 
> Are there any guidelines on how the delay period should be computed?


I don’t have any specific suggestions. My implementation practice is to
apply binary exponential backoff, with some ridiculous upper bound, but the
specifics are well outside of the boundaries of a protocol spec.


> ** Section 4.4.4.
>   An entry for a neighbor in both the IS Neighbors TLV and the Extended
>   IS Neighbors would be functionally redundant, so the Area Leader
>   SHOULD NOT do this.
> 
> Under what circumstances would this advice be ignored (i.e., why not a MUST)?


This is not a MUST because it’s a redundancy, not an error.


> ** Section 4.4.5 and 4.4.6 describe various behavior where fields “SHOULD” be
> copied.  What governs the choice of not 

Re: [Lsr] Paul Wouters' Discuss on draft-ietf-lsr-isis-area-proxy-10: (with DISCUSS)

[Tony Li]

Hi all,

On second thought, I would like to retract and amend part of my answer to Paul.


>> I have a few minor discusses, which could be just because I'm not an ISIS
>> expert. Please bear with me :)
>> 
>>   Multiple proxy system identifiers in a single area is a
>>   misconfiguration and each unique occurrence SHOULD be logged.
>> 
>> This does not really answer what systems should do in this case? Use none
>> of them? What would the implication be? Use the one advertised by most nodes?
>> What would the risk be with that? The answers would be great additions to the
>> Security Considerations :)
> 
> 
> I propose to amend this to read:
> 
>  Multiple proxy system identifiers in a single
>   area is a misconfiguration and each unique occurrence
>   SHOULD be logged and the Area Leader MUST NOT generate the
>  Proxy LSP.


My proposal is unnecessarily draconian and disruptive. A better approach would 
be:

   Multiple proxy system identifiers in a single
   area is a misconfiguration and each unique occurrence
   SHOULD be logged. Systems should use the proxy system
   identifier advertised by the Area Leader.

I will maintain an increased level of caffeination. My apologies for the 
confusion.

Regards,
Tony


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

Re: [Lsr] Paul Wouters' Discuss on draft-ietf-lsr-isis-area-proxy-10: (with DISCUSS)

[Tony Li]

Hi Paul,

Thank you for your comments.

> --
> DISCUSS:
> --
> 
> I have a few minor discusses, which could be just because I'm not an ISIS
> expert. Please bear with me :)
> 
>Multiple proxy system identifiers in a single area is a
>misconfiguration and each unique occurrence SHOULD be logged.
> 
> This does not really answer what systems should do in this case? Use none
> of them? What would the implication be? Use the one advertised by most nodes?
> What would the risk be with that? The answers would be great additions to the
> Security Considerations :)


I propose to amend this to read:

   Multiple proxy system identifiers in a single
   area is a misconfiguration and each unique occurrence
   SHOULD be logged and the Area Leader MUST NOT generate the
   Proxy LSP.


>The Area Leader and other candidates for Area Leader MAY withdraw
>the Area Proxy System Identifier when one or more Inside Routers
>are not advertising the Area Proxy Router Capability. This will
>disable Area Proxy functionality.
> 
> Wouldn't this allow a malicious Inside Router to completely disable the Area
> Proxy functionality? Could this be part of an attack? Can this be mitigated
> somehow? Is there something to say about this for the Security Considerations?



Before we get into this specific question, we should talk about the security of
link state protocols in general. We do have authentication mechanisms in place 
to
ensure that all routers are known participants. However, once inside that 
crunchy
shell of authentication, there is a very soft, gooey interior.

Any node can advertise anything. Sane or not. Correct or not. Consistent or 
not. 
And an authenticated node can trivially DoS attack the entire domain. 
There are even configuration commands defined to do so ( “redistribute bgp …”).

This applies to both IS-IS and OSPF.

Now, to your point: yes, a malicious Inside Router can trivially disable Area 
Proxy 
functionality, there is no question about that. Could that be an attack? Yes, 
certainly.
It would be quite obvious and public as all of the LSDB is completely visible.

Is this worth mitigating? IMHO no. This is no better or worse than any other 
attack
that a malicious IS-IS router can launch. It’s exactly on-par with everything 
else
that’s in the protocol today.

Is this worth discussing in the Security Considerations?  IMHO no.  We decided a
long time ago that we were not going to chase the Byzantine Generals problem 
and 
that hasn’t proven to be problematic in practice.


> 
>0   1   2
>0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |  Type | Length|Proxy System ID|
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |   Proxy System Identifier continued   |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> This diagram seems incorrect. It shows 4 fields instead of 3.
> I suggest using:
> 
>0   1   2
>0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |  Type | Length|   |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Proxy System Identifier   |
>   |   |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Thank you for the suggestion, adopted.


Tony

___
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)

[Peter Psenak]

Hi,

I don't believe any of what is being proposed in the draft is necessary.

There are existing mechanism available to advertise an inter-AS link.

Using the prefix advertisement to pair the two ends of the inter-AS link 
is a bad idea IMHO. There are better ways of doing it - e.g. 
Local/Remote Identifiers, IPv4 interface address/IPv4 neighbor address, 
IPv6 Interface Address/IPv6 Neighbor Address - these are all allowed in 
the inter-AS reachability information.


thanks,
Peter


On 06/01/2024 01:23, Yingzhen Qu wrote:

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