Re: [Lsr] Working Group Adoption Poll for "Updates to Anycast Property advertisement for OSPFv2" - draft-chen-lsr-anycast-flag-06

[Tony Przygienda]

I can only say, `spot on, Bruno` ...

a spec in IGP is not (not even experimental AFAIS) "hey, let's quickly call
something 'anycast' and put a flag into encoding and then kind of figure
out what it really means", especially for such a massive concept as
"anycast" that will be coming up over years over and over again. So if its
semantics are not clear both in case of  SR and current behavior and any
new technology that may use it for  computations yielding different
semantics/behavior we will pay high technical debt for it in the future
(also called as mess where e'thing is called "anycast" but means different
things). If this here is "SR-anycast" only, fine, let's call the flag that
and define behavior of SR with it and then we may have then
"funny-routing-v8-anycast"-flag that behaves differently (which is to say
has hence different semantics). If this is really "THE anycast flag" then
it needs to define precise semantics as interacting with today's no
signalling "kind of anycast" and rely on and expectation what behavior for
_any_ future technology in IGP should yield as semantics for this flag.

-- tony

On Thu, Mar 21, 2024 at 11:42 AM  wrote:

> Hi all,
>
>
>
> I would also welcome a clear specification of the semantics.
>
> Such that the meaning and implications are clear on both the originator
> and the receivers/consumers.
>
>
>
> e.g., from the originator standpoint:
>
> - The originator MAY advertise the Anycast Flag if CONDITIONS1 are met
> (which allow for some useful features such as….)
>
> - The originator MUST advertise the Anycast Flag if CONDITIONS1 are met
> (otherwise this breaks …)
>
>
>
> Please specify the CONDITIONS1.
>
>
>
> e.g., from the receiver standpoint:
>
> What does this mean to have this Anycast Flag set? What properties are
> being signaled? (a priori this may be already specified by CONDITIONS1
> above)
>
>
>
>
>
> If this is specific to SR,  please say so. But even in this sub-case, SR
> anycast has some conditions, both for SR-MPLS and SRv6.
>
>
>
> SR-MPLS:  https://datatracker.ietf.org/doc/html/rfc8402#section-3.3.1
>
> “determining the second label is impossible unless A1 and A2 allocated the 
> same label value to the same prefix.”
>
> “Using an anycast segment without configuring identical SRGBs on all
>
>nodes belonging to the same anycast group may lead to misrouting (in
>
>an MPLS VPN deployment, some traffic may leak between VPNs).”
>
>
>
> So for SR-MPLS, where we did not have anycast flag at the time, the burden
> of respecting the conditions seems to be on the receiver. In which case,
> Anycast flag didn’t seem to be required.
>
>
>
> SRv6:
> https://datatracker.ietf.org/doc/html/rfc9352#name-advertising-anycast-propert
>
> “All the nodes advertising the same anycast locator MUST instantiate the
> exact same set of SIDs under that anycast locator. Failure to do so may
> result in traffic being dropped or misrouted.”
>
>
>
> So for SRv6 the burden is on the originator, and we felt the need to
> define an anycast flag.
>
>
>
>
>
> Interestingly, the conditions seem different…
>
> Authors seems to use RFC9352 and RFC9513 as a justification. I’m not
> familiar with OSPFv2 but my understanding is that it does not advertise
> SRv6 SID. So presumably there are some differences
>
>
>
>
>
> “The prefix may be configured as anycast”
>
> Putting the burden on the network operator is not helping clarifying the
> semantic. We need the receivers/consumers and the network operators to have
> the same understanding of the semantic. (not to mention all implementations
> on the receiver side)
>
>
>
>
>
> So please specify the semantic.
>
> This may eventually lead to further discussion (e.g., on SR-MPLS)
>
>
>
> Thank you
>
> --Bruno
>
>
>
> *From:* Lsr  *On Behalf Of *Tony Przygienda
> *Sent:* Wednesday, March 20, 2024 5:44 PM
> *To:* Acee Lindem 
> *Cc:* Ketan Talaulikar ; Dongjie (Jimmy) <
> jie.d...@huawei.com>; lsr ;
> draft-chen-lsr-anycast-f...@ietf.org
> *Subject:* Re: [Lsr] Working Group Adoption Poll for "Updates to Anycast
> Property advertisement for OSPFv2" - draft-chen-lsr-anycast-flag-06
>
>
>
> I think the draft is somewhat superfluous and worse, can generate
> completely unclear semantics
>
>
>
> 1) First, seeing the justification I doubt we need that flag. if the only
> need is for the SR controller to know it's anycast since it computes some
> paths this can be done by configuring the prefix on the controller itself.
> It's all centralized anyway.
>
> 2) OSPF today due to SPF lim

Re: [Lsr] Working Group Adoption Poll for "Updates to Anycast Property advertisement for OSPFv2" - draft-chen-lsr-anycast-flag-06

[Tony Przygienda]

hmm, Peter, thanks for clarification but wasn't A the attach flag is OSPF
in 7684?

In ISIS it's in the SR support draft and hence I would ask here as well to
somehow clarify that  "this is for SR purposes"  and call the draft
accordingly before we get it confused with today's semantics. And possibly
call the flag the "SR-anycast flag" or some such thing that clarifies it
does not have anything to do with "normal" OSPF pseudo-anycast

I buy your 2nd use case

I don't get the first, are we talking TI-LFA with SR only? because
otherwise it's a tunnel and hence doesn't matter whether it traversed an
anycast . So for me it looks like SR specific thing again.

thanks

-- tony

On Wed, Mar 20, 2024 at 6:22 PM Peter Psenak  wrote:

> Tony,
>
> there are two use cases:
>
> 1. Your application wants to exclude address that is anycast - an example
> of where this can be used internally by IGP is a TI-LFA or uloop, when
> picking up the address of the node over which we want to do the
> enforcement. There is a N bit as well, but in case there is no address with
> the N-bit, you want to exclude anycast addresses.
>
> 2. Your application want to use only anycast addresses - inter-domain SRTE
> with anycast address for ASBRs. SRTE is using the IGP topology provided by
> BGP-LS.
>
> BTW, the A-bit exists in ISIS and OSPFv3. We are just filling the gap with
> this draft.
>
> thanks,
> Peter
>
>
>
> On 20/03/2024 17:44, Tony Przygienda wrote:
>
> I think the draft is somewhat superfluous and worse, can generate
> completely unclear semantics
>
> 1) First, seeing the justification I doubt we need that flag. if the only
> need is for the SR controller to know it's anycast since it computes some
> paths this can be done by configuring the prefix on the controller itself.
> It's all centralized anyway.
>
> please see the TI-LFA, uloop use case that is internal to IGP.
>
>
> 2) OSPF today due to SPF limitations has a "baked-in weird anycast" since
> if prefixes are ECMP (from pont of view of a source) they become anycast,
> otherwise they ain't. I think the anycast SID suffers from same limi8ation
> and is hence not a "real anycast" (if _real anycast_ means something that
> independent of metrics balances on the prefix). Hence this draft saying
> "it's anycast" has completely unclear semantics to me, worse, possibly
> broken ones. What do I do as a router when this flag is not around but two
> instances of the prefix are ECMP to me? What do I do on another router when
> those two instances have anycast but they are not ECMP? What will happen if
> the ECMP is lost due to ABR re-advertising where the "flag must be
> preserved" .
> 3) There is one good use case from my experience and this is to
> differentiate between a prefix moving between routers (mobility) and real
> anycast. That needs however far more stuff in terms of timestamping the
> prefix. pascal wrote and added that very carefully to rift if there is
> desire here to add proper anycast semantics support to the protocol.
>
> So I'm not in favor in adopting this unless the semantic is clearly
> written out for this flag and the according procedures specified (mobility?
> behavior on lack/presence of flag of normal routers etc). Saying "
>
> It
>is useful for other routers to know that the advertisement is for an
>anycast identifier.
>
> " is not a use case or justification for adding this.
>
>
> if this is "anycast in case of SR computed paths that are not ECMP" then
> the draft needs to say so and call it "SR anycast" or some such stuff. If
> it is something else I'd like to understand the semantics of this flag
> before this is adopted.
>
> -- tony
>
>
>
>
> On Wed, Mar 20, 2024 at 5:10 PM Acee Lindem  wrote:
>
>> Hi Ketan,
>>
>> On Mar 20, 2024, at 12:07, Ketan Talaulikar 
>> wrote:
>>
>> Sure, Acee. We can take that on :-)
>>
>> I hope it is ok that this is done post adoption?
>>
>>
>> Yup. I realize this is a simple draft to fill an IGP gap but I did ask
>> the question below. Hopefully, we can get to WG last call quickly.
>>
>> Thanks,
>> Acee
>>
>>
>>
>>
>> Thanks,
>> Ketan
>>
>>
>> On Wed, Mar 20, 2024 at 9:35 PM Acee Lindem  wrote:
>>
>>>
>>>
>>> > On Mar 20, 2024, at 11:17 AM, Ketan Talaulikar 
>>> wrote:
>>> >
>>> > Hi Acee/Jie,
>>> >
>>> > The most common users of the anycast property of a prefix are external
>>> controllers/PCE that perform path computation exercises. As an example,
>&

Re: [Lsr] Working Group Adoption Poll for "Updates to Anycast Property advertisement for OSPFv2" - draft-chen-lsr-anycast-flag-06

[Tony Przygienda]

I think the draft is somewhat superfluous and worse, can generate
completely unclear semantics

1) First, seeing the justification I doubt we need that flag. if the only
need is for the SR controller to know it's anycast since it computes some
paths this can be done by configuring the prefix on the controller itself.
It's all centralized anyway.
2) OSPF today due to SPF limitations has a "baked-in weird anycast" since
if prefixes are ECMP (from pont of view of a source) they become anycast,
otherwise they ain't. I think the anycast SID suffers from same limi8ation
and is hence not a "real anycast" (if _real anycast_ means something that
independent of metrics balances on the prefix). Hence this draft saying
"it's anycast" has completely unclear semantics to me, worse, possibly
broken ones. What do I do as a router when this flag is not around but two
instances of the prefix are ECMP to me? What do I do on another router when
those two instances have anycast but they are not ECMP? What will happen if
the ECMP is lost due to ABR re-advertising where the "flag must be
preserved" .
3) There is one good use case from my experience and this is to
differentiate between a prefix moving between routers (mobility) and real
anycast. That needs however far more stuff in terms of timestamping the
prefix. pascal wrote and added that very carefully to rift if there is
desire here to add proper anycast semantics support to the protocol.

So I'm not in favor in adopting this unless the semantic is clearly written
out for this flag and the according procedures specified (mobility?
behavior on lack/presence of flag of normal routers etc). Saying "

It
   is useful for other routers to know that the advertisement is for an
   anycast identifier.

" is not a use case or justification for adding this.


if this is "anycast in case of SR computed paths that are not ECMP" then
the draft needs to say so and call it "SR anycast" or some such stuff. If
it is something else I'd like to understand the semantics of this flag
before this is adopted.

-- tony




On Wed, Mar 20, 2024 at 5:10 PM Acee Lindem  wrote:

> Hi Ketan,
>
> On Mar 20, 2024, at 12:07, Ketan Talaulikar  wrote:
>
> Sure, Acee. We can take that on :-)
>
> I hope it is ok that this is done post adoption?
>
>
> Yup. I realize this is a simple draft to fill an IGP gap but I did ask the
> question below. Hopefully, we can get to WG last call quickly.
>
> Thanks,
> Acee
>
>
>
>
> Thanks,
> Ketan
>
>
> On Wed, Mar 20, 2024 at 9:35 PM Acee Lindem  wrote:
>
>>
>>
>> > On Mar 20, 2024, at 11:17 AM, Ketan Talaulikar 
>> wrote:
>> >
>> > Hi Acee/Jie,
>> >
>> > The most common users of the anycast property of a prefix are external
>> controllers/PCE that perform path computation exercises. As an example,
>> knowing the anycast prefix of a pair of redundant ABRs allows that anycast
>> prefix SID to be in a SRTE path across the ABRs with protection against one
>> of those ABR nodes going down or getting disconnected. There are other use
>> cases. An example of local use on the router by IGPs is to avoid picking
>> anycast SIDs in the repair segment-list prepared for TI-LFA protection -
>> this is because it could cause an undesirable path that may not be aligned
>> during the FRR window and/or post-convergence.
>> >
>> > That said, since ISIS (RFC9352) and OSPFv3 (RFC9513) didn't have the
>> burden of this justification of an use-case, I hope the same burden would
>> not fall on this OSPFv2 document simply because it only has this one
>> specific extension.
>>
>> But they also weren't added in a draft specifically devoted to the
>> Anycast flag. It would be good to list the examples above as  potential use
>> cases.
>>
>>
>> Thanks,
>> Acee
>>
>>
>>
>> >
>> > Thanks,
>> > Ketan
>> >
>> >
>> > On Wed, Mar 20, 2024 at 8:16 PM Acee Lindem 
>> wrote:
>> > Hi Jie,
>> >
>> > I asked this when the flag was added to IS-IS and then to OSPFv3. I
>> agree it would be good to know why knowing a prefix is an Anycast address
>> is "useful" when the whole point is that you use the closest one (or some
>> other criteria).
>> >
>> > Thanks,
>> > Acee
>> >
>> > > On Mar 20, 2024, at 9:09 AM, Dongjie (Jimmy) 
>> wrote:
>> > >
>> > > Hi authors,
>> > >
>> > > I just read this document. Maybe I didn't follow the previous
>> discussion, but it seems in the current version it does not describe how
>> this newly defined flag would be used by the receiving IGP nodes?
>> > >
>> > > Best regards,
>> > > Jie
>> > >
>> > > -Original Message-
>> > > From: Lsr  On Behalf Of Acee Lindem
>> > > Sent: Wednesday, March 20, 2024 4:43 AM
>> > > To: lsr 
>> > > Cc: draft-chen-lsr-anycast-f...@ietf.org
>> > > Subject: [Lsr] Working Group Adoption Poll for "Updates to Anycast
>> Property advertisement for OSPFv2" - draft-chen-lsr-anycast-flag-06
>> > >
>> > >
>> > > This starts the Working Group adoption call for
>> draft-chen-lsr-anycast-flag. This is a simple OSPFv2 maintenance draft
>> adding an Anycast flag 

Re: [Lsr] bunch comments on https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-admin-tags

[Tony Przygienda]

your premise holds only if you assume we can carry basically infinite
amount of tags like as-path or ext-comms. For practical reasons IGPs were,
are and will be likely limited to few tags only on a prefix and hence
without a precise ordering on borders, summarization etc (as the draft
mandates and it should) you will end up with non-determinism. I do not like
to think we get into MED with IGPs ;-)

We are talking here  of quite a border-line case of anycast with tags
exceeding the max. amount an implementation is willing to carry but one I
asked in real planning discussion and could not get an answer for.  The
basic case of having to clip the tags the draft was answering already
before.

Musing sidenote: Generally speaking, I do not consider the idea of pushing
IGPs heavily into direction of starting to carry tags on prefixes, run
policies in weird places and rely on complex tag configurations and such
machineries of complications a particularly good one.  Job of IGP is to
provide connectivity, to do it in a highly resilient, distributed and fast
fashion (unlike BGP which is not a connectivity protocol but a policy
distribution engine who can reach whom basically and hence needs such
mechanisms extensively). Introducing such tools start to make IGPs far more
prone to misconfiguration problems and unexplained brown-outs besides
forcing necessary computations/policy engines which at scale may start to
significantly slow convergence we rely on so heavily. Of course one can say
that sane designs will use that stuff only where it's unavoidable and
easily operationally tractable and I buy this argument, giving people
knives does not tell us what they will do with them ultimately ...

-- tony

On Sat, Mar 2, 2024 at 3:40 AM Gyan Mishra  wrote:

>
> Speaking from a operators POV, tags I agree can be very helpful.  However
> I think ordering that could influence SPF by router-id or other means am
> not sure is a good idea.  Have to think that through and any ramifications
> in doing so.
>
> My take is the goal of tags is very similar to BGP communities where you
> can mark the routes for filtering or redistributing of routes.
>
> I think the ability to have many tags on route is useful similar to BGP
> communities tagging.
>
> However adding more intelligence into the tagging  influencing routing and
> making it a standard I don’t think is a good idea.
>
> Kind Regards
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions A**rchitect *
>
> *Email gyan.s.mis...@verizon.com *
>
>
>
> *M 301 502-1347*
>
>
>
> On Fri, Mar 1, 2024 at 2:39 PM Tony Przygienda 
> wrote:
>
>> appreciate the ordering, some people start to get wild ideas especially
>> now you can slap that stuff on internal prefixes as well ;-)
>>
>>
>>
>> On Fri, Mar 1, 2024 at 7:27 PM Acee Lindem  wrote:
>>
>>> At the risk of complication, I've added text to clarify the ordering
>>> independence (from RFC 5130) and the usage when multiple LSAs contribute to
>>> a path in -14.
>>>
>>> I also specified the behavior for an invalid length - while I agree with
>>> Les this is a generic problem, it isn't necessary handled generically
>>> across IGPs, TLVs, and sub-TLVs. I'm used to addressing this class of
>>> comment,  Alvaroisms.
>>>
>>> Thanks and have a Great Weekend,
>>> Acee
>>>
>>> > On Feb 29, 2024, at 2:05 PM, Tony Przygienda 
>>> wrote:
>>> >
>>> > sure, on the tags given how some people start to abuse4 those in
>>> interesting ways now ;-) I'm piping in here since I'm obviously talking
>>> through some real OSPF designs where the issue of which ones will make it
>>> may matter given for practical reasons we have to limit how many we carry
>>> ... ;-)
>>> >
>>> > on the second point, don't write "this sub-TLV should carry at least
>>> one tag" if you don't specify what it means it doesn't carry one. No
>>> biggie, I just edged onto this when reading it ...
>>> >
>>> > if authors are not interested in making the spec tighter, closing
>>> possible holes then I just pipe out of course ...
>>> >
>>> > -- tony
>>> >
>>> > On Thu, Feb 29, 2024 at 8:01 PM Les Ginsberg (ginsberg) <
>>> ginsb...@cisco.com> wrote:
>>> > Tony –
>>> >  In the spirit of a friendly discussion…
>>> >   From: Lsr  On Behalf Of Tony Przygienda
>>> > Sent: Thursday, February 29, 2024 10:33 AM
>>> > To: Acee Lindem 
>>> > Cc: lsr 
>>> > Subject: Re: [Lsr] bunch comments on
>>> https

Re: [Lsr] bunch comments on https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-admin-tags

[Tony Przygienda]

appreciate the ordering, some people start to get wild ideas especially now
you can slap that stuff on internal prefixes as well ;-)



On Fri, Mar 1, 2024 at 7:27 PM Acee Lindem  wrote:

> At the risk of complication, I've added text to clarify the ordering
> independence (from RFC 5130) and the usage when multiple LSAs contribute to
> a path in -14.
>
> I also specified the behavior for an invalid length - while I agree with
> Les this is a generic problem, it isn't necessary handled generically
> across IGPs, TLVs, and sub-TLVs. I'm used to addressing this class of
> comment,  Alvaroisms.
>
> Thanks and have a Great Weekend,
> Acee
>
> > On Feb 29, 2024, at 2:05 PM, Tony Przygienda 
> wrote:
> >
> > sure, on the tags given how some people start to abuse4 those in
> interesting ways now ;-) I'm piping in here since I'm obviously talking
> through some real OSPF designs where the issue of which ones will make it
> may matter given for practical reasons we have to limit how many we carry
> ... ;-)
> >
> > on the second point, don't write "this sub-TLV should carry at least one
> tag" if you don't specify what it means it doesn't carry one. No biggie, I
> just edged onto this when reading it ...
> >
> > if authors are not interested in making the spec tighter, closing
> possible holes then I just pipe out of course ...
> >
> > -- tony
> >
> > On Thu, Feb 29, 2024 at 8:01 PM Les Ginsberg (ginsberg) <
> ginsb...@cisco.com> wrote:
> > Tony –
> >  In the spirit of a friendly discussion…
> >   From: Lsr  On Behalf Of Tony Przygienda
> > Sent: Thursday, February 29, 2024 10:33 AM
> > To: Acee Lindem 
> > Cc: lsr 
> > Subject: Re: [Lsr] bunch comments on
> https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-admin-tags
> >   1. you can easily rectify by saying, if you have  tags for same prefix
> from multiple nodes you prefere lowest router ID or maybe "sort on router
> id and then interleave" or something. depending how much of fully fledged
> specification you want here
> >  [LES:] As Acee has pointed out, the IS-IS RFC (written many years ago)
> explicitly stayed away from this sort of thing.
> > Are you saying that your experience with IS-IS has been unsatisfactory?
> If so, why aren’t you lobbying for changes to IS-IS? (Not that I am
> encouraging you to do so…  )
> >   2. we miss each other. I just say this sub-TLV being empty is NOT
> specified (i.e. behavior is undefined) if anyone sends such a thing
> > [LES:] From the POV of parsing, if you send a TLV with 0 length, it does
> no harm. Your parsing logic will just move on to the next TLV. I don’t see
> the need to specify any behavior.
> > Of course, it is useless to send this TLV with no content – so if your
> implementation wants to report that as an encoding error that seems
> reasonable to me.
> > If you send a length of 0 but actually have content, that is a serious
> encoding error – but that is a generic issue that seems outside the scope
> of this draft.
> > Les
> > -- tony
> >   On Wed, Feb 28, 2024 at 7:13 PM Acee Lindem 
> wrote:
> > Hi Tony,
> >
> > > On Feb 28, 2024, at 2:01 AM, Tony Przygienda 
> wrote:
> > >
> > > hey Acee, inline
> > >
> > >
> > > On Wed, Feb 28, 2024 at 3:30 AM Acee Lindem 
> wrote:
> > > Hi Tony,
> > >
> > > Thanks for the review.
> > >
> > >> On Feb 27, 2024, at 04:51, Tony Przygienda 
> wrote:
> > >>
> > >> Reading the draft quickly, here's bunch of observations
> > >>
> > >> "
> > >>
> > >> An OSPF router supporting this specification MUST be able to
> > >> advertise and interpret at least one 32-bit tag for all type of
> > >> prefixes. An OSPF router supporting this specification MAY be able
> > >> to advertise and propagate multiple 32-bit tags. The maximum tags
> > >> that an implementation supports is a local matter depending upon
> > >> supported applications using prefix tags.
> > >> "
> > >>
> > >>
> > >> Since different implementations may support different amount of tags
> I see that the draft says
> > >>
> > >> "
> > >> When propagating multiple tags, the order
> > >> of the the tags SHOULD be preserved.
> > >>
> > >> "
> > >>
> > >>
> > >> this is IMO not good enough in case where two nodes advertise same
> prefix with multiple tags, possibly differing or in differe

Re: [Lsr] bunch comments on https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-admin-tags

[Tony Przygienda]

sure, on the tags given how some people start to abuse4 those in
interesting ways now ;-) I'm piping in here since I'm obviously talking
through some real OSPF designs where the issue of which ones will make it
may matter given for practical reasons we have to limit how many we carry
... ;-)

on the second point, don't write "this sub-TLV should carry at least one
tag" if you don't specify what it means it doesn't carry one. No biggie, I
just edged onto this when reading it ...

if authors are not interested in making the spec tighter, closing possible
holes then I just pipe out of course ...

-- tony

On Thu, Feb 29, 2024 at 8:01 PM Les Ginsberg (ginsberg) 
wrote:

> Tony –
>
>
>
> In the spirit of a friendly discussion…
>
>
>
> *From:* Lsr  *On Behalf Of * Tony Przygienda
> *Sent:* Thursday, February 29, 2024 10:33 AM
> *To:* Acee Lindem 
> *Cc:* lsr 
> *Subject:* Re: [Lsr] bunch comments on
> https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-admin-tags
>
>
>
> 1. you can easily rectify by saying, if you have  tags for same prefix
> from multiple nodes you prefere lowest router ID or maybe "sort on router
> id and then interleave" or something. depending how much of fully fledged
> specification you want here
>
>
>
> *[LES:] As Acee has pointed out, the IS-IS RFC (written many years ago)
> explicitly stayed away from this sort of thing.*
>
> *Are you saying that your experience with IS-IS has been unsatisfactory?
> If so, why aren’t you lobbying for changes to IS-IS? (Not that I am
> encouraging you to do so… **** )*
>
>
>
> 2. we miss each other. I just say this sub-TLV being empty is NOT
> specified (i.e. behavior is undefined) if anyone sends such a thing
>
> *[LES:] From the POV of parsing, if you send a TLV with 0 length, it does
> no harm. Your parsing logic will just move on to the next TLV. I don’t see
> the need to specify any behavior.*
>
> *Of course, it is useless to send this TLV with no content – so if your
> implementation wants to report that as an encoding error that seems
> reasonable to me.*
>
> *If you send a length of 0 but actually have content, that is a serious
> encoding error – but that is a generic issue that seems outside the scope
> of this draft.*
>
>
>
> *   Les*
>
>
>
>
>
> -- tony
>
>
>
> On Wed, Feb 28, 2024 at 7:13 PM Acee Lindem  wrote:
>
> Hi Tony,
>
> > On Feb 28, 2024, at 2:01 AM, Tony Przygienda 
> wrote:
> >
> > hey Acee, inline
> >
> >
> > On Wed, Feb 28, 2024 at 3:30 AM Acee Lindem  wrote:
> > Hi Tony,
> >
> > Thanks for the review.
> >
> >> On Feb 27, 2024, at 04:51, Tony Przygienda  wrote:
> >>
> >> Reading the draft quickly, here's bunch of observations
> >>
> >> "
> >>
> >> An OSPF router supporting this specification MUST be able to
> >> advertise and interpret at least one 32-bit tag for all type of
> >> prefixes. An OSPF router supporting this specification MAY be able
> >> to advertise and propagate multiple 32-bit tags. The maximum tags
> >> that an implementation supports is a local matter depending upon
> >> supported applications using prefix tags.
> >> "
> >>
> >>
> >> Since different implementations may support different amount of tags I
> see that the draft says
> >>
> >> "
> >> When propagating multiple tags, the order
> >> of the the tags SHOULD be preserved.
> >>
> >> "
> >>
> >>
> >> this is IMO not good enough in case where two nodes advertise same
> prefix with multiple tags, possibly differing or in different order. Some
> kind of ordering is necessary then as well AFAIS.
> >>
> >
> > I guess I don’t see the problem. A policy would look for a specific tag
> and take a specific action.
> >
> > Note that for IS-IS tags so require ordering, see section 4 of
> https://datatracker.ietf.org/doc/rfc5130/.
> > I could possibly appropriate some of this text as it applies to OSPF.
> >
> >
> > my point is that if you have multiple nodes advertising some prefix with
> different 3 tag combinations and you choose to only support 3 tags the
> result is undefined by this draft as to which tags propagate at the end, so
> the "order should be preserved" doesn't help
>
> I agree this could be a problem if you have this situation but I don’t see
> how advertising the tags in any particular order rectifies it. Also, since
> an OSPF domain is under a single administrative domain, I also don’t
> understand why anyone would configure such a situ

Re: [Lsr] bunch comments on https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-admin-tags

[Tony Przygienda]

1. you can easily rectify by saying, if you have  tags for same prefix from
multiple nodes you prefere lowest router ID or maybe "sort on router id and
then interleave" or something. depending how much of fully fledged
specification you want here
2. we miss each other. I just say this sub-TLV being empty is NOT specified
(i.e. behavior is undefined) if anyone sends such a thing

-- tony

On Wed, Feb 28, 2024 at 7:13 PM Acee Lindem  wrote:

> Hi Tony,
>
> > On Feb 28, 2024, at 2:01 AM, Tony Przygienda 
> wrote:
> >
> > hey Acee, inline
> >
> >
> > On Wed, Feb 28, 2024 at 3:30 AM Acee Lindem  wrote:
> > Hi Tony,
> >
> > Thanks for the review.
> >
> >> On Feb 27, 2024, at 04:51, Tony Przygienda  wrote:
> >>
> >> Reading the draft quickly, here's bunch of observations
> >>
> >> "
> >>
> >> An OSPF router supporting this specification MUST be able to
> >> advertise and interpret at least one 32-bit tag for all type of
> >> prefixes. An OSPF router supporting this specification MAY be able
> >> to advertise and propagate multiple 32-bit tags. The maximum tags
> >> that an implementation supports is a local matter depending upon
> >> supported applications using prefix tags.
> >> "
> >>
> >>
> >> Since different implementations may support different amount of tags I
> see that the draft says
> >>
> >> "
> >> When propagating multiple tags, the order
> >> of the the tags SHOULD be preserved.
> >>
> >> "
> >>
> >>
> >> this is IMO not good enough in case where two nodes advertise same
> prefix with multiple tags, possibly differing or in different order. Some
> kind of ordering is necessary then as well AFAIS.
> >>
> >
> > I guess I don’t see the problem. A policy would look for a specific tag
> and take a specific action.
> >
> > Note that for IS-IS tags so require ordering, see section 4 of
> https://datatracker.ietf.org/doc/rfc5130/.
> > I could possibly appropriate some of this text as it applies to OSPF.
> >
> >
> > my point is that if you have multiple nodes advertising some prefix with
> different 3 tag combinations and you choose to only support 3 tags the
> result is undefined by this draft as to which tags propagate at the end, so
> the "order should be preserved" doesn't help
>
> I agree this could be a problem if you have this situation but I don’t see
> how advertising the tags in any particular order rectifies it. Also, since
> an OSPF domain is under a single administrative domain, I also don’t
> understand why anyone would configure such a situation. You could also have
> a problem if you have different nodes supporting different policies for the
> same prefix. Unless you can convince me, I’m going to stick with the IS-IS
> semantics for multiple tags. From RFC  5130.
>
>
>   The semantics of the tag order are implementation-dependent. That
>is, there is no implied meaning to the ordering of the tags that
>indicates a certain operation or set of operations need be performed
>based on the order of the tags. Each tag SHOULD be treated as an
>autonomous identifier that MAY be used in policy to perform a policy
>action. Whether or not tag A precedes or succeeds tag B SHOULD not
>change the meaning of the tag set. However, when propagating TLVs
>that contain multiple tags between levels, an implementation SHOULD
>preserve the ordering such that the first tag remains the first tag,
>so that implementations that only recognize a single tag will have a
>consistent view across levels.
>
>
>
> >
> >
> >
> >
> >>
> >>
> >> "
> >> This sub-TLV will carry one or more 32-bit unsigned integer values
> >> that will be used as administrative tags.
> >> "
> >>
> >>
> >> IMO behavior when none are carried nees to be specified if this is
> mandated. is that a MUST in fact?
> >>
> >
> >  The sub-TLV is optional so if it isn’t specified than there are no tags
> to match. What am I missing here?
> >
> > it says "one or more" so the sub=-tlv without anything has no semantics.
> is that an operational error, is that normal (then why does the draft say
> one or more). it's a nit but those nits can be ugly in interops
>
> I clearly state that the sub-TLV is optional.
>
> Thanks,
> Acee
>
>
> >
> >
> >

Re: [Lsr] bunch comments on https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-admin-tags

[Tony Przygienda]

hey Acee, inline


On Wed, Feb 28, 2024 at 3:30 AM Acee Lindem  wrote:

> Hi Tony,
>
> Thanks for the review.
>
> On Feb 27, 2024, at 04:51, Tony Przygienda  wrote:
>
> Reading the draft quickly, here's bunch of observations
>
> "
>
>An OSPF router supporting this specification MUST be able to
>advertise and interpret at least one 32-bit tag for all type of
>prefixes.  An OSPF router supporting this specification MAY be able
>to advertise and propagate multiple 32-bit tags.  The maximum tags
>that an implementation supports is a local matter depending upon
>supported applications using prefix tags.
> "
>
> Since different implementations may support different amount of tags I see 
> that the draft says
>
> "
> When propagating multiple tags, the order
>of the the tags SHOULD be preserved.
>
> "
>
> this is IMO not good enough in case where two nodes advertise same prefix 
> with multiple tags, possibly differing or in different order. Some kind of 
> ordering is necessary then as well AFAIS.
>
>
> I guess I don’t see the problem. A policy would look for a specific tag
> and take a specific action.
>
> Note that for IS-IS tags so require ordering, see section 4 of
> https://datatracker.ietf.org/doc/rfc5130/.
> I could possibly appropriate some of this text as it applies to OSPF.
>
>
my point is that if you have multiple nodes advertising some prefix with
different 3 tag combinations and you choose to only support 3 tags the
result is undefined by this draft as to which tags propagate at the end, so
the "order should be preserved" doesn't help



>
>
>
>
>
> "
>This sub-TLV will carry one or more 32-bit unsigned integer values
>that will be used as administrative tags.
> "
>
> IMO behavior when none are carried nees to be specified if this is mandated. 
> is that a MUST in fact?
>
>
>  The sub-TLV is optional so if it isn’t specified than there are no tags
> to match. What am I missing here?
>

it says "one or more" so the sub=-tlv without anything has no semantics. is
that an operational error, is that normal (then why does the draft say one
or more). it's a nit but those nits can be ugly in interops


>
>
>
>
> Moreover we already have a tag in OSPFv2 on type-5 and type-7 and opaque can 
> advertise more tags. How do those interact ?
>
>
>
> I have this text in section 4 to provide backward compatibility:
>
>When tags are advertised for AS External or NSSA LSA prefixes, the
>
>existing tag in the OSPFv2 and OSPFv3 AS-External-LSA and NSSA-LSA
>encodings SHOULD be utilized for the first tag.  This will facilitate
>backward compatibility with implementations that do not support this
>specification.
>
>
oh, I missed that. sorry.


>
> Thanks,
> Acee
>
>
>
>
> that's it for the first
>
> thanks
>
> -- tony
>
>
> ___
> 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] bunch comments on https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-admin-tags

[Tony Przygienda]

Reading the draft quickly, here's bunch of observations

"

   An OSPF router supporting this specification MUST be able to
   advertise and interpret at least one 32-bit tag for all type of
   prefixes.  An OSPF router supporting this specification MAY be able
   to advertise and propagate multiple 32-bit tags.  The maximum tags
   that an implementation supports is a local matter depending upon
   supported applications using prefix tags.
"

Since different implementations may support different amount of tags I
see that the draft says

"
When propagating multiple tags, the order
   of the the tags SHOULD be preserved.

"

this is IMO not good enough in case where two nodes advertise same
prefix with multiple tags, possibly differing or in different order.
Some kind of ordering is necessary then as well AFAIS.


"
   This sub-TLV will carry one or more 32-bit unsigned integer values
   that will be used as administrative tags.
"

IMO behavior when none are carried nees to be specified if this is
mandated. is that a MUST in fact?


Moreover we already have a tag in OSPFv2 on type-5 and type-7 and
opaque can advertise more tags. How do those interact ?

that's it for the first

thanks

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

Re: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 - 12/09/2023)

[Tony Przygienda]

Huaimo, first, I fail to see how 8202 has anything to do with this
discussion.

Did you try to implement and deploy 5311 in real networks and seen the
operational impact ? and are you suggesting that we need to have that
deployed as precondition for big-tlv idea ?

'nuff said ...

-- tony

On Thu, Dec 7, 2023 at 3:12 PM Huaimo Chen 
wrote:

> Hi Tony,
>
>
>
> My responses are inline below with [HC].
>
>
>
> Best Regards,
>
> Huaimo
>
>
>
> practically speaking "backwards compatibility" here is restricted by the
> fact that
>
>
>
> 1) we have in most largest networks de facto mp-tlv deployed and relied on
> for operations implemented by all major vendors.
>
> 2) we cannot encode mp-tlv deployed in parallel with "something new that
> we flip over once e'one has it" since the encoding space is limited and
> there are deployments that consume on some node so many fragments
> re-encoding twice until cut over would immediately break those networks
>
>
>
> *[HC]: We have encoded TLVs > 255 in two different ways (or say, deployed
> in parallel) already. *
>
> *RFC 8202 specifies one way for IID-TLV (TLV 7) > 255 on page 4-6 (quoted
> some text below for your convenience). *
>
>   “A single IID-TLV will support advertisement of up to 126 ITIDs.  If
>
>multiple IID-TLVs are present in an IIH PDU, the supported set of
>
>ITIDs is the union of all ITIDs present in all IID-TLVs.”
>
> *RFC5311 defines another way for extended IS reachability TLV 22 and
> MT-ISN TLV 222 > 255, in which two new TLVs: IS Neighbor Attribute TLV 23
> and MT IS Neighbor Attribute TLV 223, are defined. Some texts from RFC 5311
> are quoted below for your convenience.*
>
>   “If the attribute information does not conflict, it MUST be
>
>considered additive.”
>
>   “In cases where information about the same neighbor/link/attribute
>
>appears in both TLV 22 and TLV 23 (or TLV 222 and TLV 223 for the
>
>same MTID) then the information in TLV 22 (or TLV 222) MUST be used
>
>and the information in TLV 23 (or TLV 223) MUST be ignored.”
>
>   “Utilization of the new TLVs for neighbor attribute information would
>
>provide additional benefits that include:
>
>Easier support for a set of TE information associated with a single
>
>link that exceeds the 255-byte TLV limit by allowing the
>
>interpretation of multiple TLVs to be considered additive rather
>
>than mutually exclusive.”
>
> *These two different ways do not affect each other. There is no flip over. *
>
> *A new way for TLVs > 255 will not affect any existing way. There will not be 
> any flip over.*
>
>
>
>
>
> Corollary I: a flag day on such networks is NOT possible unless it's
> seamlessly flipping to something new while disabling old
>
>
>
> *[HC]: Corollary 1 seems not valid since the Theorem on which Corollary 1
> based is not valid. The Theorem is 1) and 2) above. The Theorem is not
> valid (or true) since 2) is false.*
>
>
>
> Collorary II: no matter how many times something that does not meet those
> 2 criteria is suggested is repeated ad nauseam it will not make it
> practically relevant or feasible.
>
>
>
> *[HC]:* *Corollary 2 seems not valid since the Theorem on which Corollary
> 2 based is not valid.*
>
>
>
> what we need is documentation to the extent possible of existing mp-tlv
> and framework for new tlv/sub-tlv/sub.. to describe intended behavior in
> case of mp-tlv of those. All in distributed fashion without gating it on a
> single include file ;-)  gathering documentation about existing is laudable
> and could be attempted in an application draft if someone is willing
> (TonyL's statements about that are true however). mp-tlv draft should
> probably add that every new draft doing new tlv/sub-tlv has to provide a
> mp-tlv section then (and make sure that it does not break recursion of all
> including parent hierarchy in some way [i.e. it's of no use to say that a
> sub-tlv has mp-tlv capability if the partent doesn't since the parent
> cannot repeat and will never have space hence for more than one sub-tlv
> already due to length restrictons)
>
> *[HC]: Some issues on the draft are raised in the LSR mailing list.*
>
>
>
> all that has been repeated enough already and no matter of wishful
> thinking and ASCII text will shift this reality on the ground
>
> *[HC]: More discussions, more understanding on MP-TLV and Big-TLV.*
>
>
>
> -- tony
>
>
>
> On Tue, Dec 5, 2023 at 8:11 AM Les Ginsberg (ginsberg)  40cisco@dmarc.ietf.org> wrote:
>
> Folks –
>
>
>
> The term “backwards compatibility” is getting abused here.
>
>
>
> What does “backwards compatibility” mean in the context of a routing
> protocol like IS-IS?
>
>
>
> It means that protocol extensions can be *advertised and safely used in
> the presence of legacy nodes (*which do not understand the new
> advertisements).
>
>
>
> Neither MP nor Big-TLV are backwards compatible.
>
>
>
> The authors of MP draft do not claim it is backwards compatible.
>
>
>
> The authors of 

Re: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 - 12/09/2023)

[Tony Przygienda]

On Thu, Dec 7, 2023 at 7:52 AM Gyan Mishra  wrote:

> ...
> Gyan> What Bruno is trying to provide I think strengthens the draft
> with the MUST normative language for enable/disable configuration
> controls.  As this is pre standard implementation if the devices go out of
> compliance immediately that is “ok”  as I see it all during incubation
> period trailblazing the new features and comes with the territory.  So they
> would just have to upgrade to RFC standard version to be back to
> compliance.
>

more unwise words were seldom spoken
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 - 12/09/2023)

[Tony Przygienda]

practically speaking "backwards compatibility" here is restricted by the
fact that

1) we have in most largest networks de facto mp-tlv deployed and relied on
for operations implemented by all major vendors.
2) we cannot encode mp-tlv deployed in parallel with "something new that we
flip over once e'one has it" since the encoding space is limited and there
are deployments that consume on some node so many fragments re-encoding
twice until cut over would immediately break those networks

Corollary I: a flag day on such networks is NOT possible unless it's
seamlessly flipping to something new while disabling old

Collorary II: no matter how many times something that does not meet those 2
criteria is suggested is repeated ad nauseam it will not make it
practically relevant or feasible.

what we need is documentation to the extent possible of existing mp-tlv and
framework for new tlv/sub-tlv/sub.. to describe intended behavior in case
of mp-tlv of those. All in distributed fashion without gating it on a
single include file ;-)  gathering documentation about existing is laudable
and could be attempted in an application draft if someone is willing
(TonyL's statements about that are true however). mp-tlv draft should
probably add that every new draft doing new tlv/sub-tlv has to provide a
mp-tlv section then (and make sure that it does not break recursion of all
including parent hierarchy in some way [i.e. it's of no use to say that a
sub-tlv has mp-tlv capability if the partent doesn't since the parent
cannot repeat and will never have space hence for more than one sub-tlv
already due to length restrictons)

all that has been repeated enough already and no matter of wishful thinking
and ASCII text will shift this reality on the ground

-- tony

On Tue, Dec 5, 2023 at 8:11 AM Les Ginsberg (ginsberg)  wrote:

> Folks –
>
>
>
> The term “backwards compatibility” is getting abused here.
>
>
>
> What does “backwards compatibility” mean in the context of a routing
> protocol like IS-IS?
>
>
>
> It means that protocol extensions can be *advertised and safely used in
> the presence of legacy nodes (*which do not understand the new
> advertisements).
>
>
>
> Neither MP nor Big-TLV are backwards compatible.
>
>
>
> The authors of MP draft do not claim it is backwards compatible.
>
>
>
> The authors of Big-TLV claim it is “backwards compatible” – but this is a
> false statement. Any attempt to use Big-TLV advertisements in the presence
> of legacy nodes will result in inconsistent and potentially dangerous
> behavior.
>
> Big-TLV authors like to say “you can send Big-TLV but not use it until all
> nodes support it” – but this does meet the criteria for backwards
> compatibility. If Big-TLV were “backwards compatible” there would be no
> need for a capability advertisement to determine when it is safe to use the
> advertisements.
>
>
>
>Les
>
>
>
> *From:* li_zhenqi...@hotmail.com 
> *Sent:* Monday, December 4, 2023 10:35 PM
> *To:* Huaimo Chen ; Les Ginsberg (ginsberg) <
> ginsb...@cisco.com>; Tony Li ; Linda Dunbar <
> linda.dun...@futurewei.com>
> *Cc:* Yingzhen Qu ;
> draft-pkaneria-lsr-multi-...@ietf.org; lsr 
> *Subject:* Re: Re: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv
> (11/17/2023 - 12/09/2023)
>
>
>
> Hello All,
>
>
>
> It seems Big-TLV is backward compatible. Backward compatible is an
> important point that should be considered when we introduce new features in
> a protocol, especially the widely used protocols like ISIS, BGP etc.
>
>
> --
>
> Best Regards,
>
> Zhenqiang Li
>
> China Mobile
>
> li_zhenqi...@hotmail.com
>
>
>
> *From:* Huaimo Chen 
>
> *Date:* 2023-12-04 21:57
>
> *To:* Les Ginsberg (ginsberg) ; Tony
> Li ; Linda Dunbar 
>
> *CC:* Yingzhen Qu ;
> draft-pkaneria-lsr-multi-...@ietf.org; lsr 
>
> *Subject:* Re: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv
> (11/17/2023 - 12/09/2023)
>
> Hi Les,
>
>
>
> My responses are inline below with [HC].
>
>
>
> Best Regards,
>
> Huaimo
>
>
>
> Linda –
>
>
>
> When we have polarized positions (for whatever reasons), coming to
> consensus is often difficult. Each side tends to dismiss the arguments of
> the other – sometimes regardless of merit.
>
> So, maybe the following won’t help – but I am going to give it a try.
>
>
>
> Point #1: There are existing TLVs for which MP behavior was explicitly
> stated in existing RFCs and there are already many deployments that conform
> to those RFCs (see Introduction of MP draft for a list).
>
> If we choose to use a different encoding to support > 255 bytes for other
> codepoints, this both complicates implementations and confuses the
> definition of new protocol extensions. When defining a new codepoint should
> I choose MP or should I choose a different encoding? And what criteria can
> be used to make this choice a sensible one?
>
> And since MP is already REQUIRED for those TLVs where it was explicitly
> defined, we will always have to support that – at least for 

Re: [Lsr] Question on draft-qgp-lsr-isis-pics-yang

[Tony Przygienda]

per TLV may not be particularly good in lots of cases

1) some TLVs contain tons stuff which triggers all kind of "does that
support this" variants
2) most operators do not know ISIS TLV by heart but RFPs are basically
structured along RFCs so that's the resoluton I'm most concerned with

Generally, I think we will need a multi-axis representation or some kind of
groupings like "per RFC" for this to be easily consumable

I wouldn't know actually PICS belongs to ISO even, PICS was done under this
name in ATM as well (and called PICS Proforma, whatever the Proforma stood
for [ATM Forum was more test case oriented format], Joel will remember, he
was reading a lot of sci-fi paperbacks while we were hanging in there
around midnite while point by point was chewed ;-)

-- tony

On Fri, Nov 17, 2023 at 10:14 AM  wrote:

>
>
>
>
>
>
> Orange Restricted
>
> *From:* Lsr  *On Behalf Of *Acee Lindem
> *Sent:* Thursday, November 16, 2023 11:33 PM
> *To:* Les Ginsberg (ginsberg) 
> *Cc:* Loa Andersson ; lsr@ietf.org
> *Subject:* Re: [Lsr] Question on draft-qgp-lsr-isis-pics-yang
>
>
>
> Speaking as a WG contributor:
>
>
>
> Hi Les,
>
>
>
> I think a simpler name is better - perhaps ietf-isis-feature-support.yang
> with YANG prefix isis-fs would be better.  Which brings me to my next and
> more important point…
>
>
>
> Like carbon neutrality, everyone at the LSR WG meeting who had an opinion
> thought such a YANG model would be operationally useful. However, I think
> the level of granularity is key.
>
> [Bruno] +1
>
> I agree that the level of granularity is key.
>
> I’d rather call for a significant granularity (but I’d welcome any
> pushback).
>
> Personally, I don’t see why per TLV granularity would not be ok: it’s ok
> to implement which is more work, so just listing the supported TLV and
> sub-TLV should be doable. In any case, operators, pre-sales and support
> engineers will likely need this information some day. So let’s just fill it
> once for all and have it available for all persons.
>
> I’d would even call for more granularity. E.g. for RFC 5130, for “32-bit 
> Administrative Tag Sub-TLV 1”, “On receipt, an implementation MAY consider 
> only one encoded tag, in which case, the first encoded tag MUST be considered 
> and any additional tags ignored. »
>
> To me, if the WG bothered making such granularity at the 
> feature/TLV/implementation level, we need such granularity at the reporting 
> level. And that’s not theoretical, I had to check that for a project a month 
> ago. At best, it’s indicated in the vendors documentation, so the data is 
> there, so let’s make it friendly to digest. At worst, we need to involve 
> expensive people .
>
> If we want less granularity, let’s do less granularity in spec (everything is 
> MUST)
>
>
>
> https://datatracker.ietf.org/doc/html/rfc5130#section-3.1
>
>
>
> Thanks,
>
> --Bruno
>
>
>
>
>
> I believe that having a separate data node for each TLV/sub-TLV as was
> done in the example ietf-isis-pics-sr-mpls.yang module is way too
> granular to be useful. Rather, the YANG reporting should be done at the
> feature level. Also, does a distinction need to be made as to whether the
> IS-IS node supports the feature or both supports it and has it enabled
> (as would be the case for non-backward compatible features)?
>
>
>
> Thanks,
>
> Acee
>
>
>
> On Nov 16, 2023, at 15:30, Les Ginsberg (ginsberg) <
> ginsberg=40cisco@dmarc.ietf.org> wrote:
>
>
>
> Loa -
>
> I agree with you that simply "IS-IS Support" may not be the best choice.
> Although, the meeting minutes have not yet been posted, as I recall my
> response to Tony Li's suggestion of "IS-IS Support" was "Yes - something
> like that."
>
> The draft authors have not yet discussed this - but we will and share the
> proposed new name.
> Other suggestions welcomed.
>
>   Les
>
> -Original Message-
> From: Lsr  On Behalf Of Loa Andersson
> Sent: Thursday, November 16, 2023 2:06 AM
> To: lsr@ietf.org
> Subject: [Lsr] Question on draft-qgp-lsr-isis-pics-yang
>
> Working Group,
>
> During the presentation of draft-qgp-lsr-isis-pics-yang there was a
> rather strong opposition in the chat against using the ISO-term "PICS"
> in an IETF document.
>
> I think the term "Support" was suggested (excuse me if I missed
> something), but I'm not that impressed, and would rather like to see
> something like - "Supported Protocol Aspects".
>
> /Loa
> --
> Loa Anderssonemail: l...@pi.nu
> Senior MPLS Expert  loa.pi...@gmail.com
> Bronze Dragon Consulting phone: +46 739 81 21 64
>
> ___
> 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
>
>
>
> 
> Ce message et ses 

Re: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 - 12/09/2023)

[Tony Przygienda]

operational points to understand what support is in network duly noted and
yes, yang is probably best angle for now to include the capability per tlv

however, some observations below ...

On Tue, Nov 28, 2023 at 2:18 PM  wrote:

> Hi,
>
>
>
> This draft proposes advertisements which are out of spec from the point of
> existing RFCs and implementations.
>
> Enabling one router to send such advertisement while not all routers are
> upgraded to support this extension will harm the network, potentially very
> significantly and likely by surprise.
>
> That point is not acceptable to me as some networks are critical (e.g.,
> carry emergency calls from both mobile and wireline access). So I believe
> we need solutions to avoid this.
>
>
>
> A first easy solution, from the standpoint of this WG and vendors (rather
> than operators), is to “delegate” this work to operators. This requires
> operators to have the ability to control such advertisement.
>
> In my opinion, at minimum we need the following change:
>
> OLD: It is RECOMMENDED that implementations which support the sending of
> MP-TLVs provide configuration controls to enable/disable generation of
> MP-TLVs.
>
> NEW: It is REQUIRED that implementations which support the sending of
> MP-TLVs provide configuration controls to enable/disable generation of
> MP-TLVs.
>

overspecification of implementation AFAIS and since people will happily
ship stuff without this that will work (i.e. advertise and accept by
default always) I doubt there is much we will be able to do to enforce
that.  A protocol spec governs interoperability on the wire (and sometimes
computation since it's distributed) and starting to describe knobs required
is  that if even belongs into an applicability statement. already the
'RECOMMENDED' is really applicability AFAIS.


>
>
> I would also call for the following text
>
> NEW: By default, the sending of MP-TLV for the TLVs extended by this
> document SHOULD be disabled.
>

This will not happen since a benign upgrade of software in today's network
along those lines will immediately break stuff since e.g. adjacency will
all of a sudden not be advertised as is already done today. Or in other
words this tries to declare all the de-facto planet-wide deployed major
large scale implementations non-compliant. Our job is first, like doctors,
not to harm and this will harm and second, we have to drag existing stuff
along without flag days and reality will not bend to some unrealistic text
in an ASCII document.  And no, trying to "change configuration during
update" in a benign way can 1) cause massive problems in real deployments
IME and is to be avoided and 2) if we add to config "enable" during upgrade
we basically defeat the purpose of this sentence having added tons
complexity and achieving nothing of note.

As sidenote: we have a somewhat similar case where we were forced to change
BGP default (BGP no policy not accepting) the repercussions were very
serious though far less than breaking IGP in a network (since the impact
was local for a node) and the pressure the operators were under (classical
misconfig/overrun of router with clean config) was also far more serious
than this case here.


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

Re: [Lsr] New Version Notification for draft-xu-lsr-flooding-reduction-in-clos-01.txt

[Tony Przygienda]

yeah, that's roughly the reality though you yourself basically say
link-state is being run now out of need/desperation ;-) (whether it's
open/r or bgp-ls hacks to generate equivalent of link-state, BGP is a
diffused computation and not distributed and hence will only provide you
topology if you engage into egregious hacks [which BGP _almost_ never does
;-]) ;-) and although bgp ended up being used mostly today for the original
routing (accident as much as anything else really) thnking through the
stuff from clean slate (for reason enconomic or aesthetic ;-) will most
likley lead clear thinking architecture folks to realize that what you need
a mix down to reduce state and link-state up for the top to decide and
possibly do smart stuff based on topology knowledge (and yes, controller on
top if the flows leave long and are known is not a bad thing at all AFAIS
[since we bassically move into provisioning and not control]). throiw DF
into the mix and nudge, nudge, we have something like this ;-)

the currently adopted flooding reduction drafts have their own merit in
general sense, I'm of course all for dist-topoflood due to its simplicuty,
based on previous art (MANET), good implementation experience (for me
personally in rift which is variant of this really [thanks Pascal]), not
only reduction but balancing and architecture which allows to parallelize
the necessary computations if you're a clever implementer to the point
they're neglectible overhead for the gains under heavy flooding ;-)

-- tony

On Sun, Nov 26, 2023 at 10:49 PM Jeff Tantsura 
wrote:

> I agree with all aforementioned comments.
>
> Wrt AI/ML networking - if a controller is used, what is required is link
> state exposure northbound and not link state protocol  in the fabric. (I
> could argue for RIFT though ;-))
> I’d urge you to take a look at Meta’s deployment  in their ML clusters
> (publicly available) - they use BGP as the routing protocol to exchange
> reachability (and build ECMP sets) and provide a backup if controller
> computed next hop goes away/before new one has been computed.
> Open R is used northbound to expose the topology (in exactly same way -
> BGP-LS could be used).
>
> To summarize: an LS protocol brings no additional value in scaled-out
> leaf-spine fabrics, without significant modifications -  it doesn’t work in
> irregular topologies such as DF, etc.
> Existing proposals - there are shipping implementations and experience in
> operating it, have proven their relative value in suitable deployments.
>
> Cheers,
> Jeff
>
> > On Nov 26, 2023, at 12:20, Acee Lindem  wrote:
> >
> > Speaking as WG member:
> >
> > I agree. The whole Data Center IGP flooding discussion went on years ago
> and the simplistic enhancement proposed in the subject draft is neither
> relevant or useful now.
> >
> > Thanks,
> > Acee
> >
> >> On Nov 24, 2023, at 11:55 PM, Les Ginsberg (ginsberg)  40cisco@dmarc.ietf.org> wrote:
> >>
> >> Xiaohu –
> >> I also point out that there are at least two existing drafts which
> specifically address IS-IS flooding reduction in CLOS networks and do so in
> greater detail and with more robustness than what is in your draft:
> >> https://datatracker.ietf.org/doc/draft-ietf-lsr-distoptflood/
> >> https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-spine-leaf-ext/
> >> I do not see a need for yet another draft specifically aimed at CLOS
> networks.
> >> Note that work on draft-ietf-lsr-isis-spine-leaf-ext was suspended due
> to lack of interest in deploying an IGP solution in CLOS networks.
> >> You are suggesting in draft-xu-lsr-fare that AI is going to change
> this. Well, maybe, but if so I think we should return to the solutions
> already available and prioritize work on them.
> >>Les
> >>  From: Lsr  On Behalf Of Tony Li
> >> Sent: Thursday, November 23, 2023 8:39 AM
> >> To: xuxiaohu_i...@hotmail.com
> >> Cc: lsr@ietf.org
> >> Subject: Re: [Lsr] New Version Notification for
> draft-xu-lsr-flooding-reduction-in-clos-01.txt
> >> Hi,
> >> What you’re proposing is already described in IS-IS Mesh Groups (
> https://www.rfc-editor.org/rfc/rfc2973.html) and improved upon in Dynamic
> Flooding (
> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-dynamic-flooding).
> >> Regards,
> >> Tony
> >>
> >>
> >> On Nov 23, 2023, at 8:29 AM, xuxiaohu_i...@hotmail.com wrote:
> >> Hi all,
> >> Any comments or suggestions are welcome.
> >> Best regards,
> >> Xiaohu
> >> 发件人: internet-dra...@ietf.org 
> >> 日期: 星期三, 2023年11月22日 11:37
> >> 收件人: Xiaohu Xu 
> >> 主题: New Version Notification for
> draft-xu-lsr-flooding-reduction-in-clos-01.txt
> >> A new version of Internet-Draft
> draft-xu-lsr-flooding-reduction-in-clos-01.txt
> >> has been successfully submitted by Xiaohu Xu and posted to the
> >> IETF repository.
> >>
> >> Name: draft-xu-lsr-flooding-reduction-in-clos
> >> Revision: 01
> >> Title:Flooding Reduction in CLOS Networks
> >> Date: 2023-11-22
> >> Group:Individual Submission
> >> Pages:6
> 

Re: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 - 12/09/2023)

[Tony Przygienda]

support adoption.

This draft is de-facto implemented and deployed already where it became
unavoidable. And it gets us further down the road without forcing flag day
on the networks lest older deployed versions break to best degree
achievable (which is a very important consideration these days, especially
on largest networks in existence). The reason I helped push this draft into
the light of day is that situation was becoming bits wild and forcing TLVs
to explain what multi-part semantics mean semantically is a necessary
hygiene we have to start to apply to the protocol (and yes, every draft
should have a normative section now for the multi-part just we had to
introduce the "duplicate-handling" in lots RFC based on bitter experience
[no great surprise if you think through protocol design clearly but IETF
was and is a bit of a juvenile learning by running a car into the ditch and
standing dazzled by the wreck after not having heeded the warnings about
ice on the road. Excuse my simile, probably too much caffeine this morning
;-) ]). And as such all this is ultimately the failing of the original ISO
spec even (so my gripe about IETF is bit misguided in this very case ;-),
no matter whether we keep pushing the creaking existing isis envelope or we
design a brand-new ISIS-for-IP-v2 we end up in the same problem due to
limited PDU size in flooding. Hence for any encoding using flooding to be
=semantically disambiguated the problem of repetition in different contexts
(within same parent TLV or new parent TLV etc in recursion) must be handled.

How we discover/advertise which MP-TLV is supported on an implementation is
still under debate as it should and draft is malleable but I think the
direction is the de-facto best way to deal with the situation as we have it
and dragging things into the future.

On Wed, Nov 22, 2023 at 1:00 PM Shraddha Hegde  wrote:

> Support the adoption as co-author of this draft.
>
>
>
> Juniper Business Use Only
>
> *From:* Les Ginsberg (ginsberg) 
> *Sent:* Saturday, November 18, 2023 12:01 AM
> *To:* Tony Przygienda ; Tony Li 
> *Cc:* Yingzhen Qu ;
> draft-pkaneria-lsr-multi-...@ietf.org; lsr 
> *Subject:* RE: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv
> (11/17/2023 - 12/09/2023)
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> +2 support adoption as coauthor
>
>
>
> (Chairs – is it really necessary for the authors to express support for
> their own draft? )
>
>
>
>Les
>
>
>
> *From:* Tony Przygienda 
> *Sent:* Friday, November 17, 2023 10:29 AM
> *To:* Tony Li 
> *Cc:* Yingzhen Qu ;
> draft-pkaneria-lsr-multi-...@ietf.org; lsr 
> *Subject:* Re: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv
> (11/17/2023 - 12/09/2023)
>
>
>
> +1, support adoptoinb as co-author
>
>
>
> On Fri, Nov 17, 2023 at 6:58 PM Tony Li  wrote:
>
>
>
> I support adoption as co-author.
>
>
>
> T
>
>
>
>
>
> On Nov 17, 2023, at 9:23 AM, Yingzhen Qu  wrote:
>
>
>
> Hi,
>
>
>
> This begins a WG adoption call for draft-pkaneria-lsr-multi-tlv: 
> draft-pkaneria-lsr-multi-tlv-04
> - Multi-part TLVs in IS-IS (ietf.org)
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-pkaneria-lsr-multi-tlv/__;!!NEt6yMaO-gk!GnuXZMa1l9V6gtK9gJ8eWmBcBcGdB2ZexW9CRp0WfFb_xnY2hFmutQD8PRfiypCOldw44Ef06oQ_JPaz$>
>
>
>
> Please send your support or objection to the list before December 9th,
> 2023. An extra week is allowed for the US Thanksgiving holiday.
>
>
>
> Thanks,
>
> Yingzhen
>
>
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!GnuXZMa1l9V6gtK9gJ8eWmBcBcGdB2ZexW9CRp0WfFb_xnY2hFmutQD8PRfiypCOldw44Ef06tw2lzt3$>
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 - 12/09/2023)

[Tony Przygienda]

+1, support adoptoinb as co-author

On Fri, Nov 17, 2023 at 6:58 PM Tony Li  wrote:

>
> I support adoption as co-author.
>
> T
>
>
> On Nov 17, 2023, at 9:23 AM, Yingzhen Qu  wrote:
>
> Hi,
>
> This begins a WG adoption call for draft-pkaneria-lsr-multi-tlv: 
> draft-pkaneria-lsr-multi-tlv-04
> - Multi-part TLVs in IS-IS (ietf.org)
> 
>
> Please send your support or objection to the list before December 9th,
> 2023. An extra week is allowed for the US Thanksgiving holiday.
>
> 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

Re: [Lsr] [Technical Errata Reported] RFC5340 (7649)

[Tony Przygienda]

errata is _not_ precise enough and the errata as proposed will cause more
problems than it solves from my experience

1. what is the semantics of 0 here? Don't care? Then 0 can be sent on
tunnel MTU and tunnel must stay up if one side sends "don't care"? If
semantics of 0 is "no value"  then same consideration applies AFAIS. So the
errata would need to say "0 is a reserved value that means in ospf virtual
link case that the field is not semantically valid and in other cases
represents value of 0" (which seems nonsensical a bit but seems to aim
towards what the errata tries to say)
2. fragmenting/non-fragmenting tunnels need be considered and explained in
the errata. GRE can optionally fragment (but not in v6 case AFAIR except
optionally for some wild header cases). In case of IPv6 we have
additionally the 1280 consideration on top AFAIR so if parts of the network
runs bigger MTU, GRE does NOT fragment and more than 1280 shows up we end
up with fragmented network IGP wise possibly. And I didn't even start to
talk about extension headers on which the RFC is really quiet about  ;-)
3. the MTU "largest datagram" needs to be errate'd to something more
precise on top. Is that _with_ tunnel headers, with/without tunnel encaps
etc (observe that e.g. vxlan is really an ip in ip and then ospf could be
carried in that) or _purely_ the OSPF IPv6 packet?

we fought those problems in ISIS forever with ugly corner cases (PPoE) I
need to explain every couple of years to another batch of system engineers .

I personally strongly suggest from experience to say "0 value" semantics is
everywhere a "don't care" value which implicitly does remove MTU mismatch
considerations in all kinds of interesting, ugly deployment cases. Other
option is that to mean "same value as set on my interface" or "default
value the protocol has set as constant" (in rift we chose that route from
experience but we were driven by strong ZTP requirements)

And BTW, any hardened stack has "ignore-mtu-mismatch" since this is a
pretty common case to find implementations advertising mismatched values in
weird tunnel/encaps cases (VLAN taggin' cases are a classic culprit beside
PPoE IME) and stuff gets knob'ed out then ...

that's of top of my head here ...

-- tony

On Wed, Sep 20, 2023 at 8:06 PM Acee Lindem  wrote:

> I’m beginning to get a feeling of Deja MTU…
>
> Acee
>
> > On Sep 19, 2023, at 19:15, RFC Errata System 
> wrote:
> >
> > The following errata report has been submitted for RFC5340,
> > "OSPF for IPv6".
> >
> > --
> > You may review the report below and at:
> > https://www.rfc-editor.org/errata/eid7649
> >
> > --
> > Type: Technical
> > Reported by: Owen DeLong 
> >
> > Section: A.3.3 (in part)
> >
> > Original Text
> > -
> > Interface MTU
> >  The size in bytes of the largest IPv6 datagram that can be sent
> >  out the associated interface without fragmentation.  The MTUs of
> >  common Internet link types can be found in Table 7-1 of [MTUDISC].
> >  Interface MTU should be set to 0 in Database Description packets
> >  sent over virtual links.
> >
> >
> > Corrected Text
> > --
> > Interface MTU
> >  The size in bytes of the largest IPv6 datagram that can be sent
> >  out the associated interface without fragmentation.  The MTUs of
> >  common Internet link types can be found in Table 7-1 of [MTUDISC].
> >  Interface MTU should be set to 0 in Database Description packets
> >  sent over OSPF virtual links. This rule should not be applied to
> tunnel
> >  or other software interfaces.
> >
> > Notes
> > -
> > OSPF Virtual links carry only OSPF packets so MTU negotiation is not
> needed and this provision makes sense. For interfaces that have an actual
> MTU, even though they may be "virtual" interfaces, they are not "virtual
> links" in the intended meaning of this paragraph. As such, this change will
> provide clarification and remove ambiguity from the current standard. At
> least one popular router vendor implements this RFC as MTU = 0 sent on all
> GRE interfaces which results in incompatibilities with most other router
> platforms which expect an actual value. The router vendor points to this
> provision in the RFCs as justification for their implementation. It is
> (arguably) a legitimate, if nonsensical interpretation of the existing text.
> >
> > Instructions:
> > -
> > This erratum is currently posted as "Reported". If necessary, please
> > use "Reply All" to discuss whether it should be verified or
> > rejected. When a decision is reached, the verifying party
> > can log in to change the status and edit the report, if necessary.
> >
> > --
> > RFC5340 (draft-ietf-ospf-ospfv3-update-23)
> > --
> > Title   : OSPF for IPv6
> > Publication Date: July 2008
> > Author(s)   : R. Coltun, D. 

Re: [Lsr] Comments on draft-chen-lsr-isis-big-tlv-00

[Tony Przygienda]

for what's it worth I +1 here Les & Tony obviously

-- tony

On Wed, Mar 29, 2023 at 5:30 PM Les Ginsberg (ginsberg)  wrote:

> Chris -
>
> > -Original Message-
> > From: Christian Hopps 
> > Sent: Tuesday, March 28, 2023 11:40 PM
> > To: Les Ginsberg (ginsberg) 
> > Cc: Christian Hopps ; Huaimo Chen
> > ;
> draft-chen-lsr-isis-big-tlv.auth...@ietf.org;
> > lsr@ietf.org
> > Subject: Re: [Lsr] Comments on draft-chen-lsr-isis-big-tlv-00
> >
> >
> > Supporting incremental upgrading routers in a network, with the
> > understanding that only the upgraded routers will take advantage of a new
> > feature -- is normal. In fact, it's what we normally strive for;
> flag-days are
> > bad.
>
> [LES:] Incremental deployment is possible - even expected - when a new
> advertisement is defined in support of some new feature.
> Nodes which don’t support the new feature aren’t making use of the new
> advertisement, so it does not impact them.
> That is not what we are dealing with when advertising more than 255 bytes
> of information. The need to do so does not arise because of the
> introduction of new sub-TLVs. It arises because the use of existing
> sub-TLVs in quantity exceeds 255 bytes.
> This means that all nodes in the network - whether they support the
> encoding of more than 255 bytes or not - may need to parse any or all of
> the advertised information. But when some of that information is advertised
> in a TLV that some nodes may not parse correctly (either because they don’t
> support MP or they don’t support Big TLV) then even "legacy nodes" are
> impacted.
>
> [LES:] Please see my reply to Bruno for further detail. And please look at
> and respond to the example I previously provided.
>
> >
> > In any case, there's a pivot here from "this doesn't technically work"
> to "it
> > technically works, but no one would want it" which is now a non-technical
> > assertion that I disagree with.
> >
> [LES:] I have no idea what triggers you to make this statement. At best it
> is a "cheap shot" at what I have stated which can be summarized as:
>
> a)Big TLV does not provide what the draft claims it does
> b)Having two ways to do the same thing is undesirable
>
>Les
>
> > Thanks,
> > Chris.
> >
> > "Les Ginsberg (ginsberg)"  writes:
> >
> > > Chris -
> > >
> > > 
> > > However, that is the missing piece, so it works if we also add a
> capability bit.
> > > If we have the capability bit you now know which routers are processing
> > the
> > > container TLV and which aren't. That should be enough info to route
> > correctly.
> > >
> > > Using a container TLV *and* a capability bit is not a free lunch, but
> it should
> > work to allow incremental deployment safely. If that's something we want
> as
> > a WG.
> > > 
> > >
> > > No - this does not work.
> > > Customer deploys some features. They expect all routers in the network
> to
> > be able to correctly calculate topology and correctly forward for the
> features
> > they support.
> > > They do not deploy a feature and expect only a subset of the routers
> in the
> > network that are configured to support the feature to correctly calculate
> > paths.
> > >
> > > There is no way to successfully support incremental deployment.
> > >
> > > I already gave an example in my comments below:
> > >
> > >> >> > [LES:] Consider the following simple example.
> > >> >> >
> > >> >> > Node A needs to send 10 sub-TLVs about a particular object –
> > >> >> > requiring more than 255 bytes to be sent.
> > >> >> >
> > >> >> > Some nodes in the network do not support reception of more than
> > 255
> > >> >> > bytes/object. Consider two such nodes.
> > >> >> >
> > >> >> > Node B, based on the local configuration, needs to be able to
> receive
> > >> >> > sub-TLVs 1,3,5,7,9 from A.
> > >> >> >
> > >> >> > Node C, based on local configuration, needs to be able to receive
> > >> >> > sub-TLVs 2,4,6,8,10 from A.
> > >> >> >
> > >> >> >
> > >> >> >
> > >> >> > There is no way that A can advertise all 10 sub-TLVs in a way
> which
> > >> >> > allows both B and C to correctly process the sub-TLVs they
> require.
> > >> >> >
> > >
> > >Les
> > >
> > >> -Original Message-
> > >> From: Christian Hopps 
> > >> Sent: Tuesday, March 28, 2023 9:52 AM
> > >> To: Les Ginsberg (ginsberg) 
> > >> Cc: Christian Hopps ; Huaimo Chen
> > >> ; draft-chen-lsr-isis-big-
> > tlv.auth...@ietf.org;
> > >> lsr@ietf.org
> > >> Subject: Re: [Lsr] Comments on draft-chen-lsr-isis-big-tlv-00
> > >>
> > >>
> > >> "Les Ginsberg (ginsberg)"  writes:
> > >>
> > >> > Chris -
> > >> >
> > >> > Please see inline - I'll try to conform to your request about ">>>"
> > quoting -
> > >> > but given that this style does not identify who made the comment, I
> > have
> > >> found
> > >> > in the past that this style becomes very hard to follow after a
> couple of
> > >> > replies.
> > >> > Though perhaps that could be said of any style. 
> > >>
> > >> Well in the ">>>" style my text that you were quoting would have 

Re: [Lsr] NewVersionNotificationfordraft-cheng-ospf-adjacency-suppress-00.txt

[Tony Przygienda]

So Les, your concern AFAIU it is maybe bit overwrought. Local (assuming
remote is the unplanned bouncer, in chain example B local A remote)
advertises its LSA with the link failed and that gets flooded immediately
(I assume the link local-remote is *not* a minimal cut in the topology so
there are paths to flood the whole network without the link coming up again
unlike the 3 router example) and then local does NOT advertise adjacency
until it's full no matter what which will take a bit of time. So even if
floods high-version remote LSA overriding the remote's initial low-version
LSA the bidirectional check fails as Acee points out. Then remote overrides
and remote and local only flood LSAs with adjacency in them after full
which takes some time in any case.  Adding additional signalling and
interdependencies between hellos and LSA origination seems to me shooting
at pretty little birds with canons somewhat due to involved
interdependencies.

I probably repeat partially what Acee said but it's my 2c

-- tony

On Wed, Mar 29, 2023 at 9:53 AM Les Ginsberg (ginsberg) 
wrote:

> Acee -
>
> So your proposal is to have the neighbor of the restarting router be
> responsible for ensuring that the Router LSA updates are done in the proper
> order.
> I agree this can work as well.
>
> I still think there is one element missing from your proposal i.e.,
> guaranteeing that the Router LSA update from the restarting router is
> flooded before (or at least in the same Link State Update packet) as the
> updated Router LSA from the neighbor - and that this order is maintained at
> each flooding hop throughout the network.
> This is likely to happen - but without some delay between flooding the
> updated Router LSA from the restarting router and the updated Router LSA on
> the neighbor there is still some risk.
>
>Les
>
> > -Original Message-
> > From: Acee Lindem 
> > Sent: Tuesday, March 28, 2023 2:19 PM
> > To: Les Ginsberg (ginsberg) 
> > Cc: Liyan Gong ; Tony Przygienda
> > ; chen.mengxiao ; lsr
> > ; Weiqiang Cheng ;
> > linchangwang 
> > Subject: Re: [Lsr]NewVersionNotificationfordraft-cheng-ospf-adjacency-
> > suppress-00.txt
> >
> > Hi Les
> >
> > > On Mar 28, 2023, at 4:44 PM, Les Ginsberg (ginsberg)
> >  wrote:
> > >
> > > (For some reason, email from you now goes into my Junk folder –
> delaying
> > my response. )
> > >  Acee –
> > >  Consider the simple topology:
> > >  A---B---C
> > >  A is the restarting router.
> > > C represents “the rest of the network” attached to B.
> > >  Router A goes down.
> > > Adjacency on B to A goes down.
> > > The LSPDB on C now has:
> > >  Router LSA B w no adjacency to A
> > > Router LSA A w adjacency to B (stale)
> > >  A comes up – adjacency between A and B forms.
> > > What happens next on C (and all the routers downstream) depends on
> > order.
> > >  Case #1
> > > New Router LSA B w adjacency to A arrives.
> >
> > With the change I proposed, Router B will not become adjacent to Router A
> > without getting an updated version of Router A’s LSA that doesn’t include
> > the link to Router B.
> >
> >
> >
> > > At this point, C believes there is two-way connectivity between A and B
> > because of the presence of the stale Router LSA A
> > > New Router LSA A w no adjacency to B arrives
> > > Now C has the up to date information
> > >  Case #2
> > > New Router LSA A w no adjacency to B arrives
> > > New Router LSA B w adjacency to A arrives
> > > C still sees no 2way connectivity between A and B
> > >  The reason you need to control the ordering is to prevent Case #1 from
> > occurring.
> > > Yes, this is a transient – LSPDB will eventually converge – but the
> duration
> > of “eventually’ depends on scale.
> > >  SA bit can be used to prevent Case #1 from ever occurring – or at
> least
> > make it very unlikely.
> >
> > The change I proposed will prevent it as well. Router B will request
> Router A’s
> > LSA and Router A will respond with the new version which doesn’t have the
> > link to Router B. Router B will respond with the more-recent version
> (see this
> > excerpt from RFC 2328 13.3):
> >
> >
> >
> >   (8) Else, the database copy is more recent. If the database copy
> >has LS age equal to MaxAge and LS sequence number equal to
> >  MaxSequenceNumber, simply discard the received LSA without
> >acknowledging it. (In this case, the LSA's LS sequence number
> is
> >wr

Re: [Lsr] NewVersionNotificationfordraft-cheng-ospf-adjacency-suppress-00.txt

[Tony Przygienda]

ok yes, I didn't think through the step 3 ...

thanks Les

-- tony

On Tue, Mar 28, 2023 at 11:44 AM Les Ginsberg (ginsberg) 
wrote:

> Tony -
>
>
>
> *From:* Tony Przygienda 
> *Sent:* Monday, March 27, 2023 5:11 PM
> *To:* Les Ginsberg (ginsberg) 
> *Cc:* Acee Lindem ; Liyan Gong <
> gongli...@chinamobile.com>; chen.mengxiao ; lsr <
> lsr@ietf.org>; Weiqiang Cheng ;
> linchangwang 
> *Subject:* Re: [Lsr]
> NewVersionNotificationfordraft-cheng-ospf-adjacency-suppress-00.txt
>
>
>
> I didn't say "bigger", I said "random" ;-}
>
> *[LES:] Ahhh…that makes all the difference. ***
>
>
>
> I tend to agree with SA bit solution though I don't grok how you can stop
> flooding with that precisely. especially since you cannot rely on sequence
> of hellos and DB sync packets arriving at the receiving node. And SA AFAIR
> assumes LLC or whatever while Acee's works on base spec ...
>
>
>
> *[LES:] Step 1: Send SA bit – neighbor continues to send Router LSA with
> no neighbor advertisement to the restarting router*
>
> *Step 2: Complete LSPDB sync – including Restarting router generating new
> Router LSA w no neighbors*
>
> *Step 3: Delay to allow updated Router LSA  from Restarting router to be
> flooded*
>
> *Step 4: Clear SA bit – neighboring routers can now advertise adjacency to
> the Restarting router*
>
> *Step 5: Restarting router generates new Router LSA advertising neighbors*
>
>
>
> *(To make this “extra reliable”, at Step 3 we can use your “random delay”
> strategy. **** )*
>
>
>
> *   Les*
>
>
>
> --- tony
>
>
>
> On Tue, Mar 28, 2023 at 8:04 AM Les Ginsberg (ginsberg) <
> ginsb...@cisco.com> wrote:
>
> Tony –
>
>
>
> It seems to me that the larger sequence # solution is less likely to work
> the more you use it. 
>
> In other words, if I restart once a month, each time I need to pick an
> “even bigger sequence #” to account for the starting point of the previous
> restart.
>
>
>
> I know that with a 32 bit sequence #, we have decades of updates
> available, but unless you save your most recent sequence # prior to restart
> you either have to make a generous WAG or risk the increasing likelihood
> that your WAG won’t be big enough.
>
>
>
> The SA bit logic is designed to allow the restarting router to control
> when the neighbors can safely resume advertising the neighbor to the
> restarting router.
>
> This has addressed problematic cases seen even at low scale in IS-IS
> because IS-IS does not have the equivalent of Exchange state on adjacency
> bringup.
>
> While I agree with Acee that historically this hasn’t been a significant
> issue with OSPF, as IGP scale increases the visibility of this issue
> becomes more likely.
>
>
>
> However, the problem has another aspect i.e., it is important that the
> updated LSA from the neighbor of the restarting router NOT be flooded prior
> to the updated LSA from the restarting router. Otherwise other routers in
> the network may prematurely think that two-way connectivity to the
> restarting router has been restored sooner than it actually has been.
> Neither the draft nor Acee’s alternative explicitly address this point.
> Proper use of the SA bit can address this aspect.
>
>
>
>Les
>
>
>
> *From:* Tony Przygienda 
> *Sent:* Monday, March 27, 2023 3:29 PM
> *To:* Acee Lindem 
> *Cc:* Liyan Gong ; chen.mengxiao <
> chen.mengx...@h3c.com>; Les Ginsberg (ginsberg) ; lsr
> ; Weiqiang Cheng ;
> linchangwang 
> *Subject:* Re: [Lsr]
> NewVersionNotificationfordraft-cheng-ospf-adjacency-suppress-00.txt
>
>
>
> thought about it. there are also other solutions to the problem (or rather
> to make it significantly less likely/shorter duration since perfect
> solution given we don't purge DB of an adjacenct router when we lose
> adjacency to it do not exist) such as e.g. choosing seqnr# on startup in a
> way that minimizes the problem (IMO simplest solution but only
> probabilistic).
>
>
>
> Acee's solution is significantly simpler and AFAIS will have roughly same
> behavior as the suggested draft. can be combined iwth the seqnr#
> recommendation (which I probably wouldn't do since large seqnr# on startups
> may trigger bugs in deployed, "not-so-hard-tested" implementations ;-)
>
>
>
> I see Acee's take as benign "over-compliance" to standard as we have it
> ;-) since the current wording does not say you MUST NOT do what he suggests
> ;-)
>
>
>
> -- tony
>
>
>
> On Tue, Mar 28, 2023 at 1:45 AM Acee Lindem  wrote:
>
> Hi Liyan,
>
>
>
> On Mar 27, 2023, a

Re: [Lsr] NewVersionNotificationfordraft-cheng-ospf-adjacency-suppress-00.txt

[Tony Przygienda]

I didn't say "bigger", I said "random" ;-}

I tend to agree with SA bit solution though I don't grok how you can stop
flooding with that precisely. especially since you cannot rely on sequence
of hellos and DB sync packets arriving at the receiving node. And SA AFAIR
assumes LLC or whatever while Acee's works on base spec ...

--- tony

On Tue, Mar 28, 2023 at 8:04 AM Les Ginsberg (ginsberg) 
wrote:

> Tony –
>
>
>
> It seems to me that the larger sequence # solution is less likely to work
> the more you use it. 
>
> In other words, if I restart once a month, each time I need to pick an
> “even bigger sequence #” to account for the starting point of the previous
> restart.
>
>
>
> I know that with a 32 bit sequence #, we have decades of updates
> available, but unless you save your most recent sequence # prior to restart
> you either have to make a generous WAG or risk the increasing likelihood
> that your WAG won’t be big enough.
>
>
>
> The SA bit logic is designed to allow the restarting router to control
> when the neighbors can safely resume advertising the neighbor to the
> restarting router.
>
> This has addressed problematic cases seen even at low scale in IS-IS
> because IS-IS does not have the equivalent of Exchange state on adjacency
> bringup.
>
> While I agree with Acee that historically this hasn’t been a significant
> issue with OSPF, as IGP scale increases the visibility of this issue
> becomes more likely.
>
>
>
> However, the problem has another aspect i.e., it is important that the
> updated LSA from the neighbor of the restarting router NOT be flooded prior
> to the updated LSA from the restarting router. Otherwise other routers in
> the network may prematurely think that two-way connectivity to the
> restarting router has been restored sooner than it actually has been.
> Neither the draft nor Acee’s alternative explicitly address this point.
> Proper use of the SA bit can address this aspect.
>
>
>
>Les
>
>
>
> *From:* Tony Przygienda 
> *Sent:* Monday, March 27, 2023 3:29 PM
> *To:* Acee Lindem 
> *Cc:* Liyan Gong ; chen.mengxiao <
> chen.mengx...@h3c.com>; Les Ginsberg (ginsberg) ; lsr
> ; Weiqiang Cheng ;
> linchangwang 
> *Subject:* Re: [Lsr]
> NewVersionNotificationfordraft-cheng-ospf-adjacency-suppress-00.txt
>
>
>
> thought about it. there are also other solutions to the problem (or rather
> to make it significantly less likely/shorter duration since perfect
> solution given we don't purge DB of an adjacenct router when we lose
> adjacency to it do not exist) such as e.g. choosing seqnr# on startup in a
> way that minimizes the problem (IMO simplest solution but only
> probabilistic).
>
>
>
> Acee's solution is significantly simpler and AFAIS will have roughly same
> behavior as the suggested draft. can be combined iwth the seqnr#
> recommendation (which I probably wouldn't do since large seqnr# on startups
> may trigger bugs in deployed, "not-so-hard-tested" implementations ;-)
>
>
>
> I see Acee's take as benign "over-compliance" to standard as we have it
> ;-) since the current wording does not say you MUST NOT do what he suggests
> ;-)
>
>
>
> -- tony
>
>
>
> On Tue, Mar 28, 2023 at 1:45 AM Acee Lindem  wrote:
>
> Hi Liyan,
>
>
>
> On Mar 27, 2023, at 06:36, Liyan Gong  wrote:
>
>
>
>
>
> Hi Acee,
>
>
>
> Thank you for sharing your idea about the draft. Because of the time
> limitation in the meeting, Let‘s continue here.
>
>
>
>
>
> 1. First, About your doubts about the existence of the problem, I would
> like to check whether I have elaborated it clearly through the following
> email and the presentation.
>
>
>
> It is a real problem we've actually seen and can be reproduced easily,
> you can actually try it out.
>
> I have no doubt that one could craft a test that would simulate the
> problem. My point was that in practice, the restarting Router-LSA is
> flooded to its neighbors during the restart and will be accepted by any
> neighbors in Exchange State or better.
>
>
>
>
>
>
>
> 2. About your proposed solution, we would like to share our comments.
>
>
>
> (1) Your solution does not work for other type of lsa except
> router-lsa. The blackhole still occurs for other type route.
>
>
>
> For example, Router B  has received the re-originated router lsa
> of router A, and router A both get into the full state. Now A is
> reachable through spf tree calculation.
>
> As a result, the external route is also reachable, since the type
> 5 lsa has not been re-originated.
>
>

Re: [Lsr] NewVersionNotificationfordraft-cheng-ospf-adjacency-suppress-00.txt

[Tony Przygienda]

thought about it. there are also other solutions to the problem (or rather
to make it significantly less likely/shorter duration since perfect
solution given we don't purge DB of an adjacenct router when we lose
adjacency to it do not exist) such as e.g. choosing seqnr# on startup in a
way that minimizes the problem (IMO simplest solution but only
probabilistic).

Acee's solution is significantly simpler and AFAIS will have roughly same
behavior as the suggested draft. can be combined iwth the seqnr#
recommendation (which I probably wouldn't do since large seqnr# on startups
may trigger bugs in deployed, "not-so-hard-tested" implementations ;-)

I see Acee's take as benign "over-compliance" to standard as we have it ;-)
since the current wording does not say you MUST NOT do what he suggests ;-)

-- tony

On Tue, Mar 28, 2023 at 1:45 AM Acee Lindem  wrote:

> Hi Liyan,
>
> On Mar 27, 2023, at 06:36, Liyan Gong  wrote:
>
>
> Hi Acee,
>
>
> Thank you for sharing your idea about the draft. Because of the time
> limitation in the meeting, Let‘s continue here.
>
>
>
> 1. First, About your doubts about the existence of the problem, I would
> like to check whether I have elaborated it clearly through the following
> email and the presentation.
>
>
> It is a real problem we've actually seen and can be reproduced easily,
> you can actually try it out.
>
> I have no doubt that one could craft a test that would simulate the
> problem. My point was that in practice, the restarting Router-LSA is
> flooded to its neighbors during the restart and will be accepted by any
> neighbors in Exchange State or better.
>
>
>
> 2. About your proposed solution, we would like to share our comments.
>
>
> (1) Your solution does not work for other type of lsa except
> router-lsa. The blackhole still occurs for other type route.
>
>
> For example, Router B  has received the re-originated router lsa
> of router A, and router A both get into the full state. Now A is
> reachable through spf tree calculation.
>
> As a result, the external route is also reachable, since the type
> 5 lsa has not been re-originated.
>
>
> I don’t think this can happen. Once both router A get into full sate,
> Router A will have requested and received all its stale (i.e., pre-restart
> LSAs) from Router A and will have either refreshed or purged them based it
> current state.
>
>
> (2) Your solution can be classified into the solution 2) mentioned in
> our presentation and more complicated.
>
>   It is a larger modification to the basic ospf protocol, equivalent
> to abandon the action of DD exchange. It will cause more risk and
> pressure for all the routers in the network.
>
> I disagree strongly that my solution is more complicated, it only add the
> Router-LSA to the link state request list. I don’t see how this could be
> judged more complex than using an independent hand-shake involved. OSPF
> Hello to keep Router B from forming an adjacency. BTW, the use case(s) and
> precisely how the mechanism will be used was specified in the slides but
> not the draft. The draft only says:
>
>With the proposed mechanism, the starting router's
>
>neighbors will suppress advertising an adjacency to the starting
>router until the starting router has been able to propagate newer
>
> versions of LSAs, so that the temporary blackholes can be avoided.
>
> I’m not saying this should be normative text, just a better example of
> how the mechanism would be used.
>
> Also, if you do republish, please include the WG in the draft name so it
> can easily be found, i.e., draft-cheng-lsr-ospf-adjacency-suppress-00
>
>
> Thanks,
> Acee
>
>
>
> Hope to get your opinion, Thanks.
>
>
> Best Regards,
>
> Liyan
>
>
> 邮件原文
> *发件人：*Liyan Gong  
> *收件人：*"acee.ietf" 
> *抄 送: *"chen.mengxiao" ,Les Ginsberg  <
> ginsb...@cisco.com>,lsr  ,Weiqiang Cheng  <
> chengweiqi...@chinamobile.com>,linchangwang  
> *发送时间：*2023-03-09 11:27:58
> *主题：*
> Re: [Lsr]NewVersionNotificationfordraft-cheng-ospf-adjacency-suppress-00.txt
>
> Hi Acee,
>
>
> Yes,it is a real problem we've actually seen.
>
>
> Especially when the neighbor Rouer B has many more LSAs than the Restart
> Router A.
>
>
> In this scenario, the time between the following two key points will be
> prolonged greatly.
>
>
> Further discussion is welcome, thanks a lot.
>
>
> Best Regards,
>
> Liyan
>
>
>
>
> 邮件原文
> *发件人：*Acee Lindem  
> *收件人：*Liyan Gong  
> *抄 送: *"Mengxiao.Chen" ,Les Ginsberg  <
> ginsb...@cisco.com>,lsr  ,Weiqiang Cheng  <
> chengweiqi...@chinamobile.com>,linchangwang  
> *发送时间：*2023-03-08 02:34:17
> *主题：*
> Re: [Lsr] New VersionNotificationfordraft-cheng-ospf-adjacency-suppress-00.txt
>
> Hi Liyan,
>
> This is very unlikely to happen as flooding between the routers commences
> as soon as they reach Exchange state. I’m wondering if you’ve actually seen
> this situation or it is hypothetical.
>
> In any case, I have a better solution which wouldn’t add the delay for 

Re: [Lsr] Robert Wilton's No Objection on draft-ietf-lsr-isis-flood-reflection-11: (with COMMENT)

[Tony Przygienda]

Robert, thanks for the review

* tunnel level, ok, I clarify that it means "by some mechanism the tunnel
type supports"
* good catch on 01/02, it's actually R10 and R11

-- tony


On Tue, Nov 29, 2022 at 5:32 PM Robert Wilton via Datatracker <
nore...@ietf.org> wrote:

> Robert Wilton has entered the following ballot position for
> draft-ietf-lsr-isis-flood-reflection-11: 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-flood-reflection/
>
>
>
> --
> COMMENT:
> --
>
> Hi,
>
> Thanks for this document, I found it pretty clear and easy to read
> (although, I
> skipped the TLV specifications).
>
> A couple of minor comments/nits that may help improve the doc:
>
> Minor level comments:
>
> (1) p 18, sec 9.  Security Considerations
>
>subversion of the IS-IS level 2 information.  Therefore, at tunnel
>level steps should be taken to prevent such injection.
>
> I didn't find the term "tunnel level" to be particularly clear, either
> here, or
> below.
>
> Nit level comments:
>
> (2) p 8, sec 3.  Further Details
>
>One possible solution to this problem is to expose additional
>topology information into the L2 flooding domains.  In the example
>network given, links from router 01 to router 02 can be exposed into
>L2 even when 01 and 02 are participating in flood reflection.  This
>information would allow the L2 nodes to build 'shortcuts' when the L2
>flood reflected part of the topology looks more expensive to cross
>distance wise.
>
> Should 01 and 02 be R1 and R2 respectively?
>
> Regards,
> Rob
>
>
>
> ___
> 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] Questions on draft-white-lsr-distoptflood

[Tony Przygienda]

ack, good to see I grok'ed what you said and we on same page. Next version
will incorporate

-- tony

On Mon, Nov 28, 2022 at 8:04 PM Les Ginsberg (ginsberg) 
wrote:

> Tony –
>
>
>
> I will wait for the next draft version – seems like we are in general
> agreement.
>
>
>
> I would caution regarding periodic CSNPs on P2P networks. Yes – many
> implementations support this – but not all do so by default. So assuming
> that periodic CSNPs are sent on P2P circuits and therefore nothing needs to
> be said in this regard isn’t justified.
>
>
>
>Les
>
>
>
> *From:* Tony Przygienda 
> *Sent:* Monday, November 28, 2022 10:27 AM
> *To:* Les Ginsberg (ginsberg) 
> *Cc:* draft-white-lsr-distoptflood.auth...@ietf.org; lsr@ietf.org
> *Subject:* Re: [Lsr] Questions on draft-white-lsr-distoptflood
>
>
>
>
>
>
>
> On Mon, Nov 28, 2022 at 9:39 AM Les Ginsberg (ginsberg) <
> ginsb...@cisco.com> wrote:
>
> Tony –
>
>
>
> In the interest of brevity, I am not going to respond in detail to each of
> your points. My reply focuses on two things.
>
>
>
> okey, thanks, point 1) answered in other meail.
>
>
>
> ...
>
>
>
> The mechanisms proposed in draft-ietf-lsr-dynamic-flooding are analogous
> to what is used for DIS election and (more recently) for selecting the
> winning FAD for a given flex-algo. Given the significant deployment of
> flex-algo and the long history of DIS election, I am surprised at the
> degree of concern you have for the use of these mechanisms.
>
>
>
> well, DIS is on a single LAN, not network wide so you can break a single
> LAN.  I stay out the FAD discussion given how fresh the stuff is ;-) Plus,
> a broken FAD would break a FAD (or in other one topology flavor/parts of
> network AFAIR), a broken flood reduction would brck the whole network.
>
>
>
>
>
> 2)Regarding the use of PSNPs…you propose to send a PSNP (once apparently)
> which has the LSP entries for all the LSPs which you chose NOT to flood to
> a given node (minus any LSPs for which you may have received an explicit
> ack) in the most recent time interval - suggested to be one second.
>
>
>
> ack
>
>
>
> What will happen when you send this? Let’s use a simple example where one
> LSP was selectively flooded – call it A.00-01(Seq #100).
>
> NOTE: This example assumes a P2P circuit.
>
>
>
> a)Neighbor receives the PSNP, already has A.00-01(Seq #100) in its LSPDB –
> no action taken. All is good.
>
> b)Neighbor receives the PSNP, does not have A.00-1(Seq #100) in its LSPDB
> – sends a PSNP back to the originator requesting that the LSP be flooded.
> At this point I assume normal flooding procedures apply i.e., SRM flag is
> set, causing the LSP to be flooded, and I assume SRM remains set until the
> LSP is acknowledged.
>
> All is good – but the additional flooding is likely to be redundant as the
> node which had the responsibility for sending this LSP to your neighbor
> should be doing so reliably.
>
>
>
> yepp. During normal flooding it should be minuscule overhead. During heavy
> flooding we batch PSNP, about as good as we can do AFAIS.
>
>
>
> c)Neighbor does not receive the PSNP. If the neighbor does not have
> A.00-01(Seq #100) in its database, the one time sending of the special PSNP
> won’t trigger sending of the missing LSP. As the draft does not propose
> that the special PSNP be resent, I assume during the next time interval the
> only LSP entries that would be sent in the next special PSNP would be other
> LSPs that were partially flooded in the subsequent interval – not A.00-01.
>
>
>
> yepp, in this scenario where our belt breaks we have the CSNP suspenders
> since we cannot differentiate this from scenario a). Not that different
> from normal ISIS where on a CNSP a node sends a PSNP to get a missing LSP.
> We don't retransmit that either AFAIR (which would be a possibility in the
> protocol though a complex one). Unless my brain skipped a cycle here and
> I'm too lazy right now to dig through the implementation/10589 to remember
> ...
>
>
>
>
>
> Periodic CSNPs can be dropped as well, but as periodic CSNPs are
> guaranteed to be sent continuously at some interval and they cover the
> entire LSPDB, reliability of the Update process is assured. Under some
> pathological conditions it might take a significant amount of time to
> converge, but it is assured.
>
>
>
> NOw, if you assume that we drop PSNP and _then_ we drop CSNP then we end
> up in the discussion of "how much do you lose until protocol stops
> converging" and discover that reduction always slows down convergence,
> makes it more fr

Re: [Lsr] Questions on draft-white-lsr-distoptflood

[Tony Przygienda]

e discussed and frankly, it's really just an implemenation
variable, we don't even have to make constant. It's state compression vs.
responsiveness vs. context change in implementation. Normal discussions.


>
>
> If you consider the cost of sending/receiving a PSNP is roughly equivalent
> to the cost of sending/receiving an LSP, you will have created the
> equivalent of full mesh flooding every second since every node can expect
> to receive a PSNP from every neighbor whenever an LSP update is triggered.
> NOTE: The relative impact will be more noticeable when a small # of LSPs
> are updated.
>

the point of PSNPs is that we pack them and you only send a small header so
no, I think the cost will be significantly lower. We could have optimized
further and say " _if_ something is a reflooder it should NOT send the PSNP
to the non-reflooders." since those are "leaves" hanmging off but this
makes algoirithm less robust on e.g. hash mismatches during convergnece


>
>
> And since the node which is responsible for flooding to a particular
> neighbor should be doing so reliably, under most circumstances the special
> PSNP is not needed at all – so why choose an aggressive time interval for
> sending it?
>

I read you. Basically anything much faster than CSNP intervals is fine
AFAIS. And ideally, yes, it should make for significant PSNP packing under
heavy flooding and not cuase the other nodes to request the LSP since they
already got it ;-)


>
>
> Periodic CSNPs are sufficient – are typically done at a slow rate (10s of
> seconds) – and apparently (from your response below) you seem to intend to
> send periodic CSNPs also (though the draft does not mention this). I am not
> seeing the benefit of the special PSNP – but if you are committed to this,
> please provide a more robust description of how they should be used in the
> draft and an analysis of the benefits under some realistic flooding
> scenarios.
>

we omitted the CSNP since nothing changes. And yes, we can say CSNPs stay
of course and we should say please, please send CSNP on p2p even if 10589
doesn't say so (but almost all implemenations I know do it by default
anyway since long time).

so yes, very good points you make and feel free to suggest verbiage to
cover it or otherwise we take care of that in next releasee

-- tony




>
>
>Les
>
>
>
>
>
> *From:* Tony Przygienda 
> *Sent:* Friday, November 25, 2022 1:06 AM
> *To:* Les Ginsberg (ginsberg) 
> *Cc:* draft-white-lsr-distoptflood.auth...@ietf.org; lsr@ietf.org
> *Subject:* Re: [Lsr] Questions on draft-white-lsr-distoptflood
>
>
>
>
>
> Les, bits delay since I had to think a bits about your comment to do it
> justice and it's bit long'ish
>
> 1. So, to start with a cut and dry summary and reasoning for it, I am
> firmly against adding signaling to the whole thing by some means (or rather
> any procedures to act upon distribution of info about the algorithm used by
> any of the nodes involved, i.e. I'm ok with having the algorithm advertised
> *solely* for info purposes with me though I don't see what function it
> serves except detecting nodes that do not reduce yet in transition of a
> network or maybe, as you say, detect algorithm mismatch). More detailed
> reasoning follows:
>
> a. First reason is the fact that the additional flexibility of maybe
> having one day some better hash algorithm will add *very* serious amount
> of complexity in implementation/behavior in case we are talking about
> adding it to the centralized variant of the dynamic flooding draft and
> having a leader advertising the algorithm.
> i. backup machinery needs to be added/spec'ed properly. What does the
> network do if backup has different algorithm than the current leader? First
> we would have a transition phase, some nodes have old algorithm, some the
> old, network may stop converging for a bit that way, worst case we
> partition the PGL algorithm advertisement from new nodes so we have to wait
> CSNP * diameter etc. Big network bleep is the result. I know there is lots
> verbiage in the dynamic flooding draft but I know the reality of
> implementations of such things and they are extraordinarily high for the
> bit flexibility the whole thing would buy us I see you suggesting.
>ii. What happens if PGL doesn't say anything? Default algorithm? Full
> flooding again? in case of full-flooding-regression all of a sudden one fat
> finger on PGL (or PGL moving unexpectedly due to fat finger/some other node
> config changes) can basically crash your network and worst case stop
> convergence if reduction allowed before to converge but full flooding
> seriously slows down everything. I know, this would be a network tethering
> on the edge already but why have additional

Re: [Lsr] Questions on draft-white-lsr-distoptflood

[Tony Przygienda]

On Mon, Nov 28, 2022 at 6:22 PM Les Ginsberg (ginsberg) 
wrote:

> Hi Russ!
>
> > -Original Message-
> > From: r...@riw.us 
> > Sent: Monday, November 28, 2022 4:56 AM
> > To: Les Ginsberg (ginsberg) ; Tony Przygienda
> > 
> > Cc: draft-white-lsr-distoptflood.auth...@ietf.org; lsr@ietf.org
> > Subject: Re[2]: [Lsr] Questions on draft-white-lsr-distoptflood
> >
> >
> > >1)You can successfully deploy this algorithm in the presence of nodes
> > >which do NOT support this algorithm. But you cannot successfully deploy
> > >this algorithm in the presence of nodes which enable a different
> > >flooding reduction algorithm.
> >
> > This is correct. There seem to be two sides to this situation, however.
> > Some operators will likely not want to deploy
> > draft-ietf-lsr-dynamic-flooding to deploy flooding reduction because it
> > is "something else to break," or it interferes in some way with
> > incremental deployment. I'm sympathetic to this point of view, so I'm a
> > little skittish about making the signaling in dynamic-flooding a
> > MUST--but I'm perfectly happy to make it a MAY, or perhaps a SHOULD, if
> > folks think that is useful.
> >
> [LES:] The question I am raising is whether you think it is important to
> support a means of determining that one and only one flooding reduction
> algorithm is active at a given time.
> This would seem to be desirable and is what
> draft-ietf-lsr-dynamic-flooding provides.
>
> If you, as a protocol vendor, want to provide a proprietary way of
> enabling draft-white-lsr-distoptflood and telling your customers "to be
> careful not to enable some other flooding reduction algorithm" that's out
> of scope for this discussion and for the draft. That's a matter between you
> and your customers. And you could still do that while also providing
> support for draft-ietf-lsr-dynamic-flooding.
>

Your point, now that you make it more clear, is fair and as I said, I'm
against trying to figure out based on some indication of
reduction/algorithm used and mismatches _what_ to do (i.e. procedures). I'm
not against indicating that flood reduction is used, i.e. this draft
sending a TLV (or maybe some variant of the TLV used in the
dynamic-flooding draft which this draft could refer).  A SHOULD seems fine
here unless you argue eloquently why you think a MUST is needed ;-)

So, yes, if your concern is to detect that _different_ algoirthms/drafts
are used and alert the deployment of the problematic situation, I'm for it

Footnote: I remain still baffled a bit that this is the same problem in my
eyes we have in multi-TLV and there you argued the opposite (i.e. not
sending indication)


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

Re: [Lsr] Questions on draft-white-lsr-distoptflood

[Tony Przygienda]

Les, bits delay since I had to think a bits about your comment to do it
justice and it's bit long'ish

1. So, to start with a cut and dry summary and reasoning for it, I am
firmly against adding signaling to the whole thing by some means (or rather
any procedures to act upon distribution of info about the algorithm used by
any of the nodes involved, i.e. I'm ok with having the algorithm advertised
*solely* for info purposes with me though I don't see what function it
serves except detecting nodes that do not reduce yet in transition of a
network or maybe, as you say, detect algorithm mismatch). More detailed
reasoning follows:

a. First reason is the fact that the additional flexibility of maybe having
one day some better hash algorithm will add *very* serious amount of
complexity in implementation/behavior in case we are talking about adding
it to the centralized variant of the dynamic flooding draft and having a
leader advertising the algorithm.
i. backup machinery needs to be added/spec'ed properly. What does the
network do if backup has different algorithm than the current leader? First
we would have a transition phase, some nodes have old algorithm, some the
old, network may stop converging for a bit that way, worst case we
partition the PGL algorithm advertisement from new nodes so we have to wait
CSNP * diameter etc. Big network bleep is the result. I know there is lots
verbiage in the dynamic flooding draft but I know the reality of
implementations of such things and they are extraordinarily high for the
bit flexibility the whole thing would buy us I see you suggesting.
   ii. What happens if PGL doesn't say anything? Default algorithm? Full
flooding again? in case of full-flooding-regression all of a sudden one fat
finger on PGL (or PGL moving unexpectedly due to fat finger/some other node
config changes) can basically crash your network and worst case stop
convergence if reduction allowed before to converge but full flooding
seriously slows down everything. I know, this would be a network tethering
on the edge already but why have additional daemons hiding in a single
point of failure on top.
  iii. lots of remaining subtle things. e.g. to make sure the whole thing
works each node havs to compute reachability to the leader (not sure that's
in the dynamic flooding draft now), otherwise they may use stable LSPs from
a leader that is gone/partitioned. This reachability computation will have
adverse effects. The timing is unpredictable in the network and may lead to
problems mentioned in i).   If nodes don't do the reachability we may end
up in Paxos unintentionally BTW.

Generally, I can claim that I lived the PGL in ATM so I've seen the
"central leader in IGP" game. Not excited about it from experience and it
was much easier in ATM already due to hard state of SVCs. To sum it up
again, I see here a suggestion to add massive amount of
complexity/fragility for an assumed, unspecified benefit in the future. As
footnote: centralization in an IGP a cardinal sin in my eyes moving away
from the first premise that made distributed routing so successful. I spoke
against it and still hold the same opinion and if that's heresy I'm more
than happy to be bumped off the author's list of the dynamic-flooding draft
;-).

so maybe as iv) here:  WHAT additional variables in the hash do you imagine
would constitute a _better_ algorithm? AFAIS there are none I can imagine
and the current algorithm provides pretty much best entropy with clearly
cap'ed state per node needed to balance per LSP originator/fragment. So
instead of "pledging for flexibility for flexibilitity's sake" I'd rather
see you suggesting something that would change/improve the behavior in the
future/now in concrete terms and then let's talk about specifics.

b. Then, as second reason when talking towards a distributed solution, i.e.
each node flooding the algorithm it uses. We still do NOT know what to do
in case nodes will advertise different algorithms each, no matter it's
advertised or not. Shut down the network, fall back to full flooding if one
node disagrees (which makes every node a potential attack vector)? We had
that kind of discussion before, last on multi-TLV where you were insisting
on killing the cap indication so it would be funny to add it here.
Complexity without any concrete benefit whatsoever AFAIS and lots of
ratholes again.

2. To go to your reliable PSNP/CSNP objection now. First, they were never
reliable. Neither were LSPs. We can make a very fine argument that if
PSNPs/CSNPs are not reliable then ISIS will not converge at all. We can
start to argue then how many we lose and when and how one variation of
flooding is "more robust" than other and we can actually discover that if
the redundancy factor in graph is higher than the largest fanout than we
are in normal ISIS and hence the reduced flooding redundancy factor (in
extreme case it's basically infinity for existent flooding algorithm in
ISIS) + PSNP unreliability are 

Re: [Lsr] WG Adoption Call for "IS-IS Optimal Distributed Flooding for Dense Topologies" - draft-white-lsr-distoptflood-03

[Tony Przygienda]

as co-author support adoption.

draft is a derivation of well-known MANET techniques used before
successfully. The twists improving it (balancing of flooding across
downstream nodes in addition to reduction) has been used in RIFT already as
well, implemented and works "fine" [without further defining "fine" except
obvious property of maintaining consistent databases with less flooding and
no choke-points].

Completely distributed algorithm without any signalling and flexible
deployment property (can be mixed in any fashion with nodes not supporting
the feature) should allow us to introduce it without significant risk into
existing networks.

--- tony

On Tue, Nov 22, 2022 at 9:02 PM Acee Lindem (acee)  wrote:

> LSR WG,
>
>
>
> This begins a 2 week WG adoption call for the following draft:
>
>
>
> https://datatracker.ietf.org/doc/draft-white-lsr-distoptflood/
>
>
>
> The draft would be adopted on the Informational or Experimental track.
>
>
>
> Please indicate your support or objection by December 7th, 2022.
>
> Also indicate whether you believe it should be Informational or
> Experimental track.
>
>
>
> Thanks,
>
> Acee
>
>
>
>
> ___
> 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] AD review of draft-ietf-lsr-isis-flood-reflection-08

[Tony Przygienda]

incorporated and new version pushed

many thanks for careful review

-- tony


On Tue, Sep 20, 2022 at 10:16 PM John Scudder  wrote:

> WG,
>
> I’d like to highlight that I’ve filled in (what I believe was) a missing
> registry creation in the IANA Considerations section, and proposed that the
> registration procedures be Expert Review like the other IS-IS registries. I
> don’t think this will be controversial (it just follows the established
> pattern) but I do want to highlight it.
>

ack


>
> Dear Authors,
>
> Thanks for your patience. Here’s my review of your document.
>
> For the most part I’ve supplied my questions and comments in the form of
> an edited copy of the draft. Minor editorial suggestions I’ve made in place
> without further comment, more substantive questions and comments are done
> in-line and prefixed with “jgs:”. You can use your favorite diff tool to
> review them; I’ve attached the iddiff output for your convenience if you’d
> like to use it. I’ve also pasted a traditional diff below in case you want
> to use it for in-line reply. I’d appreciate feedback regarding whether you
> found this a useful way to receive my comments as compared to a more
> traditional numbered list of comments with selective quotation from the
> draft.
>
> Thanks,
>
> —John
>
> --- draft-ietf-lsr-isis-flood-reflection-08.txt 2022-09-20
> 15:29:50.0 -0400
> +++ draft-ietf-lsr-isis-flood-reflection-08-jgs-comments.txt2022-09-20
> 16:07:33.0 -0400
> @@ -18,15 +18,15 @@
>
>  Abstract
>
> -   This document describes a backwards compatible, optional IS-IS
> +   This document describes a backward-compatible, optional IS-IS
> extension that allows the creation of IS-IS flood reflection
> topologies.  Flood reflection permits topologies in which L1 areas
> provide transit forwarding for L2 using all available L1 nodes
> internally.  It accomplishes this by creating L2 flood reflection
> adjacencies within each L1 area.  Those adjacencies are used to flood
> L2 LSPDUs and are used in the L2 SPF computation.  However, they are
> -   not utilized for forwarding within the flood reflection cluster
> -   except in pathological cases mentioned in Section 7.  This
> +   not ordinarily utilized for forwarding within the flood reflection
> cluster.
> +   This
>

ack


> arrangement gives the L2 topology significantly better scaling
> properties than traditionally used flat designs.  As an additional
> benefit, only those routers directly participating in flood
> @@ -34,6 +34,10 @@
> incremental deployment of scalable L1 transit areas in an existing,
> previously flat network design, without the necessity of upgrading
> all routers in the network.
> +
> +jgs: Note I suggested removing the forward reference to Section 7.
> +Although accurate, ISTM that this level of detail doesn't go in the
> +Abstract.
>

ack


>
>  Requirements Language
>
> @@ -130,7 +134,7 @@
> Due to the inherent properties of link-state protocols the number of
> IS-IS routers within a flooding domain is limited by processing and
> flooding overhead on each node.  While that number can be maximized
> -   by well written implementations and techniques such as exponential
> +   by well-written implementations and techniques such as exponential
>

ack


> back-offs, IS-IS will still reach a saturation point where no further
> routers can be added to a single flooding domain.  In some L2
> backbone deployment scenarios, this limit presents a significant
> @@ -148,7 +152,7 @@
> Unfortunately, in its simplest implementation, this requires the
> inclusion of most, or all, of the transit L1 routers as L1/L2 to
> allow traffic to flow along optimal paths through those transit
> -   areas.  Consequently, such approach fails to reduce the number of L2
> +   areas.  Consequently, such an approach fails to reduce the number of L2
>

ack



> routers involved and with that fails to increase the scalability of
> the L2 backbone as well.
>
> @@ -364,7 +368,7 @@
> time introducing control plane scaling benefits provided by L2 flood
> reflectors.
>
> -   The remainder of this document defines remaining extensions necessary
> +   The remainder of this document defines the remaining extensions
> necessary
> for a complete flood reflection solution:
>

ack


>
> *  It defines a special 'flood reflector adjacency' built for the
> @@ -412,12 +416,12 @@
> The following terms are used in this document.
>
> Flood Reflector:
> -  Node configured to connect L2 only to flood reflector clients and
> +  Node configured to connect L2-only clients to flood reflector
> clients and
>reflect (reflood) IS-IS L2 LSPs amongst them.
>

you changed the meaning, a FR is NOT only L2


>
> Flood Reflector Client:
>Node configured to build Flood Reflector Adjacencies to Flood
> -  Reflector, and normal adjacencies to other clients and 

Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-01.txt

[Tony Przygienda]

Given the realities of deploying something like this I am all for
advertisement of what I'll call here the "multi-TLV-compliance" flag
(assuming we agree that capability implies a change in procedures on
reception from other nodes which this draft does not).  Being able to see
that a customer network deployed something that is _not_ compliant with the
RFC (even potentially) can save a lot of head scratching and ghost chasing
given that nodes receiving multi-part-TLVs and not processing them
correctly will exhibit most vexing behavior that is not observable on LSDB
or any of the other tools we normally use.

=--- tony

On Thu, Aug 25, 2022 at 6:07 PM Acee Lindem (acee)  wrote:

> Speaking as WG member:
>
> Hi Gunder, Tony, Les,
>
> I'm also not a fan of the Multi-Part TLV Capability flag. While the intent
> of the draft is to encourage multi-part TLV advertisement and usage, the
> addition of this flag and the requirement for advertisement will most
> likely have the opposite effect. Given that IS-IS implementations are
> already advertising multi-part TLVs but none are advertising the proposed
> capability flag, implementation of the draft as currently written would
> inhibit Multi-Part TLV usage and be a step backwards. Of course, we know
> implementations that are already advertising these multi-part TLVs will
> most likely ignore the recommendation and continue to advertise them even
> when not all IS-IS routers within the scope of the Multi-Part TLV advertise
> the capability.
>
> Rather, I propose that the draft eliminates the capability flag and
> introduces a recommended configuration parameter that would allow
> Multi-Part TLVs to be suppressed. The recommended default would be FALSE.
> This would provide an out if these Multi-Part TLVs did, in fact, have dire
> consequences.
>
> Thanks,
> Acee
>
> On 8/25/22, 6:53 AM, "Lsr on behalf of Van De Velde, Gunter (Nokia -
> BE/Antwerp)"  gunter.van_de_ve...@nokia.com> wrote:
>
> Inline: GV>
>
> From: Tony Li  On Behalf Of Tony Li
> Sent: Wednesday, August 24, 2022 5:26 PM
> To: Van De Velde, Gunter (Nokia - BE/Antwerp) <
> gunter.van_de_ve...@nokia.com>
> Cc: lsr 
> Subject: Re: [Lsr] New Version Notification for
> draft-pkaneria-lsr-multi-tlv-01.txt
>
>
> Hi Gunter,
>
> I am having troubles understanding the value of ‘The Multi-part TLV
> Capability’ flag.
> What would break if ‘Multi-part TLV Capability’ flag would not exist?
>
>
> A system that supported MP-TLVs would not be able to determine that
> there were other systems in the area that did not support MP-TLVs.  The
> system might then advertise MP-TLVs and they would be misinterpreted or
> cause system crashes in the systems that did not support them.
>
> GV> crashes? I really hope that is not happening.
> GV> When a legacy router receives MP-TLVs from another system and
> legacy router has no support for handling MP-TLV, then yes, things get
> misinterpreted. There is nothing wrong with that, is there? Do you have an
> example where things go wrong?
>
> If we want to introduce MP-TLVs, that change would warrant the
> existence of the flag.
>
> GV> I am not convinced yet how a MP-TLV catch-all flag would make ISIS
> behave better
>
> I dispute that a binary flag warrants the word ‘complexity’.
>
> GV>  living without binary flag is simpler and less complex then
> dealing with a binary flag. (i.e. what, when, how, why, who sets this flag?)
>
> Note: thoughts about the flag: What if a system by accident sends
> flip-flopping (set/unset/set/unset/etc) of this flag?
>
> Then other systems might misinterpret the results and generate
> inconsistent TLVs.  That would be bad.
>
> GV> correct, no good at all.
>
> What if an advertising system support multi-tlv for TLV ‘A’ but not
> for TLV ‘B’?
>
> We are not allowing that level of granularity.  A system that is going
> to support MP-TLVs should take care to operate correctly for ALL TLVs
> before advertising that it supports them.
>
> GV> I suspect that 'ALL TLVs' is a reference to  ALL TLVs supported by
> the local system. This means that e.g. when new TLVs would be supported
> after a system upgrade, that the operator has to be aware and correct the
> flag during each single upgrade.
>
> GV> Unfortunately I remain to have troubles understanding the value
> "Multi-part TLV Capability’ flag brings to an ISIS network.
>   * Without flag it is indeed uncertain if area wide mp-tlv is
> supported (sub-optimal).
>   * but with catch all MP-TLV flag I am not sure we improve ISIS
> operation:
>   ** Who guarantees that the flag is set correctly on all systems at
> all times
>   ** Maybe all systems falls back to advertise single TLV because
> another (legacy?) system advertise a wrong flag  (sub-optimal)
>   ** Legacy system with MP-TLV support gets upgraded and now supports
> additional TLVs but not with MP-TLV...  ?manual intervention? 

Re: [Lsr] [Idr] [GROW] IGP Monitoring Protocol

[Tony Przygienda]

which as proposal actually looks IMO more interesting than IMP thingy ...
_IF_ we want to do such a thing

As to IMP itself very terse

a) configuration is already standardized via NETCONF WG/channels/methods.
pulling it via this seems redundant.
b) YANG is already pulled via other channels so I see little value of
pulling it here. same as a) basically
c) adding all those "sync" via SNP is basically building a flooding peer
again as far I can deduct having flown quickly over the draft. Doing that
over QUIC/TCP is a bad idea due to head-on blocking problems well known
with flooding. if the consumer cannot keep up with the real stream the
sender can only start to throw away stuff or reset the session practically
speaking
d) beats me why you would want this to carry BGP-LS again if y6ou can
simply run another session/BGP instance on any good implementation today.

Given all the big wishlist included in the draft protocol needs probably
something to negotiate WHAT of all the whole panopticum the producer can
support unless it's somehow in the PUB/SUB (but then again, this probably
needs mode negotiation as well given the plethora of possibilities there).

-- tony

On Mon, Jul 11, 2022 at 4:54 PM Tianran Zhou  wrote:

> Hi Robert,
>
>
> This is very interesting to me. We had a protocol design for IGP monitoring:
>
>
> https://datatracker.ietf.org/doc/html/draft-gu-opsawg-network-monitoring-igp-01
>
> It would be a good idea if we can find some common ground.
>
> Cheers,
> Tianran
>
>
>
>
> --
>
> Sent from WeLink
> *发件人： *Robert Raszuk
> *收件人： *Tianran Zhou
> *抄送： *Yingzhen Qu;idr;grow<
> g...@ietf.org>;lsr
> *主题： *Re: [GROW] [Lsr] [Idr] IGP Monitoring Protocol
> *时间： *2022-07-11 22:05:31
>
> Hi Tianran,
>
> Yes it is,
>
> I dedicated entire paragraph in section 1 of the document to highlight
> that point:
>
>The primary inspiration for this work has been based on the success
>of BGP Monitoring Protocol (BMP) [RFC7854] which in a number of
>aspects shares the same high level requirements - point to point
>routing information distribution, protocol observability and enhanced
>operations.  It also needs to be highlighted that BMP (while it
>technically could) does not use native BGP sessions to propagate such
>information, but is running a separate transport.  IMP authors have
>chosen to reuse selected BMP building blocks and BMP operational and
>deployment experience.
>
>
>
> Many thx,
> R.
>
> On Mon, Jul 11, 2022 at 4:02 PM Tianran Zhou 
> wrote:
>
>> Hi Robert,
>>
>> I see this name very similar to BMP bgp monitoring protocol.
>> Is this the similar function and scope as BMP?
>>
>>
>> Best,
>> Tianran
>>
>> --
>>
>> Sent from WeLink
>> *发件人： *Robert Raszuk
>> *收件人： *Yingzhen Qu
>> *抄送： *idr;grow;lsr
>> *主题： *Re: [GROW] [Lsr] [Idr] IGP Monitoring Protocol
>> *时间： *2022-07-11 18:01:47
>>
>> Hi Yingzhen,
>>
>> Yes I understand that OSPF-GT is a new protocol leveraging some OSPF
>> elements.
>>
>> And please do not get me wrong ... way before OSPF Transport Instance I
>> wrote BGP Transport Instance proposal and I do consider such additions to
>> protocols as a very useful thing. In fact honestly recent discussions on
>> UPA/PUA/PULSE could be very well served by OSPF-GT in a stateful fashion.
>>
>> But I just do not see this fits well as a replacement of BGP-LS.
>>
>> Yes, protocol designers like a swiss army knife approach (not to use nail
>> and hammer analogy). However I think custom tools in the toolkit work much
>> better for specific tasks :)
>>
>> Cheers,
>> R.
>>
>>
>>
>> On Mon, Jul 11, 2022 at 3:20 AM Yingzhen Qu 
>> wrote:
>>
>>> Hi Robert,
>>>
>>> Please think of OSPF-GT as a new protocol and it borrows ideas from
>>> OSPF. BGP-LS is one use case. In LSR WG, there have been proposals asking
>>> IGPs to carry non-routing information which will have impacts on protocol
>>> convergence, and OSPF-GT is meant to be the vehicle for such information.
>>>
>>> BMP started before YANG, now with NETCONF/YANG or gNMI, you can retrieve
>>> the entire LSDB or part of it from a router, or subscribe to some data
>>> instances.
>>>
>>> Thanks,
>>> Yingzhen
>>>
>>> On Jul 10, 2022, at 3:44 PM, Robert Raszuk  wrote:
>>>
>>> Hi Acee,
>>>
>>> My questions were based on section 3.4 of the latest version of the
>>> draft.
>>>
>>> So I do not think I misinterpreted it.
>>>
>>> Thank you,
>>> R.
>>>
>>>
>>>
>>> On Mon, Jul 11, 2022 at 12:38 AM Acee Lindem (acee) 
>>> wrote:
>>>
 Hi Robert,



 *From: *Lsr  on behalf of Robert Raszuk <
 rob...@raszuk.net>
 *Date: *Sunday, July 10, 2022 at 1:32 PM
 *To: *Yingzhen Qu 
 *Cc: *Gyan Mishra , Susan Hares ,
 IDR List , "g...@ietf.org g...@ietf.org" ,
 lsr 
 *Subject: *Re: [Lsr] [Idr] [GROW] IGP Monitoring Protocol



 Hi Yingzhen & OSPF-GT authors,



 UP front I must state that anything is better to export IGP 

Re: [Lsr] [Idr] draft-head-idr-bgp-ls-isis-fr-01 - WG adoption call (6/6 to 6/20)

[Tony Przygienda]

ok, we in sync then ...

thanks

-- tony

On Sat, Jun 25, 2022 at 8:07 AM Ketan Talaulikar 
wrote:

> Hi Tony,
>
> Just allowing sub-TLVs for the BGP-LS ISIS Flood Reflection TLV will
> address my concerns for this draft. For the rest, new TLVs/sub-TLVs can be
> introduced on a need basis down the line.
>
> Thanks,
> Ketan
>
>
> On Fri, Jun 24, 2022 at 11:43 PM Tony Przygienda 
> wrote:
>
>>
>>
>> On Fri, Jun 24, 2022 at 6:43 PM Ketan Talaulikar 
>> wrote:
>>
>>> Hi Tony,
>>>
>>> Please check inline below.
>>>
>>> On Wed, Jun 22, 2022 at 9:41 PM Tony Przygienda 
>>> wrote:
>>>
>>>> hey Ketan, since as you know ;-) BGP-LS is not really IGP 1:1
>>>> translation we try to put into BGP-LS here only the stuff that is strictly
>>>> needed for topology discovery and understanding for advanced computation
>>>> and nothing else.
>>>>
>>>
>>> KT> I don't agree with the "nothing else".  At least I can't claim to
>>> have the full knowledge of all the solutions being designed and deployed
>>> using BGP-LS.
>>>
>>
>> I can't answer to that except BGP-LS doesn't have enough information as
>> it stands to do a lot of stuff that you can do using full IGP database. And
>> I try to define a minimum set of what is useful already. We can always add
>> more stuff later but maybe we cannot given what we defined and I miss your
>> point (which seems to be the case reading rest of your email).
>>
>>
>>>
>>>
>>>> And hence, since the 1:1 TLV correspondence is nowhere to be seen by
>>>> now if you look at ospf/isis encoding and what BGP-LS formats are today
>>>> your requirements are interesting but I'm not sure where they came from.
>>>>
>>>
>>> KT> Not everything from OSPF/ISIS is in BGP-LS, but whatever we've put
>>> follows closely the semantics and encoding (with due consideration for
>>> normalization across the IGPs). So I don't support the design of BGP-LS
>>> encodings that are different from the underlying IGPs without strong
>>> justification.
>>>
>>
>> well, no, it doesn't. if you look e.g. at MT encoding it's upside down
>> compared to ISIS encoding. it's encoded within link descriptor while in
>> ISIS it's its own TLV with MT being on top. BGP-LS encoding is nothing like
>> the original ISIS encoding in most parts e.g. by already cumulating lots
>> stuff into same descriptior which in ISIS can be spread across multiple
>> TLVs and fragments.
>>
>> Unless you point me to a normative reference where it says that BGP-LS is
>> following IGP encoding closely I take it just as an assertion you make and
>> we disagree, Ketan.
>>
>>
>>>
>>>
>>>>
>>>>
>>>> The flag indicates already whether something is client or reflector on
>>>> an adjacency. cluster ID is there as well to differentiate between
>>>> different clusters. L2 C/FR adjacencies will show up as well. good enough
>>>> to understand topology and compute AFAIS.  All this is achievable by
>>>> putting this element on the link TLV (the draft should explain it better,
>>>> it just grabs codepoints in node/link/prefix & e'thing else ;-). Yes, we
>>>> could annotate just the node assuming strict adherence to the IGP draft
>>>> today but putting the element on the link descriptor follows the IGP spec
>>>> itself and will allow to break the RFC if necessary later also in BGP-LS
>>>> (by e.g. allowing a node to be client of two different clusters or even a
>>>> node being reflector for 2 different clusters. Observe that this will not
>>>> work in case of auto-discoery since that's on node caps ;-) But those are
>>>> sutble discussions that need to be documented into the BGP-LS draft as
>>>> procedures once adopted.
>>>>
>>>
>>> KT> So you see the scope for adding some more of the sub-TLVs from the
>>> ISIS flood-reflection draft into this BGP-LS document? If so, great - we
>>> can always extend on a need basis.
>>>
>>
>> agreed
>>
>>
>>>
>>>
>>>> Those discussions are natural and necessary since BGP-LS is NOT IGP
>>>> database but a distorted, simplified view for topology discovery. Or at
>>>> least that's how it's used in reality based on the shortcomings of its
>>>> design ;-)
>>>>
>>>> As 

Re: [Lsr] [Idr] draft-head-idr-bgp-ls-isis-fr-01 - WG adoption call (6/6 to 6/20)

[Tony Przygienda]

On Fri, Jun 24, 2022 at 6:43 PM Ketan Talaulikar 
wrote:

> Hi Tony,
>
> Please check inline below.
>
> On Wed, Jun 22, 2022 at 9:41 PM Tony Przygienda 
> wrote:
>
>> hey Ketan, since as you know ;-) BGP-LS is not really IGP 1:1 translation
>> we try to put into BGP-LS here only the stuff that is strictly needed for
>> topology discovery and understanding for advanced computation and nothing
>> else.
>>
>
> KT> I don't agree with the "nothing else".  At least I can't claim to have
> the full knowledge of all the solutions being designed and deployed using
> BGP-LS.
>

I can't answer to that except BGP-LS doesn't have enough information as it
stands to do a lot of stuff that you can do using full IGP database. And I
try to define a minimum set of what is useful already. We can always add
more stuff later but maybe we cannot given what we defined and I miss your
point (which seems to be the case reading rest of your email).


>
>
>> And hence, since the 1:1 TLV correspondence is nowhere to be seen by now
>> if you look at ospf/isis encoding and what BGP-LS formats are today  your
>> requirements are interesting but I'm not sure where they came from.
>>
>
> KT> Not everything from OSPF/ISIS is in BGP-LS, but whatever we've put
> follows closely the semantics and encoding (with due consideration for
> normalization across the IGPs). So I don't support the design of BGP-LS
> encodings that are different from the underlying IGPs without strong
> justification.
>

well, no, it doesn't. if you look e.g. at MT encoding it's upside down
compared to ISIS encoding. it's encoded within link descriptor while in
ISIS it's its own TLV with MT being on top. BGP-LS encoding is nothing like
the original ISIS encoding in most parts e.g. by already cumulating lots
stuff into same descriptior which in ISIS can be spread across multiple
TLVs and fragments.

Unless you point me to a normative reference where it says that BGP-LS is
following IGP encoding closely I take it just as an assertion you make and
we disagree, Ketan.


>
>
>>
>>
>> The flag indicates already whether something is client or reflector on an
>> adjacency. cluster ID is there as well to differentiate between different
>> clusters. L2 C/FR adjacencies will show up as well. good enough to
>> understand topology and compute AFAIS.  All this is achievable by putting
>> this element on the link TLV (the draft should explain it better, it just
>> grabs codepoints in node/link/prefix & e'thing else ;-). Yes, we could
>> annotate just the node assuming strict adherence to the IGP draft today but
>> putting the element on the link descriptor follows the IGP spec itself and
>> will allow to break the RFC if necessary later also in BGP-LS (by e.g.
>> allowing a node to be client of two different clusters or even a node being
>> reflector for 2 different clusters. Observe that this will not work in case
>> of auto-discoery since that's on node caps ;-) But those are sutble
>> discussions that need to be documented into the BGP-LS draft as procedures
>> once adopted.
>>
>
> KT> So you see the scope for adding some more of the sub-TLVs from the
> ISIS flood-reflection draft into this BGP-LS document? If so, great - we
> can always extend on a need basis.
>

agreed


>
>
>> Those discussions are natural and necessary since BGP-LS is NOT IGP
>> database but a distorted, simplified view for topology discovery. Or at
>> least that's how it's used in reality based on the shortcomings of its
>> design ;-)
>>
>> As I explained, unless L1 adjacencies are being formed IMO they don't
>> belong into BGP-LS FR information, otherwise will show up in BGP-LS
>> naturally. Neither does IMO auto-discovery of FR.
>>
>> As to mismatch of e.g. cluster ID/role. good observation but we don't
>> send IIHs in BGP-LS either to discover MTU mismatch so I don't see that's
>> what BGP-LS is here for
>>
>
> KT> The main sticking point for me here is that you have not allowed for
> the BGP-LS Flood Reflection TLV to have support for sub-TLVs as is the
> case with its underlying ISIS Flood Reflection TLV. It is a very minor
> thing that can be easily fixed and I am unable to understand why this
> cannot or should not be done. Anyway, I rest my case :-)
>

ah. ok. if that's your only thing, sure. we can allow for sub-TLVs. suggest
encoding change or Jordan can make it so sub-TLVs can be plugged in later

thanks for the comments and careful read

-- tony


>
> Thanks,
> Ketan
>
>
>>
>> -- tony
>>
>> On Wed, Jun 22, 2022 at 4:44 PM Ketan Talaulikar 
>> wrote:
>>
>>> Hi Tony,
>>

Re: [Lsr] [Idr] draft-head-idr-bgp-ls-isis-fr-01 - WG adoption call (6/6 to 6/20)

[Tony Przygienda]

hey Ketan, since as you know ;-) BGP-LS is not really IGP 1:1 translation
we try to put into BGP-LS here only the stuff that is strictly needed for
topology discovery and understanding for advanced computation and nothing
else. And hence, since the 1:1 TLV correspondence is nowhere to be seen by
now if you look at ospf/isis encoding and what BGP-LS formats are today
your requirements are interesting but I'm not sure where they came from.

The flag indicates already whether something is client or reflector on an
adjacency. cluster ID is there as well to differentiate between different
clusters. L2 C/FR adjacencies will show up as well. good enough to
understand topology and compute AFAIS.  All this is achievable by putting
this element on the link TLV (the draft should explain it better, it just
grabs codepoints in node/link/prefix & e'thing else ;-). Yes, we could
annotate just the node assuming strict adherence to the IGP draft today but
putting the element on the link descriptor follows the IGP spec itself and
will allow to break the RFC if necessary later also in BGP-LS (by e.g.
allowing a node to be client of two different clusters or even a node being
reflector for 2 different clusters. Observe that this will not work in case
of auto-discoery since that's on node caps ;-) But those are sutble
discussions that need to be documented into the BGP-LS draft as procedures
once adopted. Those discussions are natural and necessary since BGP-LS is
NOT IGP  database but a distorted, simplified view for topology discovery.
Or at least that's how it's used in reality based on the shortcomings of
its design ;-)

As I explained, unless L1 adjacencies are being formed IMO they don't
belong into BGP-LS FR information, otherwise will show up in BGP-LS
naturally. Neither does IMO auto-discovery of FR.

As to mismatch of e.g. cluster ID/role. good observation but we don't send
IIHs in BGP-LS either to discover MTU mismatch so I don't see that's what
BGP-LS is here for

-- tony

On Wed, Jun 22, 2022 at 4:44 PM Ketan Talaulikar 
wrote:

> Hi Tony,
>
> I may not be the best judge, for this feature, of which of the ISIS
> sub-TLV need to get into BGP-LS and which do not. In my limited
> understanding of the feature and its deployment, the other 3 sub-TLVs would
> be equally useful to get into BGP-LS. Isn't the Flood Reflection
> Adjacency Sub-TLV the one that distinguishes a "normal" ISIS adjacency
> from a reflector adjacency formed over the tunnel? Isn't it useful to know
> what sort of tunnel encapsulation is being signaled so a discrepancy
> between the two ends can be detected?
>
> I am copying LSR WG which probably is the better group than IDR to review
> and comment on this.
>
> In any case, I am ok to go ahead and skip the inclusion of certain ISIS
> sub-TLVs in BGP-LS - they can be always added later on.
>
> But I am not ok that while the ISIS Flood Reflection TLV has support for
> sub-TLVs, its corresponding BGP-LS ISIS Flood Reflection TLV does not allow
> for sub-TLVs. The encoding needs to be consistent. That is a show-stopper
> in my opinion.
>
> Thanks,
> Ketan
>
>
> On Wed, Jun 22, 2022 at 7:29 PM Tony Przygienda 
> wrote:
>
>> Ketan, AFAIS tunnel status is not part of IGP state and should be derived
>> from alternate mechanisms just like interface up/down state on the node. We
>> don't carry interface up/down in BGP-LS today and should not (observe that
>> I really mean admin/phy up/down and not IGP adj up/down here).  And then,
>> those L1 tunnels either form IGP adjacencies on them in which case you'll
>> get them in BGP-LS as neighbors or they use something alternate like e.g.
>> BFD (or nothing at all possibly) and at this point it will become really
>> weird to carry in BGP-LS an L1 tunnel which does not have IGP adjacency on
>> it ...
>>
>> open to suggestions but AFAIS the FR/client L2 adjacencies are in BGP-LS
>> already per normal procedures (and the fact that you see client/reflector
>> flag on both nodes & cluster ID allows you to derive the property of the
>> adjacency) but the L1 mesh (if used) has no business in BGP-LS unless it
>> forms IGP L1 adjacencies.
>>
>> -- tony
>>
>> On Wed, Jun 22, 2022 at 3:26 PM Ketan Talaulikar 
>> wrote:
>>
>>> Hi Jordan,
>>>
>>> Thanks for your response and please check inline below for what needs
>>> further discussion.
>>>
>>>
>>> On Tue, Jun 21, 2022 at 11:10 PM Jordan Head  wrote:
>>>
>>>> Hi Ketan,
>>>>
>>>>
>>>>
>>>> Thanks for reading the draft and taking the time to comment.
>>>>
>>>>
>>>>
>>>> [Ketan]
>>>>
>>>> *1) The sta

Re: [Lsr] Dynamic Flooding on Dense Graphs - draft-ietf-lsr-dynamic-flooding

[Tony Przygienda]

there should be a preso this ietf in rtg wg showing a framework that can be
used to evaluate such questions. if time permits (per Jeff). tony

On Mon, Jun 13, 2022 at 5:43 PM tom petch  wrote:

> From: Lsr  on behalf of Acee Lindem (acee)  40cisco@dmarc.ietf.org>
> Sent: 10 June 2022 15:10
>
> Initially, there was a lot interest and energy in reducing the flooding
> overhead in dense drafts. Now, it seems the interest and energy has waned.
> IMO, this draft contains some very valuable extensions to the IGPs. I
> discussed this with the editors and one suggestion was to go ahead and
> publish the draft as “Experimental”. However, before doing this I’d like to
> get the WG’s opinion on making it experimental rather standards track.
> Additionally, I know there were some prototype implementations. Have any of
> those been productized?
>
> 
> The trouble with experimental is what happens next?  Does it stay
> experimental for ever or is there some assessment at some point when it
> becomes Standards Track?  What are the criteria?  I am not aware of an RFC
> describing such a process and the IPPM WG seemed uncertain what to do with
> RFC8321 and RFC8889 when such an issue arose.
>
> The shepherd report for 8321 said
> 'the measurement utility of this extension still is to be demonstrated at
> a variety of scales
>in a plurality of network conditions'
> as the justification for experimental but did not state how that might
> later be demonstrated.
>
> Tom Petch
>
> Thanks,
> Acee
>
>
> ___
> 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] How to forward the solutions for "Prefixes Unreachable Notification" problem

[Tony Przygienda]

Right, I also saw req' up to 0.5M nodes in flat IGP core by some customers
thinking they'll have the money & need for such things (though I know only
one company in the world right now that runs anything deployed of this
scale give it 2-3 multiplier of total networking devices including switches
;-). Now, generally IME those are customers that did not work with IGPs
extensively since the beginning and put lots assumptions forward which may
look good on paper but it is not clear whether they can be built with the
current technology available (or maybe ever given we're starting to talk
gin-ormous ;-) amounts of state needing synchronization over what is
basically a broadcast). My dry observation was that we either need to break
up the network (theoretically, with enough areas that should be possible
but @ this IGP scale nothing is obvious ;-) or the other approach is to
build it in a very regular graph and use the properties of the graph to
reduce the amount of state in smart ways so in short not use "traditional"
IGPs really.

Now, because someone wants a huge IGP and lots of scale problems are being
hit, the answer is not to make it go "faster" by increasing flooding & push
more and more stuff into the broadcast, especially with flat addresses. If
that "strategy" would work we would not have IP but the planet would be
bridged L2 ;-)

Sounds abstract until the ugliness in the field overruns you (and the
assertions of "rate limited" and "timer expiring" and such stuff is
basically assumptions which will be by experience invalidated by customers
fiddling knobs or the 'unexpected' meltdown that will expose the one huge
blast radius this all encompasses).

IME at this scale you are really best served by a subscribe/publish
mechanism or to put it differently scoped queries on the network. Or you
limit the domain by e.g. carrying nhops in their own dedicated IBGP
reflected or some such thing (roughly stuff Robert was ruminating on).  And
@ publish/subscribe architectural fork in the road I truly do think that
IGPs role should be limited to exposing the SSAPs (roughly Tony's stuff). A
possible variation on the theme is mp2mp substrate that is a S-PMSI at the
same time but that's probably too far out for people's thinking of today
;-)

The discussion is currently bogged down as couple folks observed, given the
variety of assumptions and experience levels & claims extended happily
(where I often ask myself how they have been confabulated) I don't see much
progress will be made. A good option may be to observe that there is no
ultimate need for IGP to get involved here and things can be solved by an
overlay solution of PEs just fine and with that move on to practical
problems we can agree IGP must deal with (as others did already).

--- tony







On Thu, Jan 27, 2022 at 1:49 AM Les Ginsberg (ginsberg)  wrote:

> Chris -
>
> The scale request comes from real customers. So, it is understandable for
> you to be "aghast" - but it is a real request.
>
> As far as BFD goes, my opinion is this won’t scale. There is a significant
> difference between operating sessions which continuously monitor liveness
> in a full mesh versus using some approach which only triggers network-wide
> traffic when some topology change is locally detected. There are multiple
> approaches being discussed which do the latter - but BFD is not one of them.
>
> You can disagree - or - as Greg has done - say we don’t really have to
> consider this scale. I am not going to try to convince you otherwise.
> But if so you aren’t solving the problem we have been asked to solve.
>
>Les
>
>
> > -Original Message-
> > From: Christian Hopps 
> > Sent: Wednesday, January 26, 2022 2:15 PM
> > To: Les Ginsberg (ginsberg) 
> > Cc: Greg Mirsky ; Aijun Wang
> > ; lsr@ietf.org
> > Subject: Re: [Lsr] How to forward the solutions for "Prefixes Unreachable
> > Notification" problem
> >
> >
> > "Les Ginsberg (ginsberg)"  writes:
> >
> > > Greg –
> > >
> > > With 100K PE scale, we are talking about 100K BFD sessions/PE and
> > > close to 5 million BFD sessions network-wide.
> > >
> > > Eliminating one of the options we are discussing is admittedly a
> > > small step, but still worthwhile.
> >
> > Hang on a sec. :)
> >
> > We are starting off with this GINORMOUS network with 100,000 PE routers!
> > Why would 5 million sessions of anything over this gigantic network of
> > routers be a reason to disregard it as a solution? (How many total
> routers are
> > there BTW?)
> >
> > If you build something gignatic *everything* is going to scale way up.
> To use
> > an oldie but a goodie: TANSTAAFL.
> >
> > Thanks,
> > Chris.
> >
> >
> > >
> > >
> > > However, If you still want to continue to advocate for BFD, I will
> > > say no more.
> > >
> > >
> > >
> > >Les
> > >
> > >
> > >
> > > From: Lsr  On Behalf Of Greg Mirsky
> > > Sent: Tuesday, January 25, 2022 7:06 PM
> > > To: Aijun Wang 
> > > Cc: lsr 
> > > Subject: Re: [Lsr] How to forward the solutions for 

Re: [Lsr] BGP vs PUA/PULSE

[Tony Przygienda]

On Mon, Jan 24, 2022 at 5:43 AM Gyan Mishra  wrote:

>
>
> Hi Chris
>
>
> Just about every vendor out there recommended best practice is to layout
> address plan to take advantage of summarization wherever possible and that
> as well includes PE loopback next hop attribute to limit the router load as
> well as size of LSDB in the backbone as well as domain wide.
>
> I think you would be hard pressed to find any vendor that would say go
> ahead and flood loopbacks domain wide and don’t summarize.
>

it's actually not unheard off @ all (flood loopbacks flat). and with node
SID it's almost a must if you want SR without lots of reinventing of
seamless MPLS ...

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

Re: [Lsr] Fwd: New Version Notification for draft-li-lsr-liveness-00.txt

[Tony Przygienda]

we rely on the service to indicate failures while kafka relies on routing
to be able to come up and get the cluster together (unless we talk a single
server). So routing has to be up for kafka to come up and in case of
failure this may affect kafka as well so there is no signalling. not that
important, was just free-associating ...

-- tony

On Wed, Jan 19, 2022 at 9:04 PM Robert Raszuk  wrote:

> Tony P,
>
> > though this leads to chicken-egg since kafka needs routing to strip
> e'thing together
>
> I am not sure I follow the above parenthesis ... Routing will be there
> already as we are not talking about any reachability distribution hence I
> am not sure where is the chicken-egg dilemma ?
>
> Would you mind clarifying ?
>
> Thx,
> R.
>
> On Wed, Jan 19, 2022 at 8:38 PM Tony Przygienda 
> wrote:
>
>> yupp, if we want IGP involved this is definitely a much more sane
>> alternative than the ones proposed. Use IGP only to advertise the SSAP of
>> such "notification service" rather than abuse it as a broadcast mechanism.
>> And for all practical purposes we can simply advertise something like kafka
>> channels ;-) and put it onto an overlay bus (though this leads to
>> chicken-egg since kafka needs routing to strip e'thing together). Or we
>> could use BIER for that as well where e'one sits on mp2mp thing (and
>> filtering translates into bitmask you multicast the notifications to).
>>
>> As only observation, if we do this service as suggested I would like to
>> see not only port & protocol but also the according address of the endpoint
>> (since it's really  that is the SSAP here.
>> Operationally it's very often desirable to know what address stuff shows up
>> to especially if there are filtering/reachability considerations ...
>>
>> -- tony
>>
>> On Wed, Jan 19, 2022 at 2:05 AM Tony Li  wrote:
>>
>>>
>>> FYI.  This is a better alternative that PUA/Pulse.
>>>
>>> Tony
>>>
>>>
>>> Begin forwarded message:
>>>
>>> *From: *internet-dra...@ietf.org
>>> *Subject: **New Version Notification for draft-li-lsr-liveness-00.txt*
>>> *Date: *January 18, 2022 at 5:04:22 PM PST
>>> *To: *, "Tony Li" 
>>>
>>>
>>> A new version of I-D, draft-li-lsr-liveness-00.txt
>>> has been successfully submitted by Tony Li, and posted to the
>>> IETF repository.
>>>
>>> Name: draft-li-lsr-liveness
>>> Revision: 00
>>> Title: Node Liveness Protocol
>>> Document date: 2022-01-18
>>> Group: Individual Submission
>>> Pages: 9
>>> URL:
>>> https://www.ietf.org/archive/id/draft-li-lsr-liveness-00.txt
>>> Status: https://datatracker.ietf.org/doc/draft-li-lsr-liveness/
>>> Htmlized:
>>> https://datatracker.ietf.org/doc/html/draft-li-lsr-liveness
>>>
>>>
>>> Abstract:
>>>   Prompt notification of the loss of node liveness or reachability is
>>>   useful for restoring services in tunneled topologies.  IGP
>>>   summarization precludes remote nodes from directly observing the
>>>   status of remote nodes.  This document proposes a service that, in
>>>   conjunction with the IGP, provides prompt notifications without
>>>   impacting IGP summarization.
>>>
>>>
>>>
>>>
>>> The IETF Secretariat
>>>
>>>
>>>
>>> ___
>>> 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 mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Fwd: New Version Notification for draft-li-lsr-liveness-00.txt

[Tony Przygienda]

yupp, if we want IGP involved this is definitely a much more sane
alternative than the ones proposed. Use IGP only to advertise the SSAP of
such "notification service" rather than abuse it as a broadcast mechanism.
And for all practical purposes we can simply advertise something like kafka
channels ;-) and put it onto an overlay bus (though this leads to
chicken-egg since kafka needs routing to strip e'thing together). Or we
could use BIER for that as well where e'one sits on mp2mp thing (and
filtering translates into bitmask you multicast the notifications to).

As only observation, if we do this service as suggested I would like to see
not only port & protocol but also the according address of the endpoint
(since it's really  that is the SSAP here.
Operationally it's very often desirable to know what address stuff shows up
to especially if there are filtering/reachability considerations ...

-- tony

On Wed, Jan 19, 2022 at 2:05 AM Tony Li  wrote:

>
> FYI.  This is a better alternative that PUA/Pulse.
>
> Tony
>
>
> Begin forwarded message:
>
> *From: *internet-dra...@ietf.org
> *Subject: **New Version Notification for draft-li-lsr-liveness-00.txt*
> *Date: *January 18, 2022 at 5:04:22 PM PST
> *To: *, "Tony Li" 
>
>
> A new version of I-D, draft-li-lsr-liveness-00.txt
> has been successfully submitted by Tony Li, and posted to the
> IETF repository.
>
> Name: draft-li-lsr-liveness
> Revision: 00
> Title: Node Liveness Protocol
> Document date: 2022-01-18
> Group: Individual Submission
> Pages: 9
> URL:
> https://www.ietf.org/archive/id/draft-li-lsr-liveness-00.txt
> Status: https://datatracker.ietf.org/doc/draft-li-lsr-liveness/
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-li-lsr-liveness
>
>
> Abstract:
>   Prompt notification of the loss of node liveness or reachability is
>   useful for restoring services in tunneled topologies.  IGP
>   summarization precludes remote nodes from directly observing the
>   status of remote nodes.  This document proposes a service that, in
>   conjunction with the IGP, provides prompt notifications without
>   impacting IGP summarization.
>
>
>
>
> The IETF Secretariat
>
>
>
> ___
> 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 Last Call fo "IS-IS Flood Reflection"-draft-ietf-lsr-isis-flood-reflection-05

[Tony Przygienda]

I wonder whether this is now a general rule for all future ISIS drafts
suggesting extensions or a one off random thing and we can come up for
future drafts with arbitrary list of related drafts that we will
precondition to gate publish/acceptance/whatever ...

just trying to figure out what the process is here ...

-- tony

On Wed, Jan 12, 2022 at 5:16 PM Acee Lindem (acee)  wrote:

> Speaking as document shepherd:
>
>
>
> Who thinks we should delay this draft while waiting for a deployment
> draft? I know some people supported this but I believe it would be better
> to move forward with this experimental draft. Given that there were 3
> separate proposals for this topology to use level-1 as a transit for
> level-2. We’ve already established that there is a requirement.
>
>
>
> Also, I agree with Tony in that comments should be technical rather than
> simply that you don’t like it or you think it is complex.
>
>
>
> Thanks,
> Acee
>
>
>
> *From: *Tony Przygienda 
> *Date: *Monday, January 10, 2022 at 2:36 PM
> *To: *Acee Lindem 
> *Cc: *Aijun Wang , Christian Hopps <
> cho...@chopps.org>, "Les Ginsberg (ginsberg)" , "
> lsr@ietf.org" 
> *Subject: *Re: [Lsr] WG Last Call fo "IS-IS Flood
> Reflection"-draft-ietf-lsr-isis-flood-reflection-05
>
>
>
> yes, first, if you abstract in _any_ way (except a full mesh for a single
> metric) you will end up with suboptimal paths (compared to global, flat
> topology view) traversing an abstracted subgraph and different ECMP
> behavior in corner cases, it's basic graph theory (aggravated by hop-by-hop
> or loose-source route forwarding planes) and is a well-known problem
> encountered in any hierarchical network, be it IGP, seamless MPLS or even
> BGP (look @ AIGP). FR deployed with underlying tunnels in L1 does not loop
> and neither does it when deployed correctly with prefix leaking.
>
>
>
> I cannot help it if a single person on this list is harboring fears,
> preferences and doubts without hard technical arguments to make for a
> meaningful discussion so I think it's time to put that repetitive
> sub-thread aside.
>
>
>
> As I said, I will be more than happy to help on a "deployment
> considerations" or some such draft once those documents move up to
> publication  so we have stable references to talk about ...
>
>
>
> thanks
>
>
>
> -- tony
>
>
>
> On Mon, Jan 10, 2022 at 6:05 PM Acee Lindem (acee)  wrote:
>
> I'll defer to Tony but my understanding is that there could be suboptimal
> paths if there are both Level-1 and Level-2 paths but not loops.
> Thanks,
> Acee
>
> On 1/10/22, 11:38 AM, "Aijun Wang"  wrote:
>
> But there are unsolved issues for this draft—— BGP has loop prevention
> mechanism, current flood reflection draft hasn’t, the operator must  design
> the topology/link metric  carefully to avoid the possible loop.
>
> Aijun Wang
> China Telecom
>
> > On Jan 11, 2022, at 00:10, Acee Lindem (acee)  40cisco@dmarc.ietf.org> wrote:
> >
> > Speaking as a WG member, these documents are all "experimental" and,
> IMO, it would really stifle innovation to require a single experimental
> solution. We've never done that in the past. Also,  while all three
> solutions have the goal of reducing control plane overhead when using
> Level-1 areas as a transit, the flood reflection draft solves the problem
> with a different approach than the area proxy and TTZ drafts.  While the
> latter two focus on abstracting the transit area, the former also focusing
> on reducing the number of adjacencies and allows the reflector to be out of
> the data path (similar to the standardized and widely deployed BGP route
> reflection) I see no need to differentiate to stall advancement.
> >
> > Thanks,
> > Acee
> >
> > On 1/3/22, 7:05 AM, "Christian Hopps"  wrote:
> >
> >
> >Tony Przygienda  writes:
> >
> >> One thing Les is missing here is that proxy & reflection present in
> >> terms of deployment requirements and ultimate properties very
> >> different engineering & operational trade-offs. Different customers
> >> follow different philosophies here IME
> >>
> >> So we are not strictly standardizing here 2 solutions for the same
> >> thing, we are standardizing two solutions that meet very different
> >> deployment and operational requirements albeit from 20K feet view
> all
> >> that stuff looks the same of course as any other thing does ...
> >
> >Have

Re: [Lsr] WG Last Call fo "IS-IS Flood Reflection"-draft-ietf-lsr-isis-flood-reflection-05

[Tony Przygienda]

yes, first, if you abstract in _any_ way (except a full mesh for a single
metric) you will end up with suboptimal paths (compared to global, flat
topology view) traversing an abstracted subgraph and different ECMP
behavior in corner cases, it's basic graph theory (aggravated by hop-by-hop
or loose-source route forwarding planes) and is a well-known problem
encountered in any hierarchical network, be it IGP, seamless MPLS or even
BGP (look @ AIGP). FR deployed with underlying tunnels in L1 does not loop
and neither does it when deployed correctly with prefix leaking.

I cannot help it if a single person on this list is harboring fears,
preferences and doubts without hard technical arguments to make for a
meaningful discussion so I think it's time to put that repetitive
sub-thread aside.

As I said, I will be more than happy to help on a "deployment
considerations" or some such draft once those documents move up to
publication  so we have stable references to talk about ...

thanks

-- tony

On Mon, Jan 10, 2022 at 6:05 PM Acee Lindem (acee)  wrote:

> I'll defer to Tony but my understanding is that there could be suboptimal
> paths if there are both Level-1 and Level-2 paths but not loops.
> Thanks,
> Acee
>
> On 1/10/22, 11:38 AM, "Aijun Wang"  wrote:
>
> But there are unsolved issues for this draft—— BGP has loop prevention
> mechanism, current flood reflection draft hasn’t, the operator must  design
> the topology/link metric  carefully to avoid the possible loop.
>
> Aijun Wang
> China Telecom
>
> > On Jan 11, 2022, at 00:10, Acee Lindem (acee)  40cisco@dmarc.ietf.org> wrote:
> >
> > Speaking as a WG member, these documents are all "experimental" and,
> IMO, it would really stifle innovation to require a single experimental
> solution. We've never done that in the past. Also,  while all three
> solutions have the goal of reducing control plane overhead when using
> Level-1 areas as a transit, the flood reflection draft solves the problem
> with a different approach than the area proxy and TTZ drafts.  While the
> latter two focus on abstracting the transit area, the former also focusing
> on reducing the number of adjacencies and allows the reflector to be out of
> the data path (similar to the standardized and widely deployed BGP route
> reflection) I see no need to differentiate to stall advancement.
>     >
>     > Thanks,
> > Acee
> >
> > On 1/3/22, 7:05 AM, "Christian Hopps"  wrote:
> >
> >
> >Tony Przygienda  writes:
> >
> >> One thing Les is missing here is that proxy & reflection present in
> >> terms of deployment requirements and ultimate properties very
> >> different engineering & operational trade-offs. Different customers
> >> follow different philosophies here IME
> >>
> >> So we are not strictly standardizing here 2 solutions for the same
> >> thing, we are standardizing two solutions that meet very different
> >> deployment and operational requirements albeit from 20K feet view
> all
> >> that stuff looks the same of course as any other thing does ...
> >
> >Have we captured these "different deployment and operational
> requirements" anywhere? I think might be very useful...
> >
> >Thanks,
> >Chris.
> >[as wg member]
> >
> >
> >> -- tony
> >>
> >> On Tue, Dec 7, 2021 at 7:17 PM Les Ginsberg (ginsberg)  >> 40cisco@dmarc.ietf.org> wrote:
> >>
> >>
> >>When I look at this request, I see it in a larger context.
> >>
> >>
> >>
> >>There are two drafts which attempt to address the same problem in
> >>very different ways:
> >>
> >>
> >>
> >>https://datatracker.ietf.org/doc/
> >>draft-ietf-lsr-isis-flood-reflection/
> >>
> >>
> >>
> >>and
> >>
> >>
> >>
> >>https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-area-proxy/
> >>
> >>
> >>
> >>Both of them discuss in their respective introductions the
> >>motivation – which is to address scaling issues in deployment
> >>scenarios where the existing IS-IS hierarchy is being asked to
> >>“stand on its head” i.e., interconnection between different L1
> >>areas is not to be achieved by utilizing an L2 backb

Re: [Lsr] Forklifts vs Flag Days

[Tony Przygienda]

Chris, I stand accused ;-) and you're correct, flag day is a better term
for the discussions we had recently around different technologies to
flag-day the protocol ;-)  ...

-- tony

On Mon, Jan 3, 2022 at 12:55 PM Christian Hopps  wrote:

>
> On a lighter note..
>
> Forklift upgrades imply a requirement to replace hardware i.e., "get the
> forklift out to swap in/out huge heavy router chassis".. I think it's
> recently been somewhat misused to refer to software upgrades. SW upgrades
> do not require forklifts. :)
>
> "a Flag Day", would probably be a better choice to capture the intent
>
> https://en.wikipedia.org/wiki/Flag_day_(computing)
>
> ... and now back to your regularly scheduled programs...
>
> Thanks,
> Chris.
>
> ___
> 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 Last Call fo "IS-IS Flood Reflection" -draft-ietf-lsr-isis-flood-reflection-05

[Tony Przygienda]

AFAIS this is a "operational and deployment" or "applicability" draft and
not part of a protocol specification. But yes, such a draft would have
value AFAIS, especially if it deals with both abstract node & reflection in
one as available  solutions. More than happy to attack that once the specs
have moved to publication.

-- tony

On Mon, Jan 3, 2022 at 1:05 PM Christian Hopps  wrote:

>
> Tony Przygienda  writes:
>
> > One thing Les is missing here is that proxy & reflection present in
> > terms of deployment requirements and ultimate properties very
> > different engineering & operational trade-offs. Different customers
> > follow different philosophies here IME
> >
> > So we are not strictly standardizing here 2 solutions for the same
> > thing, we are standardizing two solutions that meet very different
> > deployment and operational requirements albeit from 20K feet view all
> > that stuff looks the same of course as any other thing does ...
>
> Have we captured these "different deployment and operational requirements"
> anywhere? I think might be very useful...
>
> Thanks,
> Chris.
> [as wg member]
>
>
> > -- tony
> >
> > On Tue, Dec 7, 2021 at 7:17 PM Les Ginsberg (ginsberg)  > 40cisco@dmarc.ietf.org> wrote:
> >
> >
> > When I look at this request, I see it in a larger context.
> >
> >
> >
> > There are two drafts which attempt to address the same problem in
> > very different ways:
> >
> >
> >
> > https://datatracker.ietf.org/doc/
> > draft-ietf-lsr-isis-flood-reflection/
> >
> >
> >
> > and
> >
> >
> >
> > https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-area-proxy/
> >
> >
> >
> > Both of them discuss in their respective introductions the
> > motivation – which is to address scaling issues in deployment
> > scenarios where the existing IS-IS hierarchy is being asked to
> > “stand on its head” i.e., interconnection between different L1
> > areas is not to be achieved by utilizing an L2 backbone – rather
> > it is the L1 areas themselves which are required to be used for
> > interconnection of sites (e.g., two datacenters) and the scaling
> > properties of the existing protocol hierarchy when used in this
> > way are not attractive.
> >
> >
> >
> > I find no technical basis on which to choose between the two
> > proposed solutions – so in my mind a last call for
> > “Flood-Reflection” presupposes a last call for “Area Proxy” – and
> > therein lies my angst.
> >
> > The end result will be that multiple incompatible solutions to
> > the same problem will be defined. It will then be left to
> > customers to try to determine which of the solutions seems best
> > to them – which in turn will put the onus on vendors to support
> > both solutions (depending on the set of customers each vendor
> > supports).
> >
> > This – to me – represents an utter failure of the standards
> > process. We are reduced to a set of constituencies which never
> > find common ground – the end result being sub-optimal for the
> > industry as a whole.
> >
> >
> >
> > It seems to me that the proper role of the WG is to address the
> > big questions first:
> >
> >
> >
> > 1)Is this a problem which needs to be solved by link-state
> > protocols?
> >
> > We certainly have folks who are clever enough to define solutions
> > – the two drafts are a proof of that.
> >
> > But whether this is a wise use of the IGPs I think has never been
> > fully discussed/answered.
> >
> > Relevant to this point is past experience with virtual links in
> > OSPF – use of which was problematic and which has largely fallen
> > out of use.
> >
> > Also, many datacenters use BGP (w or w/o IGP) and therefore have
> > other ways to address such issues.
> >
> > Although I am familiar with the “one protocol is simpler”
> > argument, whether that justifies altering the IGPs in any of the
> > proposed ways is still an important question to discuss.
> >
> >
> >
> > 2)If link state protocols do need to solve this problem, what is
> > the preferred way to do that?
> >
> > This requires meaningful dialogue and a willingness to engage on
> > complex technical issues.
> >
> >
> >

Re: [Lsr] Using L1 for Transit Traffic in IS-IS

[Tony Przygienda]

On Sun, Dec 12, 2021 at 6:22 PM Tony Li  wrote:

>
> Tony,
>
>
> > The new LSP seems to imply a forklift of the whole network which area
> proxy does not require, in fact flood reflection has been carefully
> constructed to touch minimum possible amount of nodes in the network and
> additionally allow a node-by-node migration.


>
> To be accurate, area proxy requires that the nodes within the area support
> area proxy.  No upgrade of the nodes outside of the abstracted area is
> required. Only software upgrades are requires, so no forklifts are required.
>
>
I re-read carefully and yes, I do stand corrected. only nodes in area need
to be upgraded

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

Re: [Lsr] Using L1 for Transit Traffic in IS-IS

[Tony Przygienda]

>
> The flood reflectors can sit in the control plane so not in the forwarding
> plane or can be in the forwarding plane with L1 or L2 shortcut.  So all
> paths including the flood Reflector path can be used for forwarding,
> however do to 1 hop L1 and L2 shortcut the flood reflector path can be
> bumped up in coast so not preferred to prevent choking the flood reflectors
> similar to issue where we exclude the BGP RR from forwarding plane so we
> don’t choke the RR. My worry is the sub optimal routing from the 1 hop
> tunnels could lead to routing loops of which as mentioned the workaround is
> to cost high  the flood reflector path so it’s only used for control plane
> flooding.
>
>
> Responses in-line
>
> Kind Regards
>
> Gyan
>
>
> On Sat, Dec 11, 2021 at 10:43 AM Les Ginsberg (ginsberg) <
> ginsb...@cisco.com> wrote:
>
>> Gyan –
>>
>>
>>
>> Both drafts have been adopted as WG documents and been provided with
>> early allocation of codepoints.
>>
> Gyan> As co-author I am aware
>
>> So there is nothing preventing implementations/deployments from
>> proceeding and doing so without fear that if/when the documents proceed to
>> become RFCs that there will be backwards compatibility issues because of
>> codepoint changes.
>>
>> My concern is that there is no effort underway since WG adoption to use
>> implementation experience to compare/contrast the solutions and determine
>> whether one is better and/or if there really is a need for multiple
>> solutions. That seemed to me to be the point of adopting both.
>>
>Gyan>  In my response here I tried to  provide an unbiased compare and
> contrast of the two solutions.
>
>> I do not see the need to progress either document to RFC at this time –
> and I am concerned that in doing so we make it even less likely that such a
> comparison will ever be made.
>
>  Gyan> I did the comparison above and I can further elaborate
>
> I had hoped – as you are a representative of one of the potential users of
> this technology and you had suggested that there might be reasons why you
> were interested in both – that you could provide some input into when one
> solution was more desirable than another.
>
>  Gyan> Just to clarify that as an operator this is scalability issue is a
> real world problem that needs to be solved.  As I am Co-Author of the Area
> Proxy draft I truly believe that is a better solution, however this is a
> solution that definitely needs solved..
>
> The value add provided by a standards organization is that it allows the
> industry to converge on an interoperable solution. If we simply become a
> means of allocating codepoints in support of multiple non-interoperable
> solutions then I think we as an organization have failed.
> Gyan> Agreed.  Interoperability is critical for all operators and is
> what makes SDOs so valuable
>
>> This does not mean that we should not support experimentation – and in
> this case I think we are doing so.
>
>  Gyan> Agreed.  And be able to progress both experimental to RFC and let
> the industry decide on the best solution and then progress that solution as
> standards track
>
>>Les
>>
>>
>>
>> *From:* Gyan Mishra 
>> *Sent:* Friday, December 10, 2021 10:56 PM
>> *To:* Les Ginsberg (ginsberg) 
>> *Cc:* Acee Lindem (acee) ; Muthu Arul Mozhi Perumal <
>> muthu.a...@gmail.com>; Tony Li ; Tony Przygienda <
>> tonysi...@gmail.com>; lsr@ietf.org
>> *Subject:* Re: [Lsr] Using L1 for Transit Traffic in IS-IS
>>
>>
>>
>>
>>
>> Hi Les
>>
>>
>>
>> My thoughts are that as both of these drafts are experimental, if both
>> get published we can let the industry decide which is to be the preferred
>> solution which can then progress as standards track to address
>> interoperability issues with a single solution implemented by vendors.
>>
>>
>>
>> I think by picking one now over the other we are not letting the cards
>> fall on the table and prematurely making a decision and not letting things
>> naturally play out.
>>
>>
>>
>> I agree the implementation of each is non trivial however the router
>> configuration could boil down to a simple knob similar to fast flooding.
>> As an example there maybe use cases that for a DC CLOS topology where area
>> proxy with n-way ECMP paths leaf to scale out spine maybe better suited,
>> however in a core or aggregation domain maybe flood reflection maybe
>> preferred from a topological perspective  during the study phase.
>>
>>
>>
&

Re: [Lsr] WG Last Call fo "IS-IS Flood Reflection" -draft-ietf-lsr-isis-flood-reflection-05

[Tony Przygienda]

inline. last email from my side in this thread.


On Sat, Dec 11, 2021 at 3:47 PM Aijun Wang 
wrote:

> Hi, Tony:
>
> The advantage of IGP is that it can cure itself when there is any topology
> change, no additional  operator intervention involved.
>

neither is it in FR case. if you lose all FRs it's not different than
traversing L1 today by means of L1/L2 routers and losing all such routers.
if you have FRs you have all the IGP properties.


> But from your explanation below, there are situations that the draft
> doesn’t covered for the possible loop scenarios. Additional route compare
> rules or configuration requirements needed to be added when such thing
> happens. Then can we call the current solution is not final?
>

nothing needs be added except what the draft describes unless you have
real, concrete examples where the draft rules are not enough assuming a
correctly working implementation.


> And, if we lack one trust theory to avoid the loop, we will be stuck in
> the emerged loop situations.
>

I cannot control what you trust or don't trust based simply on an opinion
you harbor without concrete technical arguments or operational experience.
And unfortunately I am of a distinct "opinion" that whatever technical
explanation I gi8ve you will not change your "opinion" here anyway.


>
> let's be more precise beyond sensationalist headlines ... Though it's nice
> you found our documentation and based on that make first technical argument
> ;-)
>
> a) transitory loops during convergence/tunnel setup may exist, those also
> exist during normal ISIS convergence. Simple implementation techniques used
> in other contexts since many years exist like e.g. holding the router in
> overload until converged. That can be also easily implemented if e.g. a FR
> client has no FR tunnel established. A draft/spec is not an implementation
> description however so techniques deployed can be very different and
> starting to put that in will lead to overspecification.
>
>
> [WAJ] From the example that illustrated in the mentioned example, it seems
> the loop is not transient. It seems when R1 is not act as FR client, the
> loop will occur then?
>

sigh, now I start to explain documentation instead of you reading &
understanding the draft and that's not really the purpose of this list. The
condition can be only transitory or otherwise R1 is separate from R0 in L1
(if it is not then it will form the tunnel to FR via R0 [and there is also
a very weird case of R0 being in overload which however also works]). If
it's separated from R0 in L1 R0 will not see the leaked route and hence
cannot loop via leaked L2->L1. If you have an implementation that is a
client but will not form the FR tunnel persistently despite being L1
connected to FR while nevertheless leaking L2->L1 then it's simply a buggy
implementation and nothing can prevent anything from happening then.

I wish personally this doc section was never written or published BTW
though it was surely well-meant as "operational help".


>
> b) let's split the rest assuming full convergence scenario into tunnel;
> and no L1 tunnels case
> ib.) L1 tunnel case when all tunnels in place/converged is simple, it's
> identical really to any shortcut forwarding where the next hop is a tunnel,
> the packet just shows up magically @ the egress. this is AFAIS simpler
> option to understand and deploy correctly. If you harbor fears and doubts
> about the whole thing or looping potential, just use this.
>
>
> [WAJ] Then the merit that you compared with TTZ will go away?
>

 no, FR does NOT expose the L1 tunnel mesh if you have it in L2 contrary to
TTZ (which floods equivalent of a full tunnel mesh to the outside).
Actually the mesh does not even have to be flooded in L1 in flood
reflection case so ISIS is stable (but it can depending on e.g. liveliness
requirements and so on). I have to remark frankly, it seems to me your
grasp of even the most fundamental properties of the different
solutions/trade-offs in all those drafts is tenuous.


> b.ii) no tunnel case is more delicate (but hotly desired by many [arguably
> sophisticated] customers hence the work). If the SPF is implemented
> correctly no routing loops exist when converged.
>
> This preconditions  also correct leaking of L1 into L2 (hence the "all
> egress MUST be clients", it could work with a mix but the draft gets
> unnecessarily complex) and section 5.2 of the draft provides the necessary
> implementation on SPF to prevent loops in every case.
>
> [WAJ] As Acee pointe out also, this section is harder to understand and
> not in clear logic. I doubt and am unconvinced that it can cover every case.
>

this is a spec and not a story except the introduction section maybe. Specs
are written by defining rules. The section gives all the rules SPF needs to
implement for the solution to work correctly.


>
> However, as the documentation you found says it is easier to ensure that
> L1 metrics when deployed are shorter than L2 metrics 

Re: [Lsr] WG Last Call fo "IS-IS Flood Reflection" -draft-ietf-lsr-isis-flood-reflection-05

[Tony Przygienda]

sorry, seems you didn't parse what I wrote in previous email and keep on
generating FUD. The solution is loop free if the draft is correctly
implemented in both tunnel and no-tunnel scenario. The rest is subtlety of
how you deploy it (and implementation choices) that I tried to explain. I
cannot put it more simply than that ...

-- tony

On Sat, Dec 11, 2021 at 3:47 PM Aijun Wang 
wrote:

> Hi, Tony:
>
> The advantage of IGP is that it can cure itself when there is any topology
> change, no additional  operator intervention involved.
> But from your explanation below, there are situations that the draft
> doesn’t covered for the possible loop scenarios. Additional route compare
> rules or configuration requirements needed to be added when such thing
> happens. Then can we call the current solution is not final?
> And, if we lack one trust theory to avoid the loop, we will be stuck in
> the emerged loop situations.
>
> Some additional replies inline.
>
> Aijun Wang
> China Telecom
>
> On Dec 11, 2021, at 20:08, Tony Przygienda  wrote:
>
> 
> let's be more precise beyond sensationalist headlines ... Though it's nice
> you found our documentation and based on that make first technical argument
> ;-)
>
> a) transitory loops during convergence/tunnel setup may exist, those also
> exist during normal ISIS convergence. Simple implementation techniques used
> in other contexts since many years exist like e.g. holding the router in
> overload until converged. That can be also easily implemented if e.g. a FR
> client has no FR tunnel established. A draft/spec is not an implementation
> description however so techniques deployed can be very different and
> starting to put that in will lead to overspecification.
>
>
> [WAJ] From the example that illustrated in the mentioned example, it seems
> the loop is not transient. It seems when R1 is not act as FR client, the
> loop will occur then?
>
> b) let's split the rest assuming full convergence scenario into tunnel;
> and no L1 tunnels case
> ib.) L1 tunnel case when all tunnels in place/converged is simple, it's
> identical really to any shortcut forwarding where the next hop is a tunnel,
> the packet just shows up magically @ the egress. this is AFAIS simpler
> option to understand and deploy correctly. If you harbor fears and doubts
> about the whole thing or looping potential, just use this.
>
>
> [WAJ] Then the merit that you compared with TTZ will go away?
>
> b.ii) no tunnel case is more delicate (but hotly desired by many [arguably
> sophisticated] customers hence the work). If the SPF is implemented
> correctly no routing loops exist when converged.
>
> This preconditions  also correct leaking of L1 into L2 (hence the "all
> egress MUST be clients", it could work with a mix but the draft gets
> unnecessarily complex) and section 5.2 of the draft provides the necessary
> implementation on SPF to prevent loops in every case.
>
> [WAJ] As Acee pointe out also, this section is harder to understand and
> not in clear logic. I doubt and am unconvinced that it can cover every case.
>
> However, as the documentation you found says it is easier to ensure that
> L1 metrics when deployed are shorter than L2 metrics so the L1->L2 route
> always takes preference towards the egress and not rely on the correct SPF
> preferece outside metric comparison.
>
>
> [WAJ] To achieve this, the design should be verified by manual carefully?
>
> As footnote: redistributing prefixes in ISIS is always delicate, nothing
> new here, L1->L2->L1 was originally forbidden and only works with the RFC
> and lots of tightly kept pref rules. With enough inventive re-distribution
> on a system around the RFC and fiddiling via policy with redistributed
> route properties you can loop up normal ISIS as well BTW.
>
>
> [WAJ] Can I say that your solution is based on the original forbidden
> design? To explore the forbidden, you introduce the additional SPF rules.
> When the topology or interconnection scenario become complex, will the SPF
> rules complex also?
>
> c) ECMP, yes, as our doc says it's not looping but it can be changed when
> using b.ii) unless whole network is forklifted to flood reflection and e.g.
> omits ECMP computed over FR adjacencies which again, is an implementation
> technique that is optional complexity since FR adjacencies are not
> forwarding (one could make them taht and stuff would still work but then we
> would have all kind of restrictions on tunnels like e.g. XoUDP to ECMP
> inside L1 and ultimately shove e'thing though FRs, most customers think
> that doing L2 hot potato forwarding out the area is actually far preferred
> IME).
>
> And no, you will never achieve the same "globall

Re: [Lsr] Using L1 for Transit Traffic in IS-IS

[Tony Przygienda]

it's a circular argument to an extent (though I'm sympathetic with the
thought). Unless a draft is an experimental RFC there is no real stable
point to implement & deploy so it's hard these days to get 2
implementations unless one sponsors an open source one (and nature of ISIS
is that there is barely any open source given that it runs normally @ scale
& feature count that open source is simply not efficient enough though I
admit it maybe just my lens to an extent).

So having nothing experimental and nevertheless deployed generates then
de-facto proprietary stuff since deployed solutions become pretty immovable
targets as we all know.

So, take your pick but it's hard to have it both ways these days IMO ...

-- tony

On Sat, Dec 11, 2021 at 4:14 PM Robert Raszuk  wrote:

>
> Well WFIW IDR solved this dilemma by mandating at least two documented
> implementations before proceeding with any proposal to IESG (irrespective
> of the RFC document type).
>
> After all nothing stops anyone from implementing an idea described in the
> WG document using if needed early code point allocations.
>
> On the other hand having RFC experimental status of any proposal ensures
> it has been reviewed by a number of people and that at least no major
> issues have been found during the review.
>
> Of course IGP is not BGP though both use multiple vendors network
> elements, but I guess that would narrow the gates of single vendors pushing
> their own proprietary solutions via IETF.
>
> Kind regards,
> Robert
>
> On Sat, Dec 11, 2021 at 7:56 AM Gyan Mishra  wrote:
>
>>
>> Hi Les
>>
>> My thoughts are that as both of these drafts are experimental, if both
>> get published we can let the industry decide which is to be the preferred
>> solution which can then progress as standards track to address
>> interoperability issues with a single solution implemented by vendors.
>>
>> I think by picking one now over the other we are not letting the cards
>> fall on the table and prematurely making a decision and not letting things
>> naturally play out.
>>
>> I agree the implementation of each is non trivial however the router
>> configuration could boil down to a simple knob similar to fast flooding.
>> As an example there maybe use cases that for a DC CLOS topology where area
>> proxy with n-way ECMP paths leaf to scale out spine maybe better suited,
>> however in a core or aggregation domain maybe flood reflection maybe
>> preferred from a topological perspective  during the study phase.
>>
>> I don’t have a crystal ball but it’s possible just as winning the lottery
>> is possible that both drafts garnish industry support and from a sales and
>> marketing perspective vendors can still have their cake and eat it too by
>> solving a major backbone scalability issue win win for all and so
>> developing both solutions that become standards track and implemented by
>> all vendors.  No interoperability issues.
>>
>> I am in agreement on implementation that in the end having a single
>> solution is most desirable to avoid interoperability.
>>
>> Kind Regards
>>
>> Gyan
>>
>> On Sat, Dec 11, 2021 at 12:24 AM Les Ginsberg (ginsberg) <
>> ginsb...@cisco.com> wrote:
>>
>>> Gyan –
>>>
>>>
>>>
>>> I am interested in your perspective – but could you provide more details?
>>>
>>> What deployment scenarios do you have in mind where one solution is
>>> advantageous over the other? And why are both scenarios likely to be seen
>>> in the real world?
>>>
>>>
>>>
>>> I think you can appreciate that implementation of either solution is
>>> non-trivial – as is insuring interoperability – as is the actual deployment.
>>>
>>> What justifies doubling that effort?
>>>
>>>
>>>
>>> Thanx.
>>>
>>>
>>>
>>> Les
>>>
>>>
>>>
>>> *From:* Gyan Mishra 
>>> *Sent:* Friday, December 10, 2021 5:46 PM
>>> *To:* Muthu Arul Mozhi Perumal 
>>> *Cc:* Acee Lindem (acee) ; Les Ginsberg (ginsberg) <
>>> ginsb...@cisco.com>; Tony Li ; Tony Przygienda <
>>> tonysi...@gmail.com>; lsr@ietf.org
>>> *Subject:* Re: [Lsr] Using L1 for Transit Traffic in IS-IS
>>>
>>>
>>>
>>> All
>>>
>>>
>>>
>>> As Acee mentioned per the subject of this thread “Using L1 for transit
>>> traffic in IS-IS” is supported today and is deployed by operators with
>>> large backbones as well today, and both so

Re: [Lsr] WG Last Call fo "IS-IS Flood Reflection" -draft-ietf-lsr-isis-flood-reflection-05

[Tony Przygienda]

let's be more precise beyond sensationalist headlines ... Though it's nice
you found our documentation and based on that make first technical argument
;-)

a) transitory loops during convergence/tunnel setup may exist, those also
exist during normal ISIS convergence. Simple implementation techniques used
in other contexts since many years exist like e.g. holding the router in
overload until converged. That can be also easily implemented if e.g. a FR
client has no FR tunnel established. A draft/spec is not an implementation
description however so techniques deployed can be very different and
starting to put that in will lead to overspecification.
b) let's split the rest assuming full convergence scenario into tunnel; and
no L1 tunnels case
ib.) L1 tunnel case when all tunnels in place/converged is simple, it's
identical really to any shortcut forwarding where the next hop is a tunnel,
the packet just shows up magically @ the egress. this is AFAIS simpler
option to understand and deploy correctly. If you harbor fears and doubts
about the whole thing or looping potential, just use this.
b.ii) no tunnel case is more delicate (but hotly desired by many [arguably
sophisticated] customers hence the work). If the SPF is implemented
correctly no routing loops exist when converged. This preconditions  also
correct leaking of L1 into L2 (hence the "all egress MUST be clients", it
could work with a mix but the draft gets unnecessarily complex) and section
5.2 of the draft provides the necessary implementation on SPF to prevent
loops in every case. However, as the documentation you found says it is
easier to ensure that L1 metrics when deployed are shorter than L2 metrics
so the L1->L2 route always takes preference towards the egress and not rely
on the correct SPF preferece outside metric comparison. As footnote:
redistributing prefixes in ISIS is always delicate, nothing new here,
L1->L2->L1 was originally forbidden and only works with the RFC and lots of
tightly kept pref rules. With enough inventive re-distribution on a system
around the RFC and fiddiling via policy with redistributed route properties
you can loop up normal ISIS as well BTW.
c) ECMP, yes, as our doc says it's not looping but it can be changed when
using b.ii) unless whole network is forklifted to flood reflection and e.g.
omits ECMP computed over FR adjacencies which again, is an implementation
technique that is optional complexity since FR adjacencies are not
forwarding (one could make them taht and stuff would still work but then we
would have all kind of restrictions on tunnels like e.g. XoUDP to ECMP
inside L1 and ultimately shove e'thing though FRs, most customers think
that doing L2 hot potato forwarding out the area is actually far preferred
IME).

And no, you will never achieve the same "globally optimal" routing through
the whole topology in L2 when abstracting some L1 things except when you
advertise a full mesh of links reflecting all ingress-egress metrics in L2
being basically L1 shortest path (or assume that all ingress/egress
connections have infinite/same metric, it's called a chassis or more
precisely a switching fabric then ;-). Beside scaling very poorly as the
draft explains this can also cause a single link failing in L1 to cause a
havoc of advertisements in L2 and if you are experienced in operational
matters this is the last things you desire. In more abstract control theory
terms you are building with such a solution a negatively stable system of
control loops or in simpler terms an invisible big blast radius. Good for
fighter planes, very bad for networking if you experienced those effects.

hope that's enough details, none of this is BTW pure speculation but output
of implemenation and extensive testing.

--- tony

On Sat, Dec 11, 2021 at 8:48 AM Aijun Wang 
wrote:

> Please refer to “Routing Loops” section that described in your company’s
> documents:
>
> https://www.juniper.net/documentation/en_US/junos/topics/concept/understanding-isis-flood-reflectors.html#jd0e162
>
> This is just the simplest transit scenario. I am worrying for its further
> applications.
>
> The overall routing path for L2 topologies that connected by several L1 is
> not determined by one L2 SPF algorithm, how can you assure no loop occur?
>
> Is it nightmare or mess for the operator to run its network in such
> challenges situations?
>
> Aijun Wang
> China Telecom
>
> On Dec 11, 2021, at 02:02, Tony Przygienda  wrote:
>
> 
> What you describe is not technical reality when you're dealing with SPF in
> L2 ... You seem to be deeply confused (but honestly, I have a hard time to
> even figure out what kind of assumptions you're making about all kind of
> things in all those threads about IGPs these days and on what but personal
> preferences all those claims of "better" things are based) by the simple
> fact that there is only 

Re: [Lsr] WG Last Call fo "IS-IS Flood Reflection" -draft-ietf-lsr-isis-flood-reflection-05

[Tony Przygienda]

What you describe is not technical reality when you're dealing with SPF in
L2 ... You seem to be deeply confused (but honestly, I have a hard time to
even figure out what kind of assumptions you're making about all kind of
things in all those threads about IGPs these days and on what but personal
preferences all those claims of "better" things are based) by the simple
fact that there is only a single connected L2 area ever in ISIS, if you
partition L2 you do not run ISIS within its viable envelope anymore, with
or without extensions. And L2 SPF will never loop and flood reflector draft
does not change the path taken in L2 so by first order logic you won't
loop. That is BTW one of the reasons why you will want to deploy multiple
flood reflectors per L1 (to not partition L2).

As Acee pointed out, unlike OSPF (discounting alternate ABR behavior) L2
could in ISIS from day one use L1 to "traverse across" (if you squint a bit
;-)  in a sense and those drafts just improve the behavior so we are not
even architecturally changing the topological properties of the protocol
(whatever that means without delving deeply into graph theory definitions
;-)

-- tony

On Fri, Dec 10, 2021 at 1:40 AM Aijun Wang 
wrote:

> Hi, Acee:
>
> No, I think the WG participations would like to enjoy the interested and
> correct direction topics.
> One technical considerations is the following: if IGP evolved into this
> direction, then the following connections loop diagram is also possible:
> L2-L1-L2-L1-L2-L1-…..-L2(back to the origin)
> Then, will we introduce the “AS number” to avoid loop, and various “Path
> Attributes” to influence the path selection within the IGP?
>
> There is a rush to adopt this draft, we should not rush again to
> accomplish its WG last call.
>
>
> Aijun Wang
> China Telecom
>
> On Dec 9, 2021, at 10:07, Acee Lindem (acee)  40cisco@dmarc.ietf.org> wrote:
>
> 
>
> Hi Aijun,
>
>
>
> At least I’ve had several discussions with authors on the draft and you’ll
> note my comments on the list. The lack of further discussion on the list is
> a general problem in LSR. It seems many WG participants only want to
> discuss the draft that they have authored and it is hard to get comment
> without forcing the issue without an adoption or last call. I’m expecting
> at least one more review on the draft. Technical comments on the draft
> would be appreciated.
>
>
>
> Thanks,
> Acee
>
>
>
> *From: *Aijun Wang 
> *Date: *Wednesday, December 8, 2021 at 11:15 AM
> *To: *Acee Lindem 
> *Cc: *"Les Ginsberg (ginsberg)" , "lsr@ietf.org" <
> lsr@ietf.org>
> *Subject: *Re: [Lsr] WG Last Call fo "IS-IS Flood Reflection"
> -draft-ietf-lsr-isis-flood-reflection-05
>
>
>
> Hi, Acee:
>
>
>
> I found there is no any technical discussion on the list for the mentioned
> draft after its adoption(from 2020-7-6), even before its adoption.
>
> There is only one presentation for its update at the IETF 111 meeting(1
> pages, 5 minutes) and after it’s presentation at IETF 112, the WG Last Call
> is issued.
>
>
>
> From the authors’ statement, there is only the author’s affiliation
> implemented it, no interoperability problems can be found.
>
>
>
> From the discussion in these days, it is doubtful for IGP to evolve into
> this direction as behaved by BGP.
>
>
>
> From the POV of the operator, we will not consider such strange design to
> scale the IS-IS.
>
>
>
> From the documents itself, there are unsolved problems (for example in
> section 7) which can only be solved by “sending alarm and declare
> misconfiguration).
>
>
>
> Then, why it is ready to WG Last Call?
>
>
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> On Dec 8, 2021, at 06:28, Acee Lindem (acee)  40cisco@dmarc.ietf.org> wrote:
>
> Hi Les,
>
>
>
> *From: *"Les Ginsberg (ginsberg)" 
> *Date: *Tuesday, December 7, 2021 at 5:10 PM
> *To: *"Acee Lindem (acee)" , Acee Lindem
> , "lsr@ietf.org" 
> *Subject: *RE: [Lsr] WG Last Call fo "IS-IS Flood Reflection"
> -draft-ietf-lsr-isis-flood-reflection-05
>
>
>
> Let me try to respond to Acee/Tony/Tony in one email.
>
>
>
> Acee – I don’t like any of the proposals. I believe they are all abusing
> the protocols to some degree.
>
>
>
> That’s fine if you have technical concerns with the individual drafts. The
> problem space discussion is a moot point since the WG has already adopted
> these documents.
>
>
>
> Thanks,
>
> Acee
>
>
>
> I fully believe that the authors are clever enough to figure out how to
> make this work – but that doesn’t mean any of them are desirable.
>
> So if I have to “vote” – I vote “no”.
>
>
>
> Tony Li –
>
>
>
> Area Proxy Introduction says in part:
>
>
>
> “Following the current rules of IS-IS, all spine routers would
>
>necessarily be part of the Level 2 topology, plus all links between a
>
>Level 2 leaf and the spines.  In the limit, where all leaves need to
>
>support Level 2, it implies that the entire L3LS topology becomes
>
>part of Level 2.  This is seriously problematic as it more than
>
> 

Re: [Lsr] Using L1 for Transit Traffic in IS-IS

[Tony Przygienda]

On Thu, Dec 9, 2021 at 8:05 PM Les Ginsberg (ginsberg) 
wrote:

> ...
>
> I don’t believe the WG has reached consensus that the IGPs should be
> extended to address the problem.
>

AFAI the process for that is an adoption call. And with a quick look I see
you on

Sun, Jun 21, 2020
supporting the adoption of @ least the reflection draft and working on the
problem space so what I read here is wildly inconsistent in my eyes. I
think I also responded with a detailed answer then why the "hierarchical
isis" draft will likely not scratch the itch I am asked to scratch. That
seemed to close the thread to your satisfaction.



> I don’t believe the WG has reached consensus as to which solution is
> “better”.
>
> I don’t believe the WG has even discussed whether a single solution or
> multiple solutions are required.
>
> If multiple solutions are required, there has been no discussion as to
> when each of the solutions should be used. Are there some deployment
> scenarios where flood-reflection is a better fit and some where area proxy
> is a better fit?
>
> Is there a need for additional solutions i.e., deployments where neither
> of the current candidates are suitable?
>

Drafts have been there for 2 years more or less & I don't remember you
showing particular interest in it on the 50 odds threads regarding
reflection at least that I find on mailing list in addition to all the
private reviews/comments I got ... At least from my side the progress was
well documented and co-authorship of other vendors was invited more than
once.

So, frankly, I acknowledge your current feelings and opinions without any
hard technical input but the world needed the problem solved, things had to
move in a timely manner & so the world now deploys the solution that meets
the requirements and was converged on technically in IETF and having an RFC
has really as always just the function of having a "stable snapshot" and
facilitate RFPs ...

so, ?

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

Re: [Lsr] WG Last Call for "IS-IS Flood Reflection" -draft-ietf-lsr-isis-flood-reflection-06

[Tony Przygienda]

comments addressed and new version posted

-- tony

On Tue, Dec 7, 2021 at 7:24 AM Shraddha Hegde  wrote:

> This is a very useful feature for large L2 networks and I support the
> publication of this
>
> document.
>
>
>
>
>
> I have below nits/suggestions on the document.
>
>
>
>
>
> 1. Figure 1: Example Topology of L1 with L2 Borders
>
> The diagram is not legible. The connections between L1 routers
>
> can be removed from the diagram and a description can be added that
>
> R1 layer routers are all connected to R2 layer and so on.
>
> From the diagram it appears that there is connectivity between R10 and R11
>
> and R11 and R12. If so that link can flood L2 domains and L2 is not
>
> fully disjoint. I would suggest to remove the R10->R11 link to show a pure
> clos topology
>
> in L1.
>
>
>
> 2.
>
> 4.1 Flood reflection TLV
>
> "On a given router, the same value
>
>   of the Flood Reflection Cluster ID MUST be advertised across all
>
>   interfaces advertising the Flood Reflection TLV in IIHs. "
>
>
>
> Do we really need this restriction of one single cluster-id on a router?
>
> I am imagining, this cluster-id mechanism can be used to segregate a
> single fabric
>
> into two or more clusters if the fabric size becomes too huge.
>
> The usecase itself is described out of scope for this document elsewhere
>
> which is fine but too restrictive statements like above would discourage
> further
>
> enhancements so may be worth considering these restrictions to be removed.
>
>
>
> 3.
>
> 4.2.  Flood Reflection Discovery Sub-TLV
>
> " A router receiving multiple Flood Reflection
>
>Discovery sub-TLVs in TLV 242 MUST use the values in the first sub-
>
>TLV"
>
>
>
>first sub-TLV is not deterministic as multiple TLV 242 can come is
> different fragments.
>
>Suggest to change as below.
>
>" A router receiving multiple Flood Reflection
>
>Discovery sub-TLVs in TLV 242 MUST use the values in the first sub-
>
>TLV of the lowest numbered fragment"
>
>
>
>4.
>
>"flood reflection tunnel endpoint" and "L1 shortcut"
>
>terminology should be added to the glossary. These terms are used in
> sec 4.3
>
>and reader may not get the context of these terms.
>
>
>
>
>
>
>
>5. section 4.3
>
>
>
>do we need the F bit? Looks like this info can be derived from the
>
>C bit in Flood Reflection Discovery Sub-TLV. The ones with C bit set
> are possible shortcut endpoints.
>
>The ones with C bit cleared are the flood reflector tunnel endpoints.
>
>
>
>
>
>6. The tunnel encapsulation attribute has use outside of flood reflector
>
>(such as RFC 8663). I am more in favor of getting rid of the F bit from
> this sub-TLV
>
>as to avoid the confusions that may arise when it is used in the
> absence of flood reflectors.
>
>
>
>7.
>
>" A flood reflector receiving multiple Flood Reflection Discovery
>
>Tunnel Type sub-sub-TLVs in Flood Reflection Discovery sub-TLV with F
>
>flag set SHOULD use one or more of the specified tunnel endpoints to
>
>automatically establish one or more tunnels that will serve as flood
>
>reflection adjacency(-ies)."
>
>
>
>A flood reflector should establish tunnels with clients only and not
> with
>
>other flood reflectors. also the cluster id needs to match.
>
>This text as well as next para needs revision.
>
>
>
>8. sec 4.4
>
>
>
>"The Flood Reflection Adjacency sub-TLV SHOULD NOT appear more than
>
>once in a given TLV.  A router receiving multiple Flood Reflection
>
>Adjacency sub-TLVs in a TLV MUST use the values in the first sub-TLV
>
>and it SHOULD adequately log such violations subject to rate
>
>limiting."
>
>
>
>IMO should talk abt possibility of same TLV 22 in multiple fragments
> and
>
>MUST use first sub-TLV from lowest numbered fragment.
>
>
>
>9.
>
>
>
>"If the clients have a
>
>direct L2 adjacency they SHOULD use it instead of instantiating a new
>
>tunnel."
>
>
>
>above statement seems to contradict statement below in sec 4.5
>
>" A router acting as a flood reflector MUST NOT have any traditional L2
>
>adjacencies. "
>
>
>
>
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Lsr  *On Behalf Of *Acee Lindem (acee)
> *Sent:* Friday, December 3, 2021 9:22 PM
> *To:* Antoni Przygienda 
> *Cc:* lsr@ietf.org
> *Subject:* [Lsr] WG Last Call for "IS-IS Flood Reflection"
> -draft-ietf-lsr-isis-flood-reflection-06
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Speaking as WG member:
>
>
>
> I have already supported publication. I have a couple comments:
>
>
>
>1. Can you add “leave” to the glossary in section 2?
>2. Section 5.2 is a bit hard to read. I have some suggested changes in
>my
>
> editorial comments but it would be good to expand the cases into smaller
>
> chunks and make state the overall goals ahead rather than after the
> details.
>
>   Your call though.
>
>1. In section 7, would an IS-IS router 

Re: [Lsr] Using L1 for Transit Traffic in IS-IS

[Tony Przygienda]

Les, all sounds to me unfortunately like a gripe (and a late one @ that now
that things were worked on in WG for years & are ready to RFC being
customer deployed, @ least flood reflection is).

Plus,  unless you have a dramatically better idea than the drafts extended
I fail to understand what your point is except as Tony1 says "we should not
scale IGP higher?" (AFAIS hierarchy is not an answer here unless you ask
customers for a flag day with lots new static configuration everywhere and
possibly restructuring of their network to a hard-coded "hierarchy" and
albeit such effort may work in some totalitarian countries on in pretty
small networks, the majority of large ISIS customers will end such
discussions in timeframe of single minutes clock count ;-)

-- tony

On Wed, Dec 8, 2021 at 4:23 AM Les Ginsberg (ginsberg)  wrote:

> (Subject was:  RE: [Lsr] WG Last Call for "IS-IS Flood Reflection"
> -draft-ietf-lsr-isis-flood-reflection-05)
>
>
>
> (Changing the subject as Acee has suggested that discussion of the problem
> space is inappropriate for the WG LC thread)
>
>
>
> Tony (and everyone) –
>
>
>
> This isn’t the first contentious issue the WG has considered. By way of
> comparison (hopefully a useful one), a number of folks (including you and
> I) are participating in another contentious issue – fast-flooding.
>
> But for fast-flooding there is broad WG consensus that fast-flooding is
> something that IS-IS should do. The contentious part is regarding what is
> the best way to do it. And we are proceeding in a manner where different
> algorithms are being tested while still in the WG document stage. And there
> is hope (still TBD) that multiple algorithms may be able to interoperate.
>
>
>
> Here, I am not convinced that there is broad WG consensus that this is a
> problem that the IGPs should solve. (If I am wrong on that I presume the WG
> members will let me know.)
>
> And, we have multiple proposals, none of which have any hope of
> interoperating with each other.
>
> And we have had very little discussion about the problem space. (not your
> fault – certainly you have been willing as have the authors of the
> competing draft)
>
>
>
> So, at best, I think WG LC is premature. I would like to see more
> discussion as to whether this is a problem that IGPs should solve as well
> as a general look at how this might be done with and/or without the IGPs.
>
> And since all of the proposed solutions have been allocated code points,
> they can continue to gain implementation/deployment experience in the
> meantime. Therefore, I do not see that we need to make this choice now.
>
>
>
> I realize that you are not the one asking for WG LC and I don’t know when
> you plan to do so and I am not trying to influence you in that regard.
>
> But for me, WG LC is at best premature.
>
>
>
> As regards you trying to solve a real world customer ask, I was aware of
> that. And I believe the authors of flood-reflection can make the same claim.
>
>
>
> Thanx for listening,
>
>
>
> Les
>
>
>
>
>
>
>
>
>
> *From:* Tony Li  *On Behalf Of *Tony Li
> *Sent:* Tuesday, December 7, 2021 2:53 PM
> *To:* Les Ginsberg (ginsberg) 
> *Cc:* Acee Lindem (acee) ; Acee Lindem (acee) <
> a...@cisco.com>; lsr@ietf.org
> *Subject:* Re: [Lsr] WG Last Call fo "IS-IS Flood Reflection"
> -draft-ietf-lsr-isis-flood-reflection-05
>
>
>
>
>
> Les,
>
>
>
> And in response to Tony Li’s statement:  “…the IETF is at its best when it
> is documenting de facto standards”
>
>
>
> 1) I fully believe that our customers understand their requirements(sic)
> better than we (vendors) do. But that does not mean that they understand
> what is the best solution better than we do.
>
> When a customer comes to me and says “Can you do this?” my first response
> is usually “Please fully describe your requirements independent of the
> solution.”
>
>
>
>
>
> If it matters at all, Area Proxy is the result of a customer explaining
> his issues and my attempt to address them.  I’m sorry you don’t like my
> proposal.
>
>
>
>
>
> 2)Not clear to me that there is an existing “de facto standard” here –
> which is reinforced by the fact that we have so many different solutions
> proposed.
>
>
>
>
>
> There isn’t. Yet. Thus, it’s not time to pick one vs. the other.
>
>
>
> Tony
>
>
>
>
> ___
> 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 Last Call fo "IS-IS Flood Reflection" -draft-ietf-lsr-isis-flood-reflection-05

[Tony Przygienda]

On Tue, Dec 7, 2021 at 11:53 PM Tony Li  wrote:

>
> Les,
>


Les,


> And in response to Tony Li’s statement:  “…the IETF is at its best when it
> is documenting de facto standards”
>
> 1) I fully believe that our customers understand their requirements(sic)
> better than we (vendors) do. But that does not mean that they understand
> what is the best solution better than we do.
> When a customer comes to me and says “Can you do this?” my first response
> is usually “Please fully describe your requirements independent of the
> solution.”
>
>
>
> If it matters at all, Area Proxy is the result of a customer explaining
> his issues and my attempt to address them.  I’m sorry you don’t like my
> proposal.
>
>

which funny enough is precisely what happened in case of flood reflection
as well ;-) Given that customers are different, their networks tend to be
different, timelines, deployed sets of technologies and ultimately scar
tissue and resulting preferences for better or for worse are different, you
end up sometimes with different solutions based on different equirements
for "roughly" similar problem if want to ship the stuff, run it and move
the world on in a teimely and cost-effective manner.

As Acee said, not the time now to think whether IGP should address this
problem space (that was draft acceptance timeframe), now the question is
how to make sure all possible technical holes are closed & best possible
drafts with an eye on future extensibility and an eye on making sure we
have something backwards compatible is asked for I'd say ...

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

Re: [Lsr] WG Last Call fo "IS-IS Flood Reflection" -draft-ietf-lsr-isis-flood-reflection-05

[Tony Przygienda]

One thing Les is missing here is that proxy & reflection present in terms
of deployment requirements and ultimate properties very different
engineering & operational trade-offs. Different customers follow different
philosophies here IME

So we are not strictly standardizing here 2 solutions for the same thing,
we are standardizing two solutions that meet very different deployment and
operational requirements albeit from 20K feet view all that stuff looks the
same of course as any other thing does ...

-- tony

On Tue, Dec 7, 2021 at 7:17 PM Les Ginsberg (ginsberg)  wrote:

> When I look at this request, I see it in a larger context.
>
>
>
> There are two drafts which attempt to address the same problem in very
> different ways:
>
>
>
> https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-flood-reflection/
>
>
>
> and
>
>
>
> https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-area-proxy/
>
>
>
> Both of them discuss in their respective introductions the motivation –
> which is to address scaling issues in deployment scenarios where the
> existing IS-IS hierarchy is being asked to “stand on its head” i.e.,
> interconnection between different L1 areas is not to be achieved by
> utilizing an L2 backbone – rather it is the L1 areas themselves which are
> required to be used for interconnection of sites (e.g., two datacenters)
> and the scaling properties of the existing protocol hierarchy when used in
> this way are not attractive.
>
>
>
> I find no technical basis on which to choose between the two proposed
> solutions – so in my mind a last call for “Flood-Reflection” presupposes a
> last call for “Area Proxy” – and therein lies my angst.
>
> The end result will be that multiple incompatible solutions to the same
> problem will be defined. It will then be left to customers to try to
> determine which of the solutions seems best to them – which in turn will
> put the onus on vendors to support both solutions (depending on the set of
> customers each vendor supports).
>
> This – to me – represents an utter failure of the standards process. We
> are reduced to a set of constituencies which never find common ground – the
> end result being sub-optimal for the industry as a whole.
>
>
>
> It seems to me that the proper role of the WG is to address the big
> questions first:
>
>
>
> 1)Is this a problem which needs to be solved by link-state protocols?
>
> We certainly have folks who are clever enough to define solutions – the
> two drafts are a proof of that.
>
> But whether this is a wise use of the IGPs I think has never been fully
> discussed/answered.
>
> Relevant to this point is past experience with virtual links in OSPF – use
> of which was problematic and which has largely fallen out of use.
>
> Also, many datacenters use BGP (w or w/o IGP) and therefore have other
> ways to address such issues.
>
> Although I am familiar with the “one protocol is simpler” argument,
> whether that justifies altering the IGPs in any of the proposed ways is
> still an important question to discuss.
>
>
>
> 2)If link state protocols do need to solve this problem, what is the
> preferred way to do that?
>
> This requires meaningful dialogue and a willingness to engage on complex
> technical issues.
>
>
>
> The alternative is to do what we seem to be doing – allowing multiple
> solutions to move forward largely without comment. In which case I see no
> basis on which to object – anyone who can demonstrate a deployment case
> should then be allowed to move a draft forward – and there are then no
> standardized solutions.
>
> (The Experimental Track status for these drafts reflects that reality.)
>
>
>
>Les
>
>
>
> P.S.  (Aside: There is a third draft offering a solution in this space
> https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-ttz/  - but as that
> draft continues to promote its primary usage as a means of more easily
> changing area boundaries (merging/splitting) I have not discussed it here.
> However, if the authors of that draft claim it as a solution to the same
> problem space claimed by Area Proxy/Flood Reflection then the WG would have
> no basis but to also progress it – which would result in three solutions
> being advanced.)
>
>
>
>
>
>
>
> *From:* Lsr  *On Behalf Of *Acee Lindem (acee)
> *Sent:* Monday, November 22, 2021 11:47 AM
> *To:* lsr@ietf.org
> *Subject:* [Lsr] WG Last Call fo "IS-IS Flood Reflection"
> -draft-ietf-lsr-isis-flood-reflection-05
>
>
>
> This begins the WG Last for draft-ietf-lsr-isis-flood-reflection-05.
> Please post your support or objection to this list by 12:00 AM UTC on Dec 14th
> , 2021. Also please post your comments on the draft. I’m allowing as extra
> week as I like to get some additional reviews – although my comments have
> been addressed.
>
>
>
> Thanks,
> Acee
>
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
___
Lsr mailing list

Re: [Lsr] WG Last Call for "IS-IS Flood Reflection" -draft-ietf-lsr-isis-flood-reflection-06

[Tony Przygienda]

On Tue, Dec 7, 2021 at 7:24 AM Shraddha Hegde  wrote:

> This is a very useful feature for large L2 networks and I support the
> publication of this
>
> document.
>
>
>
>
>
> I have below nits/suggestions on the document.
>
>
>
>
>
> 1. Figure 1: Example Topology of L1 with L2 Borders
>
> The diagram is not legible. The connections between L1 routers
>
> can be removed from the diagram and a description can be added that
>
> R1 layer routers are all connected to R2 layer and so on.
>
> From the diagram it appears that there is connectivity between R10 and R11
>
> and R11 and R12. If so that link can flood L2 domains and L2 is not
>
> fully disjoint. I would suggest to remove the R10->R11 link to show a pure
> clos topology
>
> in L1.
>

1. well, it's ASII. I'll redraw for the thing to look maybe more
straightforward thought it may lead
more folks astray to think it's a CLOS.

The link R10-R11 is there on purpose, this is NOT a CLOS and flood
reflection is not restricted by any
topology constraints. I drew it CLOS like since that's what lots people
do/start to do, thinking about
it I probasbly change the picture for the thing to be much less CLOS like
;-)

10-11 and 11-12 are there on purpose to show L2 leaf shortcuts.



>
>
> 2.
>
> 4.1 Flood reflection TLV
>
> "On a given router, the same value
>
>   of the Flood Reflection Cluster ID MUST be advertised across all
>
>   interfaces advertising the Flood Reflection TLV in IIHs. "
>
>
>
> Do we really need this restriction of one single cluster-id on a router?
>

For operational simplicity very much so. For future possible things, maybe
not but introducing
multiple cluster IDs in same area and possibly same cluster ID in different
areas leads to all
kind of corner cases & configuration complications because cluster ID
becomes de facto
a property of an interface (or have to carry a set of possible Cluster IDs
and that leads to
"negotiation" scenarios with additional complications in case of dynamic
tunnel establishment).
We don't have in ISIS areas "per interface" for the same reason
as we should not have a cluster ID per interface. Yes, some vendors support
"multiple"
areas per router but we know it's used only for merge/split and is a whole
dance to get it right
during transitions.

Having said that, if enough people feel that way we _should_ move the MUST
to a SHOULD
I think it's livable and then let's hope some clever vendors can try to
support multiple cluster IDs if they find an operationally
acceptable way.


> I am imagining, this cluster-id mechanism can be used to segregate a
> single fabric
>
> into two or more clusters if the fabric size becomes too huge.
>
> The usecase itself is described out of scope for this document elsewhere
>
> which is fine but too restrictive statements like above would discourage
> further
>
> enhancements so may be worth considering these restrictions to be removed.
>

as said above, I'm ok with a SHOULD but generally all the procedures
described & formats
stay at a single cluster ID.


>
>
> 3.
>
> 4.2.  Flood Reflection Discovery Sub-TLV
>
> " A router receiving multiple Flood Reflection
>
>Discovery sub-TLVs in TLV 242 MUST use the values in the first sub-
>
>TLV"
>
>
>
>first sub-TLV is not deterministic as multiple TLV 242 can come is
> different fragments.
>
>Suggest to change as below.
>
>" A router receiving multiple Flood Reflection
>
>Discovery sub-TLVs in TLV 242 MUST use the values in the first sub-
>
>TLV of the lowest numbered fragment"
>

ok, thanks. good one.


>
>
>4.
>
>"flood reflection tunnel endpoint" and "L1 shortcut"
>
>terminology should be added to the glossary. These terms are used in
> sec 4.3
>
>and reader may not get the context of these terms.
>

ok, will add. thanks for comment.


>
>
>
>
>
>
>5. section 4.3
>
>
>
>do we need the F bit? Looks like this info can be derived from the
>
>C bit in Flood Reflection Discovery Sub-TLV. The ones with C bit set
> are possible shortcut endpoints.
>
>The ones with C bit cleared are the flood reflector tunnel endpoints.
>

nope, we can't since clients may have different endpoints for the FR tunnel
& for the shortcut tunnels so
whoever originates the tunnel has to be sure they shortcut to the correct
endpoint.


>
>
>
>
>6. The tunnel encapsulation attribute has use outside of flood reflector
>
>(such as RFC 8663). I am more in favor of getting rid of the F bit from
> this sub-TLV
>
>as to avoid the confusions that may arise when it is used in the
> absence of flood reflectors.
>

as per 5. the bit is needed.


>
>
>7.
>
>" A flood reflector receiving multiple Flood Reflection Discovery
>
>Tunnel Type sub-sub-TLVs in Flood Reflection Discovery sub-TLV with F
>
>flag set SHOULD use one or more of the specified tunnel endpoints to
>
>automatically establish one or more tunnels that will serve as flood
>
>reflection adjacency(-ies)."
>
>
>
>A flood 

Re: [Lsr] WG Last Call fo "IS-IS Flood Reflection" -draft-ietf-lsr-isis-flood-reflection-05

[Tony Przygienda]

On Mon, Dec 6, 2021 at 4:42 PM Aijun Wang  wrote:

> Do not support its publication.
>
> Very curious  which operator will have such network design that the L1
> routers locate in the middle but the L2 routers sits around them.
>

Do read the draft carefully to understand that this is an evolution of a L2
network (which large amount of providers world-wide run since 20+ years by
now) and not description of current deployment. This technology is being
deployed by large operators currently who face the challenge of ISIS L2 not
scaling to the numbers they seek based on several drivers.

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

Re: [Lsr] BGP vs PUA/PULSE

[Tony Przygienda]

On Thu, Dec 2, 2021 at 2:03 PM Peter Psenak  wrote:

> Tony,
>
> On 02/12/2021 11:49, Tony Przygienda wrote:
> > Idly thinking about the stuff more and more issues pop up that confirm
> > my initial gut feeling that the pulse stuff is simply not what IGP can
> > do reasonably (i.e. liveliness). negative as liveliness indication is
> > arguably even worse ;-) but I think most of us agreed on that across
> > those hundreds of emails by now.
> >
> > So, to expound a bit. IGP reachability which IGP does normally is _very_
> > different from liveliness and here's another example (I describe it in
> > principle but people who deployed stuff will know what scenarios I'm
> > talking about)
> >
> > So, in short, the fact that an IGP, let's say ABR, advertises a summary
> > has _nothing_ to do much with liveliness of what it summarizes in system
> > wide sense. In more specifics, even when this aggregate goes away or IGP
> > cannot compute _reachability_ to a specific address/node does NOT mean
> > that the prefix advertised by such node is not _alive_.
> >
> > Imagine (often done in fact in deployments I dealt with) that the prefix
> > advertised by a node into IGP is not _reachable_ by IGP all of a sudden,
> > simplest case being a link loss of course. However, it is in the system
> > still reachable by means e.g. of a default route from another protocol
> > or a specific route (static?) over a link IGP is not running on. Now, if
> > IGP starts to pulse it will defeat the very purpose of such backup.
>
> no less specific route will ever make something that went down
> reachable.


we disagree based on my experience whereas the "went down" is only
"IGP does not see it anymore" in the draft definition here unless we want
to start to write in LSR draft that encompass multi-protocol router
requirements and
system design.


> The purpose of the pulse is not to defeat the purpose of the
> default, or less specific route. The purpose of the pulse is to notify
> interested clients that the reachability of some less specific route
> (typically a host route) that is covered by the summary in its source
> area is lost.
>
> If a unique host route that was reachable in its source area became
> unreachable because its originator became unreachable, we know for sure
> that the host route is gone no matter what less specific routes may
> cover it.
>

so if we intend to inform the service source that "IGP thinks it cannot
reach an address anymore through
an ABR (because other ABRs may still reach it [solving that preconditions
AFAIS re-invention of add-path in IGP on leaking and/or lots interesting
paxos-direction protocol work] but maybe other protocols/aggregates can
still reach it)"
so the source as you say "may do something" then it slowly deems to me
that we are not standardizing anything but some "rough hunch of a rumour"
I would never advise a customer to act upon given how very expensive
a false positive on service is including e.g. BGP re-sync or tunnel
tear-downs.


>
>
> >
> > And no, you cannot "know" whether backup is here, there are even funky
> > cases where a policy only installs a backup route if the primary went
> > away which may be fast enough to keep e.g. TCP up (whether it's the best
> > possible architecture is disputable but it's a fact of live that such
> > stuff exists).
> >
> > So, basically we try to invent "liveliness indication" in IGP whereas
> > IGP cannot be aware whether the prefix is reachable system-wide through
> > it even when IGP lost _reachability_.
>
> we can limit the pulse notification to host prefixes. That should
> address your concern.
>

I would prefer not to add hidden /32 semantics to protocol features since
the more things become "special" and "asymmetric" the harder it's to
explain how things work & why they don't work when deployed as expected.

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

Re: [Lsr] BGP vs PUA/PULSE

[Tony Przygienda]

Idly thinking about the stuff more and more issues pop up that confirm my
initial gut feeling that the pulse stuff is simply not what IGP can do
reasonably (i.e. liveliness). negative as liveliness indication is arguably
even worse ;-) but I think most of us agreed on that across those hundreds
of emails by now.

So, to expound a bit. IGP reachability which IGP does normally is _very_
different from liveliness and here's another example (I describe it in
principle but people who deployed stuff will know what scenarios I'm
talking about)

So, in short, the fact that an IGP, let's say ABR, advertises a summary has
_nothing_ to do much with liveliness of what it summarizes in system wide
sense. In more specifics, even when this aggregate goes away or IGP cannot
compute _reachability_ to a specific address/node does NOT mean that the
prefix advertised by such node is not _alive_.

Imagine (often done in fact in deployments I dealt with) that the prefix
advertised by a node into IGP is not _reachable_ by IGP all of a sudden,
simplest case being a link loss of course. However, it is in the system
still reachable by means e.g. of a default route from another protocol or a
specific route (static?) over a link IGP is not running on. Now, if IGP
starts to pulse it will defeat the very purpose of such backup.

And no, you cannot "know" whether backup is here, there are even funky
cases where a policy only installs a backup route if the primary went away
which may be fast enough to keep e.g. TCP up (whether it's the best
possible architecture is disputable but it's a fact of live that such stuff
exists).

So, basically we try to invent "liveliness indication" in IGP whereas IGP
cannot be aware whether the prefix is reachable system-wide through it even
when IGP lost _reachability_.

And yes, before we go there, I know that with enough "limited domain" and
"limited scale" and "limited use case" arguments anything one can imagine
"works" ...

--- tony

On Wed, Dec 1, 2021 at 8:13 PM Les Ginsberg (ginsberg) 
wrote:

> Tony –
>
>
>
> Inline.
>
>
>
> *From:* Tony Przygienda 
> *Sent:* Wednesday, December 1, 2021 9:33 AM
> *To:* Les Ginsberg (ginsberg) 
> *Cc:* Peter Psenak (ppsenak) ; Hannes Gredler <
> han...@gredler.at>; lsr ; Tony Li ; Aijun
> Wang ; Robert Raszuk ;
> Shraddha Hegde 
> *Subject:* Re: [Lsr] BGP vs PUA/PULSE
>
>
>
> "
>
> Nodes which originate FSP-LSPs MUST
>
>remember the last sequence number used for a given FSP-LSP and
>
>increment the sequence number when generating a new version.
>
>
>
>FSP-LSP generation SHOULD utilize the "next" FSP-LSP ID each time new
>
>pulse information needs to be advertised i.e., if the most recent
>
>FSP-LSP ID used was A-00.n, the next set of pulse information SHOULD
>
>be advertised using FSP-LSP.ID A-00.n+1.  This minimizes the
>
>possibility of confusion if other routers in the network have not yet
>
>removed A-00.n from their LSPDB.
> "
>
> So you tell me I onver-interpreted as "between restarts" ;-) OK, fine. Fair 
> 'nuff. Maybe add one sentence clarification.
>
> *[LES:] Sure.*
>
> Otherwise yeah, I'd like the draft to add the "in case of partition things 
> may break but it's not much worse than before" ;-) and "assumption is that 
> the overlay will retry after dropping session on negative so no positives are 
> needed" and I'm ok with this thread.
>
> *[LES:] I think significantly more needs to be said about the current use 
> case for event notification – and this point can be part of that. Look for 
> that in the next revision of the draft.*
>
> my big gripe about "don't do it in main ISIS, take service instance" remains 
> though due to scalability concerns that bunch of senior folks here raised 
> already
>
> *[LES:] I am not in favor of a separate instance in this case. Reason being 
> all of the information required to determine when to send pulses is already 
> known by the main instance. Moving the pulse advertisements themselves to a 
> separate instance would likely be more costly in resources on the routers 
> themselves than advertising them in the main instance. Scale considerations 
> need to be addressed – as has been stated in this and earlier threads many 
> times – and that would be true regardless of whether we used the main 
> instance or a separate instance. *
>
> *There is also the point made by Greg Mirsky early on in this discussion – 
> that the use of event-notification needs to be carefully limited to cases 
> that make sense for the main routing instance. The next revision of the draft 
> will also address this point.*
>
> *Les*
>
> -- tony
>
>

Re: [Lsr] BGP vs PUA/PULSE

[Tony Przygienda]

"

Nodes which originate FSP-LSPs MUST
   remember the last sequence number used for a given FSP-LSP and
   increment the sequence number when generating a new version.

   FSP-LSP generation SHOULD utilize the "next" FSP-LSP ID each time new
   pulse information needs to be advertised i.e., if the most recent
   FSP-LSP ID used was A-00.n, the next set of pulse information SHOULD
   be advertised using FSP-LSP.ID A-00.n+1.  This minimizes the
   possibility of confusion if other routers in the network have not yet
   removed A-00.n from their LSPDB.
"

So you tell me I onver-interpreted as "between restarts" ;-) OK, fine.
Fair 'nuff. Maybe add one sentence clarification.

Otherwise yeah, I'd like the draft to add the "in case of partition
things may break but it's not much worse than before" ;-) and
"assumption is that the overlay will retry after dropping session on
negative so no positives are needed" and I'm ok with this thread.

my big gripe about "don't do it in main ISIS, take service instance"
remains though due to scalability concerns that bunch of senior folks
here raised already

-- tony


On Wed, Dec 1, 2021 at 5:52 PM Les Ginsberg (ginsberg) 
wrote:

> Tony –
>
>
>
>
>
> *From:* Tony Przygienda 
> *Sent:* Wednesday, December 1, 2021 7:58 AM
> *To:* Peter Psenak (ppsenak) 
> *Cc:* Les Ginsberg (ginsberg) ; Hannes Gredler <
> han...@gredler.at>; lsr ; Tony Li ; Aijun
> Wang ; Robert Raszuk ;
> Shraddha Hegde 
> *Subject:* Re: [Lsr] BGP vs PUA/PULSE
>
>
>
> 1. my question is different. why does the draft say that seqnr# & IDs have
> to be preserved between restarts
>
>
>
>
>
> *[LES:] Section 4.3.1 of the draft tries to answer your question – but
> there is no mention of “restart” there.*
>
> *There is in fact no mention of restart anywhere in the draft other than
> to say pulses are not preserved across restarts.*
>
>
>
> *WE only retain the sequence #’s to make it easier to identify a new Pulse
> LSP from a retransmission.*
>
>
>
>
>
> 2. I'm still concerned about L1/L2 hierarchy. If an L2 border sees same
> prefix negative pulses from two different L1/L2s  it still has to keep
> state to only pulse into L1 after _all_ the guys pulsed negative (which is
> basically impossible since the _negative_ cannot persist it seems). Now how
> will it even know that? it has to keep track who advertised the same
> summary & who pulsed or otherwise it will pulse on anyone with a summary
> giving a pulse and with that anycast won't work AFAIS and worse you get
> into weird situations where you have 2 L1/L2 into same L1 area, one lost
> link to reach the PE (arguably L1 got partitioned) and pulses & then the
> L1/L2 on the border of the down L1 pulses and tears the session down albeit
> the prefix is perfectly reachable through the other L1/L2. I assume that
> parses for the connoscenti ...
>
>
>
> *[LES:] We are not trying to handle the area partition case.*
>
> *In such a case, even if nothing is done, traffic will flow via both ABRs
> and half of it will be dropped – so one could argue that switching BGP
> traffic to the backup path is still a good idea.*
>
>
>
> *   Les*
>
>
>
> -=--- tony
>
>
>
> On Wed, Dec 1, 2021 at 4:00 PM Peter Psenak  wrote:
>
> Tony,
>
> On 01/12/2021 15:31, Tony Przygienda wrote:
>
> >
> > Or maybe I missed something in the draft or between the lines in the
> > whole thing ... Do we assume the negative just quickly tears down the
> > BGP session & then it loses any relevance and we rely on BGP to retry
> > after reset automatically or something?
>
> yes.
>
>
> But then why do we even care about retaining the LSP IDs & SeqNr# would
> I ask?
>
> it's used for the purpose of flooding, so that during the flooding you
> do not flood the same pulse LSP multiple times.
>
> thanks,
> Peter
>
>
> >
> > -- tony
> >
> >
> >
> >
> >
> > On Tue, Nov 30, 2021 at 11:19 PM Les Ginsberg (ginsberg)
> >  > <mailto:40cisco@dmarc.ietf.org>> wrote:
> >
> > Hannes -
> >
> > Please see
> >
> https://datatracker.ietf.org/doc/html/draft-ppsenak-lsr-igp-event-notification-00#section-4.1
> >
> > The new Pulse LSPs don't have remaining lifetime - quite
> intentionally.
> > They are only retained long enough to support flooding.
> >
> > But, you remind me that we need to specify how the checksum is
> > calculated. Will do that in the next revision.
> >
> > Thanx.
> >
> >  Les
> >
> >  > -Original Mess

Re: [Lsr] BGP vs PUA/PULSE

[Tony Przygienda]

1. my question is different. why does the draft say that seqnr# & IDs have
to be preserved between restarts

2. I'm still concerned about L1/L2 hierarchy. If an L2 border sees same
prefix negative pulses from two different L1/L2s  it still has to keep
state to only pulse into L1 after _all_ the guys pulsed negative (which is
basically impossible since the _negative_ cannot persist it seems). Now how
will it even know that? it has to keep track who advertised the same
summary & who pulsed or otherwise it will pulse on anyone with a summary
giving a pulse and with that anycast won't work AFAIS and worse you get
into weird situations where you have 2 L1/L2 into same L1 area, one lost
link to reach the PE (arguably L1 got partitioned) and pulses & then the
L1/L2 on the border of the down L1 pulses and tears the session down albeit
the prefix is perfectly reachable through the other L1/L2. I assume that
parses for the connoscenti ...

-=--- tony

On Wed, Dec 1, 2021 at 4:00 PM Peter Psenak  wrote:

> Tony,
>
> On 01/12/2021 15:31, Tony Przygienda wrote:
>
> >
> > Or maybe I missed something in the draft or between the lines in the
> > whole thing ... Do we assume the negative just quickly tears down the
> > BGP session & then it loses any relevance and we rely on BGP to retry
> > after reset automatically or something?
>
> yes.
>
>
> But then why do we even care about retaining the LSP IDs & SeqNr# would
> I ask?
>
> it's used for the purpose of flooding, so that during the flooding you
> do not flood the same pulse LSP multiple times.
>
> thanks,
> Peter
>
>
> >
> > -- tony
> >
> >
> >
> >
> >
> > On Tue, Nov 30, 2021 at 11:19 PM Les Ginsberg (ginsberg)
> >  > <mailto:40cisco@dmarc.ietf.org>> wrote:
> >
> > Hannes -
> >
> > Please see
> >
> https://datatracker.ietf.org/doc/html/draft-ppsenak-lsr-igp-event-notification-00#section-4.1
> >
> > The new Pulse LSPs don't have remaining lifetime - quite
> intentionally.
> > They are only retained long enough to support flooding.
> >
> > But, you remind me that we need to specify how the checksum is
> > calculated. Will do that in the next revision.
> >
> > Thanx.
> >
> >  Les
> >
> >  > -Original Message-
> >  > From: Hannes Gredler mailto:han...@gredler.at
> >>
> >  > Sent: Tuesday, November 30, 2021 11:22 AM
> >  > To: Peter Psenak (ppsenak)  > <mailto:ppse...@cisco.com>>
> >  > Cc: Robert Raszuk mailto:rob...@raszuk.net>>;
> > Les Ginsberg (ginsberg)
> >  > mailto:ginsb...@cisco.com>>; Aijun Wang
> > mailto:wangai...@tsinghua.org.cn>>; lsr
> >  > mailto:lsr@ietf.org>>; Tony Li  > <mailto:tony...@tony.li>>; Shraddha Hegde
> >  > mailto:shrad...@juniper.net>>
> >  > Subject: Re: [Lsr] BGP vs PUA/PULSE
> >  >
> >  > hi peter,
> >  >
> >  > Just curious: Do you have an idea how to make short-lived LSPs
> > compatible
> >  > with the problem stated in
> >  > https://datatracker.ietf.org/doc/html/rfc7987
> >  >
> >  > Would like to hear your thoughts on that.
> >  >
> >  > thanks,
> >  >
> >  > /hannes
> >  >
> >  > On Tue, Nov 30, 2021 at 01:15:04PM +0100, Peter Psenak wrote:
> >  > | Hi Robert,
> >  > |
> >  > | On 30/11/2021 12:40, Robert Raszuk wrote:
> >  > | > Hey Peter,
> >  > | >
> >  > | >  > #1 - I am not ok with the ephemeral nature of the
> > advertisements. (I
> >  > | >  > proposed an alternative).
> >  > | >
> >  > | > LSPs have their age today. One can generate LSP with the
> > lifetime of 1
> >  > | > min. Protocol already allows that.
> >  > | >
> >  > | >
> >  > | > That's a pretty clever comparison indeed. I had a feeling it
> > will come
> >  > | > up here and here you go :)
> >  > | >
> >  > | > But I am afraid this is not comparing apple to apples.
> >  > | >
> >  > | > In LSPs or LSA flooding you have a bunch of mechanisms to
> > make sure the
> >  > | > information stays fresh
> >  > | > and does not time out. And the default refresh in ISIS if I
> > recall was

Re: [Lsr] BGP vs PUA/PULSE

[Tony Przygienda]

ok, but then I'm confused about all those requirements about retainting IDs
& SeqNr# and so on ... they are pretty meaningless unless you want to pulse
within 60 secs negative again (why would you?)

and it brings up the issue of having anycast for e.g. load-balancing or
reliability and one pulse basically tearing the session for another
destination.

--- tony

On Wed, Dec 1, 2021 at 3:42 PM Robert Raszuk  wrote:

> Hi Tony,
>
> > Do we assume the negative just quickly tears down the BGP session & then
> it loses any relevance
> > and we rely on BGP to retry after reset automatically or something?
>
> That is my understanding that PULSE is one time send and forget. The
> entire operation relies on upper layers for it to be operationally
> meaningful.
>
> It kind of works if there are upper layers (BGP or p2p tunnel) It does not
> work where there is just p2mp tunnel with no upper layer.
>
> But your note brings an important question which was not discussed - what
> if the summary is conditional based on the presence of specific host routes
> and those host routes went down. I guess the draft should mandate that the
> summary must be just static to null int.
>
> Thx,
> R.
>
> On Wed, Dec 1, 2021 at 3:32 PM Tony Przygienda 
> wrote:
>
>> having thought through that a bit more I think it's a significantly worse
>> idea than I actually thought. You are requesting a node to basically save a
>> possibly very large amount of state between reboots in transitive fashion
>> for this to even have a chance to work half-way reliably (assuming
>> signalling "down" means "it went down and stays down" which surely has to
>> include "positive pulses" as well BTW AFAIS?)
>>
>> Imagine following scenario:
>>
>> router L1 A summarizes 10.1/16 and realizes a 10.1.1.1 behind it went
>> down (the reason may not be in ISIS, e.g. redistributed 10.1.1.1 was one of
>> the triggers for 10.1/16 and now is not redistributed anymore). it pulses
>> negative and has to retain
>>
>> * A pulsed negative under a 10.1/16 for 10.1.1.1 (and what was the
>> "origiin" of 10.1.1.1 that was lost to pulse it)
>> * A pulsed in some ID @ some seqnr# and possibly more stuff
>>
>> it hits on the border a L1/L2 router B sumarizing 10/8 which now
>> re'pulses into L2 (or leaks it up, it's same thing, you have to keep state
>> since the LSP will "expire" within short period)
>>
>> * keep seqnr# of the "re"-pulsed negative, which pulse from whom
>> triggered it (there may be multiple folks etc)
>> * keep ID of the "re"-pulsed negative
>>
>> I don't think you get away from doing that since A is not visible in L2
>> and if there is a A' with 10.1.1.1/32 in the same L1 B MUST suppress A's
>> pulse otherwise the other end of network cannot tell whether "all" o9r just
>> "some" of 10.1.1.1 in the area went away.
>>
>> So in a sense the state in B will be "stuck" if A reboots (unless you
>> start to generate lots of rules about re-computing reachability to A and
>> based on that remove that state to make sure the L2 "re"-pulse is
>> withdrawn. or should it? A link failure here can cause quickly a good
>> amount of "positive pulse" storms for all the negative pulse state kept @
>> the border. A going away is kind of confirmation that the negative is still
>> negative or does it invalidate the pulse of A. If it doesn't and A goes
>> down the negative is stuck forever and B will repulse it after reboot? is
>> here a transitive algebra of some kind?)
>>
>> Some goes for a C @ another L2/L1 border trying to "leak it down" of
>> course
>>
>> now comes a more interesting part.
>>
>> A is shut down, its configuration changed to not include 10.1/16 anymore
>> (but possibly something subsuming/supersuming). On reboot one has to build
>> a whole logic computing all the retained negative so they can be pulsed
>> "positive" to remove the state from B (unless B pulese positive the moment
>> A goes away which kinds of seems to defaeat the purpose of the whole
>> negative and is opposite to what one does if A advertises 10.1.1.1/32
>> directly which going away kind of should pulse it negative from B)
>>
>> And I won't even ask what happens if A reboots with a different router
>> ID. Well, maybe? do you start to pulse with old router-ID since otherwise B
>> will not remove the retained state? That seems like a prescription for
>> spectacular meltdowns a la proxy purging that had to be removed.
>>

Re: [Lsr] BGP vs PUA/PULSE

[Tony Przygienda]

having thought through that a bit more I think it's a significantly worse
idea than I actually thought. You are requesting a node to basically save a
possibly very large amount of state between reboots in transitive fashion
for this to even have a chance to work half-way reliably (assuming
signalling "down" means "it went down and stays down" which surely has to
include "positive pulses" as well BTW AFAIS?)

Imagine following scenario:

router L1 A summarizes 10.1/16 and realizes a 10.1.1.1 behind it went down
(the reason may not be in ISIS, e.g. redistributed 10.1.1.1 was one of the
triggers for 10.1/16 and now is not redistributed anymore). it pulses
negative and has to retain

* A pulsed negative under a 10.1/16 for 10.1.1.1 (and what was the
"origiin" of 10.1.1.1 that was lost to pulse it)
* A pulsed in some ID @ some seqnr# and possibly more stuff

it hits on the border a L1/L2 router B sumarizing 10/8 which now re'pulses
into L2 (or leaks it up, it's same thing, you have to keep state since the
LSP will "expire" within short period)

* keep seqnr# of the "re"-pulsed negative, which pulse from whom triggered
it (there may be multiple folks etc)
* keep ID of the "re"-pulsed negative

I don't think you get away from doing that since A is not visible in L2 and
if there is a A' with 10.1.1.1/32 in the same L1 B MUST suppress A's pulse
otherwise the other end of network cannot tell whether "all" o9r just
"some" of 10.1.1.1 in the area went away.

So in a sense the state in B will be "stuck" if A reboots (unless you start
to generate lots of rules about re-computing reachability to A and based on
that remove that state to make sure the L2 "re"-pulse is withdrawn. or
should it? A link failure here can cause quickly a good amount of "positive
pulse" storms for all the negative pulse state kept @ the border. A going
away is kind of confirmation that the negative is still negative or does it
invalidate the pulse of A. If it doesn't and A goes down the negative is
stuck forever and B will repulse it after reboot? is here a transitive
algebra of some kind?)

Some goes for a C @ another L2/L1 border trying to "leak it down" of course

now comes a more interesting part.

A is shut down, its configuration changed to not include 10.1/16 anymore
(but possibly something subsuming/supersuming). On reboot one has to build
a whole logic computing all the retained negative so they can be pulsed
"positive" to remove the state from B (unless B pulese positive the moment
A goes away which kinds of seems to defaeat the purpose of the whole
negative and is opposite to what one does if A advertises 10.1.1.1/32
directly which going away kind of should pulse it negative from B)

And I won't even ask what happens if A reboots with a different router ID.
Well, maybe? do you start to pulse with old router-ID since otherwise B
will not remove the retained state? That seems like a prescription for
spectacular meltdowns a la proxy purging that had to be removed.

Just bunch thoughts to improve the draft @ best but most likely showing
futility of that approach IMO to construct a clean algebra/architecture of
that stuff under summarization on a global leak-up-down-scope.

Or maybe I missed something in the draft or between the lines in the whole
thing ... Do we assume the negative just quickly tears down the BGP session
& then it loses any relevance and we rely on BGP to retry after reset
automatically or something? But then why do we even care about retaining
the LSP IDs & SeqNr# would I ask?

-- tony





On Tue, Nov 30, 2021 at 11:19 PM Les Ginsberg (ginsberg)  wrote:

> Hannes -
>
> Please see
> https://datatracker.ietf.org/doc/html/draft-ppsenak-lsr-igp-event-notification-00#section-4.1
>
> The new Pulse LSPs don't have remaining lifetime - quite intentionally.
> They are only retained long enough to support flooding.
>
> But, you remind me that we need to specify how the checksum is calculated.
> Will do that in the next revision.
>
> Thanx.
>
> Les
>
> > -Original Message-
> > From: Hannes Gredler 
> > Sent: Tuesday, November 30, 2021 11:22 AM
> > To: Peter Psenak (ppsenak) 
> > Cc: Robert Raszuk ; Les Ginsberg (ginsberg)
> > ; Aijun Wang ; lsr
> > ; Tony Li ; Shraddha Hegde
> > 
> > Subject: Re: [Lsr] BGP vs PUA/PULSE
> >
> > hi peter,
> >
> > Just curious: Do you have an idea how to make short-lived LSPs compatible
> > with the problem stated in
> > https://datatracker.ietf.org/doc/html/rfc7987
> >
> > Would like to hear your thoughts on that.
> >
> > thanks,
> >
> > /hannes
> >
> > On Tue, Nov 30, 2021 at 01:15:04PM +0100, Peter Psenak wrote:
> > | Hi Robert,
> > |
> > | On 30/11/2021 12:40, Robert Raszuk wrote:
> > | > Hey Peter,
> > | >
> > | >  > #1 - I am not ok with the ephemeral nature of the
> advertisements. (I
> > | >  > proposed an alternative).
> > | >
> > | > LSPs have their age today. One can generate LSP with the
> lifetime of 1
> > | > min. Protocol already allows that.
> > | >
> > | >

Re: [Lsr] WG Last Call fo "IS-IS Flood Reflection" -draft-ietf-lsr-isis-flood-reflection-05

[Tony Przygienda]

+1 as co-author

On Tue, Nov 23, 2021 at 5:42 PM Acee Lindem (acee)  wrote:

> Speaking as a WG member:
>
>
>
> I support publication of this experimental extension to IS-IS.
>
> Thanks,
>
> Acee
>
>
>
> *From: *Lsr  on behalf of "Acee Lindem (acee)"
> 
> *Date: *Monday, November 22, 2021 at 2:48 PM
> *To: *"lsr@ietf.org" 
> *Subject: *[Lsr] WG Last Call fo "IS-IS Flood Reflection"
> -draft-ietf-lsr-isis-flood-reflection-05
>
>
>
> This begins the WG Last for draft-ietf-lsr-isis-flood-reflection-05.
> Please post your support or objection to this list by 12:00 AM UTC on Dec 14th
> , 2021. Also please post your comments on the draft. I’m allowing as extra
> week as I like to get some additional reviews – although my comments have
> been addressed.
>
>
>
> Thanks,
> Acee
>
>
> ___
> 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 for "IS-IS Fast Flooding" - draft-decraeneginsberg-lsr-isis-fast-flooding-00

[Tony Przygienda]

Yes, support, experimental. It would be beneficial for the authors taking
IPR here to explain in few words what we're protecting here that is not
covered by TCP & million other congestion things out there already

-- tony

On Tue, Nov 23, 2021 at 4:20 AM Jeff Tantsura 
wrote:

> Acee,
>
> I support the adoption, and would like to thank the authors for the great
> work.
> At this point in time, it feels like experimental track is more suitable.
>
> Cheers,
> Jeff
>
>
>
> On Nov 22, 2021, at 6:06 AM, Acee Lindem (acee) <
> acee=40cisco@dmarc.ietf.org> wrote:
>
> We indicated the intent to adopt of
> draft-decraeneginsberg-lsr-isis-fast-flooding-00 as an LSR WG document at
> the IETF 112 LSR WG meeting.
> We are now confirming WG consensus on this action. Please indicate your
> support or objection on this list by 12:00 AM UTC on December 7th, 2021.
>
> Another question that came to light is whether the document should be
> standards track or experimental. If you have an opinion on this matter,
> please chime in along with your arguments for one track or the other. We
> probably won’t make a final decision on this now but let’s get the
> discussion started.
>
> Here is a link for your convenience:
>
>
> https://datatracker.ietf.org/doc/draft-decraeneginsberg-lsr-isis-fast-flooding/
>
> Thanks,
> Acee
> ___
> 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 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] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Tony Przygienda]

On Tue, Nov 23, 2021 at 9:30 AM Peter Psenak  wrote:

> Hi Chris,
>
> On 22/11/2021 22:29, Christian Hopps wrote:
> >
> > Gyan Mishra  writes:
> >
> >> +1
> >>
> >> As I mentioned the requirements for E2E LSP with seamless MPLS or
> >> SR-MPLS requires domain wide flooding of host routes.
> >>
> >> For large operators with a thousands of routes per area you can image
> >> if you total that all up can equate to hundreds of thousands of host
> >> routes.  That is what we live with today real world scenario.
> >>
> >> Summarization is a tremendous optimization for operators.
> >
> > I'm having a hard time imagining 300,000 or 500,000 PEs that need this
> "liveness as a host route" notification for. Where are these hundreds of
> thousands of hosts coming from that ever need to be in the IGP?
>
> It's more like tens of thousands from what I have seen.
>

I don't know the specific network talked about here by Guayn where he
claims to see 100s of Ks of host routes on a router  either. Though IME
seeing igp RIB is excess of few 10Ks routes (in a single instance/topology)
is quiet exceptional for a lot of practical reasons in real deployments.

As side discussion, I'm getting lost how a SRv6 PE-PE is somehow a
drastically different, novel way of addressing tunnel endpoints. Nothing
prevents you from summarizing (v6) loopback addresses on PEs AFAIS in any
other tunneling technology (that preconditions having an addressing
discipline of course but it seems the same is true for SRv6). I stand
enlightened but AFAIS a tunnel is a tunnel is a tunnel, what we talk about
here is adding something that provides a partial (since it does not verify
the data path needed for the control or transport tunnels) SSAP liveliness
indication to IGP on whatever endpoint (which happens in IP being roughly
:port whereas we imply by a loss of address the loss of all
services which in itself is an assumption which is probably fair enough as
long BGP has all services on the same routing instance, not a given thing
in the future AFAIS ;-) Where I agree with TLi again that it's not
something that should be in IGP scope (or at minimum not shared with the
instance responsible to do the IP reachability computation).

-- tony


>
> thanks,
> Peter
>
> >
> > Large operators may have prefixes for each of their internal links or
> each of their router loopback addresss, so this can lead to 1000s of
> routes; however, it does not imply 100 times that many host routes being
> present at all.
> >
> > Perhaps this is just a hole in my knowledge though.
> >
> > Thanks,
> > Chris.
> >
> >
> >>
> >> With RFC 5283 the issue why it was never deployed is that it fixes
> >> half the problem.  If fixed the IGP for with the LDP inter area
> >> extension can now support LPM IGP match summarization so the RIB/FIB
> >> is optimized, however the LFIB still has to maintain all the host
> >> routes FEC binding RFC 5036.
> >>
> >> With the RFC 5283 solution we still have to track the liveliness of
> >> the egress LSR which states can be done by advertising reachability
> >> via IGP and then you are back to domain wide flooding even in the
> >> IGP.
> >>
> >> Section 7.2
> >>
> >>
> >> - Advertise LER reachability in the IGP for the purpose of the
> >>   control plane in a way that does not create IP FIB entries in the
> >>   forwarding plane.
> >>
> >>
> >>
> >> Here stated the LFIB remains not optimized
> >>
> >>
> >> - The solution documented in this document reduces te link state
> database size in the control plane and the number of FIB
> >> entries in the forwarding plane.  As such, it solves the scaling of
> >>
> >> pure IP routers sharing the IGP with MPLS routers.  However, it does
> >> not decrease the number of LFIB entries so is not sufficient to
> solve
> >> the scaling of MPLS routers.  For this, an additional mechanism is
> >> required (e.g., introducing some MPLS hierarchy in LDP).  This is
> out
> >> of scope for this document.
> >>
> >>
> >> So this is quite unfortunate for RFC 5283 and why it was never deployed
> by operators.
> >>
> >>
> >> SRv6 is an answer but majority of all SPs are not there yet and we
> >> need to be able support MPLS for a long time to come beyond our
> >> lifetime.
> >>
> >> Kind Regards
> >>
> >> Gyan
> >>
> >> On Mon, Nov 22, 2021 at 9:40 AM Peter Psenak 
> >> wrote:
> >>
> >>  Robert,
> >>
> >>  On 22/11/2021 15:26, Robert Raszuk wrote:
> >>  >
> >>  > Peter - the spec does not present full story. Hardly no RFC
> >>  > presents full A--Z on how to run a network or even a
> >>  given feature. It
> >>  > provides mechanism which can still permit for building LDP LSPs
> >>  > without host routes.
> >>  >
> >>  > So anyone claiming it is impossible by architecture of MPLS is
> >>  simply
> >>  > incorrect.
> >>  >
> >>  > As example - some vendors support ordered LDP mode some do not.
> >>  Some
> >>  > support BGP recursion some 

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Tony Przygienda]

Just to prop a voice of support to Tony Li's arguments which I have nothing
further to add really. He basically elucidated ;-) with flourishes what I
wrote in my short, terse email I think.

As he says "you either make easy choices and get an operationally unstable
environment at scale/large disturbances or you make hard architectural
choices & scale much better over time". Examples of that are abound in
systems design but it's unfortunately often RFC1295 (4). As a sidenote:
IETF has no intention or mechanism to stop people doing unscalable, poorly
designed things with their specs and that was ok as long people did not try
to push them onto the whole world without listening to folks who took the
scar tissue to get us the IETF working specs we have today which seems to
have become fashionable in last couple of years.

And fast flooding is a red herring here IMO, it does nothing but accelerate
the control loop, if the control loop is positively stable, it's good, if
the control loops are oscillating or start to negatively amplify
accelerating things just melts everything faster.

Ultimately, having followed this "discussion" my opinion is still that if
authors would like to abuse IGP as "domain wide broadcast" for liveliness
notification the "events" draft is far less fragile and convoluted but
should be kept in a service instance as basically "event based BFD
substitute" to not start to cause head-blocking on IGP resources. And AFAIR
Robert observed it's still not a very good indication compared to BFD, a
good solution would be e.g. in PE case a (hierarchical) MP2MP BFD PMSI
(assuming UDP healthy = TCP healthy which is however far less an assumption
than "flooding feels transport is OK").

-- tony

On Mon, Nov 22, 2021 at 7:55 AM Tony Li  wrote:

>
> Les,
>
>
> The problem is that restricting the prefix length does nothing to limit
> the number of advertisements that get flooded.  In a high-scale situation,
> when there is a mass failure, it would lead to a flooding spike. That’s
> exactly not the time to stress the system.
>
> *[LES:] As I have stated previously, I share your concern about the
> behavior during massive events – and some care has to be taken to prevent
> making a bad situation worse.*
> *That said, the WG (including you and I)  is taking on enhancements to
> support much faster flooding – on the order of hundreds (perhaps thousands)
> of LSPs/second. We believe this can be done safely (though proof has not
> yet been established).*
>
>
>
> And the point of doing that was to help improve IGP convergence time…
>
>
> *So, if you believe (as your active participation suggests) that IGPs can
> support faster flooding – why do you believe they cannot support liveness
> notification at a similar scale?*
>
>
>
> … not waste our time by inflating the LSDB by the same amount that we sped
> up flooding.
>
> Also, I don’t see how faster flooding has ANYTHING to do with it. Adding
> negative liveness information is primary a scale issue.
>
>
>
> *I get that you consider such notifications as architecturally undesirable
> – we can agree to disagree on that point.*
> *But I don’t get why you think the IGP’s ability to handle large scale
> events is a showstopper in this case.*
>
>
>
> I am opposed to anything that adds to the scale of the LSDB. Doubly so if
> it does so during failures, when the IGP is already under stress. As you
> well know, making an IGP stable during normal operations is one thing.
> Ensuring that it is stable during worst case topological changes is quite
> another. Adding scale during a mass failure is pessimal timing.
>
> T
>
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Tony Przygienda]

Agreeing with T. Li here (i.e. BFD next-hops) and let me add that AFAIS the
confusion here is that a presence of a /32 route is used as SSAP liveliness
AFAIS and that's simply not what IGPs are here for if you consider their
main job to be fastest possible convergence in network _reachability_ only
and not signalling of service failures. BGP is the overlay synchronizing
SSAPs & scales marvelously @ that. Having BGP next-hop (which is basically
equivalent to all services provided behind it) liveliness indicating the
health of services behind it is the scalable solution IMO, and not starting
to try to teach IGP fragile signalling or PUAM (which BTW AFAIS will
neither scale nor work on generic graphs due to lack of any consistent
algebra I could detect in the draft and it is definitely nothing "like
rift" as the preso seems to claim again) which will easily affect its main
job. For signalling I see how putting it into a service instance is a
somewhat palatable design choice and it's kind of like inventing "passive
BFD" over flooding in my eyes ;-) And BTW, in topologically sorted graphs
(CLOS being the ones of interest these days) with strict positive/negative
disaggregation algebra with minimal blast radius on failures we can scale
to (at least) 0.5M prefixes implementation wise IME and that should allow
us really, really big IP fabrics with leaves holding nothing but defaults
under normal conditions but it's still not a good idea to abuse that for
SSAP synchronization AFAIS (and observe that to scale RIFT does NOT notify
leaves of their vice-versa reachability, it simply prevents blackholing on
aggregates and will produce an ICMP unreachable if there are no routes left
to destination, if you run BFD on top of that as Tony suggests, this will
of course give you the desired effect, for RR you'll run into the TCP
session problem again but maybe you can BFD the RR session and then
propagate that as Robert seems to suggest, the third-party next-hop raises
its head again ;-).

Alternately resolving BGP over BGP as Robert suggests (if I read that
correctly) and use RR to scale out the SSAP nhop availability is possible I
think architecturally without garbage-canning IGPs as "network-wide fast
broadcast mechanism" ... I doubt it will do "couple millisecs" convergence
;-) but can be simpler hardware wise than trying to scale up BFD to large
number of very fast sessions.

-- tony



On Thu, Nov 18, 2021 at 5:06 PM Tony Li  wrote:

>
> Les,
>
> Why would we then punch holes in the summary for member routers?  Just
> because we can?
> *[LES:] No. We are doing it to improve convergence AND retain scalability.*
>
>
>
> You are not improving convergence. You are propagating liveness.  The fact
> that this relates to convergence in the overlay is irrelevant to the IGP.
>
> You are not retaining scalability. You are damaging it. You are proposing
> flooding a prefix per router that fails. If there is a mass failure, that
> would result in flooding a large number of prefixes. The last thing you
> want when there is a mass failure is additional load, exacerbating the
> situation.
>
>
>  Should we corrupt the architecture just because we can?  There are other,
> architecturally appropriate solutions available.  How about we just use
> them?
>
> *[LES:] What are you proposing?*
>
>
>
> You are signaling the (lack of) liveness of a remote node. I propose that
> we instead use existing signaling mechanisms to do this. Multi-hop BFD
> seems like an obvious choice.
>
> If you greatly dislike that for some reason, I would suggest that we
> create a proxy liveness service, advertised by the ABR. This would allow
> correspondents to register for notifications. The ABR could signal these
> unicast when it determines that the specific targets are unreachable.
>
> Tony
>
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] New Version Notification for draft-hegde-lsr-asla-any-app-00.txt

[Tony Przygienda]

On Sat, Aug 21, 2021 at 11:51 AM Robert Raszuk  wrote:

> Tony
>
> > I see a value in the "A" bit from multiple angles (which I do not read
> as "all applications" but "any application".
>
> Spot on ! Yes we did mean "any app" not "all apps". Even title says "any"
> :) Each app can still cherry pick what it uses in FAD.
>

ok, yepp, as I said, I did not scan the draft yet and if all that has been
abundantly clear no damage in spelling it out again.


>
> > (I didn't read the 'a' draft yet so it may be taken care of) is whether
> SABM length is 1 with all 0s or
> > length is 0 on A bit presence and if 0 will the current implementations
> hold up to that ;-)
>
> I am not following this one ...
>
> SABM length in octets describes length of the actual application bit
> octets. A-bit or R,S,F,X are part of it.
>
> So for A-bit length must be at least 1 or more.
>
> But now comes Les and says:
>
> *> (For the purposes of this discussion it does not matter whether I use
> the existing 0 length *
> *> ABM format or the proposed new “A-bit” format)*
>
> That to me is ambiguous as it sort of means that 0 length ABM flags may be
> defined as any application.
>

it's not a good suggestion AFAIS, a natural semantics for 0 length ABM is
realy "_no_ application"


>
> If that would be the case (which I believe is not today) then indeed no
> need to define A-bit.
>
> Cheers,
> R.
>
>
> On Sat, Aug 21, 2021 at 9:05 AM Tony Przygienda 
> wrote:
>
>> My quick take:
>>
>> 1. yes, A bit will necessitate being either deployed in a well understood
>> part of the network (because as Les says old nodes will basically see _no_
>> application [which seems desirable, they basically take themselves out]) or
>> forklifting. Not that different from flex-algo being same kind of forklift
>> AFAIS.
>> 2. any application introduced after that will precondition implementation
>> of A bit if we don't want to get into the rathole of "do not encode using
>> A, encode using repetition per application if you have old routers".
>>
>> I see a value in the "A" bit from multiple angles (which I do not read as
>> "all applications" but "any application". The distinction is subtle but
>> important)
>>
>> a) it fits what flex-algo needs in ASLA architecture. E'one wins AFAIS.
>> b) if we want to replace A with X|Y|Z we need to know on a router about
>> _all_ applications on all routers and that may be non-trivial and on every
>> change may force re-adverts (unless we set all bits 1 on a 8 bytes ASLA
>> mask [as in _all_ applications]. That does not seem like a good idea given
>> the encoding sizes). A as "any" basically means "any application on this
>> router uses this metric" and avoids both problems. Significantly simpler
>> AFAIS.
>>
>> A very, very subtle point (I didn't read the 'a' draft yet so it may be
>> taken care of) is whether SABM length is 1 with all 0s or length is 0 on A
>> bit presence and if 0 will the current implementations hold up to that ;-)
>>
>> Les, correct me if I'm off somewhere, I was watching lots of that just
>> from the corner of my eye ;-)
>>
>> -- tony
>>
>>
>>
>> On Sat, Aug 21, 2021 at 2:06 AM Les Ginsberg (ginsberg) > 40cisco@dmarc.ietf.org> wrote:
>>
>>> Robert -
>>>
>>>
>>>
>>> *From:* Robert Raszuk 
>>> *Sent:* Friday, August 20, 2021 5:01 PM
>>> *To:* Les Ginsberg (ginsberg) 
>>> *Cc:* Ron Bonica ; lsr@ietf.org
>>> *Subject:* Re: [Lsr] New Version Notification for
>>> draft-hegde-lsr-asla-any-app-00.txt
>>>
>>>
>>>
>>> Hi Les,
>>>
>>>
>>>
>>> *The point being is that “A-bit” is no different than introducing any
>>> other new application bit. Until all routers in the network understand it
>>> you cannot safely use it.*
>>>
>>>
>>>
>>> That is true.
>>>
>>>
>>>
>>> But the entire point of A-bit is that you are doing this exercise to
>>> make sure your routers understand A-bit only one time.
>>>
>>> *[LES:] This does not mean that you can introduce support for a new
>>> application (call it “bit N”) w/o upgrading your routers simply because you
>>> already have A-bit support. I hope that is obvious. ***
>>>
>>>
>>>
>>> *My original point was simply  that the statement about “backwards
>>

Re: [Lsr] New Version Notification for draft-hegde-lsr-asla-any-app-00.txt

[Tony Przygienda]

My quick take:

1. yes, A bit will necessitate being either deployed in a well understood
part of the network (because as Les says old nodes will basically see _no_
application [which seems desirable, they basically take themselves out]) or
forklifting. Not that different from flex-algo being same kind of forklift
AFAIS.
2. any application introduced after that will precondition implementation
of A bit if we don't want to get into the rathole of "do not encode using
A, encode using repetition per application if you have old routers".

I see a value in the "A" bit from multiple angles (which I do not read as
"all applications" but "any application". The distinction is subtle but
important)

a) it fits what flex-algo needs in ASLA architecture. E'one wins AFAIS.
b) if we want to replace A with X|Y|Z we need to know on a router about
_all_ applications on all routers and that may be non-trivial and on every
change may force re-adverts (unless we set all bits 1 on a 8 bytes ASLA
mask [as in _all_ applications]. That does not seem like a good idea given
the encoding sizes). A as "any" basically means "any application on this
router uses this metric" and avoids both problems. Significantly simpler
AFAIS.

A very, very subtle point (I didn't read the 'a' draft yet so it may be
taken care of) is whether SABM length is 1 with all 0s or length is 0 on A
bit presence and if 0 will the current implementations hold up to that ;-)

Les, correct me if I'm off somewhere, I was watching lots of that just from
the corner of my eye ;-)

-- tony



On Sat, Aug 21, 2021 at 2:06 AM Les Ginsberg (ginsberg)  wrote:

> Robert -
>
>
>
> *From:* Robert Raszuk 
> *Sent:* Friday, August 20, 2021 5:01 PM
> *To:* Les Ginsberg (ginsberg) 
> *Cc:* Ron Bonica ; lsr@ietf.org
> *Subject:* Re: [Lsr] New Version Notification for
> draft-hegde-lsr-asla-any-app-00.txt
>
>
>
> Hi Les,
>
>
>
> *The point being is that “A-bit” is no different than introducing any
> other new application bit. Until all routers in the network understand it
> you cannot safely use it.*
>
>
>
> That is true.
>
>
>
> But the entire point of A-bit is that you are doing this exercise to make
> sure your routers understand A-bit only one time.
>
> *[LES:] This does not mean that you can introduce support for a new
> application (call it “bit N”) w/o upgrading your routers simply because you
> already have A-bit support. I hope that is obvious. ***
>
>
>
> *My original point was simply  that the statement about “backwards
> compatibility” regarding A-bit isn’t accurate. Good that we now agree on
> that.*
>
>
>
> *   Les*
>
>
>
> Otherwise you need to do it each time you invent a new bit.
>
>
>
> Thx,
>
> R.
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Sat, Aug 21, 2021 at 1:34 AM Les Ginsberg (ginsberg) <
> ginsb...@cisco.com> wrote:
>
> Robert –
>
>
>
> Inline.
>
>
>
> *From:* Robert Raszuk 
> *Sent:* Friday, August 20, 2021 1:29 PM
> *To:* Les Ginsberg (ginsberg) 
> *Cc:* Ron Bonica ; lsr@ietf.org
> *Subject:* Re: [Lsr] New Version Notification for
> draft-hegde-lsr-asla-any-app-00.txt
>
>
>
> Hi Les,
>
>
>
> Please see below.
>
>
>
> It is not just that a new application wants to use the same link attribute
> value that allows you to use the "all applications" encoding. It is also
> necessary for the set of links used by the new application to be identical
> to the set of links used by the existing applications.
>
>
>
> Not really. You can use subset of links when you apply affinity bits to
> it.
>
> *[LES:] This isn’t relevant.*
>
> *Let me try explaining this a different way.*
>
>
>
> *Suppose I have 1000 links in my network. *
>
> *On 500 of those links I have Attribute #1 advertised using “all
> applications”. (For the purposes of this discussion it does not matter
> whether I use the existing 0 length ABM format or the proposed new “A-bit”
> format)*
>
> *There are currently two applications, X and Y, deployed in the network
> and they are both using the same value of attribute #1 on the same set of
> 500 links.*
>
> *All is well.*
>
> *Now, I want to enable application Z. If I do so and make no changes to
> the existing link attribute advertisements, application Z will think it can
> use Attribute #1 on all 500 of the links on which the “all” form of the
> ASLA sub-TLV is being advertised.*
>
> *If application Z is intended to use all of those 500 links all is well.
> But if application Z is NOT meant to use one or more of the links on which
> the ALL ASLA sub-TLVs are being advertised then I have to make changes to
> at least some of the existing advertisements.*
>
>
>
> *This is why, in RFC 8919/8920, we advise caution in using the “all” form
> – and why we do not allow both the “all” form and the “app-specific” form
> to be used by a given application. It is too easy for mistakes to occur,
> especially when enabling a new application.*
>
>
>
> *Implementations that I am aware of do not send the “ALL” form for this
> reason i.e., it introduces dependencies between 

Re: [Lsr] Request to consider Flood Reflection going into LC

[Tony Przygienda]

speaking of which, can I have 5 mins on the agenda for update flood
reflection draft v2/v3? earlier in the session would be merciful since it's
1am-3am session on Fri for me. thx. tony

On Fri, Jul 9, 2021 at 7:26 AM Tony Przygienda  wrote:

> Dear chairs, flood reflection is implemented/shipped and deploying and
> we’re on early alloc codepoints that expire start Aug’. No further
> discussions on the list happened.
>
> As far as we see as authors stuff looks shaken out, all things that were
> found in implementation/use are in the latest draft version and I’d like to
> test the waters of LC’ing it rather than dragging it on as draft and asking
> for temporary alloc again which does not seem to serve a purpose AFAIS.
>
> thanks
>
> -- tony
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] Request to consider Flood Reflection going into LC

[Tony Przygienda]

Dear chairs, flood reflection is implemented/shipped and deploying and
we’re on early alloc codepoints that expire start Aug’. No further
discussions on the list happened.

As far as we see as authors stuff looks shaken out, all things that were
found in implementation/use are in the latest draft version and I’d like to
test the waters of LC’ing it rather than dragging it on as draft and asking
for temporary alloc again which does not seem to serve a purpose AFAIS.

thanks

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

Re: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03

[Tony Przygienda]

I never saw more than 3-4 MT "slices" deployed, Gyan. Operational
complexity basically. Usual Ks or 10Ks prefixes in main instance and not
more than maybe 1K in others.

So practically speaking I would worry about operational procedures of such
a deployment first (OAM, connected topologies, provisioning [since both
sides of MT need matching configuration, as I said, on purpose from
experience operating such things then], validation). A controller makes a
lot sense here, not even necessarily as provisioning tool first but
visualization, OAM, operational analytics. Think basically that you're
getting yourself from "normal IGP" experience into something that will
resemble L3VPN more and you know the problems there pretty well ;-)

Also, planning of fast reroute strategy is good, what links/mix of
topologies you want to protect others and will you have enough capacity
once FRR kicks in. There are commercial tools available to "simulate" that
kind of stuff and AFAIR decent amount of theoretical work done on necessary
algorithms (and since the solution space starts to become real large real
fast something like an A/B test with ML could deliver good results [weighed
decision trees or something like this]. The difficult thing being of course
to establish a cost function as in "is one topology down due to overload &
e'one protected without loss better than e'one losing some packets better
or worse").

--- tony



On Mon, Mar 29, 2021 at 7:07 AM Gyan Mishra  wrote:

> Hi  Tony
>
> One of the main concerns for operators as you have elaborated is the real
> world operators experiences aside from what you mentioned common use case
> of IPv6 as the first non zero MT, and vendor feedback on scalability and
> resource issues using many MT IPv4 and IPv6 separate instance and how well
> it scales or not and operational impacts with troubleshooting multiple RIB
> instances with common LSDB with discrete SPF instance per topology and
> control plane scale issues as the number of instances grows.
>
> Also complexity related to NOC troubleshooting and MTTR when you have
> let’s say 10 to 100 network slices for example, how complex do things get
> and is it manageable or not.
>
> As you have 12 bits of MT ID, 4096 instances is quite a lot.  Could you
> really ever scale to 4096 MT instances, probably not.
>
> What is a real world practical hard limit from your experiences of number
> of prefixes per MT RIB and maximum number of MT RIB instances.
>
> Also a cross comparison of MI non zero instance IID/ITID comparing 100
> ITID sub topologies to 100 MT RIB topologies and which scales better.
>
> Much appreciated your MT & MI experiences  and real world feedback.
>
>
> Kind Regards
>
> Gyan
>
> On Sat, Mar 27, 2021 at 6:59 AM Tony Przygienda 
> wrote:
>
>> Having had a long history with RFC5120 (and with the concept before IETF
>> was even afoot really) and their deployment in its time I cannot resist
>> finally chiming in a bit ;-)
>>
>> Well, first, it seems there is agreement that the drafts state fairly
>> straightforward things but as informational probably nothing wrong with
>> having it captured and I'd agree with that.
>>
>> Second, as to realities of MT in such architecture some musings based on
>> experience;
>>
>> a) MT was best used when faced with the problem of "alien" topologies,
>> e.g. introduction of v6 into a network when a lot of boxes/links couldn't
>> do v6 yet (there was a good set of discussions in its time around MT
>> strictly per node or per link being best approach and for many reasons link
>> based architecture was chosen) or need for drastically different forwarding
>> decision deviating from simple SPF (RPF problems).
>> b) using underlay to "slice" is an expensive proposition of course. The
>> costliest resources in large networks is really ASIC space in the core and
>> if the MTs are properly separated, that will take ASIC state. in simplest
>> form e.g. topology being mirrored into per DSCP bits lookup or something
>> like this. Nothing wrong with that if one has the $ (or CNY ;-) to foot the
>> bill for that and slicing underlay gives of course the best quality
>> assurance compared to overlay approaches AFAIS.
>> c) MT (well, at least in ISIS ;-) has been built to scale ;-), originally
>> 8 bits were suggested and then I asked others "what's the biggest you can
>> imagine" to which answer was 1024 MT which needed of course a
>> multiplication by 4 to make sure stuff will still work in 25 years where we
>> are today ;-)
>> d) SPF is to an extent only limitation of MT. the tree itself can be
>> computed very efficiently today (and ther

Re: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03

[Tony Przygienda]

Having had a long history with RFC5120 (and with the concept before IETF
was even afoot really) and their deployment in its time I cannot resist
finally chiming in a bit ;-)

Well, first, it seems there is agreement that the drafts state fairly
straightforward things but as informational probably nothing wrong with
having it captured and I'd agree with that.

Second, as to realities of MT in such architecture some musings based on
experience;

a) MT was best used when faced with the problem of "alien" topologies, e.g.
introduction of v6 into a network when a lot of boxes/links couldn't do v6
yet (there was a good set of discussions in its time around MT strictly per
node or per link being best approach and for many reasons link based
architecture was chosen) or need for drastically different forwarding
decision deviating from simple SPF (RPF problems).
b) using underlay to "slice" is an expensive proposition of course. The
costliest resources in large networks is really ASIC space in the core and
if the MTs are properly separated, that will take ASIC state. in simplest
form e.g. topology being mirrored into per DSCP bits lookup or something
like this. Nothing wrong with that if one has the $ (or CNY ;-) to foot the
bill for that and slicing underlay gives of course the best quality
assurance compared to overlay approaches AFAIS.
c) MT (well, at least in ISIS ;-) has been built to scale ;-), originally 8
bits were suggested and then I asked others "what's the biggest you can
imagine" to which answer was 1024 MT which needed of course a
multiplication by 4 to make sure stuff will still work in 25 years where we
are today ;-)
d) SPF is to an extent only limitation of MT. the tree itself can be
computed very efficiently today (and there are techniques like incremental
SPF which can drastically lessen the cost of a computation and one can go
to the extent of throwing the SPF computations to a beefy side-box even and
most extreme, ASIC [unbelievale or not, this has been done for trees up to
a certain space ;-)]), the limiting factor is more prefix attachement and
prefix download on massive changes (but there is no reason any LFA would
not work with MT BTW, even to the point where an MT can protect another MT
or MT use all links when protecting disregarding MT itself, I'm not aware
of implementations but the theoretical thinking/whiteboarding has been done
here long ago albeit one has to know a fair bit of math [metric sets
largely]) to not blow up on a mine ;-)
e) main limiting factor of MT deployment was IME operational discontinuity
of topologies that happens much more often than one thinks it does. That's
why MT negotiates on every link the topologies so continuity is clearly
provisioned and can be tracked. Tools to visualize, manage all that are
much harder to operate than one would think, I assume because humans
generally have poor intuition concerning topological spaces under different
metrics. Just look how confused we are when we try to strike something in a
glass of water ;-)
b) yes, TE can be advertised in topologies but here is bunch of things that
fall out of it
i) oversubscription is a fact of life in such an architecture and
discussions about this will start quickly
ii) except in case of massive under-subscription (but even then) the
correct scheduling of MTs will become an issue and possibly pre-emption in
HW when the timing becomes tight enough. DetNet is an interesting romping
ground of ideas for that right now
iii) Even with under-subscription interesting problems crop up like parties
that don't need much resources under normal circumstances but in case of
emergencies are willing to pay any amount to allocate resources their need
and pre-empt any other traffic.

--- tony






On Sat, Mar 27, 2021 at 4:47 AM Gyan Mishra  wrote:

>
> Hi Acee
>
> As an operator, I  support adoption of the draft and would like to provide
> answers to your questions.
>
> I would like to start by stating that as this is an informational
> document,  as nothing new is proposed other then the recommendation to use
> MT for VTN provisioning as a component of the 5G network slicing solutions,
> the benefit is that this concept can be used immediately as other NS
> features are still being developed.
>
> The solution for network slicing resource isolation is multi faceted
> involves Enhanced VPN+ provisioning, resource SIDs for provisioning
> underlay resources, SR-TE Per VPN or flow path steering to meet NS SLO
> requirements, as well as a method to isolate IGP resources for a VTN.
>
> MT is a component of the entire NS solution so there is really nothing to
> market as it’s not the only component used to provision the VTN.
>
> As their is a need for providing a viable means of provisioning IGP
> underlay resources VTN network slice and the ability to provide forwarding
> plane isolation via topological RIB without consuming tremendous control
> plane resources per instance as with MI.
>
> This draft does fill the gap 

Re: [Lsr] https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-05

[Tony Przygienda]

same thing. if you want go multiple hops ZeroMQ you need forwarding
already. And if you go one hop it really doesn't matter, it's just FOSE
(flooding over something else ;-)

-- tony

On Wed, Mar 10, 2021 at 12:52 PM Robert Raszuk  wrote:

> >  You think Kafka here?
>
> Nope ... I meant ZeroMQ message bus as underlaying pub-sub transport for
> service related info.
>
> Thx,
> R.,
>
>
> On Wed, Mar 10, 2021 at 11:41 AM Tony Przygienda 
> wrote:
>
>> ? Last time I looked @ it (and it's been a while) Open-R had nothing of
>> that sort, it was basically KV playing LSDB (innovative and clever in
>> itself). You think Kafka here? Which in turn needs underlying IGP however
>> and is nothing but BGP problems in new clothes having looked @ their
>> internal architecture and where it's goiing a while ago.
>>
>> -- tony
>>
>> On Wed, Mar 10, 2021 at 11:29 AM Robert Raszuk  wrote:
>>
>>> Peter,
>>>
>>> > But suddenly the DOWN event distribution is considered
>>> > problematic. Not sure I follow.
>>>
>>> In routing and IP reachability we use p2mp distribution and flooding as
>>> it is required to provide any to any connectivity.
>>>
>>> Such spray model no longer fits services where not every endpoint
>>> participates in all services.
>>>
>>> So my point is that just because you have transport ready we should not
>>> continue to announce neither good nor bad news in spray fashion for
>>> services.
>>>
>>> Sure it works, but it is hardly a good design and sound architecture.
>>>
>>> It happened to BGP as the convenience of already having TCP sessions
>>> between nodes was so great that we loaded loads of stuff to go along basic
>>> routing reachability.
>>>
>>> And now it seems time came to do the same with IGPs :).
>>>
>>> I think unless we stop and define a real pub-sub messaging protocol
>>> (like FB does with open-R)  we will continue this.
>>>
>>> And to me it is like building a tower from the cards ... the higher you
>>> go the more likely your entire tower is to collapse.
>>>
>>> Cheers,
>>> R.
>>>
>>> PS.
>>>
>>> > with MPLS loopback address of all PEs is advertised everywhere.
>>>
>>> Is this a feature or a day one design bug later fixed by RFC5283 ?
>>>
>>>
>>>
>>>
>>> On Wed, Mar 10, 2021 at 9:10 AM Peter Psenak  wrote:
>>>
>>>> Robert,
>>>>
>>>>
>>>> On 09/03/2021 19:30, Robert Raszuk wrote:
>>>> > Hi Peter,
>>>> >
>>>> >  > Example 1:
>>>> >  >
>>>> >  > If session to PE1 goes down, withdraw all RDs received from
>>>> such PE.
>>>> >
>>>> > still dependent on RDs and BGP specific.
>>>> >
>>>> >
>>>> > To me this does sound like a feature ... to you I think it was rather
>>>> > pejorative.
>>>>
>>>> not sure I understand your point with "pejorative"...
>>>>
>>>> There are other ways to provide services outside of BGP - think GRE,
>>>> IPsec, etc. The solution should cover them all.
>>>>
>>>> >
>>>> > We want app independent way of
>>>> > signaling the reachability loss. At the end that's what IGPs do
>>>> without
>>>> > a presence of summarization.
>>>> >
>>>> >
>>>> > Here you go. I suppose you just drafted the first use case for OSPF
>>>> > Transport Instance.
>>>>
>>>> you said it, not me.
>>>>
>>>>
>>>> >
>>>> > I suppose you just run new ISIS or OSPF Instance and flood info about
>>>> PE
>>>> > down events to all other instance nodes (hopefully just PEs and no Ps
>>>> as
>>>> > such plane would be OTT one).  Still you will be flooding this to
>>>> 100s
>>>> > of PEs which may never need this information at all which I think is
>>>> the
>>>> > main issue here. Such bad news IMHO should be distributed on a
>>>> pub/sub
>>>> > basis only. First you subscribe then you get updates ... not get
>>>> > everything then keep junk till it get's removed or expires.
>>>>
>>>> with MPLS loopback address of all PEs is advertised everywhere. So you
>>>> keep the state when the remote PE loopback is up and you get a state
>>>> withdrawal when the remote PE loopback goes down.
>>>>
>>>> In Srv6, with summarization we can reduced the amount of UP state to
>>>> minimum. But suddenly the DOWN event distribution is considered
>>>> problematic. Not sure I follow.
>>>>
>>>> thanks,
>>>> Peter
>>>>
>>>> >
>>>> > Many thx,
>>>> > Robert
>>>> >
>>>>
>>>> ___
>>> 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] https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-05

[Tony Przygienda]

? Last time I looked @ it (and it's been a while) Open-R had nothing of
that sort, it was basically KV playing LSDB (innovative and clever in
itself). You think Kafka here? Which in turn needs underlying IGP however
and is nothing but BGP problems in new clothes having looked @ their
internal architecture and where it's goiing a while ago.

-- tony

On Wed, Mar 10, 2021 at 11:29 AM Robert Raszuk  wrote:

> Peter,
>
> > But suddenly the DOWN event distribution is considered
> > problematic. Not sure I follow.
>
> In routing and IP reachability we use p2mp distribution and flooding as it
> is required to provide any to any connectivity.
>
> Such spray model no longer fits services where not every endpoint
> participates in all services.
>
> So my point is that just because you have transport ready we should not
> continue to announce neither good nor bad news in spray fashion for
> services.
>
> Sure it works, but it is hardly a good design and sound architecture.
>
> It happened to BGP as the convenience of already having TCP sessions
> between nodes was so great that we loaded loads of stuff to go along basic
> routing reachability.
>
> And now it seems time came to do the same with IGPs :).
>
> I think unless we stop and define a real pub-sub messaging protocol (like
> FB does with open-R)  we will continue this.
>
> And to me it is like building a tower from the cards ... the higher you go
> the more likely your entire tower is to collapse.
>
> Cheers,
> R.
>
> PS.
>
> > with MPLS loopback address of all PEs is advertised everywhere.
>
> Is this a feature or a day one design bug later fixed by RFC5283 ?
>
>
>
>
> On Wed, Mar 10, 2021 at 9:10 AM Peter Psenak  wrote:
>
>> Robert,
>>
>>
>> On 09/03/2021 19:30, Robert Raszuk wrote:
>> > Hi Peter,
>> >
>> >  > Example 1:
>> >  >
>> >  > If session to PE1 goes down, withdraw all RDs received from such
>> PE.
>> >
>> > still dependent on RDs and BGP specific.
>> >
>> >
>> > To me this does sound like a feature ... to you I think it was rather
>> > pejorative.
>>
>> not sure I understand your point with "pejorative"...
>>
>> There are other ways to provide services outside of BGP - think GRE,
>> IPsec, etc. The solution should cover them all.
>>
>> >
>> > We want app independent way of
>> > signaling the reachability loss. At the end that's what IGPs do
>> without
>> > a presence of summarization.
>> >
>> >
>> > Here you go. I suppose you just drafted the first use case for OSPF
>> > Transport Instance.
>>
>> you said it, not me.
>>
>>
>> >
>> > I suppose you just run new ISIS or OSPF Instance and flood info about
>> PE
>> > down events to all other instance nodes (hopefully just PEs and no Ps
>> as
>> > such plane would be OTT one).  Still you will be flooding this to 100s
>> > of PEs which may never need this information at all which I think is
>> the
>> > main issue here. Such bad news IMHO should be distributed on a pub/sub
>> > basis only. First you subscribe then you get updates ... not get
>> > everything then keep junk till it get's removed or expires.
>>
>> with MPLS loopback address of all PEs is advertised everywhere. So you
>> keep the state when the remote PE loopback is up and you get a state
>> withdrawal when the remote PE loopback goes down.
>>
>> In Srv6, with summarization we can reduced the amount of UP state to
>> minimum. But suddenly the DOWN event distribution is considered
>> problematic. Not sure I follow.
>>
>> thanks,
>> Peter
>>
>> >
>> > Many thx,
>> > Robert
>> >
>>
>> ___
> 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] New Version Notification for draft-wang-lsr-isis-mfi-00.txt

[Tony Przygienda]

Gyan, all good except you find that once you have MFI thought through and
really working (implementations do wonder to understanding) with all kind
of frills like Les pointed out you'll build MT by another name again most
likely AFAIS.

If you want to flood everywhere and have some attribution on links you try
to put into computation you end up in flex algo corner pretty much (which
has been done pretty much already in a mild but extremely practical form in
RFC2676 but wasn't the hot cookie of the day then)

The sharing of FECs Tarek proposes seems like a clever optimization and
something bitsy new if that gives you the "slice" definition @ maximum
scale you look for.

-- tony

On Tue, Mar 9, 2021 at 3:47 PM Gyan Mishra  wrote:

> Tony,
>
> In-line
>
> On Tue, Mar 9, 2021 at 5:55 AM Tony Przygienda 
> wrote:
>
>> and replying to myself, as was mentioned yesterday in LSR already, the
>> key questions is HOW MANY control plane slices and then FIB slices do you
>> really need in the technology to be built.  And how much of that needs to
>> be really in the core? Both will have large implication on solutions, you
>> cannot run 2000 IGP processes in a box but you could run 2K topologies on
>> IGP (cough, cough). IGP control plane will be limited by how many
>> computations you can crunch (unless you take that off box, bit risky but
>> thnkable) and then can you OAM & operate such a solution, especially if
>> topologies disjoin. FEC sharing tricks are proposed here and are worth
>> thinking through if they allow to squeeze #context in control plane into
>> less context in FIB but compression is a devil (think SR stack compression
>> today) since it often leads operationally to surprising effects. In
>> forwarding path all those things are trickier/more costly, on the edge we
>> run thousands of VPNs/EVIs in MP-BGP so it's thinkable, in the core, ehem,
>> well, you start to reinvent MPLS since about only thing that scales on
>> every core box is switching (if you want precise per box
>> accounting/control). You can 'fudge' things by the ancient loose source
>> routing, ehem, sorry, it's called SR now ;-) but this has a formidable set
>> of operational challenges since the ole Token Ring doing it.
>>
>> exec summary: figure out how many "slices" you need in control & data
>> plane & how tight they need to be in terms of SLAs and then swallow the
>> trade-offs. that may not be a single data point and multiple solutions may
>> be necessary.
>>
>> Gyan> Agreed.  For draft "draft-xie-lsr-isis-sr-vtn-mt-03" VTN
> underpinning it makes sense with this draft to pick the design to use MT
> separate forwarding plane RIB/FIB topology resource isolation over MI -
> Separate control plane & forwarding plane resource isolation.  As you
> stated with TEAS NS there could be 1000s of slices and so you really need
> to pick your poison carefully as far as degree of resource isolation to
> provide optimized overall scalability. This draft is another way to skin
> the cat for VTN network slice as far as isolation and taking it another
> step further to provide lesser isolation then MT with isolating with MFI
> flood instance to provide greater scalability with slices.
>
>> --- tony
>>
>> On Tue, Mar 9, 2021 at 11:47 AM Tony Przygienda 
>> wrote:
>>
>>> Gyan, you are confusing RIB with LSDB. It is absolutely feasible and
>>> normal to generate multiple RIBs/FIBs from a single LSDB and that has been
>>> done for about forever
>>>
>>> problem with lots of those proposals and assertions here is that
>>> powerpoint and rfc text always compiles no matter what you put into it,
>>> silicon and real implementations force to face the world not as you imagine
>>> it but as you can actually make it work in practical terms. Akin to talking
>>> about pottery (*there is a value to it in itself) and making a real pot
>>> with clay. Making a real pot first gives you a much better chance to
>>> actually talk about pottery meaningfully albeit it does not teach you
>>> aesthetics of pottery or a complete new way to make pots possibly.
>>>
>>> 2c
>>>
>>> -- tony
>>>
>>> On Fri, Mar 5, 2021 at 5:11 PM Gyan Mishra 
>>> wrote:
>>>
>>>> Hi Peter
>>>>
>>>> On Fri, Mar 5, 2021 at 10:56 AM Peter Psenak  wrote:
>>>>
>>>>> Gyan,
>>>>>
>>>>> On 05/03/2021 16:46, Gyan Mishra wrote:
>>>>> > Yali
>>>>> >
>>>>> > I agree with a Peter.
>>>>> >

Re: [Lsr] https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-05

[Tony Przygienda]

I know it's not fashionable (yet) but put multipoint BFD on BIER & run 2
subdomains and you got 10K. Add subdomains to taste which will also allow
to partition it across chips easily. Yepp, needs silicon that will sustain
reasonable rates but you have a pretty good darn' solution. IGP gives you
reachability for BIER already, you got minimal replication and you can tune
your timers to heart's delight.

Sticking stuff in IGP (to second Tony #1) is very satisfying, especially
since some of that could work some time @ no load on IGP. All those "let's
add a million things to IGP" only catches you when you realize in serious
outage your IGP is busy figuring out/flooding junk rather than getting you
basic connectivity. Yes, good implementation technique and careful design
of protocol can help (e.g. take ISIS extensions that allow you for a large
LSP space where you know what priority things are that need to go out/come
in/compute, here is sympathize with the new idea of separate instance for
"junk hauling" BTW ;-) but mashing overlay into underlay of your most time
sensitive and delicate piece of network control to use it as overlay
signalling protocol does not have a promising history. Confounding the
whole thing on top with adding a route type as signalling means is a bit
injury on top of insult or vice versa

-- tony

On Tue, Mar 9, 2021 at 12:03 PM Robert Raszuk  wrote:

> Hey Peter,
>
> Well ok so let's forget about LDP - cool !
>
> So IGP sends summary around and that is all what is needed.
>
> So the question why not propage information that PE went down in service
> signalling - today mainly BGP.
>
> >   And forget BFD, does not scale with 10k PEs.
>
> You missed the point. No one is proposing full mesh of BFD sessions
> between all PEs. I hope so at least.
>
> PE is connected to RRs so you need as many BFD sessions as RR to PE BGP
> sessions. Once that session is brought down RR has all it needs to trigger
> a message (withdraw or implicit withdraw) to remove the broken service
> routes in a scalable way.
>
> Thx,
> R.
>
> PS. Yes we still need to start support signalling of unreachability in BGP
> itself when BGP is used for underlay but this is a bit different use case
> and outside of scope of LSR
>
>
> On Tue, Mar 9, 2021 at 11:55 AM Peter Psenak  wrote:
>
>> Robert,
>>
>> On 09/03/2021 11:47, Robert Raszuk wrote:
>> >  > You’re trying to fix a problem in the overlay by morphing the
>> > underlay.  How can that seem like a good idea?
>> >
>> > I think this really nails this discussion.
>> >
>> > We have discussed this before and while the concept of signalling
>> > unreachability does seem useful such signalling should be done where it
>> > belongs.
>> >
>> > Here clearly we are talking about faster connectivity restoration for
>> > overlay services so it naturally belongs in overlay.
>> >
>> > It could be a bit misleading as this is today underlay which propagates
>> > reachability of PEs and overlay relies on it. And to scale,
>> > summarization is used hence in the underlay, failing remote PEs remain
>> > reachable. That however in spite of many efforts in lots of networks
>> are
>> > really not the practical problem as those networks still relay on exact
>> > match of IGP to LDP FEC when MPLS is used. So removal of /32 can and
>> > does happen.
>>
>> think SRv6, forget /32 or /128 removal. Think summarization.
>>
>> I'm not necessary advocating the solution proposed in this particular
>> draft, but the problem is valid. We need fast detection of the PE loss.
>>
>> And forget BFD, does not scale with 10k PEs.
>>
>> thanks,
>> Peter
>>
>>
>>
>> >
>> > In the same time BGP can pretty quickly (milliseconds) remove affected
>> > service routes (or rather paths) hence connectivity can be restored to
>> > redundantly connected endpoints in sub second. Such removal can be in a
>> > form of atomic withdraw (or readvertisement), removal of recursive
>> > routes (next hop going down) or withdraw of few RD/64 prefixes.
>> >
>> > I am not convinced and I have not seen any evidence that if we put this
>> > into IGP it will be any faster across areas or domains (case of
>> > redistribution over ASBRs to and from IGP to BGP). One thing for sure -
>> > it will be much more complex to troubleshoot.
>> >
>> > Thx,
>> > R.
>> >
>> > On Tue, Mar 9, 2021 at 5:39 AM Tony Li > > > wrote:
>> >
>> >
>> > Hi Gyan,
>> >
>> >  > Gyan> In previous threads BFD multi hop has been mentioned to
>> > track IGP liveliness but that gets way overly complicated especially
>> > with large domains and not viable.
>> >
>> >
>> > This is not tracking IGP liveness, this is to track BGP endpoint
>> > liveness.
>> >
>> > Here in 2021, we seem to have (finally) discovered that we can
>> > automate our management plane. This ameliorates a great deal of
>> > complexity.
>> >
>> >
>> >  > Gyan> As we are trying to signal the IGP to trigger the
>> > control plane 

Re: [Lsr] New Version Notification for draft-wang-lsr-isis-mfi-00.txt

[Tony Przygienda]

and replying to myself, as was mentioned yesterday in LSR already, the key
questions is HOW MANY control plane slices and then FIB slices do you
really need in the technology to be built.  And how much of that needs to
be really in the core? Both will have large implication on solutions, you
cannot run 2000 IGP processes in a box but you could run 2K topologies on
IGP (cough, cough). IGP control plane will be limited by how many
computations you can crunch (unless you take that off box, bit risky but
thnkable) and then can you OAM & operate such a solution, especially if
topologies disjoin. FEC sharing tricks are proposed here and are worth
thinking through if they allow to squeeze #context in control plane into
less context in FIB but compression is a devil (think SR stack compression
today) since it often leads operationally to surprising effects. In
forwarding path all those things are trickier/more costly, on the edge we
run thousands of VPNs/EVIs in MP-BGP so it's thinkable, in the core, ehem,
well, you start to reinvent MPLS since about only thing that scales on
every core box is switching (if you want precise per box
accounting/control). You can 'fudge' things by the ancient loose source
routing, ehem, sorry, it's called SR now ;-) but this has a formidable set
of operational challenges since the ole Token Ring doing it.

exec summary: figure out how many "slices" you need in control & data plane
& how tight they need to be in terms of SLAs and then swallow the
trade-offs. that may not be a single data point and multiple solutions may
be necessary.

--- tony

On Tue, Mar 9, 2021 at 11:47 AM Tony Przygienda  wrote:

> Gyan, you are confusing RIB with LSDB. It is absolutely feasible and
> normal to generate multiple RIBs/FIBs from a single LSDB and that has been
> done for about forever
>
> problem with lots of those proposals and assertions here is that
> powerpoint and rfc text always compiles no matter what you put into it,
> silicon and real implementations force to face the world not as you imagine
> it but as you can actually make it work in practical terms. Akin to talking
> about pottery (*there is a value to it in itself) and making a real pot
> with clay. Making a real pot first gives you a much better chance to
> actually talk about pottery meaningfully albeit it does not teach you
> aesthetics of pottery or a complete new way to make pots possibly.
>
> 2c
>
> -- tony
>
> On Fri, Mar 5, 2021 at 5:11 PM Gyan Mishra  wrote:
>
>> Hi Peter
>>
>> On Fri, Mar 5, 2021 at 10:56 AM Peter Psenak  wrote:
>>
>>> Gyan,
>>>
>>> On 05/03/2021 16:46, Gyan Mishra wrote:
>>> > Yali
>>> >
>>> > I agree with a Peter.
>>> >
>>> > As for resource isolation and provisioning of a VTN I think you really
>>> > need separate LSDB instances provided by MT or MI as better suited for
>>> > network slicing.
>>>
>>> MT does not provide LSDB separation, only MI does.
>>>
>>> thanks,
>>> Peter
>>
>>
>>I thought that each MT topology was a separate RIB meaning separate
>> LSDB.  The RFC is confusing.
>>
>> https://tools.ietf.org/html/rfc5120
>>
>> 6 <https://tools.ietf.org/html/rfc5120#section-6>.  MT SPF Computation
>>
>>Each MT MUST run its own instance of the decision process.  The
>>pseudo-node LSPs are used by all topologies during computation.  Each
>>non-default topology MAY have its attached bit and overload bit set
>>in the MT TLV.  A reverse-connectivity check within SPF MUST follow
>>the according MT to assure the bi-directional reachability within the
>>same MT.
>>
>>The results of each computation SHOULD be stored in a separate
>>Routing Information Base (RIB), in normal cases, otherwise
>>overlapping addresses in different topologies could lead to
>>undesirable routing behavior, such as forwarding loops.  The
>>forwarding logic and configuration need to ensure the same MT is
>>traversed from the source to the destination for packets.  The
>>nexthops derived from the MT SPF MUST belong to the adjacencies
>>
>>
>> conforming to the same MT for correct forwarding.  It is recommended
>>for the administrators to ensure consistent configuration of all
>>routers in the domain to prevent undesirable forwarding behavior.
>>
>>No attempt is made in this document to allow one topology to
>>calculate routes using the routing information from another topology
>>inside SPF.  Even though it is possible to redistribute and leak
>>routes from another IS-IS topology or from external

Re: [Lsr] New Version Notification for draft-wang-lsr-isis-mfi-00.txt

[Tony Przygienda]

Gyan, you are confusing RIB with LSDB. It is absolutely feasible and normal
to generate multiple RIBs/FIBs from a single LSDB and that has been done
for about forever

problem with lots of those proposals and assertions here is that powerpoint
and rfc text always compiles no matter what you put into it, silicon and
real implementations force to face the world not as you imagine it but as
you can actually make it work in practical terms. Akin to talking about
pottery (*there is a value to it in itself) and making a real pot with
clay. Making a real pot first gives you a much better chance to actually
talk about pottery meaningfully albeit it does not teach you aesthetics of
pottery or a complete new way to make pots possibly.

2c

-- tony

On Fri, Mar 5, 2021 at 5:11 PM Gyan Mishra  wrote:

> Hi Peter
>
> On Fri, Mar 5, 2021 at 10:56 AM Peter Psenak  wrote:
>
>> Gyan,
>>
>> On 05/03/2021 16:46, Gyan Mishra wrote:
>> > Yali
>> >
>> > I agree with a Peter.
>> >
>> > As for resource isolation and provisioning of a VTN I think you really
>> > need separate LSDB instances provided by MT or MI as better suited for
>> > network slicing.
>>
>> MT does not provide LSDB separation, only MI does.
>>
>> thanks,
>> Peter
>
>
>I thought that each MT topology was a separate RIB meaning separate
> LSDB.  The RFC is confusing.
>
> https://tools.ietf.org/html/rfc5120
>
> 6 .  MT SPF Computation
>
>Each MT MUST run its own instance of the decision process.  The
>pseudo-node LSPs are used by all topologies during computation.  Each
>non-default topology MAY have its attached bit and overload bit set
>in the MT TLV.  A reverse-connectivity check within SPF MUST follow
>the according MT to assure the bi-directional reachability within the
>same MT.
>
>The results of each computation SHOULD be stored in a separate
>Routing Information Base (RIB), in normal cases, otherwise
>overlapping addresses in different topologies could lead to
>undesirable routing behavior, such as forwarding loops.  The
>forwarding logic and configuration need to ensure the same MT is
>traversed from the source to the destination for packets.  The
>nexthops derived from the MT SPF MUST belong to the adjacencies
>
>
> conforming to the same MT for correct forwarding.  It is recommended
>for the administrators to ensure consistent configuration of all
>routers in the domain to prevent undesirable forwarding behavior.
>
>No attempt is made in this document to allow one topology to
>calculate routes using the routing information from another topology
>inside SPF.  Even though it is possible to redistribute and leak
>routes from another IS-IS topology or from external sources, the
>exact mechanism is beyond the scope of this document.
>
>
>
>>
>> >
>> > To me it seems a common LSDB shared among network slices VTN underlay
>> > could be problematic with network overlap issues.
>> >
>> > Kind Regards
>> >
>> > Gyan
>> >
>> > On Fri, Mar 5, 2021 at 10:28 AM Peter Psenak > > > wrote:
>> >
>> > Hi Yali,
>> >
>> > On 05/03/2021 15:31, wangyali wrote:
>> >  > Hi Peter,
>> >  >
>> >  > Thanks for your question. Please see inline [yali3].
>> >  >
>> >  > -Original Message-
>> >  > From: Peter Psenak [mailto:ppse...@cisco.com
>> > ]
>> >  > Sent: Thursday, March 4, 2021 11:20 PM
>> >  > To: wangyali > > >; Gyan Mishra > > >; Robert Raszuk > > >
>> >  > Cc: Huzhibo mailto:huzh...@huawei.com>>;
>> > Aijun Wang > > >; Tony Li > > >; lsr mailto:lsr@ietf.org
>> >>;
>> > Tianran Zhou mailto:zhoutian...@huawei.com
>> >>
>> >  > Subject: Re: [Lsr] New Version Notification for
>> > draft-wang-lsr-isis-mfi-00.txt
>> >  >
>> >  > Hi Yali,
>> >  >
>> >  > On 04/03/2021 14:45, wangyali wrote:
>> >  >> Hi Peter,
>> >  >>
>> >  >> Please see inline [Yali2]. Thanks a lot.
>> >  >>
>> >  >> -Original Message-
>> >  >> From: Peter Psenak [mailto:ppse...@cisco.com
>> > ]
>> >  >> Sent: Thursday, March 4, 2021 6:50 PM
>> >  >> To: wangyali > > >; Gyan Mishra
>> >  >> mailto:hayabusa...@gmail.com>>; Robert
>> > Raszuk mailto:rob...@raszuk.net>>
>> >  >> Cc: Huzhibo mailto:huzh...@huawei.com>>;
>> > Aijun Wang
>> >  >> mailto:wang...@chinatelecom.cn>>;
>> Tony
>> > Li mailto:tony...@tony.li>>; lsr
>> >  >> mailto:lsr@ietf.org>>; Tianran Zhou
>> > mailto:zhoutian...@huawei.com>>
>> >  >> Subject: Re: [Lsr] New Version Notification for
>> >  >> draft-wang-lsr-isis-mfi-00.txt
>> >  >>
>> >  >> Hi Yali,
>> >  >>
>> > 

Re: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03

[Tony Przygienda]

This argument seems fairly bogus to me. if you use IGP to flood some stuff
and then want the distributed computation stitch it together based on IGP
topology to get you a nexthop you end in computation which is something
like Bellman or Dijkstra or Boruvka. Unless you have some controller
distributing next-hops but then it's really PCE and not IGP AFAIS.

The difference in MI and MT is that MT carries the topology information
everywhere (you don't have to compute if you're not part of [simple check
on adjacencies] it but you still get stuff flooded). Some people like that
(manageability), some don't. IS does only flood to nodes connected in MI.

Operationally I learned ages ago that topologies disconnecting are some of
the most vexing scenarios and there MT is @ an advantage since partitioned
topology can be easily derived (and that's BTW why it's built that way with
strict adjacency negotiation). Reading the bestbar draft and looking @ e.g.
flex algo I am waiting to see how the "I cannot get there, why?" problems

On Mon, Mar 8, 2021 at 3:43 PM Tarek Saad  wrote:

> Hi authors,
>
>
>
> My understanding is the draft is proposing a separate MT topology (unique
> MT-ID) to identify a forwarding treatment to be enforced on a shared
> resource.
>
> While this may work for limited number of MT topologies (i.e. forwarding
> treatments), as described in RF5120 there is overhead with
> creating/advertising and managing and running separate SPF for each of the
> MT topology. This will restrict the scalability of such approach (number of
> forwarding treatments to be realized) using this approach.
>
>
>
> In I-D.draft-bestbar-lsr-spring-sa we are proposing carrying an
> independent ID (associated with the forwarding treatment) independent of
> the topology ID. This allows the # of forwarding treatmentst to be
> independent of the # of MT topologies that need to be managed by IGP; and
> hence, allow it to scale. Your feedback on this approach is welcome.
>
>
>
> Regards,
>
> Tarek
>
>
>
>
>
> On 3/8/21, 9:29 AM, "Lsr on behalf of Dongjie (Jimmy)" <
> lsr-boun...@ietf.org on behalf of jie.d...@huawei.com> wrote:
>
>
>
> Hi Gyan,
>
>
>
> Thanks for your comments.
>
>
>
> As you mentioned, both MT and MI can provide separate topologies and the
> topology based computation, and MI can provide separate LSDBs at some
> additional cost (separate adjacencies, etc.). In this document, the
> resource of VTN mainly refers to the forwarding plane resources, thus MT is
> chosen as it can provide the required functionality with less overhead.
>
>
>
> Hope this helps.
>
>
>
> Best regards,
>
> Jie
>
>
>
> *From:* Lsr [mailto:lsr-boun...@ietf.org] *On Behalf Of *Gyan Mishra
> *Sent:* Monday, March 8, 2021 7:29 AM
> *To:* Tony Przygienda 
> *Cc:* Les Ginsberg (ginsberg) ;
> Chongfeng Xie ; Acee Lindem (acee) <
> a...@cisco.com>; Robert Raszuk ; lsr@ietf.org
> *Subject:* Re: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology
> (MT) for Segment Routing based Virtual Transport Network” -
> draft-xie-lsr-isis-sr-vtn-mt-03
>
>
>
>
>
> Dear Authors
>
>
>
> Why was MT chosen and not MI for VTN underlay network slice underpinning.
> MT instances has separate topology but not separate LSDB where MI Multi
> instance RFC 6822 has a separate LSDB for resources isolation and I think
> would be a better fit for VTN underlay provisioning.
>
>
>
> MI
>
> https://tools.ietf.org/html/rfc6822
>
>
>
> Thanks
>
>
>
> Gyan
>
>
>
> On Sun, Mar 7, 2021 at 10:34 AM Tony Przygienda 
> wrote:
>
>
>
> Robert ruminated:
>
>
>
> That said I think perhaps we are indeed missing LROW WG (Local Routing
> Operations WG) where just like in GROW WG where mainly (Global) BGP
> operational aspects are discussed there could be good place to discuss
> operational aspects of link state protocols deployment and use cases. In
> fact perhaps it would also free some LSR bandwidth to really focus on
> protocol extensions.
>
>
>
>
>
> +1
>
>
>
> IGPs grew a zoo of horns and bells by now and no'one tells the operators
> which spines are poisonous ;-)
>
>
>
> --- tony
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
> --
>
> [image: 图像已被发件人删除。] <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
>
>
> *M 301 502-1347 13101 Columbia Pike  *Silver Spring, MD
>
>
>
> Juniper Business Use Only
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03

[Tony Przygienda]

Robert ruminated:

>
> That said I think perhaps we are indeed missing LROW WG (Local Routing
> Operations WG) where just like in GROW WG where mainly (Global) BGP
> operational aspects are discussed there could be good place to discuss
> operational aspects of link state protocols deployment and use cases. In
> fact perhaps it would also free some LSR bandwidth to really focus on
> protocol extensions.
>
>
+1

IGPs grew a zoo of horns and bells by now and no'one tells the operators
which spines are poisonous ;-)

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

Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints

[Tony Przygienda]

the pesky operational issue of those computations to suddenly partition the
graph (if used with dynamic resource updates) or otherwise pile everything
on the same link that led to RFC5120 being built the way it is. It is one
thing to get from RSVP-TE a "no resources to get there" indication and
another for IGP to magically not be getting there anymore while in terms of
best-effort functionality the destination looks perky and happy. One could
argue that you just need a routing table to see whether it's there but the
nature of those algorithms is that people show up with "I want 100MB" and
the answer there is very different from another request for "I want 1GB".
In Fore systems we basically had bunch of pre-defined/configurable profiles
we were pre-computing the answers (obviously also for performance purposes)
and comibned with the Q.2931 doing roughly what RSVP-TE is doing  +
crankback to do low catches stuff was working pretty well. There is a
patent for that still somewhere AFAIR.

-- tony

On Mon, Mar 1, 2021 at 10:48 PM Jeff Tantsura 
wrote:

> In ol’ good RSVP-TE days we already used “severity/relevance indicator” to
> decide whether changes in link  attributes (BW/etc) are significant enough
> and should be propagated in into TED and trigger re-optimization/rerouting,
> this is no different,  define your threshold for a trigger.
> Note - flex-also requires contiguous topology to work, self isolation as
> the result of (dynamic) topology re-computation would not be a great thing.
>
> Cheers,
> Jeff
> On Mar 1, 2021, 12:48 PM -0800, Tony Li , wrote:
>
>
> Robert,
>
> Constructing arbitrary topologies with bw constrain is useful work. For
> example I want to create a topology without links of the capacity less then
> 1 Gbps. All cool. Of course if I have a case where two nodes have 10 L3
> 1Gbps links nicely doing ECMP I will not include those which may be a
> problem.
>
>
>
> I agree that it may be a problem. Maybe it’s not the right tool for the
> job at hand. That doesn’t make it a bad tool, just the wrong one. I try not
> to turn screws with a hammer. And I try not to drive nails with a
> screwdriver.
>
> I will happily stipulate that we need more tools and that these are not
> enough. We should not reject a tool simply because it doesn’t solve all
> problems. Let’s work towards the right set of tools. Linear algebra tells
> us that we want an orthogonal set of basis vectors. What are they? Adding
> them one at a time is not horrible progress.
>
>
> However my observation is precisely related to your last sentence.
>
> Is this extension to be used with static or dynamic data ? If static all
> fine. But as William replied to me earlier link delay may be dynamically
> computed and may include queue wait time. That to me means something much
> different if Flex-Algo topologies will become dynamically adjustable. And I
> am not saying this is not great idea .. My interest here is just to
> understand the current scope.
>
>
>
> Link delay was dynamic before this draft. As William mentioned, TWAMP can
> already be used to provide a dynamic measurement of link delay. That,
> coupled with the link delay metric already gave us dynamic path computation
> requirements and the possibilities of oscillation and instability. We have
> chosen to charge ahead, without addressing those concerns already.
>
> Regards,
> Tony
>
> ___
> 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 mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints

[Tony Przygienda]

dyanmic queue lengths are still poor indicators of delay (in routing
network wide sense @ realistic routing flood/processing resolution),
nothing changed much since 1980 AFAIK

https://www.cs.yale.edu/homes/lans/readings/routing/mcquillan-darpa_routing-1980.pdf

delay/jitter can be talked about meaningfully if the context of the
topologies involved is controlled, pretty much stuff Lou's DETNET is
chewing

my 2c

-- tony



On Mon, Mar 1, 2021 at 9:22 PM Robert Raszuk  wrote:

> Hi Tony,
>
> Constructing arbitrary topologies with bw constrain is useful work. For
> example I want to create a topology without links of the capacity less then
> 1 Gbps. All cool. Of course if I have a case where two nodes have 10 L3
> 1Gbps links nicely doing ECMP I will not include those which may be a
> problem.
>
> However my observation is precisely related to your last sentence.
>
> Is this extension to be used with static or dynamic data ? If static all
> fine. But as William replied to me earlier link delay may be dynamically
> computed and may include queue wait time. That to me means something much
> different if Flex-Algo topologies will become dynamically adjustable. And I
> am not saying this is not great idea .. My interest here is just to
> understand the current scope.
>
> Thx,
> R.
>
>
>
>
>
> On Mon, Mar 1, 2021 at 7:42 PM Tony Li  wrote:
>
>>
>> Hi William, Gyan, Robert, Tony, et. al.,
>>
>> Please permit me to wax a bit philosophic here.
>>
>> William is exactly correct that the goal is not to make FlexAlgo deal
>> with reservations like RSVP does.  Without some kind of setup protocol or
>> global computation, that’s simply not possible. Moreover that’s not the
>> real problem that we’re out to solve.
>>
>> Reservations are just a first order approximation to a traffic flow in
>> any case. We characterize them as having a fixed constant bandwidth, but we
>> all know that that is far from the truth. Each flow is diurnal and
>> fractally bursty. Every user who ever clicks on a link creates bandwidth
>> demand and while the Law of Large Numbers helps us out with some averages
>> we all know that we have no good way of characterizing the traffic that
>> we’re trying to carry. Claiming that it is a single 12Gbps LSP is truly a
>> huge over simplification and a good step towards solving the real problem.
>>
>> So what is the real problem that we’re trying to solve?
>>
>> We are trying to not drop packets.
>>
>> Dropping packets is bad because it forces retransmissions and impacts
>> someone’s Internet experience. Dropping packets is our response to
>> congestion events. If we could manage to have a network that never
>> congested and always delivered packets without giant latency, all would be
>> good.
>>
>> To date, we have created traffic engineering mechanisms to help us steer
>> traffic so that we could delivery traffic without congesting. It has been a
>> means to an end. The mechanisms that we’ve created have a non-trivial
>> overhead and approximate our goals, but they do NOT preclude, anticipate,
>> or avoid congestion. They do not react when we have unexpected inputs. We
>> do extensive pre-computation to deal with even single failures and have no
>> serious mechanisms that handle multiple failures.
>>
>> Right now, FlexAlgo does nothing to help with bandwidth management.
>> Wiilliam et. al., are proposing some first steps, which are to be
>> encouraged. Much more will be needed, not to recreate legacy mechanisms but
>> because we should be striving for a more sophisticated, real-time approach
>> to bandwidth management and congestion avoidance.
>>
>> Regards,
>> Tony
>>
>>
>> On Mar 1, 2021, at 2:24 AM, William Britto A J <
>> bwilliam=40juniper@dmarc.ietf.org> wrote:
>>
>> Hi Gyan,
>>
>> This draft aims to provide the protocol constructs to define a
>> flex-algorithm which is suitable for sending high bandwidth traffic. 
>> Flex-Algo
>> is a very useful feature for network consolidation use-cases which requires
>> different metric-types for SPF. We are trying introduce the protocol
>> constructs to simplify the use of metric based on bandwidth via
>> Flex-Algo.
>>
>> This draft does not attempt to do bandwidth management nor reservation
>> like what RSVP does. For LDP based networks that use igp metric relative to
>> bandwidth, Flex-Algo provides an easy alternate.
>>
>> Thanks,
>> William
>>
>>
>> *From: *Gyan Mishra 
>> *Date: *Saturday, 27 February 2021 at 9:40 PM
>> *To: *Robert Raszuk 
>> *Cc: *DECRAENE Bruno IMT/OLN , Rajesh M <
>> mraj...@juniper.net>, Shraddha Hegde , William
>> Britto A J , lsr@ietf.org 
>> *Subject: *Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints
>> *[External Email. Be cautious of content]*
>>
>>
>> Hi William & Co-authors
>>
>> From first read of the draft it does appear your are trying to apply RSVP
>> TE PCALC path and reserve message link attributes constraints such as
>> concept of affinity bits to exclude low bandwidth or delay of individual
>> links 

Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints

[Tony Przygienda]

On Sat, Feb 27, 2021 at 2:56 AM Tony Li  wrote:

>
> Hi William & co-authors,
>
> Thank you for your contribution. It’s definitely interesting. As bandwidth
> management is one area where FlexAlgo lags legacy traffic engineering, this
> is definitely one small step in the right direction.
>
> But I have many comments…
>
> 1) I’ll start with the title: there is MUCH more here than bandwidth
> constraints. Perhaps this should be generalized somehow? Sorry, I don’t
> have a constructive suggestion.
>

there is good general, theoretical body of work here that shows what is
possible to compute (NP completeness, algorighms, heuristics). short search
yields e.g.

http://www.csun.edu/~ctoth/Handbook/chap31.pdf
https://engineering.purdue.edu/~ece624/Week-9.pdf

JSAC '96 Crowcroft is a starting point on additive/multiplicative, other
papers even eqarlier called that stuff max/additive, convex/concave (that
has to do with linear programming space properties) etc. I'm aware of work
going as far back as '92-'93 here.

Generally, one max/min & one additive is doable (you need additive to make
sure you don't start hamiltonian walks based on a constraint ;-)  Mixing up
addvitive & mix/min is a fairly poor idea unless one is happy with
heurestics that kind of "almost always work" and customer is not looking
for hard guarantees but "wishes that maybe granted".

>
>
> 2) Section 2: I concur that bandwidth is an important consideration in
> path computation. At a first reading, it is not at all clear to me that it
> is optimal to somehow transmogrify things into a metric. Why not simply
> deal with the bandwidth directly?  I did (eventually) realize that you did
> this because you want SPF to somehow select the path with the minimum
> product of (# links) * bandwidth.  I think you need to be explicit about
> this motivation and also mention that traditional SPF is not set up to deal
> with a floating point metric. Note that a bandwidth metric is STILL
> somewhat counter-intuitive to me, as I would expect that you’d mostly want
> to route things along the highest bandwidth paths, not the lowest ones.
> More motivation behind the bandwidth metric would be most welcome.
>

yeah, BW can be made a metric and work, IEEE encoding is simply a funky
number and different max/min/additive/multiplicative/any increasing
function (whether it has to be stricly monotonic is a more complex
discussion).  old but very solid stuff for that space

https://tools.ietf.org/html/rfc2676

based on even earlier


   [BP95]   J.-Y. Le Boudec and T. Przygienda.  A Route Pre-Computation
Algorithm for Integrated Services Networks.  Journal of
Network and Systems Management, 3(4), 1995.
   [GOW97]  R. Guerin, A. Orda, and D. Williams.  QoS Routing Mechanisms
and OSPF Extensions.  In Proceedings of the 2nd IEEE Global
Internet Mini-Conference, pages 1903-1908, Phoenix, AZ,
November 1997.

expired draft-ietf-qosr-framework-04.txt

 but given graph theory doesn't change things roughly still the same ;-)

There is also good body of work on something that quickly interacts with
that work, namely k-disjointness. e'thing looking for "fattest pipe" or
"shortest-widest" pretty quickly crams all traffic on the same links ;-)
unless somehting like RSVP-TE reserves & changes metric.

All those things have been implemented and worked in products so we know
they work, maybe flex stuff is just a framework now to unify it all a bit.

my only small nit on the draft is that the stepping is in practical terms
almost always exponewntial so you don't have to encode full value
necessarily. the rounding has to adjust to link size as well or is better
served as % value.

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

Re: [Lsr] Prefix Unreachable Announcement Use Cases

[Tony Przygienda]

Yeah, so to give e'one his due, negative disaggregation is Pascal's
brilliant brain-child, I bow to this. And I bow to his patience grinding me
down to convince me the complexity of it is by far outweighted by elegance
it brings to ugly failure repair. Then it took a lot of brow-beating until
e'one on RIFT understood that no, we will not get negative entry silicon
and hence need to remap negative to proper resolution as positive. Not the
simplest things but once you implemented it it turns out simpler than it
looks @ first

my 2c, I'll be watching here from a distance probably until it gelled a bit
more

-- tony

On Fri, Nov 20, 2020 at 12:45 PM Robert Raszuk  wrote:

> Hey Tony,
>
> >  people somehow implying a map of RIFT negative disaggregation in
> relation to this work
>
> I think those people just made a subtle point that considering IGP alone
> if you want to influence your data plane forwarding by advertising PUA in
> today's hardware you really need to install more specific blocks of the
> summary routes which PUA punched the hole in as sent by say one of the
> ABR's. Analogy made to RIFT was just limited to this data plane fragment
> only.
>
> And that comment was not to compare PUA to RIFT negative routing in any
> way. It was just to a) realize what could be required if such a use case
> continues and more importantly b) highlight that if we just use PUA in the
> control plane to for example invalidate BGP next hops or other overlay
> service routes the disaggregation piece does not apply.
>
> Cheers,
> R.
>
>
>
>
>
> On Fri, Nov 20, 2020 at 9:09 PM Tony Przygienda 
> wrote:
>
>>
>>
>> On Fri, Nov 20, 2020 at 6:27 AM Aijun Wang 
>> wrote:
>>
>>> Hi, Tony:
>>>
>>> Aijun Wang
>>> China Telecom
>>>
>>> On Nov 20, 2020, at 17:45, Tony Przygienda  wrote:
>>>
>>> 
>>> Yes, acknowledging the idea of negative disaggregation is inspired by
>>> RIFT work is fine (and normally, when inspired by an idea at least in
>>> research cycles it is considered basic courtesy to refer to the according
>>> source, something has been lost more and more in IETF over time I dare to
>>> observe which in itself reflects on the community IMO) but please do not
>>> try to compare the two beyond that.
>>>
>>> [WAJ] PUA has no relation with RIFT. I have not yet study what’s problem
>>> it encountered, but welcome the experts have such design experience to
>>> point out the pitfall that PUA can bypass.
>>>
>>>
>> aha, ok, I just chimed in because I saw people somehow implying a map of
>> RIFT negative disaggregation in relation to this work but if this is a
>> completely different mechanism than I just watch from the sidelines
>>
>> thanks
>>
>> -- tony
>>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Prefix Unreachable Announcement Use Cases

[Tony Przygienda]

On Fri, Nov 20, 2020 at 6:27 AM Aijun Wang 
wrote:

> Hi, Tony:
>
> Aijun Wang
> China Telecom
>
> On Nov 20, 2020, at 17:45, Tony Przygienda  wrote:
>
> 
> Yes, acknowledging the idea of negative disaggregation is inspired by RIFT
> work is fine (and normally, when inspired by an idea at least in research
> cycles it is considered basic courtesy to refer to the according source,
> something has been lost more and more in IETF over time I dare to observe
> which in itself reflects on the community IMO) but please do not try to
> compare the two beyond that.
>
> [WAJ] PUA has no relation with RIFT. I have not yet study what’s problem
> it encountered, but welcome the experts have such design experience to
> point out the pitfall that PUA can bypass.
>
>
aha, ok, I just chimed in because I saw people somehow implying a map of
RIFT negative disaggregation in relation to this work but if this is a
completely different mechanism than I just watch from the sidelines

thanks

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

Re: [Lsr] Prefix Unreachable Announcement Use Cases

[Tony Przygienda]

Yes, acknowledging the idea of negative disaggregation is inspired by RIFT
work is fine (and normally, when inspired by an idea at least in research
cycles it is considered basic courtesy to refer to the according source,
something has been lost more and more in IETF over time I dare to observe
which in itself reflects on the community IMO) but please do not try to
compare the two beyond that. Disaggregation works well on directed graphs
(lattices) or arguably if your addressing scheme is aligned with regular
topology (hypercube e.g.). it works in generic graphs in super special
cases only & it will be @ best a crutch that may under all the correct
circumstances have some utility but probably ends up hurting operationally
more than helping. The indication that "magic timer" is needed in the draft
should be first warning, all kind of seat-of-pants heuristics to dis- and
re-aggregate 2nd.  Just quickly flying through the draft I see lots of
logic problems already that will lead to vexing effects, e.g. indication of
missing neighbor will work in specific type of topologies, in others
varying by one link only may lead to stable blackholes.

my 2c

-- tony

On Sun, Nov 15, 2020 at 11:29 AM Jeff Tantsura 
wrote:

> As RIFT chair - I’d like to respond to Robert’ comment -  the example is
> rather  unfortunate, in RIFT disaggregation is conditional and well
> contained within its context, it doesn’t  affect overall scalability.
>
> Regards,
> Jeff
>
> On Nov 15, 2020, at 08:44, Robert Raszuk  wrote:
>
> 
> Hi Aijun,
>
> I would in fact only propose that the presented mechanism is narrowed down
> to invalidate BGP (service) routes - in fact their next hops.
>
> The reason being that the moment you make the solution generic, moreover
> the moment you want it to be used in RIB and data plane I am afraid you are
> running into similar (even if local) deaggregation mechanism like recently
> described in RIFT. That would kill all the scalability of advertising
> summary routes in the first place and I bet would face lots of opposition.
>
> Thx,
> R.
>
>
>> I would actually trim most use cases leaving just one - to signal remote
>> service node (ex: PE) going down in the presence of summary route being
>> advertised from remote area or pop.
>>
>>  [WAJ] Yes, this may be the most useful use case, but the PUA mechanism
> can also apply to other scenarios. We want to make it one general solution.
> ___
> 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 mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

[Tony Przygienda]

I read the draft since the longish thread triggered my interest. As Peter
said very thin ice walking with magic soft-state-timers for (to me)
entirely unclear benefit and lots of interesting questions completely
omitted like e.g. what will happen if a mix of old and new routers are in
the network.

RIFT works completely differently BTW (and I don't think we _also_ noticed
the problem, AFAIK RIFT is the first protocol that defined the concept of
at least negative disaggregation to deal with black-hole avoidance in
presence of summaries). RIFT defines precisely how negative disaggregation
state is transitively propagated (if necessary) and next-hop resolved via
recursive inheritance to provide black-hole and loop free routing in case
of links failures on IP fabrics. No soft-timers or undescribed magic there.
However, to do what RIFT is doing a sense of direction on the graph is
needed (this is relatively easy on semi-lattice RIFT supports but would
precondition uniform topological sorting on generic graphs, probably ending
up in RPL type of solutions [which still need a direction indicator on arc
to work and would take out a lot of links out of the topology possibly {but
Pascal is better to judge that}]).

-- tony

On Mon, Aug 24, 2020 at 11:11 AM Aijun Wang 
wrote:

> Hi, Gyan:
>
>
>
> Sorry for replying you so late.
>
> You are right about the summary address behavior, but the summary address
> is configured by manually, and if one of the specific prefix within this
> summary range is down, the black hole(route to this specific prefix) will
> be formed.  PUA mechanism just want to amend this.
>
> Glad to know Rift has also noticed such issues.  In OSPF/ISIS, such
> problem needs also be solved.
>
>
>
> If you are interested this topic, welcome to join us to the solution.
>
>
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> *From:* lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] *On Behalf Of *Gyan
> Mishra
> *Sent:* Thursday, August 6, 2020 4:44 PM
> *To:* Aijun Wang 
> *Cc:* Peter Psenak ; Robert Raszuk <
> rob...@raszuk.net>; Huzhibo ; Aijun Wang <
> wang...@chinatelecom.cn>; lsr ; Acee Lindem (acee) <
> a...@cisco.com>; Xiaoyaqun 
> *Subject:* Re: [Lsr] New Version Notification for
> draft-wang-lsr-prefix-unreachable-annoucement-03.txt
>
>
>
> Hi Aijun and authors
>
>
>
> I am catching up with this thread after reading through this draft.
>
>
>
> I understand the concept that we are trying to send a PUA advertisement
> which sounds similar to Rift Negative Disaggregation prefix now with a
>  null setting when a longer match component prefix that is part of a
> summary range is down to detect prefix down conditions with longer match
> component prefixes that are part of a summary.
>
>
>
> Basically how summarization works with both OSPF and ISIS is that at
> minimum a single longer match within the defined IA summary range must
> exist for the IA summary to be sent.  So the summary is sent conditionally
> similar to a BGP conditional advertisement or even a ospf default originate
> which requires a default in the RIB to exist before the advertisement is
> sent.  A good example of non conditional analogy with BGP if you have a
> null0 static for a summary for an exact match BGP advertisement the prefix
> is always advertised no matter what even if no component prefixes exist.
> This can result in black hole routing. BGP has conditional feature to
> conditionally advertisement based on existence of a route advertisement of
> downstream neighbor in the BGP RIB.  So with ospf and Isis the summary is
> in fact conditional similar to a BGP conditional advertisement and in the
> example given in the draft in section 3.1 when node T2 is down and pt2
> becomes unreachable and let’s say that prefix is 1.1.1.1/32 and the
> summary is 1.1.1.0/30 and no other component prefix exists within the
> summary range the prefix will not get adversed.  So there will not be any
> black hole.
>
>
>
> The summary represents all prefixes within the range that would be
> suppressed with the summary when advertised into the backbone area.
> However only at a minimum one prefix must exist in the range for the
> summary to be generated.  That is done by design as the summary represents
> all prefixes within the range.  So let’s say there are a 100 prefixes and
> let’s say a few devices are down and so now only 5 prefixes exist within
> the range.  By design it is OK for router to generate the summary for the 5
> prefixes it is representing and that will not cause any routing loop or
> black hole.
>
>
>
>
>
> I am trying to understand wage gap exists and what we are trying to solve
> related to summarization in the context of IPv6.  Both IPv4 and IPV6
> summarization operates the similarly as far as the requirement of at
> minimum a single component route within the summary range must exist  as a
> condition to be present in the RIB before the summary can be advertised.
>
>
>
> Kind Regards
>
>
>
> Gyan
>
>
>
> On 

Re: [Lsr] WG adoption call for draft-przygienda-lsr-flood-reflection-01

[Tony Przygienda]

thanks Les, albeit the authors got already lots of helpful comments from
you and Peter over beers in a bar I hope for further discussions.
Especially your opinion on

a) special case where FR is 1-hop away from the leafs should not need a
tunnel. I think most people would agree it's a good thing
b) some example/better text on the computation as John poked at
c) to give no favorite treatment to either data-tunnels or no-data-tunnels
shortcutting since both of those variants have its own camp of non-likers
;-) ; both shall be equally documented over time I think.
d) some people pine for FR hierarchy which would have the advantage of
being "future-proof" while I fear the rathole involved when looking @ my
RR-hierarchy-deployment-scar-tissues. Maybe we can cook something up that
buys us an option to add it in the future in backwards compatible fashion
without doing work now. I didn't think through the issue though.

Ultimately, and in the danger of sounding a bit like a broken record, your
view on hierarchy is IMO bitsy sideways. Customer would do like a generic,
summarizing, self-building, non-looping hierarchy (i.e. not forced to be
star-like) but as I think became obvious, only realistic distributed option
without connection setup and crank-back is unfortunately a rather rigidly
configured star without sideways transits (or high instability in hierarchy
if arbitrary edges are introduced and hierarchy is 'renegotiated'). And
it's not even protocol mechanics, it's fairly grounded in graph theory (if
you summarize, i.e. information flow is only partial). Another way to think
about it that Clos is actually nothing but such a
star-no-horizontal-transit networks (well, to an extent, this discussion
leads into ABR alternate behavior and shortcuts we lived and was "solved"
for 2 levels only as well) and hence automatically building hierarchy from
the defined center out is safe (just as RPL [which forces basically a CLOS
and would be possibly an option for ISIS but don't forget that RPL to work
needs arc-direction packet format change to prevent looping so that would
need looking at] or RIFT [which largely assumes CLOS with some variants so
is basically only good in discovering automatically a constraint it already
posed ;-) ]).  We may evolve over time to all networks topologies being
Banyan-variants exclusively (well, where locality is given, we already do)
but I consider that unlikely in generic WANs hence sprung the need for this
draft.

thanks

--- tony

On Sun, Jun 21, 2020 at 7:37 AM Les Ginsberg (ginsberg)  wrote:

> I support WG adoption of
> https://datatracker.ietf.org/doc/draft-przygienda-lsr-flood-reflection ..
>
>
>
> (I also support the WG adoption of
> https://datatracker.ietf.org/doc/draft-li-lsr-isis-area-proxy/ )
>
>
>
> I believe the problem space addressed by these two drafts warrants
> attention.
>
>
>
> I am not yet overly enthused about approaches which promote
> non-hierarchical network architectures. But it seems clear that there is
> interest in deploying non-hierarchical solutions and both drafts present
> solutions
>
> which merit further evaluation.
>
>
>
> The easy road for the WG to take would be to simply allow both drafts to
> proceed to Experimental RFCs, but I hope we are able to do more than this.
> Multiple solutions place undesirable burdens on vendors and providers alike.
>
>
>
> To the extent they feel comfortable, I encourage folks who wish to deploy
> such solutions to share their requirements and discuss how each of the
> solutions
>
> address their requirements/fall short of addressing their requirements. I
> think this would help the WG discover better ways forward.
>
>
>
>Les
>
>
>
>
>
> > -Original Message-
>
> > From: Lsr  On Behalf Of Christian Hopps
>
> > Sent: Wednesday, June 10, 2020 12:29 PM
>
> > To: lsr@ietf.org
>
> > Cc: lsr-cha...@ietf.org; lsr-...@ietf.org; Christian Hopps
>
> > 
>
> > Subject: [Lsr] WG adoption call for
> draft-przygienda-lsr-flood-reflection-01
>
> >
>
> > This begins a 2 week WG adoption call for the following draft:
>
> >
>
> >   https://datatracker.ietf.org/doc/draft-przygienda-lsr-flood-reflection
>
> >
>
> > The draft would be adopted on the Experimental track.
>
> >
>
> > Please indicate your support or objection by June 24, 2020.
>
> >
>
> > Authors, please respond to the list indicating whether you are aware of
> any
>
> > IPR that applies to this draft.
>
> >
>
> > Thanks,
>
> > Chris and Acee.
>
> > ___
>
> > 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 mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG adoption call for draft-przygienda-lsr-flood-reflection-01

[Tony Przygienda]

On Fri, Jun 19, 2020 at 12:43 PM John Scudder  wrote:

> Hi All,
>
> I just did a full read-through of -01. Without denigrating any other
> solutions, I support adoption of this one.
>
> I do have a few comments and nits, below.
>
> - Paragraph 2 of section 9 is unclear, IMO; I hope this can be improved in
> the next version. It reads exactly like a protocol expert writing for
> another protocol expert; as we know, a good spec has to be written so that
> as little as possible is left to the creativity of the implementor. This
> paragraph seems to require creativity.
>

yepp, would benefit from an example. Nothing speaks against that.


>
> - Please decide whether to do the right thing, and call the protocol
> “IS-IS”, or the wrong thing, and call it “ISIS”. Whatever the decision,
> standardize on that one instead of randomly adding and dropping hyphens.
>

no opinion but Les will keep me honest ;-)


>
> - Section 8 mentions “route reflector clients”, probably what was meant
> was “flood reflector clients”.
>

oops ;-) Sincerest form of flattery ;-)

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

Re: [Lsr] WG adoption call for draft-przygienda-lsr-flood-reflection-01

[Tony Przygienda]

support as co-author. not aware of any additional IPR beside the one
disclosed on the tracker already

thx

== t

On Wed, Jun 10, 2020 at 12:29 PM Christian Hopps  wrote:

> This begins a 2 week WG adoption call for the following draft:
>
>   https://datatracker.ietf.org/doc/draft-przygienda-lsr-flood-reflection
>
> The draft would be adopted on the Experimental track.
>
> Please indicate your support or objection by June 24, 2020.
>
> Authors, please respond to the list indicating whether you are aware of
> any IPR that applies to this draft.
>
> Thanks,
> Chris and Acee.
> ___
> 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 for draft-li-lsr-isis-area-proxy-06

[Tony Przygienda]

yepp, it's one philosophy and design point which I'm  quite well aware off
;-) and it's feasible of course that instead of a signalling protocol or
even SR the controller provisions all paths via e.g. PCE of course if one
can live with the delay and implications of large scale failures. If we
rely on controller fixing LPM as well under failures then really, who needs
IGPs anymore anyway except for bunch of loopbacks and SPF for the
controller to do all the FIB work and hence discussions like high
hierarchies or anisotropic routing are largely superfluous me thinks ;-)

-- tony




On Mon, Jun 15, 2020 at 11:01 AM  wrote:

>
>
> On Jun 15, 2020, at 10:56 AM, Tony Przygienda  wrote:
>
> PNNI had transit areas in hierarchy working but the trick was connection
> setup cranck-back. Such a thing would work for RSVP or any of the stateful
> connection setups but alas, this is not fashionable right now.
> Unfortunately, generic hierarchy with reachability summarization ends up
> with very sub-optimal routing or black-holing on aggregates since we cannot
> "back-off" generic LPM packet forwarding when we realize we're @ a dead end
> due to aggregation. To prevent bi-furcation of topology or transit
> horizontals several solutions exist, one of which (configure hierarchy
> statically everywhere) the current draft has in now but alas, the topology
> is star of stars (you can actually see CLOS conceptually as something like
> this as well ;-)
>
>
>
> Hi Tony,
>
> The modern solution of choice is to relegate all of the traffic
> engineering to an out-of-band controller that no longer operates in
> real-time and has the scale to span levels and areas.
>
> Tony
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG adoption call for draft-li-lsr-isis-area-proxy-06

[Tony Przygienda]

On Mon, Jun 15, 2020 at 10:37 AM  wrote:

>
> Hi Robert,
>
>
> > > It’s very clear that this is inadequate.
> >
> > Doesn't this really depend how you architect multiple levels ? Sure you
> have some physical topology - but it seems to me that the trick is in
> properly laying out levels on top of them and between them.
>
>
> The very pragmatic viewpoint is that network architects will construct the
> physical topology that best suits their traffic pattern and that trying to
> contort that physical topology into some kind of hierarchy will create
> additional (and perhaps significant) cost.  People don’t want to do that.
> They want scalable networks that match their physical topology.  For this
> to work, our hierarchical abstractions need to be independent of the
> topology and that forces us into having transit areas.
>
>
>
PNNI had transit areas in hierarchy working but the trick was connection
setup cranck-back. Such a thing would work for RSVP or any of the stateful
connection setups but alas, this is not fashionable right now.
Unfortunately, generic hierarchy with reachability summarization ends up
with very sub-optimal routing or black-holing on aggregates since we cannot
"back-off" generic LPM packet forwarding when we realize we're @ a dead end
due to aggregation. To prevent bi-furcation of topology or transit
horizontals several solutions exist, one of which (configure hierarchy
statically everywhere) the current draft has in now but alas, the topology
is star of stars (you can actually see CLOS conceptually as something like
this as well ;-)

my meta 2c

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

Re: [Lsr] WG adoption call for draft-przygienda-lsr-flood-reflection-01

[Tony Przygienda]

JNPR holds relevant IPR on the draft. We are in the process of disclosing
it ASAP

thanks

-- tony

On Wed, Jun 10, 2020 at 12:29 PM Christian Hopps  wrote:

> This begins a 2 week WG adoption call for the following draft:
>
>   https://datatracker.ietf.org/doc/draft-przygienda-lsr-flood-reflection
>
> The draft would be adopted on the Experimental track.
>
> Please indicate your support or objection by June 24, 2020.
>
> Authors, please respond to the list indicating whether you are aware of
> any IPR that applies to this draft.
>
> Thanks,
> Chris and Acee.
> ___
> 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 for draft-przygienda-lsr-flood-reflection-01

[Tony Przygienda]

Christian, thanks much for that. As there were already two different
threads over last months where a good amount of people/companies expressed
their support for the draft to progress as WG item, I don't expect to need
to pester them again but maybe more will chime in here ...

thanks

-- tony

On Wed, Jun 10, 2020 at 12:29 PM Christian Hopps  wrote:

> This begins a 2 week WG adoption call for the following draft:
>
>   https://datatracker.ietf.org/doc/draft-przygienda-lsr-flood-reflection
>
> The draft would be adopted on the Experimental track.
>
> Please indicate your support or objection by June 24, 2020.
>
> Authors, please respond to the list indicating whether you are aware of
> any IPR that applies to this draft.
>
> Thanks,
> Chris and Acee.
> ___
> 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] Thoughts on the area proxy and flood reflector drafts.

[Tony Przygienda]

On Wed, Jun 10, 2020 at 11:04 AM Christian Hopps  wrote:

>
> ...
>
>
> > I also suggest to look up why in PNNI we ended up introducing a special
> "L1 equivalent" computation to the peer group leader to validate that it
> was actually reachable for correct operation (especially hierarchy
> negotiations) on peer group egresses which in a sense was like but worse
> than virtual links operationally IME. I was suggesting then to keep an SVC
> from PGL to every border for that reason since a partition of a PGL led
> otherwise to the peer groups looking like the same thing for a while with
> highly undesirable operational effects (my memory doesn't reach that far
> really but we had at least discussions then to implement proprietary
> solution in Fore to have such SVCs for more stable deployments). In more
> abstract terms, flooding is extremely good to quickly "route around
> failures" when e'ones state is completely decentralized but is simply not a
> great mechanism if you have to talk to an entity couple hops away in a
> stable manner, especially if this entity hold state you need for correct
> operation when talking to your peers.
>
>
So we understand L2 tunnels from leaf to FR are "real" tunnels and have
nothing to do with virtual links.

As to the data plane, nope, you don't end up with any "virtual links" I can
recognize unless you choose to call redistribution "virtual links" as well,
maybe look @ the presentation again.

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

Re: [Lsr] Thoughts on the area proxy and flood reflector drafts.

[Tony Przygienda]

On Wed, Jun 10, 2020 at 10:29 AM Christian Hopps  wrote:

>
>
>
> >
> >
> > Hmmm, AFAIR the implementation of OSPF virtual links was having no
> tunnel at all (and that's how I remember I implemented it then). I cite
>
> Correct, that's why I'm suggesting that any solution without tunnels is
> going to reduce to OSPF virtual links.
>
>
Good to hear you implemented virtual w/o tunnels.

But then FR is not a solution "without tunnels" so the whole logic of "it's
not the same hence it's the same for me" escapes me completely now and I
let it rest.


>
>
> If it seems like I'm "carrying the torch" it's b/c as I understand the
> drafts currently, the area proxy seems like a much simpler solution (KISS),
> and I haven't yet been able to figure out what the benefits of using the
> flood reflector method instead would bring. If those benefits were more
> obvious I'd probably like it too. :)
>
>
looking @ the amount of protocol extensions in terms of TLVs, flooding
scoping, configuration etc necessary in either case and involved
fork-lifting, new-constructs necessary in operational tooling I dare say
you hold a somewhat unique "opinion" IMO ...

As to simplicity you see and since your mental model seems fixed around
virtual links concept, I also suggest to look up why in PNNI we ended up
introducing a special "L1 equivalent" computation to the peer group leader
to validate that it was actually reachable for correct operation
(especially hierarchy negotiations) on peer group egresses which in a sense
was like but worse than virtual links operationally IME. I was suggesting
then to keep an SVC from PGL to every border for that reason since a
partition of a PGL led otherwise to the peer groups looking like the same
thing for a while with highly undesirable operational effects (my memory
doesn't reach that far really but we had at least discussions then to
implement proprietary solution in Fore to have such SVCs for more stable
deployments). In more abstract terms, flooding is extremely good to quickly
"route around failures" when e'ones state is completely decentralized but
is simply not a great mechanism if you have to talk to an entity couple
hops away in a stable manner, especially if this entity hold state you need
for correct operation when talking to your peers.

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

Re: [Lsr] Thoughts on the area proxy and flood reflector drafts.

[Tony Przygienda]

ok, let's not drag vendor specific stuff in. I shouldn't have brought it up
I guess, outside the scope of IETF threads ...

thanks

--- tony

On Wed, Jun 10, 2020 at 10:23 AM  wrote:

>
> Tony,
>
>
> On Jun 10, 2020, at 9:40 AM, Tony Przygienda  wrote:
>
> You do seem to be carrying as WG member a hot torch for area-proxy for
> some reason, that's fine with me, frankly, I had extensive discussions with
> customers when DriveNet was being proposed to them (which AFAIS is
> basically area-proxy) and the solution is intriguing but it did not cut
> lots of requirements of large customers and there are a lot of unresolved
> issues operationally with an approach like that.
>
>
>
> Drivenets, as I understand it, is an attempt to physically deaggregate a
> multi-chassis fabric down to the chip level using a proprietary
> chip-set-specific cell based interlink protocol. However, it retains a
> single control plane and as such looks like a single IS-IS system.  It has
> no relationship whatsoever to area proxy.
>
> Regards,
> Tony
>
>
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr