Re: [Lsr] [spring] Concerns with draft-chunduri-lsr-isis-preferred-path-routing

Uma Chunduri <> Tue, 17 July 2018 18:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 781EC130E4C; Tue, 17 Jul 2018 11:40:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xfCRDRoGl2v2; Tue, 17 Jul 2018 11:40:07 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7D9E0130E2A; Tue, 17 Jul 2018 11:40:07 -0700 (PDT)
Received: by with SMTP id 139-v6so750712ywg.12; Tue, 17 Jul 2018 11:40:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+ZrbV0DmGQAq8/RlMpSVTNuZDon7ipCqPGKe+3l+eCM=; b=aLrl03SK3k0H6srjxhm9Zg2qblX18ZST0F7wpv0vTloTUReWq09bf+sLH7uL+KcJnV xvq/lFe62zxrQmDlhOSzNJ7gXMNMkpV4n0CMbnWBwcBpRRZzAtOVIZq4Dl/0ky/iFohH wQjJaLBuIX0Mi8Dnk8QNryKjKBQ3MZ/6TaBDR8y6sFdCBR3w/cUek2ESvQ/HBzx0gDBq xR6Qb2yISbm0LWW6t+l3x95ENlJ8grioKcpy8Q2lKkdUvgo7uQHJH3lTX1CLCYXWRR3D bY+h4p5ZrrURdj1R6B5/nWZdjESLYyYoXseht5YJ+rekti0pLpAUYej/J6jm2eeMeWmd t6ug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+ZrbV0DmGQAq8/RlMpSVTNuZDon7ipCqPGKe+3l+eCM=; b=ccbZ5P16To8bILNRSl+QJ8HyRsByFAy0ZqR4v393H+KqoJRU1B56iU7jmp4tdvPyHO q0QKqSMgNAggjFeksAS3XrD2LRGnS1DTp/XAYV98pJ+qkx2Ppk/QNeWklEcqnZhwwVe6 UMI9p67KYPePCKF5cT0njaWHZN+1wbQaExj2g7zfTlTkDF9zmDgSbTN/JRUOpGIiqV6L zHDYyidktQkPwv2TMPEtDJp1pLW7UKn2Gfy3GnTeGJtIwP2/eiGalVNnvJTngD8n0oOy nWh9UILRpEzgiY3UO0S2a6n7pBkoH48Y3JzfAcjfEZF71ijTI5d8jwPw/FcR7kjEliaU PK4w==
X-Gm-Message-State: AOUpUlHUq/Jcar/gtRDcBnMbeq3TYrkWhdV5jVEbuvhZH9PFjjNeHWnj Yd2oHZhslHFpzBftE3TLwpMGAYlnMiBOysr4A/D8bA==
X-Google-Smtp-Source: AAOMgpf3M2+x8Rco0evQyrm9VNc4gqTF7YMf0cc9obgDaWpcnB75nZMD413vE7NZuzbnrMEosgz/CUQHzz/Hc9keTsw=
X-Received: by 2002:a81:e548:: with SMTP id c8-v6mr1496973ywm.153.1531852806562; Tue, 17 Jul 2018 11:40:06 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a81:4849:0:0:0:0:0 with HTTP; Tue, 17 Jul 2018 11:40:06 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
From: Uma Chunduri <>
Date: Tue, 17 Jul 2018 14:40:06 -0400
Message-ID: <>
To: "Ketan Talaulikar (ketant)" <>
Cc: Uma Chunduri <>, "" <>, "" <>
Content-Type: multipart/alternative; boundary="0000000000006228c3057136463f"
Archived-At: <>
Subject: Re: [Lsr] [spring] Concerns with draft-chunduri-lsr-isis-preferred-path-routing
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Link State Routing Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 17 Jul 2018 18:40:10 -0000

                > [Uma]:  This helps in deployments, who is seeking source
routing paradigm, but SID stack on the packet is unsustainable. This
statement is applicable for both MPLS and IPv6 case.

                >[KT] Could we look at why the SID stack is getting
"unsustainable" in the first place?

I am not sure what you want to look - plz don't ask topology of a
particular deployment and how the SRH/SR-MPLS path is crafted?

Please see the generic example and some of the references in the draft.  You
have to tell me the issues summarized for various deployments (including
brownfield scenarios) are not an issue.

If this is not an issue there is no need for MSD capability either and all
the hoops to discover this capability and work around. I don't think you  can
definitely say, you can limit X SR SIDs in SRH and Y labels etc..

                 >[KT] Dave's argument was in multicast context while he
was giving the p2p example perhaps as a worst case theoretical example.
IMHO we should not look at such worst case scenarios.

                 >To me, this is a hybrid proposal to bring a hop by hop
path (which is why the SID stack is so huge) like in RSVP-TE into an SR
network and then try to figure out a way to do this in IGPs. You can feel
free to disagree :-)

This is not the worst case scenario (I just referred to the thread overall
and discussion of adding a FIB entry is considered OK and being argued it
is not OK stating that as considered as  "state" - I feel at some level we
are confusing with this and the soft state and refresh required thereof );
it could be the base scenario, depending on the deployment.


Uma C.