Hi Acee,
Yes, by all means input from the operator's community is needed. It can be
collected through LSR WG, IDR WG or GROW WG. RTGWG could also contribute.
We have already seen input from some operators and their opinion on adding
and distributing more and more link state protocol and topology
+1
mh
8 juillet 2022 21:19 "Randy Bush" a écrit:
>> Meaning, please add a note to the security considerations saying don't
>> trust communities (this one included) from untrusted sources. See rfc
>> 7999 S6.
>
> because A trusts B, A does not know B's inbound security model. so B
> could have
> Meaning, please add a note to the security considerations saying don't
> trust communities (this one included) from untrusted sources. See rfc
> 7999 S6.
because A trusts B, A does not know B's inbound security model. so B
could have accepted the community from C with conditions less strict
Fri, Jul 08, 2022 at 05:13:37PM +0200, Robert Raszuk:
> > I do not understand Robert's issues with this community.
>
> Let me say that I like it from operational perspective.
>
> However from routing perspective I have doubts on how this community is
> going to be originated and how it is going
> I do not understand Robert's issues with this community.
Let me say that I like it from operational perspective.
However from routing perspective I have doubts on how this community is
going to be originated and how it is going to be used.
Example 1: Hyperscaler has global POP footprint and
Thu, Jul 07, 2022 at 12:21:27PM -0400, Jeffrey Haas:
>
>
> > On Jul 7, 2022, at 11:50 AM, Robert Raszuk wrote:
> > But most if not all of those do not affect intradomain traffic engineering
> > rules.
> >
> > So I think Jeff's point is how much trust is needed to overwrite your own
> >
Hi Paolo,
I reviewed
https://datatracker.ietf.org/doc/html/draft-lucente-grow-bmp-tlv-ebit-02
and have some minor nits and simplifications in wording to be considered.
Best wishes
Thomas
Change from
Vendors need the ability to define proprietary Information Elements,
because, for
