Support
Thanks
Gyan
On Fri, Aug 18, 2023 at 8:27 PM Christian Hopps wrote:
>
> This begins a 2 week WG Last Call, ending Sep 1, 2023, for:
>
>
> https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-extended-lsa-yang/
>
> Authors,
>
> Please indicate to the list, your knowledge of any IPR
I am not aware of any undisclosed IPRs.
Thanks
Gyan
On Wed, Aug 23, 2023 at 4:02 PM Acee Lindem wrote:
> Co-Authors,
>
> Are you aware of any IPR that applies to
> draft-posenak-lsr-igp-ureach-prefix-announce-04?
> If so, has this IPR been disclosed in compliance with IETF IPR rules (see
>
Hi Yao
Yes there would be a way to tell the virtual instances apart from routing
protocol perspective exactly as you stated could be different router-id and
virtual / sub ports similar to line card case where each line card is a
different virtual routing instance.
Here are the MSD cases
+1 Tony
> On Aug 29, 2023, at 7:18 AM, Tony Li wrote:
>
>
> Hi Eduard,
>
> I know several different products that use different silicon on different
> line cards, ending up with different capabilities on different interfaces.
>
> This is more of a hardware issue than a software one.
>
>
Hi Tony, Hi Les,
Thanks for your thoughts and suggestions.
The per-link RLD will be taken into account regardless of the scope of ERLD-MSD
and the draft will be continuously refined based on the WG's discussion and
conclusion.
Kind Regards,
Yao
Original
From: LesGinsberg(ginsberg)
Speaking as WG member:
I support WG adoption. This draft solves the WG agreed upon problem of
notification of a prefix being unreachable to other applications without
modifying the routing table and with a fully backward compatible mechanism.
There is running vendor code and operators who are
I am in agreement with Tony.
It seems that there are potential use cases for link specific RLD.
As to why RFC 9088 chose to prohibit use of link specific ERLD, the authors of
that RFC are in the best position to answer.
One possible explanation is “simplicity”. This aspect is discussed in
< changing subject so as not to hijack the ongoing WG adoption poll thread >
Hi Aijun,
One only needs to search the LSR WG archives for the discussions, comments
and feedback given on draft-wang-lsr-prefix-unreachable-annoucement by many
participants (including me) over the past many years to
Hi Eduard,
I know several different products that use different silicon on different line
cards, ending up with different capabilities on different interfaces.
This is more of a hardware issue than a software one.
Different chips will necessarily have different low layer micro-code. That
Hi Yao,
IMHO, that was a mistake in the specification of ERLD.
I’m hopeful that we don’t repeat the same mistake.
Tony
> On Aug 29, 2023, at 1:22 AM,
> wrote:
>
> Hi Tony,
>
>
>
> Thanks a lot for your suggestion. This scenario would be taken into
> consideration.
>
> But on the
Hi Robert,
Precise interface information naturally falls out of any path computation done
for traffic engineering.
Regards,
Tony
> On Aug 29, 2023, at 2:31 AM, Robert Raszuk wrote:
>
> Hi Tony,
>
> Unless you are using precise interface based packet steering (which may not
> be a great
Object its adoption.
This document does not solves area/domain partition, but this is a very common
scenario.
From the perspective of comprehensiveness and maturity, I think
https://datatracker.ietf.org/doc/ Draft-wang-lsr-prefix-unreachable-annoucement
is a better choice.
Thanks,
Guoqi Xu
For the record, -04 published last week adequately addresses my comments.
-- Bruno
Orange Restricted
-Original Message-
From: DECRAENE Bruno INNOV/NET
Sent: Monday, July 31, 2023 11:12 AM
To: Peter Psenak
Cc: lsr
Subject: RE: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce
Thanks
Object its adoption.
https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/
(PUA) covering all use cases and scenarios in this document, the PUA describes
additional more useful use cases and scenarios, including:
1. PUA solves area/domain partition, which is necessary
Object its adoption.
https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/
(PUA) covering all use cases and scenarios in this document, the PUA describes
additional more useful use cases and scenarios, including:
1. PUA solves area/domain partition, which is necessary
Robert,
On 29/08/2023 02:54, Robert Raszuk wrote:
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.
I'm not saying you should flood MSD domain
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,
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
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
Hi Gyan,
If I understand you right, in the virtualization scenario, eventually there
would be some way to tell virtual routing instances apart from the routing
protocol's perspective, either they can be treated as different routers with
different router ID (taking OSPF as an example), or
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:
Support from my side as well! I think it’s essential for a large-scale
operator’s network when using SRv6.
Best regards, Martin
Von: Lsr im Auftrag von Gyan Mishra
Datum: Dienstag, 29. August 2023 um 01:27
An: Acee Lindem
Cc: draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org
, lsr
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
Hi Tony,
Thanks a lot for your suggestion. This scenario would be taken into
consideration.
But on the other hand, what I haven't understood is that why ERLD-MSD is
limited to per-node scope considering that each line card may have different
capabilities to read through the label stack.
Hi, Ketan:Which part in https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/ is not workable?I want to remind you again that it is the above draft initiates the problem first, insists that the explicit signaling was the direction, covers more scenarios that draft-ppsenak
Hi Tony,
Do you know any product that supports different label (or SID) stacks on
different PFEs? (Not mandatory to disclose the vendor)
I remember many major upgrades for many vendors and all the time the whole
router supported the “common denominator”.
Of course, it is possible to develop code
26 matches
Mail list logo
