Re: [Idr] BGP Classful Transport Planes

Gyan Mishra <hayabusagsm@gmail.com> Tue, 20 October 2020 15:00 UTC

Return-Path: <hayabusagsm@gmail.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E66D33A1174 for <idr@ietfa.amsl.com>; Tue, 20 Oct 2020 08:00:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.986
X-Spam-Level:
X-Spam-Status: No, score=-1.986 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, 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, HTTPS_HTTP_MISMATCH=0.1, 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 H9JTQCf0FYyF for <idr@ietfa.amsl.com>; Tue, 20 Oct 2020 08:00:36 -0700 (PDT)
Received: from mail-vk1-xa2f.google.com (mail-vk1-xa2f.google.com [IPv6:2607:f8b0:4864:20::a2f]) (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 A40453A1164 for <idr@ietf.org>; Tue, 20 Oct 2020 08:00:25 -0700 (PDT)
Received: by mail-vk1-xa2f.google.com with SMTP id p5so562916vkm.4 for <idr@ietf.org>; Tue, 20 Oct 2020 08:00:25 -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=4fUjL8kPh6aljp9oxRmqnTu+nrCc7s8e4YCScdxGqPQ=; b=uSjOdOKAWIUQlrmWsjum/2mV7z6BZDGu9EG4BZLAZbHxNTvCmE1mrU5qOfu4Qg15az mlF+zZzJIFzu9BzMooujVxfvmElacJEmsVXdmum1WSudhCkJiZllyDyHtqn8jv5X3jv0 +1iPjemwL7sOT784KXupU8wZkPtwiNjjo4kaCi6v9EYpK2upHK9xzU2J4KAeW75EDt2f 5o6nrjY91Dtc4ndHF8hziCn2rPzMatywlrz5RSNG9fPXlSK3qxk7GHVgbgJ5ERomLY4+ 21aXZWFSz4NJBICDdUUzU8cGjDs0hKV/y60m4JjQN9DzPI+HpUTIKJSCR789nQK5LGnd khyA==
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=4fUjL8kPh6aljp9oxRmqnTu+nrCc7s8e4YCScdxGqPQ=; b=rZmOgS1HqZbDRwfG0VejSI4F6RSHklSr3BcB9QcMUW7r+fb13h6GDMbTNd8NGre1+v 36ORM1iBirxGQk76o5xpuYSbqQdZ/rF6hrasl8XT7jmLA/vQ7Xd613IRGLj5808CHqku 3zsriSjVH+ELMKFrScu+fPmFkeqTor+e7UsYqAJwGSkS01aiidx2NCUFOt5EyHakw4D+ hFMCGqDM7Hkdnj4n7ckQj7/MeuxDwW62pbjXrKstoz34QNiev7lnqZCsKm70rw1iuc3g hIUc350umLBnrGG8Mx4R8f21XyBgZ2xcZ5Y6iPVNZ90SIqMDVT70MEHFUWtJsxPG3pQO BtyQ==
X-Gm-Message-State: AOAM530UCrxU270OLksE5yfZrqtI2NbK9u+6xZ3GpYhZbLgUtvXWDcVe 9cMkjHgrF2ISLVnyXXAyMr+anOu32UTdvyL6Mv7txYEhhtPhwQ==
X-Google-Smtp-Source: ABdhPJzYlZLHGed++8RBqOLOJf/nxtbBColjcXzYdGRGIMlRc44Q18LG+ruUjH9vgmeeYzjr/HONVsZq8rLJLvAlqpY=
X-Received: by 2002:a1f:bd56:: with SMTP id n83mr1945859vkf.5.1603206024377; Tue, 20 Oct 2020 08:00:24 -0700 (PDT)
MIME-Version: 1.0
References: <CAOj+MMEdijdGVMKS3Qf-nabj0gZk+rrf7ygZ1H+6AyvxdP7xuA@mail.gmail.com> <59A888A2-682A-4A36-B80A-CC46DB02D1EA@juniper.net> <CAOj+MME2fY0HT0jKd-mVPgJPyModgwLwexb=XXsKxPxW91yfsw@mail.gmail.com> <CABNhwV0cCm+n0q8tvJuaU9ayhhWrLoFNbfSGogeAM+ecgt3L8A@mail.gmail.com> <BD0F986A-1A85-49E8-9FCA-80D1232B5C3A@juniper.net>
In-Reply-To: <BD0F986A-1A85-49E8-9FCA-80D1232B5C3A@juniper.net>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Tue, 20 Oct 2020 11:00:03 -0400
Message-ID: <CABNhwV3M3VQ8RRHSWofQxyfZykHks74=CKuADEhAVC1ENYikvQ@mail.gmail.com>
To: Kaliraj Vairavakkalai <kaliraj@juniper.net>
Cc: Natrajan Venkataraman <natv@juniper.net>, Robert Raszuk <robert@raszuk.net>, "idr@ietf. org" <idr@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000095bc4205b21b7d82"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/7zKNAr091RYJOkzeL2lHmCIzwkE>
Subject: Re: [Idr] BGP Classful Transport Planes
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Oct 2020 15:00:47 -0000

Hi Kaliraj

In-line

Thanks

Gyan
On Mon, Oct 19, 2020 at 2:06 PM Kaliraj Vairavakkalai <kaliraj@juniper.net>
wrote:

> Hi Gyan,
>
>
>
> No, there is no impact to existing CsC deployments.
>
>
    Gyan> Understood as a new CT RIB is created per new SAFI 76.  So this
draft defines a new SAFI RD/RT that could be used instead of the current
BGP-LU Labeled Unicast rib in global table used for Opt C which would now
be carried in a separate CT RIB within the domain.  Today with service VPN
their is an automatic underpinning with label stack topmost encapsulation
so no recursion with VPN routes.  With BGP LU,  it is has a BGP RIB for
transport prefixes injected between domains as it’s a BGP RIB and not a
separate VRF RIB as being proposed with CT RIB new extended community,  and
so BGP LU sit in the global table so has next hop recursion.  In contrast
the next hop underpinning to topmost label tunnel PNH would be a special
mapping community mapped it sounds like to a primary and failover tunnel or
a set of tunnels  to map CT transport service to underlay tunnel.  This
feature could also be used as stated in the draft with CSC customer carrier
VRF new CT SAFI for the topmost labeled transport prefixes.

Section 4 details the new extended community.  I believe this is a typo as
the CT community would follow RFC 4360 and 5668.  You mention 8 byte RT and
RD but I believe you meant 6 bytes community with new IANA codepoint for
new Hi Order and low Order sub type setting.  I think you would want to
stay with standard type 0 2 byte global 4 byte local for 2 byte AS, type 1
4 byte global 2 byte local for IPv4 Global, end type 2 4 byte global 2 byte
local for 4 byte AS.



> This draft creates a new SAFI that parallels BGP-LU in option-C
> deployments. I will clarify this with an explicit mention to option-C in
> the introduction.
>
>
>
   Gyan> Understood

> The deficiency being addressed is: In today’s option-C deployments, if
> multiple classes(gold, bronze, etc) of tunnels exist to a destination PE1
> in one domain, they can not be extended out to the adjacent domains by
> using BGP-LU, such that service-traffic in those domains is able to choose
> a certain class of tunnel.
>

    Gyan> In general Opt C is not generally used between ASs with operators
in separate administrative domains end to end LSP.  The other down side of
Opt C is the RR-RR eBGP SAFI 128 129 next hop unchanged peering which makes
it impossible to use between operators in separate admin domains.  The last
major issue with Opt C being addressed here is the import of loopbacks
between domains has to be carried in the global table.  So Opt C in general
is used only for M&A or internal inter AS peering where their is a trust
relationship and the loopbacks FECs can be imported between domains.  So
with this SAFI 76 if addresses the loopback import into the global table
issue but does not address the eBGP SAFI 128 129 RR-RR peering for VPN and
MVPN NLRI.  So in this option as the LSP is end to end the next hop self
rewrite is not done in ingress egress NNI inter-as peering as the LSP
builds end to end from ingress PE in domain A to egress PE in domain B.  So
the major advantage of Opt B is that BGP LU is only for connected transport
label on the inter-as peer and no loopbacks are injected between domains
and as next hop self is utilized to terminate each segment of the LSP into
3 segments.  In Opt B the 1st segment is Ingress PE to egress PE domain A,
2nd segment inter as link, 3rd segment ingress PE to egress PE domain B.
So here I don’t see any benefit of using SAFI 76 for Opt B which scales
well.  With both Opt B SAFI 128 and new 76 you would have to do the RT
rewrite as well so no benefit there.  RTC is a RT membership optimization
that can be used     RR-PE only RTs that the PE has membership explicit
import of RT is what is sent to PE.  By default all PEs have RT filtering
enabled by default so if their is not an interesting explicit import of the
RT the RT is dropped.  So RTC is an optimizations for incongruent VPNs on
operator PEs to cut down on flooding of all RTs. So for CT are we changing
the behavior of RTC RFC 4684.  Are we making RTC part of CT architecture
and what is the requirement that it must be used as RTC is only an
optimization.
Also for CSC we here we are changing the VPN rib for customer carrier from
SAFI 128 to 76.  With CSC hierarchical VRFs VPNs the transport prefix in
the customer carrier VRF sit in the separate SAFI 128 RIB and so do the
have the issue as exists with Opt C and you are just shifting from one VPN
to another SAFI 128 to 76.  I still don’t see the benefit.

With this draft overall I do see the benefit with Opt C to assist with the
BGP LU carrying imported loopbacks between domains in the global table but
don’t see benefit in any other inter as solution that exists today.

With SRv6 LPM IPv6 data plane and no BGP-LU and use of SR-TE binding sid
policy inter domain I don’t see any benefit in using SAFI 76.

With SR-MPLS as can use legacy inter as options would have same opt-c
benefit but I think most customers using SR-MPLS would prefer to use SR-TE
binding sid policy instead of MPLS based inter as options.

> The new SAFI 76 carries NLRI of the form RDx:PE1, such that route for each
> class is carried using a distinct RD and doesn’t hide the other classes.
> And a new type of RT is used to denote the transport-class of the tunnel.
> This RT is used to leak the transport-routes into transport-RIBs of the
> same class on the receiving nodes – just like what L3VPN family does.
>
>
>
> The note about similarity with CsC was just that: CsC uses SAFI 128 (L3VN)
> family to carry transport-prefixes in the mother carrier. Similarly, this
> SAFI 76(BGP-CT) also carries transport-routes in option-C deployments.
>
>
>
> Hope that clears the confusion. Thanks for the comments.
>
>
>
> Kaliraj
>
>
>
> *From: *Gyan Mishra <hayabusagsm@gmail.com>
> *Date: *Sunday, October 18, 2020 at 10:52 PM
> *To: *Robert Raszuk <robert@raszuk.net>
> *Cc: *Kaliraj Vairavakkalai <kaliraj@juniper.net>, Natrajan Venkataraman <
> natv@juniper.net>, "idr@ietf. org" <idr@ietf.org>
> *Subject: *Re: [Idr] BGP Classful Transport Planes
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Hi Kaliraj,
>
>
>
> I read the draft and had a few comments.
>
>
>
> This draft creates a new SAFI 76 BGP-CT that parallels BGP-LU that is
> being used to fix a deficiency with CSC as far as the transport label being
> used as customer carrier Hierarchical VRF to the customer carrier customer
> VRF and not in a separate transport rib.
>
>
>
> The framework behind CSC is that the backbone carrier PE runs BGP LU to
> customer carrier CE, and the transport routes are within SAFI 128 Customer
> carrier VRF. The PE-CE backbone to customer carrier must MPLS enabled. The
> Customer Carrier
>
> would have a it’s own hierarchical customer VRFs that would be tunneled
> across the backbone carrier.
>
>
>
> The customer carrier hierarchical VRF to its customers are tunneled over
> the backbone carrier.
>
>
>
> The customer carrier transport routes are in a VRF SAFI 128 and don’t
> touch the backbone carrier global table.  BGP LU is enabled on the eBGP
> connection PE-CE for the transport label binding and is identical to
> inter-as Opt B usage of BGP-LU and then the customer carrier transport
> prefixes  routes sit in SAFI 128 eBGP VPN IPV4 VPN IPV6.
>
>
>
> You mention in the draft inter-as opt B interchangeably with CSC which
> they both are similar but very different.  However, I believe you are
> trying to address deficiencies with only CSC.
>
>
>
> As RFC 4364 CSC had been deployed for years by many carriers and it scales
> very well.  I am trying to understand the issues and gap related to CSC.
>
>
>
> So with this new SAFI the intent is to not have a hierarchical VRF and
> instead this new BGP-CT Transport rib.
>
>
>
> What is the impact to existing CSC deployments using hierarchical VRF.
> How would you address backwards compatibility.
>
>
>
>
>
> Kind Regards
>
>
>
> Gyan
>
>
>
> On Sun, Oct 18, 2020 at 7:39 AM Robert Raszuk <robert@raszuk.net> wrote:
>
> Hi Kaliraj,
>
>
>
> Just a few points as a follow up on your note.
>
>
>
> Ad 1 - The point was that you can carry mapping (or if you will stitching
> information) by extending with new draft encoding defined in
> draft-ietf-idr-tunnel-encaps.
>
>
>
> As you know tunnel SAFI (5512) was deprecated and going forward the
> recommendation is to use a new encap attribute. That is why I suggest you
> consider the use of a new attribute attached to RFC3107 SAFI 4 instead of
> defining new SAFI.
>
>
>
> Ad 2a - You say "it will work" then just a few lines below you admit the
> current draft only addresses MPLS stitching via ASBR/ABRs.
>
>
>
> Ad 2b - All three points on value of MPLS Inter-AS or Inter-area
> stitching are quite questionable even in brownfield deployment. But that's
> not the point to debate any more here. Market will decide.
>
>
>
> Ad 3 - No I was not asking for yet one more abuse of flowspec use case. I
> was not asking for new ACL based mapping to specific VRF either. If your
> draft is about "BGP Classful Transport" it better also define "Classful
> RIB" where forwarding decision is done not only based on destination
> address and its next hop but also on other fields in the packet. That was
> the first thing I was curious to see in your new SAFI definition but there
> is none.
>
>
>
> Ad 4 - I was asking where exactly is the Longest Prefix Match performed ?
> Based on aggregates generated by which network element and which protocol ?
> What set of destinations does the aggregate cover ? Assuming option-C don't
> you still need to leak all /32s or /128s across the domains - or you assume
> RFC5283 is in use ? I think it would help whoever is reviewing this work to
> have an end to end illustration of how each SN/BN/RR hop service route and
> its next hop changes as well as how underlay transport and overlay tunnels
> are advertised at each BN with the use of real IP addresses and labels.
> Even Shraddha's blog post does not go into that level of details.
>
>
>
> Many thx,
> Robert
>
>
>
>
>
>
>
> On Sun, Oct 18, 2020 at 1:47 AM Kaliraj Vairavakkalai <kaliraj@juniper.net>
> wrote:
>
> Hi Robert, thanks for the comments. Please see inline.
>
>
>
> *From: *Robert Raszuk <robert@raszuk.net>
> *Date: *Saturday, October 17, 2020 at 8:30 AM
> *To: *Kaliraj Vairavakkalai <kaliraj@juniper.net>, Natrajan Venkataraman <
> natv@juniper.net>, Balaji Rajagopalan <balajir@juniper.net>
> *Cc: *"idr@ietf. org" <idr@ietf.org>
> *Subject: *BGP Classful Transport Planes
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Hi,
>
>
>
> I have read
> https://tools.ietf.org/html/draft-kaliraj-idr-bgp-classful-transport-planes-01
> <https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-kaliraj-idr-bgp-classful-transport-planes-01__;!!NEt6yMaO-gk!Xg6xfSibwETZhsptdOJv2QL0vVF8WVkztqeHhepYnVCyfQQAMILyPEH9JnXnhQDO$>
>
> and have few questions & observations.
>
>
>
> *1.*
>
>
>
> > A domain boundary is demarcated by a rewrite of BGP nexthop to 'self'
> while
>
> > readvertising tunnel routes in BGP.
>
>
>
> For advertising tunneling in BGP we already have a number of options.
> Starting from RFC5512 through draft-ietf-idr-tunnel-encaps-19 or
> https://tools.ietf.org/html/draft-ietf-intarea-tunnels-10
> <https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-intarea-tunnels-10__;!!NEt6yMaO-gk!Xg6xfSibwETZhsptdOJv2QL0vVF8WVkztqeHhepYnVCyfQQAMILyPEH9Jl8x4R7Q$>
>
>
>
> Q: Do we really need more signalling extensions instead of working with
> existing protocols to accommodate new applications ?
>
>
>
> This is not an extension parallel to TEA. The above para means to say,
> when BGP speaker does nexthop-self on a advertised transport-route, the
> details of the intra-domain tunnel used in the advertising-domain is hidden
> from the BGP-speaker in the other domain receiving the route. Because it
> sees as nexthop only the advertising BGP-speaker.
>
>
>
> Such nexthop-self happens in
>
> ·   option-B VPNs, at the Service-ASBRs  (BGP-L3VPN families)
>
> ·   option-C VPNs, at the Transport-ASBRs or BGP ABRs (BGP-LU and BGP-CT
> are examples of this)
>
>
>
> So this act of doing nexthop-self demarcate the boundary between two
> domains. That boundary either link on an inter-AS link, or an ABR.
>
>
>
> May be I should clarify the statement to use “transport-route” instead of
> tunnel-route. Will that make it clear?
>
>
>
> *2. *
>
>
>
> > The path uses MPLS label-switching when crossing domain boundary
>
>
>
> So if the network for any reason does not use MPLS in its data plane -
> what you are proposing here simply is not going to work. Just for clarity
> MPLS can be used for service plane demux while transport can still be pure
> IP.
>
>
>
> It will work. There are two cases here:
>
> ·   intra-AS non-MPLS-tunnel.
>
>
>
> As explained above, details of what type of intra-AS tunnel is used is
> confined to the tunnel boundary nodes. And we can encapsulate MPLS-traffic
> on other type of tunnels. So this will work.
>
>
>
> ·   Inter-AS non-MPLS data-plane.
>
>
>
> Yes, in this document we take the case of inter-AS link running MPLS
> data-plane. Because that is the most prevalent deployment today. But we
> have put thought into how the mechanisms prescribed in this document can
> work with non-MPLS data-planes also. But they are out of scope of this
> document.
>
>
>
> In brief, instead of doing MPLS label-swap on the inter-AS link, we can do
> plain IPv6 forwarding. We may have a separate document in future, that will
> explain how mechanisms in this document adapt to SRv6 data-plane.
>
>
>
>
>
> In contrast if you are carrying your services with SRv6 across your
> domains you actually have Seamless SR for free without yet another BGP SAFI
> and stack of tunnels.
>
>
>
>    Supporting inter-AS MPLS data-plane has the following advantages:
>
> ·   Uses and builds on top of deployment experience that we have gained
> thru the years.
>
> ·   Preserves returns on investment made in existing deployments. i.e.
> Brown-field networks.
>
> ·   Scales better. Because MPLS allows us to do build network hierarchies
> with nexthop chaining and label-stacks.
>
>
>
>    But yes, if a green-field network decides to use IPv6 end-to-end, there
> are two ways it can be done:
>
> ·   Use IPv6 for control-plane, and MPLS in the data-plane.
>
> ·   Use IPv6 in the data-plane as-well. Even in this case, association of
> IPv6-tunnel endpoints with appropriate transport-class will be required.
> Which can be achieved with BGP-CT.
>
>
>
> In summary, mechanisms described in BGP-CT are agnostic to
>
> ·   What type of tunneling technology is used in the intra-AS
> transport-layer
>
> ·   And what type of data-plane is used on the inter-AS links. Though the
> draft uses MPLS.
>
>
>
> I will clarify the same in this draft. That, this draft uses MPLS as the
> defacto inter-AS data-plane, but the mechanisms will work with non-MPLS
> data-planes also. Future documents will specify details on how.
>
>
>
> *3. *
>
>
>
> >  Overlay routes carry sufficient indication of the Transport
> Classes they should be encapsulated over,
>
> > in form of BGP community called the "mapping community".
>
>
>
> My feedback here is that granularity to color routes and group routes into
> transport classes is not sufficient.
>
>
>
> If I have a cluster of compute servers which I advertise as a single
> address block I must have ability to define and disseminate flows in/out
> such cluster on a per application basis (ideally per flow 5 tuple).
>
>
>
> At min per dst port granularity would be must have. Just doing the dst
> based ip lookup and based on that placing the switching via proper color of
> inet.3 RIB will just not cut it.
>
>
>
> Please note, BGP-Flowspec routes can be colored appropriately to achieve
> what you describe here. Flowspec becomes just another service-family that
> can resolve over transport-classes created by BGP-CT.
>
>
>
> So, you could have an inet-unicast service-route advertised for the
> ‘cluster of compute servers’ with desired color mapping-community.
>
>
>
> And further, inet-flowspec route with the 5-tuple can be advertised, with
> redirect-to-ip nexthop and color mapping community. Such that any flow
> mathing this flowspec route is redirected using the transport-class, that
> the color mapping community maps to.
>
>
>
> Does that address this comment?
>
>
>
> If yes, I can add some text to the draft describing the flowspec use-case.
>
>
>
> *4.*
>
>
>
> > Based on the mapping community, "route resolution" procedure on the
> ingress node selects from the
>
> > corresponding Transport Class an appropriate tunnel whose
> destination matches (LPM) the nexthop
>
> > of the overlay route.
>
>
>
> Assume I am using inter-as option C across my domians.  So VPNv4 AF
> carries service routes with remote PEs next hops.
>
>
>
> Can you elaborate or better update the draft with a new section describing
> in detail the relation between transport next hops, border nodes and
> service next hop for a given service route across 3 domains ?
>
>
>
> Sure. We will add text to the draft describing this. in brief,
>
> At the Transport BNs:
>
> ·   It will have BGP-CT route for remote-PE/32 in gold transport-RIB.
>
> ·   This BGP-CT route will be marked un-usable, if there is no routes in
> the gold transport-RIB matching remote-PE/32
>
> ·   It Will create mpls swap-routes when readvertising the BGP-CT route.
>
> At the Ingress SN:
>
> ·   It will have the BGP-CT route for remote-PE/32 route in gold
> transport-RIB, when gold-connectivity exists end to end.
>
> ·   Service-routes carrying gold mapping-community will resolve using
> this gold transport-RIB route.
>
>
>
> For example what is not stated in the draft - if LPM match is sufficient
> here do you depend on BGP-CT to remove the advertisements to remote overlay
> tunnel endpoints when such endpoint fails ?
>
>
>
> Yes. The BGP-CT routes for a gold transport-class will fail resolving it’s
> nexthop if no gold tunnels exist. So, BGP-CT will not advertise it further.
> This is similar to the rules followed by any BGP-family regarding nexthop
> resolution.
>
>
>
> Then how about not complete failure but partial service degradation (for
> example increased fabric drops) ? How do you intend to detect those and
> automate say "gold" class bypass around such BNs ?
>
>
>
> BGP-CT will depend on the individual intra-domain transport-tunneling
> technologies to monitor such metrics, and classify whether ‘gold
> reachabilty’ exists to the nexthop in question. BGP-CT provides a way to
> collect such information procured from various intra-domain tunnels, and
> stich it across multiple domains and give an end to end picture to the
> service routes. How exactly such parameters are monitored will be left to
> the purview of the individual tunneling technologies.
>
>
>
> e.g. RSVP or SRTE can monitor such parameters at nodes along the path, and
> give feedback to the RSVP/SRTE ingress node, which either adjusts the
> ingress route in gold transport-RIB, or takes down the gold
> transport-route. Which will trigger appropriate response in the BGP-CT
> layer.
>
>
>
> *5.*
>
>
>
> > baby carrier
>
>
>
> Nice !
>
>
>
> Never used such term when describing CSC to customers  :-)
>
>
>
> Thanks! :)
>
>
>
> Once we reach consensus on the various points discussed in this thread, we
> will update the draft.
>
>
>
> Balaji, Natz, Shradha, please add if anything.
>
>
>
> Thanks,
>
> Kaliraj
>
>
>
>
>
>
>
> Juniper Business Use Only
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/idr__;!!NEt6yMaO-gk!U8HbQ5jZBlsxEu8405jmF-287HZ0Rs-PwJCc2URxQqPyf59kvSU9h1YXFcFZxEh2$>
>
> --
>
> [image: Image removed by sender.]
> <https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!U8HbQ5jZBlsxEu8405jmF-287HZ0Rs-PwJCc2URxQqPyf59kvSU9h1YXFRulXXkX$>
>
> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
>
>
> *M 301 502-1347 13101 Columbia Pike
> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g>
> *Silver Spring, MD
> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g>
>
>
>
> Juniper Business Use Only
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *



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