Subject: Re: [spring] to drop or to forward unlabelled (Re: Question on RFC8660)

From: Martin Horneffer <[email-masked]>
Date: Fri, 4 Sep 2020 16:56:59 +0200

Hi Tarek,

1) it's a good question what to do label stack has more than one label 
left, e.g. more SR-MPLS segments. Or a service label. Or both...
So far I was considering two possibilities:
a) Only one label is dumped. In case of SR-MPLS this means that one 
sgement can be skipped. In case of a folloowing service label, this 
could theoretically put the packet in a wrong context.
b) The packets is only forwarded if the label was the last, i.e. 
bottom-of-stack set.
Any of the two possibilities would help in the relevant case of an IP 
packet with a single label (which is the transport label).

2) My assumption would be that the last path information is being used.
I.e. if a packets arrives at a router R with a single label. Based on 
the label R determines a next-hop. If the next-hop does not provide a 
label for this FEC, then the router effectively performs a POP 
operations, but still forwards.
If the packets arrives at R as plain IP, and the routes can successfully 
do a route lookup and determine a next-hop, then it sends the packets 
WITHOUT doing a PUSH operation.
If I understood it correctly, this is the way LDP behaves.

Best regards, Martin

Am 30.08.20 um 02:36 schrieb Tarek Saad:
> Hi Martin,
>
> See inline for some comments.
>
> On 8/27/20, 6:35 AM, "spring on behalf of Martin Horneffer" <[email-masked] on behalf of [email-masked]> wrote:
>
>      Hello everyone,
>
>      may I come back the the question below? Or rather let me update it a little:
>
>      In case an SR-MPLS path is broken, should a node rather drop the packet,
>      or forward it?
>
>      This can happen whenever the IGP points to a certain next hop, but that
>      neither supplies a valid SID, nor allows LDP-stitching for whatever
>      reason. For PUSH as well as for CONTINUE.
>
>      We have been using MPLS transport and a BGP free core since about two
>      decades now, using LDP. In the analog case, LDP creates "unlabelled"
>      entries in the LFIB, does the equivalent of a POP operation and forwards
>      the packet to the next-hop as chosen by the IGP.
>
>      This behavior obviously breaks any traffic that relies on a service
>      label, but it can protect some traffic.
>      In our case a huge percentage of all traffic still is public IPv4. This
>      needs MPLS only for a transport label, be it LDP or SR-MPLS. If this
>      traffic gets forwarded unlabelled, it follows an IGP default route to a
>      central device, where it is 1) redirected to the correct destination and
>      2) counted in a way that operators can quickly see whether and where
>      this kind of failure occurs at some point in the network.
>
> [TS]: The SR Path may be composed of multiple SIDs (i.e. label stack) -- where the top SID destination is not the SR Path endpoint.. I sense from "gets forwarded unlabelled " as you will discard the full label stack (?) and forward the packet unlabeled to the central device? Or are you encapsulating the remaining MPLS packet over IP and IP routing packet to the central device to be inspected? In either case, I expect somehow the packet to be ultimately delivered to the original SR Path endpoint/egress?
>
>      After more operational experience and several internal discussions we
>      agreed that we want packets to be forwarded unlabelled rather than
>      dropped. Anyone to share, or oppose this position?
> [TS]: again, I'm not clear on when you say "forward unlabelled" - do you mean packets will follow the top SID's the IP IGP route? Or are you peaking into the destination IP (public IPv4) of packet encapsulated in MPLS to determine how to forward it?
>
> Regards,
> Tarek
>
>      Best regards, Martin
>
>
>      Am 31.01.20 um 16:50 schrieb Martin Horneffer:
>      > Hello everyone,
>      >
>      > again it seems the interesting questions only show up when applying
>      > something to the live network...
>      >
>      > We ran into something that poses a question related to RFC8660: What
>      > is the exact meaning of section 2.10.1, "Forwarding for PUSH and
>      > CONTINUE of Global SIDs", when the chosen neighbor doesn't provide a
>      > valid MPLS path?
>      >
>      > The relevant sections reads:
>      >
>      >       -  Else, if there are other usable next hops, use them to forward
>      >          the incoming packet.  The method by which the router "R0"
>      >          decides on the possibility of using other next hops is beyond
>      >          the scope of this document.  For example, the MCC on "R0" may
>      >          chose the send an IPv4 packet without pushing any label to
>      >          another next hop.
>      >
>      > Does the part "send an IPv4 packet without pushing any label" apply to
>      > PUSH and CONTINUE, or just to PUSH?
>      > Does R0 have to validate that neighbor N can correctly process to
>      > packet? Or can it forward the packet regardless?
>      >
>      > The reason for asking is that we are now seeing issues similar to ones
>      > we had when starting with LDP based MPLS about two decades ago:
>      > traffic being black holed even though a path to the destination
>      > exists, because the MPLS path is interrupted somewhere in the middle.
>      >
>      > With LDP we know the case of LFIBentries called "unlabelled". While
>      > this does break connectivity for many kinds of service, e.g. those
>      > relying on an additional service labels, it still works for plain
>      > IP(v4) traffic. In our cases, this works perfectly fine for all
>      > internal routing and control traffic. And even for IPv4 traffic that
>      > gets collected by a central router that injects a default route.
>      >
>      > However, depending on the exact interpretation of the above paragraph,
>      > an implementor might feel obliged to chose the next paragraph:
>      >
>      >       -  Otherwise, drop the packet.
>      >
>      > Which is, at least in our case, very unfortunate...
>      >
>      > Any advice or opinion appreciated!
>      >
>      >
>      > Best regards, Martin
>      >
>      >
>      >
>      >
>      > _______________________________________________
>      > spring mailing list
>      > [email-masked]
>      > https://www.ietf.org/mailman/listinfo/spring
>
>      _______________________________________________
>      spring mailing list
>      [email-masked]
>      https://www.ietf.org/mailman/listinfo/spring

---

From: Martin Horneffer <[email-masked]>
Date: Fri, 4 Sep 2020 17:01:05 +0200

Hi Gyan,

we had this kind of issue since the rise of LDP and the invention of the 
BGP free core. In a larger network, every now and then.

Some years later the notions of setting up targeted LDP sessions solved 
some part of the issue.
Some more years later, IGP-LDP synchronization indeed solved a big part 
of the issue in a more elegant way.
Yet they don't cover all possible failure cases.

Best regards, Martin

Am 30.08.20 um 16:21 schrieb Gyan Mishra:
>
> Hi Martin
>
> That is a very common scenario that occurs where one path where LDP 
> neighbor has lost its label binding for FEC destinations.
>
> Most providers don’t label all prefixes and only label interesting 
> traffic meaning FEC destination which is the egress endpoint loopback 
> iBGP peers for an LSP.
>
> So their is an ACL that is used for label allocation, label 
> advertisement and label accept policy to created the label binding LIB 
> and and Label forwarding table LFIB.
>
> So the LSP is built from ingress PE to egress PE and the label mapping 
> along the path occurs downstream unsolicited in the opposite direction 
> of the LSP via label mapping message from the egress PE that the LSP 
> is being built to - to the ingress PE from the downstream node to the 
> upstream node.
>
> Most operators have a BGP free and PIM free core and usually don’t 
> dual stack the core and the concept of softwire mesh framework RFC 
> 5565 so 6to4 softwire would be v6 edge over a v4 core or v4 edge over 
> a v6 core.
>
> So with the BGP free core all PE are BGP route reflector clients and 
> have a peer to RRs that sit in the P core.
>
> The P core is BGP free so only runs an IGP ISIS PE OSPF.  This point 
> is critical and that is that since the core is BGP free it can not 
> perform L3 forwarding so all packets must be L2.5 label switched via 
> topmost label either LDP or RSVP or SR-TE.
>
> So now that we have established the core construct let’s dig into the 
> problem with the label mapping being broken on a node along a path.
>
> So with LDPv4 or LDPv6 or SR-MPLS we have a concept called “ldp-IGP” 
> synchronization.  SR-MPLS uses IGP sync for SR sid labels as well 
> since SR is reusing the MPLS data plane.
>
> So on all MPLS core enabled interfaces on both PE and P LDP sync is 
> enabled.
>
> So the goal of ldp-IGP sync is to prevent black hole of packets on 
> MPLS interfaces cause by MPLS LDP failure and so how it works is the 
> IGP prefix that needs to build a label binding for FEC destination for 
> label swapping to occurs in the core so the IGP must not come up and 
> forward traffic along the path until MPLS is up or traffic will be 
> “black holed” and dropped.  So how this is accomplished is the IGP 
> sets the prefix metric to maximum 65535 for ospf and ISIS wide metric 
> does the same so the path now cannot be utilized until ldp comes up 
> and the label binding message is received via downstream unsolicited 
> to create outgoing label for the LFIB entry.  Once LDP is up and the 
> LFIB entry outing label is populated the IGP prefix is “unset” so now 
> is set to its normal IGP metric and traffic can now flow over the path.
>
> For LDP troubleshooting first you have to see if discovery link LDP is 
> up on the interface and then have to check if both Ldp adjacencent 
> nodes have a route in rib for each other’s LDP router id for the ldp 
> neighbor to come UP and label mapping message to be sent.  As you 
> mentioned if their is summarization for FEC which results in a loop 
> the binding does not get built for the FEC resulting in unlabeled FECs 
> in the LFIB.
>
> Hope that explanation helps.
>
>
> Kind Regards
>
> Gyan
>
> On Sat, Aug 29, 2020 at 8:37 PM Tarek Saad <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi Martin,
>
>
>
>     On 8/27/20, 6:35 AM, "spring on behalf of Martin Horneffer"
>     <[email-masked] <mailto:[email-masked]> on
>     behalf of [email-masked] <mailto:[email-masked]>> wrote:
>
>
>
>         Hello everyone,
>
>
>
>     [TS]: The SR Path may be composed of multiple SIDs (i.e. label
>     stack) -- where the top SID destination is not the SR Path
>     endpoint.. I sense from "gets forwarded unlabelled " as you will
>     discard the full label stack (?) and forward the packet unlabeled
>     to the central device? Or are you encapsulating the remaining MPLS
>     packet over IP and IP routing packet to the central device to be
>     inspected? In either case, I expect somehow the packet to be
>     ultimately delivered to the original SR Path endpoint/egress?
>
>
>
>     [TS]: again, I'm not clear on when you say "forward unlabelled" -
>     do you mean packets will follow the top SID's the IP IGP route? Or
>     are you peaking into the destination IP (public IPv4) of packet
>     encapsulated in MPLS to determine how to forward it?
>
>
>
>     Regards,
>
>     Tarek
>
>
>
>         Best regards, Martin
>
>
>
>
>
>         > Hello everyone,
>         >
>         > again it seems the interesting questions only show up when
>     applying
>
>         > something to the live network...
>
>         >
>
>         > We ran into something that poses a question related to
>     RFC8660: What
>
>         > is the exact meaning of section 2.10.1, "Forwarding for PUSH
>     and
>
>         > CONTINUE of Global SIDs", when the chosen neighbor doesn't
>     provide a
>
>         > valid MPLS path?
>
>         >
>
>         > The relevant sections reads:
>
>         >
>
>         >       -  Else, if there are other usable next hops, use them
>     to forward
>
>         >          the incoming packet.  The method by which the
>     router "R0"
>
>         >          decides on the possibility of using other next hops
>     is beyond
>
>         >          the scope of this document.  For example, the MCC
>     on "R0" may
>
>         >          chose the send an IPv4 packet without pushing any
>     label to
>
>         >          another next hop.
>
>         >
>
>         > Does the part "send an IPv4 packet without pushing any
>     label" apply to
>
>         > PUSH and CONTINUE, or just to PUSH?
>
>         > Does R0 have to validate that neighbor N can correctly
>     process to
>
>         > packet? Or can it forward the packet regardless?
>
>         >
>
>         > The reason for asking is that we are now seeing issues
>     similar to ones
>
>         > we had when starting with LDP based MPLS about two decades ago:
>
>         > traffic being black holed even though a path to the destination
>
>         > exists, because the MPLS path is interrupted somewhere in
>     the middle.
>
>         >
>
>         > With LDP we know the case of LFIBentries called
>     "unlabelled". While
>
>         > this does break connectivity for many kinds of service, e.g.
>     those
>
>         > relying on an additional service labels, it still works for
>     plain
>
>         > IP(v4) traffic. In our cases, this works perfectly fine for all
>
>         > internal routing and control traffic. And even for IPv4
>     traffic that
>
>         > gets collected by a central router that injects a default route.
>
>         >
>
>         > However, depending on the exact interpretation of the above
>     paragraph,
>
>         > an implementor might feel obliged to chose the next paragraph:
>
>         >
>
>         >       -  Otherwise, drop the packet.
>
>         >
>
>         > Which is, at least in our case, very unfortunate...
>
>         >
>
>         > Any advice or opinion appreciated!
>
>         >
>
>         >
>
>         > Best regards, Martin
>
>         >
>
>         >
>
>         >
>
>         >
>
>         > _______________________________________________
>
>         > spring mailing list
>
>         > [email-masked] <mailto:[email-masked]>
>
>         > https://www.ietf.org/mailman/listinfo/spring
>
>
>
>     [email-masked] <mailto:[email-masked]>
>
>     [email-masked] <mailto:[email-masked]>
>
> -- 
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> /Network Solutions A//rchitect /
>
> /M 301 502-1347
> 13101 Columbia Pike
> /Silver Spring, MD
>
>

---

From: Martin Horneffer <[email-masked]>
Date: Fri, 4 Sep 2020 17:03:59 +0200

Hi Jakob,

the security consideration is a good one.
However I am not asking for more than LDP used to do for decades.
An MPLS backbone needs to make sure that MPLS packets are not accepted 
from untrusted neighbors.

Best regards, Martin

Am 28.08.20 um 20:31 schrieb Jakob Heitz (jheitz):
> It all hinges on "useable next hops". If the connected next hop
> (a bgp next hop may not be connected) has a correct route for the
> packet, then it is useable.
>
> One more consideration: With the BGP free core, external devices
> cannot send packets to your internal routers. Once you allow to
> forward packets without a labelled route, you need to make sure that
> this protection remains.
>
> Regards,
> Jakob.
>
> -----Original Message-----
> From: spring <[email-masked]> On Behalf Of Martin Horneffer
> Sent: Thursday, August 27, 2020 3:35 AM
> To: [email-masked]
> Subject: [spring] to drop or to forward unlabelled (Re: Question on RFC8660)
>
> Hello everyone,
>

---

From: <[email-masked]>
Date: Fri, 4 Sep 2020 15:49:24 +0000

Hi Martin,

> From: spring [mailto:[email-masked]] On Behalf Of Martin
> Horneffer
> 
> Hello everyone,
> 

Speaking as an individual contributor, my reading of RFC 8660 (SR-MPLS) is that the packet is dropped ("Otherwise, drop the packet").
https://www.rfc-editor.org/rfc/rfc8660.html#name-forwarding-for-push-and-con

However that could be seen as a local behavior, hence possibly configurable.

As a network operator, 
- I understand your use case.
- I equally understand the use case of someone preferring/requiring the packet to be dropped, e.g. in the VPN case where the isolation is the main requirement.

Best regards,
--Bruno

> > Any advice or opinion appreciated!

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 4 Sep 2020 23:02:17 -0400

Hi Martin

Yes MPLS has definitely been a learning curve for operators as especially
with LDP-IGP sync, session protection and RLFA LDP tunnel in failure
scenarios.

In that context of the dropped question with LDP-IGP sync on unlabeled FEC
the packets would not get dropped and would take a different path until the
unset of maximum metric occurred after LDP came up.

Thanks

Gyan

On Fri, Sep 4, 2020 at 11:01 AM Martin Horneffer <[email-masked]> wrote:

>
>
>
>
>
>
>
>
>
>
> Hi Gyan,
>
>
>
>
>
> we had this kind of issue since the rise of LDP and the invention of
>
> the BGP free core. In a larger network, every now and then.
>
>
>
>
>
> Some years later the notions of setting up targeted LDP sessions
>
> solved some part of the issue.
>
>
> Some more years later, IGP-LDP synchronization indeed solved a big
>
> part of the issue in a more elegant way.
>
>
> Am 30.08.20 um 16:21 schrieb Gyan
>
> Mishra:
>
>
>
>
>
>
>
>
>
>
>
>
>
> Hi Martin
>
>
>
>
>
>
>
> That is a very common scenario that occurs where
>
> one path where LDP neighbor has lost its label binding for FEC
>
> destinations.
>
>
>
>
>
>
>
> Most providers don’t label all prefixes and only
>
> label interesting traffic meaning FEC destination which is the
>
> egress endpoint loopback iBGP peers for an LSP.
>
>
>
>
>
>
>
> So their is an ACL that is used for label
>
> allocation, label advertisement and label accept policy to
>
> created the label binding LIB and and Label forwarding table
>
> LFIB.
>
>
>
>
>
>
>
> So the LSP is built from ingress PE to egress PE
>
> and the label mapping along the path occurs downstream
>
> unsolicited in the opposite direction of the LSP via label
>
> mapping message from the egress PE that the LSP is being built
>
> to - to the ingress PE from the downstream node to the upstream
>
> node.
>
>
>
>
>
>
>
> Most operators have a BGP free and PIM free core
>
> and usually don’t dual stack the core and the concept of
>
> softwire mesh framework RFC 5565 so 6to4 softwire would be v6
>
> edge over a v4 core or v4 edge over a v6 core.
>
>
>
>
>
>
>
> So with the BGP free core all PE are BGP route
>
> reflector clients and have a peer to RRs that sit in the P
>
> core.
>
>
>
>
>
>
>
> The P core is BGP free so only runs an IGP ISIS PE
>
> OSPF.  This point is critical and that is that since the core is
>
> BGP free it can not perform L3 forwarding so all packets must be
>
> L2.5 label switched via topmost label either LDP or RSVP or
>
> SR-TE.
>
>
>
>
>
>
>
> So now that we have established the core construct
>
> let’s dig into the problem with the label mapping being broken
>
> on a node along a path.
>
>
>
>
>
>
>
> So with LDPv4 or LDPv6 or SR-MPLS we have a
>
> concept called “ldp-IGP” synchronization.  SR-MPLS uses IGP sync
>
> for SR sid labels as well since SR is reusing the MPLS data
>
> plane.
>
>
>
>
>
>
>
> So on all MPLS core enabled interfaces on both PE
>
> and P LDP sync is enabled.
>
>
>
>
>
>
>
> So the goal of ldp-IGP sync is to prevent black
>
> hole of packets on MPLS interfaces cause by MPLS LDP failure and
>
> so how it works is the IGP prefix that needs to build a label
>
> binding for FEC destination for label swapping to occurs in the
>
> core so the IGP must not come up and forward traffic along the
>
> path until MPLS is up or traffic will be “black holed” and
>
> dropped.  So how this is accomplished is the IGP sets the prefix
>
> metric to maximum 65535 for ospf and ISIS wide metric does the
>
> same so the path now cannot be utilized until ldp comes up and
>
> the label binding message is received via downstream unsolicited
>
> to create outgoing label for the LFIB entry.  Once LDP is up and
>
> the LFIB entry outing label is populated the IGP prefix is
>
> “unset” so now is set to its normal IGP metric and traffic can
>
> now flow over the path.
>
>
>
>
>
>
>
> For LDP troubleshooting first you have to see if
>
> discovery link LDP is up on the interface and then have to check
>
> if both Ldp adjacencent nodes have a route in rib for each
>
> other’s LDP router id for the ldp neighbor to come UP and label
>
> mapping message to be sent.  As you mentioned if their is
>
> summarization for FEC which results in a loop the binding does
>
> not get built for the FEC resulting in unlabeled FECs in the
>
> LFIB.
>
>
>
>
>
>
>
> On Sat, Aug 29, 2020 at 8:37
>
> PM Tarek Saad <[email-masked]> wrote:
>
>
>
>
> Hi
>>
>> Martin,
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> <[email-masked] on
>>
>> behalf of [email-masked]> wrote:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>     Hello everyone,
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>     may I come back the the question below? Or rather let me
>>
>> update it a little:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>     In case an SR-MPLS path is broken, should a node rather
>>
>> drop the packet,
>>
>>
>>
>>
>>
>>     or forward it?
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>     This can happen whenever the IGP points to a certain
>>
>> next hop, but that
>>
>>
>>
>>
>>
>>     neither supplies a valid SID, nor allows LDP-stitching
>>
>> for whatever
>>
>>
>>
>>
>>
>>     We have been using MPLS transport and a BGP free core
>>
>> since about two
>>
>>
>>
>>
>>
>>     decades now, using LDP. In the analog case, LDP creates
>>
>> "unlabelled"
>>
>>
>>
>>
>>
>>     entries in the LFIB, does the equivalent of a POP
>>
>> operation and forwards
>>
>>
>>
>>
>>
>>     This behavior obviously breaks any traffic that relies
>>
>> on a service
>>
>>
>>
>>
>>
>>     In our case a huge percentage of all traffic still is
>>
>> public IPv4. This
>>
>>
>>
>>
>>
>>     needs MPLS only for a transport label, be it LDP or
>>
>> SR-MPLS. If this
>>
>>
>>
>>
>>
>>     traffic gets forwarded unlabelled, it follows an IGP
>>
>> default route to a
>>
>>
>>
>>
>>
>>     central device, where it is 1) redirected to the correct
>>
>> destination and
>>
>>
>>
>>
>>
>>     2) counted in a way that operators can quickly see
>>
>> whether and where
>>
>>
>>
>>
>>
>>     this kind of failure occurs at some point in the
>>
>> network.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> [TS]: The SR Path may be composed of multiple SIDs (i.e.
>>
>> label stack) -- where the top SID destination is not the SR
>>
>> Path endpoint.. I sense from "gets forwarded unlabelled " as
>>
>> you will discard the full label stack (?) and forward the
>>
>> packet unlabeled to the central device? Or are you
>>
>> encapsulating the remaining MPLS packet over IP and IP
>>
>> routing packet to the central device to be inspected? In
>>
>> either case, I expect somehow the packet to be ultimately
>>
>> delivered to the original SR Path endpoint/egress?
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>     After more operational experience and several internal
>>
>> discussions we
>>
>>
>>
>>
>>
>>     agreed that we want packets to be forwarded unlabelled
>>
>> rather than
>>
>>
>>
>>
>>
>> [TS]: again, I'm not clear on when you say "forward
>>
>> unlabelled" - do you mean packets will follow the top SID's
>>
>> the IP IGP route? Or are you peaking into the destination IP
>>
>> (public IPv4) of packet encapsulated in MPLS to determine
>>
>> how to forward it?
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Regards,
>>
>>
>>
>>
>>
>> Tarek
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>     Best regards, Martin
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>     > again it seems the interesting questions only show
>>
>> up when applying
>>
>>
>>
>>
>>
>>     > We ran into something that poses a question related
>>
>> to RFC8660: What
>>
>>
>>
>>
>>
>>     > is the exact meaning of section 2.10.1, "Forwarding
>>
>> for PUSH and
>>
>>
>>
>>
>>
>>     > CONTINUE of Global SIDs", when the chosen neighbor
>>
>> doesn't provide a
>>
>>
>>
>>
>>
>>     > valid MPLS path?
>>
>>
>>
>>
>>
>>     >
>>
>>
>>
>>
>>
>>     >       -  Else, if there are other usable next hops,
>>
>> use them to forward
>>
>>
>>
>>
>>
>>     >          the incoming packet.  The method by which
>>
>> the router "R0"
>>
>>
>>
>>
>>
>>     >          decides on the possibility of using other
>>
>> next hops is beyond
>>
>>
>>
>>
>>
>>     >          the scope of this document.  For example,
>>
>> the MCC on "R0" may
>>
>>
>>
>>
>>
>>     >          chose the send an IPv4 packet without
>>
>> pushing any label to
>>
>>
>>
>>
>>
>>     >          another next hop.
>>
>>
>>
>>
>>
>>     >
>>
>>
>>
>>
>>
>>     > Does the part "send an IPv4 packet without pushing
>>
>> any label" apply to
>>
>>
>>
>>
>>
>>     > Does R0 have to validate that neighbor N can
>>
>> correctly process to
>>
>>
>>
>>
>>
>>     > The reason for asking is that we are now seeing
>>
>> issues similar to ones
>>
>>
>>
>>
>>
>>     > we had when starting with LDP based MPLS about two
>>
>> decades ago:
>>
>>
>>
>>
>>
>>     > traffic being black holed even though a path to the
>>
>> destination
>>
>>
>>
>>
>>
>>     > exists, because the MPLS path is interrupted
>>
>> somewhere in the middle.
>>
>>
>>
>>
>>
>>     >
>>
>>
>>
>>
>>
>>     > With LDP we know the case of LFIBentries called
>>
>> "unlabelled". While
>>
>>
>>
>>
>>
>>     > this does break connectivity for many kinds of
>>
>> service, e.g. those
>>
>>
>>
>>
>>
>>     > relying on an additional service labels, it still
>>
>> works for plain
>>
>>
>>
>>
>>
>>     > IP(v4) traffic. In our cases, this works perfectly
>>
>> fine for all
>>
>>
>>
>>
>>
>>     > internal routing and control traffic. And even for
>>
>> IPv4 traffic that
>>
>>
>>
>>
>>
>>     > gets collected by a central router that injects a
>>
>> default route.
>>
>>
>>
>>
>>
>>     >
>>
>>
>>
>>
>>
>>     > However, depending on the exact interpretation of
>>
>> the above paragraph,
>>
>>
>>
>>
>>
>>     > an implementor might feel obliged to chose the next
>>
>> paragraph:
>>
>>
>>
>>
>>
>>     >
>>
>>
>>
>>
>>
> *Network Solutions A**rchitect *
>
>
>
>
>
>
>
>
> *M 301 502-1347 13101 Columbia Pike
> <https://www.google.com/maps/search/13101+Columbia+Pike%C2%A0+%0D%0A+++++++++++++++++++++++++++++Silver+Spring,+MD?entry=gmail&source=g>
> <https://www.google.com/maps/search/13101+Columbia+Pike%C2%A0+%0D%0A+++++++++++++++++++++++++++++Silver+Spring,+MD?entry=gmail&source=g>*Silver
> Spring, MD
> <https://www.google.com/maps/search/13101+Columbia+Pike%C2%A0+%0D%0A+++++++++++++++++++++++++++++Silver+Spring,+MD?entry=gmail&source=g>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> --

*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD

---

From: Jeff Tantsura <[email-masked]>
Date: Wed, 9 Sep 2020 10:38:12 +0200

I’m with Bruno here, and the spec is quite clear on the behavior expected (implementors, please speak up).
Given variability and interdependencies in use cases, I’d say, drop should be (and de-jure it is) the default behavior, and if someone wants their vendor of choice to implement a knob to change that - they are free to do so (local behavior) as long as consequences are well understood (rope is short).

Cheers,
Jeff

> On Sep 4, 2020, at 17:49, [email-masked] wrote:
> 
> Hi Martin,
>

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 12 Sep 2020 02:28:00 -0400

Jeff

I am in agreement that drop should be the default behavior in this case
where ldp is broken and unable to forward due to unlabeled fec.

As of the last many years most vendors and best practice of any MPLS
implementations is to have knobs to change the default behavior.  That
being said you won’t encounter the default unlabeled drop
behavior now as operators had early on with MPLS 20+ years ago.  With the
maturity of any technology comes with hard knocks and learning curves that
in order for MPLS to work without customer impact you have to implement
these knobs.

Kind Regards

Gyan

On Wed, Sep 9, 2020 at 4:38 AM Jeff Tantsura <[email-masked]>
wrote:

> Given variability and interdependencies in use cases, I’d say, drop should
> be (and de-jure it is) the default behavior, and if someone wants their
> vendor of choice to implement a knob to change that - they are free to do
> so (local behavior) as long as consequences are well understood (rope is
> short).
>
>
>
> Cheers,
>
> Jeff
>
>
>
> > Speaking as an individual contributor, my reading of RFC 8660 (SR-MPLS)
> is that the packet is dropped ("Otherwise, drop the packet").
>
> >
> > - I equally understand the use case of someone preferring/requiring the
> packet to be dropped, e.g. in the VPN case where the isolation is the main
> requirement.
>
> >
>
> > Best regards,
>
> > --Bruno
>
> >
>
> >
>
> > Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
>
> > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
> recu ce message par erreur, veuillez le signaler
>
> > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
>
> > This message and its attachments may contain confidential or privileged
> information that may be protected by law;
>

*Gyan Mishra*

---

From: Martin Horneffer <[email-masked]>
Date: Wed, 16 Sep 2020 16:41:56 +0200

Hi Jeff,

actually the paragraph just before "Otherwise, drop the packet" reads:

  * Else, if there are other usable next hops, use them to forward the
    incoming packet. The method by which the router "R0" decides on the
    possibility of using other next hops is beyond the scope of this
    document. For example, the MCC on "R0" may chose the send an IPv4
    packet without pushing any label to another next hop.

To me this doesn't really make clear which behaviour is expected.

As Jakob suggested, it depends on the exact understanding of "usable 
next hops".

In my opinion a plain IGP next hop is usable. At least for the BoS case, 
if you want to look at it.

Best regards, Martin