Subject: [netmod] [Technical Errata Reported] RFC8349 (6251)

From: RFC Errata System <[email-masked]>
Date: Fri, 7 Aug 2020 08:45:34 -0700 (PDT)

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://www.rfc-editor.org/errata/eid6251

--------------------------------------
Type: Technical
Reported by: Tarek Saad <[email-masked]>

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

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Mon, 10 Aug 2020 18:29:49 +0000

[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-masked]>
> Sent: 10 August 2020 17:32
> To: RFC Errata System <[email-masked]>; [email-masked]; Acee
> Lindem (acee) <[email-masked]>; [email-masked]; [email-masked];
> Rob Wilton (rwilton) <[email-masked]>; [email-masked];
> [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [netmod] [Technical Errata Reported] RFC8349 (6251)
> 
> From: netmod <[email-masked]> on behalf of RFC Errata System
> <[email-masked]>
> 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
> 
> For MPLS RIB, it makes sense to augment with leaf named 'local-label'
> since MPLS routes are identified by MPLS label.
> 
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 10 Aug 2020 19:26:52 +0000

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-masked]> wrote:

    Hi Tom,

    Regards,
    Rob

---

From: Tarek Saad <[email-masked]>
Date: Mon, 10 Aug 2020 20:23:48 +0000

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".

        >                 parameters with a leaf named 'destination-address'.";

Regards,
Tarek

On 8/10/20, 3:27 PM, "Acee Lindem (acee)" <[email-masked]> wrote:

    [External Email. Be cautious of content]

        Hi Tom,

        Regards,
        Rob

        > https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid6251__;!!NEt6yMaO-gk!URK5WVsqD5g7WpzCU1VuzKJA0AUiawXBFLB_gENlsYMrpiMqDtyFoxw8DnSr2A$
        >
        > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/netmod__;!!NEt6yMaO-gk!URK5WVsqD5g7WpzCU1VuzKJA0AUiawXBFLB_gENlsYMrpiMqDtyFoxxyc2_LZA$

Juniper Business Use Only

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 10 Aug 2020 20:39:26 +0000

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" <[email-masked]> wrote:

    Hi Acee,

    Regards,
    Tarek

            Hi Tom,

            Regards,
            Rob

---

From: tom petch <[email-masked]>
Date: Mon, 10 Aug 2020 16:32:16 +0000

From: netmod <[email-masked]> on behalf of RFC Errata System <[email-masked]>
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 

Section: 7

Original Text
-------------

OLD:
           action active-route {
             description

Corrected Text
--------------
NEW:
           action active-route {
             description

Notes
-----

Instructions:
-------------

---

From: Tarek Saad <[email-masked]>
Date: Mon, 10 Aug 2020 23:27:30 +0000

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.
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.).

Given the above, can you take another look and let us know?

Regards,
Tarek

On 8/10/20, 4:39 PM, "Acee Lindem (acee)" <[email-masked]> wrote:

    Hi Tarek,

    Acee

        Hi Acee,

        Regards,
        Tarek

                Hi Tom,

                Regards,
                Rob

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 11 Aug 2020 00:24:19 +0000

Hi Tarek, 

On 8/10/20, 7:27 PM, "Tarek Saad" <[email-masked]> wrote:

    Hi Acee,

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?  

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.";
       }
     }

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

        Hi Tarek,

        Acee

            Hi Acee,

            Regards,
            Tarek

                    Hi Tom,

                    Regards,
                    Rob

---

From: tom petch <[email-masked]>
Date: Tue, 11 Aug 2020 08:58:45 +0000

Tarek

Picking up on an earlier point,

________________________________________
From: Tarek Saad <[email-masked]>
Sent: 10 August 2020 21:23

Hi 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

Regards,
Tarek

        Hi Tom,

        Regards,
        Rob

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 11 Aug 2020 09:47:36 +0000

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-masked]> wrote:

    Tarek

    Hi Acee,

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. 

Thanks,
Acee

    <tp>

    Tom Petch

    Regards,
    Tarek

            Hi Tom,

            Regards,
            Rob

---

From: tom petch <[email-masked]>
Date: Tue, 11 Aug 2020 10:09:51 +0000

From: Acee Lindem (acee) <[email-masked]>
Sent: 11 August 2020 10:47

Hi Tom,

    Tarek

    Hi Acee,

<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>

    Tom Petch

    Regards,
    Tarek

            Hi Tom,

            Regards,
            Rob

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 11 Aug 2020 13:08:38 +0000

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. 
  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. 
  4. Limit the active-route augmentation to AF MPLS and change the input to destination-address. 

Thanks,
Acee

On 8/11/20, 6:10 AM, "tom petch" <[email-masked]> wrote:

    Hi Tom,

        Tarek

        Hi Acee,

    <tp>

    Tom Petch 

    Thanks,
    Acee

        <tp>

        Tom Petch

        Regards,
        Tarek

                Hi Tom,

                Regards,
                Rob

---

From: Tarek Saad <[email-masked]>
Date: Tue, 11 Aug 2020 17:36:37 +0000

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-masked]> wrote:

    Hi Tom, Draft Authors,

      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 -  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

        Hi Tom,

            Tarek

            Hi Acee,

        <tp>

        Tom Petch

        Thanks,
        Acee

            <tp>

            Tom Petch

            Regards,
            Tarek

                    Hi Tom,

                    Regards,
                    Rob

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 11 Aug 2020 17:44:07 +0000

Hi Tarek,

On 8/11/20, 1:36 PM, "Tarek Saad" <[email-masked]> wrote:

    Hi Acee and Tom,

        Hi Tom, Draft Authors,

    [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:

    Acee is suggesting:
    ===============

    Regards,
    Tarek

        Thanks,
        Acee

            Hi Tom,

                Tarek

                Hi Acee,

            <tp>

            Tom Petch

            Thanks,
            Acee

                <tp>

                Tom Petch

                Regards,
                Tarek

                        Hi Tom,

                        Regards,
                        Rob

---

From: tom petch <[email-masked]>
Date: Fri, 14 Aug 2020 11:45:02 +0000

From: Acee Lindem (acee) <[email-masked]>
Sent: 11 August 2020 14:08

Hi Tom, Draft Authors,

<tp>
'easily'  mmm... I have been getting my mind around this and see what Acee means and agree.  The I-D specifies an MPLS address family but then does not create the RIB entries for it in the way that e.g. IPv4 unicast does in  RFC8349.  Easy may be but quite a change  Another option, again a significant change, would be to cater only for IP address family with MPLS and drop the MPLS address family.  Either way, whatever the authors decide, I cannot personally see this falling within the scope or an Erratum or for the IETF Last Call to complete in a week's time.

I have dropped the RFC Editor and netconf-chairs pro tem

Tom Petch

Thanks,
Acee

    Hi Tom,

        Tarek

        Hi Acee,

    <tp>

    Tom Petch

    Thanks,
    Acee

        <tp>

        Tom Petch

        Regards,
        Tarek

                Hi Tom,

                Regards,
                Rob

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 14 Aug 2020 15:27:52 +0000

Hi Tom, 
The problem is that RFC 8349 defines an AF-agnostic model for a RIB. The draft augments the base model with optional MPLS attributes that would ostensibly be applicable to all AFs. What most people miss, is that it also hijacks the base model for the MPLS address-family and subverts the AF-agnostic model. This shouldn't and can't be fixed with an Errata for RFC 8349.
Thanks,
Acee
On 8/14/20, 7:45 AM, "tom petch" <[email-masked]> wrote:

    Hi Tom, Draft Authors,

    <tp>

    Tom Petch

    Thanks,
    Acee

        Hi Tom,

            Tarek

            Hi Acee,

        <tp>

        Tom Petch

        Thanks,
        Acee

            <tp>

            Tom Petch

            Regards,
            Tarek

                    Hi Tom,

                    Regards,
                    Rob

---

From: tom petch <[email-masked]>
Date: Fri, 14 Aug 2020 16:05:56 +0000

From: Acee Lindem (acee) <[email-masked]>
Sent: 14 August 2020 16:27

Hi Tom,

Acee

We agree that this Erratum should be rejected.  When I first read the I-D, I queried that brief statement in s.2.1 about a new address family and eventually got pointed to RFC8349 s.3.  I did then and do now wonder about the meaning of address family and found its use scattered across the Routing Area with only BGP4 making any coherent, to me, use of the term; I found the use in RFC8349 a little surprising.  I tagged that sentence in the I-D as one I did not understand and still do not although Tarek's comment about routing with no IP gives me a clue.  So I see IP routing, an IP address family, as something that could have an MPLS label augmented to it; while an MPLS address family is IP free and something I am not familiar with.

I noted the lack of conditionals in the early versions of this I-D and I think it was my comments that got them added but I noted that they were not based on address family, as the IPv4 unicast augmentations of RFC8349 are, but on mpls being enabled on the box.  So I have always seen this I-D as different as adding MPLS to all the existing address families, the existing RIBs.

So I agree, as it stands the I-D augments everything but I had assumed that that is exactly what it intended to do and so does.  I did not see that as subverting the model but what it comes down to is that when we have IP with MPLS labels, or MPLS with no IP, then how many RIBs do we want and what to we want the RIBS to look like.

I would love to hear Lada's view on this as I am aware of how much research he did before the production of RFC8022 and wonder if he came across an implementation which illuminates this issue.

Tom Petch.

Thanks,
Acee

    Hi Tom, Draft Authors,

    <tp>

    Tom Petch

    Thanks,
    Acee

        Hi Tom,

            Tarek

            Hi Acee,

        <tp>

        Tom Petch

        Thanks,
        Acee

            <tp>

            Tom Petch

            Regards,
            Tarek

                    Hi Tom,

                    Regards,
                    Rob

---

From: Yingzhen Qu <[email-masked]>
Date: Fri, 14 Aug 2020 22:37:34 +0000

Sorry, had to resend the email with reduced recipients because it was held due to too many recipients. 

Thanks,
Yingzhen

On 8/14/20, 2:50 PM, "Yingzhen Qu" <[email-masked]> wrote:

    Hi Tarek,
    
    The proposed change separates IP routes and MPLS routes, and it works fine with RFC 8349. All other MPLS category augmentations can follow this style. 
    
    One question, my understanding is MPLS RIB will list all MPLS routes, such as mpls-ldp routes and mpls-static routes. A comparison is IPv4 address-family RIB lists all routes calculated by different routing protocols (BGP, OSPF etc), and ietf-ospf.yang augments "/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route" with OSPF specific attributes. However, I don't see this relationship between the base MPLS model and for example MPLS-LDP model, the binding state is in container IPv4 and IPv6 address family, and this is a bit like OSPF local-rib. The base MPLS routes is not showing this binding information (mpls-ldp model may augment this although this is not critical.). Am I missing or misunderstanding something here?
    
    In RFC 8349, "leaf source-protocol" is mandatory, and its type is identityref of routing-protocol. I don't see this is defined in the base MPLS, mpls-ldp, or mpls-static model, so what will the "source-protocol" be?
    
    Thanks,
    Yingzhen 
    
    On 8/14/20, 9:25 AM, "Tarek Saad" <[email-masked]> wrote:
    
        Hi Acee and Tom,
        
        The authors of ID: draft-ietf-mpls-base-yang met and we discussed the points below.
        We understand that RFC8349 defines an AF-agnostic model for RIBs. RFC8349 defined only two types of RIBs (IPv4 and IPv6 RIBs), but we envision other types of RIBs too (e.g. L2 RIB, MCAST RIB, etc.), in addition to MPLS RIB -- and we hope all such RIBs indeed leverage the generic RIB model introduced in RFC8349.
        
        We revisited Acee's suggestion and made a small modification (on top of it) that makes IP routes, MPLS routes (and possibly L2 or MCAST routes in future) - all have similar MPLS augmentation (in terms of local-label) while still adhering with RFC8349 to augment with leaf destination-prefix.
        
            "This leaf augments a native MPLS route.";
            type leafref {
              path "../local-label";
        
        We follow same approach for the active route RPC and continue to use a leaf "destination-address" as input (that points to a local-label leaf).
        If this is acceptable, we believe the errata 6251 can be rejected and we'll proceed with the change in the MPLS RIB model.
        
        Regards,
        Tarek (for authors)

            Hi Tom, Draft Authors,

        
            Thanks,
            Acee

        
                Hi Tom,

                    Tarek

        
                    Hi Acee,

        
                <tp>

        
                Tom Petch

                Thanks,
                Acee

                    <tp>

                    Tom Petch
        
                    Regards,
                    Tarek

        

                            Hi Tom,

        
        
                            Regards,
                            Rob

                            > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid6251__%3B!!NEt6yMaO-gk!URK5WVsqD5g7WpzCU1VuzKJA0AUiawXBFLB_gENlsYMrpiMqDtyFoxw8DnSr2A%24&amp;data=02%7C01%7Cyingzhen.qu%40futurewei.com%7Cd4686302ebf54f18490a08d8406e9beb%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637330191097435008&amp;sdata=G0myw%2BDac%2FzSudbPTi109q5JNQVaTLUTCQZHY1iQjsg%3D&amp;reserved=0
                            >
                            > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fnetmod__%3B!!NEt6yMaO-gk!URK5WVsqD5g7WpzCU1VuzKJA0AUiawXBFLB_gENlsYMrpiMqDtyFoxxyc2_LZA%24&amp;data=02%7C01%7Cyingzhen.qu%40futurewei.com%7Cd4686302ebf54f18490a08d8406e9beb%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637330191097435008&amp;sdata=n8rsj63DK2eGc%2BM5%2BxzUarSUMNfeDUqj46t8FuCm5oI%3D&amp;reserved=0

---

From: tom petch <[email-masked]>
Date: Sat, 15 Aug 2020 12:18:58 +0000

From: Yingzhen Qu <[email-masked]>
Sent: 14 August 2020 23:37
Sorry, had to resend the email with reduced recipients because it was held due to too many recipients.

Thanks,
Yingzhen

    Hi Tarek,

The problem I have is that I do not know what an address family is and I do not know what a RIB is.  I see different uses in different part of the IETF - e.g. BGP makes extensive use of AF but it is not what is meant here - and RIB was much discussed in the first iteration of the routing model with two major manufacturers seeming to have different meanings and the I-D choosing one over the other.

So, based on RFC8349, we have AF IPv4 unicast and AF IPv6 unicast as AF with multicast and MPLS as future possibilities.  And a RIB is defined by AF and a name, with the possibility of multiple such if the box supports that.  So a RIB is all the routes with a given AF value (perhaps more than one suc). 

So when you say the MPLS RIB will list all MPLS route - no, if AF is set to MPLS it is the MPLS RIB, if AF is set to something else then it is a something else RIB so a MPLS route could be in an IPv6multicast RIB..

For IPv4, it does not matter where the route came from , BGP, static, OSPF etc; if the AF is IPv4unicast then that this the RIB it is in (other organisations disagree but this is what RFC8349 says).

Which then says if you want MPLS-LDP in the same RIB, then you define them with AF MPLS (while YANG allows you to derive AF and then use derived-from-or-self to put a hierarchy of AF in a given RIB..  

So what is comes down to is what RIB do you want, which stems from what AF do you have?  MPLS-static can be a different RIB or the same RIB - the choice is yours when you configure the YANG modules assuming that they have defined the appropriate AF..

Tom Petch

    Thanks,
    Yingzhen

        Hi Acee and Tom,

        Regards,
        Tarek (for authors)

            Hi Tom, Draft Authors,

            Thanks,
            Acee

                Hi Tom,

                    Tarek

                    Hi Acee,

                <tp>

                Tom Petch

                Thanks,
                Acee

                    <tp>

                    Tom Petch

                    Regards,
                    Tarek

                            Hi Tom,

                            Regards,
                            Rob

---

From: tom petch <[email-masked]>
Date: Sat, 15 Aug 2020 12:25:15 +0000

From: Tarek Saad <[email-masked]>
Sent: 14 August 2020 17:24

Hi Acee and Tom,

<tp>
Tarek

Looks good but what about the other augments?  In RFC8349, the AF constraint is applied to augments to route, simple next hop and next hop list.  You say that you will add the constraint to the route in so doing creating an MPLS RIB but what about next hop?

Tom Petch

Regards,
Tarek (for authors)

    Hi Tom, Draft Authors,

    Thanks,
    Acee

        Hi Tom,

            Tarek

            Hi Acee,

        <tp>

        Tom Petch

        Thanks,
        Acee

            <tp>

            Tom Petch

            Regards,
            Tarek

                    Hi Tom,

                    Regards,
                    Rob

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sat, 15 Aug 2020 20:03:17 +0000

Hi Tom, 

On 8/15/20, 8:25 AM, "tom petch" <[email-masked]> wrote:

    Hi Acee and Tom,

    <tp>
    Tarek

<acee>
These are needed for the AF IPv4/IPv6 RIBs for routes with MPLS paths as you would see in vendor implementations. It was the MPLS RIB that was the source of confusion as the local-label leaf was an optional attribute for AF IPv4/IPv6 RIB sbut the primary RIB key for AF MPLS. Hopefully the MPLS-specific destination-prefix leaf will make this more obvious. 

Thanks,
Acee

    Tom Petch

    Regards,
    Tarek (for authors)

        Hi Tom, Draft Authors,

        Thanks,
        Acee

            Hi Tom,

                Tarek

                Hi Acee,

            <tp>

            Tom Petch

            Thanks,
            Acee

                <tp>

                Tom Petch

                Regards,
                Tarek

                        Hi Tom,

                        Regards,
                        Rob

---

From: tom petch <[email-masked]>
Date: Mon, 17 Aug 2020 08:44:00 +0000

From: Acee Lindem (acee) <[email-masked]>
Sent: 15 August 2020 21:03

Hi Tom,

    Hi Acee and Tom,

    <tp>
    Tarek

<acee>

<tp>
Acee,

thanks for that.  I was suspecting that that was the intention but I appreciate having the confirmation.

Tom Petch

Thanks,
Acee

    Tom Petch

    Regards,
    Tarek (for authors)

        Hi Tom, Draft Authors,

        Thanks,
        Acee

            Hi Tom,

                Tarek

                Hi Acee,

            <tp>

            Tom Petch

            Thanks,
            Acee

                <tp>

                Tom Petch

                Regards,
                Tarek

                        Hi Tom,

                        Regards,
                        Rob

---

From: Kent Watsen <[email-masked]>
Date: Mon, 17 Aug 2020 15:29:36 +0000

Folks,

Many messages for this thread are being blocked by the list server, requiring manual effort by the chairs to release them.  Here are the headers from one such message:

To: Tarek Saad <[email-masked]>, tom petch <[email-masked]>, "Rob
 Wilton (rwilton)" <[email-masked]>, RFC Errata System
 <[email-masked]>, "[email-masked]" <[email-masked]>,
 "[email-masked]" <[email-masked]>, "[email-masked]"
 <[email-masked]>

CC: "[email-masked]" <[email-masked]>, "[email-masked]"
 <[email-masked]>, "[email-masked]" <[email-masked]>,
 "[email-masked]" <[email-masked]>

At a minimum, I suggest removing [email-masked] and [email-masked] in your next Reply-All.  Thanks!

PS: I’ll release the messages stuck in the queue now.

Kent

Pending posts:
From: [email-masked] <mailto:[email-masked]> on Fri Aug 14 09:25:03 2020
Subject: Re: [netmod] [Technical Errata Reported] RFC8349 (6251)
Cause: Too many recipients to the message

From: [email-masked] <mailto:[email-masked]> on Fri Aug 14 09:27:16 2020
Subject: Re: [netmod] [Technical Errata Reported] RFC8349 (6251)
Cause: Too many recipients to the message

From: [email-masked] <mailto:[email-masked]> on Fri Aug 14 09:29:05 2020
Subject: Re: [mpls] [netmod] [Technical Errata Reported] RFC8349 (6251)
Cause: Too many recipients to the message

From: [email-masked] <mailto:[email-masked]> on Fri Aug 14 09:30:28 2020
Subject: Re: [mpls] [netmod] [Technical Errata Reported] RFC8349 (6251)
Cause: Too many recipients to the message

From: [email-masked] <mailto:[email-masked]> on Fri Aug 14 09:41:14 2020
Subject: Re: [mpls] [netmod] [Technical Errata Reported] RFC8349 (6251)
Cause: Too many recipients to the message

From: [email-masked] <mailto:[email-masked]> on Fri Aug 14 10:38:23 2020
Subject: RE: [mpls] [netmod] [Technical Errata Reported] RFC8349 (6251)
Cause: Too many recipients to the message

K.

> On Aug 14, 2020, at 7:45 AM, tom petch <[email-masked]> wrote:
> 
> From: Acee Lindem (acee) <[email-masked] <mailto:[email-masked]>>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/netmod <https://www.ietf.org/mailman/listinfo/netmod>

---

From: Tarek Saad <[email-masked]>
Date: Fri, 14 Aug 2020 16:24:34 +0000

Hi Acee and Tom,

Regards,
Tarek (for authors)

    Hi Tom, Draft Authors,

    Thanks,
    Acee

        Hi Tom,

            Tarek

            Hi Acee,

        <tp>

        Tom Petch

        Thanks,
        Acee

            <tp>

            Tom Petch

            Regards,
            Tarek

                    Hi Tom,

                    Regards,
                    Rob

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 14 Aug 2020 16:27:08 +0000

Hi Tarek,
This works for me. 
Thanks,
Acee

On 8/14/20, 12:25 PM, "Tarek Saad" <[email-masked]> wrote:

    Hi Acee and Tom,

    Regards,
    Tarek (for authors)

        Hi Tom, Draft Authors,

        Thanks,
        Acee

            Hi Tom,

                Tarek

                Hi Acee,

            <tp>

            Tom Petch

            Thanks,
            Acee

                <tp>

                Tom Petch

                Regards,
                Tarek

                        Hi Tom,

                        Regards,
                        Rob