Hi Martin,
I agree with Luis. RFC 7971 list PCE as a potential data source for ALTO
server - https://datatracker.ietf.org/doc/html/rfc7971#autoid-19
Further RFC 7491 attempts to capture some of the possible PCE and ALTO
interactions where PCE and ALTO complement each other.
Thanks!
Dhruv
On Tue,
Hi,
I am not aware of any IPR related to this draft.
Thanks,
Dhruv
On Mon, 27 Feb 2023 at 19:28, wrote:
> Hi Authors,
>
>
>
> Please reply to this email (with the WG mailing list cced) indicating
> whether you are aware of any IPR related to draft-ietf-alto-oam-yang.
>
>
>
> If you are aware o
Hi Jensen,
For what it's worth, rfc 9249 (NTP Yang, which I am a co-author of..) uses
ACL for similar access control.
module: ietf-ntp
+--rw ntp!
+--rw port?inet:port-number {ntp-port}?
+--rw refclock-master!
| +--rw master-stratum? ntp-stratum
+--rw a
Hi Qin,
This is meant to be more about to health of the ALTO server itself instead
of that of the underlying network. This is to monitor the functioning of
the ALTO protocol with various statistics and counters.
Is the use of the term "ALTO-specific performance metrics", a source of
confusion? We
As a co-author, it is obvious I support adoption by the WG.
I believe it is a reasonable starting point for WG to take over and develop
further under its purview.
Thanks!
Dhruv
On Mon, Apr 4, 2022 at 3:44 PM wrote:
> Hi all,
>
>
>
> This is a reminder that this call for adoption is still runni
Hi WG,
I am unaware of any IPR related to this I-D.
Thanks!
Dhruv
On Wed, Mar 30, 2022 at 12:01 PM wrote:
> Hi all,
>
>
>
> You are listed as a co-author of draft-zhang-alto-oam-yang currently under
> call for adoption in ALTO WG.
>
>
>
> Please reply to this email (with the WG mailing list cc
efix. Removing
> the entry would be consistent with the newly created registry and aligned
> with the intended usage.
>
>
>
> Thank you.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* Dhruv Dhody
> *Envoyé :* mercredi 9 mars 2022 09:26
> *À :* BOUCADAIR Moh
Hi,
Does the erratum ask that we remove priv: from the IANA registry as well?
https://www.iana.org/assignments/alto-protocol/alto-protocol.xhtml#cost-metrics
https://www.iana.org/assignments/alto-protocol/alto-protocol.xhtml#endpoint-property-types
I think that would be unfortunate. Perhaps some
stry. Further, consistency in the
protocol extensions is a good thing to have, and thus using priv: makes
sense to me! I was not in the room when RFC 7285 was being developed. Maybe
some of the OG participants from the WG could through some light on this as
well :)
Thanks!
Dhruv
> Cheers,
>
&
Hi Kai,
Support adoption!
Should the IANA consideration section follow the format followed by RFC
7285 which includes lot more details on the rationale, requested
information, string format etc.
That also made me wonder if there is some benefit to also mark priv: for
private use as done for some
Hi Jensen,
>> Yes the YANG needs to follow whatever decision is taken regarding the
>> ALTO server-to-server communication. There is also a high-level
>> decision that if we have a single YANG model for ALTO that can be used
>> by both client and server or have independent yang models: one for
Hi Jensen,
Thanks for starting this thread. It is great that you are thinking of
similar questions as I was :)
On Wed, Mar 3, 2021 at 9:03 PM Jensen Zhang wrote:
>
> Dear all,
>
> I would like to make some comments on the 3rd recharter item.
>
> This item is going to propose YANG data models for
Support!
On Tue, Aug 2, 2016 at 3:07 AM, Vijay K. Gurbani <
vijay.gurb...@nokia-bell-labs.com> wrote:
> Folks: As the (draft) minutes [1] of IETF 96 reflect, there was general
> consensus on adoption of path vector and routing state abstraction
> documents towards the charter deliverable of graph
support!
Dhruv
On Tue, Aug 2, 2016 at 3:18 AM, Vijay K. Gurbani <
vijay.gurb...@nokia-bell-labs.com> wrote:
> Folks: As the (draft) minutes [1] of IETF 96 reflect, there was general
> consensus on adoption of the ALTO traffic engineering cost metrics
> (draft-wu-alto-te-metrics-08) draft as a de
rote:
>
>
> 发件人: yang.r.y...@gmail.com [mailto:yang.r.y...@gmail.com] 代表 Y. Richard Yang
> 发送时间: 2014年7月22日 15:00
> 收件人: Dhruv Dhody
> 抄送: RANDRIAMASY, SABINE (SABINE); Qin Wu; alto@ietf.org
> 主题: Re: statistics operators for ALTO cost metrics
>
>
>
> Hi Dhruv, all,
Hi Qin,
IMHO we should limit the hop count to the output we expect if we run
traceroute to the endpoint thus not indicate any lower layer devices
in this.
Hop count by its nature is a rough metric and one must rely on other
metrics like routing cost, delay to judge an optimum endpoint.
Dhruv
On
d. But that
might not be in scope of 'draft-wu-alto-te-metrics-03'
>
>The ALTO Server may protect from "malicious" requests by setting thresholds on
>the granularity of the filtering interval, >e.g. reject [a, b] with b-a < 10,
>and or reject series of req
Hi Qin,
One point to note that would be that metrics in IGP drafts are in
terms of a TE link, in ALTO we need to worry about E2E cost ( or cost
of an abstract link incase when ALTO also convey an abstract
topology), so these cost metrics are composite metrics.
ALTO server may rely on database pop
Thanks Vijay and Enrico for preparing this list of possible work items.
I support all 7.
Regards,
Dhruv
On Fri, Jan 24, 2014 at 12:41 AM, Vijay K. Gurbani wrote:
> Folks: Over the last few IETFs, Enrico and I have solicited feedback
> during face-to-face meetings, WG sessions, hallway conversat
C,D),
> ord(A,B) >= ord(C,D) implies num(A,B) >= num(C,D),
> num(A,B) <= num(C,D) implies ord(A,B) <= ord(C,D),
> ord(A,B) <= ord(C,D) implies num(A,B) <= num(C,D)."
>
> Is that sufficient?
[Dhruv Dhody>]
For most cost-type (routingcost,
20 matches
Mail list logo
