Hi,
Besides, we will add texts in the security considerations section to state the
issues Acee and Peter pointed out and recommend authentication to be used.
We appreciate more comments and suggestions.
Best Regards,
Zhenqiang Li
China Mobile
li_zhenqi...@hotmail.com
发件人： linchangwang
发送时间：
Robert,
On 25/07/2023 22:19, Robert Raszuk wrote:
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
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
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.
Well
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
Hello,
Support.
Pierre.
Le mer. 19 juil. 2023 à 16:06, Acee Lindem a écrit :
> This begins three week LSR Working Group last call for the “IS-IS Fast
> Flooding”. Please express your support or objection prior to Friday, August
> 11th, 2023. The longer WG last call is to account for the IETF
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:
Thanks - I recognize the need to clean up the data tracker pending review. I
was the document shepherd so I had been following the document quite closely.
Acee
> On Jul 25, 2023, at 06:58, Liushucheng (Will LIU, Strategy & Industry
> Development) wrote:
>
> Hi Acee,
>
> Yes, thanks for
Hi Acee,
Yes, thanks for your kind reminder. I noticed that before I submit. However as
the system still said pending so I tried to close this.
(I thought I finished my review for version -10, however, it seems the second
round of review was missed by me, sorry)
Regards, | 致礼!
Will LIU |
Hi Will,
I’m not sure what happened with the scheduling of this review, but this
document is already an RFC (since January).
https://datatracker.ietf.org/doc/rfc9353/
RFC 9353: IGP Extension for Path Computation Element Communication Protocol
(PCEP) Security Capability Support in PCE
Reviewer: Will LIU
Review result: Ready
Hi all,
I have reviewed draft-ietf-lsr-pce-discovery-security-support-13 as part of the
Operational directorate's ongoing effort to review all IETF documents being
processed by the IESG. These comments were written with the intent of
improving the
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
Hi all,
From Notes and recordings：
Purge Originator Identification for OSPF
11:15 (originally 10:45, remote presenter could not be reached)
https://datatracker.ietf.org/doc/draft-li-lsr-ospf-purge-originator/
Zhenqiang Li & Changwang lin (10 mins)
[Acee Lindem] The medicine/solution is worse than
25 matches
Mail list logo
