Robert –
If you are suggesting that – based on the current state of advertised support
for a given feature (such as Multi-tlv) by all routers in the network - that
routers should dynamically modify what they send, this is VERY DANGEROUS – and
should not be done.
It can lead to flooding storms
Hi Les,
Ok that helps to clarify the current use case (and name confusion) of
RFC7981. I did look at some of the drafts defined in the registry of this
Capability TLV bringing in sub-TLVs and while clearly lots of them are used
in a run time I did see a few which could be also stated to use mgmt
Robert –
The intent of my response was to get agreement on separating the discussion of
advertising features supported by an implementation from the content of the
multi-tlv draft.
Router capabilities TLV (RFC 4971/7981) is something quite different. In every
case, information advertised in
Hi Les,
> 2) Applicability of advertising what features an implementation supports
extends
> to much more than just multi-tlv support.
Indeed. Spot on !
And wasn't it the reason for rfc4971 then updated by rfc7981 ?
I think having such capabilities flooded via area or entire domain is a
very
Placed on agenda for telechat - 2022-10-06
Datatracker URL:
https://datatracker.ietf.org/doc/draft-ietf-lsr-pce-discovery-security-support/
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
Tony -
For me, your discussion with Henk highlights two points:
1)There are different POVs on whether advertising management information (like
multi-tlv support) in the LSPDB is a good idea
2)Applicability of advertising what features an implementation supports extends
to much more than just
Peter,
Thank you! I've studied this draft in LSR WG multiple times. I had a difficult
time thinking how a router computing the paths when receiving 100+ topologies
for one IGP domain, until being told most deployments only having handful of
topologies.
Linda
-Original Message-
Andrew Alston has entered the following ballot position for
draft-ietf-lsr-isis-rfc5316bis-04: 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
On 21/09/2022 19:15, Les Ginsberg (ginsberg) wrote:
John -
Thanx for the thoughtful suggestions.
I like your last suggestion i.e., simply removing the phrase
"which contains the IPv4 Router ID of the router who generates the inter-AS
reachability TLV"
Hope that works for everyone.
Les,
Hi Linda,
On 22/09/2022 00:24, Linda Dunbar via Datatracker wrote:
Reviewer: Linda Dunbar
Review result: Has Nits
I have reviewed this document as part of the Ops area directorate's ongoing
effort to review all IETF documents being processed by the IESG. These
comments were written primarily
Hi Les,
Thank you very much for the clarification.
Regards,
Venkat.
On Wed, Sep 21, 2022 at 9:02 AM Les Ginsberg (ginsberg)
wrote:
> Venkat –
>
>
>
> First, you really should be looking at RFC 7794 – the use of R,N flags in
> prefix-sid sub-tlv only exists for backwards compatibility with
Murray Kucherawy has entered the following ballot position for
draft-ietf-lsr-isis-rfc5316bis-04: 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
12 matches
Mail list logo
