Re: [spring] to drop or to forward unlabelled (Re: Question on RFC8660)
Gyan Mishra <hayabusagsm@gmail.com> Sat, 05 September 2020 03:02 UTC
Return-Path: <hayabusagsm@gmail.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49ABB3A1127 for <spring@ietfa.amsl.com>; Fri, 4 Sep 2020 20:02:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Level:
X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y-QHOwi2L5TB for <spring@ietfa.amsl.com>; Fri, 4 Sep 2020 20:02:29 -0700 (PDT)
Received: from mail-vs1-xe31.google.com (mail-vs1-xe31.google.com [IPv6:2607:f8b0:4864:20::e31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA46F3A1123 for <spring@ietf.org>; Fri, 4 Sep 2020 20:02:28 -0700 (PDT)
Received: by mail-vs1-xe31.google.com with SMTP id q13so4657379vsj.13 for <spring@ietf.org>; Fri, 04 Sep 2020 20:02:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gLu7RzL7sSLUQyfsptZ66aVeJjYhilVDaxEDIJwubvY=; b=fFRgOGD1EXC9uzodbp0jQxgZvWLD+HQv6fCnOD4TwtXt5sjN7sAPNJCqJJL4f4BelX ObUv2ovymXADm55bure1w/lJxFavtqUqgsSf4B5tq9wBg0RUMajzbmSFelUj/CQPLgWt Hx0kOY+GegmEBQZAh0Da4Z/GwulBOCAH2sZz0kB8ah+NP1QYWcEx81FmsxOYJRV/oraF vqAcoTVgKvFVJVZm5bauW9r31e6Yv5J01jKXUN42DcHlrgfjlahKOcjrhilHJoTo1pzB BVLOQ6c8yjHZl0XjDeadirN8yUtlPLyGSbU3N2dsJ73W2uCyxxAd1donfRQvrRq68fSY PQow==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gLu7RzL7sSLUQyfsptZ66aVeJjYhilVDaxEDIJwubvY=; b=dSaPrumKt8Xr8EhQxSIhD5Dc16qk6FfB9cj9R6rrs6p1XNab5RN4RHkwA15K/HygXt tJDjcACxZNrBCFSUZBNJdHVwizZ9uo9UBJrb2Trky3QGPcpnRn4MqVR3U8MeKE3Fknfn TUMQccAl0isS9JVBFPXsPU4MlrNiY7R44TkDTvpFld/eLMT9BGe/ZACOCpZbQolYzrif hgqIJlLOmvFsR4QlMvK0u2BSWAmgYO/ycxk9tlFM768D1lyogvYRhxMSbraCUN3WF8he wxkHRGKUCfc8JMjiaepE24f+Wy7mHQBqj282hbqavsl0R8m44Fy/Dt/OSmfgwCUDejJz VAVg==
X-Gm-Message-State: AOAM5309CMWPcvCXZ4VR8cGqdaxZ2PBbf+iEOAlv3F7Skphz4iMoPgOw 8je33kkvZHCCieoYRUNIgz6OhlNiSwcEQxnC94L03VSJanQ=
X-Google-Smtp-Source: ABdhPJxnBo3HzfDM4oDximQqcQJQb23vrJwUP+w48rVCY908IwSoiAQ22pFnQejc0mnEK6gR2LhYFiAvrl5qNHjFGvs=
X-Received: by 2002:a67:ea92:: with SMTP id f18mr7154302vso.117.1599274947873; Fri, 04 Sep 2020 20:02:27 -0700 (PDT)
MIME-Version: 1.0
References: <15389fb7-d7d5-2f28-2869-4ee9fb84fccb@lab.dtag.de> <52be9fc3-0764-93ec-9dca-64291f2f62ab@lab.dtag.de> <DM5PR1901MB21503856C598C1BCC0B931B3FC500@DM5PR1901MB2150.namprd19.prod.outlook.com> <CABNhwV2CpMmaiCN9wKMc9pK2dL+W=KwBUvpb4saz9GXDNLzJ=Q@mail.gmail.com> <5f07d1ae-cdc3-7b8b-4bf7-6e7ba97a7669@lab.dtag.de>
In-Reply-To: <5f07d1ae-cdc3-7b8b-4bf7-6e7ba97a7669@lab.dtag.de>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Fri, 04 Sep 2020 23:02:17 -0400
Message-ID: <CABNhwV1pEWO+hZGpM4B7zfiUatx8j-RWU1F=TwVZX-i6qKgj9Q@mail.gmail.com>
To: Martin Horneffer <maho@lab.dtag.de>
Cc: Tarek Saad <tsaad.net@gmail.com>, "spring@ietf.org" <spring@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000002a932005ae88377d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/rIiLHqQEUM1At4aI-sfxkNptV58>
Subject: Re: [spring] to drop or to forward unlabelled (Re: Question on RFC8660)
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 05 Sep 2020 03:02:32 -0000
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 <maho@lab.dtag.de> 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. > > > 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 <tsaad.net@gmail.com> wrote: > > > > > Hi >> >> Martin, >> >> >> >> >> >> >> >> >> >> >> >> See inline for some comments. >> >> >> >> >> >> >> >> >> >> >> >> On 8/27/20, 6:35 AM, "spring on behalf of Martin Horneffer" >> >> <spring-bounces@ietf.org on >> >> behalf of maho@lab.dtag.de> 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 >> >> >> >> >> >> > spring@ietf.org >> >> >> >> >> >> > https://www.ietf.org/mailman/listinfo/spring >> >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> >> >> >> >> spring mailing list >> >> >> >> >> >> spring@ietf.org >> >> >> >> >> >> https://www.ietf.org/mailman/listinfo/spring >> >> >> >> >> >> _______________________________________________ >> >> >> >> >> >> spring mailing list >> >> >> >> >> >> spring@ietf.org >> >> >> >> >> >> https://www.ietf.org/mailman/listinfo/spring >> >> >> >> >> >> > > > > > > -- > > > > > > > > > > > > > > > > > > > > > <http://www.verizon.com/> > > > > > > > *Gyan Mishra* > > > *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> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD
- [spring] Question on RFC8660 Martin Horneffer
- [spring] to drop or to forward unlabelled (Re: Qu… Martin Horneffer
- Re: [spring] to drop or to forward unlabelled (Re… Ketan Talaulikar (ketant)
- Re: [spring] to drop or to forward unlabelled (Re… Robert Raszuk
- Re: [spring] to drop or to forward unlabelled (Re… peng.shaofu
- Re: [spring] to drop or to forward unlabelled (Re… Martin Horneffer
- Re: [spring] to drop or to forward unlabelled (Re… Martin Horneffer
- Re: [spring] to drop or to forward unlabelled (Re… Jakob Heitz (jheitz)
- Re: [spring] to drop or to forward unlabelled (Re… Tarek Saad
- Re: [spring] to drop or to forward unlabelled (Re… Gyan Mishra
- Re: [spring] to drop or to forward unlabelled (Re… Martin Horneffer
- Re: [spring] to drop or to forward unlabelled (Re… Martin Horneffer
- Re: [spring] to drop or to forward unlabelled (Re… Martin Horneffer
- Re: [spring] to drop or to forward unlabelled (Re… bruno.decraene
- Re: [spring] to drop or to forward unlabelled (Re… Gyan Mishra
- Re: [spring] to drop or to forward unlabelled (Re… Jeff Tantsura
- Re: [spring] to drop or to forward unlabelled (Re… Gyan Mishra
- Re: [spring] to drop or to forward unlabelled (Re… Martin Horneffer