Hi Les,
The proposed new titles are much better than the old ones. I’m debating between
“application-scoped” and “application-based”, but no strong opinion. It’s up to
you and Peter to decide a good name.
Thanks,
Yingzhen
From: "Les Ginsberg (ginsberg)" <ginsb...@cisco.com>
Date: Thursday, June 18, 2020 at 11:04 AM
To: Yingzhen Qu <yingzhen...@futurewei.com>, "Les Ginsberg (ginsberg)"
<ginsberg=40cisco....@dmarc.ietf.org>, "BRUNGARD, DEBORAH A" <db3...@att.com>,
The IESG <i...@ietf.org>
Cc: "lsr-cha...@ietf.org" <lsr-cha...@ietf.org>, "aretana.i...@gmail.com"
<aretana.i...@gmail.com>, "Acee Lindem (acee)" <a...@cisco.com>,
"draft-ietf-isis-te-...@ietf.org" <draft-ietf-isis-te-...@ietf.org>,
"lsr@ietf.org" <lsr@ietf.org>
Subject: RE: [Lsr] Deborah Brungard's Discuss on draft-ietf-isis-te-app-14:
(with DISCUSS and COMMENT)
Yingzhen –
Thanx for providing the YANG example – and for taking on the additions to the
IGP YANG models.
Regarding changing the titles of the documents, I see your point. The work
started because of issues related to different TE applications (RSVP-TE and SR
Policy) – but you are correct that the solution provided can be used by
applications that are NOT TE related.
Peter and I are still mulling this over, but how about these for new titles?
IS-IS Application-Scoped Link Attributes
OSPF Application-Scoped Link Attributes
Les
From: Yingzhen Qu <yingzhen...@futurewei.com>
Sent: Wednesday, June 17, 2020 11:29 PM
To: Les Ginsberg (ginsberg) <ginsberg=40cisco....@dmarc.ietf.org>; BRUNGARD,
DEBORAH A <db3...@att.com>; The IESG <i...@ietf.org>
Cc: lsr-cha...@ietf.org; aretana.i...@gmail.com; Acee Lindem (acee)
<a...@cisco.com>; draft-ietf-isis-te-...@ietf.org; lsr@ietf.org
Subject: Re: [Lsr] Deborah Brungard's Discuss on draft-ietf-isis-te-app-14:
(with DISCUSS and COMMENT)
Hi Deborah and Les,
From YANG model’s perspective, whether there is a default value is based on the
protocol definition and it is optional. For this case, if there is no default
value the following could be an example YANG definition:
choice te-app-op-mode {
mandatory "true";
leaf legacy {
type empty;
}
leaf transition {
type empty;
}
leaf app-specific{
type empty;
}
description
"Link attributes mode.";
}
“mandatory true” is used here to make this configuration mandatory, which means
implementations supporting this draft need to explicitly config the operation
mode. I’ll add the YANG support of this feature for both OSPF and ISIS into the
next version of the augmentation drafts.
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-yang-augmentation-v1/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-lsr-ospf-yang-augmentation-v1%2F&data=02%7C01%7Cyingzhen.qu%40futurewei.com%7Cebfff0c58b924ba8765208d813b215f3%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637281002898434543&sdata=wHXivwmdfWQ5653WGjMKZSYIQClCTug3u%2BPoSKEEza0%3D&reserved=0>
https://datatracker.ietf.org/doc/draft-acee-lsr-isis-yang-augmentation-v1/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-acee-lsr-isis-yang-augmentation-v1%2F&data=02%7C01%7Cyingzhen.qu%40futurewei.com%7Cebfff0c58b924ba8765208d813b215f3%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637281002898434543&sdata=PpbaAJ3X%2FP4NA1GVcAFnGCrn3HEDKyCBh7nS9WtkIV4%3D&reserved=0>
BTW, I’m now wondering whether the title of the draft is precise? Instead of
“IS-IS TE Attributes per application”, maybe something like “IS-IS per
application link attributes”? considering more applications will be using the
sub-TLV and they may not be TE. Same for OSPF.
Thanks,
Yingzhen
From: Lsr <lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org>> on behalf of "Les
Ginsberg (ginsberg)"
<ginsberg=40cisco....@dmarc.ietf.org<mailto:ginsberg=40cisco....@dmarc.ietf.org>>
Date: Wednesday, June 17, 2020 at 4:19 PM
To: "BRUNGARD, DEBORAH A" <db3...@att.com<mailto:db3...@att.com>>, The IESG
<i...@ietf.org<mailto:i...@ietf.org>>
Cc: "lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>"
<lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>>,
"aretana.i...@gmail.com<mailto:aretana.i...@gmail.com>"
<aretana.i...@gmail.com<mailto:aretana.i...@gmail.com>>, "Acee Lindem (acee)"
<a...@cisco.com<mailto:a...@cisco.com>>,
"draft-ietf-isis-te-...@ietf.org<mailto:draft-ietf-isis-te-...@ietf.org>"
<draft-ietf-isis-te-...@ietf.org<mailto:draft-ietf-isis-te-...@ietf.org>>,
"lsr@ietf.org<mailto:lsr@ietf.org>" <lsr@ietf.org<mailto:lsr@ietf.org>>
Subject: Re: [Lsr] Deborah Brungard's Discuss on draft-ietf-isis-te-app-14:
(with DISCUSS and COMMENT)
Resent-From: <yingzhen...@huawei.com<mailto:yingzhen...@huawei.com>>
Deborah –
We have a protocol extension that provides alternative ways of supporting
legacy applications.
Under the conditions noted in Section 6.1, implementations have a choice as to
which advertisements they use.
There is nothing in the document to specify which choice is the default – nor
should there be.
To do so implies that you believe that an implementation which is otherwise
compliant (i.e., it sends/receives TLVs in accordance with the specification)
could or should be considered in violation of the specification because it
chose to use new advertisements as the default with an option to select legacy
advertisements rather than use legacy advertisements as the default with an
option to use new advertisements.
Further, what makes sense to be the default – from a user convenience POV - is
likely to change over time. Initially the existence of legacy routers will be
large and the upgraded routers few. This argues for legacy being the default.
But a few years down the road and the numbers will be reversed – in which case
the “better” default will be “new”. Declaring conformant implementations in
violation simply because they decide to align their defaults with their most
common deployment scenarios seems like unreasonable punishment.
There are certainly past examples – not least of which is the introduction of
the “extended” TLVs in RFC 5305 - which have followed a similar path. Initially
it made sense to default to old style advertisements – but over time it made
more sense to default to new advertisements.
Note that RFC 5305 was silent on this – which in my opinion is correct and what
we should do here.
I also take issue with your assumption that a default MUST be specified in the
corresponding YANG model. I am far from a YANG expert – and will happily defer
to those with more experience – but I see no reason why this cannot be modeled
as a leaf which can take on one enumerated value – but there need not be a
default. It is simply required to have a value.
A few more comments inline.
From: BRUNGARD, DEBORAH A <db3...@att.com<mailto:db3...@att.com>>
Sent: Wednesday, June 17, 2020 1:07 PM
To: Les Ginsberg (ginsberg) <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>;
The IESG <i...@ietf.org<mailto:i...@ietf.org>>
Cc: draft-ietf-isis-te-...@ietf.org<mailto:draft-ietf-isis-te-...@ietf.org>;
lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>;
lsr@ietf.org<mailto:lsr@ietf.org>; Acee Lindem (acee)
<a...@cisco.com<mailto:a...@cisco.com>>;
aretana.i...@gmail.com<mailto:aretana.i...@gmail.com>
Subject: RE: Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: (with
DISCUSS and COMMENT)
Les-
To shortcut the discussion on the need for adding a default for “control”,
these two sections are inconsistent as currently worded:
Section 6.1.1
Specifies for SR Policy and/or LFA applications: “This will require
implementations to provide controls specifying which type of advertisements are
to be sent/processed on receive for these applications.”
Section 6.3.3.
“2)Enable the use of the application specific advertisements on all Routers”
[Les:] What is being described here is a “hitless transition strategy”. It is
wrong to assume that the use of “enable” here means that the default is
“disable”.
This is the action taken in Step 2 after you started (Step 1) by using legacy
only.
None of this says or implies anything about what defaults are nor what config
commands (if any) were needed to place the box in the state specified at Step 1.
This document is not a vendor configuration guide – and I do not want to make
it one.
Les
If one is “enabling” then the default is “OFF”? So this document already
assumes it. I don’t understand the reluctance to add also to section 6.1.1.
When the YANG model is defined, this will be the config default. So either you
specify now or later – later, may result in every vendor/platform having a
different default if they don’t read section 6.3.3. That will be a major
interoperability problem – even potentially among the same vendor for different
platforms.
This same comment is for the OSPF document – it needs to specify a default.
More notes below.
Thanks,
Deborah
[Les:] “Legacy” refers to routers which do not support the extensions defined
in this document.
“Legacy advertisements” are explicitly listed in Section 3.
“Legacy advertisements” have been used (prior to this draft) in support of all
of the applications discussed in this draft (RSVP-TE, SRTE (renamed to SR
Policy as per your comment), and LFA) because there was nothing else available.
There is no intent to “upgrade RSVP-TE”. The new encodings can be used by
RSVP-TE (as discussed in Sections 6.3.4) – but this is not a main motivation
for the draft and if it never happens (i.e., RSVP-TE implementations continue
to use legacy advertisements) that is fine.
[Deborah:]
Ok, but I still agree with Bruno – this is very confusing on what is being
referenced, especially what needs to be done for RSVP-TE deployments. The
addition of the default=off will clarify RSVP-TE deployments remain the same.
[Les:]
It is not an update to RFC 5305.
As an analogy, are you suggesting that RFC 5120 should be considered an update
to RFC 5305 because it introduces new forms of IS-Neighbor and Prefix
Reachability advertisements?
[Deborah:]
If this document is similar to RFC5120, why doesn’t it use similar wording? It
would be much clearer. RFC5120 abstract says “describes an optional mechanism”.
It does not use the confusing terms “upgraded” or “legacy”. The abstract for
this document says “This document introduces new link attribute advertisements
that address both of these shortcomings.” This document does not say
“optional”. It would really help to add similar wording to the abstract. Again,
specifying the default “OFF”, will ensure the reader knows these are optional.
[Les:]
I see no reason to go beyond what the draft specifies. An implementation which
is working and conforms to the published standards in terms of the form of
advertisements sent/received is not going to change simply because an RFC says
you SHOULD.
[Deborah:]
Maybe some vendors won’t follow an RFC, maybe they will still “work”, but I
don’t see that as justification for not clearly defining a control default in
one of our RFCs.
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
