Re: [Idr] draft-ietf-idr-te-lsp-distribution questions

Gyan Mishra <> Fri, 20 January 2023 03:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BD335C14F737 for <>; Thu, 19 Jan 2023 19:56:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.085
X-Spam-Status: No, score=-2.085 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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8BFyyfelaZdU for <>; Thu, 19 Jan 2023 19:55:58 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::f2e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 9AA69C14E514 for <>; Thu, 19 Jan 2023 19:55:58 -0800 (PST)
Received: by with SMTP id k12so3042400qvj.5 for <>; Thu, 19 Jan 2023 19:55:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=N2ldn0UMqzdksNqOIwhrf0bdVxP5EaXodXKuKI/v6os=; b=p7LpL7W1uMqXNn/i6opCl5Li5VdkK8aSN9xkFp/o/75Ac8vgSFupN2EnfiVJdUttra eoXMraBIRRHd8ciWhaSOr0/1+xigyNP1foM6BXb0rJPZnvzQKuklOyBwZNQTRf/Y4p+C j5py9VgAdHsRYApN/nlr5cxiNlPo+QvAReNUjOGKXgr2JevJWnfUE/4N/b3Hpb4Slfih zPY4uFvHFKZbXYmgVl7P58qCBNdHEqTyURlEJQGY/wmFU5kCuxEDVnytvvv/DEdrLvLH 4mXZJbMcY1sxG4Clx0CHIaVBRm9nqFgVkxtPbkLPNuK1LWhpg0xAf9teoo+mgEF/KnwK /yLA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=N2ldn0UMqzdksNqOIwhrf0bdVxP5EaXodXKuKI/v6os=; b=VgarzInaVDuwszwxgqQ3rcTjxvDhSy8B0X/SqFAXVPv6XVk0gD9SN6L2MnJOe9pI9g ueGrYPnqSH2zHj4i2TUxjISWh00AFD31Zx/P7UygY7bPuPSd09av4dMSIfWTwUrCkxlr z+5JBeAgVNBu4PIsbpGU5YtwL+AptSP/u8wOF9UGCHCL+T6FA+I4j1F1Xv2qGxyTYqFB +RYj7J9VnfI53wn5wWbASPPwzxR8YHnP5PPQ+Ua8x4w52jKaDWnkhExcGzZ1PQqZNEtc tTB/1ixUSR5S00sxWXd30dIAlSuDs1c7Dg2+FCYzvet7NdXkwdZK5Vtx+AGyK3+pYiKN kMVg==
X-Gm-Message-State: AFqh2kqiECqmGwHbP52BgqPeKAzFJDdXzUx9TduQ4MDXmny3eBkzaNdh RHkkKWIUFoRKSEhDc07b7tIGK0R6ojWMVNbjknJ0fkvgBog=
X-Google-Smtp-Source: AMrXdXsbh6I2RQo/J8YdZ5adARzt4fEp6T9MKyzdOfOn38Ma82mTP3LFW181QMnLg9ciks9y1PmUYBzjW9CQaQiX4u0=
X-Received: by 2002:ad4:4532:0:b0:534:1ea7:5c27 with SMTP id l18-20020ad44532000000b005341ea75c27mr515718qvu.62.1674186957412; Thu, 19 Jan 2023 19:55:57 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Gyan Mishra <>
Date: Thu, 19 Jan 2023 22:55:46 -0500
Message-ID: <>
To: "Jeffrey (Zhaohui) Zhang" <>
Cc: "idr@ietf. org" <>
Content-Type: multipart/alternative; boundary="000000000000e2603405f2aa068a"
Archived-At: <>
Subject: Re: [Idr] draft-ietf-idr-te-lsp-distribution questions
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 20 Jan 2023 03:56:02 -0000

Hi Jeffrey

I read the draft as well and I agree with you that it is primarily goal is
to coalesce all the characteristics of RSVP-TE and SR Policy into new
BGP-LS TLVs to collect to build a network visualization of a domain wide
multi area or AS view for stateful path computation and instantiation by
means other than centralized PCE.  I agree also the goal is to collect the
multicast related RSVP-TE or SR P2MP policy using the cross connect
interfaces TLVs.

I agree with your recommendations for enhancements mentioned to support
multicast.  Makes sense.

Overall I think the draft is very useful as SR policy can be complicated
and  building the data structures and transporting to a single painted
glass NMS station or controller is a great idea.

Dear Authors

Few comments on the draft.

I noticed the metric type - IGP, latency, TE, hop count is missing

Also noticed Flex Algo constraint missing

Also static SID list weight for UCMP should be added

Maybe ODN and automated steering color and colorless policy should be added

Also I think SRv6 compression draft C-SID should be added.

I think maybe MPLS and Spring path Segment should be included.

SRv6 path Segment

SR-MPLS path Segment

BIDIR path Segment

Possibly SR-PM monitoring policy so that tracking data monitoring of SR
policy endpoints within the policy can now be monitored by external

Kind Regards


On Wed, Jan 18, 2023 at 9:01 AM Jeffrey (Zhaohui) Zhang <zzhang=> wrote:

> Hi,
> I have some questions on this draft.
> It apparently is TE-specific (RSVP-TE or SR policy) and unicast-specific.
> While it mentions multicast in the cross-connect case, it is not clear how
> multicast state is reported. For example, if a node needs to replicate to
> 10 branches, would there be 10 cross-connect NLRIs used, each for a
> replication branch? If so, what is the use case of multiple outgoing
> interfaces?
> Also, is the cross-connect NLRI intended only for locally "configured"
> (vs. signaled by RSVP-TE), as implied by the following text?
>    In many network environments, traffic engineering (TE) policies are
>    instantiated into various forms:
>    *  MPLS Traffic Engineering Label Switched Paths (TE-LSPs).
>    *  Segment Routing (SR) Policies as defined in [RFC9256]
>    *  Local MPLS cross-connect *configuration*   <------
> Relatedly, are the TE-LSP and SR policy NLRI intended for headend only
> (and not used to report RSVP-TE state on transit-nodes)?
> Consider the following two use cases:
> - Hop-by-hop signaled mLDP trees are used in a network but the operator
> wants state on the tree nodes to be reported to a controller for
> display/visualization purpose.
> - A PCE signals SR-P2MP trees via BGP and it needs confirmation from tree
> nodes that replication state has been set up as signaled.
> I had initially thought that the cross-connect NLRI can be used for that,
> but looks like quite some enhancements would be needed:
> - make the draft applicable to non-TE as well
> - make the cross-connect NLRI applicable to beyond local configuration
> - add attribute to the cross-connect to indicate tree information (e.g.
> mLDP FEC, RSVP session object)
> Alternatively, make the TE-LSP and SR policy NLRI applicable to transit
> nodes as well and report the cross-connect information as attribute.
> If this makes sense, do we want to extend the existing draft or should I
> start a new draft?
> Thanks.
> Jeffrey
> Juniper Business Use Only
> _______________________________________________
> Idr mailing list


*Gyan Mishra*

*Network Solutions A**rchitect *

*Email <>*

*M 301 502-1347*