Hi,
Contributor hat on, I take the opportunity mentioned by Acee to
highlight some of the issues in the current version:
- The I-D teaches multiple time about RFC 5088 and 5089 (while 8253 is
only mentioned in the introduction): the discussed mechanism has been
used multiple times, there is no
Hi Peter,
I agree - it is not needed in OSPFv3 Extended LSAs.
Hi Dirk, Mahendra,
How will this impact your implementations?
Thanks,
Acee
On 11/15/18, 9:48 AM, "Lsr on behalf of Peter Psenak (ppsenak)"
wrote:
Hi,
as a part of the RtgDir review we got a comment about the usage
Hi,
as a part of the RtgDir review we got a comment about the usage of the
IA bit in the OSPFv3 Extended Prefix Range TLV (Section 5).
We defined this bit for OSPFv2 originally. In OSPFv2 Extended Prefix
Range TLV is carried as a top level TLV of the Extended Prefix Opaque
LSA, which is not
Authors,
Please note that you need not wait until the end of the adoption poll to
address my comment and Julien's comments.
Thanks,
Acee
On 11/15/18, 10:02 AM, "Lsr on behalf of julien.meu...@orange.com"
wrote:
Hi,
Contributor hat on, I take the opportunity mentioned by Acee
On Fri, Nov 16, 2018 at 12:28:27AM +0100, Robert Raszuk wrote:
> Hey Toerless,
>
> Please observe that DSCP based steering may be very useful vehicle for end
> hosts/applications influencing how their packets are transported.
>
> So instead of closing that option I recommend we at least take a
Hey Toerless,
Please observe that DSCP based steering may be very useful vehicle for end
hosts/applications influencing how their packets are transported.
So instead of closing that option I recommend we at least take a good look
at what alternative mechanism exists.
And btw I read Peter's note
Thanks, Les, Peter
So... is there any opinion about creating a normative or BCP recommendation to
not use DSCP to distinguish topologies/flex-algos ? Mabybe this would
not be appropriate for LSR, but TSVWG, but i think it would be
participants in LSR that would know if there is actually still
On Thu, 15 Nov 2018 at 16:07 Toerless Eckert wrote:
> > And btw I read Peter's note as possibility (or invitation) to define
> > algorithm which takes into account DSCP rather then a announcement that
> > this is not there and it should never be.
>
> Sure, i am only talking about the solutions
-邮件原件-
发件人: Lsr [mailto:lsr-boun...@ietf.org] 代表 julien.meu...@orange.com
发送时间: 2018年11月15日 23:01
收件人: lsr@ietf.org
主题: Re: [Lsr] WG Adoption Poll for IGP extension for PCEP security capability
support in the PCE discovery - draft-wu-lsr-pce-discovery-security-support-00
Hi,
Contributor
Authors – Reminder that you need to explicitly reply to this poll.
From: Lsr on behalf of Acee Lindem
Date: Wednesday, November 14, 2018 at 3:02 PM
To: draft-wu-lsr-pce-discovery-security-support
Cc: "lsr@ietf.org"
Subject: [Lsr] IPR Poll for "IGP extension for PCEP security capability
Working on this. Try to figure out how to carry key name in PCED sub-TLV. It
looks RFC5088 and RFC5089 doesn't allow add additional sub-TLVs.
"
RFC5088
No additional sub-TLVs will be added to the PCED TLV in the future.
If a future application requires the advertisement of additional PCE
+1 Rob
I have seen number of MBH networks using DSCP to change forwarding - AKA PBR..
The question is really - what is here to standardize?
RSVP-TE use cases mentioned by Rob (CBTS/PBTS in IOS realm) are classical
examples of Policy Based Routing and as such are subject to implementation
Jeff,
> What architecture?
> PBR is a form of:
> match DSCP X
> set next-hop Y
> needs no interoperability...
That's pretty narrow view. I could say the worst possible example :) You
would have to either encapsulate or apply your sample config consistently
on every hop. Br.
To me DSCP can
It seems there was one relevant IPR
https://patents.google.com/patent/US8127129B2/en
but I am not sure it is applicable. I will consult with our IPR people to check
on this.
-Qin
发件人: Acee Lindem (acee) [mailto:a...@cisco.com]
发送时间: 2018年11月16日 11:59
收件人:
> On Nov 15, 2018, at 8:47 PM, Jeff Tantsura wrote:
>
> The question is really - what is here to standardize?
There’s a fine architectural BCP here: this is how we are solving problem XYZ.
Please don’t break this.
Tony
___
Lsr mailing list
Hi all,
PCE chair hat on, I need to rectify the statement below: at this stage,
PCE, as a WG, has not reach any consensus on this I-D, which has only
been discussed within the LSR WG. There may be individuals involved in
both WGs, but that is not a PCE WG consensus.
However, I suggest that the
16 matches
Mail list logo
