On March 29, 2019 at 1:55:17 AM, Les Ginsberg (ginsberg) (ginsb...@cisco.com)
wrote:
Les:
Hi!
Thanks for the update.
I have a couple of comments on your replies — no showstoppers. However, it
looks like my original comments were truncated; I added the remaining
comments at the end.
I am
As far as attack if someone can attach to LAN and if he knows security
details he can do much better then hack IGP.
But oh well if we prefer to continue to ride on current type of roads while
complicating design of new vehicles to accomodate it that is fine too.
Best,
R.
On Wed, Apr 3, 2019,
If you want a way to more easily enable P2P mode by default – speak to your
favorite vendor. That is a feature – not a protocol extension.
Completely disagree. To detect how many IGP peers are on the interface and to
do the switchover gracefully between 2 vs N or N vs 2 protocol extension is
On Wed, Apr 3, 2019 at 1:36 AM Robert Raszuk wrote:
> Hi Tony,
>
> > The fact that we use them in a point-to-point fashion today is somewhat
> orthogonal, as from
> > the routing protocol layer, *we cannot tell* whether an interface is
> point-to-point or not, and we
> > must be explicitly
> What extension are you proposing?
If you have only two routers on LAN based on IIH multicast discovery you
are still forming an adj between them (you do that anyway as one of them
will be DIS). But for flooding reduction point of view you can treat it as
p2p link (so it must be signaled as
Robert –
Having one circuit (or even 2 or 3) run in LAN mode “unnecessarily” does not
represent a significant scale issue.
The need for the extension you suggest would come only when there are many such
circuits which could change from 2 nodes only to > 2 (and possibly back again).
Unless that
Bruno -
V3 of the draft has been posted.
Hopefully it addresses your remaining comment.
Les
From: bruno.decra...@orange.com
Sent: Tuesday, April 02, 2019 6:59 AM
To: Les Ginsberg (ginsberg) ; lsr@ietf.org;
draft-ginsberg-lsr-isis-invalid-...@ietf.org
Cc: Alvaro Retana
Subject: RE:
Hi Les,
Sorry – but I really think you are taking this thread off topic.
>
If asking a question which is outside of the box is equal to thread
hijacking then sorry. But you won - subject line changed.
But I really think this isn’t relevant. The use of LANs in the flooding
> topology is only
Hi Robert,
> But I really think this isn’t relevant. The use of LANs in the flooding
> topology is only meaningful if we have a multi-access circuit which is used
> for transit traffic. And at least some of us are leaning to allowing for that
> possibility – which is not at all the same thing
Mobashshera -
Thanx for your interest.
While there is nothing wrong with advertising Algo 0 first, the benefits of
doing so are minimal. This is because when SR algorithm sub-TLV is received all
the algorithms advertised need to be parsed by the receiver. If your argument
is that having
Robert –
Sorry – but I really think you are taking this thread off topic.
Dynamic transition from P2P to multi-access has been defined in TRILL – see
https://tools.ietf.org/html/rfc6325#section-4.4.2 and the discussion of the
“bypass pseudo-node” bit.
Without intending to insult anyone, I have
The direction of the Flooding Path in draft-ietf-lsr-dynamic-flooding-00
is not clear.
I think it should be uni-directional, such that path (1,2) is different to
path (2,1). If the path (1,2) should be bi-directional, then it can be encoded
as (1,2,1).
Regards,
Jakob.
The IESG has received a request from the Link State Routing WG (lsr) to
consider the following document: - 'IS-IS Extensions for Segment Routing'
as Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive
Alvaro –
Responses inline.
From: Alvaro Retana
Sent: Wednesday, April 03, 2019 2:22 PM
To: Les Ginsberg (ginsberg) ;
draft-ietf-isis-segment-routing-extensi...@ietf.org
Cc: lsr-cha...@ietf.org; lsr@ietf.org; Uma Chunduri
Subject: RE: AD Review of draft-ietf-isis-segment-routing-extensions-22
I think this is too restrictive.
We should not exclude algorithms that can build a flooding topology with
unidirectional links.
Regards,
Jakob.
From: Tony Li On Behalf Of tony...@tony.li
Sent: Wednesday, April 3, 2019 10:10 PM
To: Jakob Heitz (jheitz)
Cc: lsr@ietf.org
Subject: Re: [Lsr]
Dear Authors,
I have a suggestion. Have a look :)
As per section 3.2. SR-Algorithm Sub-TLV of this draft, a router must
advertise algorithm 0 if it advertises SR Algorithm Sub TLV.
[cid:image003.png@01D4E961.B6C8F5F0]
Therefore if a router does not advertises algorithm 0 in this sub TLV,
16 matches
Mail list logo
