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

[Robert Raszuk]

Hi Acee and WG,

> Those questioning the flag should have been paying attention
> when RFC 9513 and RFC 9352 were being discussed.

No.

#1 Those two RFCs are about segment routing
extensions. draft-chen-lsr-anycast-flag is not.

#2 In those two RFCs it is very clear that anycast flag reflects only the
local configuration of the prefix (locator). Please observe that the draft
under discussion fails to indicate who and when should set this flag.
Quoted RFCs do. Number of questions surfaced if ABRs or ASBRs should be
setting such flag. Should summaries have such flag ? Etc 

#3 In those two RFCs there is very good justification why this flag can be
useful .. to check if anycast prefixes are advertised with the same SIDs.
To me this is sufficient justification and perhaps a good reason why no one
had objections to RFC9513 and RFC9352.

Neither #1, nor #2 nor #3 apply to the subject draft for OSPFv2. While #2
hopefully can be easily added #1 and #3 are fundamentally different. So at
least draft-chen-lsr-anycast-flag should provide a justification being as
good as #3.

So justification to add it here just because OSPFv3 or ISIS have it is not
enough.

Kind regards,
Robert


On Sat, Mar 23, 2024 at 10:38 PM Acee Lindem  wrote:

> Speaking as WG member:
>
> I support working group adoption.
>
> It would be good to add:
>
>1. In the introduction, informational references to OSPFv3 [RFC9513]
> and ISIS [9352].
>2. The example use cases for the prefix Anycast flag we've been
> discussing.
>
> Note that we already have this flag for OSPFv3 and IS-IS and
> implementations are making use of it. That ship has left the dock
> and now is the time to question whether the use cases could be solved in a
> different manner. Those questioning the flag should
> have been paying attention when RFC 9513 and RFC 9352 were being
> discussed.
>
> Thanks,
> Acee
>
>
>
> > On Mar 19, 2024, at 2:43 PM, Acee Lindem  wrote:
> >
> >
> > This starts the Working Group adoption call for
> draft-chen-lsr-anycast-flag. This is a simple OSPFv2 maintenance draft
> adding an Anycast flag for IPv4 prefixes to align with IS-IS and OSPFv3.
> >
> > Please send your support or objection to this list before April 6th,
> 2024.
> >
> > 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] Working Group Adoption Poll for "Updates to Anycast Property advertisement for OSPFv2" - draft-chen-lsr-anycast-flag-06

[Robert Raszuk]

Hi Les,

> I fail to understand why you and others on this thread seem to require a
definition for “anycast”.

Asking for definition of "anycast" has a different reason ...

Which is to validate all network conditions which may result in having the
same address advertised by more then one node. Being IGP area node, ABR
(summary injected via two ABRs is an anycast), ASBRs (redistributed 3017
routes to IGP + LDP by two or more ASBRs is an anycast etc).

That is why I think it is important to a bit scope the meaning of the
proposed herein flag.

Or at least to say that this flag applies only to manually configured
addresses on more then one node.

Many thx,
R.



On Fri, Mar 22, 2024 at 5:48 PM Les Ginsberg (ginsberg) 
wrote:

> Robert –
>
>
>
> For the most part, I think it is most appropriate if the authors of the
> draft respond to questions – and I think Ketan has been doing his best to
> do so.
>
>
>
> Since you have specifically targeted your questions to me, I will respond
> with a few points.
>
>
>
> I fail to understand why you and others on this thread seem to require a
> definition for “anycast”. It is as if you don’t understand what the term
> means – which is quite surprising since you have many years in the
> networking field. This draft (nor other IGP drafts which have defined the
> equivalent functionality) is not inventing a new definition of “anycast”.
> The draft is just defining a way to mark a given prefix advertisement as
> being an anycast address.
>
>
>
> Marking an address is an indication of the operator’s intent i.e., it is
> saying that it is possible that this address will be associated with
> multiple nodes.
>
> It is true that such an intent can also be derived by examining the LSDB
> and seeing if multiple nodes are originating the same advertisement, but
> that logic does not detect the case where an address is intended to be
> anycast, but at a given moment only one node is originating the
> advertisement – possibly because the operator has not yet brought up other
> nodes yet – or some nodes are temporarily down – or configuration of the
> network is in progress.
>
>
>
> As to use case, one example (which I think Ketan has already mentioned) is
> when calculating repair paths. You would not want to use an anycast address
> for a node on the repair path because forwarding of packets to that address
> could be sent towards multiple nodes.
>
>
>
>Les
>
>
>
>
>
> *From:* Robert Raszuk 
> *Sent:* Friday, March 22, 2024 7:33 AM
> *To:* Les Ginsberg (ginsberg) 
> *Cc:* Acee Lindem ; 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
>
>
>
> Hi Les,
>
>
>
> > Knowledge of whether a given prefix is Anycast has proven useful in
> existing deployments
>
>
>
> Would you be so kind and enlighten us with a few practical examples in
> which you exhibit practical usefulness of this flag at the IGP level?
>
>
>
> More basic question - is this set by CLI or is there a special protocol
> algorithm which set such flag ? If it is the latter, can you explain it ?
>
>
>
> So if suddenly one src of such anycast goes down rest of the area still
> thinks it is anycast ?
>
>
>
> From the BGP side of things indeed for basic IPv4/IPv6 concept of ghost
> loopbacks were used as next hops which indeed were advertised as anycast
> addresses. Is that one example in which you would hope that BGP prefers a
> path if the next hop is an anycast address as told by IGP ? And you push
> that "automation" to operators to prefer such paths by manual configuration
> ?
>
>
>
> And to second Bruno's question - what is IGP's definition of an anycast
> address ?
>
>
>
> Many thx,
>
> Robert
>
>
>
>
>
> On Thu, Mar 21, 2024 at 7:47 PM Les Ginsberg (ginsberg)  40cisco@dmarc.ietf.org> wrote:
>
> I support adoption of this draft.
> Knowledge of whether a given prefix is Anycast has proven useful in
> existing deployments - closing this gap for OSPFv2 is a good thing to do.
>
> One editorial comment. The introduction (and abstract) states:
>
> " Both SR-MPLS prefix-SID and IPv4 prefix may be configured as anycast
>and as such the same value can be advertised by multiple routers."
>
> But there is no further discussion of prefix-SID in the draft.
> I think mention of the prefix-SID should be removed.
>
> Les
>
>
> > -Original Message-
> > From: Lsr  On Behalf Of Acee Lindem
> > Sent: Tuesday, March 19, 2024 11:43 AM
> &g

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

[Robert Raszuk]

Hi Les,

> Knowledge of whether a given prefix is Anycast has proven useful in
existing deployments

Would you be so kind and enlighten us with a few practical examples in
which you exhibit practical usefulness of this flag at the IGP level?

More basic question - is this set by CLI or is there a special protocol
algorithm which set such flag ? If it is the latter, can you explain it ?

So if suddenly one src of such anycast goes down rest of the area still
thinks it is anycast ?

>From the BGP side of things indeed for basic IPv4/IPv6 concept of ghost
loopbacks were used as next hops which indeed were advertised as anycast
addresses. Is that one example in which you would hope that BGP prefers a
path if the next hop is an anycast address as told by IGP ? And you push
that "automation" to operators to prefer such paths by manual configuration
?

And to second Bruno's question - what is IGP's definition of an anycast
address ?

Many thx,
Robert


On Thu, Mar 21, 2024 at 7:47 PM Les Ginsberg (ginsberg)  wrote:

> I support adoption of this draft.
> Knowledge of whether a given prefix is Anycast has proven useful in
> existing deployments - closing this gap for OSPFv2 is a good thing to do.
>
> One editorial comment. The introduction (and abstract) states:
>
> " Both SR-MPLS prefix-SID and IPv4 prefix may be configured as anycast
>and as such the same value can be advertised by multiple routers."
>
> But there is no further discussion of prefix-SID in the draft.
> I think mention of the prefix-SID should be removed.
>
> Les
>
>
> > -Original Message-
> > From: Lsr  On Behalf Of Acee Lindem
> > Sent: Tuesday, March 19, 2024 11: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 for IPv4
> > prefixes to align with IS-IS and OSPFv3.
> >
> > Please send your support or objection to this list before April 6th,
> 2024.
> >
> > 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

Re: [Lsr] I-D Action: draft-ietf-lsr-igp-flex-algo-reverse-affinity-02.txt

[Robert Raszuk]

Peter,

Ok I think what you are proposing is pretty granular and that is fine. We
may still disagree if link should be used at all if there are errors on
this link in *ANY* direction.

So my suggestion here is to have that support build in as well in the nodes
computing the topology and not always require to flood REVERSE colors.

In other words a color GRAY can be injected by node B irrespective if
errors appear in TX or RX direction of the link. And that GRAY color should
remove the link from computation bidirectionally.

In the same time sure for those who want to remove given link only in one
direction your proposal provides tool for that.

> In our example it is used for Rx errors only. Tx errors on B are not
relevant for A->B traffic.

+
> I want to avoid using the link even in the case of a minimal error rate.

Well typically packet errors are expressed as counters not rates. Only
active measurements express quality of the links as rates.

If this is just a counter then the moment it crosses threshold there is no
return till operator or script resets this counter :)  Not very OPS
friendly 

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

Re: [Lsr] I-D Action: draft-ietf-lsr-igp-flex-algo-reverse-affinity-02.txt

[Robert Raszuk]

Hey Peter,

> Why do we need the notion of "reverse direction" to be any different then
> the notion of forward direction from node B to A on a link ?
>
> For a link A->B, we typically use attributes in the direction A->B. .e.g.
> link delay, link affinities, etc.
>
> The reason why we want to be able to use reverse affinities is that for
> some cases, it is only B that knows about certain properties that relates
> to traffic A->B. For example only B can detect that there is a high rate of
> errors on that link for incoming traffic.
>

That is clear from the draft and I think that extension of computation is
useful. I am only asking about the flooding granularity.

Can't we just use the reverse metrics locally by computing node without
> flooding
> anything new ?
>
> no, because we want to use the metric in the forwarding direction, but be
> able to exclude link if the errors are detected on the other side of the
> link in the incoming direction.
>

What I meant to say was not really not to flood anything .. but not to
flood any "reverse" colors. Meaning if node B notices errors coming on link
to node A he floods it as some color.

Then node running flex-algo can treat such flooding as reverse locally if
instructed so.

Example: Node B sees 1000 RX CRC errors on link to A. it checks O it
crossed threshold 999 so I flood it as color GRAY. Why there is need to
have this flooded with notion of "reverse" that is my question ?

Does the "REVERSE" really means that those are RX errors as opposed to TX
errors ?

I think you want to differentiate the link direction and say if I see RX
errors this link should be removed from computation A --> B, yet in the
same time I there is no TX errors it would be fine to keep that link in
data direction B --> A  Is this the case ?

Would it be better to just declare link as crap bidirectionally ? :)

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

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

[Robert Raszuk]

Hi Ketan,

That is my main point. So we define something which is only local to the
area.

If this information will turn out to be very useful I am sure there is
going to be someone proposing to leak it :)  Remember the UPA discussions ?

If so my real question is - should such information belong in IGP ? Or
maybe rather in DROID (
https://datatracker.ietf.org/doc/html/draft-li-lsr-droid) ?

Honestly I am still a bit struggling to understand the need for it. And the
draft is not very helpful ...



*   The prefix may be configured as anycast and it is useful for other
 routers to know that the advertisement is for an anycast identifier.*

or







*2.  Use-case   In the absence of the N-flag, the node specific prefixes
need to be   identified from the anycast prefixs.  A prefix that is
advertised by   a single node and without an AC-flag MUST be considered
node   specific.*

Especially the "use-case" looks to me like copy and paste error :)

Thx,
Robert


On Thu, Mar 21, 2024 at 5:44 PM Ketan Talaulikar 
wrote:

> Hi Robert,
>
> Summarization/aggregation does result in loss of individual prefixes'
> attributes.
>
> The draft does not intend to specify procedures for propagation of anycast
> attribute of individual prefixes to the summary since that is not something
> that is going to be robust.
>
> Thanks,
> Ketan
>
>
> On Thu, Mar 21, 2024 at 10:02 PM Robert Raszuk  wrote:
>
>> Hi,
>>
>> Isn't this knowledge gone outside of the local area when ABR does
>> summarization ? If so, is this really practically useful ?
>>
>> Thx,
>> R.
>>
>>
>> On Thu, Mar 21, 2024 at 4:19 PM Ketan Talaulikar 
>> wrote:
>>
>>> Hi Bruno,
>>>
>>> Please check inline below with KT2 for responses.
>>>
>>>
>>> On Thu, Mar 21, 2024 at 7:16 PM  wrote:
>>>
>>>> Hi Ketan,
>>>>
>>>>
>>>>
>>>> Thanks for your quick reply.
>>>>
>>>> Please see inline [Bruno]
>>>>
>>>>
>>>>
>>>> *From:* Ketan Talaulikar 
>>>> *Sent:* Thursday, March 21, 2024 2:18 PM
>>>> *To:* DECRAENE Bruno INNOV/NET 
>>>> *Cc:* Acee Lindem ; lsr ;
>>>> draft-chen-lsr-anycast-f...@ietf.org; Dongjie (Jimmy) <
>>>> jie.d...@huawei.com>; Tony Przygienda 
>>>> *Subject:* Re: [Lsr] Working Group Adoption Poll for "Updates to
>>>> Anycast Property advertisement for OSPFv2" - draft-chen-lsr-anycast-flag-06
>>>>
>>>>
>>>>
>>>> Hi Bruno,
>>>>
>>>>
>>>>
>>>> Thanks for your feedback. Please check inline below for responses.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Thu, Mar 21, 2024 at 4:12 PM  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.
>>>>
>>>>
>>>>
>>>> KT> Whether a prefix is anycast or not is configured by the operator.
>>>> This spec does not require implementations to detect that a prefix that it
>>>> is originating is also being originated from another node and hence may be
>>>> an anycast advertisement. We can clarify the same in the document.
>>>>
>>>>
>>>>
>>>> [Bruno] As an operator, why would I configure this? What for? What are
>>>> the possible drawbacks? (i.e., can this be configured on all prefixes
>>>> regardless of their anycast status)
>>>>
>>>
>>> KT2> If anycast property is configured on all prefixes, then it is an
>>> indication that none of those prefixes resolve to a unique node. That has
>>> consequences in terms of usage. E.g., taking the TI-LFA repair path
>>> use-case, we won't find the Node SID to be used to form the repair
>>> segment-list.
>>>
>&g

Re: [Lsr] I-D Action: draft-ietf-lsr-igp-flex-algo-reverse-affinity-02.txt

[Robert Raszuk]

Hi,

> When Flex-Algorithm calculation processes the link A to B, it may look at
> the 'colors' of the link in the reverse direction, e.g., link B to A.
This would
> allow the operator to exclude such link from the Flex-Algorithm topology.

Why do we need the notion of "reverse direction" to be any different then
the notion of forward direction from node B to A on a link ?

Can't we just use the reverse metrics locally by computing node without
flooding
anything new ?

> An operator may measure the rate of such input errors and set certain
'color' on a link
> locally on node B when the input error rate crosses a certain threshold.

IMO the draft should go into more detail or at least provide a pointer to
another document with description how to protect from continued churn in
propagating those colors when oscillate and go below and above a set
threshold many times per second.

Then aside from reducing the propagation frequency local protection from
continued SPF runs should also be mentioned. I guess you assume that this
is in place anyway.

> The IS-IS Flexible Algorithm Exclude Reverse Admin Group (FAERAG)

I think "FAERAG" is very hard to say. How about just "ERAG" as an acronym ?

Thx,
R.


On Mon, Mar 18, 2024 at 9:12 AM  wrote:

> Internet-Draft draft-ietf-lsr-igp-flex-algo-reverse-affinity-02.txt is now
> available. It is a work item of the Link State Routing (LSR) WG of the
> IETF.
>
>Title:   IGP Flexible Algorithms Reverse Affinity Constraint
>Authors: Peter Psenak
> Jakub Horn
> Amit Dhamija
>Name:draft-ietf-lsr-igp-flex-algo-reverse-affinity-02.txt
>Pages:   9
>Dates:   2024-03-18
>
> Abstract:
>
>An IGP Flexible Algorithm (Flex-Algorithm) allows IGPs to compute
>constraint-based paths.
>
>This document extends IGP Flex-Algorithm with additional constraints.
>
> The IETF datatracker status page for this Internet-Draft is:
>
> https://datatracker.ietf.org/doc/draft-ietf-lsr-igp-flex-algo-reverse-affinity/
>
> There is also an HTMLized version available at:
>
> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-igp-flex-algo-reverse-affinity-02
>
> A diff from the previous version is available at:
>
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-lsr-igp-flex-algo-reverse-affinity-02
>
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
>
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Robert Raszuk]

Hi,

Isn't this knowledge gone outside of the local area when ABR does
summarization ? If so, is this really practically useful ?

Thx,
R.


On Thu, Mar 21, 2024 at 4:19 PM Ketan Talaulikar 
wrote:

> Hi Bruno,
>
> Please check inline below with KT2 for responses.
>
>
> On Thu, Mar 21, 2024 at 7:16 PM  wrote:
>
>> Hi Ketan,
>>
>>
>>
>> Thanks for your quick reply.
>>
>> Please see inline [Bruno]
>>
>>
>>
>> *From:* Ketan Talaulikar 
>> *Sent:* Thursday, March 21, 2024 2:18 PM
>> *To:* DECRAENE Bruno INNOV/NET 
>> *Cc:* Acee Lindem ; lsr ;
>> draft-chen-lsr-anycast-f...@ietf.org; Dongjie (Jimmy) <
>> jie.d...@huawei.com>; Tony Przygienda 
>> *Subject:* Re: [Lsr] Working Group Adoption Poll for "Updates to Anycast
>> Property advertisement for OSPFv2" - draft-chen-lsr-anycast-flag-06
>>
>>
>>
>> Hi Bruno,
>>
>>
>>
>> Thanks for your feedback. Please check inline below for responses.
>>
>>
>>
>>
>>
>> On Thu, Mar 21, 2024 at 4:12 PM  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.
>>
>>
>>
>> KT> Whether a prefix is anycast or not is configured by the operator.
>> This spec does not require implementations to detect that a prefix that it
>> is originating is also being originated from another node and hence may be
>> an anycast advertisement. We can clarify the same in the document.
>>
>>
>>
>> [Bruno] As an operator, why would I configure this? What for? What are
>> the possible drawbacks? (i.e., can this be configured on all prefixes
>> regardless of their anycast status)
>>
>
> KT2> If anycast property is configured on all prefixes, then it is an
> indication that none of those prefixes resolve to a unique node. That has
> consequences in terms of usage. E.g., taking the TI-LFA repair path
> use-case, we won't find the Node SID to be used to form the repair
> segment-list.
>
>
>> I would propose those points be discussed in the operation considerations
>> section of this draft.
>>
>> In the absence of reason, this is not likely be configured IMHO.
>>
>
> KT2> Sure. Thanks for that feedback. We can certainly do that in the
> draft. I hope this isn't blocking the adoption in your view though, right?
>
>
>>
>>
>> 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)
>>
>>
>>
>> KT> In addition to the previous response, for the receiver this means
>> that the same prefix MAY be advertised from more than one node (that may be
>> happening now or may happen in the future). This can be clarified as well.
>>
>>
>>
>> [Bruno] OK. If this is happening now, this is a priori already visible in
>> the LSDB.
>>
>
> KT2> This is tricky. If the prefix is originated in a different domain, it
> gets tricky to determine if the prefix is anycast or dual-homed since the
> LSDB has a local area/domain view.
>
>
>> Any reason to duplicate the info (I would guess that’s easier for
>> implementation but since this is not guaranteed to be implemented one would
>> need to also check in the LSDB. So doubling the work).
>>
>
> KT2> This extension brings in simplicity for the receivers provided that
> operators can configure this property. Like I mentioned above, this starts
> to get more complicated in multi-domain scenarios. Perhaps we can think of
> this as the complexities that we experience in determining this property
> via an LSDB/topology-db that motivate us to bring forth this easier and
> more robust way.
>
>
>> Any specific reason requiring the knowledge of the future?
>>
>
> KT2> Perhaps at time T1, there are two nodes originating the prefix. Then
> at time T2, one of them goes down (or becomes disconnected), do we assume
> that the prefix is now not anycast? Then what happens if that other node
> comes back up again. For certain use-cases where anycast prefix is not
> desired, it may be helpful to completely avoid use of this prefix. The
> operator knows their design and addressing and perhaps is able to provision
> this prefix property correctly from the outset.
>
>
>>
>>
>>
>>
>>
>>
>> If this is specific to SR,  please say so.
>>
>>
>>
>> KT> It is not specific to SR, it is a property of an IP prefix.
>>
>>
>>
>> But even in this sub-case, SR anycast has some conditions, both for
>> SR-MPLS and SRv6.
>>
>>
>>
>> KT> This document does not discuss either SR-MPLS or SRv6 anycast. It
>> covers an OSPFv2 extension to simply advertise the anycast property of any
>> IP prefix. The discussion of SR anycast 

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

[Robert Raszuk]

Aijun,

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

That is unfortunately a wrong assumption.

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

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

Regards,
Robert



On Wed, Jan 17, 2024 at 7:56 AM Aijun Wang 
wrote:

> Hi, Les:
>
> Let’s keep the discussions simple.
>
> Please answer the following two questions that you haven’t responsed
> directly in previous mail:
> 1) How the existing point-to-point based solution(RFC9346/RFC5392) solve
> the broadcast(LAN, A.1 Figure2) inter-AS topology recovery scenario---There
> are multiple neighbors on one interfaces, which are located in different
> AS. How to encode the information within one inter-AS reachability TLV?
> 2) How the inter-AS based solutions solve the non inter-AS scenario
> requirements(A.2)?
>
> One point that I want to remind for your misunderstanding: the proposed
> Stub-link TLV can contain other attributes sub-TLVs of the link.
> And, if the interfaces share the same prefixes, they are in the same IP
> subnet. Is there any ambiguously for the IP topology recovery?
>
> What I want to emphasize is that the existing solutions are suitable for
> inter-AS point-to-point TE, the proposed solutions are suitable(more
> efficient)for inter-AS topology recovery(p2p, p2mp and broadcast etc.) and
> also other non inter-as traffic optimization scenarios.  They are not
> contrary.
>
>
>
> Aijun Wang
> China Telecom
>
> On Jan 17, 2024, at 00:57, Les Ginsberg (ginsberg)  40cisco@dmarc.ietf.org> wrote:
>
> 
>
> Aijun –
>
>
>
> Please see inline.
>
>
>
> *From:* Aijun Wang 
> *Sent:* Tuesday, January 16, 2024 12:18 AM
> *To:* Les Ginsberg (ginsberg) ; 'Christian Hopps' <
> cho...@chopps.org>; 'Huzhibo' 
> *Cc:* 'Acee Lindem' ; 'Yingzhen Qu' <
> yingzhen.i...@gmail.com>; lsr@ietf.org
> *Subject:* 答复: [Lsr] WG Adoption Call -
> draft-wang-lsr-stub-link-attributes (01/05/2024 - 01/19/2024)
>
>
>
> Hi, Les:
>
>
>
> -邮件原件-
> 发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org
> ] 代表 Les Ginsberg (ginsberg)
> 发送时间: 2024年1月16日 0:16
> 收件人: Christian Hopps ; Huzhibo <
> huzhibo=40huawei@dmarc.ietf.org>
> 抄送: Acee Lindem ; Yingzhen Qu <
> yingzhen.i...@gmail.com>; lsr@ietf.org
> 主题: Re: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes
> (01/05/2024 - 01/19/2024)
>
>
>
> I respect that individuals may have different opinions - but it is
> important to distinguish what is factual from what is not.
>
> Opinions based upon false information are clearly compromised.
>
>
>
> Please do heed Chris's (as WG chair) admonition to review the first WG
> adoption thread. That will reveal to you what the substantive objections
> were.
>
>
>
> https://mailarchive.ietf.org/arch/msg/lsr/Li7wJsaY68gzJ8mXxff7K-Fy_nw/
>
> https://www.mail-archive.com/search?l=lsr%40ietf.org=stub+link=0=0
>
>
>
>
>
> Please also do examine the delta between the previous version which was
> put up for WG adoption (V3) and the current version (V8) so you can see
> what has changed.
>
>
> https://author-tools.ietf.org/iddiff?url1=draft-wang-lsr-stub-link-attributes-03=draft-wang-lsr-stub-link-attributes-08=--html
>
>
>
> Some facts:
>
>
>
> The substantive objections raised during the first adoption call had
> nothing to do with use cases - they had to do with:
>
>
>
> a)The use of a prefix to identify a link between two nodes is a flawed
> concept. It is not robust enough to be used in cases of unnumbered or
> Pt-2-MP.
>
> [WAJ] Current encoding has covered the unnumbered scenario. For Pt-2-MP
> scenario, they share also the same subnet, please see our previous
> discussion at
> https://mailarchive.ietf.org/arch/msg/lsr/molRRoWXOBhaHFc5GPAPmvVISDs/
>
>
>
> *[LES:] I have no idea why you think the email you point to resolved the
> issue. It was an early email in a very long thread, the lack of support for
> unnumbered etc. continued to be discussed in subsequent emails by multiple
> participants and has been raised again by multiple participants in this
> second adoption call thread.*
>
> *The minor changes you made to the encoding of Stub Link advertisement
> does nothing to resolve the issue.*
>
> *The fundamental issue is that the same prefix can be associated with
> multiple links, so what you have defined is ambiguous in some cases.*
>
> *Either you don’t understand this or don’t think this is important – I am
> not sure which – but many of us do believe this is important.*
>
>
>
> b)Existing mechanisms (RFC 9346/was RFC 5316 and RFC 5392) fully cover the
> potential use cases and do so more robustly than the Stub-link 

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

[Robert Raszuk]

Jeff,

End-points do not need to participate in link state topology. Those are
merely leaves even if all endpoints are L3.

And 8K or even 256K of routes I think would be supported today by cheapest
nodes nodes from any vendor :)

Cheers,
R.





On Tue, Nov 28, 2023 at 12:32 AM Jeff Tantsura 
wrote:

> Robert,
>
> In context of LLM (10% of that for DLRM) training clusters, towards
> 2024/25 we would be looking to up to 8K end-points in a 3 stage leaf-spine
> fabric and up to 64-256K in 5 stages.
> Virtualization and how it is instantiated might significantly change
> amount/distribution of state in underlay/overlay.
>
> Obviously, these are hyperscale size deployments, many will be running
> 10-30 switches fabrics, where anything could work.
> BGP seems to work just fine, some data plane signaling could be used as a
> near real time augmentation to “slow but stable” control plane.
>
> Cheers,
> Jeff
>
> On Nov 26, 2023, at 14:30, Robert Raszuk  wrote:
>
> 
> Hey Jeff,
>
> Could you be so kind and defined term: "scaled-out leaf-spine fabrics" ?
>
> Specifically folks watching us here would highly appreciate if we state
> max target nodes with vanilla ISIS and max target nodes when your ISIS
> implementation supports draft-ietf-lsr-dynamic-flooding
> <https://datatracker.ietf.org/doc/html/draft-ietf-lsr-dynamic-flooding>
>
> While I am a BGP person I feel pretty strongly that BGP is not a best fit
> for the vast majority of DC fabrics in use today.
>
> Cheers,
> Robert
>
>
> 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
>> >>
>> >>

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

[Robert Raszuk]

Hey Jeff,

Could you be so kind and defined term: "scaled-out leaf-spine fabrics" ?

Specifically folks watching us here would highly appreciate if we state max
target nodes with vanilla ISIS and max target nodes when your ISIS
implementation supports draft-ietf-lsr-dynamic-flooding


While I am a BGP person I feel pretty strongly that BGP is not a best fit
for the vast majority of DC fabrics in use today.

Cheers,
Robert


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
> >> URL:
> https://www.ietf.org/archive/id/draft-xu-lsr-flooding-reduction-in-clos-01.txt
> >> Status:
> https://datatracker.ietf.org/doc/draft-xu-lsr-flooding-reduction-in-clos/
> >> HTMLized:
> https://datatracker.ietf.org/doc/html/draft-xu-lsr-flooding-reduction-in-clos
> >> Diff:
> https://author-tools.ietf.org/iddiff?url2=draft-xu-lsr-flooding-reduction-in-clos-01
> >>
> >> Abstract:
> >>
> >>   In a CLOS topology, an OSPF (or ISIS) router may receive identical
> >>   copies of an LSA (or LSP) from multiple OSPF (or ISIS) neighbors.
> >>   Moreover, two OSPF (or ISIS) neighbors may exchange the same LSA (or
> >>   LSP) simultaneously.  This results in unnecessary flooding of link-
> >>   state information, which wastes the precious resources of OSPF (or
> >>   ISIS) routers.  Therefore, this document proposes extensions to OSPF
> >>   (or ISIS) to reduce this flooding within CLOS networks.  The
> >>   reduction of OSPF (or ISIS) flooding is highly beneficial for
> >>   improving the scalability of CLOS 

Re: [Lsr] 转发: New Version Notification for draft-xu-lsr-fare-00.txt

[Robert Raszuk]

Hi Xiaohu,

I would be interested to learn why described elephant flows couldn't be
instead handled in typical TE fashion (choose your TE flavor) since we know
the target AI training clusters at the CLOS edges ? Such TE could steer
such flows link by link or inject it into disjoied virtual topologies.

Said this I am quite sceptical when it comes to injection of lot's of
dynamic application performance data into any routing protocol. Yes it has
been done in the past see rfc7810 and you do need to explain why
essentially similar additional data of such kind is needed.

Kind regards,
Robert

On Thu, Nov 23, 2023 at 5:27 PM xuxiaohu_i...@hotmail.com <
xuxiaohu_i...@hotmail.com> wrote:

> Hi all,
>
> Any comments or suggestions are welcome.
>
> Best regards,
> Xiaohu
>
>
>
> 发件人: internet-dra...@ietf.org 
> 日期: 星期五, 2023年11月24日 00:13
> 收件人: Xiaohu Xu 
> 主题: New Version Notification for draft-xu-lsr-fare-00.txt
>
> A new version of Internet-Draft draft-xu-lsr-fare-00.txt has been
> successfully
> submitted by Xiaohu Xu and posted to the
> IETF repository.
>
> Name: draft-xu-lsr-fare
> Revision: 00
> Title:Fully Adaptive Routing Ethernet
> Date: 2023-11-22
> Group:Individual Submission
> Pages:7
> URL:  https://www.ietf.org/archive/id/draft-xu-lsr-fare-00.txt
> Status:   https://datatracker.ietf.org/doc/draft-xu-lsr-fare/
> HTMLized: https://datatracker.ietf.org/doc/html/draft-xu-lsr-fare
>
>
> Abstract:
>
>Large language models (LLMs) like ChatGPT have become increasingly
>popular in recent years due to their impressive performance in
>various natural language processing tasks.  These models are built by
>training deep neural networks on massive amounts of text data, often
>consisting of billions or even trillions of parameters.  However, the
>training process for these models can be extremely resource-
>intensive, requiring the deployment of thousands or even tens of
>thousands of GPUs in a single AI training cluster.  Therefore, three-
>stage or even five-stage CLOS networks are commonly adopted for AI
>networks.  The non-blocking nature of the network become increasingly
>critical for large-scale AI models.  Therefore, adaptive routing is
>necessary to dynamically load balance traffic to the same destination
>over multiple ECMP paths, based on network capacity and even
>congestion information along those paths.
>
>
>
> 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] [Technical Errata Reported] RFC5340 (7649)

[Robert Raszuk]

Indeed ... a tunnel (GRE, IPSec, etc...) is an interface. How is this
different from any other interface from an OSPF point of view  If mtu is
configured on such interface (and in most cases it should be) that value
should be used in OSPF not 0.

Either way it has zero reassemblage to the "OSPF virtual link" hence it
seems this is a clear overinterpretation of the RFC.

I don't think either -bis is needed, nor errata.

Thx,
R.







On Wed, Sep 20, 2023 at 9:59 PM Acee Lindem  wrote:

> I agree - though I don’t think this is a case of underspecification. OSPF
> virtual links should not be confused with OSPF adjacencies over tunnels and
> there shouldn’t be any need for the added text.
>
> Thanks,
> Acee
>
> > On Sep 20, 2023, at 3:42 PM, John Scudder  wrote:
> >
> > Without commenting on the other aspects,
> >
> >> On Sep 20, 2023, at 3:34 PM, Tony Przygienda 
> wrote:
> >>
> >> 3. the MTU "largest datagram" needs to be errate'd to something more
> precise on top.
> >
> > Generally, errata are not the right way to fix “this is underspecified”
> kinds of problems. The right way is to do a bis or an update. See also
> https://www.ietf.org/about/groups/iesg/statements/processing-errata-ietf-stream/
> >
> > —John
>
>
> ___
> 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] RFC5838 (7644)

[Robert Raszuk]

Looks like this problem is known for over 13 years - Looks like a day one
implementation bug:

https://juniper-nsp.puck.nether.narkive.com/2DmYT8s6/j-nsp-ospfv3-junos-sends-zero-mtu-in-dbd-stuck-in-exstart

Do you think fixing a few RFCs which are pretty obvious what the behaviour
should be will really help ?

Cheers,
R.




On Mon, Sep 18, 2023 at 5:46 PM Owen DeLong  wrote:

> Happy to achieve the desired result (clarification) through whatever is
> the best mechanism, whether that be reattached, addition of a terminology
> section, or some other process not yet expressed.
>
> The vendor I referred to as getting this wrong is a very large router
> vendor. Multiple parties that have reported this issue through their TAC
> have been told “working as designed” with reference to this section and to
> section A.3.3 of RFC 5343 (for which I have submitted a similar errata
> report (7645).
>
> I’m trying to do this without public shaming of the vendor in question,
> but they are one of the domains in the CC list of this message.
>
> As such, I don’t think this mistake is limited to casual readers.
>
> Owen
>
>
> On Sep 18, 2023, at 05:13, Acee Lindem  wrote:
>
> Hi Robert,
>
>
>
> On Sep 18, 2023, at 07:50, Robert Raszuk  wrote:
>
> Acee,
>
> I agree with your assessment.
>
> But looking at the RFC I would say it is missing a Terminology section. If
> such section would clearly define meaning of virtual link in the context of
> this RFC there would be no ambiguity.
>
> Otherwise those not skilled in OSPF art may take a document and apply
> casual meaning to virtual link (which does indeed include a tunnel of any
> sort :).
>
> Of course this entire RFC is about OSPFv3 so this should be very intuitive
> to read it in such context not as casual IETF issued paper.
>
>
> Right.
>
>
> If any errara is needed here IMHO is just to add terminology section
> unless there is some formal definition that in all IETF RFCs terms
> apply only to the context of given subject doc. I am honestly not sure if
> there is one.
>
>
> I believe you could take almost any Routing RFC and improve it with
> editing and the addition of more context. This was clearly the case for
> https://datatracker.ietf.org/doc/draft-ietf-rtgwg-vrrp-rfc5798bis/
>
> This started out as a respin of the document for inclusive language but I
> also made significant edits to improve the readability (as well as address
> errata and other minor errors). After that, I received some really good
> input from reviewers (e.g., Quentin Arimitage provided around 70 comments
> and suggestions, most of which were incorporated).
>
> However, improvements such as these are usually not done with an Errata.
>
> Thanks,
> Acee
>
>
>
>
> Thx,
> R.
>
> On Mon, Sep 18, 2023 at 1:27 PM Acee Lindem  wrote:
>
>>
>>
>> > On Sep 17, 2023, at 22:07, Owen DeLong  wrote:
>> >
>> > You say they are unnecessary, then why do we have vendors doing this
>> wrong and pointing to this requirement of the RFC as their reason for doing
>> so?
>> >
>> > While there may be a valid argument that they shouldn’t be necessary, I
>> would argue that real world implementation experience suggests that they are
>> > most definitely necessary and are a minor edit to provide additional
>> clarity.
>>
>> An OSPF virtual link and a tunnel (e.g., GRE tunnel) are totally
>> different constructs. The vendor is incorrect in arguing that this text
>> specifics operation over a GRE tunnel. Rather, they should be arguing that
>> OSPF doesn’t have any path MTU capabilities and since a tunnel can be
>> multi-hop, OSPF doesn’t know the MTU.
>>
>> Thanks,
>> Acee
>>
>>
>> >
>> > Are you really arguing to preserve ambiguous language when the problem
>> is so easy to solve?
>> >
>> > Owen
>> >
>> >
>> >
>> >> On Sep 17, 2023, at 15:25, Acee Lindem  wrote:
>> >>
>> >> Given that the context of the “Interface MTU” is specifically the
>> “interface MTU” field in OSPFv3 Database Description packets and OSPF
>> virtual links (RFC 2328), the additions recommended in this Errata are
>> unnecessary. The Errata should be rejected.
>> >>
>> >> Thanks,
>> >> Acee
>> >>> On Sep 17, 2023, at 15:58, RFC Errata System <
>> rfc-edi...@rfc-editor.org> wrote:
>> >>>
>> >>> The following errata report has been submitted for RFC5838,
>> >>> "Support of Address Families in OSPFv3".
>> >>>
>> >>> --

Re: [Lsr] [Technical Errata Reported] RFC5838 (7644)

[Robert Raszuk]

Acee,

I agree with your assessment.

But looking at the RFC I would say it is missing a Terminology section. If
such section would clearly define meaning of virtual link in the context of
this RFC there would be no ambiguity.

Otherwise those not skilled in OSPF art may take a document and apply
casual meaning to virtual link (which does indeed include a tunnel of any
sort :).

Of course this entire RFC is about OSPFv3 so this should be very intuitive
to read it in such context not as casual IETF issued paper.

If any errara is needed here IMHO is just to add terminology section unless
there is some formal definition that in all IETF RFCs terms apply only to
the context of given subject doc. I am honestly not sure if there is one.

Thx,
R.

On Mon, Sep 18, 2023 at 1:27 PM Acee Lindem  wrote:

>
>
> > On Sep 17, 2023, at 22:07, Owen DeLong  wrote:
> >
> > You say they are unnecessary, then why do we have vendors doing this
> wrong and pointing to this requirement of the RFC as their reason for doing
> so?
> >
> > While there may be a valid argument that they shouldn’t be necessary, I
> would argue that real world implementation experience suggests that they are
> > most definitely necessary and are a minor edit to provide additional
> clarity.
>
> An OSPF virtual link and a tunnel (e.g., GRE tunnel) are totally different
> constructs. The vendor is incorrect in arguing that this text specifics
> operation over a GRE tunnel. Rather, they should be arguing that OSPF
> doesn’t have any path MTU capabilities and since a tunnel can be multi-hop,
> OSPF doesn’t know the MTU.
>
> Thanks,
> Acee
>
>
> >
> > Are you really arguing to preserve ambiguous language when the problem
> is so easy to solve?
> >
> > Owen
> >
> >
> >
> >> On Sep 17, 2023, at 15:25, Acee Lindem  wrote:
> >>
> >> Given that the context of the “Interface MTU” is specifically the
> “interface MTU” field in OSPFv3 Database Description packets and OSPF
> virtual links (RFC 2328), the additions recommended in this Errata are
> unnecessary. The Errata should be rejected.
> >>
> >> Thanks,
> >> Acee
> >>> On Sep 17, 2023, at 15:58, RFC Errata System <
> rfc-edi...@rfc-editor.org> wrote:
> >>>
> >>> The following errata report has been submitted for RFC5838,
> >>> "Support of Address Families in OSPFv3".
> >>>
> >>> --
> >>> You may review the report below and at:
> >>> https://www.rfc-editor.org/errata/eid7644
> >>>
> >>> --
> >>> Type: Technical
> >>> Reported by: Owen DeLong 
> >>>
> >>> Section: 2.7
> >>>
> >>> Original Text
> >>> -
> >>> Interface MTU
> >>>The size in octets of the largest address family specific datagram
> >>>that can be sent on the associated interface without
> >>>fragmentation.  The MTUs of common Internet link types can be
> >>>found in Table 7-1 of [MTUDISC].  The Interface MTU SHOULD be set
> >>>to 0 in Database Description packets sent over virtual links.
> >>>
> >>>
> >>> Corrected Text
> >>> --
> >>> Interface MTU
> >>>The size in octets of the largest address family specific datagram
> >>>that can be sent on the associated interface without
> >>>fragmentation.  The MTUs of common Internet link types can be
> >>>found in Table 7-1 of [MTUDISC].  The Interface MTU SHOULD be set
> >>>to 0 in Database Description packets sent over (OSPF3) virtual
> links.
> >>>This recommendation MUST NOT be applied to tunnel and other virtual
> >>>or software interfaces which carry traffic other than OSPF protocol
> packets.
> >>>
> >>> Notes
> >>> -
> >>> Currently, the language is ambiguous and at least one vendor has
> implemented OSPF3 sending an MTU of zero on GRE interfaces (and possibly
> others such as IPIP, IPSEC, etc., as I have not tested these). I believe
> that the intent of the RFC is to refer strictly to OSPF virtual-links which
> carry only OSPF protocol data and therefore have no meaningful MTU. When
> this is mistakenly applied to other forms of "virtual" interfaces such as
> tunnels, the results can be quite harmful.
> >>>
> >>> As such, I think that clarification is in order, since the vendor in
> question is unrepentant and claims their current implementation to be
> compliant with the RFC.
> >>>
> >>> 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.
> >>>
> >>> --
> >>> RFC5838 (draft-ietf-ospf-af-alt-10)
> >>> --
> >>> Title   : Support of Address Families in OSPFv3
> >>> Publication Date: April 2010
> >>> Author(s)   : A. Lindem, Ed., S. Mirtorabi, A. Roy, M. Barnes,
> R. Aggarwal
> >>> Category: 

Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-unreach-prefix-announce-04

[Robert Raszuk]

Hi Acee,

In any case, one will need to update the signaling routers and the routers
> acting on the signal.


I guess this is clear to all.

Additionally, your request for the adoption was that the draft have a
> stronger statement about the mechanism being used for solely for signaling
> for applications (e.g., BGP PIC).


As to the applicability my comment was that either draft should state in
strong normative language that this is applicable only to applications
which data plane uses encapsulation to the next hop.

Said this draft-wang introduces the additional signalling, sort of trying
to assure that all nodes in an area understand the new messages - but I am
not sure if even advertising PUAM capability means that it will be actually
used for all destinations ?

By responding to this Email inline, some may believe you support the
> assertion that we should start the adoption of both drafts. Please be
> clarify this.


Well the way I see this is that adoption call is a bit more formal
opportunity for WG members to express their opinion on any document. But
maybe LSR (for good reasons) have different internal rules to decide which
document should be subject to WG adoption and does sort of pre-filtering.

If adoption call proves document has negative comments or lacks cross
vendor support it simply does not get adopted.

Maybe I am just spoiled looking at how IDR WG process works :-)


> As for your other comment that this could be accomplished with BGP or an
> out-of-bound mechanism, that is true but that could be true of many
> problem. However, the solution under adoption has running code and wide
> vendor support.
>

 Right ... As I wrote to Peter - perhaps this is just a pragmatic approach
and flooding is what link state uses so be it.

As you know I did try in the past to propose BGP Aggregate withdraw but
then feedback of the community was that PEs do not go down that often to
justify the extension.

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

Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-unreach-prefix-announce-04

[Robert Raszuk]

Peter,


> > I am not sure what harm would it make to start WG adoption call on both
> > drafts and see the results.
> >
> > So far I am not seeing strong and uniform adoption support for either
> > one :)
>
> I hope you are not serious. Having two different ways of signalling the
> same thing in a protocol is hardy something you would want.



This is WC adoption call not WG last call.

Once documents are in WG, WG owns them and can merge them or improve them.
I hope LSR's mission is not just to rubber stamp the accepted drafts.

And actually I do not see sufficient and uniform support for either of them
as of today to get even to the WG doc status.

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

[Lsr] Question on draft-ppsenak-lsr-igp-unreach-prefix-announce

[Robert Raszuk]

Hi Peter & Les,

I was looking at the draft, but failed to find any text which would be a
normative MUST and would state that only advertisers of a given summary are
allowed to inject specific UPAs covered by those summaries.

If it comes from some other node it MUST be dropped.

I think this is just an omission and security hole. If not please elaborate
why you have chosen not to make this restriction explicit in the text.

Thx,
R.

PS. The way I read the current draft means that any bug in the ABR can
trigger a blast of UPAs for any prefix irrespective of the area ABR is
connected to. That's not too good.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-unreach-prefix-announce-04

[Robert Raszuk]

>  it would be helpful to summarize the common parts of the two solutions,

Actually IMO it would be much more helpful to summarise differences of both
solutions not common parts.

Thx,
r.



On Thu, Aug 31, 2023 at 11:23 AM Dongjie (Jimmy) 
wrote:

> Hi Les and Robert,
>
>
>
> Please see some comments inline:
>
>
>
> *From:* Lsr [mailto:lsr-boun...@ietf.org] *On Behalf Of *Robert Raszuk
> *Sent:* Thursday, August 31, 2023 4:19 PM
> *To:* Les Ginsberg (ginsberg) 
> *Cc:* Huzhibo ; Peter Psenak
> (ppsenak) ; linchangwang ;
> Acee Lindem ; lsr ;
> draft-ppsenak-lsr-igp-unreach-prefix-annou...@ietf.org
> *Subject:* Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix
> Announcement" - draft-ppsenak-lsr-igp-unreach-prefix-announce-04
>
>
>
> *Hi Les,*
>
>
>
> > But existing implementations will NOT ignore a prefix reachability
> advertisement just because
>
> > it has a source Router ID set to 0 as
> draft-wang-lsr-prefix-unreachable-annoucement defines.
>
>
>
> True, but let's do not forget the bigger picture here. The dst is already
> covered by summary so for the
>
> app it really does not matter ... It is reachable anyway.
>
>
>
> Bottom line is that both solutions need to have upgraded code to use the
> new trigger.
>
>
>
> [Jie] Agreed. Consider the existence of the summary route, advertising
> Max_Metric for a prefix covered by the summary route will not make it
> unreachable. A router needs to either understand the new flags as defined
> in draft-ppsenak, or understand the semantic of the NULL originator as
> specified in draft-wang to behave accordingly. This make me wonder whether
> it is still necessary to set the metric of that prefix to Max?
>
>
>
> After several rounds of update, to me the two solutions becomes similar in
> principle , just choose different ways to encode the trigger information.
>
>
>
>
>
> *Dear LSR chairs,*
>
>
>
> I am not sure what harm would it make to start WG adoption call on both
> drafts and see the results.
>
>
>
> [Jie] This sounds like a reasonable suggestion.
>
>
>
> And since the WG has been discussing this problem and the two solution
> drafts for a while, it would be helpful to summarize the common parts of
> the two solutions, and highlight their difference, so that people can
> understand the current state and make their decision.
>
>
>
> Best regards,
>
> Jie
>
>
>
>
> So far I am not seeing strong and uniform adoption support for either one
> :)
>
>
>
> Not sure why some authors feel like their work was rejected.
>
>
>
> Cheers,
>
> R.
>
>
>
>
>
> On Thu, Aug 31, 2023 at 4:57 AM Les Ginsberg (ginsberg)  40cisco@dmarc.ietf.org> wrote:
>
> Zhibo -
>
>
>
> Please see inline.
>
>
>
> > -Original Message-
>
> > From: Huzhibo 
>
> > Sent: Wednesday, August 30, 2023 6:33 PM
>
> > To: Les Ginsberg (ginsberg) ; Peter Psenak (ppsenak)
>
> > ; linchangwang ;
>
> > Acee Lindem ; lsr 
>
> > Cc: draft-ppsenak-lsr-igp-unreach-prefix-annou...@ietf.org
>
> > Subject: RE: [Lsr] Working Group Adoption of "IGP Unreachable Prefix
>
> > Announcement" - draft-ppsenak-lsr-igp-unreach-prefix-announce-04
>
> >
>
> > Hi Les:
>
> >
>
> > I think you may have connected something. Existing routers, on
> receiving a
>
> > prefix reachability advertisement with a
>
> > U-Flag described in
> https://datatracker.ietf.org/doc/draft-ppsenak-lsr-igp-
> <https://datatracker.ietf.org/doc/draft-ppsenak-lsr-igp-ureach-prefix-announce/>
>
> > ureach-prefix-announce/
> <https://datatracker.ietf.org/doc/draft-ppsenak-lsr-igp-ureach-prefix-announce/>
> also will interpret that prefix as being reachable.
>
>
>
> [LES:] This statement is incorrect.
>
> RFC 5305 states:
>
>
>
> 
>
> If a prefix is advertised with a metric larger then MAX_PATH_METRIC
>
>(0xFE00, see paragraph 3.0), this prefix MUST NOT be considered
>
>during the normal SPF computation.  This allows advertisement of a
>
>prefix for purposes other than building the normal IP routing table.
>
> 
>
>
>
> (Equivalent statement in RFC 5308 for IPv6)
>
>
>
> Existing implementations will ignore the advertisement purely on the basis
> of the metric value - this does not depend upon understanding the U bit.
>
>
>
> But existing implementations will NOT ignore a prefix reachability
> advertisement just because it has a source Router ID set to 0 as
> draft-wang-lsr-prefix-unr

Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-unreach-prefix-announce-04

[Robert Raszuk]

*Hi Les,*

> But existing implementations will NOT ignore a prefix reachability
advertisement just because
> it has a source Router ID set to 0 as 
> draft-wang-lsr-prefix-unreachable-annoucement
defines.

True, but let's do not forget the bigger picture here. The dst is already
covered by summary so for the
app it really does not matter ... It is reachable anyway.

Bottom line is that both solutions need to have upgraded code to use the
new trigger.


*Dear LSR chairs,*

I am not sure what harm would it make to start WG adoption call on both
drafts and see the results.

So far I am not seeing strong and uniform adoption support for either one
:)

Not sure why some authors feel like their work was rejected.

Cheers,
R.


On Thu, Aug 31, 2023 at 4:57 AM Les Ginsberg (ginsberg)  wrote:

> Zhibo -
>
>
>
> Please see inline.
>
>
>
> > -Original Message-
>
> > From: Huzhibo 
>
> > Sent: Wednesday, August 30, 2023 6:33 PM
>
> > To: Les Ginsberg (ginsberg) ; Peter Psenak (ppsenak)
>
> > ; linchangwang ;
>
> > Acee Lindem ; lsr 
>
> > Cc: draft-ppsenak-lsr-igp-unreach-prefix-annou...@ietf.org
>
> > Subject: RE: [Lsr] Working Group Adoption of "IGP Unreachable Prefix
>
> > Announcement" - draft-ppsenak-lsr-igp-unreach-prefix-announce-04
>
> >
>
> > Hi Les:
>
> >
>
> > I think you may have connected something. Existing routers, on
> receiving a
>
> > prefix reachability advertisement with a
>
> > U-Flag described in
> https://datatracker.ietf.org/doc/draft-ppsenak-lsr-igp-
> 
>
> > ureach-prefix-announce/
> 
> also will interpret that prefix as being reachable.
>
>
>
> [LES:] This statement is incorrect.
>
> RFC 5305 states:
>
>
>
> 
>
> If a prefix is advertised with a metric larger then MAX_PATH_METRIC
>
>(0xFE00, see paragraph 3.0), this prefix MUST NOT be considered
>
>during the normal SPF computation.  This allows advertisement of a
>
>prefix for purposes other than building the normal IP routing table.
>
> 
>
>
>
> (Equivalent statement in RFC 5308 for IPv6)
>
>
>
> Existing implementations will ignore the advertisement purely on the basis
> of the metric value - this does not depend upon understanding the U bit.
>
>
>
> But existing implementations will NOT ignore a prefix reachability
> advertisement just because it has a source Router ID set to 0 as
> draft-wang-lsr-prefix-unreachable-annoucement defines.
>
>
>
> It is worth noting that AFTER the publication of
> draft-ppsenak-lsr-igp-pfx-reach-loss-00 in March 2022 (subsequently renamed
> as draft-ppsenak-lsr-igp-ureach-prefix-announce), the authors of
> draft-wang-lsr-prefix-unreachable-annoucement apparently realized they had
>  an interoperability problem with existing routers (something many of us
> had been highlighting for years) and in V10 (published in Jul 2022) an
> option was added to advertise using maximum metric (the solution already
> proposed by draft-ppsenak). But because the authors apparently didn’t want
> to abandon the use of "Router ID = 0", the new version of the draft
> proposed a dependency on how the unreachable prefix should be advertised.
> If all routers in the network indicated support for the new extension
> (indicated by yet another protocol extension - a new Router Capability
> sub-TLV for IS-IS) then the use of Router ID = 0 could be used, but if any
> router in the network did not advertise the new capability, then the use of
> max-metric is required. Which means the solution requires routers
> advertising unreachability to potentially regenerate the advertisement in a
> different form whenever the state of support by all routers in the network
> for the extension changes.
>
>
>
> > Both two draft used The 0xFE00 metric indicates that the prefix is
> not
>
> > reachable. Doesn't make a difference at this point.
>
>
>
> [LES:] The solution defined in
> draft-ppsenak-lsr-igp-unreach-prefix-announce does not introduce any
> interoperability issues with existing routers, does not require multiple
> encoding formats, and does not require a router to regenerate
> advertisements in a different form based on the state of support by all
> routers in the network.
>
> I think this makes a big difference. 
>
>
>
>Les
>
>
>
> >
>
> > Thanks
>
> >
>
> > Zhibo Hu
>
> >
>
> > > -Original Message-
>
> > > From: Lsr [mailto:lsr-boun...@ietf.org ] On
> Behalf Of Les Ginsberg
>
> > > (ginsberg)
>
> > > Sent: Thursday, August 31, 2023 12:31 AM
>
> > > To: Peter Psenak ; linchangwang
>
> > > ; Acee Lindem ;
>
> > > lsr 
>
> > > Cc: draft-ppsenak-lsr-igp-unreach-prefix-annou...@ietf.org
>
> > > Subject: Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix
>
> > > Announcement" - draft-ppsenak-lsr-igp-unreach-prefix-announce-04
>
> > >
>
> > > Changwang -
>
> > >
>
> > > It is very important to note ...
>
> > >
>
> > > 
>
> > > > > 2. 

Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft name)

[Robert Raszuk]

Ok so you are saying it is still perfectly fine to flood domain wide per
node MSDs and completely ground breaking to flood per the very same amount
of nodes one loopback prefix ... Interesting.

Thx.
R.


On Tue, Aug 29, 2023 at 11:52 AM Peter Psenak  wrote:

> Robert,
>
> On 29/08/2023 02:23, Robert Raszuk wrote:
> >
> > Well takeMSDs ... I would think remote PE may find useful to know them
> > (ie. what is the capability of egress PE). Why those would not be needed
> > outside of an area I do not get.
>
> MSDs are advertise per node or per link, nothing to do with prefixes and
> summarization.
>
> thanks,
> Peter
>
> >
> > Thx,
> > R.
> >
> > On Tue, Aug 29, 2023 at 10:38 AM Peter Psenak  > <mailto:ppse...@cisco.com>> wrote:
> >
> > Robert,
> >
> > On 28/08/2023 14:19, Robert Raszuk wrote:
> >  > Daniel,
> >  >
> >  >  > [DV] No, there’s no need to leak and advertise
> >  >
> >  > You mean there is no need for RFC9352 in your network. If so -
> great.
> >  >
> >  > I was however asking the question: if network needs to advertise
> > any of
> >  > the information defined in RFC9352 would it still benefit from
> UPA ?
> >
> > ISIS SIDs are not needed outside of its area. Service SIDs are
> > advertised by BGP.
> >
> > thanks,
> > Peter
> >  >
> >  > Thx,
> >  > R.
> >  >
> >  >
> >  >
> >  > On Mon, Aug 28, 2023 at 11:05 PM Voyer, Daniel
> > mailto:daniel.vo...@bell.ca>
> >  > <mailto:daniel.vo...@bell.ca <mailto:daniel.vo...@bell.ca>>>
> wrote:
> >  >
> >  > Hi Robert, inlines
> >  >
> >  > __ __
> >  >
> >  > __ __
> >  >
> >  > *From: *Lsr  > <mailto:lsr-boun...@ietf.org> <mailto:lsr-boun...@ietf.org
> > <mailto:lsr-boun...@ietf.org>>> on
> >  > behalf of Robert Raszuk  > <mailto:rob...@raszuk.net> <mailto:rob...@raszuk.net
> > <mailto:rob...@raszuk.net>>>
> >  > *Date: *Monday, August 28, 2023 at 12:00 PM
> >  > *To: *"Hassan, Shehzad"
> >  > <mailto:40bell...@dmarc.ietf.org>
> >  > <mailto:40bell...@dmarc.ietf.org
> > <mailto:40bell...@dmarc.ietf.org>>>, Daniel Bernier
> >  > mailto:daniel.bern...@bell.ca>
> > <mailto:daniel.bern...@bell.ca <mailto:daniel.bern...@bell.ca>>>
> >  > *Cc: *lsr mailto:lsr@ietf.org>
> > <mailto:lsr@ietf.org <mailto:lsr@ietf.org>>>,
> >  > "draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org
> > <mailto:draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org>
> >  > <mailto:draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org
> > <mailto:draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org>>"
> >  >  > <mailto:draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org>
> >  > <mailto:draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org
> > <mailto:draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org>>>
> >  > *Subject: *[EXT]Re: [Lsr] Working Group Adoption of "IGP
> > Unreachable
> >  > Prefix Announcement" -
> >  > draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft
> > name)
> >  >
> >  > __ __
> >  >
> >  > Hi Shehzad & Daniel,
> >  >
> >  > 
> >  >
> >  > I support this work as it is key for summarization in an
> >  > SRv6/IPv6 network.
> >  >
> >  > __ __
> >  >
> >  > Are you not going to advertise and leak across your IGP
> > domain any
> >  > of the SRv6 extensions as described in
> >  > https://datatracker.ietf.org/doc/rfc9352/
> > <https://datatracker.ietf.org/doc/rfc9352/>
> >  > <https://datatracker.ietf.org/doc/rfc9352/
> > <https://datatracker.ietf.org/doc/rfc9352/>> for the PEs ? 
> >  >
> >  > [DV] No, there’s no need to leak and advertise. For an SRv6
> > network,
> >  > we are summa

Re: [Lsr] New Version Notification for draft-liu-lsr-mpls-inspection-msd-01.txt

[Robert Raszuk]

Hi Tony,

Unless you are using precise interface based packet steering (which may not
be a great idea to start with) how do you know on which line card type your
packets arrive/exit ?

Just curious ...

Thx,
R.

On Tue, Aug 29, 2023 at 4:36 AM Tony Li  wrote:

>
> Hi Yao,
>
> Please consider the case of a modular node with a number of different line
> cards, where the line cards are based on different forwarding engines.
>
> RLD needs to be link specific.
>
> Regards,
> Tony
>
>
> On Aug 28, 2023, at 6:55 PM,  
> wrote:
>
> Hi Les,
>
> Thanks a lot for your review and comments.
>
> This new MSD is a per-node capability just like ERLD-MSD, mainly because
> it represents how many MPLS labels the node can read, and it is not related
> with the links.
>
> And the description in this draft you mentioned is written taking example
> by RFC9088(section 4. Advertising ERLD Using IS-IS).
>
> I'll explicitly state the scope of the new MSD in the next version.
>
>
> Best Regards,
>
> Yao
> Original
> *From: *LesGinsberg(ginsberg) 
> *To: *刘尧00165286;m...@ietf.org ;lsr@ietf.org  >;
> *Date: *2023年08月28日 20:57
> *Subject: **RE: [Lsr] Fw: New Version Notification for
> draft-liu-lsr-mpls-inspection-msd-01.txt*
>
> Yao –
>
>
>
> Both RFC 8476(OSPF) and RFC 8491(IS-IS) define MSD advertisements with
> per-link scope and per-node scope.
>
>
>
> Your draft only states:
>
>
>
> “If a router has multiple interfaces with different capabilities of
>
>reading the maximum label stack depth, the router MUST advertise the
>
>smallest value found across all its interfaces.”
>
>
>
> This suggests that you intend only to advertise a per-node capability –
> but as you don’t explicitly state that – and you don’t provide a reason why
> a per link capability isn’t applicable, I am unclear as to what your
> intentions are here.
>
>
>
> Could you clarify whether you intend to support both per link and per node
> capability – and if not why not?
>
>
>
> Thanx.
>
>
>
>Les
>
>
>
>
>
> *From:* Lsr  *On Behalf Of * liu.ya...@zte.com.cn
> *Sent:* Monday, August 28, 2023 12:33 AM
> *To:* m...@ietf.org; lsr@ietf.org
> *Subject:* [Lsr] Fw: New Version Notification for
> draft-liu-lsr-mpls-inspection-msd-01.txt
>
>
>
> Hi All,
>
> A new version of draft-liu-lsr-mpls-inspection-msd has just been uploaded.
>
> In this document, a new type of MSD is defined to reflect the Readable
> Label Depth(RLD), which helps in the MPLS MNA solution.
>
> In this version, the main update is that some description is added to
> explain why a new MSD is preferred instead of the ERLD-MSD.
>
> Currently this new MSD is called Base MPLS Inspection MSD, it may be
> changed to a more straightforward name like RLD-MSD based on the
> description in the MNA architecture/solution document.
>
> Your comments and suggestions are more than welcome!
>
>
>
> Thanks,
>
> Yao
>
> Original
>
> *From: *internet-dra...@ietf.org 
>
> *Date: *2023年08月28日 14:55
>
> *Subject: New Version Notification for
> draft-liu-lsr-mpls-inspection-msd-01.txt*
>
>
> A new version of Internet-Draft draft-liu-lsr-mpls-inspection-msd-01.txt has
> been successfully submitted by Yao Liu and posted to the
> IETF repository.
>
> Name: draft-liu-lsr-mpls-inspection-msd
> Revision: 01
> Title:Signaling Base MPLS Inspection MSD
> Date: 2023-08-27
> Group:Individual Submission
> Pages:7
> URL:
> https://www.ietf.org/archive/id/draft-liu-lsr-mpls-inspection-msd-01.txt
> Status:
> https://datatracker.ietf.org/doc/draft-liu-lsr-mpls-inspection-msd/
> HTML:
> https://www.ietf.org/archive/id/draft-liu-lsr-mpls-inspection-msd-01.html
> HTMLized:
> https://datatracker.ietf.org/doc/html/draft-liu-lsr-mpls-inspection-msd
> Diff:
> https://author-tools.ietf.org/iddiff?url2=draft-liu-lsr-mpls-inspection-msd-01
>
> Abstract:
>
>This document defines a new type of MSD, Base MPLS Inspection MSD to
>reflect the Readable Label Depth(RLD), and the mechanism to signal
>this MSD using IGP and BGP-LS.
>
>
>
> 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] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft name)

[Robert Raszuk]

Well takeMSDs ... I would think remote PE may find useful to know them (ie.
what is the capability of egress PE). Why those would not be needed outside
of an area I do not get.

Thx,
R.

On Tue, Aug 29, 2023 at 10:38 AM Peter Psenak  wrote:

> Robert,
>
> On 28/08/2023 14:19, Robert Raszuk wrote:
> > Daniel,
> >
> >  > [DV] No, there’s no need to leak and advertise
> >
> > You mean there is no need for RFC9352 in your network. If so - great.
> >
> > I was however asking the question: if network needs to advertise any of
> > the information defined in RFC9352 would it still benefit from UPA ?
>
> ISIS SIDs are not needed outside of its area. Service SIDs are
> advertised by BGP.
>
> thanks,
> Peter
> >
> > Thx,
> > R.
> >
> >
> >
> > On Mon, Aug 28, 2023 at 11:05 PM Voyer, Daniel  > <mailto:daniel.vo...@bell.ca>> wrote:
> >
> >     Hi Robert, inlines
> >
> > __ __
> >
> > __ __
> >
> > *From: *Lsr mailto:lsr-boun...@ietf.org>> on
> > behalf of Robert Raszuk mailto:rob...@raszuk.net
> >>
> > *Date: *Monday, August 28, 2023 at 12:00 PM
> > *To: *"Hassan, Shehzad"  > <mailto:40bell...@dmarc.ietf.org>>, Daniel Bernier
> > mailto:daniel.bern...@bell.ca>>
> > *Cc: *lsr mailto:lsr@ietf.org>>,
> > "draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org
> > <mailto:draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org>"
> >  > <mailto:draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org>>
> > *Subject: *[EXT]Re: [Lsr] Working Group Adoption of "IGP Unreachable
> > Prefix Announcement" -
> > draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft
> name)
> >
> > __ __
> >
> > Hi Shehzad & Daniel,
> >
> > 
> >
> > I support this work as it is key for summarization in an
> > SRv6/IPv6 network.
> >
> > __ __
> >
> > Are you not going to advertise and leak across your IGP domain any
> > of the SRv6 extensions as described in
> > https://datatracker.ietf.org/doc/rfc9352/
> > <https://datatracker.ietf.org/doc/rfc9352/> for the PEs ? 
> >
> > [DV] No, there’s no need to leak and advertise. For an SRv6 network,
> > we are summarizing locators and loopback (should be derived from
> > locator 0). This makes the routing domain “opaque”.
> >
> > __ __
> >
> > And if you do, is there still some use case for UPA ? 
> >
> > __ __
> >
> > Perhaps I am missing something but how would those extensions
> > survive summarization ? 
> >
> > __ __
> >
> > __ __
> >
> > Thx,
> > Robert
> >
> > Cheers,
> >
> > Dan
> >
> > __ __
> >
> >  > On Aug 23, 2023, at 4:07 PM, Acee Lindem  > <mailto:acee.i...@gmail.com>> wrote:
> >  >
> >  > LSR Working Group,
> >  >
> >  > This begins the working group adoption call for “IGP
> > Unreachable Prefix Announcement” -
> > draft-ppsenak-lsr-igp-unreach-prefix-announce-04.
> >  > Please indicate your support or objection on this list prior
> > to September 7th, 2023.
> >  >
> >  > Thanks,
> >  > Acee
> >  >
> >
>  
> --
> >  > External Email: Please use caution when opening links and
> > attachments / Courriel externe: Soyez prudent avec les liens et
> > documents joints
> >  >
> > ___
> > Lsr mailing list
> > Lsr@ietf.org <mailto:Lsr@ietf.org>
> > https://www.ietf.org/mailman/listinfo/lsr
> > <https://www.ietf.org/mailman/listinfo/lsr>
> >
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft name)

[Robert Raszuk]

Daniel,

> [DV] No, there’s no need to leak and advertise

You mean there is no need for RFC9352 in your network. If so - great.

I was however asking the question: if network needs to advertise any of the
information defined in RFC9352 would it still benefit from UPA ?

Thx,
R.



On Mon, Aug 28, 2023 at 11:05 PM Voyer, Daniel  wrote:

> Hi Robert, inlines
>
>
>
>
>
> *From: *Lsr  on behalf of Robert Raszuk <
> rob...@raszuk.net>
> *Date: *Monday, August 28, 2023 at 12:00 PM
> *To: *"Hassan, Shehzad" , Daniel
> Bernier 
> *Cc: *lsr , "
> draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org" <
> draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org>
> *Subject: *[EXT]Re: [Lsr] Working Group Adoption of "IGP Unreachable
> Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04
> (Fixed draft name)
>
>
>
> Hi Shehzad & Daniel,
>
>
>
> I support this work as it is key for summarization in an SRv6/IPv6 network.
>
>
>
> Are you not going to advertise and leak across your IGP domain any of the
> SRv6 extensions as described in https://datatracker.ietf.org/doc/rfc9352/
> for the PEs ?
>
> [DV] No, there’s no need to leak and advertise. For an SRv6 network, we
> are summarizing locators and loopback (should be derived from locator 0).
> This makes the routing domain “opaque”.
>
>
>
> And if you do, is there still some use case for UPA ?
>
>
>
> Perhaps I am missing something but how would those extensions survive
> summarization ?
>
>
>
>
>
> Thx,
> Robert
>
> Cheers,
>
> Dan
>
>
>
> > On Aug 23, 2023, at 4:07 PM, Acee Lindem  wrote:
> >
> > LSR Working Group,
> >
> > This begins the working group adoption call for “IGP Unreachable Prefix
> Announcement” - draft-ppsenak-lsr-igp-unreach-prefix-announce-04.
> > Please indicate your support or objection on this list prior to
> September 7th, 2023.
> >
> > Thanks,
> > Acee
> >
> --
> > External Email: Please use caution when opening links and attachments /
> Courriel externe: Soyez prudent avec les liens et documents joints
> >
> ___
> 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] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft name)

[Robert Raszuk]

Hi Shehzad & Daniel,


> I support this work as it is key for summarization in an SRv6/IPv6 network.
>

Are you not going to advertise and leak across your IGP domain any of the
SRv6 extensions as described in https://datatracker.ietf.org/doc/rfc9352/
for the PEs ?

And if you do, is there still some use case for UPA ?

Perhaps I am missing something but how would those extensions survive
summarization ?


Thx,
Robert


> On Aug 23, 2023, at 4:07 PM, Acee Lindem  wrote:
> >
> > LSR Working Group,
> >
> > This begins the working group adoption call for “IGP Unreachable Prefix
> Announcement” - draft-ppsenak-lsr-igp-unreach-prefix-announce-04.
> > Please indicate your support or objection on this list prior to
> September 7th, 2023.
> >
> > Thanks,
> > Acee
> >
> --
> > External Email: Please use caution when opening links and attachments /
> Courriel externe: Soyez prudent avec les liens et documents joints
> >
> ___
> 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] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft name)

[Robert Raszuk]

Hi Peter,

> The version -04 does not contain normative MUST that UPA shall only be
> > used to trigger invalidation when end to end encapsulation is used for
> > subject application(s). So as written is in fact quite undeployable in a
> > mixed vendor and legacy node(s) environment doing hop by hop routing. We
> > can't just hope that this is all about configuring the network in a
> > proper way.
>
> above looks more like a comment that can easily be addressed by
> additional text, which I'm willing to add, rather than an objection to
> draft becoming a WG document. Please let me know if you think otherwise.
>

Ok if you are willing to add such restriction to the spec then I can remove
my concern #1.

> The solution is too pragmatic ...
>
> Isn't that a good thing, isn't it? :)
>

:)

Yes and it does assure that we can have some mechanism like this before
we all retire !

But you know once you have an interim solution it is much harder to
convince
folks to work on a more optimal one.


> It does not look at the problem
> > holistically. Yes I still think the problem is worth solving but outside
> > of link state IGP doing UPA blast flooding everywhere domain wide even
> > if no nodes need that info. As discussed at length it could be done via
> > either BGP indirection or via PUB-SUB model (as proposed).
>
> I don't object to solve this problem in BGP, or elsewhere. But given
> that the problem we are trying to solve is created by the IGP
> summarization and the ultimate source of the prefix reachability or
> unreachibility comes from IGPs, having a solution in IGPs seems like a
> natural choice.


That is all correct. But I really do not like to use domain wide flooding
for it.

For example if you would contain the solution within IGP but from local or
remote
ABRs unicast by UDP to subscribers that given PE or POP is down that would
also
contain the solution to IGP.  Yes it is a bit more difficult as you would
need to solve
subscription problem first as opposed to the blast or spray approach, but
the current draft
does not even leave any room for such apparatus.

So my concern here is not that the proposal is broken. It is just
suboptimal IMHO.

And as we spoke a few weeks back in SF I think it is harmless, but is this
enough ?

Lastly, I think PEs do not accidentally go down that often, and for any
planned
maintenance there are other ways to drain the box.

With that said, consider my objection to be a soft one based on the above.

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

Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft name)

[Robert Raszuk]

Dear LSR WG,

I object on two basis ...

1)

The version -04 does not contain normative MUST that UPA shall only be used
to trigger invalidation when end to end encapsulation is used for subject
application(s). So as written is in fact quite undeployable in a mixed
vendor and legacy node(s) environment doing hop by hop routing. We can't
just hope that this is all about configuring the network in a proper way.

2)

The solution is too pragmatic ... It does not look at the problem
holistically. Yes I still think the problem is worth solving but outside of
link state IGP doing UPA blast flooding everywhere domain wide even if no
nodes need that info. As discussed at length it could be done via either
BGP indirection or via PUB-SUB model (as proposed).

Regards,
Robert


On Wed, Aug 23, 2023 at 10:07 PM Acee Lindem  wrote:

> LSR Working Group,
>
> This begins the working group adoption call for “IGP Unreachable Prefix
> Announcement” - draft-ppsenak-lsr-igp-unreach-prefix-announce-04.
> Please indicate your support or objection on this list prior to September
> 7th, 2023.
>
> 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] draft-ppsenak-lsr-igp-ureach-prefix-announce

[Robert Raszuk]

>  where you are forwarding hop by hop routing simultaneously with end to
end encapsulation.

That is not the point here. What you said above is mutually exclusive.

The issue arise when you are not doing end to end encapsulation as
current UPA draft does not preclude using UPA for such networks where
routing decision is made at each transit node of the domain or at each
segment endpoint.

Rgs,
Robert


On Wed, Jul 26, 2023 at 9:38 PM Gyan Mishra  wrote:

> Hi Bruno
>
> Can you give an example of an application or scenario where you are
> forwarding hop by hop routing simultaneously with end to end encapsulation.
>
> So the end to end encapsulation would be MPLS, SR-MPLS or  SRv6 and both
> global table routing and L3 VPN instances and even simultaneously all three
> would be end to end encapsulation.
>
> I was trying to imagine a scenario where you have hop by hop forwarding
> which would be IP forwarding without MPLS or L3 VPN just straight IP
> forwarding.
>
> If you are doing global table IPv6 that would be the one possible scenario
> and with that in parallel have MPLS / SR-MPLS as ships in night during a
> migration  phase.
>
> RSVP-TE if you throw into the mix that is also same end to end
> encapsulation over LSP MPLS dataplane.
>
>  In an end state network I can’t see how you would have two different data
> planes simultaneously.
>
> In the DC you could have IP fabric hop by hop and migrating to NVO VXLAN
> or GENEVE end to end encapsulation.
>
> Anytime you have an  overlay such as VPN or NVO are all end to end
> encapsulations.
>
> So it’s few and far between scenarios with hop by hop which would be any
> scenario using vanilla IP fabric single tenant and no overlay.
>
> Thoughts?
>
> Gyan
>
> On Wed, Jul 26, 2023 at 10:38 AM  wrote:
>
>> Peter,
>>
>> please see inline
>>
>>
>> > From: Peter Psenak 
>> > Sent: Tuesday, July 25, 2023 10:04 PM
>> >
>> > Bruno,
>> >
>> > please see inline:
>> >
>> > On 25/07/2023 20:58, bruno.decra...@orange.com wrote:
>> > > Peter,
>> > >
>> > > Thank for you answer. Please see inline [Bruno]
>> > >
>> > >
>> > >> From: Peter Psenak 
>> > >> Sent: Tuesday, July 25, 2023 6:11 PM
>> > >>
>> > >> Bruno,
>> > >>
>> > >> On 25/07/2023 14:39, bruno.decra...@orange.com wrote:
>> > >>> Hi all,
>> > >>>
>> > >>> IP reachability advertised by IS-IS is often used by other routing
>> and
>> > >>> signaling protocols (e.g., BGP, PIM (rpf vector) LDP, RSVP-TE...).
>> As
>> > >>> such, UPA may affect those protocols.
>> > >>>
>> > >>> Has UPA been presented in other WGs in the routing areas?
>> > >>>
>> > >>> I believe this would be prudent if not required.
>> > >>
>> > >> why do you believe so? How is this different to an IGP prefix
>> becoming
>> > >> unreachable without UPA?
>> > >
>> > > [Bruno] Because, at least for IS-IS, this is a protocol extension.
>> > >
>> > > When receiving:
>> > > IP1/32 with metric 0xFE01
>> > > IP1/24 with metric 10  (covering aggregate)
>> > >
>> > > Legacy routers will only consider the aggregate for the SPF/RIB
>> > > IP1/24 with metric 10
>> >
>> > even routers with UPA processing enabled would only use IP2/24 in
>> > forwarding. The UPA would only be used to send signal to apps like BGP.
>>
>> you are correct.
>> (I meant legacy node will not see the UPA hence that IP1/32 is
>> unreachable)
>>
>> > >
>> > > As a result, a BGP route IP2 with BGP Next-Hop IP1 is still feasible
>> and used.
>> > >
>> > > UPA compliant routers will consider the aggregate for the SPF/RIB,
>> plus they will consider that IP1/32 is unreachable.
>> >
>> > no, they will NOT consider that IP1/32 is unreachable.
>> >
>> > UPA is only used to signal the unreachability to apps that are
>> > interested.
>>
>> "apps" are part of the router, in particular BGP.
>> So let me rephrase: the BGP protocol on UPA compliant routers will
>> consider the aggregate for the SPF/RIB, plus they will consider that IP1/32
>> is unreachable.
>>
>> > What the apps do with it is out of the scope of UPA.
>>
>> Use of UPA have consequences. Some good (advertising loss of
>> reachability), some bads (forwarding loops for BGP prefixes which are
>> routed hop by hop).
>> I don't think that we can claim the benefits (adopt UPA because it's
>> useful for e.g. BGP PIC edge) and refuse to talk about the drawbacks.
>>
>> >
>> > > As a result, a BGP route IP2 with BGP Next-Hop IP1 is not feasible
>> and not used.
>> > >
>> > > (note that I have assume that the UPA signal is sent to BGP, but this
>> is the same picture if UPA is only used by BGP PIC Edge)
>> > >
>> > >
>> > >
>> > >>>
>> > >>> In particular, BGP is (heavily) using reachability of (loopbacks)
>> > >>> addresses advertised in IS-IS in order to evaluate the reachability
>> of
>> > >>> BGP routes and compute their preference.
>> > >>>
>> > >>> If UPA is not interpreted the same ways by all routers, forwarding
>> loops
>> > >>> may occur in a hop by hop routed network. (because different routers
>> > >>> would select different paths since 

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce

[Robert Raszuk]

Peter,

I am with you that enabling signalling UPA to the application is up to the
operator.

But going with Bruno's concern, the app (say BGP) on vendor X may use UPA
in a completely different way that on vendor Y then again on vendor Z. One
may invalidate a path with a given next hop for 5 sec the other for 120 sec
etc ... as an example.

So as suggested I think UPA should not be (in fact I would use normative
MUST NOT be) enabled for address families which do not use end to end
encapsulation.

Thx,
R,

On Wed, Jul 26, 2023 at 8:41 AM Peter Psenak  wrote:

> Hi Bruno,
>
> please see inline:
>
> On 26/07/2023 16:38, bruno.decra...@orange.com wrote:
> > Peter,
> >
> > please see inline
> >
> >
> >> From: Peter Psenak 
> >> Sent: Tuesday, July 25, 2023 10:04 PM
> >>
> >> Bruno,
> >>
> >> please see inline:
> >>
> >> On 25/07/2023 20:58, bruno.decra...@orange.com wrote:
> >>> Peter,
> >>>
> >>> Thank for you answer. Please see inline [Bruno]
> >>>
> >>>
>  From: Peter Psenak 
>  Sent: Tuesday, July 25, 2023 6:11 PM
> 
>  Bruno,
> 
>  On 25/07/2023 14:39, bruno.decra...@orange.com wrote:
> > Hi all,
> >
> > IP reachability advertised by IS-IS is often used by other routing
> and
> > signaling protocols (e.g., BGP, PIM (rpf vector) LDP, RSVP-TE...). As
> > such, UPA may affect those protocols.
> >
> > Has UPA been presented in other WGs in the routing areas?
> >
> > I believe this would be prudent if not required.
> 
>  why do you believe so? How is this different to an IGP prefix becoming
>  unreachable without UPA?
> >>>
> >>> [Bruno] Because, at least for IS-IS, this is a protocol extension.
> >>>
> >>> When receiving:
> >>> IP1/32 with metric 0xFE01
> >>> IP1/24 with metric 10  (covering aggregate)
> >>>
> >>> Legacy routers will only consider the aggregate for the SPF/RIB
> >>> IP1/24 with metric 10
> >>
> >> even routers with UPA processing enabled would only use IP2/24 in
> >> forwarding. The UPA would only be used to send signal to apps like BGP.
> >
> > you are correct.
> > (I meant legacy node will not see the UPA hence that IP1/32 is
> unreachable)
> >
> >>>
> >>> As a result, a BGP route IP2 with BGP Next-Hop IP1 is still feasible
> and used.
> >>>
> >>> UPA compliant routers will consider the aggregate for the SPF/RIB,
> plus they will consider that IP1/32 is unreachable.
> >>
> >> no, they will NOT consider that IP1/32 is unreachable.
> >>
> >> UPA is only used to signal the unreachability to apps that are
> >> interested.
> >
> > "apps" are part of the router, in particular BGP.
> > So let me rephrase: the BGP protocol on UPA compliant routers will
> consider the aggregate for the SPF/RIB, plus they will consider that IP1/32
> is unreachable.
> >
> >> What the apps do with it is out of the scope of UPA.
> >
> > Use of UPA have consequences. Some good (advertising loss of
> reachability), some bads (forwarding loops for BGP prefixes which are
> routed hop by hop).
> > I don't think that we can claim the benefits (adopt UPA because it's
> useful for e.g. BGP PIC edge) and refuse to talk about the drawbacks.
>
> ##PP
> we basically leave the responsibility to the consumer of the UPA, as the
> treatment of the UPA signal an its consequence on the app is app specific.
>
> But we can clarify that in the draft.
>
> >
> >>
> >>> As a result, a BGP route IP2 with BGP Next-Hop IP1 is not feasible and
> not used.
> >>>
> >>> (note that I have assume that the UPA signal is sent to BGP, but this
> is the same picture if UPA is only used by BGP PIC Edge)
> >>>
> >>>
> >>>
> >
> > In particular, BGP is (heavily) using reachability of (loopbacks)
> > addresses advertised in IS-IS in order to evaluate the reachability
> of
> > BGP routes and compute their preference.
> >
> > If UPA is not interpreted the same ways by all routers, forwarding
> loops
> > may occur in a hop by hop routed network. (because different routers
> > would select different paths since they use different information to
> > select their path)
> 
>  I don't see a problem, please provide an example.
> >>>
> >>> iPE1 - P1 - P2 - ABR1 - P3 - ePE2 (IP1)
> >>>  |
> >>>  |
> >>> ePE3 (IP1)
> >>>
> >>>
> >>> 
> >>>
> >>> ABR1 is L1L2. It advertises, in L1, an aggregate prefix covering
> routers in L2.
> >>>
> >>>
> >>>
> >>> ePE2 and ePE3 advertise IP1 in BGP. ePE2 is preferred. All nodes have
> both BGP paths to IP1.
> >>> Traffic to IP1 is IP routed hop by hop from iPE1.
> >>> P2 support UPA, P1 does not.
> >>> ePE2 fails and ABR1 advertise UPA in level 1.
> >>>
> >>>
> >>> P1 does not support UPA so is unaware of ePE2 failure and keeps
> routing IP1 toward ePE2, hence P2.
> >>> P2 supports UPA so knows that the ePE2 is down and invalidate BGP
> routes using this BGP Next-Hop. Hence P2 routes IP1 toward ePE3.
> >>>

[Lsr] UPA for option C

[Robert Raszuk]

Hey Peter and Lsr,

At the risk of being called troublemaker by Les again :) can you refresh my
failing memory how UPA would work in case of Inter-AS option C (where
original next hops are maintained for service routes across two or more
ASNs) and reachability to next hops is redistributed (often with labels)
between ASBRs ?

On a similar note how UPAs travel (if at all) between backbone area and
remote areas in the single AS case ?

While reading mail from Bruno I also realized a bit more complex case where
someone may use service routes in service BGP over "seamless MPLS 3107/LU
routes by BGP over IGP. In such cases signalling remote PE going down is
not going to help much I am afraid.

- - -

As to the draft I think just adding a sentence that it should be
used/enabled only for encapsulated services at ingress to the service
nodes.

And actually to expand on what Bruno mentioned in the last note next hop
validation can in some implementations be enabled to resolve in different
RIBs on a per SAFI basis.

But how BGP (or any other app) takes such triggers is indeed outside of
scope of the current draft IMO.

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

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce

[Robert Raszuk]

Hi,

> So we have a way to achieve consistency if it is ever needed.

Well you do not have any protocol way to assure that operational
configuration mistakes will not result in inconsistent routing.

But overall I do agree that for the vast majority of applications that
concern is not really applicable ? In fact I would be happy if you limit
the UPA scope *only* for services which use end to end encapsulation.

It is also important to observe that this is not negative routing and that
P nodes will continue to forward packets to destinations marked as UPA as
the information will not be really reflected as holes/drops in their
respective FIBs.

Thx,
R.



On Tue, Jul 25, 2023 at 10:38 AM Peter Psenak  wrote:

> Hi Robert,
>
>
>
> On 25/07/2023 18:51, Robert Raszuk wrote:
> > Hey Peter,
> >
> > I think the point Bruno is making is valid ... Imagine dual or triple
> > vendor network and hop by hop routing (no end to end SAFI).
> >
> > That means that all nodes should be in synch in terms to react on UPA,
>
> chapter 7 of the draft says:
>
> "Processing of the received UPAs is optional and SHOULD be controlled by
> the configuration at the receiver. The receiver itself, based on its
> configuration, decides what the UPA will be used for and what
> applications, if any, will be notified when UPA is received."
>
> So we have a way to achieve consistency if it is ever needed. For most
> cases, the network wide consistency is not needed.
>
> thanks,
> Peter
>
> >
> > Of course you will say that this is up to wise operator to enable it
> > only when it makes sense ... but I think the point is still valid and
> > clearly for none tunneled networks (if ever to use UPA) this is NOT a
> > local decision,
> >
> > For vast majority it is local as forwarding is using some sort of PE-PE
> > encapsulation.
> >
> > Cheers,
> > R.
> >
> >
> > On Tue, Jul 25, 2023 at 9:11 AM Peter Psenak
> > mailto:40cisco@dmarc.ietf.org>>
>
> > wrote:
> >
> > Bruno,
> >
> > On 25/07/2023 14:39, bruno.decra...@orange.com
> > <mailto:bruno.decra...@orange.com> wrote:
> >  > Hi all,
> >  >
> >  > IP reachability advertised by IS-IS is often used by other
> > routing and
> >  > signaling protocols (e.g., BGP, PIM (rpf vector) LDP,
> > RSVP-TE...). As
> >  > such, UPA may affect those protocols.
> >  >
> >  > Has UPA been presented in other WGs in the routing areas?
> >  >
> >  > I believe this would be prudent if not required.
> >
> > why do you believe so? How is this different to an IGP prefix
> becoming
> > unreachable without UPA?
> >
> >  >
> >  > In particular, BGP is (heavily) using reachability of (loopbacks)
> >  > addresses advertised in IS-IS in order to evaluate the
> > reachability of
> >  > BGP routes and compute their preference.
> >  >
> >  > If UPA is not interpreted the same ways by all routers,
> > forwarding loops
> >  > may occur in a hop by hop routed network. (because different
> routers
> >  > would select different paths since they use different information
> to
> >  > select their path)
> >
> > I don't see a problem, please provide an example.
> > If an ingress PE decides to switch to an alternate BGP path, how does
> > that creates any potential loop? And why all egress PEs would need
> > to do
> > the same?
> >
> >  >
> >  > This is not considered nor discussed in the draft. Quite the
> > contrary,
> >  > draft says that recognition, processing and use of UPA is a local
> >  > consideration.
> >
> > yes, and we want to keep it that way.
> >
> > thanks,
> > Peter
> >
> >
> >  >
> >  > I would suggest to at minimum present this draft to IDR and gets
> the
> >  > feedback from the IDR WG.
> >  >
> >  > --Bruno
> >  >
> >  >
> >
>  
> 
> >  > Ce message et ses pieces jointes peuvent contenir des
> > informations confidentielles ou privilegiees et ne doivent donc
> >  > pas etre diffuses, exploites ou copies sans autorisation. Si vous
> > avez recu ce message par erreur, veuillez le signaler
> >  > a l'expedite

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce

[Robert Raszuk]

Hey Peter,

I think the point Bruno is making is valid ... Imagine dual or triple
vendor network and hop by hop routing (no end to end SAFI).

That means that all nodes should be in synch in terms to react on UPA,

Of course you will say that this is up to wise operator to enable it only
when it makes sense ... but I think the point is still valid and clearly
for none tunneled networks (if ever to use UPA) this is NOT a local
decision,

For vast majority it is local as forwarding is using some sort of PE-PE
encapsulation.

Cheers,
R.


On Tue, Jul 25, 2023 at 9:11 AM Peter Psenak  wrote:

> Bruno,
>
> On 25/07/2023 14:39, bruno.decra...@orange.com wrote:
> > Hi all,
> >
> > IP reachability advertised by IS-IS is often used by other routing and
> > signaling protocols (e.g., BGP, PIM (rpf vector) LDP, RSVP-TE...). As
> > such, UPA may affect those protocols.
> >
> > Has UPA been presented in other WGs in the routing areas?
> >
> > I believe this would be prudent if not required.
>
> why do you believe so? How is this different to an IGP prefix becoming
> unreachable without UPA?
>
> >
> > In particular, BGP is (heavily) using reachability of (loopbacks)
> > addresses advertised in IS-IS in order to evaluate the reachability of
> > BGP routes and compute their preference.
> >
> > If UPA is not interpreted the same ways by all routers, forwarding loops
> > may occur in a hop by hop routed network. (because different routers
> > would select different paths since they use different information to
> > select their path)
>
> I don't see a problem, please provide an example.
> If an ingress PE decides to switch to an alternate BGP path, how does
> that creates any potential loop? And why all egress PEs would need to do
> the same?
>
> >
> > This is not considered nor discussed in the draft. Quite the contrary,
> > draft says that recognition, processing and use of UPA is a local
> > consideration.
>
> yes, and we want to keep it that way.
>
> thanks,
> Peter
>
>
> >
> > I would suggest to at minimum present this draft to IDR and gets the
> > feedback from the IDR WG.
> >
> > --Bruno
> >
> >
> 
> > Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
> recu ce message par erreur, veuillez le signaler
> > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> > Orange decline toute responsabilite si ce message a ete altere, deforme
> ou falsifie. Merci.
> >
> > This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> > they should not be distributed, used or copied without authorisation.
> > If you have received this email in error, please notify the sender and
> delete this message and its attachments.
> > As emails may be altered, Orange is not liable for messages that have
> been modified, changed or falsified.
> > Thank you.
> >
>
> ___
> 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] IETF-116 LSR - IGP extensions for Advertising Offset forFlex-Algorithm

[Robert Raszuk]

Sorry but I do not see how 1 label will allow me to steer packets via 5
different segment nodes and on each apply specific PHB. I am not taking
about FA based forwarding but SR-TE with PHB.

Thx,
R.

On Thu, Apr 13, 2023 at 4:42 PM Louis Chan  wrote:

> Hi Robert,
>
>
>
> In this case, the minimum is 1 transport label.
>
>
>
> In slide 5, for R116, the FA129 label is 402116. If the packet is sent
> from R106 to R116, the only transport label needed is 402116. Each transit
> node in the path only check the top label, which is found within 402xxx
> range, and apply QOS.
>
>
>
> In case of TI-LFA or SR-TE with FA129 labels, there is chance that some
> Adj-SID’s are used. That is why this draft is needed.
>
>
>
> e.g. If a packet arrives at R109 with R109’s local label range 2xxx as top
> label,  R109 will immediately know this is FA129 related. QOS is then
> applied at ingress or egress.
>
> i.e. 2xxx refers to PHB, and xxx refers to the exit interface.
>
>
>
> Hope this is clear.
>
>
>
> /louis
>
>
>
> *From:* Robert Raszuk 
> *Sent:* Thursday, April 13, 2023 9:44 PM
> *To:* Louis Chan 
> *Cc:* linchangwang ; Peter Psenak <
> ppse...@cisco.com>; 程伟强 ; Les Ginsberg
> (ginsbe ; Acee Lindem ; lsr <
> lsr@ietf.org>; Krzysztof Szarkowicz 
> *Subject:* Re: [Lsr] IETF-116 LSR - IGP extensions for Advertising Offset
> forFlex-Algorithm
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Louis,
>
>
>
> I must be missing something obvious ...
>
>
>
> Consider the SR-MPLS case and 5 nodes on which I need specific PHB. Does
> this mean that each packet requires at least *10 labels* on the stack
> imposed on ingress ?
>
>
>
> Many thx,
>
> R.
>
>
>
>
>
>
>
>
>
> On Thu, Apr 13, 2023 at 3:35 PM Louis Chan  40juniper@dmarc.ietf.org> wrote:
>
> Hi ChangWang,
>
> For #2, your interpretation is quite close.
>
> Re-visit slide 8. For QOS, local adj-sid are interpreted based on range
>
> 2xxx - FA129 related
> 6xxx - VFA600 related
> 7xxx - VFA601 related
>
> The current node, just examine the top label, could do policing at
> ingress, and pass it to the right queue at egress interface.
>
> Without Flex-Algo, the working mechanism for VFA/Pizza is the same.
>
> /Louis
>
>
>
>
> -Original Message-
> From: linchangwang 
> Sent: Thursday, April 13, 2023 6:04 PM
> To: Peter Psenak ; Louis Chan ; 程伟强
> ; Les Ginsberg (ginsbe ;
> Acee Lindem 
> Cc: lsr ; Krzysztof Szarkowicz 
> Subject: RE: [Lsr] IETF-116 LSR - IGP extensions for Advertising Offset
> forFlex-Algorithm
>
> [External Email. Be cautious of content]
>
>
> Hi Peter ,
>
>  I don't agree that adj sid is not a major contributor.
>  Specifically, we can look at the following two scenarios:
>
> 1) flex-algo scenarios:
>   When deploying SR-TE or SRv6 TE, only ADJ-SID on this interface will
> increase with the number of flex algos increased, so we need to optimize
> this advertise.
>
> 2) without flex-algo scenarios:
>   In scenarios where flex algo is not deployed, the space of LSP can also
> be greatly reduced through the VFA mechanism.
>   I think one usage scenario for VFA is as follows:
>
>
>  
> DUT1--DUT2-DUT3
>   Interface 1interface 1   interface 2
>
> Vfa1---vfa1vfa1vfa1
> Vfa2---vfa2
> vfa2vfa2
> Vfa3---vfa3
> vfa3vfa3
> Vfa4- -vfa4
> vfa4vfa4
>
>  Vfa:  maybe cpu-queue on interface, assign one ADJ-SID to one VFA1
>
>Each label or srv6 end.x sid corresponds to a queue, and VFAR labels
> are arranged in the sr policy to achieve SR-TE traffic scheduling
>
>So , this draft with offset would reduce the refresh requirement.
>
> Regards,
> Changwang
>
>
>
> -Original Message-
> From: Peter Psenak [mailto:ppse...@cisco.com]
> Sent: Thursday, April 13, 2023 5:09 PM
> To: Louis Chan; linchangwang (RD); 程伟强; Les Ginsberg (ginsbe; Acee Lindem
> Cc: lsr; Krzysztof Szarkowicz
> Subject: Re: [Lsr] IETF-116 LSR - IGP extensions for Advertising Offset
> forFlex-Algorithm
>
> Loius,
>
> there are many reasons why we need to advertise additional data for
> adjacency - TE being a major one. You are trying to optimize the Adj-SID
> only, w

Re: [Lsr] IETF-116 LSR - IGP extensions for Advertising Offset forFlex-Algorithm

[Robert Raszuk]

Louis,

I must be missing something obvious ...

Consider the SR-MPLS case and 5 nodes on which I need specific PHB. Does
this mean that each packet requires at least *10 labels* on the stack
imposed on ingress ?

Many thx,
R.




On Thu, Apr 13, 2023 at 3:35 PM Louis Chan  wrote:

> Hi ChangWang,
>
> For #2, your interpretation is quite close.
>
> Re-visit slide 8. For QOS, local adj-sid are interpreted based on range
>
> 2xxx - FA129 related
> 6xxx - VFA600 related
> 7xxx - VFA601 related
>
> The current node, just examine the top label, could do policing at
> ingress, and pass it to the right queue at egress interface.
>
> Without Flex-Algo, the working mechanism for VFA/Pizza is the same.
>
> /Louis
>
>
>
>
> -Original Message-
> From: linchangwang 
> Sent: Thursday, April 13, 2023 6:04 PM
> To: Peter Psenak ; Louis Chan ;
> 程伟强 ; Les Ginsberg (ginsbe <
> ginsb...@cisco.com>; Acee Lindem 
> Cc: lsr ; Krzysztof Szarkowicz 
> Subject: RE: [Lsr] IETF-116 LSR - IGP extensions for Advertising Offset
> forFlex-Algorithm
>
> [External Email. Be cautious of content]
>
>
> Hi Peter ,
>
>  I don't agree that adj sid is not a major contributor.
>  Specifically, we can look at the following two scenarios:
>
> 1) flex-algo scenarios:
>   When deploying SR-TE or SRv6 TE, only ADJ-SID on this interface will
> increase with the number of flex algos increased, so we need to optimize
> this advertise.
>
> 2) without flex-algo scenarios:
>   In scenarios where flex algo is not deployed, the space of LSP can also
> be greatly reduced through the VFA mechanism.
>   I think one usage scenario for VFA is as follows:
>
>
>  
> DUT1--DUT2-DUT3
>   Interface 1interface 1   interface 2
>
> Vfa1---vfa1vfa1vfa1
> Vfa2---vfa2
> vfa2vfa2
> Vfa3---vfa3
> vfa3vfa3
> Vfa4- -vfa4
> vfa4vfa4
>
>  Vfa:  maybe cpu-queue on interface, assign one ADJ-SID to one VFA1
>
>Each label or srv6 end.x sid corresponds to a queue, and VFAR labels
> are arranged in the sr policy to achieve SR-TE traffic scheduling
>
>So , this draft with offset would reduce the refresh requirement.
>
> Regards,
> Changwang
>
>
>
> -Original Message-
> From: Peter Psenak [mailto:ppse...@cisco.com]
> Sent: Thursday, April 13, 2023 5:09 PM
> To: Louis Chan; linchangwang (RD); 程伟强; Les Ginsberg (ginsbe; Acee Lindem
> Cc: lsr; Krzysztof Szarkowicz
> Subject: Re: [Lsr] IETF-116 LSR - IGP extensions for Advertising Offset
> forFlex-Algorithm
>
> Loius,
>
> there are many reasons why we need to advertise additional data for
> adjacency - TE being a major one. You are trying to optimize the Adj-SID
> only, which is not the major contributor anyway. The problem is not
> specific to Adj-SID.
>
> In terms of convergence, if you are worried about the flooding speed,
> there is a draft in progress:
>
>
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-fast-flooding/__;!!NEt6yMaO-gk!Czo2RBiwF_5gMcXG53UyV8Wkh4fKLEl_Sfv1uSpVhhltc1dqF_gl6Hk3u6XedMpZUKPytJDEQVGMrnJx6wW3cbHsfw$
>
> thanks,
> Peter
>
>
>
> On 13/04/2023 10:52, Louis Chan wrote:
> > Hi Peter/all,
> >
> > Here I do a simple analysis on this scaling issue.
> >
> > 1. Assume a network with these parameters
> > - 20 x Flex-algo
> > - 2 x core nodes with 1,000 links
> > - network diameter with 5 hops
> >
> > 2. Just check out the additional advertisement size from core nodes
> following ChangWang example.
> >
> > For 1 core node,
> > n x 20 x 1000
> > MPLS-SR：If n = 10 bytes, it is 200K bytes per core node
> >
> > With 2 core nodes, it is 400KB in total
> >
> > LSP num: 400KB/1500 = 267 lsps, at least
> >
> > 3. About the delivery/flooding rate, from
> > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-iet
> > f-lsr-isis-fast-flooding/__;!!NEt6yMaO-gk!Czo2RBiwF_5gMcXG53UyV8Wkh4fK
> > LEl_Sfv1uSpVhhltc1dqF_gl6Hk3u6XedMpZUKPytJDEQVGMrnJx6wW3cbHsfw$
> 
> >As IS-IS is deployed in greater scale both in the number of nodes in
> > an area and in the number of neighbors per node, the impact of the
> > historic flooding rates becomes more significant.  Consider the
> > bringup or failure of a node with 1000 neighbors.  This will result
> <--- 1000 adj links
> > in a minimum of 1000 LSP updates.  At typical LSP flooding rates
> used<--- imply 1000 LSP updates
> > today (33 LSPs/second), it would take 30+ seconds simply to send
> the <--- 33lsp/s
> > updated LSPs to a given neighbor.  Depending on the diameter of the
> > network, achieving a consistent LSDB on all nodes in the network
> > could easily take a minute or more.
> 

Re: [Lsr] IETF-116 LSR - IGP extensions for Advertising Offset forFlex-Algorithm

[Robert Raszuk]

Jie,

Your Enhanced VPN documents are very well written - thx for sharing
the pointer to them. However I don't think I would put NRP as a new
Extension Header for IPv6 data plane or Post Stack Data for MPLS data plane
to indicate PHB in the packets.

I think there are better alternatives which do not require hardware
extensions or modification.

Thx,
Robert.


On Thu, Apr 13, 2023 at 1:24 PM Dongjie (Jimmy)  wrote:

> Hi Krzysztof,
>
>
>
> If my understanding is correct, you and Louis are considering about two
> separate optimizations:
>
>
>
> 1.  Allowing multiple “Virtual Flex-Algos” to share the SPF
> calculation of one “legacy” Flex-Algo.
>
>
>
> This can be addressed by the mechanisms described in section 2 of
> https://datatracker.ietf.org/doc/html/draft-dong-lsr-sr-enhanced-vpn-08.
>
>
>
> More specifically, that document allows multiple NRPs to associate with
> the same Flex-Algo, so that the Flex-Algo computation could be reused. NRP
> is used to represent different set of network resources, and Flex-Algo is
> still used to specify the topology and computation constraints for the NRP.
> In that way, no change to Flex-Algo is needed.
>
>
>
> 2.  Reducing the amount of SR SIDs which are used to indicate
> different set of bandwidth reservation.
>
>
>
> The approach of using SR SIDs to represent different set of network
> resources is suitable for networks in which the number of NRPs are
> relatively small. As the number of NRPs increases, there will be
> scalability challenge not only in the control plane but also in the data
> plane. In that case, a more scalable and IGP friendly approach is to
> introduce a network-wide NRP ID into the packet. This is also described in
> section 5.3 of draft-dong-lsr-sr-enhanced-vpn-08.
>
>
>
> Hope this helps.
>
>
>
> Best regards,
>
> Jie
>
>
>
> *From:* Lsr  *On Behalf Of *Krzysztof Szarkowicz
> *Sent:* Wednesday, April 12, 2023 11:42 PM
> *To:* Robert Raszuk 
> *Cc:* linchangwang ; Acee Lindem <
> acee.i...@gmail.com>; Peter Psenak ; 程伟强 <
> chengweiqi...@chinamobile.com>; Louis Chan ; Les
> Ginsberg (ginsbe ; lsr 
> *Subject:* Re: [Lsr] IETF-116 LSR - IGP extensions for Advertising Offset
> forFlex-Algorithm
>
>
>
> Hi,
>
>
>
> It is the question, if we could for example have more than 20 (e.g. 200),
> for 200 different service bandwidth guarantees (but having only one - or
> handful - SPF calculation domains, where one SPF calculation domain is one
> ‘legacy’ flex-algo ). The challenge is with SPP calculations, once the
> number of flex-algos goes high.
>
>
>
> Thanks,
>
> Krzysztof
>
>
>
>
>
> On 2023 -Apr-12, at 17:13, Robert Raszuk  wrote:
>
>
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
>
>
>
>
> Ok you can use 20 flex algos today with no extension. Is going to another
> level of nesting really necessary ?
>
>
>
> On Wed, Apr 12, 2023 at 4:52 PM linchangwang 
> wrote:
>
> Hi Acee
>
>
>
> An operator's backbone network is divided into different flex algorithms
> planes according to different SLA requirements of users.
>
> A flex algo represents a service requirement, such as bandwidth
> requirements.
>
> 20 flex algorithms represent 20 different service bandwidth guarantees,
> corresponding to different resource requirements.
>
>
>
> Thanks,
>
> Changwang lin
>
>
>
> *From:* Acee Lindem [mailto:acee.i...@gmail.com]
> *Sent:* Wednesday, April 12, 2023 10:12 PM
> *To:* Peter Psenak
> *Cc:* linchangwang (RD); 程伟强; Louis Chan; Les Ginsberg (ginsbe; lsr;
> Krzysztof Szarkowicz
> *Subject:* Re: [Lsr] IETF-116 LSR - IGP extensions for Advertising Offset
> forFlex-Algorithm
>
>
>
> Hi Weiqiang,
>
>
>
> I’m also curious as to how you are using 20 different flex algorithms. Is
> this just a hypothetical scenario
>
> to illustrate the mathematics or do you have an actual use case?
>
>
>
> On Apr 12, 2023, at 09:31, Peter Psenak  wrote:
>
>
>
> Changwang,
>
> please see inline (##PP2):
>
>
> On 12/04/2023 15:13, linchangwang wrote:
>
> Hi Peter
>  Please see inline [changwang lin].
>
> We've met the same problem when applying Flex Algo in SRv6 network.
>
> what problem exactly, can you please describe it?
> [changwang lin]
> Advertisement size of per Flex-Algo Adj-SID in the network
> Related to F(# of node, # of FA, # of links)
> For a node with 1,000 links and 20 Flex-Algo
>n x 20 x 1000
>MPLS-SR：If n = 10 bytes, it is 200K bytes
>SRv6：   If n = 24 bytes, it is 400K+ bytes
> If 500 nodes:
>MPLS-SR：it i

Re: [Lsr] IETF-116 LSR - IGP extensions for Advertising Offset forFlex-Algorithm

[Robert Raszuk]

Krzysiek,

Then let's call it by it's name - you want packet marking to represent
different PHB at segment endpoints.

Yes that may be a valid ask. Not sure if we should embed this in SIDs.
Remember SRH has space for additional function parameters and not
everything needs to be placed into SID or uSID.

Bottom line is that this has nothing to do with Flex-Algos what so ever :)

Cheers,
R.



On Wed, Apr 12, 2023 at 5:41 PM Krzysztof Szarkowicz <
kszarkow...@juniper.net> wrote:

> Hi,
>
> It is the question, if we could for example have more than 20 (e.g. 200),
> for 200 different service bandwidth guarantees (but having only one - or
> handful - SPF calculation domains, where one SPF calculation domain is one
> ‘legacy’ flex-algo ). The challenge is with SPP calculations, once the
> number of flex-algos goes high.
>
> Thanks,
> Krzysztof
>
>
> On 2023 -Apr-12, at 17:13, Robert Raszuk  wrote:
>
>
> [External Email. Be cautious of content]
>
>
>
> Ok you can use 20 flex algos today with no extension. Is going to another
> level of nesting really necessary ?
>
> On Wed, Apr 12, 2023 at 4:52 PM linchangwang 
> wrote:
>
>> Hi Acee
>>
>>
>>
>> An operator's backbone network is divided into different flex algorithms
>> planes according to different SLA requirements of users.
>>
>> A flex algo represents a service requirement, such as bandwidth
>> requirements.
>>
>> 20 flex algorithms represent 20 different service bandwidth guarantees,
>> corresponding to different resource requirements.
>>
>>
>>
>> Thanks,
>>
>> Changwang lin
>>
>>
>>
>> *From:* Acee Lindem [mailto:acee.i...@gmail.com]
>> *Sent:* Wednesday, April 12, 2023 10:12 PM
>> *To:* Peter Psenak
>> *Cc:* linchangwang (RD); 程伟强; Louis Chan; Les Ginsberg (ginsbe; lsr;
>> Krzysztof Szarkowicz
>> *Subject:* Re: [Lsr] IETF-116 LSR - IGP extensions for Advertising
>> Offset forFlex-Algorithm
>>
>>
>>
>> Hi Weiqiang,
>>
>>
>>
>> I’m also curious as to how you are using 20 different flex algorithms. Is
>> this just a hypothetical scenario
>>
>> to illustrate the mathematics or do you have an actual use case?
>>
>>
>>
>> On Apr 12, 2023, at 09:31, Peter Psenak  wrote:
>>
>>
>>
>> Changwang,
>>
>> please see inline (##PP2):
>>
>>
>> On 12/04/2023 15:13, linchangwang wrote:
>>
>> Hi Peter
>>  Please see inline [changwang lin].
>>
>> We've met the same problem when applying Flex Algo in SRv6 network.
>>
>> what problem exactly, can you please describe it?
>> [changwang lin]
>> Advertisement size of per Flex-Algo Adj-SID in the network
>> Related to F(# of node, # of FA, # of links)
>> For a node with 1,000 links and 20 Flex-Algo
>>n x 20 x 1000
>>MPLS-SR：If n = 10 bytes, it is 200K bytes
>>SRv6：   If n = 24 bytes, it is 400K+ bytes
>> If 500 nodes:
>>MPLS-SR：it is 200K*500   =  10k bytes
>>SRv6：   it is 400K+ * 500  = 20k bytes
>> If interface mtu=1500, lsp length = 1497
>>  LSPs num:
>>MPLS-SR：1k bytes/1497 = 66800  lsps
>>SRv6：   2k bytes/1497 = 160320 lsps
>> The number of LSPs is too large, and IS-IS needs to periodically refresh
>> LSPs,
>> resulting in a decrease in ISIS performance and unstable network
>> operation.
>>
>>
>> ##PP2
>> above is hardly a realistic estimation.
>>
>> In a network with 1k nodes, not every node will have 1k links.
>>
>> Advertising large number of LSPs is not caused by Adj-SIDs.
>> With TE enabled the amount of data flooded per link is larger than
>> advertisement of the 20 Adj-SID. The problem you are highlighting is not
>> specific to Adj-SIDs, it's generic.
>>
>> LSP refresh time can be set to 18 hours and any reasonable implementation
>> does not refresh all LSPs at the same time.
>>
>>
>> So we need to optimize on the control surface to save LSP space.
>>
>>
>> ##PP2
>> with all the respect, I don't agree. The problem as you described it does
>> not exist.
>>
>>
>> Through the optimization notification mechanism mentioned in these two
>> documents,
>> we have greatly saved LSP space for IS-IS and improved the performance of
>> IS-IS flex algo in large-scale networking.
>> At the same time, through the VFA mechanism, in other non flex algo
>> application scenarios,
>>  such as network slicing scenarios, the LSP space of IS-IS can also be
>> saved
>>
>>

Re: [Lsr] IETF-116 LSR - IGP extensions for Advertising Offset forFlex-Algorithm

[Robert Raszuk]

Ok you can use 20 flex algos today with no extension. Is going to another
level of nesting really necessary ?

On Wed, Apr 12, 2023 at 4:52 PM linchangwang 
wrote:

> Hi Acee
>
>
>
> An operator's backbone network is divided into different flex algorithms
> planes according to different SLA requirements of users.
>
> A flex algo represents a service requirement, such as bandwidth
> requirements.
>
> 20 flex algorithms represent 20 different service bandwidth guarantees,
> corresponding to different resource requirements.
>
>
>
> Thanks,
>
> Changwang lin
>
>
>
> *From:* Acee Lindem [mailto:acee.i...@gmail.com]
> *Sent:* Wednesday, April 12, 2023 10:12 PM
> *To:* Peter Psenak
> *Cc:* linchangwang (RD); 程伟强; Louis Chan; Les Ginsberg (ginsbe; lsr;
> Krzysztof Szarkowicz
> *Subject:* Re: [Lsr] IETF-116 LSR - IGP extensions for Advertising Offset
> forFlex-Algorithm
>
>
>
> Hi Weiqiang,
>
>
>
> I’m also curious as to how you are using 20 different flex algorithms. Is
> this just a hypothetical scenario
>
> to illustrate the mathematics or do you have an actual use case?
>
>
>
> On Apr 12, 2023, at 09:31, Peter Psenak  wrote:
>
>
>
> Changwang,
>
> please see inline (##PP2):
>
>
> On 12/04/2023 15:13, linchangwang wrote:
>
> Hi Peter
>  Please see inline [changwang lin].
>
> We've met the same problem when applying Flex Algo in SRv6 network.
>
> what problem exactly, can you please describe it?
> [changwang lin]
> Advertisement size of per Flex-Algo Adj-SID in the network
> Related to F(# of node, # of FA, # of links)
> For a node with 1,000 links and 20 Flex-Algo
>n x 20 x 1000
>MPLS-SR：If n = 10 bytes, it is 200K bytes
>SRv6：   If n = 24 bytes, it is 400K+ bytes
> If 500 nodes:
>MPLS-SR：it is 200K*500   =  10k bytes
>SRv6：   it is 400K+ * 500  = 20k bytes
> If interface mtu=1500, lsp length = 1497
>  LSPs num:
>MPLS-SR：1k bytes/1497 = 66800  lsps
>SRv6：   2k bytes/1497 = 160320 lsps
> The number of LSPs is too large, and IS-IS needs to periodically refresh
> LSPs,
> resulting in a decrease in ISIS performance and unstable network operation.
>
>
> ##PP2
> above is hardly a realistic estimation.
>
> In a network with 1k nodes, not every node will have 1k links.
>
> Advertising large number of LSPs is not caused by Adj-SIDs.
> With TE enabled the amount of data flooded per link is larger than
> advertisement of the 20 Adj-SID. The problem you are highlighting is not
> specific to Adj-SIDs, it's generic.
>
> LSP refresh time can be set to 18 hours and any reasonable implementation
> does not refresh all LSPs at the same time.
>
>
> So we need to optimize on the control surface to save LSP space.
>
>
> ##PP2
> with all the respect, I don't agree. The problem as you described it does
> not exist.
>
>
> Through the optimization notification mechanism mentioned in these two
> documents,
> we have greatly saved LSP space for IS-IS and improved the performance of
> IS-IS flex algo in large-scale networking.
> At the same time, through the VFA mechanism, in other non flex algo
> application scenarios,
>  such as network slicing scenarios, the LSP space of IS-IS can also be
> saved
>
>
> ##PP2
> it seems to me you are trying to fix the implementation problem with the
> protocol changes, which is never a good idea.
>
> thanks,
> Peter
>
>
> thanks,
> Changwang lin
> -Original Message-
> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak
> Sent: Wednesday, April 12, 2023 7:10 PM
> To: 程伟强; Louis Chan; Les Ginsberg (ginsbe; Acee Lindem
> Cc: lsr; Krzysztof Szarkowicz
> Subject: Re: [Lsr] IETF-116 LSR - IGP extensions for Advertising Offset
> forFlex-Algorithm
> Weiqiang,
> please see inline (##PP):
> On 12/04/2023 12:05, 程伟强 wrote:
>
> Hi Louis and Les,
>
>
> My two cents from operator perspective.
>
>
> We've met the same problem when applying Flex Algo in SRv6 network.
>
> what problem exactly, can you please describe it?
> [changwang lin]
> Advertisement size of per Flex-Algo Adj-SID in the network
> Related to F(# of node, # of FA, # of links)
> For a node with 1,000 links and 20 Flex-Algo
>n x 20 x 1000
>MPLS-SR：If n = 10 bytes, it is 200K bytes
>SRv6：   If n = 24 bytes, it is 400K+ bytes
> If 500 nodes:
>MPLS-SR：it is 200K*500   =  10k bytes
>SRv6：   it is 400K+ * 500  = 20k bytes
> If interface mtu=1500, lsp length = 1497
>  LSP num:
>MPLS-SR：1k bytes/1497 = 66800  lsps
>SRv6：   2k bytes/1497 = 160320 lsps
> The number of LSPs is too large, and IS-IS needs to periodically refresh
> LSPs,
> resulting in a decrease in ISIS performance and unstable network operation.
> So we need to optimize on the control surface to save LSP space.
> Through the optimization notification mechanism mentioned in these two
> documents,
> we have greatly saved LSP space for IS-IS and improved the performance of
> IS-IS flex algo in large-scale networking.
> At the same time, through the VFA mechanism, in other non flex algo
> 

Re: [Lsr] IETF-116 LSR - IGP extensions for Advertising Offset forFlex-Algorithm

[Robert Raszuk]

> Number of LSPs in the entire network: 140 * 20 * 32 * 200/1497=12000 LSPs
>
> The performance of IGP has always been affected by the size of the entire
> network's LSDB,
> and even if the periodic flooding time is reduced, there will still be
> convergence issues.


How total number of LSPs in the entire network matter for convergence ?

When link goes down adjacent nodes sitting on this link flood.

If node goes down adjacent nodes to the failed node flood.

Practically the large numbers look indeed scary on slides but have no real
meaning in real operation.

I also do not agree with your assertion that IGP performance is a function
of entrie network's LSDB. Lot's of optimizations went into decent
implementations of IGPs that total size of LSDB does not really matter.

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

Re: [Lsr] UPA and planned/unplanned signalling

[Robert Raszuk]

Hi Shraddha,

So are you saying that ABR will inject UPA with U Flag when it notices
unreachability and it will inject UP Flag when it notices Max Metric ?

And the remote end point receiving UPA will still in both cases result in
identical action ?

Thx,
R

On Mon, Mar 27, 2023 at 9:25 PM Shraddha Hegde  wrote:

> Hi Les,
>
> Pls see inline for replies.
>
>
> Juniper Business Use Only
>
> -Original Message-
> From: Les Ginsberg (ginsberg) 
> Sent: Tuesday, March 28, 2023 9:10 AM
> To: Shraddha Hegde ; lsr@ietf.org
> Subject: UPA and planned/unplanned signalling
>
> [External Email. Be cautious of content]
>
>
> Shraddha -
>
> To follow up on our discussion over chat at the LSR meeting yesterday...
>
> At a remote ABR, if BGP had already been told about a planned node
> maintenance event (by means that is outside the scope of the UPA draft),
> then BGP would have moved traffic away from the node on which the
> maintenance event is scheduled in advance of the arrival of the UPA
> advertisement. In such a case the arrival of the UPA advertisement would be
> of no significance. Since traffic has already moved away it does not matter
> whether BGP processes the UPA or does not.
>
> If, however, BGP had NOT been told about planned maintenance in advance,
> the arrival of the UPA should be treated in the same way regardless of
> whether the trigger was a planned maintenance event or not. The node
> associated with the address advertised in the UPA has become unreachable
> and BGP needs to act accordingly.
>  This is the case when BGP is not aware of the planned maintenance and
> is learning that info from IGP.
> You are right that the final outcome of the planned maintenance vs
> unreachability is same that the traffic needs to be moved away
> >From the remote PE. The difference is in how that is achieved. In case of
> unreachability, the action need to be immediate and mechanisms such as
> BGP-PIC needed. In case of planned maintenance,  it would just be costing
> out
> Igp metric for the PE and hence the control plane convergence.
> There may be implementations which just choose to trigger one mechanisms
> for both scenarios and draft does not
> Mandate/suggest any of this and is left to implementations.
>
>
>
> I therefore see no value add in differentiating between planned/unplanned
> in the UPA advertisement.
>
> I hope this is clear.
> Please point out what I might have missed.
>
> Thanx.
>
>Les
>
> ___
> 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] [Editorial Errata Reported] RFC9350 (7406)

[Robert Raszuk]

Hi Barry,

Looks like RFC Editor expanded the "LSP" abbreviation as version -26 (last
before publication) says this:

*   The IS-IS FAD Sub-TLV MAY be advertised in an LSP of any number.*  IS-
   IS router MAY advertise more than one IS-IS FAD Sub-TLV for a given
   Flexible Algorithm (see Section 6).


Rgs,
R.


On Mon, Mar 27, 2023 at 8:34 PM RFC Errata System 
wrote:

> The following errata report has been submitted for RFC9350,
> "IGP Flexible Algorithm".
>
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid7406
>
> --
> Type: Editorial
> Reported by: Barry Friedman 
>
> Section: 5.1
>
> Original Text
> -
> The IS-IS FAD sub-TLV MAY be advertised in a
> Label Switched Path (LSP) of any number.
>
> Corrected Text
> --
> The IS-IS FAD sub-TLV MAY be advertised in a
> Link State PDU (LSP) of any number.
>
> Notes
> -
> I assume LSP is meant to refer to the PDU carrying the FAD, not a Label
> Switched Path.
>
> 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.
>
> --
> RFC9350 (draft-ietf-lsr-flex-algo-26)
> --
> Title   : IGP Flexible Algorithm
> Publication Date: February 2023
> Author(s)   : P. Psenak, Ed., S. Hegde, C. Filsfils, K.
> Talaulikar, A. Gulko
> Category: PROPOSED STANDARD
> Source  : Link State Routing
> Area: Routing
> Stream  : IETF
> Verifying Party : IESG
>
> ___
> 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] draft-ppsenak-lsr-igp-ureach-prefix-announce

[Robert Raszuk]

> All it does that it advertises UPA for  prefixes that are summarized on
it and change from reachable to unreachable

Ok but this is a bit too vague,

If my ABR disconnects from an area nodes it should remove the summary and
not inject possibly 100s or 1000s of UPAs. And IMO the draft should
describe this procedure in detail.

Thx,
R

On Mon, Mar 27, 2023 at 8:07 AM Peter Psenak  wrote:

> Robert,
>
> On 27/03/2023 16:57, Robert Raszuk wrote:
> > Hi Peter,
> >
> >  >  4. Is an UPA for a /24 equivalent to 255 UPA for /32? (i.e. will
> >  > trigger BGP PIC edge for 255 /32)
> >
> > no. For BGP PIC to be triggered by UPA, the UPA must be sent for the
> > prefix that is used to resolve BGP prefixes. But the treatment of the
> > UPA is outside of the scope.
> >
> >
> > "UPA must be sent for the prefix that is used to resolve BGP prefixes."
> >
> > Are you saying that UPA is only /32 or /128 ?
>
> I have not said that.
>
>
> >
> > So if my PE has /64 loopback and I use it for next hops I can not send
> > UPA for /64 ?
>
> sure you can.
>
> > And how would ABR know what I am using as BGP next hops if
> > it may not even run service BGP at all ?
>
> it does not need to know. All it does that it advertises UPA for
> prefixes that are summarized on it and change from reachable to
> unreachable. If you use /32 as BGP HN and it is covered by the summary,
> when you receive UPA for that /32 you may decide to activate PIC. Same
> is true if you resolve over /64 locator instead of /32. Again, all this
> is up to the implementation. All that drafts specifies is the indication
> of the unreachability from the summarization point.
>
> Peter
>
> >
> > Thx.
> > R.
> >
> >
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce

[Robert Raszuk]

>
> Hi Peter,
>


> >  4. Is an UPA for a /24 equivalent to 255 UPA for /32? (i.e. will
> > trigger BGP PIC edge for 255 /32)
>
> no. For BGP PIC to be triggered by UPA, the UPA must be sent for the
> prefix that is used to resolve BGP prefixes. But the treatment of the
> UPA is outside of the scope.


"UPA must be sent for the prefix that is used to resolve BGP prefixes."

Are you saying that UPA is only /32 or /128 ?

So if my PE has /64 loopback and I use it for next hops I can not send UPA
for /64 ? And how would ABR know what I am using as BGP next hops if it may
not even run service BGP at all ?

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

Re: [Lsr] Interdomain UPA & UP Flag

[Robert Raszuk]

Hi Peter,

While perhaps one could argue on the benefits for UPA in single domain IMO
the same benefits hardly apply in multi-domain case.

Reason being that this is just a pulse and whatever event (and local domain
flooding) triggered UPA it should be able to also trigger withdrawal of
service routes from BGP.  Those can be aggregated or even atomic - no
issue.

Note that there were valid concerns in respect to flooding UPA domain wide
where there is network failure triggering it. Now we are talking about
triggering a much wider UPA storm as response to local failure. That is
especially worrying as you do not even know if all domains even need such
information.

Clearly a lot of thinking needs to go into this in terms of policy for
triggering UPAs or propagating it across domains.

Last note that some large multi domain networks I know even if using option
C for L3VPNs still go via BGP + Label between ASBRs to propagate all
next hops with labels from IGP+LDP to BGP(3107) and back to IGP+LDP as
natively IGPs do not carry LDP labels. SR-MPLS fixes that, but then you are
running to domains with different IGPs issues and I do not see anything in
the draft which would allow you to take UPA from OSPF domain and inject it
into ISIS core domain then back to OSPF on the remote domain.

Bottom line: sure you can burn a few more codepoints to fix the space for
it. But I think interdomain UPA requires much more work to be of any
practical value and if really needed deserves a standalone doc.

Many thx,
Robert

On Mon, Mar 27, 2023 at 1:39 AM Peter Psenak  wrote:

> Hi Robert,
>
> On 27/03/2023 10:05, Robert Raszuk wrote:
> > Hi,
> >
> > I would like to get more clarification in respect to extending External
> > LSAs for UPA. Area summary use case is pretty clear - but in case of
> > redistribution (typical src of external LSAs) IMO we are going way too
> > far with this. Let's all keep in mind that this is a pulse designed to
> > trigger upper protocol switchover.
> >
> > Needless to say that would work only via one hop by design as
> > redistribution happens via RIB and by definition of UPA unreachable
> > routes are not being installed in RIB in the first place.
>
> there are two cases we need to distinguish:
>
> 1. ASBR is redistributing routes and creating a summary out of that. In
> such case the ASBR may create the UPA for a summarized prefix for which
> it lost reachability in the source domain.
>
> 2. UPA as such is crossing multiple domains with redistribution.
> The fact that UPA is not installed in forwarding does not mean it can
> not be redistributed. How that is done is an implementation detail. The
> whole redistribution is implementation specific.
>
> I let others co-authors to respond to the below, as I'm not entirely
> convinced we need the UP-flag.
>
> thanks,
> Peter
>
> >
> > On the apparently relative terms I do not see a need for the UP Flag.
> > First planned maintenance should be solved by BGP protocol and there are
> > already a number of tools in BGP allowing one to do it.
> >
> > Second, if you say this is needed for BGP free deployments then I
> > question the merit on the basis that UPA is ephemeral and expires say in
> > 120 sec which will not be enough for most planned maintenance work. So
> > if someone insists to add UP Flag it should be not just a bit but also a
> > time or time delta from set UTC where it is expected that provided
> > prefix will be down,
> >
> > Kind regards,
> > R.
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] Interdomain UPA & UP Flag

[Robert Raszuk]

Hi,

I would like to get more clarification in respect to extending External
LSAs for UPA. Area summary use case is pretty clear - but in case of
redistribution (typical src of external LSAs) IMO we are going way too far
with this. Let's all keep in mind that this is a pulse designed to trigger
upper protocol switchover.

Needless to say that would work only via one hop by design as
redistribution happens via RIB and by definition of UPA unreachable routes
are not being installed in RIB in the first place.

On the apparently relative terms I do not see a need for the UP Flag. First
planned maintenance should be solved by BGP protocol and there are already
a number of tools in BGP allowing one to do it.

Second, if you say this is needed for BGP free deployments then I question
the merit on the basis that UPA is ephemeral and expires say in 120 sec
which will not be enough for most planned maintenance work. So if someone
insists to add UP Flag it should be not just a bit but also a time or time
delta from set UTC where it is expected that provided prefix will be down,

Kind regards,
R.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Working Last Call for "Dynamic Flooding on Dense Graphs" - draft-ietf-lsr-dynamic-flooding-12

[Robert Raszuk]

Support

Regards,
R.

On Fri, Feb 24, 2023 at 9:59 PM Acee Lindem  wrote:

> There was a lot of LSR Working Group interest and excellent technical work
> on this draft
> and we’ve decided publish it on the “Experimental” track. We chose that
> track due to the
> complexity and the fact that there is only one known implementation.
>
> This starts the Working Group Last call for
> draft-ietf-lsr-dynamic-flooding-12. Please send your
> support or objection to this before March 11th, 2023.
>
> 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 Optimal Distributed Flooding for Dense Topologies" - draft-white-lsr-distoptflood-03

[Robert Raszuk]

Support

R.

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] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

[Robert Raszuk]

Hi Chris,

> If that means they are installing a negative route then they are
modifying the IP routing table.
> If he meant they don't do anything with the announcement, well then
that's in spec.

There are lots of options between installing negative route in IP routing
table and not doing anything with that.

As example negative route may be passed directly to BGP to invalidate BGP
next hop and trigger a new best path run on a set of routes which happen to
select path with such next hop as best.

That would not require to install negative route anywhere.

Second an implementation may have N RIBs - one of them be negative and be
used for next hop validation. It is clearly not an IP routing table
in terms of IP reachability.

A good test perhaps would be to locally originate ICMP ping to PUA covered
dst from PUA receiving node after getting PUA for 1.1.1.1/32 (before the
timeout) ... If ICMP packets will go out of the box to IGP neighbor as
covered by say summary of 1.1.1.0/24 that means PUA is in spec as IP
routing table is unaltered. If we would not see such packets that would
mean there is base for more discussions and the point you are making
stands.

Cheers,
Robert


On Sun, Nov 13, 2022 at 1:18 PM Christian Hopps  wrote:

>
> Robert Raszuk  writes:
>
> > Chris,
> >
> >> unreachable routes in the IP routing table
>
> That quote leaves zero context at all for what I was saying.
>
> I was replying to Peter saying that implementations are using the max
> metric announcements to avoid sending traffic to overload routers. If that
> means they are installing a negative route then they are modifying the IP
> routing table. If he meant they don't do anything with the announcement,
> well then that's in spec.
>
> Thanks,
> Chris.
>
> >
> > I don't see anywhere in the UPA spec even a hint that those
> > unreachable pulses would be installed in the IP routing table. It
> > seems to be a local implementation choice how ISIS or OSPF would
> > inform other protocols about them.
> >
> > In fact the quote you provided specifically "other than building the
> > normal IP routing table" IMO endorses quite verbatim what Peter
> > claims. They can be used for other purposes then building a
> > reachability table.
> >
> > Thx,
> > R.
> >
> >
> >
> >
> >
> >
> > On Sat, Nov 12, 2022 at 6:47 AM Christian Hopps 
> > wrote:
> >
> >
> >
> > > On Nov 9, 2022, at 2:13 PM, Peter Psenak  > 40cisco@dmarc.ietf.org> wrote:
> > >
> > > On 09/11/2022 14:56, David Lamparter wrote:
> > >> On Wed, Nov 09, 2022 at 01:27:41PM +, Acee Lindem (acee)
> > wrote:
> > >>> I guess I'd like to understand what one would accomplish with
> > further
> > >>> specification of prefix reachable? What requirement would
> > this
> > >>> satisfy? For the use case UPA is designed to handle
> > (triggering BGP
> > >>> PIC or other local action) , I can't see that there would be
> > any case
> > >>> where you wouldn’t want to take this action for an
> > unreachable prefix.
> > >> The problem is that a prefix with metric > 0xfe00 isn't
> > actually an
> > >> unreachable prefix, it's a prefix that doesn't have specific
> > routing
> > >> information associated with it, which in turn allows sticking
> > other data
> > >> into it that might be routing-related but not quite a
> > reachability.
> > >
> > > well, that is your interpretation. For me a prefix with metric
> > > 0xfe00 is unreachable. Implementations use the max-metric
> > today to signal the prefix unreachability - to avoid reaching
> > local/leaked/redistributed prefixes in cases where OL-bit is set
> > on the originator. So we are not doing anything new here really.
> >
> > [as wg-member]
> >
> > But his interpretation seems correct. RFC5305 says specifically
> > that the prefix is not to be used for building the normal IP
> > routing table, that would include not creating/installing
> > blackhole/reject routes in the normal IP routing table.
> >
> >If a prefix is advertised with a metric larger then
> > MAX_PATH_METRIC
> >(0xFE00, see paragraph 3.0), this prefix MUST NOT be
> > considered
> >during the normal SPF computation.  This allows advertisement
> > of a
> >prefix for purposes other than building the normal 

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

[Robert Raszuk]

Chris,

> unreachable routes in the IP routing table

I don't see anywhere in the UPA spec even a hint that those unreachable
pulses would be installed in the IP routing table. It seems to be a local
implementation choice how ISIS or OSPF would inform other protocols about
them.

In fact the quote you provided specifically "other than building the normal
IP routing table" IMO endorses quite verbatim what Peter claims. They can
be used for other purposes then building a reachability table.

Thx,
R.






On Sat, Nov 12, 2022 at 6:47 AM Christian Hopps  wrote:

>
>
> > On Nov 9, 2022, at 2:13 PM, Peter Psenak  40cisco@dmarc.ietf.org> wrote:
> >
> > On 09/11/2022 14:56, David Lamparter wrote:
> >> On Wed, Nov 09, 2022 at 01:27:41PM +, Acee Lindem (acee) wrote:
> >>> I guess I'd like to understand what one would accomplish with further
> >>> specification of prefix reachable? What requirement would this
> >>> satisfy? For the use case UPA is designed to handle (triggering BGP
> >>> PIC or other local action) , I can't see that there would be any case
> >>> where you wouldn’t want to take this action for an unreachable prefix.
> >> The problem is that a prefix with metric > 0xfe00 isn't actually an
> >> unreachable prefix, it's a prefix that doesn't have specific routing
> >> information associated with it, which in turn allows sticking other data
> >> into it that might be routing-related but not quite a reachability.
> >
> > well, that is your interpretation. For me a prefix with metric >
> 0xfe00 is unreachable. Implementations use the max-metric today to
> signal the prefix unreachability - to avoid reaching
> local/leaked/redistributed prefixes in cases where OL-bit is set on the
> originator. So we are not doing anything new here really.
>
> [as wg-member]
>
> But his interpretation seems correct. RFC5305 says specifically that the
> prefix is not to be used for building the normal IP routing table, that
> would include not creating/installing blackhole/reject routes in the normal
> IP routing table.
>
>If a prefix is advertised with a metric larger then MAX_PATH_METRIC
>(0xFE00, see paragraph 3.0), this prefix MUST NOT be considered
>during the normal SPF computation.  This allows advertisement of a
>prefix for purposes other than building the normal IP routing table.
>
> Do the implementations you’re referring to install unreachable routes in
> the IP routing table, seemingly in violation of this?
>
> Thanks,
> Chris.
>
>
> >> I vaguely remember several years back we did indeed implement something
> >> (seriously no memory on details) that resulted in the creation of a new
> >> prefix reachability TLV with some experimental/local sub-TLVs.  These
> >> prefixes did not exist in the IS-IS domain beforehand.  I have no idea
> >> what the operational reality is on the existence of such things, but I
> >> know that /some/ code exists that does this.
> >> To boil this down into the core of the essence and be explicit,
> >> - you can create an IS-IS prefix reachability for some arbitrary prefix,
> >>   and stick > 0xfe00 into the metric, and that won't have any effect
> >>   on the existing IS-IS domain
> >> - this has in fact been done to carry custom bits of information that
> >>   for one reason or another were decided to be routing-related and thus
> >>   make sense to put there
> >> - the assumption for the use case is that there are indeed less specific
> >>   covering prefixes around, providing actual reachability
> >> - any setup doing that would now suddenly have fresh "unreachable"
> >>   semantics attached to something that didn't have them before, which
> >>   breaks things (or rather: prevents enabling/deployment of the UPA
> >>   feature)
> >
> > and why that would be a problem? Such prefix would never be used to for
> resolution of the BGP prefix. So the presence of such unreachable prefix
> would never trigger any action even of the UPA processing was enabled on
> the receiver. I don't see a problem.
> >
> >> - (if those extra prefixes are created with 0x metric, a
> >>   configurable >= limit for UPA does not help either.)
> >
> > again, what is the problem?
> >
> >> Making IS-IS UPA explicit with a bit, sub-TLV, or whatever else is
> >> (IMHO) not a significant cost, and completely eliminates this issue.
> >> The only reason against it (that I can think of) is that the
> >> advertisement might be a little bit larger;  a new sub-TLV or flag bit
> >> should be completely invisible to existing implementations (= I don't
> >> see how this would create compatibility or rollout problems.)
> >
> > I'm afraid, you forgot to consider an operational aspect of the solution.
> >
> > thanks,
> > Peter
> >
> >> Cheers,
> >> -David
> >
> > ___
> > Lsr mailing list
> > Lsr@ietf.org
> > https://www.ietf.org/mailman/listinfo/lsr
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> 

Re: [Lsr] OSPF-GT

[Robert Raszuk]

True !

So when are we shipping DROID ?

Cheers,
R.

On Thu, Nov 10, 2022 at 12:46 PM Tony Li  wrote:

>
> I’d suggest that the IGP is still not a dump truck. Putting labels on the
> side of it doesn’t make the situation better.
>
> I’m opposed to this work.
>
> Tony
>
>
> On Nov 10, 2022, at 3:07 AM, Aijun Wang  wrote:
>
> Agree.
>
> It is simple to put different application information onto different
> planes, but it brings the complex for operator to manage such planes, and
> the inter communication among different planes.
>
> Lacks of deployments for Geninfo in IS-IS can also predict the future fate
> of such approaches in some sense.
>
>
> Aijun Wang
> China Telecom
>
> On Nov 10, 2022, at 10:48, Robert Raszuk  wrote:
>
> 
> Thx Acee ...
>
> Since you mentioned "sparse" and since you highlighted that OSPF is better
> then ISIS for this as it runs over IP I took a risk if not using flooding
> is an option.
>
> Well ... apparently not.
>
> Of course you could build lots of parallel GT planes and still flood in
> each across interested parties for a given type of info present in such a
> plane, but this comes with much more overhead then pub-sub.
>
> Cheers,
> R.
>
>
> On Thu, Nov 10, 2022 at 11:34 AM Acee Lindem (acee) 
> wrote:
>
>> Hi Robert,
>>
>>
>>
>> *From: *Robert Raszuk 
>> *Date: *Wednesday, November 9, 2022 at 10:37 AM
>> *To: *Acee Lindem , lsr 
>> *Subject: *OSPF-GT
>>
>>
>>
>> Hi Acee,
>>
>>
>>
>> The point of sparse GT makes it much more attractive.
>>
>>
>>
>> With that I have two questions/suggestions to make it even more useful.
>>
>>
>>
>> #1 Would you consider adding reflection function to spares mode GT ?
>>
>>
>>
>> Within a flooding scope (e.g., area) , reflection is inherent in the
>> flooding algorithm. One thing that applications will need to specify is
>> whether or not information is re-originated outside the flooding scope
>> (e.g., does the ABR re-originate application LSAs into other areas).
>>
>>
>>
>>
>>
>> #2 If you do #1 would you considet pub-sub model ?
>>
>>
>>
>> I wouldn’t change basic OSPF flooding. So, one could support pub-sub but
>> everyone in the OSPF application routing domain would receive a superset of
>> subscribed information (or the application would have to do something
>> unnatural from an OSPF standpoint to limit the neighbors receiving the
>> information, e.g., dynamically assign areas for unique subscriptions). I
>> think other protocols are better suited to pub-sub.
>>
>>
>>
>> Thanks,
>> Acee
>>
>>
>>
>> Then this could be used for lot's of current use cases ... some of them
>> even discussed today :)
>>
>>
>>
>> Thx
>>
>> R
>>
> ___
> 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] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

[Robert Raszuk]

>
>
> > I think the point of this was that it could be other applications where
> > an ephemeral unreachability notification is useful. For this type of
> > notification, recursive route resolution is the primary application.
> > However, I’ll defer to the authors.
>
> that is correct indeed.
>

Ok that explanation works !

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

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

[Robert Raszuk]

> But BGP service PIC is the use case this draft is targeting?

For many emails on LSR and beyond I got point from authors against using
BGP for such signalling as "BGP may not be running there at all".

So if the draft works *only* with service provided by BGP let's please
state it clearly in the document. This is not my current assumption.

Many thx,
R.



On Thu, Nov 10, 2022 at 11:47 AM Acee Lindem (acee)  wrote:

> Hi Robert,
>
>
>
> *From: *Robert Raszuk 
> *Date: *Thursday, November 10, 2022 at 9:41 AM
> *To: *Peter Psenak 
> *Cc: *Bruno Decraene , David Lamparter <
> equi...@diac24.net>, Acee Lindem , "lsr@ietf.org" <
> lsr@ietf.org>
> *Subject: *Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA
> IS-IS semantics
>
>
>
> Peter,
>
>
>
> > But:
> > - that is nonetheless a change which is non backward compatible with
> people currently using such high metric without the intention to mean UPA
> > - to differentiate different usages (e.g. your UPA, my other usage such
> as "graceful shutdown" (still reachable but will disappear soon), endpoint
> CPU load is 80%...) one
>
> well, the question is whether it would not make sense to trigger UPA for
> the above mentioned usages as well. Because eventually the destination
> is becoming unreachable anyway and I would want my services to reroute
> to alternate egress node. But seems like folks want to have a way to
> differentiate, so I'm not going to argue against it.
>
>
>
> I think You are right if there is a hierarchical service above it.
>
>
>
> But consider flat routing - where there is no BGP service on top. Example
> - some DCs do use flat routing.
>
>
>
> With that I am afraid UPA triggers may not work well (or at all) ...
> especially considering that they are history after the timeout irrespective
> of the remote prefix state.
>
>
>
> But BGP service PIC is the use case this draft is targeting? For example,
> there is no intent to install negative routes throughout the domain.
>
>
>
> Thanks,
> Acee
>
>
>
>
>
> Cheers,
>
> R.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> thanks,
> Peter
>
> > would need to use different metric values that would need to be at least
> locally registered. So why not have the IANA register a flag and avoid each
> network operator to do that job?
> >
> > In all cases, I don't see a reason for UPA to change the meaning of all
> the metric values >0xFE00. You can pick a single value (e.g.
> 0xFE01) and that would equally work for your use case.
> >
> > Regards,
> > --Bruno
> >
> >
> >
> >
> >>
> >>>
> >>> I vaguely remember several years back we did indeed implement something
> >>> (seriously no memory on details) that resulted in the creation of a new
> >>> prefix reachability TLV with some experimental/local sub-TLVs.  These
> >>> prefixes did not exist in the IS-IS domain beforehand.  I have no idea
> >>> what the operational reality is on the existence of such things, but I
> >>> know that /some/ code exists that does this.
> >>>
> >>> To boil this down into the core of the essence and be explicit,
> >>>
> >>> - you can create an IS-IS prefix reachability for some arbitrary
> prefix,
> >>> and stick > 0xfe00 into the metric, and that won't have any
> effect
> >>> on the existing IS-IS domain
> >>> - this has in fact been done to carry custom bits of information that
> >>> for one reason or another were decided to be routing-related and
> thus
> >>> make sense to put there
> >>> - the assumption for the use case is that there are indeed less
> specific
> >>> covering prefixes around, providing actual reachability
> >>> - any setup doing that would now suddenly have fresh "unreachable"
> >>> semantics attached to something that didn't have them before, which
> >>> breaks things (or rather: prevents enabling/deployment of the UPA
> >>> feature)
> >>
> >> and why that would be a problem? Such prefix would never be used to for
> >> resolution of the BGP prefix. So the presence of such unreachable prefix
> >> would never trigger any action even of the UPA processing was enabled on
> >> the receiver. I don't see a problem.
> >>
> >>> - (if those extra prefixes are created with 0x metric, a
> &g

Re: [Lsr] OSPF-GT

[Robert Raszuk]

Thx Acee ...

Since you mentioned "sparse" and since you highlighted that OSPF is better
then ISIS for this as it runs over IP I took a risk if not using flooding
is an option.

Well ... apparently not.

Of course you could build lots of parallel GT planes and still flood in
each across interested parties for a given type of info present in such a
plane, but this comes with much more overhead then pub-sub.

Cheers,
R.


On Thu, Nov 10, 2022 at 11:34 AM Acee Lindem (acee)  wrote:

> Hi Robert,
>
>
>
> *From: *Robert Raszuk 
> *Date: *Wednesday, November 9, 2022 at 10:37 AM
> *To: *Acee Lindem , lsr 
> *Subject: *OSPF-GT
>
>
>
> Hi Acee,
>
>
>
> The point of sparse GT makes it much more attractive.
>
>
>
> With that I have two questions/suggestions to make it even more useful.
>
>
>
> #1 Would you consider adding reflection function to spares mode GT ?
>
>
>
> Within a flooding scope (e.g., area) , reflection is inherent in the
> flooding algorithm. One thing that applications will need to specify is
> whether or not information is re-originated outside the flooding scope
> (e.g., does the ABR re-originate application LSAs into other areas).
>
>
>
>
>
> #2 If you do #1 would you considet pub-sub model ?
>
>
>
> I wouldn’t change basic OSPF flooding. So, one could support pub-sub but
> everyone in the OSPF application routing domain would receive a superset of
> subscribed information (or the application would have to do something
> unnatural from an OSPF standpoint to limit the neighbors receiving the
> information, e.g., dynamically assign areas for unique subscriptions). I
> think other protocols are better suited to pub-sub.
>
>
>
> Thanks,
> Acee
>
>
>
> Then this could be used for lot's of current use cases ... some of them
> even discussed today :)
>
>
>
> Thx
>
> R
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

[Robert Raszuk]

Peter,

> But:
> > - that is nonetheless a change which is non backward compatible with
> people currently using such high metric without the intention to mean UPA
> > - to differentiate different usages (e.g. your UPA, my other usage such
> as "graceful shutdown" (still reachable but will disappear soon), endpoint
> CPU load is 80%...) one
>
> well, the question is whether it would not make sense to trigger UPA for
> the above mentioned usages as well. Because eventually the destination
> is becoming unreachable anyway and I would want my services to reroute
> to alternate egress node. But seems like folks want to have a way to
> differentiate, so I'm not going to argue against it.
>

I think You are right if there is a hierarchical service above it.

But consider flat routing - where there is no BGP service on top. Example -
some DCs do use flat routing.

With that I am afraid UPA triggers may not work well (or at all) ...
especially considering that they are history after the timeout irrespective
of the remote prefix state.

Cheers,
R.








>
> thanks,
> Peter
>
> > would need to use different metric values that would need to be at least
> locally registered. So why not have the IANA register a flag and avoid each
> network operator to do that job?
> >
> > In all cases, I don't see a reason for UPA to change the meaning of all
> the metric values >0xFE00. You can pick a single value (e.g.
> 0xFE01) and that would equally work for your use case.
> >
> > Regards,
> > --Bruno
> >
> >
> >
> >
> >>
> >>>
> >>> I vaguely remember several years back we did indeed implement something
> >>> (seriously no memory on details) that resulted in the creation of a new
> >>> prefix reachability TLV with some experimental/local sub-TLVs.  These
> >>> prefixes did not exist in the IS-IS domain beforehand.  I have no idea
> >>> what the operational reality is on the existence of such things, but I
> >>> know that /some/ code exists that does this.
> >>>
> >>> To boil this down into the core of the essence and be explicit,
> >>>
> >>> - you can create an IS-IS prefix reachability for some arbitrary
> prefix,
> >>> and stick > 0xfe00 into the metric, and that won't have any
> effect
> >>> on the existing IS-IS domain
> >>> - this has in fact been done to carry custom bits of information that
> >>> for one reason or another were decided to be routing-related and
> thus
> >>> make sense to put there
> >>> - the assumption for the use case is that there are indeed less
> specific
> >>> covering prefixes around, providing actual reachability
> >>> - any setup doing that would now suddenly have fresh "unreachable"
> >>> semantics attached to something that didn't have them before, which
> >>> breaks things (or rather: prevents enabling/deployment of the UPA
> >>> feature)
> >>
> >> and why that would be a problem? Such prefix would never be used to for
> >> resolution of the BGP prefix. So the presence of such unreachable prefix
> >> would never trigger any action even of the UPA processing was enabled on
> >> the receiver. I don't see a problem.
> >>
> >>> - (if those extra prefixes are created with 0x metric, a
> >>> configurable >= limit for UPA does not help either.)
> >>
> >> again, what is the problem?
> >>
> >>>
> >>> Making IS-IS UPA explicit with a bit, sub-TLV, or whatever else is
> >>> (IMHO) not a significant cost, and completely eliminates this issue.
> >>> The only reason against it (that I can think of) is that the
> >>> advertisement might be a little bit larger;  a new sub-TLV or flag bit
> >>> should be completely invisible to existing implementations (= I don't
> >>> see how this would create compatibility or rollout problems.)
> >>
> >> I'm afraid, you forgot to consider an operational aspect of the
> solution.
> >>
> >> thanks,
> >> Peter
> >>
> >>>
> >>> Cheers,
> >>>
> >>>
> >>> -David
> >>>
> >>
> >
> > Orange Restricted
> >
> >
> _
> >
> > Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
> recu ce message par erreur, veuillez le signaler
> > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> > Orange decline toute responsabilite si ce message a ete altere, deforme
> ou falsifie. Merci.
> >
> > This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> > they should not be distributed, used or copied without authorisation.
> > If you have received this email in error, please notify the sender and
> delete this message and its attachments.
> > As emails may be altered, Orange is not liable for messages that have
> been modified, changed or falsified.
> > 

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

[Robert Raszuk]

Aijun,

 > there is another summary address that covers it is in the FIB.

You keep bringing this point over and over.

But what you are not aware of is that service route validation or
invalidation can be set and tracked for reachability with specific length
of the next hop. Both validation and invalidation can be of different
length. So from this point of view what UPA suggests works just fine.

Your local implementation can trivially be able to handle such triggers for
invalidation.

I have my own reservations for UPA but I do not see how points you are
raising are of any real issues.

Kind regards,
R.









On Wed, Nov 9, 2022 at 10:51 PM Aijun Wang 
wrote:

> Hi, Peter:
>
> Actually, the “unreachable” meaning of LSInfinity in current standard is
> not the same as the “unreachable” meaning that we are supposed to act:
> 1) In current standard, the “unreachable” is meant that the related prefix
> will not be in the FIB.(you can read again and again
> https://www.rfc-editor.org/rfc/rfc2328.html#page-157)
>
> 2) What we aim to solve is that although the specific prefixes is not in
> the FIB, there is another summary address that cover it is in the FIB. Even
> in such situations, the specific prefixes is still unreachable.
>
> Then, depend solely on 1) is not enough.
> We must need one explicit information to signal 2).
>
> There are so many experts within LSR state that your solution is not
> appropriate,  will bring much chaos into the network, you still insist your
> approach. Is this productive?
>
> The final solution should be definitely in “Standard Track”, but not your
> approach.
> The explicit signaling is the right direction.
>
> Even the experts in LSR are confusing on your multiplex usage of
> “LSInfinity”, how to deploy it in the large scale network?
>
> Please don’t let the operator struggle to explain such vague usages to its
> Network OPS, Network Planning team.
>
> Aijun Wang
> China Telecom
>
>
> I wasn't clear on that in the first mail but Bruno clarified
>
> that this would still be inside a high-metric prefix reachability TLV.
>
> The only difference is that there is a flag/sub-TLV inside that triggers
>
> UPA behavior.  However, prefixes with > 0xfe00 metric *without*
>
> the UPA indicator MUST be ignored as they were before and MUST NOT
>
> trigger UPA/PIC.
>
>
> for me flagging something that is unreachable with a unreachable flag is
> redundant. But I let the WG to decide. That would obviously push the draft
> to standard track trajectory.
>
> Peter
>
>
> Cheers,
>
> -David
>
>
> ___
> 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] OSPF-GT

[Robert Raszuk]

Hi Acee,

The point of sparse GT makes it much more attractive.

With that I have two questions/suggestions to make it even more useful.

#1 Would you consider adding reflection function to spares mode GT ?

#2 If you do #1 would you considet pub-sub model ?

Then this could be used for lot's of current use cases ... some of them
even discussed today :)

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

Re: [Lsr] RFC 8362 and LSInfinity

[Robert Raszuk]

> 1) The LSInfinity is defined almost 30 years, but it is not
applied/deployed within the
> network about 30 years

OSPF Max Metric (LSInfinity) is commonly deployed and used in pretty much
every decent network.

As an example it is used to drain traffic from active forwarding nodes
before planned maintenance. It is also used when wait-for-bgp is active.

So sorry, but your above assertion is false.

Rgs,
Robert.


On Wed, Oct 12, 2022 at 8:30 AM Aijun Wang 
wrote:

> Hi, Acee:
>
> Let me state some points more clearly:
> 1) The LSInfinity is defined almost 30 years, but it is not
> applied/deployed within the network about 30 years, why to deprecate it?
> 2) RFC8362 say nothing about LSInifinity, only RFC5340 says it inherits
> the definition from RFC2328.
> 3) It is problematic to define again the LSInifinity within RFC8362, as
> the value of 0xff, because the metric of the normal summary prefixes
> advertised by ABR may reach this predefined value.
>
> The most important point is that there is reasonable/sound reason to
> define such value for its special handling.
>
> Best Regards
>
> Aijun Wang
> China Telecom
>
>
> -Original Message-
> From: lsr-boun...@ietf.org  On Behalf Of Acee
> Lindem (acee)
> Sent: Tuesday, October 11, 2022 11:20 PM
> To: Peter Psenak (ppsenak) ; Aijun Wang <
> wangai...@tsinghua.org.cn>; 'Ketan Talaulikar' 
> Cc: lsr@ietf.org
> Subject: Re: [Lsr] RFC 8362 and LSInfinity
>
> Hi Aijun,
>
> After almost 30 years, we're not going to deprecate OSPF LSInfinity based
> on your opinion.
>
> Please be specific as to what you feel is problematic with usage in the
> 24-bit metric in the E-Intra-Area-Prefix LSA.
>
> Thanks,
> Acee
>
> On 10/11/22, 12:09 AM, "Peter Psenak"  wrote:
>
> Aijun,
>
> On 11/10/2022 05:44, Aijun Wang wrote:
> > Hi, Peter:
> >
> > Let's focus on OSPF itself then.
> >
> > In OSPFv2(RFC2328) and OSPFv3(RFC5340), the metric length for the
> link or intra-area prefix is 16 bit; but the metric length for the summary
> LSA/inter-area is 24bit.
> > There will be no problem to define the LSInfinity for the summary
> LSA as 0xFF( although the usages of such definition is doubtful and
> should be revaluatedfor example, is there any real deployment for the
> mentioned possible usages?)
> >
> > But for OSPFv3(RFC8362), if you still define the LSInifiity as
> 0xFF, there is possible the cost to some prefixes advertised by the ABR
> reach this value, it is unreasonable to consider such prefixes are
> unreachable.  Then, rely on such value of the metric to determine the
> reachability is problematic.
>
> again, there is no problem. For RFC8362 0xFF already means
> LSInfinity for inter/external prefixes. All we propose is to define
> the
> same meaning for that metric for intra-area prefixes as it is 24 bits
> as
> well.
>
> Peter
>
> >
> > We should decrease or abandon such unsound reliance.
> >
> > It is easy for the device to implement such special treatment, it is
> difficult and complex for the operator to run the network based on such
> special treatment.
> >
> >
> > Best Regards
> >
> > Aijun Wang
> > China Telecom
> >
> > -Original Message-
> > From: lsr-boun...@ietf.org  On Behalf Of
> Peter Psenak
> > Sent: Monday, October 10, 2022 3:56 PM
> > To: Aijun Wang ; 'Acee Lindem (acee)'
> ; 'Ketan Talaulikar' <
> ketant.i...@gmail.com>; 'Peter Psenak'  >
> > Cc: lsr@ietf.org
> > Subject: Re: [Lsr] RFC 8362 and LSInfinity
> >
> > Aijun,
> >
> > On 09/10/2022 07:44, Aijun Wang wrote:
> >> Hi, Acee, Peter and Ketan:
> >>
> >> I propose we limit the usage of LSInfinity within the network. That
> is
> >> to say, we should depreciate its usages, not enhance it.
> >>
> >> As defined in RFC2328, the sole purpose of LSInfinity is to let the
> >> receiver bypass the SPF calculation for the associated LSA:
> >>
> >> a)In case the advertisement of LSA for some special aim.
> >>
> >> b)Another is for the premature aging the LSA (which is not
> encouraged).
> >>
> >> There is few application for the a) usage until now, same situation
> >> for
> >> b) usage.
> >
> > definition of LSInfinity is very exact - it means unreachability.
> >
> >>
> >> The reason for the above situations may be the definition within the
> >> RFC2328 is counterintuitivethe maximum value of the metric
> should
> >> be used for the last resort of the reachability, no other more
> >> meanings. Or else, it will complex the implementation and
> deployment, for example:
> >>
> >> a)For OSPFv2, the LSInfinity is defined as 0xff
> >>
> >> b)For IS-IS, the equivalent variable is MAX_PATH_METRIC, which is
> >> defined as 0xFE00
> >
> > you are comparing apples to oranges. These are two different
> protocols.
> >
> 

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

[Robert Raszuk]

Dear LSR WG,

> MP-TLVs (explicit or implicit) are not an extension of the protocol -
they are completely consistent
> with the base operation of the protocol. I have always viewed lack of
support for MP-TLVs as an
> implementation limitation - not a gap in the protocol.

I don't agree with this assertion. For many of us resending PDU with the
same key is an implicit update.

Is there any text in the base ISIS spec which would suggest otherwise ?

> you're talking about networks defined to work by SE not by standards

It seems like it. The problem with this is that it works well in static
single vendor networks where one can always blame operators for
"provisioning mistakes''.  We can do much better than that. I am with Tony,
Chris, Bruno here. It is cool that the IETF consensus does not have a
"liberum veto" (unanimity <https://en.wikipedia.org/wiki/Unanimity> voting
rule).

Thx,
Robert.

PS. And we all know how splitting the drafts will end up .. so no thank you
Peter & Les for this suggestion.


On Fri, Oct 7, 2022 at 12:20 AM Les Ginsberg (ginsberg) 
wrote:

> Chris -
>
> > -Original Message-
> > From: Christian Hopps 
> > Sent: Thursday, October 6, 2022 1:36 PM
> > To: Peter Psenak (ppsenak) 
> > Cc: Christian Hopps ; Tony Li ; Les
> > Ginsberg (ginsberg) ; Robert Raszuk
> > ; Henk Smit ; lsr@ietf.org
> > Subject: Re: [Lsr] New Version Notification for
> draft-pkaneria-lsr-multi-tlv-
> > 01.txt
> >
> >
> > Peter Psenak  writes:
> >
> > > Chris,
> > >
> > > On 06/10/2022 18:34, Christian Hopps wrote:
> > >> Peter Psenak  writes:
> > >>
> > >>> Tony, Les,
> > >>>
> > >>> I believe we can all agree that we do not want to change the
> behavior of
> > >>> existing implementations that support MP-TLVs based on the
> > advertisements of the
> > >>> MP-capability from other routers - it would break existing networks.
> > Even the
> > >>> text in the MP-TLV draft does not suggest that to be the case.
> > >> Are people not looking at the spreadsheet Tony put together?
> > >> Which implicit multi-part TLVs are these "existing implementations"
> > >> advertising that keep getting referred to? Please let's work with
> real data
> > --
> > >> the spreadsheet shows a grand total of *0* TLVs that could fall in
> this
> > >> category.
> > >
> > > then the spreadsheet is incorrect.
> > >
> > > I know of implementation that can send and receive Multi part TLVs for
> > IPv4/IPv6
> > > (MT) IP Reach, (MT) Extended IS reachability and IS-IS Router
> CAPABILITY
> > TLV to
> > > start with.
> >
> > Do you know all of the implementations, and all of those that don't? If
> we
> > could publish that list then we presumably could explore more simple
> > solutions. :)
> >
> > People keep talking about breaking deployed networks, but that assumes
> > there are functional networks with implicit MP-TLVs in them. I am not
> sure I
> > accept the assertion that these networks are truly functional.
> >
> > AFAICT these networks are *lucky* to be working. There's no document to
> > point at, there's no bit to look at, there's literally nothing to help
> an operator
> > or their routers know if all the routers correctly receive and process
> these
> > implicit MP-TLVs. These networks are one network change (even as small as
> > an interface up or down event) away from failing, or may even be failing
> > already but not yet in a noticeable way. This is the case regardless of
> what
> > type of bit or functionality this document provides.
>
> [LES:] I don't agree at all with your characterization.
>
> MP-TLVs (explicit or implicit) are not an extension of the protocol - they
> are completely consistent with the base operation of the protocol. I have
> always viewed lack of support for MP-TLVs as an implementation limitation -
> not a gap in the protocol.
> Until relatively recently, there was no need to send MP-TLVs for
> neighbors/prefixes and since it is far from trivial to implement MP-TLV
> support it is understandable why most(all?) implementations did not include
> such support initially.
> But this does not mean that the protocol itself lacks the support.
>
> Would it have been better if all RFCs were explicit about the possibility
> of MP-TLVs? Sure - but hindsight is always easier than foresight.
> And even in those cases where MP-TLV support was explicitly defined, this
> did not guarantee that all implementations had that supp

Re: [Lsr] Warren Kumari's Yes on draft-ietf-lsr-ospf-bfd-strict-mode-09: (with COMMENT)

[Robert Raszuk]

Hi Warren,

You have just asked a very valid question.

I have brought this to the attention of LSR WG here:

https://mailarchive.ietf.org/arch/msg/lsr/LaXtqHuoZ6FCeOuvZ9sUXxZ_Z20/

But after 10s of emails on and off line apparently you observing the issue
again at this stage is proof that no real improvement went into the
document.

Sad but I have no more cycles to continue banging the closed doors.

The answer I got is that such a timer may exist but as private vendor
enhancement not clearly part of the spec.

Cheers,
R.




On Thu, Oct 6, 2022 at 12:40 AM Warren Kumari via Datatracker <
nore...@ietf.org> wrote:

> Warren Kumari has entered the following ballot position for
> draft-ietf-lsr-ospf-bfd-strict-mode-09: Yes
>
> 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-ospf-bfd-strict-mode/
>
>
>
> --
> COMMENT:
> --
>
> Thank you for this document.
>
> When I started reading this document / read the Abstract, I must admit I
> thought "This is a silly idea, and smacks of creeping featuritis and
> premature
> optimization. This is an already solved problem - you bring up OSPF and
> *then*
> use that to signal that you want BFD" and then I actually read the
> Introduction section and the use-case / utility became clear...
>
> My only question (and I'm suspecting it has already been discussed) if is
> there
> should actually be some (small) delay after the BFD session establishment
> to
> allow the interface to "settle" / give BFD a second or two to figure out
> if the
> link is actually "stable" - having BFD come up and then immediately
> bringing up
> the adjacency, only to have BFD pull it down 10ms later doesn't seem to
> solve
> the issue really... unless it is expected that the OSPF exchange is
> sufficiently slow that BFD would detect it before OSPF is actually working?
>
>
>
> ___
> 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-pkaneria-lsr-multi-tlv-01.txt

[Robert Raszuk]

Les,

I agree - the scenario I presented is much bigger than this thread.

But in this thread what is being discussed is one little (arguably very
valuable) piece of it.

Many thx,
R.




On Thu, Oct 6, 2022 at 12:00 AM Les Ginsberg (ginsberg) 
wrote:

> I see – so you want a configuration model that says “Enable X when
> conditions Y and Z are met”.
>
>
>
> There are examples of this already e.g., conditional installation of
> static routes based on reachability/interface state… but they are typically
> quite modest in scope.
>
>
>
> Applying this to all of the potentially applicable configs would be quite
> complex and require lots of extensions to the configuration model supported.
>
> And it still risks oscillation…
>
>
>
> This is a big ask – and I think goes well beyond what has been discussed
> in this thread – so if you want to pursue this I think another thread/draft
> is called for.
>
> Certainly well beyond anything I am thinking about.
>
>
>
>Les
>
>
>
> *From:* Robert Raszuk 
> *Sent:* Wednesday, October 5, 2022 2:41 PM
> *To:* Les Ginsberg (ginsberg) 
> *Cc:* bruno.decra...@orange.com; Tony Li ; Christian
> Hopps ; Henk Smit ; lsr@ietf.org
> *Subject:* Re: [Lsr] New Version Notification for
> draft-pkaneria-lsr-multi-tlv-01.txt
>
>
>
>
>
> >  where implementations decide when to apply configuration that has been
> accepted
>
>
>
> where implementations decide when to apply *conditional* configuration
> that has been accepted
>
>
>
> Thx,
> R.
>
>
>
> On Wed, Oct 5, 2022 at 11:32 PM Les Ginsberg (ginsberg) <
> ginsb...@cisco.com> wrote:
>
> Robert –
>
>
>
> This has nothing to do with centralized vs distributed.
>
>
>
> You are advocating a model where implementations decide when to apply
> configuration that has been accepted. This fundamentally changes the
> authority from the management tool (be it manual or automated) to the
> implementation.
>
>
>
>Les
>
>
>
> *From:* Robert Raszuk 
> *Sent:* Wednesday, October 5, 2022 1:41 PM
> *To:* Les Ginsberg (ginsberg) 
> *Cc:* bruno.decra...@orange.com; Tony Li ; Christian
> Hopps ; Henk Smit ; lsr@ietf.org
> *Subject:* Re: [Lsr] New Version Notification for
> draft-pkaneria-lsr-multi-tlv-01.txt
>
>
>
> Hi Les,
>
>
>
> Yes you have correctly understood my last point.
>
>
>
> So your take it to always put a human to operate/run the network.
> Enable statically features and always manually map user traffic to such
> features.
>
>
>
> That's the legacy (old fashioned) network model. Yes it works today
> in a lot of networks, but is it to stay like this forever ?
>
>
>
> My view is that networks should operate by themselves (or as much
> autonomously as possible).
>
>
>
> We can do it via management plane - centralized model
>
> or
>
> We can do it in the network itself - distributed model.
>
>
>
> What are the network's overall transit capabilities should be dynamically
> signalled to applications too.
>
>
>
> It is surprising you are so much endorsing a centralized (oracle like)
> approach. I am even more surprised you are against using IGP to signal
> itself what it is capable of supporting to help today's operators.
>
>
>
> Best,
>
> R.
>
>
>
>
>
>
>
>
>
> On Wed, Oct 5, 2022 at 10:24 PM Les Ginsberg (ginsberg) <
> ginsb...@cisco.com> wrote:
>
> Robert –
>
>
>
> Not certain I completely understand you – but I “think” what you are
> saying is that we could allow configuration independent of what nodes in
> the network currently support, but suppress advertisement/enabling until
> all nodes advertise support.
>
> Am I close??
>
>
>
> If so, this is one of the aspects that adds complexity.
>
> And it still does not result in a working network.
>
> So, no thanks.
>
>
>
>Les
>
>
>
> *From:* Robert Raszuk 
> *Sent:* Wednesday, October 5, 2022 12:40 PM
> *To:* Les Ginsberg (ginsberg) 
> *Cc:* bruno.decra...@orange.com; Les Ginsberg (ginsberg) <
> ginsb...@cisco.com>; Tony Li ; Christian Hopps <
> cho...@chopps.org>; Henk Smit ; lsr@ietf.org
> *Subject:* Re: [Lsr] New Version Notification for
> draft-pkaneria-lsr-multi-tlv-01.txt
>
>
>
>
>
> Just to add and expand to your point Les ...
>
>
>
> The concept of "forward referencing" used in some OSes explicitly permit
> configuration of elements not even present on the box or in the system
> ahead of time. For example you can configure an interface which will be
> inserted later.
>

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

[Robert Raszuk]

>  where implementations decide when to apply configuration that has been
accepted

where implementations decide when to apply *conditional* configuration that
has been accepted

Thx,
R.

On Wed, Oct 5, 2022 at 11:32 PM Les Ginsberg (ginsberg) 
wrote:

> Robert –
>
>
>
> This has nothing to do with centralized vs distributed.
>
>
>
> You are advocating a model where implementations decide when to apply
> configuration that has been accepted. This fundamentally changes the
> authority from the management tool (be it manual or automated) to the
> implementation.
>
>
>
>Les
>
>
>
> *From:* Robert Raszuk 
> *Sent:* Wednesday, October 5, 2022 1:41 PM
> *To:* Les Ginsberg (ginsberg) 
> *Cc:* bruno.decra...@orange.com; Tony Li ; Christian
> Hopps ; Henk Smit ; lsr@ietf.org
> *Subject:* Re: [Lsr] New Version Notification for
> draft-pkaneria-lsr-multi-tlv-01.txt
>
>
>
> Hi Les,
>
>
>
> Yes you have correctly understood my last point.
>
>
>
> So your take it to always put a human to operate/run the network.
> Enable statically features and always manually map user traffic to such
> features.
>
>
>
> That's the legacy (old fashioned) network model. Yes it works today
> in a lot of networks, but is it to stay like this forever ?
>
>
>
> My view is that networks should operate by themselves (or as much
> autonomously as possible).
>
>
>
> We can do it via management plane - centralized model
>
> or
>
> We can do it in the network itself - distributed model.
>
>
>
> What are the network's overall transit capabilities should be dynamically
> signalled to applications too.
>
>
>
> It is surprising you are so much endorsing a centralized (oracle like)
> approach. I am even more surprised you are against using IGP to signal
> itself what it is capable of supporting to help today's operators.
>
>
>
> Best,
>
> R.
>
>
>
>
>
>
>
>
>
> On Wed, Oct 5, 2022 at 10:24 PM Les Ginsberg (ginsberg) <
> ginsb...@cisco.com> wrote:
>
> Robert –
>
>
>
> Not certain I completely understand you – but I “think” what you are
> saying is that we could allow configuration independent of what nodes in
> the network currently support, but suppress advertisement/enabling until
> all nodes advertise support.
>
> Am I close??
>
>
>
> If so, this is one of the aspects that adds complexity.
>
> And it still does not result in a working network.
>
> So, no thanks.
>
>
>
>Les
>
>
>
> *From:* Robert Raszuk 
> *Sent:* Wednesday, October 5, 2022 12:40 PM
> *To:* Les Ginsberg (ginsberg) 
> *Cc:* bruno.decra...@orange.com; Les Ginsberg (ginsberg) <
> ginsb...@cisco.com>; Tony Li ; Christian Hopps <
> cho...@chopps.org>; Henk Smit ; lsr@ietf.org
> *Subject:* Re: [Lsr] New Version Notification for
> draft-pkaneria-lsr-multi-tlv-01.txt
>
>
>
>
>
> Just to add and expand to your point Les ...
>
>
>
> The concept of "forward referencing" used in some OSes explicitly permit
> configuration of elements not even present on the box or in the system
> ahead of time. For example you can configure an interface which will be
> inserted later.
>
>
>
> Same for any network wide feature.
>
>
>
> However this means that activation of such network wide features can take
> place under dynamic conditions too. If "all nodes required" support feature
> X I can advertise it. (Let's assume that other nodes which do not require
> it will not crash).
>
>
>
> That means that having such dynamic capability may be actually pretty
> helpful.
>
>
>
> Thx,
> R.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Wed, Oct 5, 2022 at 9:33 PM Les Ginsberg (ginsberg) 
> wrote:
>
> Bruno –
>
>
>
> Thanx for commenting – I really want to hear from the operator community.
>
>
>
> In regards to using “functionality supported” advertisements to either
> issue warnings or possibly block/disable configuration changes…I think this
> sounds better in theory than it can be realized in practice.
>
>
>
> If you block config when not all nodes advertise support for “feature X”,
> what do you do with existing config which was accepted at a time when all
> nodes that are up/reachable did advertise the needed support, but now a new
> node comes up (or becomes reachable) and it does NOT advertise the support?
>
> What do you do on bootup when the saved config includes configuration that
> should not be accepted under the rules for “feature X”?
>
> Do implementations have to provide a knob

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

[Robert Raszuk]

Hi Les,

Yes you have correctly understood my last point.

So your take it to always put a human to operate/run the network.
Enable statically features and always manually map user traffic to such
features.

That's the legacy (old fashioned) network model. Yes it works today
in a lot of networks, but is it to stay like this forever ?

My view is that networks should operate by themselves (or as much
autonomously as possible).

We can do it via management plane - centralized model
or
We can do it in the network itself - distributed model.

What are the network's overall transit capabilities should be dynamically
signalled to applications too.

It is surprising you are so much endorsing a centralized (oracle like)
approach. I am even more surprised you are against using IGP to signal
itself what it is capable of supporting to help today's operators.

Best,
R.




On Wed, Oct 5, 2022 at 10:24 PM Les Ginsberg (ginsberg) 
wrote:

> Robert –
>
>
>
> Not certain I completely understand you – but I “think” what you are
> saying is that we could allow configuration independent of what nodes in
> the network currently support, but suppress advertisement/enabling until
> all nodes advertise support.
>
> Am I close??
>
>
>
> If so, this is one of the aspects that adds complexity.
>
> And it still does not result in a working network.
>
> So, no thanks.
>
>
>
>Les
>
>
>
> *From:* Robert Raszuk 
> *Sent:* Wednesday, October 5, 2022 12:40 PM
> *To:* Les Ginsberg (ginsberg) 
> *Cc:* bruno.decra...@orange.com; Les Ginsberg (ginsberg) <
> ginsb...@cisco.com>; Tony Li ; Christian Hopps <
> cho...@chopps.org>; Henk Smit ; lsr@ietf.org
> *Subject:* Re: [Lsr] New Version Notification for
> draft-pkaneria-lsr-multi-tlv-01.txt
>
>
>
>
>
> Just to add and expand to your point Les ...
>
>
>
> The concept of "forward referencing" used in some OSes explicitly permit
> configuration of elements not even present on the box or in the system
> ahead of time. For example you can configure an interface which will be
> inserted later.
>
>
>
> Same for any network wide feature.
>
>
>
> However this means that activation of such network wide features can take
> place under dynamic conditions too. If "all nodes required" support feature
> X I can advertise it. (Let's assume that other nodes which do not require
> it will not crash).
>
>
>
> That means that having such dynamic capability may be actually pretty
> helpful.
>
>
>
> Thx,
> R.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Wed, Oct 5, 2022 at 9:33 PM Les Ginsberg (ginsberg) 
> wrote:
>
> Bruno –
>
>
>
> Thanx for commenting – I really want to hear from the operator community.
>
>
>
> In regards to using “functionality supported” advertisements to either
> issue warnings or possibly block/disable configuration changes…I think this
> sounds better in theory than it can be realized in practice.
>
>
>
> If you block config when not all nodes advertise support for “feature X”,
> what do you do with existing config which was accepted at a time when all
> nodes that are up/reachable did advertise the needed support, but now a new
> node comes up (or becomes reachable) and it does NOT advertise the support?
>
> What do you do on bootup when the saved config includes configuration that
> should not be accepted under the rules for “feature X”?
>
> Do implementations have to provide a knob to control whether configs
> should be rejected or just a warning issued?
>
> Do you think operators will now try to leverage the new “protection” they
> expect from implementations and feel free to relax testing on the
> assumption that a good implementation will prevent a “bad configuration”
> from being enabled?
>
>
>
> And what are the candidates for such functionality?
>
> In this thread we talk about MP-TLV support – but this is less than
> precise. What we are really talking about is MP-TLV support for specific
> TLVs. So this now requires per/TLV advertisement.
>
> And what else might be a good candidate? What about individual sub-TLV
> support e.g., for the different link attributes? If a node advertises a
> link attribute that not all nodes support then various forms of
> TE/flex-algo may not work.
>
> Do we then require each node to advertise every TLV it supports and every
> sub-TLV it supports?
>
> What about flag bits within a given TLV/sub-TLV?
>
>
>
> One response to this is to say “we will limit this to ‘important’
> advertisements” – but how are we to agree on what is important and what
> isn’t? Do we have an operational definition of “important”?

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

[Robert Raszuk]

Just to add and expand to your point Les ...

The concept of "forward referencing" used in some OSes explicitly permit
configuration of elements not even present on the box or in the system
ahead of time. For example you can configure an interface which will be
inserted later.

Same for any network wide feature.

However this means that activation of such network wide features can take
place under dynamic conditions too. If "all nodes required" support feature
X I can advertise it. (Let's assume that other nodes which do not require
it will not crash).

That means that having such dynamic capability may be actually pretty
helpful.

Thx,
R.








On Wed, Oct 5, 2022 at 9:33 PM Les Ginsberg (ginsberg) 
wrote:

> Bruno –
>
>
>
> Thanx for commenting – I really want to hear from the operator community.
>
>
>
> In regards to using “functionality supported” advertisements to either
> issue warnings or possibly block/disable configuration changes…I think this
> sounds better in theory than it can be realized in practice.
>
>
>
> If you block config when not all nodes advertise support for “feature X”,
> what do you do with existing config which was accepted at a time when all
> nodes that are up/reachable did advertise the needed support, but now a new
> node comes up (or becomes reachable) and it does NOT advertise the support?
>
> What do you do on bootup when the saved config includes configuration that
> should not be accepted under the rules for “feature X”?
>
> Do implementations have to provide a knob to control whether configs
> should be rejected or just a warning issued?
>
> Do you think operators will now try to leverage the new “protection” they
> expect from implementations and feel free to relax testing on the
> assumption that a good implementation will prevent a “bad configuration”
> from being enabled?
>
>
>
> And what are the candidates for such functionality?
>
> In this thread we talk about MP-TLV support – but this is less than
> precise. What we are really talking about is MP-TLV support for specific
> TLVs. So this now requires per/TLV advertisement.
>
> And what else might be a good candidate? What about individual sub-TLV
> support e.g., for the different link attributes? If a node advertises a
> link attribute that not all nodes support then various forms of
> TE/flex-algo may not work.
>
> Do we then require each node to advertise every TLV it supports and every
> sub-TLV it supports?
>
> What about flag bits within a given TLV/sub-TLV?
>
>
>
> One response to this is to say “we will limit this to ‘important’
> advertisements” – but how are we to agree on what is important and what
> isn’t? Do we have an operational definition of “important”?
>
>
>
> I think this quite easily leads to an explosion of advertisements and a
> great deal of complexity which returns very little.
>
> If an operator configures something it is because they need that in order
> for the network to meet the requirements of the given deployment.
> Blocking/disabling config might prevent some problems – but it won’t make
> the network functional.
>
>
>
> I am quite concerned that this is something that “sounds good” but in
> practice adds little value – yet places significant demands on
> implementations.
>
>
>
>Les
>
>
>
>
>
> *From:* Lsr  *On Behalf Of *
> bruno.decra...@orange.com
> *Sent:* Wednesday, October 5, 2022 2:29 AM
> *To:* Les Ginsberg (ginsberg) ; Tony
> Li ; Christian Hopps 
> *Cc:* Robert Raszuk ; Henk Smit ;
> lsr@ietf.org
> *Subject:* Re: [Lsr] New Version Notification for
> draft-pkaneria-lsr-multi-tlv-01.txt
>
>
>
> I’ve not followed everything in details so I’ve been reluctant to comment,
> but nonetheless please find below a diverse set of comments.
>
>
>
> > From: Christian Hopps 
>
> […]
>
> > AFAICT we now have implementations out there that are sending multiple
> TLVs which are not documented to be sent that way, that historically were
> not expected to be received that way, and then we have other
> implementations that do not expect this new, convenient but rather loose
> interpretation of the standards. Consider we have documents that explicitly
> state that a TLV can be sent multiple times, it would be completely normal
> for someone to then assume that when that isn't stated explicitly that
> multiple versions of those TLV will not be sent.
>
>
>
> > Thus the need for this document -- in some form.
>
>
>
> Thank you Chris.
>
> Definitely +1
>
>
>
> To clarify, are we talking about:
>
> - different nodes in the flooding domain having a different understanding
> of the LSDB content
>

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

[Robert Raszuk]

Tony & Les,

I do think we should be signalling node's enabled/active capabilities
including the ability to process various types of encoded PDUs in band.

I do not believe in live management planes. Sure getting stats, config push
etc ... it is all doable and deployed. But dynamic configuration based on
nodes activated capabilities via mgmt plane is hard as we keep adding stuff
to protocols. Even if one builds such tool today tomorrow it is obsoleted.

I do however consider Les's points as valid too. Especially insertion of
node anywhere in the area which may not be capable of handling some
encoding (and does not need to operationally) yet his signalling if we act
on it in the protocol operationally would have a potential to break
existing features. So to do this right such capability signalling would
need to contain scope.

But I see no harm in having such info available as mgmt information. After
all this is all pretty static and so little that I am not sure why we are
even spending time to discuss it so long.

> The thought of someone keeping all of this in their heads is simply naive.

Or maybe it is actually smart :) Maybe the goal here is to make networks so
complex that only a few can safely operate them. Otherwise just outsource
it and use "...as-a-service".

Best,
R.

On Tue, Oct 4, 2022 at 6:16 PM Tony Li  wrote:

> Hi Les,
>
> *Folks may well complain that management tools are not as good as they
> need to be, but trying to compensate for this by adding management
> information into the protocol itself isn’t a good solution.*
>
> It is not a good solution. But it is the only practical solution
> available. At scale, we need automation. We have tried and failed (again)
> to get broad adoption of a management infrastructure. We continue to reject
> alternative approaches. The thought of someone keeping all of this in their
> heads is simply naive.
>
> We have already painted ourselves into this corner. There is no good way
> out.
>
> Tony
>
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Robert Raszuk]

Hi Les,

Ok that helps to clarify the current use case (and name confusion) of
RFC7981. I did look at some of the drafts defined in the registry of this
Capability TLV bringing in sub-TLVs and while clearly lots of them are used
in a run time I did see a few which could be also stated to use mgmt plane
instead :).

But back to this topic - do you see that support for Multi-TLV processing
could not be disabled by a node ? If so, would this information not be
useful in run time ?

Thx,
R.





On Thu, Sep 22, 2022 at 10:30 PM Les Ginsberg (ginsberg) 
wrote:

> Robert –
>
>
>
> The intent of my response was to get agreement on separating the
> discussion of advertising features supported by an implementation from the
> content of the multi-tlv draft.
>
>
>
> Router capabilities TLV (RFC 4971/7981) is something quite different. In
> every case, information advertised in the Router Capability TLV is used at
> run time by the protocol. For example, advertising SR Capability is not
> there so that the operator can know which implementations include SR
> support. It is there so that at run time other routers in the network will
> know whether a given router has SR enabled – which influences how (for
> example) label stacks are built when forwarding via that node.
>
>
>
> What is being proposed here is for the protocol to advertise what features
> it supports. This is not information which will be used by the protocol at
> run time – it is there solely to inform the network operator of what
> support is included in a given implementation.
>
> This is not what Router Capability TLV does (please do not argue with me
> about the TLV name – it was chosen long ago…) and if the WG were to decide
> that management information should be sent by the protocol I would
> certainly argue that Router Capability TLV is not the correct TLV to be
> used.
>
>
>
> If you are interested in discussing having the protocol include management
> information in the LSPDB – please discuss this in a separate thread – and
> note that (with the notable exception of “hostname”) this isn’t done today
> – so it is something very new.
>
>
>
>Les
>
>
>
>
>
>
>
> *From:* Robert Raszuk 
> *Sent:* Thursday, September 22, 2022 12:38 PM
> *To:* Les Ginsberg (ginsberg) 
> *Cc:* Tony Li ; Henk Smit ; lsr <
> lsr@ietf.org>
> *Subject:* Re: [Lsr] New Version Notification for
> draft-pkaneria-lsr-multi-tlv-01.txt
>
>
>
> Hi Les,
>
>
>
> > 2) Applicability of advertising what features an implementation supports
> extends
>
> > to much more than just multi-tlv support.
>
>
>
> Indeed. Spot on !
>
>
>
> And wasn't it the reason for rfc4971 then updated by rfc7981 ?
>
>
>
> I think having such capabilities flooded via area or entire domain is a
> very useful thing.
>
>
>
> It is much better to crash local node then randomly see crashes here and
> there when it comes to handling new feature.
>
>
>
> Is the resistance here coming from the fact that multi-part TLVs are used
> today without such capability and introducing it now would cause a mess ?
> If so maybe rewording first sentence from section 5 rather then removing
> section 4 is better solution.
>
>
>
> Mgmt plane exists here and there. I am yet to see parity in how routers
> expose information from ISIS and OSPF. So if someone is seriously thinking
> of self driving networks we will see much more management stuff being sent
> inline other then expecting that networks will be driven by magic oracles.
> That experiment of SDN is not going that well I am afraid.
>
>
>
> Best,
>
> R.
>
>
>
>
>
> On Thu, Sep 22, 2022 at 6:40 PM Les Ginsberg (ginsberg)  40cisco@dmarc.ietf.org> wrote:
>
> Tony -
>
> For me, your discussion with Henk highlights two points:
>
> 1)There are different POVs on whether advertising management information
> (like multi-tlv support) in the LSPDB is a good idea
>
> 2)Applicability of advertising what features an implementation supports
> extends to much more than just multi-tlv support.
>
> Therefore, introduction of such advertisements should be removed from the
> multi-tlv draft. If you and/or others want to pursue this idea, then a new
> draft focused on this new use of the protocol should be written.
> In this way the WG will have the opportunity to discuss the merits of such
> a significant protocol extension independently - which is appropriate.
> And the work on how to support multi-tlv - which I think is both useful
> and non-controversial - can proceed.
>
> I hope this is something on which we can easily agree - even if we do not
> agree on whether featu

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

[Robert Raszuk]

Hi Les,

> 2) Applicability of advertising what features an implementation supports
extends
> to much more than just multi-tlv support.

Indeed. Spot on !

And wasn't it the reason for rfc4971 then updated by rfc7981 ?

I think having such capabilities flooded via area or entire domain is a
very useful thing.

It is much better to crash local node then randomly see crashes here and
there when it comes to handling new feature.

Is the resistance here coming from the fact that multi-part TLVs are used
today without such capability and introducing it now would cause a mess ?
If so maybe rewording first sentence from section 5 rather then removing
section 4 is better solution.

Mgmt plane exists here and there. I am yet to see parity in how routers
expose information from ISIS and OSPF. So if someone is seriously thinking
of self driving networks we will see much more management stuff being sent
inline other then expecting that networks will be driven by magic oracles.
That experiment of SDN is not going that well I am afraid.

Best,
R.


On Thu, Sep 22, 2022 at 6:40 PM Les Ginsberg (ginsberg)  wrote:

> Tony -
>
> For me, your discussion with Henk highlights two points:
>
> 1)There are different POVs on whether advertising management information
> (like multi-tlv support) in the LSPDB is a good idea
>
> 2)Applicability of advertising what features an implementation supports
> extends to much more than just multi-tlv support.
>
> Therefore, introduction of such advertisements should be removed from the
> multi-tlv draft. If you and/or others want to pursue this idea, then a new
> draft focused on this new use of the protocol should be written.
> In this way the WG will have the opportunity to discuss the merits of such
> a significant protocol extension independently - which is appropriate.
> And the work on how to support multi-tlv - which I think is both useful
> and non-controversial - can proceed.
>
> I hope this is something on which we can easily agree - even if we do not
> agree on whether feature support should/should not be advertised in the
> LSPDB.
>
> A few more comments inline.
>
> > -Original Message-
> > From: Lsr  On Behalf Of Tony Li
> > Sent: Tuesday, September 13, 2022 1:44 PM
> > To: Henk Smit 
> > Cc: lsr 
> > Subject: Re: [Lsr] New Version Notification for
> draft-pkaneria-lsr-multi-tlv-
> > 01.txt
> >
> >
> > Hi Henk,
> >
> > >> Yes, I'm advocate for putting things elsewhere, but that proposal has
> > >> met with crickets.  You don't get it both ways: no capabilities in the
> > >> protocol and nowhere else does not work.
> > >
> > > I'm not sure I know what you are talking about.
> > > Did you write a draft?
> >
> >
> > I did.  You don’t remember it. It was that memorable.
>
> [LES:] Sorry, I am not aware that you (or anyone else) has written a draft
> proposing advertisement of feature support in the LSPDB.
> Could you provide a reference?
>
> >
> >
> > >> Because the thought of trying to deploy this capability at scale
> without
> > >> this attribute seems impossible. Consider the case of Tier 1 providers
> > >> who have large IS-IS deployments. Are you really going to evaluate
> 2000+
> > >> nodes without some kind of help?
> > >
> > > With the help of the management-plane?
> >
> >
> > There is no management plane.  We had the chance at one, but we had the
> > great schism between OpenConfig and the IETF. So now we have nothing
> > that we can rely on.
>
> [LES:] I sympathize with your POV here. From an industry standpoint the
> schism is most unfortunate.
> But making the protocol itself responsible for sending management info is
> not a solution.
>
>Les
>
> >
> >
> > > How did those providers make changes to their
> > configs/features/architecture before?
> > > I would expect them to use the same tools.
> >
> >
> > They have configuration databases, but they do NOT have good tools that
> tell
> > them about router capabilities. They MAY be able to do something ad hoc
> > based on software release numbers, but this is far from a good solution.
> >
> >
> > >> And the routers will do computations based on the multi-part TLVs.
> > >> One level of indirection for a capability does not seem extreme.
> > >
> > > Not extreme, indeed.
> > > But again, I rather not see 20 different minor or irrelevant things
> > > in the router-capability TLV. Certainly not at 2 octets per item.
> > > 1 Bit would already be (16 times) better.
> >
> >
> > I am happy to go with one bit.  However, there is no place to encode that
> > single bit today.
> >
> >
> > >>> Regardless whether we do that or not, this discussion maybe should be
> > done
> > >>> outside the multipart TLV  discussion. Maybe another draft should be
> > written
> > >>> about these software-capabilities in general?
> > >>
> > >> Please feel free.  My proposal was shot down.
> > >
> > > Are you talking about a very recent proposal? Linked to the
> multipart-TLV
> > > draft? Or something older? I vaguely remember some idea about
> 

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

[Robert Raszuk]

All,

I am actually finding this capability useful. If for nothing else then to
help the operator to see what is going on in the area. On any node simple
show command will clearly show who is willing and capable to receive
MP-TLVs and who is not.

Analogy to including hostnames Tony brought here as an example is spot on
and along the same lines.

Of course how node uses that info could be discussed further. I would also
not object to put that capability into a separate document.

Thx,
R.





On Thu, Aug 25, 2022 at 6:06 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? (sub-optimal)
>   ** what, when, how, why, who sets the MP-TLV flag? What with
> flapping of MP-TLV flag (undefined)
>
> G/
>
> 

Re: [Lsr] Question about draft-ppsenak-lsr-igp-ureach-prefix-announce

[Robert Raszuk]

>
> you advertise the algo X locator as UPA.
>

So as UPA is generated by ABRs now ABRs must be locator aware.

Moreover local flooding must be able to map nodes to locators and locators
must be flooded in the underlay.

If one wants to tunnel flex-algo's between POPs across base (say core not
being flex-algo aware) this is not possible to still use UPA ?

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

Re: [Lsr] Question about draft-ppsenak-lsr-igp-ureach-prefix-announce

[Robert Raszuk]

So how do I forward my services with SRv6 if I advertise all with single
BGP next hop /128 across N flex algos ?

Assume for mapping I am attaching BGP Tunnel Attribute and signal on a per
service route which flex-algo to use.

Moreover how do I UPA some flex-algo's becoming unreachable in the case
where BGP next hop is different then flex-algo destination address ?

Thx,
R.








On Fri, Aug 5, 2022 at 3:19 PM Peter Psenak  wrote:

> Robert,
>
> On 05/08/2022 09:09, Robert Raszuk wrote:
> > Peter,
> >
> > Side question ...
> >
> > Assume PE participates in 10 end to end flex-algos.
> >
> > However BGP advertises 100K service routes with base 0 nh 1.1.1.1/32
> > <http://1.1.1.1/32>
> >
> > Are you stating that BGP should advertise 100K routes 10 times with
> > different IP address ?
>
> absolutely not.
>
> >
> > Note that mapping to flex-algo may not be prefix based on the number of
> > forwarding paradigms. Yet UPA seems to be only prefix based.
>
> so far flex-algo has been documented for SR (MPLS and SRv6) and for IP
> (v4/v6). For SR MPLS the algo forwarding is realized via unique algo
> label, for SRv6 via unique algo locator and for IP via unique IP prefix.
> If other "forwarding paradigms" want to use it, they would need to defne
> how.
>
> UPA is about prefix reachability, or more precisely about the loss of it.
>
> thanks,
> Peter
> >
> > Was this case discussed in any document/thread so far ?
> >
> > Thx,
> > R.
> > .
> >
> >
> >
> > On Fri, Aug 5, 2022 at 12:16 PM Peter Psenak
> > mailto:40cisco@dmarc.ietf.org>>
>
> > wrote:
> >
> > Zhibo,
> >
> > On 05/08/2022 05:49, Huzhibo wrote:
> >  > Peter:
> >  >
> >  >> -Original Message-
> >  >> From: Peter Psenak [mailto:ppse...@cisco.com
> > <mailto:ppse...@cisco.com>]
> >  >> Sent: Friday, August 5, 2022 1:55 PM
> >  >> To: Huzhibo mailto:huzh...@huawei.com>>
> >  >> Cc: lsr@ietf.org <mailto:lsr@ietf.org>
> >  >> Subject: Re: Question about
> > draft-ppsenak-lsr-igp-ureach-prefix-announce
> >  >>
> >  >> Zhibo,
> >  >>
> >  >> On 03/08/2022 21:09, Huzhibo wrote:
> >  >>> Hi Peter:
> >  >>>Please see inline.
> >  >>>
> >  >>>> -Original Message-
> >  >>>> From: Peter Psenak [mailto:ppse...@cisco.com
> > <mailto:ppse...@cisco.com>]
> >  >>>> Sent: Wednesday, August 3, 2022 11:20 PM
> >  >>>> To: Huzhibo mailto:huzh...@huawei.com>>
> >  >>>> Cc: lsr@ietf.org <mailto:lsr@ietf.org>
> >  >>>> Subject: Re: Question about
> >  >>>> draft-ppsenak-lsr-igp-ureach-prefix-announce
> >  >>>>
> >  >>>> Hi Zhibo,
> >  >>>>
> >  >>>> On 29/07/2022 20:49, Huzhibo wrote:
> >  >>>>> Hi Peter:
> >  >>>>>
> >  >>>>> Supplement to yesterday's online questions, If a node that
> > does not
> >  >>>>> support IP Flexalgo, which has a default route, should the
> node
> >  >>>>> process the IP Flexalgo prefix as a UPA?
> >  >>>>
> >  >>>> - I assume you are talking about the algo 0 default route.
> > Because IP
> >  >>>> Flex-algo default route does not make much sense really.
> >  >>>>
> >  >>>> - If the node does not support IP flex-algo, than it would not
> use
> >  >>>> any IP algo prefix as BGP service endpoint or for any other
> > purpose.
> >  >>>>
> >  >>>
> >  >>> Which IP Algo prefix as BGP service endpoint is not determined
> > by the ingress
> >  >> node, Such as VXLAN and SRv6 VPN.
> >  >>> When the ingress node receives an BGP Service cayyied a IP algo
> > prefix
> >  >>> as endpoint and it has a algo 0 default route, it should be
> > process this BGP
> >  >> service. and this can not be affected by the IGP Flexalgo prefix.
> >  >>
> >  >> sorry, but above is completely wrong.
> >  >>
> >  >> When you want to use IP fle

Re: [Lsr] Question about draft-ppsenak-lsr-igp-ureach-prefix-announce

[Robert Raszuk]

Peter,

Side question ...

Assume PE participates in 10 end to end flex-algos.

However BGP advertises 100K service routes with base 0 nh 1.1.1.1/32

Are you stating that BGP should advertise 100K routes 10 times with
different IP address ?

Note that mapping to flex-algo may not be prefix based on the number of
forwarding paradigms. Yet UPA seems to be only prefix based.

Was this case discussed in any document/thread so far ?

Thx,
R.
.



On Fri, Aug 5, 2022 at 12:16 PM Peter Psenak  wrote:

> Zhibo,
>
> On 05/08/2022 05:49, Huzhibo wrote:
> > Peter:
> >
> >> -Original Message-
> >> From: Peter Psenak [mailto:ppse...@cisco.com]
> >> Sent: Friday, August 5, 2022 1:55 PM
> >> To: Huzhibo 
> >> Cc: lsr@ietf.org
> >> Subject: Re: Question about draft-ppsenak-lsr-igp-ureach-prefix-announce
> >>
> >> Zhibo,
> >>
> >> On 03/08/2022 21:09, Huzhibo wrote:
> >>> Hi Peter:
> >>>Please see inline.
> >>>
>  -Original Message-
>  From: Peter Psenak [mailto:ppse...@cisco.com]
>  Sent: Wednesday, August 3, 2022 11:20 PM
>  To: Huzhibo 
>  Cc: lsr@ietf.org
>  Subject: Re: Question about
>  draft-ppsenak-lsr-igp-ureach-prefix-announce
> 
>  Hi Zhibo,
> 
>  On 29/07/2022 20:49, Huzhibo wrote:
> > Hi Peter:
> >
> > Supplement to yesterday's online questions, If a node that does not
> > support IP Flexalgo, which has a default route, should the node
> > process the IP Flexalgo prefix as a UPA?
> 
>  - I assume you are talking about the algo 0 default route. Because IP
>  Flex-algo default route does not make much sense really.
> 
>  - If the node does not support IP flex-algo, than it would not use
>  any IP algo prefix as BGP service endpoint or for any other purpose.
> 
> >>>
> >>> Which IP Algo prefix as BGP service endpoint is not determined by the
> ingress
> >> node, Such as VXLAN and SRv6 VPN.
> >>> When the ingress node receives an BGP Service cayyied a IP algo prefix
> >>> as endpoint and it has a algo 0 default route, it should be process
> this BGP
> >> service. and this can not be affected by the IGP Flexalgo prefix.
> >>
> >> sorry, but above is completely wrong.
> >>
> >> When you want to use IP flex-algo forwarding, you must advertise the
> prefix as
> >> algo prefix, relying on the algo 0 default would not give you algo
> forwarding.
> >>
> >> Advertising IP algo prefix at the egress and relying in algo 0 default
> at the
> >> ingress is going to cause all sorts of problems. You CAN NOT mix/change
> algos
> >> along the path through the network - if you do, you may end up in a
> permanent
> >> loop.
> >
> >If the ingress node does not support Flexalgo, the ingress node does
> not cause a
> > permanent loop because once the packet is forwarded to the Flexalgo
> node, it always
> > follows Flexalgo forwarding. If the packet does not reach the Flexalgo
> node, it always follows
> > Algo 0 forwarding.
>
> well, flex-algo was design for end to end forwarding. Switching between
> algos as packet traverses the network is not guaranteed to be loop free.
> If you don't trust me, I let you figure that out yourself when you do
> such a thing and it breaks.
>
> >
> >>
> >>> Therefore,
> >>> the IGP does only not generate the RIB/Fib for LSinfinity Metric
> prefix, but can
> >> not trigger BGP Service Down.
> >>> In addition, LSinfinity Metric may be applied to other scenarios in
> >>> the future. We cannot guarantee that LSinfinity Metric will not
> conflict with
> >> other purposes when being processed as a UPA.
> >>
> >> no, it can not, because the LSinfinity has a very strict definition -
> it means
> >> unreachable, which is exactly what the UPA is about.
> >>
> > I believe you are confusing a concept. The LSInfinity metric defined in
> RFC 5308
> > can be considered as zero route, but PUA/UPA actually defines a negative
> route.
> > It's not consistent
>
> I'm not confusing anything:
>
> rfc2328:
>
> LSInfinity
>  The metric value indicating that the destination described by an
>  LSA is unreachable.
>
> regards,
> Peter
>
>
>
> >
> >> Peter
> >>
> >>>
>  - If such node receives the IP algo prefix and even if it treats it
>  as UPA, given that such IP algo prefix was never reachable before on
>  this node, the UPA would result in no action.
> 
>  thanks,
>  Peter
> >
> > Thanks
> >
> > Zhibo
> >
> 
> >>>
> >>>
> >>
> >
> >
>
> ___
> 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] Comments on draft-wang-lsr-stub-link-attributes

[Robert Raszuk]

Hi Aijun,

How does this proposal impacts BGP path selection ?

Note that it is common to do next hop self on the ASBRs towards the
intradomain. So your proposal would not require any signalling to be
effective on a given ASBR. Local decision.

Originally I was under impression that you want to enhance TE for option C
like deployments. But if not then I see not much point of doing it.

Thx,
R.

On Fri, Jul 29, 2022 at 4:09 AM Aijun Wang 
wrote:

> Hi, Ketan:
>
>
>
> In the inter-AS scenario, we will not deploy BGP session on each p2p link.
> The BGP session exists only within the loopback address of each ASBR pair.
>
> Such deployment is also same in the LAN scenario. Then there is no mesh or
> partial p2p link that congruent to the BGP sessions.
>
> But such LAN interfaces are sharing the same prefixes.
>
>
>
> And regarding to your comments on Prefix sub-TLV: yes, if we redistribute
> such external prefixes into the IGP, then they will be transported within
> the associated “External Prefixes TLV”.
>
> But for these stub links, if we configure them as “passive” only( no
> redistributed action), then the prefixes of these stub links will not
> exists within the IGP LSA.
>
> Attach the prefixes information with these stub links can certainly fill
> such gap. There will be no redundancy information.
>
>
>
> And, regarding to your comments: “… …- at least let us not go overboard
> and repeat the same info in multiple places. ”, this is also the main
> reason that we don’t want to use the RFC5316/RFC5392 mechanism to
> accomplish the goal for the inter-as topology recovery--there will be
> many redundancy information being flooded within the IGP area.
>
>
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
>
>
> *From:* Ketan Talaulikar 
> *Sent:* Thursday, July 28, 2022 4:54 PM
> *To:* Aijun Wang 
> *Cc:* Les Ginsberg (ginsberg) ; Acee
> Lindem (acee) ; lsr 
> *Subject:* Re: [Lsr] Comments on draft-wang-lsr-stub-link-attributes
>
>
>
> Hi Aijun,
>
>
>
> Please check inline below.
>
>
>
> On Thu, Jul 28, 2022 at 1:15 PM Aijun Wang 
> wrote:
>
> Hi, Ketan:
>
>
>
> There are situation that such information is necessary:
>
> When several ASes are connected via the LAN interface, it is impossible to
> describe the inter-AS relationship with the current descriptors that
> provided by RFC5316 and RFC5392.
>
>
>
> KT> Note that we have BGP running on these Inter-AS links. Even when there
> is an underlying LAN, the BGP sessions are p-t-p and maybe a full or
> partial mesh. Therefore, I believe representing such a LAN as a mesh of
> p-t-p links that are congruent to the BGP sessions is the right approach. I
> am happy to be corrected. In any case, I still fail to see how a prefix
> associated with the links helps here.
>
>
>
>
>
> And another scenario is that when these stub links are used to correct
> servers, there is no remote-AS, remote ASBR ID information. But we can
> distinguish different stub link via their associated prefixes.
>
>
>
> KT> I disagree - such stub links can be identified by their local
> interface ids along with their local IP address. Note that we already have
> the corresponding prefix being advertised as prefix reachability. So I
> don't see the need to repeat. All of this is already overloading IGPs with
> info that is not used by IGPs - at least let us not go overboard and repeat
> the same info in multiple places.
>
>
>
> Please check the new fresh thread about use-cases.
>
>
>
> Thanks,
>
> Ketan
>
>
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> On Jul 28, 2022, at 15:03, Ketan Talaulikar  wrote:
>
> 
>
> Hi Aijun,
>
>
>
> Similar to Les, I disagree with you on the use of Prefix TLV as an
> attribute of the "Stub Link". The reason is that this attribute is not
> required for the identification of a link in BGP-LS (or in IGPs for that
> matter) that was the main use case. I also don't see the use of that in
> Inter-AS links. Please justify this.
>
>
>
> Thanks,
>
> Ketan
>
>
>
>
>
> On Thu, Jul 28, 2022 at 12:19 PM Aijun Wang 
> wrote:
>
> Hi, Les:
>
>
>
> Please note the references to RFC5316/RFC5392 in
> draft-ietf-idr-bgpls-inter-as-topology-ext-11 is for TE scenarios, and
> what we are discussing are non-TE scenarios.
>
> For prefixes sub-TLV, would you like to revisit my responses to Ketan,
> before make any comments? For your convenience, I can elaborate again to
> you——-“The prefix sub-TLV is not the link identifier, it is just one kind
> of link attributes”. Is it clear enough?
>
>
>
> Based on these facts, I think it is unnecessary to response your other
> baseless comments.
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> On Jul 28, 2022, at 12:51, Les Ginsberg (ginsberg)  40cisco@dmarc.ietf.org> wrote:
>
> 
>
> Acee –
>
>
>
> I have a somewhat different take on this draft.
>
>
>
> I agree with you that draft-ietf-idr-bgpls-inter-as-topology-ext-11 is
> relevant – but I disagree that the lsr-stub-link draft is needed at all.
>
> In fact one of the main points 

Re: [Lsr] UPA/PUA

[Robert Raszuk]

Hi Greg,

That in fact even further highlights the benefits of using app to app
> network quality detection. When app has been exposed with more then one
> network path.
>
GIM>> I imagine that application layer OAM would be more burdensome than
OAM in the underlay. Of course, the detection of some failures in an
application is based on the application mechanism, not on the OAM. I
consider that as a tradeoff.


There is one more (IMHO very important) consideration to this.

With respect to application detection if you run 1000 application instances
each one of them needs to detect it. And not all of them may be sending
packets with OAM all the time.

So when I was going with ABR to PE probing that it should be enough for one
application to detect the failure, ABR would intercept this and trigger UPA
for all PEs which host behind 999 application endpoints.

That way the vast majority of applications would not even notice the issue
which is what we are all aiming for (one could hope :).

Many thx,
R.

On Mon, Jul 18, 2022 at 3:40 PM Greg Mirsky  wrote:

> Hi Robert,
> a note on active OAM in-lined below under GIM>>.
>
> Regards,
> Greg
>
> On Sun, Jul 17, 2022 at 11:12 PM Robert Raszuk  wrote:
>
>> Good point !
>>
>> That proves that if PE-PE OAM does not follow app to app path it is
>> useless. I would tend to agree.
>>
> GIM>> I agree, and the requirement for the active OAM to follow the same
> path has always been placed at the front of all OAM requirement documents I
> am familiar with. That equally applies to Fault Management (echo
> request/reply or BFD) and Performance Monitoring OAM protocols. I think
> that that requirement can be addressed by using the same encapsulation in
> the underlay network.
>
>>
>> That in fact even further highlights the benefits of using app to app
>> network quality detection. When app has been exposed with more then one
>> network path.
>>
> GIM>> I imagine that application layer OAM would be more burdensome than
> OAM in the underlay. Of course, the detection of some failures in an
> application is based on the application mechanism, not on the OAM. I
> consider that as a tradeoff.
>
>>
>> Thx,
>> R.
>>
>>
>> On Mon, Jul 18, 2022 at 6:04 AM Aijun Wang 
>> wrote:
>>
>>> Hi, Greg:
>>>
>>>
>>>
>>> As indicated in the update draft
>>> https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-10
>>>
>>>
>>>
>>> The motivation behind this draft is for either MPLS LPM FEC binding,
>>>
>>>SRv6 etc. tunnel ,or BGP overlay service that are using LPM
>>>
>>>forwarding plane where the IGP domain has been carved up into OSPF
>>>
>>>areas or IS-IS levels and summarization is utilized.  In such
>>>
>>>scenario, a link or node failure can result in a black hole of
>>>
>>>traffic when the summary advertisement that covers the failure
>>>
>>>prefixes still exists.
>>>
>>>
>>>
>>>PUAM can track the unreachability of the important component
>>>
>>>    prefixes to ensure traffic is not black hole sink routed for the
>>>
>>>above overlay services.
>>>
>>>
>>>
>>> Then considering only the BFD sessions among PEs are not enough, even we
>>> put aside the BFD sessions overhead on each PE.
>>>
>>>
>>>
>>>
>>>
>>> Best Regards
>>>
>>>
>>>
>>> Aijun Wang
>>>
>>> China Telecom
>>>
>>>
>>>
>>> *From:* Greg Mirsky 
>>> *Sent:* Monday, July 18, 2022 11:06 AM
>>> *To:* Aijun Wang 
>>> *Cc:* Robert Raszuk ; Christian Hopps <
>>> cho...@chopps.org>; Peter Psenak ; lsr 
>>> *Subject:* Re: [Lsr] UPA/PUA
>>>
>>>
>>>
>>> Hi Aijun,
>>>
>>> I cannot figure out how you draw such a conclusion from my comments to
>>> Robert. You may recall that from very early in the discussion, I was not
>>> enthusiastic, to put it lightly, about either of the solutions. Instead, I
>>> believe that multi-hop BFD should be used to monitor the continuity of a
>>> path PE-PE, not ABR/ASBR-PE as suggested by Robert. I hope I've made my
>>> position clear.
>>>
>>>
>>>
>>> Regards,
>>>
>>> Greg
>>>
>>>
>>>
>>> On Sun, Jul 17, 2022 at 7:04 PM Aijun Wang 
>>> wrote:
>>>
>>

Re: [Lsr] UPA/PUA

[Robert Raszuk]

Good point !

That proves that if PE-PE OAM does not follow app to app path it is
useless. I would tend to agree.

That in fact even further highlights the benefits of using app to app
network quality detection. When app has been exposed with more then one
network path.

Thx,
R.


On Mon, Jul 18, 2022 at 6:04 AM Aijun Wang 
wrote:

> Hi, Greg:
>
>
>
> As indicated in the update draft
> https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-10
>
>
>
> The motivation behind this draft is for either MPLS LPM FEC binding,
>
>SRv6 etc. tunnel ,or BGP overlay service that are using LPM
>
>forwarding plane where the IGP domain has been carved up into OSPF
>
>areas or IS-IS levels and summarization is utilized.  In such
>
>scenario, a link or node failure can result in a black hole of
>
>traffic when the summary advertisement that covers the failure
>
>prefixes still exists.
>
>
>
>PUAM can track the unreachability of the important component
>
>prefixes to ensure traffic is not black hole sink routed for the
>
>above overlay services.
>
>
>
> Then considering only the BFD sessions among PEs are not enough, even we
> put aside the BFD sessions overhead on each PE.
>
>
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> *From:* Greg Mirsky 
> *Sent:* Monday, July 18, 2022 11:06 AM
> *To:* Aijun Wang 
> *Cc:* Robert Raszuk ; Christian Hopps <
> cho...@chopps.org>; Peter Psenak ; lsr 
> *Subject:* Re: [Lsr] UPA/PUA
>
>
>
> Hi Aijun,
>
> I cannot figure out how you draw such a conclusion from my comments to
> Robert. You may recall that from very early in the discussion, I was not
> enthusiastic, to put it lightly, about either of the solutions. Instead, I
> believe that multi-hop BFD should be used to monitor the continuity of a
> path PE-PE, not ABR/ASBR-PE as suggested by Robert. I hope I've made my
> position clear.
>
>
>
> Regards,
>
> Greg
>
>
>
> On Sun, Jul 17, 2022 at 7:04 PM Aijun Wang 
> wrote:
>
> Then considering both the scalability and possible false negative of BFD
> based solution,  can we say that the PUA/UPA solution is more preferable?
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> *From:* lsr-boun...@ietf.org  *On Behalf Of *Greg
> Mirsky
> *Sent:* Monday, July 18, 2022 8:39 AM
> *To:* Robert Raszuk 
> *Cc:* Christian Hopps ; Peter Psenak ;
> lsr 
> *Subject:* Re: [Lsr] UPA
>
>
>
> Hi Robert,
>
> top-posting and then my notes in-line under the GIM>> tag:
>
> As mentioned it is still not the same. BFDs on the link tell me that link
> is up and part of the line card responder to BFD is alive.
>
> GIM>> I assume you refer to BFD single-hop. Then I have a question What do
> you mean by "link is up"? If the link is Ethernet, p2p single-hop BFD in
> the Down state may not indicate that the link is down but that the remote
> peer is operating down.
>
>
>
> Multihop BFD sessions will tell me that PE is up or down and that at least
> one connection to it is still up. That is subtle but there is an important
> difference.
>
> GIM>> Not necessarily, depends on the implementation. I can imagine a
> scenario, depending on the Detect Multiplier and Transmission Interval
> values, when the BFD multi-hop session going down indicates that the
> particular path to the remote PE lost continuity.
>
>
>
> And I repeat from the Abstract of RFC 5880:
>
>This document describes a protocol intended to detect faults in the
>
>bidirectional path between two forwarding engines, including
>
>interfaces, data link(s), and to the extent possible the forwarding
>
>engines themselves, with potentially very low latency.
>
> I believe that BFD cannot give us a reliable indication of the operational
> state of a node that hosts the BFD session, applications, and protocols
> hosted on that node.
>
>
>
> Regards,
>
> Greg
>
>
>
>
>
> On Sun, Jul 17, 2022 at 4:49 AM Robert Raszuk  wrote:
>
> Hi Christian,
>
>
>
> > It seems you saying use multi-hop BFD for fast detection b/c you've gone
> and configured one of those same hops along the
>
> > multi-hop path to an incredibly slow link-local BFD rate in comparison
> to the BFD multi-hop rate.
>
>
>
> Yes. That is exactly the case. What is however missing in your picture is
> that UPA is not only about signalling that all links to a node went down.
>
>
>
> UPA is also about signalling node down while links are still up - con

Re: [Lsr] UPA/PUA

[Robert Raszuk]

Hi Greg,

I am observing we are partially on the same page.

But if we compare full mesh PE-PE multihop BFD sessions vs PE-ABR then
flooding or DROID to remote PEs don't you think that the latter model is
far more scalable and operationally friendly ?

To make it clear - I am not against PE-PE detection ... in fact I am
suggesting that correctly provisioned service should get multiple paths end
to end (app to app) and detect quality app to app keeping all network away
from doing it.

Best,
R.


On Mon, Jul 18, 2022 at 5:06 AM Greg Mirsky  wrote:

> Hi Aijun,
> I cannot figure out how you draw such a conclusion from my comments to
> Robert. You may recall that from very early in the discussion, I was not
> enthusiastic, to put it lightly, about either of the solutions. Instead, I
> believe that multi-hop BFD should be used to monitor the continuity of a
> path PE-PE, not ABR/ASBR-PE as suggested by Robert. I hope I've made my
> position clear.
>
> Regards,
> Greg
>
> On Sun, Jul 17, 2022 at 7:04 PM Aijun Wang 
> wrote:
>
>> Then considering both the scalability and possible false negative of BFD
>> based solution,  can we say that the PUA/UPA solution is more preferable?
>>
>>
>>
>> Best Regards
>>
>>
>>
>> Aijun Wang
>>
>> China Telecom
>>
>>
>>
>> *From:* lsr-boun...@ietf.org  *On Behalf Of *Greg
>> Mirsky
>> *Sent:* Monday, July 18, 2022 8:39 AM
>> *To:* Robert Raszuk 
>> *Cc:* Christian Hopps ; Peter Psenak <
>> ppse...@cisco.com>; lsr 
>> *Subject:* Re: [Lsr] UPA
>>
>>
>>
>> Hi Robert,
>>
>> top-posting and then my notes in-line under the GIM>> tag:
>>
>> As mentioned it is still not the same. BFDs on the link tell me that link
>> is up and part of the line card responder to BFD is alive.
>>
>> GIM>> I assume you refer to BFD single-hop. Then I have a question What
>> do you mean by "link is up"? If the link is Ethernet, p2p single-hop BFD in
>> the Down state may not indicate that the link is down but that the remote
>> peer is operating down.
>>
>>
>>
>> Multihop BFD sessions will tell me that PE is up or down and that at
>> least one connection to it is still up. That is subtle but there is an
>> important difference.
>>
>> GIM>> Not necessarily, depends on the implementation. I can imagine a
>> scenario, depending on the Detect Multiplier and Transmission Interval
>> values, when the BFD multi-hop session going down indicates that the
>> particular path to the remote PE lost continuity.
>>
>>
>>
>> And I repeat from the Abstract of RFC 5880:
>>
>>This document describes a protocol intended to detect faults in the
>>
>>bidirectional path between two forwarding engines, including
>>
>>interfaces, data link(s), and to the extent possible the forwarding
>>
>>engines themselves, with potentially very low latency.
>>
>> I believe that BFD cannot give us a reliable indication of the
>> operational state of a node that hosts the BFD session, applications, and
>> protocols hosted on that node.
>>
>>
>>
>> Regards,
>>
>> Greg
>>
>>
>>
>>
>>
>> On Sun, Jul 17, 2022 at 4:49 AM Robert Raszuk  wrote:
>>
>> Hi Christian,
>>
>>
>>
>> > It seems you saying use multi-hop BFD for fast detection b/c you've
>> gone and configured one of those same hops along the
>>
>> > multi-hop path to an incredibly slow link-local BFD rate in comparison
>> to the BFD multi-hop rate.
>>
>>
>>
>> Yes. That is exactly the case. What is however missing in your picture is
>> that UPA is not only about signalling that all links to a node went down.
>>
>>
>>
>> UPA is also about signalling node down while links are still up -
>> continue responding to BFD in the line cards.
>>
>>
>>
>> See what we need here is not a signalling moment when all peers of PE see
>> all links to it going down. What is really needed is to signal when such PE
>> can not perform its service function any more. And that BFD to interfaces
>> will not tell you.
>>
>>
>>
>>
>>
>> > Why would you do that? In fact you're defeating a fundamental scaling
>> aspect of link-state protocols here.
>>
>>
>>
>> Since I have no physical alternative to use as backup other then crappy
>> carrier's backup link.
>>
>>
>>
>>
>>
>> >  Now you have N multi-hop BFDs session

Re: [Lsr] UPA

[Robert Raszuk]

Because you do not want to destabilize link state protocol. Even in the
area.

You do not want to compute SPF immediately at each link flap.

But you do want to signal to remote guys a hint (remember UPA is a hint not
a solid state) that paths coming with this next hop should be discouraged.

I think you and Les may be thinking of UPA as solid state PE unreachable
"pulse". For me however signalling issues (even if transient) about local
PE liveness is more important and has a value.

Many thx,
R.

PS. In fact that mutlihop session between ABRs and local PEs could be smart
and fail when there are some issues with data and control plane on the box
outside of BFD path and BFD components. Obviously outside of OSPF or ISIS
as well. In other words link state get's signalled to ABRs that some less
specifics have fever and those ABRs in turn issue a UPA or SPA (suspicious)
messages to remote guys.

I am not seeing it as local area trigger must be IGP native even if further
flooding would be.


On Sun, Jul 17, 2022 at 11:18 PM Christian Hopps  wrote:

>
> I feel like this is so obvious that I must still be misunderstanding you.
>
> Why is it ok for N * multi-hop sessions to run over this crappy-link at
> millisecond rates, but *not* ok for a single link local session to do the
> same?
>
> Thanks,
> Chris.
>
> Robert Raszuk  writes:
>
> > Hi Les,
> >
> >
> >> You seem to be suggesting that multi-hop BFD could be more
> > aggressive in failure detection than single hop BFD in
> >
> >> the presence of some link with slow single hop BFD timers.
> >
> >> This makes no sense to me. In order to avoid false failure reports,
> > the multi-hop BFD session has to allow for IGP FRR > to occur, which
> > means it cannot be more aggressive than worst case link protection
> > mechanisms for the links which
> >
> >> may be used to reach the multi-hop destination.
> >
> >
> > Not quite.
> >
> > Your and Chris comment is correct when both links connecting such PE
> > would be having the same metric and would be equal class citizens as
> > far as IGP connectivity to PE.
> >
> > This is however not the case I am presenting.
> >
> > To illustrate further:
> >
> > Good link PE-P has BFD timbers 10 ms x 3 = 30 ms
> > Bad link has timers 2 s x 3 = 6 sec detection.
> >
> > Good link is always preferred IGP wise.
> >
> > So when bad link fails and good link is ok - no false positive is
> > triggered.
> >
> > When good link fails multihop session must be just slower then this
> > link so it's timers would be 20 ms x 3 = 60 ms.
> >
> > When bad link remains the only one active multihop will detect the PE
> > down 100 times faster !
> >
> >> But this would affect multi-hop BFD as well as single hop BFD.
> >
> > Not if multihop BFD is going to RP/RE. Perhaps some vendors can
> > handle it on LCs.
> >
> >> And, I would argue, your issue is really with the vendor who ships
> > such a product which
> >> has a serious functionality gap.
> >
> > I would not be that fast. PEs today are compute nodes and I am yet to
> > see distributed BFD supported on the NICs.
> >
> > Many thx !
> > Robert
> >
> >
> >
> > On Sun, Jul 17, 2022 at 6:57 PM Les Ginsberg (ginsberg) <
> > ginsb...@cisco.com> wrote:
> >
> >
> > Robert –
> >
> >
> >
> > I continue to be a bit unclear on the relevance of the points you
> > are making.
> >
> > And I do want to express my agreement with the points Peter and
> > Chris have made.
> >
> >
> >
> > In that vein, some top posted comments.
> >
> >
> >
> > You seem to be suggesting that multi-hop BFD could be more
> > aggressive in failure detection than single hop BFD in the
> > presence of some link with slow single hop BFD timers.
> >
> > This makes no sense to me. In order to avoid false failure
> > reports, the multi-hop BFD session has to allow for IGP FRR to
> > occur, which means it cannot be more aggressive than worst case
> > link protection mechanisms for the links which may be used to
> > reach the multi-hop destination.
> >
> >
> >
> > You also seem to be concerned about headless Line Cards
> > continuing to maintain BFD sessions even after control plane
> > failures.
> >
> > But this would affect multi-hop BFD as well as single hop BFD.
> >
> > And, I would argue, your issue is really with the vendor 

Re: [Lsr] UPA

[Robert Raszuk]

Hmm

I am not sure I follow what you just said.

1000s of PEs in an area ? Even if so you are worried about 1000s of
multihop BFD sessions to be handled at ABRs ?

But ABRs can be good vendor boxes and offload those 1000s of sessions to
LCs.

I was talking about PEs where they only do less then 10 multihop BFD
sessions to local area ABRs.

Please clarify.

Thx,
R.


On Sun, Jul 17, 2022 at 10:57 PM Les Ginsberg (ginsberg) 
wrote:

> Robert –
>
>
>
> Throughout the discussions of various alternatives to solving this problem
> we have been consistently saying that the solution MUST work at scale – up
> to thousands of PEs.
>
> That’s because there are customers asking for this.
>
>
>
>Les
>
>
>
> *From:* Robert Raszuk 
> *Sent:* Sunday, July 17, 2022 1:12 PM
> *To:* Les Ginsberg (ginsberg) 
> *Cc:* Christian Hopps ; Peter Psenak (ppsenak) <
> ppse...@cisco.com>; lsr 
> *Subject:* Re: [Lsr] UPA
>
>
>
> Hi Les,
>
>
>
> Your excerpted top posting may not have enough context for everyone to
> easily follow the point being discussed – hopefully that is not the case.
>
>
>
> Well just trying to respond to the points raised.
>
>
>
> *[LES:] Sooo, you apparently think it is OK to declare a node unreachable
> even though the criteria for determining that the link(s) being used to
> reach the node are down have not yet been met.*
>
>
>
> Yes. In fact I am not worrying about hard down. I am more worried
> about brownouts.
>
>
>
> *I would think this is prone to false negatives.*
>
>
>
> Well maybe yes maybe no.
>
>
>
> But let's think about it in the bigger context of UPA which is the subject
> here.
>
>
>
> Nodes receiving UPA will only deprioritize paths with such next hop. If
> there is no backup paths it will not harm anything. If there are
> backup paths the indication that some remote PE has a hiccup seems to me
> like very good signalling to use alternative path instead of continuing to
> go via potentially breaking node.
>
>
>
>
>
> Not if multihop BFD is going to RP/RE. Perhaps some vendors can handle it
> on LCs.
>
>
>
> *[LES:] Indeed they can – and if they cannot then the scalability of your
> proposed solution is limited.*
>
>
>
> Really ? How ?
>
>
>
> Do you see any scalability issues with 2 (oh maybe 4-8) multihop BFD
> sessions to *local* ABRs ? How is this not scalable ? Of course if your LC
> <--> RE/RP path takes up to 100 ms in the box your multihop timers must
> keep this in mind however this is I think obvious.
>
>
>
> Many thx,
>
> R.
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] UPA

[Robert Raszuk]

Hi Les,

Your excerpted top posting may not have enough context for everyone to
> easily follow the point being discussed – hopefully that is not the case.
>

Well just trying to respond to the points raised.

*[LES:] Sooo, you apparently think it is OK to declare a node unreachable
> even though the criteria for determining that the link(s) being used to
> reach the node are down have not yet been met.*
>

Yes. In fact I am not worrying about hard down. I am more worried
about brownouts.


> *I would think this is prone to false negatives.*
>

Well maybe yes maybe no.

But let's think about it in the bigger context of UPA which is the subject
here.

Nodes receiving UPA will only deprioritize paths with such next hop. If
there is no backup paths it will not harm anything. If there are
backup paths the indication that some remote PE has a hiccup seems to me
like very good signalling to use alternative path instead of continuing to
go via potentially breaking node.


Not if multihop BFD is going to RP/RE. Perhaps some vendors can handle it
> on LCs.
>
>
>
> *[LES:] Indeed they can – and if they cannot then the scalability of your
> proposed solution is limited.*
>

Really ? How ?

Do you see any scalability issues with 2 (oh maybe 4-8) multihop BFD
sessions to *local* ABRs ? How is this not scalable ? Of course if your LC
<--> RE/RP path takes up to 100 ms in the box your multihop timers must
keep this in mind however this is I think obvious.

Many thx,
R.

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

Re: [Lsr] UPA

[Robert Raszuk]

> I believe a lot of the false positive and / or negative issues are helped
with BFD Strict mode.

BFD strict mode is completely irrelevant to this discussion and UPA. At no
point we are here concerned with the interface up event which BFD strict
mode is addressing.


> I agree with Les on the comments related to BFD.

I recommend first to understand the scenario then provide cheerleading.

Many Thx,
R.


On Sun, Jul 17, 2022 at 7:31 PM Gyan Mishra  wrote:

>
> I agree with Les on the comments related to BFD.
>
> I believe a lot of the false positive and / or negative issues are helped
> with BFD Strict mode.
>
> Thanks
>
> Gyan
>
> On Sun, Jul 17, 2022 at 12:57 PM Les Ginsberg (ginsberg)  40cisco@dmarc.ietf.org> wrote:
>
>> Robert –
>>
>>
>>
>> I continue to be a bit unclear on the relevance of the points you are
>> making.
>>
>> And I do want to express my agreement with the points Peter and Chris
>> have made.
>>
>>
>>
>> In that vein, some top posted comments.
>>
>>
>>
>> You seem to be suggesting that multi-hop BFD could be more aggressive in
>> failure detection than single hop BFD in the presence of some link with
>> slow single hop BFD timers.
>>
>> This makes no sense to me. In order to avoid false failure reports, the
>> multi-hop BFD session has to allow for IGP FRR to occur, which means it
>> cannot be more aggressive than worst case link protection mechanisms for
>> the links which may be used to reach the multi-hop destination.
>>
>>
>>
>> You also seem to be concerned about headless Line Cards continuing to
>> maintain BFD sessions even after control plane failures.
>>
>> But this would affect multi-hop BFD as well as single hop BFD.
>>
>> And, I would argue, your issue is really with the vendor who ships such a
>> product which has a serious functionality gap.
>>
>>
>>
>> Finally, I am not certain you are saying this – but you seem to be saying
>> that BFD itself does not tell you whether the BFD client is fully sane.
>> This I agree with – but again it applies to Multi-hop BFD as well as single
>> hop BFD.
>>
>>
>>
>> Thanx.
>>
>>
>>
>> Les
>>
>>
>>
>>
>>
>>
>>
>> *From:* Lsr  *On Behalf Of * Robert Raszuk
>> *Sent:* Sunday, July 17, 2022 4:49 AM
>> *To:* Christian Hopps 
>> *Cc:* Peter Psenak (ppsenak) ; lsr 
>> *Subject:* Re: [Lsr] UPA
>>
>>
>>
>> Hi Christian,
>>
>>
>>
>> > It seems you saying use multi-hop BFD for fast detection b/c you've
>> gone and configured one of those same hops along the
>>
>> > multi-hop path to an incredibly slow link-local BFD rate in comparison
>> to the BFD multi-hop rate.
>>
>>
>>
>> Yes. That is exactly the case. What is however missing in your picture is
>> that UPA is not only about signalling that all links to a node went down.
>>
>>
>>
>> UPA is also about signalling node down while links are still up -
>> continue responding to BFD in the line cards.
>>
>>
>>
>> See what we need here is not a signalling moment when all peers of PE see
>> all links to it going down. What is really needed is to signal when such PE
>> can not perform its service function any more. And that BFD to interfaces
>> will not tell you.
>>
>>
>>
>>
>>
>> > Why would you do that? In fact you're defeating a fundamental scaling
>> aspect of link-state protocols here.
>>
>>
>>
>> Since I have no physical alternative to use as backup other then crappy
>> carrier's backup link.
>>
>>
>>
>>
>>
>> >  Now you have N multi-hop BFDs sessions (one per ABR) running over the
>> link instead of just *1* session running on that link.
>>
>>
>>
>> As mentioned it is still not the same. BFDs on the link tell me that link
>> is up and part of the line card responder to BFD is alive.
>>
>>
>>
>> Multihop BFD sessions will tell me that PE is up or down and that at
>> least one connection to it is still up. That is subtle but there is an
>> important difference.
>>
>>
>>
>>
>>
>> > If your (possible multiple sessions of) multi-hop BFD can be sent over
>> this "slow link" at fast rate X then why not do it just once using a link
>> local BFD session at the same rate instead?
>>
>>
>>
>> As described, BFD over a link is not the same as BF

Re: [Lsr] UPA

[Robert Raszuk]

Hi Les,

> You seem to be suggesting that multi-hop BFD could be more aggressive in
failure detection than single hop BFD in

> the presence of some link with slow single hop BFD timers.

> This makes no sense to me. In order to avoid false failure reports, the
multi-hop BFD session has to allow for IGP FRR > to occur, which means it
cannot be more aggressive than worst case link protection mechanisms for
the links which

> may be used to reach the multi-hop destination.

Not quite.

Your and Chris comment is correct when both links connecting such PE would
be having the same metric and would be equal class citizens as far as IGP
connectivity to PE.

This is however not the case I am presenting.

To illustrate further:

Good link PE-P has BFD timbers 10 ms x 3 = 30 ms
Bad link has timers 2 s x 3 = 6 sec detection.

Good link is always preferred IGP wise.

So when bad link fails and good link is ok - no false positive is
triggered.

When good link fails multihop session must be just slower then this link so
it's timers would be 20 ms x 3 = 60 ms.

When bad link remains the only one active multihop will detect the PE down
100 times faster !

> But this would affect multi-hop BFD as well as single hop BFD.

Not if multihop BFD is going to RP/RE. Perhaps some vendors can handle it
on LCs.

> And, I would argue, your issue is really with the vendor who ships such a
product which
> has a serious functionality gap.

I would not be that fast. PEs today are compute nodes and I am yet to see
distributed BFD supported on the NICs.

Many thx !
Robert



On Sun, Jul 17, 2022 at 6:57 PM Les Ginsberg (ginsberg) 
wrote:

> Robert –
>
>
>
> I continue to be a bit unclear on the relevance of the points you are
> making.
>
> And I do want to express my agreement with the points Peter and Chris have
> made.
>
>
>
> In that vein, some top posted comments.
>
>
>
> You seem to be suggesting that multi-hop BFD could be more aggressive in
> failure detection than single hop BFD in the presence of some link with
> slow single hop BFD timers.
>
> This makes no sense to me. In order to avoid false failure reports, the
> multi-hop BFD session has to allow for IGP FRR to occur, which means it
> cannot be more aggressive than worst case link protection mechanisms for
> the links which may be used to reach the multi-hop destination.
>
>
>
> You also seem to be concerned about headless Line Cards continuing to
> maintain BFD sessions even after control plane failures.
>
> But this would affect multi-hop BFD as well as single hop BFD.
>
> And, I would argue, your issue is really with the vendor who ships such a
> product which has a serious functionality gap.
>
>
>
> Finally, I am not certain you are saying this – but you seem to be saying
> that BFD itself does not tell you whether the BFD client is fully sane.
> This I agree with – but again it applies to Multi-hop BFD as well as single
> hop BFD.
>
>
>
> Thanx.
>
>
>
> Les
>
>
>
>
>
>
>
> *From:* Lsr  *On Behalf Of * Robert Raszuk
> *Sent:* Sunday, July 17, 2022 4:49 AM
> *To:* Christian Hopps 
> *Cc:* Peter Psenak (ppsenak) ; lsr 
> *Subject:* Re: [Lsr] UPA
>
>
>
> Hi Christian,
>
>
>
> > It seems you saying use multi-hop BFD for fast detection b/c you've gone
> and configured one of those same hops along the
>
> > multi-hop path to an incredibly slow link-local BFD rate in comparison
> to the BFD multi-hop rate.
>
>
>
> Yes. That is exactly the case. What is however missing in your picture is
> that UPA is not only about signalling that all links to a node went down.
>
>
>
> UPA is also about signalling node down while links are still up - continue
> responding to BFD in the line cards.
>
>
>
> See what we need here is not a signalling moment when all peers of PE see
> all links to it going down. What is really needed is to signal when such PE
> can not perform its service function any more. And that BFD to interfaces
> will not tell you.
>
>
>
>
>
> > Why would you do that? In fact you're defeating a fundamental scaling
> aspect of link-state protocols here.
>
>
>
> Since I have no physical alternative to use as backup other then crappy
> carrier's backup link.
>
>
>
>
>
> >  Now you have N multi-hop BFDs sessions (one per ABR) running over the
> link instead of just *1* session running on that link.
>
>
>
> As mentioned it is still not the same. BFDs on the link tell me that link
> is up and part of the line card responder to BFD is alive.
>
>
>
> Multihop BFD sessions will tell me that PE is up or down and that at least
> one connection to it is still up. That is subtle but there is a

Re: [Lsr] UPA

[Robert Raszuk]

Hi Christian,

> It seems you saying use multi-hop BFD for fast detection b/c you've gone
and configured one of those same hops along the
> multi-hop path to an incredibly slow link-local BFD rate in comparison to
the BFD multi-hop rate.

Yes. That is exactly the case. What is however missing in your picture is
that UPA is not only about signalling that all links to a node went down.

UPA is also about signalling node down while links are still up - continue
responding to BFD in the line cards.

See what we need here is not a signalling moment when all peers of PE see
all links to it going down. What is really needed is to signal when such PE
can not perform its service function any more. And that BFD to interfaces
will not tell you.


> Why would you do that? In fact you're defeating a fundamental scaling
aspect of link-state protocols here.

Since I have no physical alternative to use as backup other then crappy
carrier's backup link.


>  Now you have N multi-hop BFDs sessions (one per ABR) running over the
link instead of just *1* session running on that link.

As mentioned it is still not the same. BFDs on the link tell me that link
is up and part of the line card responder to BFD is alive.

Multihop BFD sessions will tell me that PE is up or down and that at least
one connection to it is still up. That is subtle but there is an important
difference.


> If your (possible multiple sessions of) multi-hop BFD can be sent over
this "slow link" at fast rate X then why not do it just once using a link
local BFD session at the same rate instead?

As described, BFD over a link is not the same as BFD to the node.


And to project a bigger picture why I asked this ...

If I would do the fast signalling of PE going down in BGP RRs would likely
have some form of detecting PE liveness anyway. Multihop BFD could be one
such option. So I was thinking
if the same can be done with IGP detection wise.

Note also that there are folks who do recommend PE to PE full mesh of BFD.
That orders of magnitude more BFD sessions then within an area.

Many thx,
R.




On Sun, Jul 17, 2022 at 8:48 AM Christian Hopps  wrote:

>
> Robert Raszuk  writes:
>
> > Peter,
> >
> > In the scenario described there is really nothing to be tuned as you
> > are limited by the quality of local telco carriers.
> >
> > Apparently you are not willing to consider it. Thank you.
>
> First, I don't like any of these unreachable things, and so I don't want
> my comment to reflect in any way on them one way or the other.
>
> On a more fundamental level though, I don't see why Peter's answers are
> not sufficient here. In particular, unless I am misunderstanding your
> scenario it seems ... unrealistic -- but maybe I've missed something.
>
> It seems you saying use multi-hop BFD for fast detection b/c you've gone
> and configured one of those same hops along the multi-hop path to an
> incredibly slow link-local BFD rate in comparison to the BFD multi-hop
> rate. Why would you do that? In fact you're defeating a fundamental scaling
> aspect of link-state protocols here. Now you have N multi-hop BFDs sessions
> (one per ABR) running over the link instead of just *1* session running on
> that link.
>
> If your (possible multiple sessions of) multi-hop BFD can be sent over
> this "slow link" at fast rate X then why not do it just once using a link
> local BFD session at the same rate instead?
>
> If you configure the "down-detect" timer to a slow rate, then it'll be
> slow detecting the link down. It's sort of tautological, right?
>
> Thanks,
> Chris.
>
> >
> > Cheers,
> > R.
> >
> >
> > On Thu, Jul 7, 2022 at 2:43 PM Peter Psenak 
> > wrote:
> >
> > Robert,
> >
> > people know how to tune IGPs for faster convergence. They may or
> > may do,
> > it's their decision based on their requirements. BFD is a
> > standard
> > mechanism used by IGPs for fast detection of the adjacency loss.
> > I see
> > no reason to require anything more or special for the UPA.
> >
> > thanks,
> > Peter
> >
> > On 07/07/2022 14:28, Robert Raszuk wrote:
> > > Peter,
> > >
> > > I think you are still not clear on some deployment scenarios.
> > >
> > > So allow me to restate ...
> > >
> > > It is pretty often (if not always) a valid requirement to
> > redundantly
> > > connect your PEs over different physical paths to the P nodes
> > in the area.
> > >
> > > For simplicity let's assume there are two links (it could be
> > more then
> > > two which only makes the situation 

Re: [Lsr] IGP Monitoring Protocol

[Robert Raszuk]

Hi Christian,

Your message is actually spot on and very timely.

Last friday I have had a great meeting with Thomas and he actually
suggested to decouple YANG from IMP transport. And I think this is great
suggestion.

In the same time main goal of IMP is to provide BGP-LS TLVs directly from
IGP process over either TCP or QUIC sessions in native IGP format. So IMP
is focusing on this very functionality.

Many thx,
R.



On Sun, Jul 17, 2022 at 12:38 AM Christian Hopps  wrote:

>
> Robert Raszuk  writes:
>
> > Btw this independent attempt by two WG groups to normalize link state
> > data is a clear proof that the YANG model has failed here.
>
> I'm not sure which "YANG model" you are referring to here (perhaps you
> just mean YANG in general?), but I don't think YANG itself has failed at
> all. Has anyone even tried to attack this problem directly using it yet?
>
> I'm pretty sure that GRPC is being used by google for telemetry, I don't
> know if they're using it for LSDB information or not, but they have the
> infrastructure setup for it obviously. I'm pretty sure Microsoft is doing
> similar stuff to google with YANG modeled data as well.
>
> FWIW, YANG is a modeling language describing structured data, the
> transport is just as important here, and NETCONF or RESTCONF probably
> aren't the ones to use for your application. Maybe someone needs to look
> into marrying the correct transport, with the correct YANG modeled data and
> describe a system that would do what you want using existing technologies.
>
> Thanks,
> Chris.
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] FW: New Version Notification for draft-lin-lsr-srv6-service-sid-00.txt

[Robert Raszuk]

Hi,

Thank you for publishing this document.

I have few comments about it.

#1 - While you are defining IGP extensions I think this document still
belongs in BESS WG not in LSR WG.

#2 - Injecting IPv4 sites to your IPv6 only IGP is IMO a terrible idea. BGP
overlays are used to keep core IGPs stable and lean. Networks which do not
want to run BGP in the core just use dual stack.

#3 However I do see value of general idea as expressed in this draft but
only for deployment scenario where you DO NOT inject prefixes from sites to
your IGP core and you use CSC (carrier's carrier) approach - still no BGP
in IPv6 core. That means IPv4 sites exchange IPv4 reachability over the top
and encapsulate packets to the other edge of IPv4 islands.

So for #3 I would in fact state that this is not a bad idea. But not for #2
as currently written.

Many thx,
Robert.


On Thu, Jul 14, 2022 at 1:58 PM Chenmengxiao  wrote:

> Hi WG,
>
> We posted a new draft: draft-lin-lsr-srv6-service-sid-00. It's about
> advertising SRv6 service SID in IGP.
>
> For the IPv6 backbone networks not deploying BGP, for example, the campus
> network using IS-IS or OSPFv3, there may be requirements to interconnect
> IPv4 islands. SRv6 Service SIDs like End.DT4 may be used to realize such
> requirements. Similar with the BGP based L3 Service over SRv6, SRv6 Service
> SIDs like End.DT4 may be used to realize such requirements. This document
> extends IS-IS and OSPFv3 to advertise SRv6 Service SIDs along with
> prefixes. The receiving router creates forwarding entries associated with
> SID.
> In the IPv4 over IPv6 scenario, the IPv4 packets will be encapsulated in
> an outer IPv6 header with the destination address of SRv6 Service SID and
> forwarded according to the SID. When they are forwarded to the destination,
> the SID's owner decapsulates the outer IPv6 header and performs IPv4 table
> lookup to forward the inner IPv4 packet. Furthermore, it may be extended to
> support SRv6-TE Services in IGP.
>
> Any questions or comments are welcomed.
>
> Thanks,
> Mengxiao Chen
>
> -Original Message-
> From: internet-dra...@ietf.org 
> Sent: Monday, July 11, 2022 4:38 PM
> To: linchangwang (RD) ; lihao (02566, RD) <
> li...@h3c.com>; chenmengxiao (RD) 
> Subject: New Version Notification for draft-lin-lsr-srv6-service-sid-00.txt
>
>
> A new version of I-D, draft-lin-lsr-srv6-service-sid-00.txt
> has been successfully submitted by Mengxiao Chen and posted to the IETF
> repository.
>
> Name:draft-lin-lsr-srv6-service-sid
> Revision:00
> Title:IS-IS and OSPFv3 Extensions to Advertise SRv6 Service SID
> Document date:2022-07-11
> Group:Individual Submission
> Pages:9
> URL:
> https://www.ietf.org/archive/id/draft-lin-lsr-srv6-service-sid-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-lin-lsr-srv6-service-sid/
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-lin-lsr-srv6-service-sid
>
>
> Abstract:
>The IPv6 backbone networks only deploying IGP may be required to
>interconnect IPv4 islands. SRv6 Service SIDs like End.DT4 may be
>used to realize such requirements. This document extends IS-IS and
>OSPFv3 to advertise SRv6 Service SIDs.
>
>
>
>
> The IETF Secretariat
>
>
>
> -
> 本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出
> 的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、
> 或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本
> 邮件！
> This e-mail and its attachments contain confidential information from New
> H3C, which is
> intended only for the person or entity whose address is listed above. Any
> use of the
> information contained herein in any way (including, but not limited to,
> total or partial
> disclosure, reproduction, or dissemination) by persons other than the
> intended
> recipient(s) is prohibited. If you receive this e-mail in error, please
> notify the sender
> by phone or email immediately and delete it!
> ___
> 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-ginsberg-lsr-rfc8919bis-01.txt

[Robert Raszuk]

Hi Les,

> it is quite permissible to restrict the meaning of a given term

Yes you are correct. It sure is.

But I just do not get why we are coming with counter intuitive terms in key
specifications.

Kind regards,
R.


On Wed, Jul 13, 2022 at 11:07 PM Les Ginsberg (ginsberg) 
wrote:

> Robert –
>
>
>
> I have replied to Shraddha’s post – pointing out that there is an explicit
> definition of “application” in the documents.
>
>
>
> I have nothing more to add in response to your comments other than to
> reemphasize that it is quite permissible to restrict the meaning of a given
> term when used in the scope of a document so long as we have a clear
> definition – which we do.
>
>
>
>Les
>
>
>
>
>
>
>
> *From:* Robert Raszuk 
> *Sent:* Wednesday, July 13, 2022 12:25 AM
> *To:* Shraddha Hegde 
> *Cc:* Les Ginsberg (ginsberg) ; lsr@ietf.org
> *Subject:* Re: [Lsr] New Version Notification for
> draft-ginsberg-lsr-rfc8919bis-01.txt
>
>
>
> Hello,
>
>
>
> Yes I very much support Shraddha's msg.
>
>
>
> The term "application" should not even be (re)defined up front, but
> completely removed from the document. Likewise ASLA should be renamed too.
> I thought we had the agreement in subsequent documents to do so. Why not
> fix it across the board ?
>
>
>
> If we look at the dictionary:
>
>
> https://dictionary.cambridge.org/dictionary/english/application
>
>
>
> I do not see any definition which would even closely fit the real use case
> for this term here. Application is a computer program not a network
> forwarding/protection mechanism like RSVP-TE, SRv6, LFA etc ...
>
>
>
> If someone who is writing real applications - say ticker forwarder - and
> he takes such RFC she or he will be super confused and will start expecting
> his application to have its own bit to be identified directly in the ASLA
> bit mask.
>
>
>
> Thx,
>
> R.
>
>
>
> On Wed, Jul 13, 2022 at 7:52 AM Shraddha Hegde  40juniper@dmarc.ietf.org> wrote:
>
> Authors,
>
> Thanks for the bis version of RFC 8919 and the clarifying text on errata.
> The issues raised with respect to the errata have been addressed well in
> the bis version.
> However, I believe that the bis version is also an opportunity for us to
> address any other ambiguities and clarifications and not just restrict it
> to
> the raised errata. RFC 8919 is going to serve as base document for many
> future applications /attributes and a clear definition and documentation
> is necessary for interoperable implementations as well as for future
> evolution of the protocol.
>
> I have below comments on the document
>
> 1. The definition of what constitutes an application in the scope of this
> document is not
> clearly defined in the document. Currently RSVP,SR-TE, LFA, Flex-algo
> have been defined
> so it appears that any application that uses TE attributes can be
> defined as a separate application.
> The TE mechanisms like RSVP, SR-TE and flex-algo have been defined
> as separate applications
> and it appears features having significantly different
> forwarding plane is defined as new application. It is not clear if
> SRv6 would be
> qualified as a new application.
> LFA for different forwarding planes such as IP, MPLS, SRv6 are not
> separate applications
> but LFA is defined as a single application.
> I have also seen many drafts confusing application specific to be
> user application.
> I  suggest to add a section and describe what is an application
> clearly in the draft that should provide
> sufficient input on what can be defined as an application from
> ASLA context in future.
>
>
> 2. "   When SABM or UDABM Length is non-zero and the L-flag is NOT set, all
>applications specified in the bit mask MUST use the link attribute
>advertisements in the sub-TLV."
>Applications such as RSVP, SR-TE, LFA already use legacy
> advertisements.
>This document suggests that if any attribute is advertised with an
> application bit set in ASLA
>ASLA advertisements MUST be used by that application.
>Implementations may support ASLA for only some applications.
>I suggest to add below text.
>
>Until all nodes upgraded to support ASLA for a particular application,
> different values of link attributes
>MUST NOT be advertised for that application in legacy advertisement and
> ASLA advertisements.
>
>
> Rgds
> Shraddha
>
>
> Juniper Business Use Only
>
> -Original Message-
> From: Lsr  On Behalf Of Les Ginsberg (ginsberg)
> Sen

Re: [Lsr] New Version Notification for draft-ginsberg-lsr-rfc8919bis-01.txt

[Robert Raszuk]

Hello,

Yes I very much support Shraddha's msg.

The term "application" should not even be (re)defined up front, but
completely removed from the document. Likewise ASLA should be renamed too.
I thought we had the agreement in subsequent documents to do so. Why not
fix it across the board ?

If we look at the dictionary:

https://dictionary.cambridge.org/dictionary/english/application

I do not see any definition which would even closely fit the real use case
for this term here. Application is a computer program not a network
forwarding/protection mechanism like RSVP-TE, SRv6, LFA etc ...

If someone who is writing real applications - say ticker forwarder - and he
takes such RFC she or he will be super confused and will start expecting
his application to have its own bit to be identified directly in the ASLA
bit mask.

Thx,
R.

On Wed, Jul 13, 2022 at 7:52 AM Shraddha Hegde  wrote:

> Authors,
>
> Thanks for the bis version of RFC 8919 and the clarifying text on errata.
> The issues raised with respect to the errata have been addressed well in
> the bis version.
> However, I believe that the bis version is also an opportunity for us to
> address any other ambiguities and clarifications and not just restrict it
> to
> the raised errata. RFC 8919 is going to serve as base document for many
> future applications /attributes and a clear definition and documentation
> is necessary for interoperable implementations as well as for future
> evolution of the protocol.
>
> I have below comments on the document
>
> 1. The definition of what constitutes an application in the scope of this
> document is not
> clearly defined in the document. Currently RSVP,SR-TE, LFA, Flex-algo
> have been defined
> so it appears that any application that uses TE attributes can be
> defined as a separate application.
> The TE mechanisms like RSVP, SR-TE and flex-algo have been defined
> as separate applications
> and it appears features having significantly different
> forwarding plane is defined as new application. It is not clear if
> SRv6 would be
> qualified as a new application.
> LFA for different forwarding planes such as IP, MPLS, SRv6 are not
> separate applications
> but LFA is defined as a single application.
> I have also seen many drafts confusing application specific to be
> user application.
> I  suggest to add a section and describe what is an application
> clearly in the draft that should provide
> sufficient input on what can be defined as an application from
> ASLA context in future.
>
>
> 2. "   When SABM or UDABM Length is non-zero and the L-flag is NOT set, all
>applications specified in the bit mask MUST use the link attribute
>advertisements in the sub-TLV."
>Applications such as RSVP, SR-TE, LFA already use legacy
> advertisements.
>This document suggests that if any attribute is advertised with an
> application bit set in ASLA
>ASLA advertisements MUST be used by that application.
>Implementations may support ASLA for only some applications.
>I suggest to add below text.
>
>Until all nodes upgraded to support ASLA for a particular application,
> different values of link attributes
>MUST NOT be advertised for that application in legacy advertisement and
> ASLA advertisements.
>
>
> Rgds
> Shraddha
>
>
> Juniper Business Use Only
>
> -Original Message-
> From: Lsr  On Behalf Of Les Ginsberg (ginsberg)
> Sent: Tuesday, June 21, 2022 8:59 AM
> To: lsr@ietf.org
> Subject: [Lsr] FW: New Version Notification for
> draft-ginsberg-lsr-rfc8919bis-01.txt
>
> [External Email. Be cautious of content]
>
>
> Folks -
>
> Please note V01 of the RFC8919bis draft has been posted.
>
> This version incorporates comments received from Bruno.
>
>Les
>
> -Original Message-
> From: internet-dra...@ietf.org 
> Sent: Monday, June 20, 2022 8:22 PM
> To: John Drake ; Les Ginsberg (ginsberg) <
> ginsb...@cisco.com>; Peter Psenak (ppsenak) ; Stefano
> Previdi ; Wim Henderickx 
> Subject: New Version Notification for draft-ginsberg-lsr-rfc8919bis-01.txt
>
>
> A new version of I-D, draft-ginsberg-lsr-rfc8919bis-01.txt
> has been successfully submitted by Les Ginsberg and posted to the IETF
> repository.
>
> Name:   draft-ginsberg-lsr-rfc8919bis
> Revision:   01
> Title:  IS-IS Application-Specific Link Attributes
> Document date:  2022-06-20
> Group:  Individual Submission
> Pages:  25
> URL:
> https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-ginsberg-lsr-rfc8919bis-01.txt__;!!NEt6yMaO-gk!GPzaO3U3q5SdDuafGd00fxwDKseki5v69TK_7OWQ6XlbSNK2EwgaJqAIeyd1bbeYOilNpT-2QlLXl7KIf7D24NLUlB5e_NMk$
> Status:
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ginsberg-lsr-rfc8919bis/__;!!NEt6yMaO-gk!GPzaO3U3q5SdDuafGd00fxwDKseki5v69TK_7OWQ6XlbSNK2EwgaJqAIeyd1bbeYOilNpT-2QlLXl7KIf7D24NLUlMHc2Gn4$
> Html:
> 

Re: [Lsr] IGP Monitoring Protocol

[Robert Raszuk]

Hi Les,

I agree with your point of view except this statement:

> the consumer now needs to connect to every router in each IGP area (or at
least each router of interest)

Use of Producer's proxy can vastly simplify this if we ever get to
that point.

But yes IMP is just trying to relax BGP from carrying BGP-LS. The only
exception in the current version of the spec is to optionally share local
configuration - which I thought would be helpful. But I am not attached to
it :)

To your point on network management do you think BMP is a network
management protocol ? It reports local RIBs, it reports peer state etc ...

I think there is no clear line here what is and what is not a network mgmt.
And depending who you ask you will get a different answer. Maybe this is
why network management is in such a great shape today :)

Many thx,
Robert








On Tue, Jul 12, 2022 at 4:03 PM Les Ginsberg (ginsberg) 
wrote:

> Hannes -
>
> Thanx for the perspective.
> Your post reminds me of something I wanted to say.
>
> This discussion was started to discuss alternatives to BGP-LS.
> It has quickly broadened to include discussion of what I would call
> network management.
> This is fine - if the community wants to look at both use cases I have no
> objection.
> But I think it is important to understand the difference in requirements.
>
> The consumer of BGP-LS needs to acquire the topology information for
> multiple IGP areas/domains. To get this, the consumer only needs to connect
> to a small number of ABRs/IGP area.
> And currently there is only one standardized way to do this (RFC 7752).
>
> However, once we start talking about information which is NOT part of the
> LSDB (e.g., adjacencies, rib contents) the consumer now needs to connect to
> every router in each IGP area (or at least each router of interest) and the
> existing alternatives to support this are a different set (BMP, YANG data
> models, telemetry).
>
> This does not preclude the use of a single "protocol" (such as IMP) to
> support both use cases, but since the requirements are very different I
> would find it easier to have a meaningful discussion if the two use cases
> were discussed in separate threads.
>
> As it seems likely we are headed towards an interim meeting on such topics
> (based on available time and the WG chair comments) I would also like to
> know if both topics are in scope for a common meeting or if they will be
> split into separate meetings. Either way is fine w me.
>
> Thanx.
>
>Les
>
>
>
> > -Original Message-
> > From: Lsr  On Behalf Of Hannes Gredler
> > Sent: Tuesday, July 12, 2022 6:23 AM
> > To: Robert Raszuk 
> > Cc: bruno.decra...@orange.com; lsr ; idr@ietf. org
> > ; Susan Hares 
> > Subject: Re: [Lsr] IGP Monitoring Protocol
> >
> > Hi Robert,
> >
> > When designing BGP-LS we had to make a fundamental choice for expressing
> > an link-state graph.
> > the two models under consideration:
> >
> > 1) encapsulating raw IGP LS PDUs into some NLRI
> > 2) transcoding all elements of a graph (nodes, links, prefixes, node
> attributes
> > and link attributes)
> >into some NLRI
> >
> > We did see some value for getting visibility of serialized LS PDUs
> (proposal 1),
> > but then decided
> > against it as the primary use-case has been to be friendly to controllers
> > where controller developers
> > told us they do not want to to implement each and every protocol specific
> > IGP extension, but rather be comfortable
> > with a "protocol neutral" representation of a LS graph (proposal 2).
> > So here we are - if a certain feature is relevant to a controller, then
> you need
> > to specify a
> > BGP-LS transcoding scheme / TLV - no way around that if you want to be
> > friendly to controller developers.
> > As the IMP proposal stands today there is not much additional value
> > compared to the local-LSDB that BGP-LS provides already.
> >
> > However, for debugging IGPs there is certainly some value in monitoring
> the
> > flooding subsystem.
> > Now if you want to however monitor what's going on at the flooding level
> of
> > your IGP then there is
> > a tad of information missing in the current proposal.
> >
> > For further illustration let me pull-up the BMP analogy, where there is
> a clear
> > per-RIB orientation:
> > e.g. from which peer a NLRI has been received from ?
> >  what NLRI has been sent to particular peer ?
> >  per-peer stats, global stats ?
> >
> > That per-adj related information is IMO missing for IMP to be useful.
> > additional data of interest ->

Re: [Lsr] IGP Monitoring Protocol

[Robert Raszuk]

Hey Hannes,

Nice to hear from you !

Yes I was around when this "thing" happened :) Spoke with Stefano a lot
about it ... And as you can see from my proposal I do value a lot of
usability for existing controllers and I do support unification of exported
data into common format. That is why DATA type 1 and 2 use BGP-LS TLVs as
is.

Btw this independent attempt by two WG groups to normalize link state data
is a clear proof that the YANG model has failed here.

> As the IMP proposal stands today there is not much additional value
> compared to the local-LSDB that BGP-LS provides already.

The advantage is that it does not need to touch BGP. Does not need to make
an avalanche of drafts asking for extensions in IDR WG.

See you know the BGP-LS started very innocently .. Let's ship over BGP
session some topology and TE info for ALTO. But now it is growing out of
propositions. And no matter if the info is useful or not we see drafts of
people to just put their name on BGP RFC. And if it approved in LSR WG,
SPRING, DETNET ... the gate is wide open.

Do you think this makes sense ?

> That per-adj related information is IMO missing for IMP to be useful.
> additional data of interest -> where (interface) and when a LS PDU has
been received (redundant copies ?),
> retransmisison stats, differentiate between LSDB-in / LSDB-out,
LSDB-self-originated ?

Now as far as your comment about RIB data - that deserves a separate draft.
On the other hand peer's state I already had in the draft - but decided to
remove it for simplicity. Especially knowing that that peer state will be
reflected in LSDB anyway.

Also most of the info you listed is already available via telemetry. So I
am not trying to duplicate this on purpose. However as I said if anyone
finds it useful I will copy and paste it back to the draft.

Kind regards,
Robert


On Tue, Jul 12, 2022 at 3:23 PM Hannes Gredler  wrote:

> Hi Robert,
>
> When designing BGP-LS we had to make a fundamental choice for expressing
> an link-state graph.
> the two models under consideration:
>
> 1) encapsulating raw IGP LS PDUs into some NLRI
> 2) transcoding all elements of a graph (nodes, links, prefixes, node
> attributes and link attributes)
>into some NLRI
>
> We did see some value for getting visibility of serialized LS PDUs
> (proposal 1), but then decided
> against it as the primary use-case has been to be friendly to controllers
> where controller developers
> told us they do not want to to implement each and every protocol specific
> IGP extension, but rather be comfortable
> with a "protocol neutral" representation of a LS graph (proposal 2).
> So here we are - if a certain feature is relevant to a controller, then
> you need to specify a
> BGP-LS transcoding scheme / TLV - no way around that if you want to be
> friendly to controller developers.
> As the IMP proposal stands today there is not much additional value
> compared to the local-LSDB that BGP-LS provides already.
>
> However, for debugging IGPs there is certainly some value in monitoring
> the flooding subsystem.
> Now if you want to however monitor what's going on at the flooding level
> of your IGP then there is
> a tad of information missing in the current proposal.
>
> For further illustration let me pull-up the BMP analogy, where there is a
> clear per-RIB orientation:
> e.g. from which peer a NLRI has been received from ?
>  what NLRI has been sent to particular peer ?
>  per-peer stats, global stats ?
>
> That per-adj related information is IMO missing for IMP to be useful.
> additional data of interest -> where (interface) and when a LS PDU has
> been received (redundant copies ?), retransmisison stats,
> differentiate between LSDB-in / LSDB-out, LSDB-self-originated ?
>
> I am sure that bruno and his team have way more ideas for data that they
> would be interested in ;-)
>
> /hannes
>
> On Fri, Jul 08, 2022 at 09:20:04PM +0200, Robert Raszuk wrote:
> |Dear LSR WG,
> |Based on ongoing discussion in respect to the future of BGP-LS I
> |committed myself to put together an alternate proposal.
> |The main goal is not to just publish a -00 version of the draft using
> |different encapsulation. The goal is to make a useful tool which can
> help
> |to export link state information from network elements as well as
> assist
> |in network observability.
> |The IGP Monitoring Protocol (IMP) draft has been posted and should be
> |available at:
> |https://datatracker.ietf.org/doc/draft-raszuk-lsr-imp/
> |One of the key points I wanted to accomplish was full backwards
> |compatibility with TLVs defined for BGP-LS. In parallel other formats
> |(optional) are also supported.
> |The PUB-SUB nature or FILTERING capabilities

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

[Robert Raszuk]

Hi,


> Did you read the draft? The main difference is that since OSPF-GT is
>> generalized to be used for non-routing, there is no installation of routes.
>>
>

> Gyan> So The routes would be application use case specific “non
> routing” routes for example for BGP-LS it would be the related LSDB data
> that maybe similar data formatting as in RFC 7752 or new formatting
> described in separate draft.  The other possible use cases it’s “non
> routing” use cases, however in the BGP-LS case it is routing related info,
> not “non routing” related, so would this really be a good solution for
> BGP-LS?  I am thinking maybe not.
>

Guys,

It really does not matter if the northbound distribution of link state data
results in route installation or not. I understand why Acee is bringing
this point, but holistically looking at the entire domain it is irrelevant.

The data received is used for end to end path computation within a given
domain which is equally critical as local route installation.

So no matter what - Gyan you are correct here - it is better to be
accurate.

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

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

[Robert Raszuk]

> but kindly don't assert that others can't do it when it's being done.

I did not assert that it can not be done as it is done today.

But not everything which is done today should be kept that way for an
endless future.

Many thx,
R.


On Mon, Jul 11, 2022 at 8:18 PM Jeffrey Haas  wrote:

> Robert,
>
>
> On Jul 11, 2022, at 12:16 PM, Robert Raszuk  wrote:
> On Mon, Jul 11, 2022 at 6:09 PM Jeffrey Haas  wrote:
>
>> Tianran,
>>
>> Please note that nothing prohibits BGP-LS from being distributed over BMP
>> today aside from implementation support.  It's just another AFI/SAFI.
>>
>> -- Jeff
>>
>
> Do you mean to build a dummy Adj_RIB_IN or OUT just to feed BMP with the
> BGP-LS formatted data at the IGP node exporting this data ?
>
>
> Do whatever you'd do in your implementation for BMP for the scenario that
> makes sense for you.
>
> If you want to know what an upstream BGP router sent you, look at your
> rib-in.
> If you want to know what local state you've got and are intending to
> disseminate to your downstreams, look at your loc-rib.
> If you want to know what state you've sent to your downstream, look at
> your rib-out.
>
> None of this is unusual.
>
> rib-in and rib-out are clear from a BGP protocol fundamentals perspective.
>
> loc-rib has a touch of ambiguity, along with exactly the same dose of
> ambiguity about "where does locally originated state manifest in
> implementations" that made for a lot of discussion in GROW "recently" as
> the loc-rib and rib-out specs were being finished for RFC purposes.
>
> In our implementation, where loc-rib tracks the "lsdist.0" table, I'd
> probably use that for the majority of use cases that I'd want to get a feed
> for BGP-LS from BMP.  Or, I could just do a BGP-LS peering session and get
> it that way, but the discussion is that BMP works fine.
>
>
> If this would avoid BGP to check the syntax of what is send it would work
> fine .. but it would not. And BGP has no business on doing that check and
> to understand zoo of foreign extensions completely not related to BGP
> itself.
>
>
> Feel free to speak for your own implementation, but kindly don't assert
> that others can't do it when it's being done.
>
> -- Jeff
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Robert Raszuk]

HI Jeff,

On Mon, Jul 11, 2022 at 6:09 PM Jeffrey Haas  wrote:

> Tianran,
>
> Please note that nothing prohibits BGP-LS from being distributed over BMP
> today aside from implementation support.  It's just another AFI/SAFI.
>
> -- Jeff
>

Do you mean to build a dummy Adj_RIB_IN or OUT just to feed BMP with the
BGP-LS formatted data at the IGP node exporting this data ?

If this would avoid BGP to check the syntax of what is send it would work
fine .. but it would not. And BGP has no business on doing that check and
to understand zoo of foreign extensions completely not related to BGP
itself.

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

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

[Robert Raszuk]

Hi,

I think BMP is busy enough that loading more on it will be problematic.

Sourcing from two protocols just to leverage single transport session seems
not best idea.

IMO opening a new unicast session directly by the producer of subject data
is best way to share/export it.

Many thx,
R.

On Mon, Jul 11, 2022 at 5:34 PM Tianran Zhou  wrote:

> Hi Robert,
>
>
> Since our work is just follow the BMP which is in GROW in OPS area, we 
> presented this in OPSAWG and GROW.
>
>
> We want to reuse BMP for IGP with some simple extensions. We do not want to 
> create a new protocol only because of the BMP name.
>
> 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 23:05:56
>
> Hello Tianran,
>
> Oh I was not aware of such document. Did you ever share it with LSR WG
> before ?
>
> Quick browsing reveals that you have taken a bit different approach ..
> very IGP centric borrowing IGP encoding at the message level.
>
> For example peer state notification I purposely decided not to include as
> this is already reflected in the LSDB.
>
> I will take a more detail read of your spec. Then we can talk if there is
> some overlap or both approaches are so different then it makes sense to
> progress both. One size does not fit all :)
>
> Best,
> R.
>
>
>
>
> 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

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

[Robert Raszuk]

Tony,


> a) configuration is already standardized via NETCONF WG/channels/methods.
> pulling it via this seems redundant.
>

It is optional.


> b) YANG is already pulled via other channels so I see little value of
> pulling it here. same as a) basically
>

Please enumerate what channels ? And in the same time please indicate why
those channels are not good enough such that we need to keep stuffing BGP
protocol with the IGP, SR, Detnet etc .. data.



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

IMP is NOT doing flooding. If you think that control plane with 100s of CPU
cores will be slower in accepting your RE generated streams please kindly
reconsider.

But if the rate of data change would be a problem we would already choke
with TCP based BGP-LS. So not sure what problem are you seeing. Are you
referring to one interface flood mirroring ? For debugging it either be
nicely packed and sent or screen scraped. Which one do you prefer ?

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

beats me why would ever want to keep polluting BGP protocol like this. Are
you saying that IGP can not open a TCP socket or setup a QUIC session ? Is
it too much to ask ? Too complex ?


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

Please kindly observe what is mandatory and what is optional. Also kindly
notice the split between Producer and Producer's Proxy.

Thx,
R.






>
> -- tony
>
> On Mon, Jul 11, 2022 at 4:54 PM Tianran Zhou  40huawei@dmarc.ietf.org> 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-

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

[Robert Raszuk]

Hello Tianran,

Oh I was not aware of such document. Did you ever share it with LSR WG
before ?

Quick browsing reveals that you have taken a bit different approach .. very
IGP centric borrowing IGP encoding at the message level.

For example peer state notification I purposely decided not to include as
this is already reflected in the LSDB.

I will take a more detail read of your spec. Then we can talk if there is
some overlap or both approaches are so different then it makes sense to
progress both. One size does not fit all :)

Best,
R.




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&qu

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

[Robert Raszuk]

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 information
>>> from routers to interested nodes than using BGP for it.
>>>
>>>
>>>
>>> But to propose using OSPF to transport ISIS seems pretty brave :) I must
>>> admit it !
>>>
>>>
>>>
>>> With that I have few questions to the proposal - assuming the use case
>>> is to distribute links state info in a *point to point* fashion:
>>>
>>>
>>>
>>>1. What is the advantage - if any - to use a new OSPF
>>>instance/process to send link state data over a unicast session to a
>>>controller ?
>>>
>>>
>>>
>>> It doesn’t have to be unicast, the remote neighbor construct just
>>> extends the possibilities in OSPF-GT. With an OSPF LSDB, the obvious
>>> advantage is all the protocol machinery is in place.  Note that LSDB
>>> streaming is just but one use case and of OSPF-GT. The detals of this
>>> application would be specified in a separate draft.
>>>
>>>
>>>
>>>
>>>
>>>1. The draft is pretty silent on the nature of such a p2p session.
>>>Please be explicit if this is TCP, QUIC or what ?
>>>
>>>
>>>
>>> It is OSPF, 

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

[Robert Raszuk]

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 information
>> from routers to interested nodes than using BGP for it.
>>
>>
>>
>> But to propose using OSPF to transport ISIS seems pretty brave :) I must
>> admit it !
>>
>>
>>
>> With that I have few questions to the proposal - assuming the use case is
>> to distribute links state info in a *point to point* fashion:
>>
>>
>>
>>1. What is the advantage - if any - to use a new OSPF
>>instance/process to send link state data over a unicast session to a
>>controller ?
>>
>>
>>
>> It doesn’t have to be unicast, the remote neighbor construct just extends
>> the possibilities in OSPF-GT. With an OSPF LSDB, the obvious advantage is
>> all the protocol machinery is in place.  Note that LSDB streaming is just
>> but one use case and of OSPF-GT. The detals of this application would be
>> specified in a separate draft.
>>
>>
>>
>>
>>
>>1. The draft is pretty silent on the nature of such a p2p session.
>>Please be explicit if this is TCP, QUIC or what ?
>>
>>
>>
>> It is OSPF, OSPF has its own protocol identifier (89). This draft just
>> extends OSPF. I think you’ve misinterpreted the draft. Hence, your other
>> questions aren’t really applicable or would be answered in a draft of the
>> OSPF/IS-IS LSDB usage of OSPF-GT.
>>
>>
>>
>> Thanks,
>> Acee
>>
>>
>>
>>
>>
>>
>>
>> C) The draft is pretty silent on types of authentication for such
>> sessions. Security considerations are pretty weak in that respect as well.
>>
>>
>>
>>The security considerations for OSPF-GT will be similar to those for
>>OSPFv2 [RFC2328] and OSPFv3 [RFC5340].  However, since OSPF-GT is not
>>used to update OSPF routing, the consequences of attacks will be
>>dependent on advertised non-routing information.
>>
>>
>>
>> I would actually argue that security considerations of p2p remote
>> neighbors are actually quite different from security considerations of
>> flooding data.
>>
>>
>>
>> Along the same lines security is not about protecting your routing ... it
>> is much more about protecting the entire network by exposing critical
>> information externally to non authorized parties.
>>
>>
>>
>> D) Are there any PUB-SUB options possible for OSPF-GT ?
>>
>>
>>
>> E) Is there any filtering possible for OSPF-GT ?
>>
>>
>>
>> F) Are you envisioning use of OSPF-GT proxies and if so are you planning
>> to add t

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

[Robert Raszuk]

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 information
> from routers to interested nodes than using BGP for it.
>
>
>
> But to propose using OSPF to transport ISIS seems pretty brave :) I must
> admit it !
>
>
>
> With that I have few questions to the proposal - assuming the use case is
> to distribute links state info in a *point to point* fashion:
>
>
>
>1. What is the advantage - if any - to use a new OSPF instance/process
>to send link state data over a unicast session to a controller ?
>
>
>
> It doesn’t have to be unicast, the remote neighbor construct just extends
> the possibilities in OSPF-GT. With an OSPF LSDB, the obvious advantage is
> all the protocol machinery is in place.  Note that LSDB streaming is just
> but one use case and of OSPF-GT. The detals of this application would be
> specified in a separate draft.
>
>
>
>
>
>1. The draft is pretty silent on the nature of such a p2p session.
>Please be explicit if this is TCP, QUIC or what ?
>
>
>
> It is OSPF, OSPF has its own protocol identifier (89). This draft just
> extends OSPF. I think you’ve misinterpreted the draft. Hence, your other
> questions aren’t really applicable or would be answered in a draft of the
> OSPF/IS-IS LSDB usage of OSPF-GT.
>
>
>
> Thanks,
> Acee
>
>
>
>
>
>
>
> C) The draft is pretty silent on types of authentication for such
> sessions. Security considerations are pretty weak in that respect as well.
>
>
>
>The security considerations for OSPF-GT will be similar to those for
>OSPFv2 [RFC2328] and OSPFv3 [RFC5340].  However, since OSPF-GT is not
>used to update OSPF routing, the consequences of attacks will be
>dependent on advertised non-routing information.
>
>
>
> I would actually argue that security considerations of p2p remote
> neighbors are actually quite different from security considerations of
> flooding data.
>
>
>
> Along the same lines security is not about protecting your routing ... it
> is much more about protecting the entire network by exposing critical
> information externally to non authorized parties.
>
>
>
> D) Are there any PUB-SUB options possible for OSPF-GT ?
>
>
>
> E) Is there any filtering possible for OSPF-GT ?
>
>
>
> F) Are you envisioning use of OSPF-GT proxies and if so are you planning
> to add this to the document ?
>
>
>
> G) How are you going to address Receivers which do not support OSPF-GT
> parser ?
>
>
>
> H) As you know many operators are attracted to BGP-LS based on the fact
> that it offers the same view of information irrespective of what is the
> protocol producing the data. Is there some thought on such normalization in
> the OSPF-GT proposal ?
>
>
>
> I) What's the take of OSPF-GT draft authors on the YANG model in respect
> of using it for normalization of exported data ?
>
>
>
> To summarize IMHO we should not stretch routing protocols be it OSPF, ISIS
> or BGP to be messengers of link state data running and to artificially
> force them to run in a point-to-point model between router and controller.
>
>
>
> Kind regards,
>
> Robert
>
>
>
>
>
> On Sun, Jul 10, 2022 at 7:04 AM Yingzhen Qu 
> wrote:
>
> Hi,
>
>
>
> Since we’re discussing possible solutions, I’d like to bring up the draft:
> https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-transport-instance/
>
>
>
> We just submitted a new version. The name of the document is changed to
> “OSPF-GT (Generalized Transport)”, and a use case is added to use OSPF-GT
> as a possible replacement of BGP-LS.
>
>
>
> Note: OSPF-GT is not traditional OSPF, and it’s not used to calculate
> routes. It uses the reachability info calculated by routing protocols,
> OSPF, ISIS or static routing etc.. It provides mechanisms to advertise
> non-routing information, and remote neighbor is supported.
>
>
>
> Reviews and comments are welcome.
>
>
>
>
>
> Thanks,
>
> Yingzhen
>
>
>
> On Jul 9, 2022, at 5:33 PM, Gy

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

[Robert Raszuk]

Hi Yingzhen & OSPF-GT authors,

UP front I must state that anything is better to export IGP information
from routers to interested nodes than using BGP for it.

But to propose using OSPF to transport ISIS seems pretty brave :) I must
admit it !

With that I have few questions to the proposal - assuming the use case is
to distribute links state info in a *point to point* fashion:

A) What is the advantage - if any - to use a new OSPF instance/process to
send link state data over a unicast session to a controller ?

B) The draft is pretty silent on the nature of such a p2p session. Please
be explicit if this is TCP, QUIC or what ?

C) The draft is pretty silent on types of authentication for such sessions.
Security considerations are pretty weak in that respect as well.

   The security considerations for OSPF-GT will be similar to those for
   OSPFv2 [RFC2328] and OSPFv3 [RFC5340].  However, since OSPF-GT is not
   used to update OSPF routing, the consequences of attacks will be
   dependent on advertised non-routing information.

I would actually argue that security considerations of p2p remote neighbors
are actually quite different from security considerations of flooding data.

Along the same lines security is not about protecting your routing ... it
is much more about protecting the entire network by exposing critical
information externally to non authorized parties.

D) Are there any PUB-SUB options possible for OSPF-GT ?

E) Is there any filtering possible for OSPF-GT ?

F) Are you envisioning use of OSPF-GT proxies and if so are you planning to
add this to the document ?

G) How are you going to address Receivers which do not support OSPF-GT
parser ?

H) As you know many operators are attracted to BGP-LS based on the fact
that it offers the same view of information irrespective of what is the
protocol producing the data. Is there some thought on such normalization in
the OSPF-GT proposal ?

I) What's the take of OSPF-GT draft authors on the YANG model in respect of
using it for normalization of exported data ?

To summarize IMHO we should not stretch routing protocols be it OSPF, ISIS
or BGP to be messengers of link state data running and to artificially
force them to run in a point-to-point model between router and controller.

Kind regards,
Robert


On Sun, Jul 10, 2022 at 7:04 AM Yingzhen Qu  wrote:

> Hi,
>
> Since we’re discussing possible solutions, I’d like to bring up the draft:
> https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-transport-instance/
>
> We just submitted a new version. The name of the document is changed to
> “OSPF-GT (Generalized Transport)”, and a use case is added to use OSPF-GT
> as a possible replacement of BGP-LS.
>
> Note: OSPF-GT is not traditional OSPF, and it’s not used to calculate
> routes. It uses the reachability info calculated by routing protocols,
> OSPF, ISIS or static routing etc.. It provides mechanisms to advertise
> non-routing information, and remote neighbor is supported.
>
> Reviews and comments are welcome.
>
>
> Thanks,
> Yingzhen
>
> On Jul 9, 2022, at 5:33 PM, Gyan Mishra  wrote:
>
>
> During the interim meeting we should keep it open to discuss all possible
> alternatives to BGP-LS.
>
> Thanks
>
> Gyan
>
> On Sat, Jul 9, 2022 at 4:45 PM Susan Hares  wrote:
>
>> Jeff:
>>
>>
>>
>> An interim sounds like a good plan.
>>
>>
>>
>> [IDR-chair hat]
>>
>> Alvaro has indicated that since all of the proposal received on the IDR
>> list are new protocol proposals,
>>
>>- Capturing IDR’s input on BGP-LS problems and potential solutions is
>>appropriate for IDR as BGP-LS home.
>>- Refining any potential non-BGP solutions is outside of the scope of
>>IDR.
>>
>>
>>
>> [IDR-chair hat off]
>>
>> [rtgwg WG member]
>>
>> I’d love to attend an interim on this topic.
>>
>>
>>
>> Sue Hares
>>
>>
>>
>>
>>
>> *From:* Jeff Tantsura 
>> *Sent:* Saturday, July 9, 2022 3:40 PM
>> *To:* Robert Raszuk 
>> *Cc:* Acee Lindem (acee) ; lsr ;
>> i...@ietf.org; Susan Hares ; g...@ietf.org g...@ietf.org
>> 
>> *Subject:* Re: [Idr] [Lsr] IGP Monitoring Protocol
>>
>>
>>
>>
>>
>> Speaking as RTGWG chair:
>>
>>
>>
>> Robert - I don’t think we’d have enough time to accommodate a good
>> discussion during IETF114 (we got only 1 slot), however would be happy to
>> provide a platform for an interim.
>>
>> The topic is important and personally (being a very large BGP-LS user)
>> I’d like to see it progressing.
>>
>> Cheers,
>>
>> Jeff
>>
>>
>>
>> On Jul 8, 2022, at 14:44, Robert Raszuk  wrote:

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

[Robert Raszuk]

ns at the DATA
Types. That IMO is an IMP property. I agree that what specific elements are
sent can be done with the NETCONF/RESTCONF mechanism.

For now I refrained from adding this to the spec. Only added top level TLV
filters.

Said this I am very open to follow your above recommendation for YANG DATA
Types and need for more granular subscriptions. But I think I would rather
see this applicable to Producer's Proxies not Producers directly. Just
trying to keep Producers as light as possible as not all RP/RE can handle
too much of such load.


> Regarding the terminology of "Producer" and "Receiver". I suggest to align
> the wording with existing Network Telemetry (RFC 9232) protocols.
> Unfortunately they aren't aligned among at all even though they are doing
> more or less all the same. Exporting monitoring data to a data collection.
> My personal favorite is Exporting and Collecting Process.
>
>
>
> IPFIX:   Exporting Process, Collecting Process
>
> BMP: Management Station, Monitoring Station
>
> YANG push:   Publisher, Receiver
>
> IMP:  Producer, Receiver
>

I used the Producer term as this is how some implementations call its
components. The receivers are Clients.

But if we think that "Publisher" term is a better fit I have no issue
renaming it such. Receiver could stay as is or could be called Client too.

Many thx and thank you again for your review and excellent comments.

Robert



>
>
> Best wishes
>
> Thomas
>
>
>
> *From:* GROW  *On Behalf Of *Robert Raszuk
> *Sent:* Saturday, July 9, 2022 9:49 PM
> *To:* Jeff Tantsura 
> *Cc:* lsr ; g...@ietf.org g...@ietf.org ;
> idr@ietf. org 
> *Subject:* Re: [GROW] [Idr] [Lsr] IGP Monitoring Protocol
>
>
>
> Thx Jeff !
>
>
>
> Also I welcome more reviews and suggestions for additions or deletions of
> parts of it. For now I tried to keep it very simple for routers -
> essentially setup new p2p TCP or QUIC sessions and send over exactly what
> you put in BGP today. In the same time I see use cases beyond that so added
> few optional more DATA Types.
>
>
>
> With basic DATA Types 1 or 2 there is zero changes needed on the receivers
> - some folks told me this is huge advantage.
>
>
>
> Then two optional messages REQUEST and FILTER provide ability for trimming
> excessive data either on the Producer or Producer's Proxy.
>
>
>
> Many thx,
>
> Robert
>
>
>
>
>
> On Sat, Jul 9, 2022 at 9:39 PM Jeff Tantsura 
> wrote:
>
> Speaking as RTGWG chair:
>
>
>
> Robert - I don’t think we’d have enough time to accommodate a good
> discussion during IETF114 (we got only 1 slot), however would be happy to
> provide a platform for an interim.
>
> The topic is important and personally (being a very large BGP-LS user) I’d
> like to see it progressing.
>
> Cheers,
>
> Jeff
>
>
>
> On Jul 8, 2022, at 14:44, Robert Raszuk  wrote:
>
> 
>
> Hi Acee,
>
>
>
> Yes, by all means input from the operator's community is needed. It can be
> collected through LSR WG, IDR WG or GROW WG. RTGWG could also contribute.
> We have already seen input from some operators and their opinion on adding
> and distributing more and more link state protocol and topology data in
> BGP. More such input is very welcome.
>
>
>
> And to your point about RFC9086 - I see nothing wrong in keeping BGP
> information in BGP. So IGP Monitoring Protocol does not target to shut down
> BGP-LS. It only aims to remove 100% of non BGP sourced information from it.
>
>
>
> Controllers which today listen to BGP-LS need a number of information
> sources and that spread will only keep increasing as more inputs are
> becoming necessary for its computations.
>
>
>
> Regards,
>
> Robert.
>
>
>
>
>
> On Fri, Jul 8, 2022 at 11:32 PM Acee Lindem (acee)  wrote:
>
> Hi Robert,
>
>
>
> *From: *Robert Raszuk 
> *Date: *Friday, July 8, 2022 at 4:36 PM
> *To: *Acee Lindem 
> *Cc: *lsr , IDR List , Susan Hares <
> sha...@ndzh.com>
> *Subject: *Re: [Lsr] IGP Monitoring Protocol
>
>
>
> Hi Acee,
>
>
>
> Thank you. I was not planning to present it in the upcoming IETF.
>
>
>
> > Let’s see how many stakeholders actually want to this protocol - then we
> can talk about a WG home.
>
>
>
> An alternative approach could be to see how many stakeholders do not want
> to further (for no good reason) to trash BGP. That to me would be in this
> specific case a much better gauge.
>
>
>
> In that case, it seems to me that this discussion should be relegated to
> IDR. Note that there is already non-IGP informatio

Re: [Lsr] [Idr] IGP Monitoring Protocol

[Robert Raszuk]

Thx Jeff !

Also I welcome more reviews and suggestions for additions or deletions of
parts of it. For now I tried to keep it very simple for routers -
essentially setup new p2p TCP or QUIC sessions and send over exactly what
you put in BGP today. In the same time I see use cases beyond that so added
few optional more DATA Types.

With basic DATA Types 1 or 2 there is zero changes needed on the receivers
- some folks told me this is huge advantage.

Then two optional messages REQUEST and FILTER provide ability for trimming
excessive data either on the Producer or Producer's Proxy.

Many thx,
Robert


On Sat, Jul 9, 2022 at 9:39 PM Jeff Tantsura 
wrote:

> Speaking as RTGWG chair:
>
> Robert - I don’t think we’d have enough time to accommodate a good
> discussion during IETF114 (we got only 1 slot), however would be happy to
> provide a platform for an interim.
> The topic is important and personally (being a very large BGP-LS user) I’d
> like to see it progressing.
>
> Cheers,
> Jeff
>
> On Jul 8, 2022, at 14:44, Robert Raszuk  wrote:
>
> 
> Hi Acee,
>
> Yes, by all means input from the operator's community is needed. It can be
> collected through LSR WG, IDR WG or GROW WG. RTGWG could also contribute.
> We have already seen input from some operators and their opinion on adding
> and distributing more and more link state protocol and topology data in
> BGP. More such input is very welcome.
>
> And to your point about RFC9086 - I see nothing wrong in keeping BGP
> information in BGP. So IGP Monitoring Protocol does not target to shut down
> BGP-LS. It only aims to remove 100% of non BGP sourced information from it.
>
> Controllers which today listen to BGP-LS need a number of information
> sources and that spread will only keep increasing as more inputs are
> becoming necessary for its computations.
>
> Regards,
> Robert.
>
>
> On Fri, Jul 8, 2022 at 11:32 PM Acee Lindem (acee)  wrote:
>
>> Hi Robert,
>>
>>
>>
>> *From: *Robert Raszuk 
>> *Date: *Friday, July 8, 2022 at 4:36 PM
>> *To: *Acee Lindem 
>> *Cc: *lsr , IDR List , Susan Hares <
>> sha...@ndzh.com>
>> *Subject: *Re: [Lsr] IGP Monitoring Protocol
>>
>>
>>
>> Hi Acee,
>>
>>
>>
>> Thank you. I was not planning to present it in the upcoming IETF.
>>
>>
>>
>> > Let’s see how many stakeholders actually want to this protocol - then
>> we can talk about a WG home.
>>
>>
>>
>> An alternative approach could be to see how many stakeholders do not want
>> to further (for no good reason) to trash BGP. That to me would be in this
>> specific case a much better gauge.
>>
>>
>>
>> In that case, it seems to me that this discussion should be relegated to
>> IDR. Note that there is already non-IGP information transported in BGP-LS,
>> e.g., Egress Peer Engineering (https://datatracker.ietf.org/doc/rfc9086/).
>> I implemented this on our data center routers (NXOS) years and it is solely
>> BGP specific.
>>
>>
>>
>> Thanks,
>>
>> Acee
>>
>>
>>
>> Kind regards,
>>
>> Robert
>>
>>
>>
>>
>>
>> On Fri, Jul 8, 2022 at 9:54 PM Acee Lindem (acee)  wrote:
>>
>> Speaking as WG chair:
>>
>>
>>
>> *From: *Lsr  on behalf of Robert Raszuk <
>> rob...@raszuk.net>
>> *Date: *Friday, July 8, 2022 at 3:21 PM
>> *To: *lsr 
>> *Cc: *IDR List , Susan Hares 
>> *Subject: *[Lsr] IGP Monitoring Protocol
>>
>>
>>
>> Dear LSR WG,
>>
>>
>>
>> Based on ongoing discussion in respect to the future of BGP-LS I
>> committed myself to put together an alternate proposal.
>>
>>
>>
>> The main goal is not to just publish a -00 version of the draft using
>> different encapsulation. The goal is to make a useful tool which can help
>> to export link state information from network elements as well as assist in
>> network observability.
>>
>>
>>
>> The IGP Monitoring Protocol (IMP) draft has been posted and should be
>> available at:
>>
>>
>>
>> https://datatracker.ietf.org/doc/draft-raszuk-lsr-imp/
>>
>>
>>
>> One of the key points I wanted to accomplish was full backwards
>> compatibility with TLVs defined for BGP-LS. In parallel other formats
>> (optional) are also supported.
>>
>>
>>
>> The PUB-SUB nature or FILTERING capabilities are in the spec however as
>> noted in the deployment section there is no expectation that this should be
>> supported directly on routers. Conce

Re: [Lsr] IGP Monitoring Protocol

[Robert Raszuk]

Hi Acee,

Yes, by all means input from the operator's community is needed. It can be
collected through LSR WG, IDR WG or GROW WG. RTGWG could also contribute.
We have already seen input from some operators and their opinion on adding
and distributing more and more link state protocol and topology data in
BGP. More such input is very welcome.

And to your point about RFC9086 - I see nothing wrong in keeping BGP
information in BGP. So IGP Monitoring Protocol does not target to shut down
BGP-LS. It only aims to remove 100% of non BGP sourced information from it.

Controllers which today listen to BGP-LS need a number of information
sources and that spread will only keep increasing as more inputs are
becoming necessary for its computations.

Regards,
Robert.


On Fri, Jul 8, 2022 at 11:32 PM Acee Lindem (acee)  wrote:

> Hi Robert,
>
>
>
> *From: *Robert Raszuk 
> *Date: *Friday, July 8, 2022 at 4:36 PM
> *To: *Acee Lindem 
> *Cc: *lsr , IDR List , Susan Hares <
> sha...@ndzh.com>
> *Subject: *Re: [Lsr] IGP Monitoring Protocol
>
>
>
> Hi Acee,
>
>
>
> Thank you. I was not planning to present it in the upcoming IETF.
>
>
>
> > Let’s see how many stakeholders actually want to this protocol - then we
> can talk about a WG home.
>
>
>
> An alternative approach could be to see how many stakeholders do not want
> to further (for no good reason) to trash BGP. That to me would be in this
> specific case a much better gauge.
>
>
>
> In that case, it seems to me that this discussion should be relegated to
> IDR. Note that there is already non-IGP information transported in BGP-LS,
> e.g., Egress Peer Engineering (https://datatracker.ietf.org/doc/rfc9086/).
> I implemented this on our data center routers (NXOS) years and it is solely
> BGP specific.
>
>
>
> Thanks,
>
> Acee
>
>
>
> Kind regards,
>
> Robert
>
>
>
>
>
> On Fri, Jul 8, 2022 at 9:54 PM Acee Lindem (acee)  wrote:
>
> Speaking as WG chair:
>
>
>
> *From: *Lsr  on behalf of Robert Raszuk <
> rob...@raszuk.net>
> *Date: *Friday, July 8, 2022 at 3:21 PM
> *To: *lsr 
> *Cc: *IDR List , Susan Hares 
> *Subject: *[Lsr] IGP Monitoring Protocol
>
>
>
> Dear LSR WG,
>
>
>
> Based on ongoing discussion in respect to the future of BGP-LS I
> committed myself to put together an alternate proposal.
>
>
>
> The main goal is not to just publish a -00 version of the draft using
> different encapsulation. The goal is to make a useful tool which can help
> to export link state information from network elements as well as assist in
> network observability.
>
>
>
> The IGP Monitoring Protocol (IMP) draft has been posted and should be
> available at:
>
>
>
> https://datatracker.ietf.org/doc/draft-raszuk-lsr-imp/
>
>
>
> One of the key points I wanted to accomplish was full backwards
> compatibility with TLVs defined for BGP-LS. In parallel other formats
> (optional) are also supported.
>
>
>
> The PUB-SUB nature or FILTERING capabilities are in the spec however as
> noted in the deployment section there is no expectation that this should be
> supported directly on routers. Concept of Producer's Proxies has been
> introduced to support this added functionality as well as provide fan-out
> (analogy to BGP route reflectors).
>
>
>
> I encourage everyone interested to take a look and provide comments. At
> this point this document is nothing more than my individual submission.
> Offline I have had few conversations with both operators and vendors
> expressing some level of interest in this work. How we proceed further (if
> at all :) depends on WG feedback.
>
>
>
> Kind regards,
>
> Robert.
>
>
>
> PS, I do believe this work belongs in LSR WG pretty squerly.
>
>
>
> Let’s see how many stakeholders actually want to this protocol - then we
> can talk about a WG home.  By stakeholders, I mean operators and vendors
> who are committed to implementing and deploying it - not simply those who
> you are able to enlist as co-authors. Note that our IETF 114 LSR agenda is
> full (with multiple agenda items not making the cut).
>
>
>
> Thanks,
>
> Acee
>
>
>
>
>
>
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] IGP Monitoring Protocol

[Robert Raszuk]

Hi Acee,

Thank you. I was not planning to present it in the upcoming IETF.

> Let’s see how many stakeholders actually want to this protocol - then we
can talk about a WG home.

An alternative approach could be to see how many stakeholders do not want
to further (for no good reason) to trash BGP. That to me would be in this
specific case a much better gauge.

Kind regards,
Robert


On Fri, Jul 8, 2022 at 9:54 PM Acee Lindem (acee)  wrote:

> Speaking as WG chair:
>
>
>
> *From: *Lsr  on behalf of Robert Raszuk <
> rob...@raszuk.net>
> *Date: *Friday, July 8, 2022 at 3:21 PM
> *To: *lsr 
> *Cc: *IDR List , Susan Hares 
> *Subject: *[Lsr] IGP Monitoring Protocol
>
>
>
> Dear LSR WG,
>
>
>
> Based on ongoing discussion in respect to the future of BGP-LS I
> committed myself to put together an alternate proposal.
>
>
>
> The main goal is not to just publish a -00 version of the draft using
> different encapsulation. The goal is to make a useful tool which can help
> to export link state information from network elements as well as assist in
> network observability.
>
>
>
> The IGP Monitoring Protocol (IMP) draft has been posted and should be
> available at:
>
>
>
> https://datatracker.ietf.org/doc/draft-raszuk-lsr-imp/
>
>
>
> One of the key points I wanted to accomplish was full backwards
> compatibility with TLVs defined for BGP-LS. In parallel other formats
> (optional) are also supported.
>
>
>
> The PUB-SUB nature or FILTERING capabilities are in the spec however as
> noted in the deployment section there is no expectation that this should be
> supported directly on routers. Concept of Producer's Proxies has been
> introduced to support this added functionality as well as provide fan-out
> (analogy to BGP route reflectors).
>
>
>
> I encourage everyone interested to take a look and provide comments. At
> this point this document is nothing more than my individual submission.
> Offline I have had few conversations with both operators and vendors
> expressing some level of interest in this work. How we proceed further (if
> at all :) depends on WG feedback.
>
>
>
> Kind regards,
>
> Robert.
>
>
>
> PS, I do believe this work belongs in LSR WG pretty squerly.
>
>
>
> Let’s see how many stakeholders actually want to this protocol - then we
> can talk about a WG home.  By stakeholders, I mean operators and vendors
> who are committed to implementing and deploying it - not simply those who
> you are able to enlist as co-authors. Note that our IETF 114 LSR agenda is
> full (with multiple agenda items not making the cut).
>
>
>
> Thanks,
>
> Acee
>
>
>
>
>
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] IGP Monitoring Protocol

[Robert Raszuk]

Dear LSR WG,

Based on ongoing discussion in respect to the future of BGP-LS I
committed myself to put together an alternate proposal.

The main goal is not to just publish a -00 version of the draft using
different encapsulation. The goal is to make a useful tool which can help
to export link state information from network elements as well as assist in
network observability.

The IGP Monitoring Protocol (IMP) draft has been posted and should be
available at:

https://datatracker.ietf.org/doc/draft-raszuk-lsr-imp/

One of the key points I wanted to accomplish was full backwards
compatibility with TLVs defined for BGP-LS. In parallel other formats
(optional) are also supported.

The PUB-SUB nature or FILTERING capabilities are in the spec however as
noted in the deployment section there is no expectation that this should be
supported directly on routers. Concept of Producer's Proxies has been
introduced to support this added functionality as well as provide fan-out
(analogy to BGP route reflectors).

I encourage everyone interested to take a look and provide comments. At
this point this document is nothing more than my individual submission.
Offline I have had few conversations with both operators and vendors
expressing some level of interest in this work. How we proceed further (if
at all :) depends on WG feedback.

Kind regards,
Robert.

PS, I do believe this work belongs in LSR WG pretty squerly.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr