Please see inline..
On Fri, Jun 1, 2018 at 2:34 AM, Stefano Previdi (IETF)
wrote:
>
>
> On Thu, May 31, 2018, 6:15 PM Muthu Arul Mozhi Perumal <
> muthu.a...@gmail.com> wrote:
>
>> Thanks, Jeff. Would be good to have this clarified in
>>
>> draft-ginsberg-isis-rfc7810bis. My original messag
Hi Muthu,
The Sections 5, 6 and 7 of these drafts are critical as it impacts the IGP
protocol operation and stability though it is not an integral part of the IGP
protocol machinery. This functionality in a system, whether achieved in the
IGP/measurement/some-other module, is an implementation
Sounds reasonable to me..
Adding a clarification note in the draft would be useful, IMHO.
Regards,
Muthu
On Tue, Jun 5, 2018 at 5:00 PM, Ketan Talaulikar (ketant)
wrote:
> Hi Muthu,
>
>
>
> The Sections 5, 6 and 7 of these drafts are critical as it impacts the IGP
> protocol operation and stab
Hi Muthu,
These are implementation specific aspects and I am not sure if this is
something that the draft should be getting into.
Thanks,
Ketan
From: Muthu Arul Mozhi Perumal
Sent: 05 June 2018 17:19
To: Ketan Talaulikar (ketant)
Cc: Stefano Previdi (IETF) ; lsr@ietf.org; Jeff Tantsura
Subj
If these are only implementation specific aspects and shouldn't get into
the draft, what is the point of sections 5,6,7? Why would it hurt to say
what is generally expected to be part of the protocol machinery and what is
not?
BTW, any known implementation for RFC 7810, also supporting sections 5,
Hi Muthu,
The sections 5,6,7 specify the required aspects that an implementation needs to
take care of (with all its normative language) - it specifies the “WHAT” part.
Your questions were related to the “WHERE” and “HOW” parts for the same (e.g.
when you asked “configurable under IGP” and “out
> On Jun 5, 2018, at 2:21 PM, Muthu Arul Mozhi Perumal
> wrote:
>
> If these are only implementation specific aspects and shouldn't get into the
> draft, what is the point of sections 5,6,7?
these sections describe the requirements implementations must address. The way
they address them is
Muthu,
> How is the measurement interval and filter coefficients described in the
> draft related to dissemination?
>
It is directly related. If you see the title of the section is:
"Announcement Thresholds and Filters"
So measurement interval does not intend to describe how often you act
Hi Les,
The expiration date is set to expire one year from the date of allocation.
Since we made the registrations yesterday, the expiration date is different
from the others. If the document hasn't been approved for publication before
the expiration date, we'll contact you to ask whether you n
Robert,
On Tue, Jun 5, 2018 at 9:28 PM, Robert Raszuk wrote:
> Muthu,
>
>
>> How is the measurement interval and filter coefficients described in the
>> draft related to dissemination?
>>
>
> It is directly related. If you see the title of the section is:
> "Announcement Thresholds and Filt
Muthu –
I agree with the comments from all of the folks who have responded to you thus
far.
The RFC is specifying what the externally visible behavior needs to be in order
for the feature to be safely and usefully deployed – it is not specifying HOW
to implement that behavior.
But, let’s assum
Dear Authors,
I seek few clarifications on "Application Identifier bits".
As defined in the draft:
R-bit: RSVP-TE
S-bit: Segment Routing Traffic Engineering
F-bit: Loop Free Alternate
X-bit: Flex-Algo
Am I right, when I say:
R-bit: For RSVP-TE on IPv6 and IPv4 networks.
S-bit: For SR MPLS an
12 matches
Mail list logo
