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
Thanks Peter.
-- Bruno
Orange Restricted
> -Original Message-
> From: Peter Psenak
> Sent: Sunday, July 30, 2023 8:04 PM
>
> Hi Bruno,
>
> I will update the draft.
>
> thanks,
> Peter
>
> On 28/07/2023 14:32, bruno.decra...@orange.com wrote:
> > Peter,
> >
> >> From: Peter Psenak
>
Hi Bruno,
I will update the draft.
thanks,
Peter
On 28/07/2023 14:32, bruno.decra...@orange.com wrote:
Peter,
From: Peter Psenak
Sent: Thursday, July 27, 2023 8:00 PM
Bruno,
On 27/07/2023 16:12, bruno.decra...@orange.com wrote:
Bottom line:
- we see that this can be problematic in
Peter,
> From: Peter Psenak
> Sent: Thursday, July 27, 2023 8:00 PM
>
> Bruno,
>
> On 27/07/2023 16:12, bruno.decra...@orange.com wrote:
>
> >
> > Bottom line:
> > - we see that this can be problematic in some cases
> > - it's very easy to fix by mandating the use of the flags(s).
>
> I
Bruno,
On 27/07/2023 16:12, bruno.decra...@orange.com wrote:
Bottom line:
- we see that this can be problematic in some cases
- it's very easy to fix by mandating the use of the flags(s).
I believe we understand each other. I even believe we are in a violent
agreement, although we have
27, 2023 at 9:31 AM wrote:
> Hi Gyan,
>
>
>
> Please see inline.
>
>
>
>
>
> *From:* Gyan Mishra
> *Sent:* Thursday, July 27, 2023 6:38 AM
> *To:* DECRAENE Bruno INNOV/NET
> *Cc:* Peter Psenak ; lsr
> *Subject:* Re: [Lsr] draft-ppsenak-lsr-igp-ureach
Peter,
Please see inline (##Bruno2)
> From: Peter Psenak
>
> Bruno,
>
> please see inline (##PP2):
disclaimer: to ease further reading I took the liberty to edit some #PP into
#PP2
(if I made some errors, they were not intentional)
>
> On 26/07/2023 23:34, bruno.decra...@orange.com
Hi Gyan,
Please see inline.
From: Gyan Mishra
Sent: Thursday, July 27, 2023 6:38 AM
To: DECRAENE Bruno INNOV/NET
Cc: Peter Psenak ; lsr
Subject: Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce
Hi Bruno
Can you give an example of an application or scenario where you are forwarding
Understood. Thanks for clarification.
Thanks
Gyan
On Thu, Jul 27, 2023 at 2:14 AM Robert Raszuk wrote:
> > 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
> 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
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
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
Bruno,
please see inline (##PP2):
On 26/07/2023 23:34, bruno.decra...@orange.com wrote:
Peter,
From: Peter Psenak
Sent: Wednesday, July 26, 2023 11:26 PM
Bruno,
please see inline (##PP):
On 26/07/2023 22:46, bruno.decra...@orange.com wrote:
Peter,
Please see inline
From: Peter
Peter,
> From: Peter Psenak
> Sent: Wednesday, July 26, 2023 11:26 PM
>
> Bruno,
>
> please see inline (##PP):
>
> On 26/07/2023 22:46, bruno.decra...@orange.com wrote:
> > Peter,
> >
> > Please see inline
> >
> >> From: Peter Psenak
> >>
> >> Bruno,
> >>
> >> please see inline:
> >>
Bruno,
please see inline (##PP):
On 26/07/2023 22:46, bruno.decra...@orange.com wrote:
Peter,
Please see inline
From: Peter Psenak
Bruno,
please see inline:
On 25/07/2023 21:11, bruno.decra...@orange.com wrote:
Peter,
Please see inline
From: Peter Psenak
Sent: Tuesday, July
Peter,
Please see inline
> From: Peter Psenak
>
> Bruno,
>
> please see inline:
>
> On 25/07/2023 21:11, bruno.decra...@orange.com wrote:
> > Peter,
> >
> > Please see inline
> >
> >> From: Peter Psenak
> >> Sent: Tuesday, July 25, 2023 6:49 PM
> >>
> >> Bruno,
> >>
> >> please see
Hi Peter,
Please see inline.
> From: Peter Psenak
> Sent: Wednesday, July 26, 2023 5:41 PM
>
> 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,
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
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
>
Bruno,
please see inline:
On 25/07/2023 21:11, bruno.decra...@orange.com wrote:
Peter,
Please see inline
From: Peter Psenak
Sent: Tuesday, July 25, 2023 6:49 PM
Bruno,
please see inline:
On 25/07/2023 18:36, bruno.decra...@orange.com wrote:
Peter,
Thanks for your answer.
Please see
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
Peter,
> From: Peter Psenak
> Sent: Tuesday, July 25, 2023 7:38 PM
> To: Robert Raszuk
>
> 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
Thanks Robert, you got my point.
More inline.
From: Robert Raszuk
Sent: Tuesday, July 25, 2023 7:51 PM
To: Peter Psenak
Cc: DECRAENE Bruno INNOV/NET ; lsr
Subject: Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce
Hi,
> So we have a way to achieve consistency if it is ever needed.
W
Peter,
Please see inline
> From: Peter Psenak
> Sent: Tuesday, July 25, 2023 6:49 PM
>
> Bruno,
>
> please see inline:
>
> On 25/07/2023 18:36, bruno.decra...@orange.com wrote:
> > Peter,
> >
> > Thanks for your answer.
> > Please see inline [Bruno]
> >
> >
> >> From: Peter Psenak
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
> >
Robert,
On 25/07/2023 19:50, Robert Raszuk wrote:
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
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
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
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
Bruno,
please see inline:
On 25/07/2023 18:36, bruno.decra...@orange.com wrote:
Peter,
Thanks for your answer.
Please see inline [Bruno]
From: Peter Psenak
Sent: Tuesday, July 25, 2023 6:05 PM
Bruno,
On 25/07/2023 14:39, bruno.decra...@orange.com wrote:
Hi all,
With RC5305, in
Peter,
Thanks for your answer.
Please see inline [Bruno]
> From: Peter Psenak
> Sent: Tuesday, July 25, 2023 6:05 PM
>
> Bruno,
>
> On 25/07/2023 14:39, bruno.decra...@orange.com wrote:
> > Hi all,
> >
> > With RC5305, in IS-IS we can advertise two states for a prefix IP1:
> >
> > *
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
Bruno,
On 25/07/2023 14:39, bruno.decra...@orange.com wrote:
Hi all,
With RC5305, in IS-IS we can advertise two states for a prefix IP1:
* Positive reachability (state “1”), by advertising IP1 in TLV 135
with a metric lower than 0xFE00
* No reachability (state “0”) by either:
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.
Hi all,
With RC5305, in IS-IS we can advertise two states for a prefix IP1:
* Positive reachability (state "1"), by advertising IP1 in TLV 135 with a
metric lower than 0xFE00
* No reachability (state "0") by either:
* Not advertising IP1 in TLV 135
* Advertising IP1
Robert,
On 27/03/2023 17:18, Robert Raszuk wrote:
> 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
> 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
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
>
> 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
Hi Bruno,
On 27/03/2023 06:59, bruno.decra...@orange.com wrote:
Hi authors,
Please find below some questions.
1. Assuming ABR1 advertises IP1 with metric 10 while ABR2 advertises
IP1 with MAX metric. Is this prefix reachable or unreachable (or both)?
UPA is meant to be sent only for
Hi authors,
Please find below some questions.
1. Assuming ABR1 advertises IP1 with metric 10 while ABR2 advertises IP1
with MAX metric. Is this prefix reachable or unreachable (or both)?
2. Assuming ABR1 advertises a summary address but ABR2 does not. If ABR2
advertises IP1 with MAX
"Les Ginsberg (ginsberg)" writes:
Chris/David -
I was replying to Peter saying that implementations are using the max metric
announcements to avoid sending traffic to overload routers.
[LES:] Are you claiming this because you know this to be true - or are you just
speculating that an
Chris/David -
>
> I was replying to Peter saying that implementations are using the max metric
> announcements to avoid sending traffic to overload routers.
[LES:] Are you claiming this because you know this to be true - or are you just
speculating that an implementation "might" do this?
If
On 12/11/2022 06:45, Christian Hopps wrote:
On Nov 9, 2022, at 2:13 PM, Peter Psenak
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
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
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
Hi, Robert:
> "other than building the normal IP routing table"
There may be different purposes, so advertise the “unreachable within the
summary address” should be signed explicitly.
Aijun Wang
China Telecom
> On Nov 12, 2022, at 11:59, Robert Raszuk wrote:
>
>
> Chris,
>
> >
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
> On Nov 9, 2022, at 2:13 PM, Peter Psenak
> 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
>
>
> > 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.
>
On 10/11/2022 11:59, Acee Lindem (acee) wrote:
Hi Robert,
*From: *Robert Raszuk
*Date: *Thursday, November 10, 2022 at 10:51 AM
*To: *Acee Lindem
*Cc: *Peter Psenak , Bruno Decraene
, David Lamparter ,
"lsr@ietf.org"
*Subject: *Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-anno
Hi Robert,
From: Robert Raszuk
Date: Thursday, November 10, 2022 at 10:51 AM
To: Acee Lindem
Cc: Peter Psenak , Bruno Decraene
, David Lamparter ,
"lsr@ietf.org"
Subject: Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS
semantics
> But BGP service PIC is
Hi, Peter:
I suggest that you consider such problems and the solutions from the broader
viewpoint, not just the behavior of one single device, or only from the vendor
side.
To deploy the mechanism into the network, the operator must assure it will not
conflict with other possible usages, and
, 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 none
Hi Robert,
From: Robert Raszuk
Date: Thursday, November 10, 2022 at 9:41 AM
To: Peter Psenak
Cc: Bruno Decraene , David Lamparter
, Acee Lindem , "lsr@ietf.org"
Subject: Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS
semantics
Peter,
> But:
> - tha
On 09/11/2022 22:51, 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
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
Bruno,
On 10/11/2022 02:18, bruno.decra...@orange.com wrote:
Peter,
From: Peter Psenak
Sent: Wednesday, November 9, 2022 2:13 PM
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
Peter,
> From: Peter Psenak
> Sent: Wednesday, November 9, 2022 2:13 PM
>
> 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
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
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
On 09/11/2022 16:32, David Lamparter wrote:
On Wed, Nov 09, 2022 at 03:16:11PM +, Peter Psenak wrote:
On 09/11/2022 15:48, David Lamparter wrote:
On Wed, Nov 09, 2022 at 02:32:35PM +, Peter Psenak wrote:
as far as that /128 is not used as BGP next-hop (which obviously is not
the
On Wed, Nov 09, 2022 at 03:16:11PM +, Peter Psenak wrote:
> On 09/11/2022 15:48, David Lamparter wrote:
> > On Wed, Nov 09, 2022 at 02:32:35PM +, Peter Psenak wrote:
> >> as far as that /128 is not used as BGP next-hop (which obviously is not
> >> the case),
> >
> > You keep saying things
On 09/11/2022 15:48, David Lamparter wrote:
On Wed, Nov 09, 2022 at 02:32:35PM +, Peter Psenak wrote:
On 09/11/2022 15:26, David Lamparter wrote:
On Wed, Nov 09, 2022 at 02:13:17PM +, Peter Psenak wrote:
and why that would be a problem? Such prefix would never be used to for
On Wed, Nov 09, 2022 at 02:32:35PM +, Peter Psenak wrote:
> On 09/11/2022 15:26, David Lamparter wrote:
> > On Wed, Nov 09, 2022 at 02:13:17PM +, Peter Psenak wrote:
> >> and why that would be a problem? Such prefix would never be used to for
> >> resolution of the BGP prefix.
> >
> >
On 09/11/2022 15:26, David Lamparter wrote:
On Wed, Nov 09, 2022 at 02:13:17PM +, Peter Psenak wrote:
On 09/11/2022 14:56, David Lamparter wrote:
On Wed, Nov 09, 2022 at 01:27:41PM +, Acee Lindem (acee) wrote:
The problem is that a prefix with metric > 0xfe00 isn't actually an
On Wed, Nov 09, 2022 at 02:13:17PM +, Peter Psenak wrote:
> On 09/11/2022 14:56, David Lamparter wrote:
> > On Wed, Nov 09, 2022 at 01:27:41PM +, Acee Lindem (acee) wrote:
> > The problem is that a prefix with metric > 0xfe00 isn't actually an
> > unreachable prefix, it's a prefix that
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
Aijun,
On 09/11/2022 13:21, Aijun Wang wrote:
Hi, Peter:
I think you over explain the meaning of “LSInfinity”. I concur with David:
A less specific prefix may cover it
Then, you conclusion that:
when a prefix is "not considered during the normal Shortest Path First (SPF)
computation",
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
One more information:
The explicit solution,
https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-10
does not require all the nodes be upgraded simultaneously.
Aijun Wang
China Telecom
> On Nov 9, 2022, at 12:06, Peter Psenak
> Using a new Sub-TLV to signal
Speaking as WG Participant:
Hi Bruno, David,
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
Hi, Peter:
I think you over explain the meaning of “LSInfinity”. I concur with David:
>> A less specific prefix may cover it
Then, you conclusion that:
> when a prefix is "not considered during the normal Shortest Path First (SPF)
> computation", the result will be that the prefix will become
Hi David,
On 09/11/2022 11:44, David Lamparter wrote:
Hi Peter, hi all,
to iterate on the comment I made on the mic a few minutes ago, I
apparently have a rather different understanding of existing IS-IS
behaviour. Reading 5305/5308,
... "if a prefix is advertised with a
On Wed, Nov 09, 2022 at 10:55:38AM +, bruno.decra...@orange.com wrote:
> > From: Lsr On Behalf Of David Lamparter
> > I'd rather not do that and just add
> > a sub-TLV for it.
>
> I'm fine to use max_prefix as per RFC 5305 (prefix not considered
> during SPF) as this allow for incremental
> From: Lsr On Behalf Of David Lamparter
> Sent: Wednesday, November 9, 2022 10:45 AM
> Hi Peter, hi all,
>
>
> to iterate on the comment I made on the mic a few minutes ago, I
> apparently have a rather different understanding of existing IS-IS
> behaviour. Reading 5305/5308,
>
> ...
Hi Peter, hi all,
to iterate on the comment I made on the mic a few minutes ago, I
apparently have a rather different understanding of existing IS-IS
behaviour. Reading 5305/5308,
... "if a prefix is advertised with a metric larger
than MAX_V6_PATH_METRIC (0xFE00),
; lsr@ietf.org
Subject: Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce
Hi Bruno,
thanks for your feedback, please see inline (##PP):
On 15/06/2022 16:09, bruno.decra...@orange.com wrote:
Hi Peter, authors, all
Thanks for the draft. I find it a useful contribution to the problem space
Hi Peter,
Thanks for your reply. Please see inline [Bruno2]
Orange Restricted
> -Original Message-
> From: Peter Psenak
> Sent: Thursday, June 16, 2022 11:22 AM
> To: DECRAENE Bruno INNOV/NET ; lsr@ietf.org
> Subject: Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-a
Bruno,
Actually I like your flag suggestion for an additional and different
reason.
If someone does not need to flood UPAs in any remote area it is trivial to
filter those on the ABRs connecting those areas to the core. Otherwise such
filtering could be more difficult if at all possible.
Thx,
Hi Bruno,
thanks for your feedback, please see inline (##PP):
On 15/06/2022 16:09, bruno.decra...@orange.com wrote:
Hi Peter, authors, all
Thanks for the draft. I find it a useful contribution to the problem space.
IMHO the use of MAX_PATH_METRIC is a good idea in particular since it
can be
Daniel, inline
Orange Restricted
From: Voyer, Daniel
Sent: Wednesday, June 15, 2022 9:43 PM
To: DECRAENE Bruno INNOV/NET ; lsr@ietf.org
Subject: RE: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce
Bruno, inline
From: Bruno Decraene
mailto:bruno.decra...@orange.com>>
Date: Wednesday
Hi Aijun,
Orange Restricted
From: Aijun Wang
Sent: Thursday, June 16, 2022 1:59 AM
To: DECRAENE Bruno INNOV/NET
Cc: lsr@ietf.org
Subject: Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce
Hi, Bruno:
I agree with your thoughts on the solutions to this questions.
Actually
Hi, Bruno:
I agree with your thoughts on the solutions to this questions.
Actually, this is the reason that we brought up the thread “Convergence of
Prefixes Unreachable Announcement Proposal” and I think you can review the
discussion of this thread again.
And, in the mail
Bruno, inline
From: Bruno Decraene
Date: Wednesday, June 15, 2022 at 12:27 PM
To: Dan Voyer , "lsr@ietf.org"
Subject: [EXT]RE: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce
Hi Daniel,
I agree that the draft-ppsenak-lsr-igp-ureach-prefix-announce, is presented as
“
: DECRAENE Bruno INNOV/NET ; lsr@ietf.org
Subject: RE: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce
Hi Bruno,
Thanks for your comment on the draft. I too, have a minor disagreement on your
disagreement.
The draft-ppsenak-lsr-igp-ureach-prefix-announce, is really presented as "a use
case
: Wednesday, June 15, 2022 at 10:09 AM
To: "lsr@ietf.org"
Subject: [EXT][Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce
Hi Peter, authors, all
Thanks for the draft. I find it a useful contribution to the problem space.
IMHO the use of MAX_PATH_METRIC is a good idea in particular since it ca
Hi Peter, authors, all
Thanks for the draft. I find it a useful contribution to the problem space.
IMHO the use of MAX_PATH_METRIC is a good idea in particular since it can be
made backward compatible and provides incremental benefits with incremental
deployment.
I also have two disagreements
88 matches
Mail list logo
