Hi Tom,
On 6/1/20, 6:53 AM, "rtgwg on behalf of t petch" <[email protected] on
behalf of [email protected]> wrote:
I have some doubts about this I-D.
Hopefully, I can assuage your doubts.
-01 had four authors; -13 has four authors. None are the same yet much
of the text in the I-D is the same.
As excellent observation - the original authors had no ambition to complete the
draft. There are listed in the acknowledgments.
NSSA could be added to the Terminology and/or expanded on first use.
Fixed.
Policy subroutines sound interesting - if there is one example I would
find useful it would be one involving subroutines.
We could look at this.
10 YANG modules
I only see one singular
Fixed.
XXXX is used as a placeholder for two different I-D
I've fixed this though I don't see the placeholders references as being
ambiguous in the context.
I like the reference to RFC2178, RFC5130 but they need to appear in the
I-D References and more YANG reference clauses would not come amiss
Fixed.
typedef metric-modification-type {
.....
If the result would exceed the maximum metric
(0xffffffff), set the metric to the maximum.";
OSPF has a 16 bit link metric, a 24 bit route metric as defined in
ospg-yang. Defining a maximum of 0xffffffff seems problematic. Add two
to 16777215 and you get one.
The other LSR protocol has a 6 or 24 or 32 bit metric depending on where
you look.
The setting of the metric is independent of the application of the policy. As
with other components of a routing policy, it is up to the network engineer
defining the policy to define a policy that matches the context.
"The prefix member in CIDR notation -- "
member of what? My prefix are a number!
I've removed CIDR as it is not used in RFC RFC 6021.
leaf mask-length-upper {
the example implies that upper and lower must both be present which I do
not see in the YANG. Both upper and lower are part of the YANG key of
the list which also suggests that both need to be present
You are correct - they are both required to be part of the key. If they are not
part of the key, you would not be able to have multiple rules with the same
prefix. We could change this to have prefix sequence number or name but this
would diverge from the OpenConfig model unnecessarily.
grouping match-proto-route-type-condition {
gets a bit long; here and elsewhere, is 'proto' needed as part of the
identifiers?
I agree - will change condition but keep identity for protocol types to match
as proto-route-type.
container prefix-sets {
leaf mode {
I am not a fan of features - Cartesian explosion - but wonder if one is
called for here at least for mixed mode
I am going to start a discussion on removing "mixed" since I know of no
implementations.
Thanks,
Acee
Tom Petch
>
> ----- Original Message -----
> From: <[email protected]>
> To: <[email protected]>
> Cc: <[email protected]>
>
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
