Hi, Les:
Would you like to revisit
https://mailarchive.ietf.org/arch/msg/lsr/7DwbQXjBO8qeGsES7In7OavN1mk/ for our
previous discussion on this point?
If there is no more new contents/inputs, can we stop looping it back again?
I think you should also notice that the bogus information that needs
Makes sense.
Thanks for the detailed explanation!
Gyan
On Fri, Feb 18, 2022 at 10:51 PM Les Ginsberg (ginsberg)
wrote:
> Gyan –
>
>
>
> As RFC 5302 and RFC 7775 clearly state, IS-IS also has “a pecking order
> for route preference before the equal cost time breaker comes into play”.
>
>
>
>
Gyan –
As RFC 5302 and RFC 7775 clearly state, IS-IS also has “a pecking order for
route preference before the equal cost time breaker comes into play”.
The differences between IS-IS and OSPF largely derive from the fact that a
single OSPF instance may include multiple areas – whereas a single
Chris -
I don't agree with everything you state below - but let's put that aside.
You have a tough call to make - no matter what you decide some folks will be
very unhappy - I don't want to make things tougher for you.
But there is one point that seems highly relevant to me. A compelling case
Les
Just as a comparison and I believe that maybe what Muthu is alluding to is
that OSPF on the other hand does have a pecking order for route preference
before the equal cost time breaker comes into play.
intra-area, inter-area followed by external
So the result is not an ECMP with two
"Les Ginsberg (ginsberg)" writes:
Chris -
[... trimmed out the restated points ...]
I also strongly object to your statement below:
" I've asked for cases that this draft would break things, not whether it has warts
or not."
This suggests (intentionally or not) that so long as a draft
I don’t see any response to the points Les made in the email thread, below.
RFC5316 should be fine, so, as I indicated, your draft is redundant and
dubious. As an aside. I find it incredibly obnoxious and not within your remit
to be instructing WG members what to do and I hope the WG chairs
Hi, John:
If you follow Les, then also follow my responses to Les.
Aijun Wang
China Telecom
> 在 2022年2月19日，06:28，John E Drake 写道：
>
> Hi,
>
> I completely agree with the email from Les, below. "Do no harm" is an
> insufficient reason to adopt a draft of redundant and dubious functionality.
Hi, Les:
I remembered we have discussed your proposal. If you ignored, let me repeat its
drawbacks:
Don’t you think it is curious to construct the bogus information within the
network, just want to let the operator conform their deployment with the
non-aimed application scenarios of one RFC?
Hi,
I completely agree with the email from Les, below. "Do no harm" is an
insufficient reason to adopt a draft of redundant and dubious functionality.
Yours Irrespectively,
John
Juniper Business Use Only
> -Original Message-
> From: Lsr On Behalf Of Les Ginsberg (ginsberg)
>
Chris -
My objections to this draft are similar to Peter's - the use of a prefix to
identify a link is flawed - does not work in all cases. And the use case for
the draft can be met using RFC 5316.
It is also incorrect to state that a bis of RFC 5316 is required. That
statement was made based
Muthu –
Let me try to be more complete in my response.
What RFC 7775 is addressing is defining the route preference between different
route types. It is necessary for interoperability that all implementations use
the same preference rules in this regard.
(One of the motivations for the RFC was
[resent with correct CC's]
Peter Psenak writes:
Chris,
I looked at ver-3.
It defines a new top-level TLV, that advertises prefix and supports all
existing sub-TLVs defined for link advertisement ("IS-IS Sub-TLVs for TLVs
Advertising Neighbor Information").
And why? Because authors want to
Robert Raszuk writes:
I didn't see any client/app data in this proposal.. There are
other drafts out there that seem to be talking about that, which
I also don't like (as wg member )
The way I look at them and seeing authors referencing directly those
drafts is that this
Chris,
I looked at ver-3.
It defines a new top-level TLV, that advertises prefix and supports all
existing sub-TLVs defined for link advertisement ("IS-IS Sub-TLVs for
TLVs Advertising Neighbor Information").
And why? Because authors want to use common subnet to identify two
endpoints of
Robert Raszuk writes:
Hi Chris,
Tony Li (at least) seemed to think that it was useful to be able
to attach TE attributes to a link, not just to prefixes. Perhaps
I've missed this in the thread but what current mechanism (rfc?)
are you referring to, to identify a link and
Hi Chris,
Tony Li (at least) seemed to think that it was useful to be able to attach
> TE attributes to a link, not just to prefixes. Perhaps I've missed this in
> the thread but what current mechanism (rfc?) are you referring to, to
> identify a link and attach TE attributes to it?
I have two
Peter Psenak writes:
Chris,
the draft attempt to use the local subnet information for identifying two
endpoints of the same link. That seems wrong in itself. In addition:
The -03 revision uses other methods to identify an inter-AS link (the same that
are used in RFC5316 if I'm not
Hi, Robert:
Thanks for your considerations.
Currently the optimization routing for CAN scenarios are mainly for local area,
I think such information needn’t flood throughout the original area.
In future, it may be needed in other areas if the cost from the IGP metric play
the weak role for
Hi Aijun,
I do have some sympathy to what you are trying to do here. But I also have
a concern if IGP is the right protocol to load it and use it disseminate
completely opaque to its main role information.
Imagine your CAN use case and use of areas with summarization. The ingress
nodes/machines
Hi, Peter:
I think you may not have time to follow the previous discussions.
Please refer to
https://mailarchive.ietf.org/arch/msg/lsr/molRRoWXOBhaHFc5GPAPmvVISDs/ for
my summary responses, for how to apply the solution in various scenarios,
include the unnumbered scenario(we have updated the
21 matches
Mail list logo
