Hi Tarek,
On 8/11/20, 1:36 PM, "Tarek Saad" <[email protected]> wrote:
Hi Acee and Tom,
Thanks for your feedback and suggestions. Please see further response
inline..
On 8/11/20, 9:08 AM, "Acee Lindem (acee)" <[email protected]> wrote:
[External Email. Be cautious of content]
Hi Tom, Draft Authors,
The draft could easily be fixed. You just need to:
1. Expand on the single sentence in section 2.1 on the need for
non-IP MPLS routes. Given that the draft wasn't modeled correctly, this wasn't
apparent to most of the reviewers.
[TS]: sure, we can add more text to this section. However,
2. Add an MPLS AF only augmentation (enforced via a when statement)
to each route for the MPLS AF specific destination-prefix or
destination-address.
3. Limit the current local-label augmentation to non-MPLS AFs.
[TS]: you are asking to overload "destination-prefix" to carry the MPLS
label for the MPLS RIB only
The AF specific type for the destination-prefix would be rt-types:mpls-label.
RFC 8349 was designed to support AF agnostic RIBs and if you are going to
augment it, you have to fix into the framework. If you don't, you don't, you
should add a separate table for MPLS. It seems a bit strange to consider raw
MPLS its own AF when it isn't considered an AF in other IETF documents.
Thanks,
Acee
- and to continue to use local-label to carry the label for IP RIBs - this is
a bit awkward. To illustrate:
Currently, ID:draft-ietf-mpls-base-yang models as:
=========================================
IP RIB route:
Route {
Destination-prefix = 192.168.0.0/24
Next-hop-address = 10.0.0.2
Local-label = 16000 (draft-ietf-mpls-base-yang adds this as augmentation)
}
MPLS RIB route:
Route {
Local-label = 18000
Next-hop-address = 10.0.0.2
}
Acee is suggesting:
===============
IP RIB route (same as in ID:draft-ietf-mpls-base-yang)
Route {
Destination-prefix = 192.168.0.0/24
Next-hop-address = 10.0.0.2
Local-label = 16000
}
MPLS RIB route:
Route {
Destination-prefix = 18000
Next-hop-address = 10.0.0.2
}
IMO, it is awkward that MPLS label is carried in local-label for IP RIBs
routes, while it is carried in destination-prefix for MPLS AF routes.
4. Limit the active-route augmentation to AF MPLS and change the
input to destination-address.
[TS]: I'm summarizing intention of ID:draft-ietf-mpls-base-yang in the
example below to illustrate:
1) RFC 8349 defines RPC (equivalent to "show route 192.168.0.1":
Input:
destination-address (IP=192.168.0.1, RIB AF=IPv4)
Output:
Active-route
2) ID:draft-ietf-mpls-base-yang wants to reuse this RPC (equivalent to
"show route mpls-label 16000")
Input:
Local-label (label=18000, RIB AF=MPLS)
Output:
Active-route
Regards,
Tarek
Thanks,
Acee
On 8/11/20, 6:10 AM, "tom petch" <[email protected]> wrote:
From: Acee Lindem (acee) <[email protected]>
Sent: 11 August 2020 10:47
Hi Tom,
I fully understood your original comment. There are other problems
with this model. See inline.
On 8/11/20, 4:59 AM, "tom petch" <[email protected]> wrote:
Tarek
Picking up on an earlier point,
________________________________________
From: Tarek Saad <[email protected]>
Sent: 10 August 2020 21:23
Hi Acee,
The existing RPC is used to query (defined AFIs=IPv4/IPv6) RIB
to return the matching active route identified by a "destination address".
The MPLS module is trying to reuse this RPC so to query the
MPLS RIB to return the matching active route identified by a "local label".
The RPC defined in RFC 8349 readily accepts MPLS AFI in it
(/rt:routing/rt:ribs/rt:rib/rt:active-route) - unless we augment and suppress
it with a "when check".
IMO, it is reusable as-is but the text below is limiting the
leaf name that identifies an entry in RIB to "destination-address" only - in
MPLS RIB the entry leaf name that identifies an entry is "local-label".
It is not reusable as is since the augmentation RPC augmentation
must have a when statement restricting it to AF MPLS. Also, local-label is a
leaf which is applicable to all address families. It cannot be the AF MPLS
destination-prefix. This augmentation is missing.
<tp>
I am probably getting out of my depth here, On 1may20 I raised the
issue of why the 'MUST' in the description in RFC8349 was not enforced in the
YANG and 5may20 Martin explained that there is a rule in the YANG ABNF of
input-stmt that makes the obvious impossible:-( You are raising more profound
issues about the RIB that I had not perceived when I reviewed mpls-base-yang
for which I, and I hope everyone else, will be grateful.
If this mpls I-D is to proceed in the immediate future, it looks
like the action may have to be deferred for future study.
More generally, I think that the interaction of forward by address
and forward by label is challenging. When first I looked at the MPLS I-D I was
surprised at the way RFC8349 was augmented. I had not seen MPLS as an
alternative to IPv4 or IPv6 or ... in the way in which the RFC is used although
the RFC does state that it can be; rather, to me, labels are a different
animal, but I assumed that everyone knew what they were doing.
Tom Petch
Thanks,
Acee
<tp>
There should be a 'when' check to enforce the 'MUST' but the
rules of YANG do not allow it in this structure. I raised this on the NETMOD
list at the time of WGLC and Martin pointed me to a rule in the ABNF which
prohibits such a check. He also said that the rule was not needed and would be
a candidate to remove when YANG is revised.
Hence I have always thought of this MUST in the documentation
as a constraint that must be enforced in the YANG
Tom Petch
> action active-route {
> description
> "Return the active RIB route that is
used for the
> destination address.
>
> Address-family-specific modules MUST
augment input
> parameters with a leaf named
'destination-address'.";
Regards,
Tarek
On 8/10/20, 3:27 PM, "Acee Lindem (acee)" <[email protected]>
wrote:
[External Email. Be cautious of content]
All (Speaking as an author of RFC 8349),
I just looked at this in more detail and I don't think the
ietf-mpls.yang model should be augmenting the
/rt:routing/rt:ribs/rt:rib/rt:active-route RPC. The intent of the RPC is to
return the address-family specific active-route corresponding to the
destination-address. This model attempts to overload this RPC with a different
action all together - returning a route that has the local-label as an optional
attribute. I'd reject the Errata and believe the augmentation should be removed
from ietf-mpl.yang. Whether it is replaced with a different one is up to the
co-authors of ietf-mpls.yang.
Thanks,
Acee
On 8/10/20, 2:29 PM, "Rob Wilton (rwilton)"
<[email protected]> wrote:
[Resend to hopefully pass recipient limit filter]
Hi Tom,
I would be interested to hear from the original authors.
My impression is that this is a technically reasonable
change, but I don't think that an erratum can create a new revision of a YANG
module.
If this erratum was processed as "Hold for document
update" then would that be sufficient to do the right thing in the MPLS YANG
module?
Regards,
Rob
> -----Original Message-----
> From: tom petch <[email protected]>
> Sent: 10 August 2020 17:32
> To: RFC Errata System <[email protected]>;
[email protected]; Acee
> Lindem (acee) <[email protected]>;
[email protected]; [email protected];
> Rob Wilton (rwilton) <[email protected]>;
[email protected];
> [email protected]; [email protected]
> Cc: [email protected]; [email protected]
> Subject: Re: [netmod] [Technical Errata Reported]
RFC8349 (6251)
>
> From: netmod <[email protected]> on behalf of
RFC Errata System
> <[email protected]>
> Sent: 07 August 2020 16:45
>
> <tp>
> This is the erratum of whose arrival I speculated on
this list on June
> 16th.
>
> There is a degree of urgency about it. The I-D in
question is mpls-base-
> yang, currently in IETF Last Call, which is a
Normative dependency of bfd-
> yang which is a Normative dependency for a small
mountain of I-D which
> have been waiting a year or so (e.g. ospf-yang).
>
> I suspect that the technically perfect solution would
involve a YANG
> union, choice or some such structure but as I said in
my Last Call comment
> I can live with a label that contains such as
'address' encompassing such
> as 'label' in the context of forwarding. I take
labels to mean what
> labels mean rather than what I might find in a work
of reference.
>
> Tom Petch
>
> The following errata report has been submitted for
RFC8349,
> "A YANG Data Model for Routing Management (NMDA
Version)".
>
> --------------------------------------
> You may review the report below and at:
>
https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid6251__;!!NEt6yMaO-gk!URK5WVsqD5g7WpzCU1VuzKJA0AUiawXBFLB_gENlsYMrpiMqDtyFoxw8DnSr2A$
>
> --------------------------------------
> Type: Technical
> Reported by: Tarek Saad <[email protected]>
>
> Section: 7
>
> Original Text
> -------------
> The RPC "active-route" is used to retrieve the active
route in a RIB.
> RFC8349 defined two AFIs (v4/v6).
>
> draft-ietf-mpls-base-yang is defining a new RIB AFI
for MPLS as per
> section 3 in RFC8349.
>
> The RPC has a "MUST" statement that all RIBs must
augment input
> parameters with a leaf named 'destination-address'.
>
> For MPLS RIB, it makes sense to augment with leaf
named 'local-label'
> since MPLS routes are identified by MPLS label.
>
> We ask to make the following change:
>
> OLD:
> action active-route {
> description
> "Return the active RIB route that is
used for the
> destination address.
>
> Address-family-specific modules MUST
augment input
> parameters with a leaf named
'destination-address'.";
>
>
> Corrected Text
> --------------
> NEW:
> action active-route {
> description
> "Return the active RIB route that is
used for the
> destination address.
>
> Address-family-specific modules MUST
augment input
> parameters with a suitable leaf that
identifies the
> route.";
>
>
> Notes
> -----
>
>
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If
necessary, please
> use "Reply All" to discuss whether it should be
verified or
> rejected. When a decision is reached, the verifying
party
> can log in to change the status and edit the report,
if necessary.
>
> --------------------------------------
> RFC8349 (draft-ietf-netmod-rfc8022bis-11)
> --------------------------------------
> Title : A YANG Data Model for Routing
Management (NMDA
> Version)
> Publication Date : March 2018
> Author(s) : L. Lhotka, A. Lindem, Y. Qu
> Category : PROPOSED STANDARD
> Source : Network Modeling
> Area : Operations and Management
> Stream : IETF
> Verifying Party : IESG
>
> _______________________________________________
> netmod mailing list
> [email protected]
>
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/netmod__;!!NEt6yMaO-gk!URK5WVsqD5g7WpzCU1VuzKJA0AUiawXBFLB_gENlsYMrpiMqDtyFoxxyc2_LZA$
Juniper Business Use Only
Juniper Business Use Only
Juniper Business Use Only
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
