Hi Tarek,
On 8/10/20, 7:27 PM, "Tarek Saad" <ts...@juniper.net> wrote:
Hi Acee,
Are you checking https://tools.ietf.org/html/draft-ietf-mpls-base-yang-14?
If so, Figure 2 shows the module is augmenting IPv4/IPv6 AFI with MPLS for
paths - check the paths
augment /rt:routing/rt:ribs/rt:rib/rt:routes/rt:route:
augment
/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route/rt:next-hop/rt:next-hop-options/rt:simple-next-hop:
augment
/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route/rt:next-hop/rt:next-hop-options/rt:next-hop-list/rt:next-hop-list/rt:next-hop:
You'll notice the MPLS augmentation above is applicable for all RIB types
(including IPv4/IPv6 and the new AFI introduced by this module). The MPLS
augmentation for IPv4/IPv6 RIBs are specific to IP prefixes that are MPLS
enabled.
That is how I originally interpreted this augmentation. Precisely, what
constitutes a route with MPLS enabled? Is it any route for the which the MPLS
augmentations are applicable or only routes on which they are present?
You'll also notice draft-ietf-mpls-base-yang is defining a new RIB
address-family for MPLS as per section 3 in RFC8349 (search for "identity mpls"
in YANG module).
The new MPLS RIB address-family is meant for "non IP" MPLS routes (e.g.
MPLS routes installed by RSVP on transit nodes, cross-connects, etc.).
Then what is missing is an augmentation for the destination-prefix that is
specific to the MPLS AFI. You should not be overloading the local-label which
applicable to all AFIs is also the destination-prefix for the MPLS AFI.
augment "/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route" {
when "derived-from-or-self(../../rt:address-family, "
+ "'mpls:mpls')" {
description
"This augment is valid only for native MPLS routes.";
}
description
"This leaf augments an native MPLS route.";
leaf destination-prefix {
type rt-types:mpls-label;
description
"MPLS destination prefix.";
}
}
Given the above, can you take another look and let us know?
I think you must follow the AFI specific augmentations set forth in RFC 8349.
It is not for the augmenting models to break these conventions
One more nit, why is label-block_state not label-block-state?
Thanks,
Acee
Regards,
Tarek
On 8/10/20, 4:39 PM, "Acee Lindem (acee)" <a...@cisco.com> wrote:
[External Email. Be cautious of content]
Hi Tarek,
In that case, there is more wrong than just the RPC since you haven't
augmented ietf-routing.yang properly to define an MPLS-specific RIB.
Furthermore, I don't think you should. We need the optional MPLS augmentations
for the IPv4 and IPv6 address families as these are what one would need in for
a IPv4 or IPv6 RIB for a device that supports MPLS.
Your augmentation to the active-route RPC needs to just be removed.
Acee
On 8/10/20, 4:24 PM, "Tarek Saad" <ts...@juniper.net> wrote:
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".
> 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)" <a...@cisco.com> 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)" <rwil...@cisco.com>
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 <ie...@btconnect.com>
> Sent: 10 August 2020 17:32
> To: RFC Errata System <rfc-edi...@rfc-editor.org>;
lho...@nic.cz; Acee
> Lindem (acee) <a...@cisco.com>; yingzhen...@huawei.com;
war...@kumari.net;
> Rob Wilton (rwilton) <rwil...@cisco.com>;
joe...@bogus.com;
> kent+i...@watsen.net; lber...@labn.net
> Cc: ts...@juniper.net; netmod@ietf.org
> Subject: Re: [netmod] [Technical Errata Reported] RFC8349
(6251)
>
> From: netmod <netmod-boun...@ietf.org> on behalf of RFC
Errata System
> <rfc-edi...@rfc-editor.org>
> 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 <ts...@juniper.net>
>
> 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
> netmod@ietf.org
>
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
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
