Re: [netmod] [Technical Errata Reported] RFC8349 (6251)
Hi Tom,
On 8/15/20, 8:25 AM, "tom petch" wrote:
From: Tarek Saad
Sent: 14 August 2020 17:24
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.
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 a native MPLS route.";
leaf destination-prefix {
type leafref {
path "../local-label";
}
description
"MPLS destination prefix.";
}
}
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.
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?
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)
On 8/11/20, 9:08 AM, "Acee Lindem (acee)" 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.
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" wrote:
From: Acee Lindem (acee)
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" wrote:
Tarek
Picking up on an earlier point,
From: Tarek Saad
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.
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
Re: [netmod] [Technical Errata Reported] RFC8349 (6251)
From: Tarek Saad
Sent: 14 August 2020 17:24
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.
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 a native MPLS route.";
leaf destination-prefix {
type leafref {
path "../local-label";
}
description
"MPLS destination prefix.";
}
}
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.
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)
On 8/11/20, 9:08 AM, "Acee Lindem (acee)" 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.
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" wrote:
From: Acee Lindem (acee)
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" wrote:
Tarek
Picking up on an earlier point,
From: Tarek Saad
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.
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.
Re: [netmod] [Technical Errata Reported] RFC8349 (6251)
From: Yingzhen Qu
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
On 8/14/20, 2:50 PM, "Yingzhen Qu" 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?
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
On 8/14/20, 9:25 AM, "Tarek Saad" 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.
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 a native MPLS route.";
leaf destination-prefix {
type leafref {
path "../local-label";
}
description
"MPLS destination prefix.";
}
}
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)
On 8/11/20, 9:08 AM, "Acee Lindem (acee)" 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
