I think that the only time we should include the protocol (in addition to
'-lsr-') is if we have split documents (for whatever reason) on the same
solution. We have an example of this actually:
draft-ietf-isis-segment-routing-msd-09
draft-ietf-ospf-segment-routing-msd-09
Going forward we either combine these types of documents into a single document
(discussion started @101) so "-lsr-" is appropriate, or if there's some reason
not to merge them then we have 2 documents that need the protocol identifier to
disambiguate.
In this case there's no ambiguity so I don't see the need of adding an extra
"-isis-".
Thanks,
Chris.
Les Ginsberg (ginsberg) <[email protected]> writes:
Well...this raises a topic on which I would like to have feedback from the WG.
Combining IS-IS/OSPF into one working group is fine - no argument there.
But, we now may be producing two classes of documents:
1)Documents which are specific to a protocol (IS-IS or OSPFv2 or OSPFv3)
2)Documents which cover 2 or more protocols
draft-ginsberg-isis-rfc7810bis-00.txt is Category #1 - and there is NO CHANCE this
document will EVER cover OSPF - since OSPF already has RFC 7471 and this bis document is
a correction to the IS-IS specific RFC7810. Calling it "-lsr-" to me is simply
confusing as it in no way indicates that it is IS-IS specific.
I suggest that any document which falls into Category 1 should continue to
follow the traditional protocol specific naming.
If this somehow violates some IETF rule then I suppose we could use
"-lsr-isis-". (somewhat verbose)
For Category 2 documents "-lsr-" certainly makes sense.
Comments??
Les
-----Original Message-----
From: Acee Lindem (acee)
Sent: Tuesday, April 03, 2018 7:45 AM
To: Les Ginsberg (ginsberg) <[email protected]>; [email protected]
Subject: Re: [Lsr] FW: New Version Notification for draft-ginsberg-isis-
rfc7810bis-00.txt
Hi Les,
Can you resubmit as draft-ginsberg-lsr-rfc7810bis-00.txt? Also, please add a
"Changes from RFC 7810" section to the "Introduction". I see you have added
RFC8174 to the "Requirements Language" section already.
I think we should accept this as an LSR Working Group document - does
anyone disagree?
Thanks,
Acee
On 3/30/18, 6:39 PM, "Lsr on behalf of Les Ginsberg (ginsberg)" <lsr-
[email protected] on behalf of [email protected]> wrote:
Folks -
A bis version of RFC 7810 has been submitted to address the issue reported
in Errata ID: 5293 https://www.rfc-editor.org/errata_search.php?rfc=7810
Given that there exist implementations which have interpreted the
ambiguous encoding of some sub-TLVs in different/non-interoperable ways
it was felt that a bis version of the RFC was justified.
Please see the Appendix of the draft for a discussion of the changes from
RFC 7810 and the reasons why.
Les
-----Original Message-----
From: [email protected] <[email protected]>
Sent: Friday, March 30, 2018 3:33 PM
To: Qin Wu <[email protected]>; David Ward (wardd)
<[email protected]>; Spencer Giacolone <[email protected]>;
Spencer Giacalone <[email protected]>; John Drake
<[email protected]>; Les Ginsberg (ginsberg) <[email protected]>; David
Ward (wardd) <[email protected]>; Stefano Previdi <[email protected]>
Subject: New Version Notification for draft-ginsberg-isis-rfc7810bis-00.txt
A new version of I-D, draft-ginsberg-isis-rfc7810bis-00.txt
has been successfully submitted by Les Ginsberg and posted to the IETF
repository.
Name: draft-ginsberg-isis-rfc7810bis
Revision: 00
Title: IS-IS Traffic Engineering (TE) Metric Extensions
Document date: 2018-03-30
Group: Individual Submission
Pages: 19
URL: https://www.ietf.org/internet-drafts/draft-ginsberg-isis-
rfc7810bis-00.txt
Status:
https://datatracker.ietf.org/doc/draft-ginsberg-isis-rfc7810bis/
Htmlized:
https://tools.ietf.org/html/draft-ginsberg-isis-rfc7810bis-00
Htmlized: https://datatracker.ietf.org/doc/html/draft-ginsberg-isis-
rfc7810bis
Abstract:
In certain networks, such as, but not limited to, financial
information networks (e.g., stock market data providers), network-
performance criteria (e.g., latency) are becoming as critical to
data-path selection as other metrics.
This document describes extensions to IS-IS Traffic Engineering
Extensions (RFC 5305) such that network-performance information can
be distributed and collected in a scalable fashion. The information
distributed using IS-IS TE Metric Extensions can then be used to make
path-selection decisions based on network performance.
Note that this document only covers the mechanisms with which
network-performance information is distributed. The mechanisms for
measuring network performance or acting on that information, once
distributed, are outside the scope of this document.
This document obsoletes RFC 7810.
Please note that it may take a couple of minutes from the time of
submission until the htmlized version and diff are available at tools.ietf.org.
The IETF Secretariat
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
