Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt

Gyan Mishra <hayabusagsm@gmail.com> Fri, 02 October 2020 16:30 UTC

Return-Path: <hayabusagsm@gmail.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B50C33A1134 for <lsr@ietfa.amsl.com>; Fri, 2 Oct 2020 09:30:44 -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 O0gjsDFzgn9m for <lsr@ietfa.amsl.com>; Fri, 2 Oct 2020 09:30:41 -0700 (PDT)
Received: from mail-ua1-x934.google.com (mail-ua1-x934.google.com [IPv6:2607:f8b0:4864:20::934]) (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 37A123A1103 for <lsr@ietf.org>; Fri, 2 Oct 2020 09:30:41 -0700 (PDT)
Received: by mail-ua1-x934.google.com with SMTP id z1so552460uaa.6 for <lsr@ietf.org>; Fri, 02 Oct 2020 09:30:41 -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=LgfjRaMjdbkxvXbYWEvke1AZli7wBXl0qVLQoXooE6Q=; b=B3CEiK/h9t3h8HwoYez7ZN2Fp/Kz+QvCEE7GboFj9oqzG0jjlFtAOUS9MKoziyEL0G +yiMDEF/ENM++Tu3Yd75Lfa6+GAynKrKXztpC2oKeLjr6ecor2plbIbycp1TcD49zkrq J5Sn+d/VjchUdlLeA7eSmPU03h3stohv0xLtVp2yiQnIdA121bNulj9WDwdFVldEPeRz 8k4xaH6DzeXSE2p86ArSh9Ckl1oC0IHfAKGypIQe5jyc9nGjtuScfTDvOGOoJxpNnMba +BPsIZvSz5BhckOJxbhGZnSkBpYONelX1mqyNJT2ppTNbV7hVpcbdeBRgrdrAV7gC6mg yFpg==
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=LgfjRaMjdbkxvXbYWEvke1AZli7wBXl0qVLQoXooE6Q=; b=AMJwzSvCYPajre7FtYK0NFGQVnTkUouk/aDioyJ9OJ2h3IeLZhgxajpi4b0CNbY9mz Xm5+1SjbFYDXD8V2sCc5Bc2wizcnoNjKCgwnMuQDuJGNl02H/Q174SAIb9wttY+EJTn0 L8Ylr6E6Gelp2VTgaGBR19Yh9d8CmdsbgVVYFyB2YxCsPR/Q786QMv2qOxYPogiSssGt SWhNaJjzX1HdpyMPbdGWnL0G5hoQTNjIxrqsG4wugPGNFyvQnytF9noo7o3cmkl8Cl4Q HlD3HF6+FiyE2TlpsqX8s0KTrBKDvGcKOC6heUDlrzairBXW5vYUXlJD5vor+EJRKP+A VG/w==
X-Gm-Message-State: AOAM530P+TFHQgwkKY0G/olxHxaNeCwdowFDIjcuGM1AGFCub54YiAFj 8WqR54iYEGtsReKfTiZmswiH2Bm7p+ZnxkUbZG8=
X-Google-Smtp-Source: ABdhPJxBZP4laGxrfjvHb0VVgS8lJC8MfcUQ+WjeTLWCTpY7Rf1me1eoZd+wy4b6iHg2Qj2uP6Ht5r77uTeAY9GtNgY=
X-Received: by 2002:ab0:4e25:: with SMTP id g37mr1717186uah.106.1601656239947; Fri, 02 Oct 2020 09:30:39 -0700 (PDT)
MIME-Version: 1.0
References: <160138654056.12980.329207214151594381@ietfa.amsl.com> <DM6PR05MB63482DBC001DD56BEF6F7311AE320@DM6PR05MB6348.namprd05.prod.outlook.com> <CAKz0y8w5VOf_=baG6UCP8Q9s=VLM2ghT2jhiF5FZNN4JXB23eA@mail.gmail.com> <DM6PR05MB63485389C261CA2E0C08DE50AE330@DM6PR05MB6348.namprd05.prod.outlook.com> <0f85212d-fac7-47ea-a608-4f53061cbf02@Spark> <DM6PR05MB63480E863599BBC810BF334AAE300@DM6PR05MB6348.namprd05.prod.outlook.com>
In-Reply-To: <DM6PR05MB63480E863599BBC810BF334AAE300@DM6PR05MB6348.namprd05.prod.outlook.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Fri, 02 Oct 2020 12:30:29 -0400
Message-ID: <CABNhwV2+jhjAfxq5FzaukdhCOqXvGCkv75xYWcStN=SCrpni4Q@mail.gmail.com>
To: Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>
Cc: Jeff Tantsura <jefftant.ietf@gmail.com>, "lsr@ietf.org" <lsr@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000003c04c905b0b2a76c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/Fyq2fU38bBBqF3L_9zwUTNnvZRM>
Subject: Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Oct 2020 16:30:45 -0000

Hi Ron

I really like the idea of being able to use flex algo over native IPv4 or
IPv6.  I had asked that very question early on with flex algo and wondered
if there was a way to support it with native IP.

Great concept and idea!!

As mentioned in the thread as you are using loopbacks associated with the
flex algorithm the concept is very similar to SRv6 locator and only one
algorithm per IP, interface or prefix and uses the same IGP longest prefix
match routing.

A lot of the basic concepts TLV and nomenclature from the SR flex algo
draft seems to be adopted with this draft.  Main difference is IP data
plane forwarding instead of SR Segment based forwarding plane.

Had a question related to the data plane forwarding and building of the
explicit paths loose or strict similar to constraint based prefix sid loose
path or adjacency sid based strict path done in SR paradigm.  As you are
using a native IP forwarding plane, how do we accomplish the same building
of the explicit path as done with Segment Routing SRv6 using SRH SID list
or SR-MPLS label stack from a data plane forwarding standpoint?

Would you use a similar RSVP TE style ERO lose or strict record route
option used for FRR n:1 facility protection in IP world use ip source route
record route IP option to record the path.

For IPv6 would you use EH routing header to record the path.


In this section maybe having some examples or graphical depiction of the
forwarding plane both loose and strict path instantiation and how that
would work.

8 <https://tools.ietf.org/html/draft-bonica-lsr-ip-flexalgo-00#section-8>.
Calculating Constraint-Based Paths

   Nodes calculate constraint-based paths as described in Section 12 of
   [I-D.ietf-lsr-flex-algo
<https://tools.ietf.org/html/draft-bonica-lsr-ip-flexalgo-00#ref-I-D.ietf-lsr-flex-algo>].


Maybe recording of the path is not needed if we are doing hop by hop
routing just with different constraint algorithms and not the instantiation
of a source routed path as with SR.

With SR flex algo since the data plane is SR based its a source routed path
that is instantiated so this would be different as it would be a IGP
control plane based hop by hop routed path.  If that’s the case.

As flex algo in SR framework can be used in conjunction with SR-TE can this
IP based flex algo be used with RSVP TE maybe adding in future IGP opaque
LSA or TLV extension to flex algo.

As IP based flex algo is very similar to SRv6-BE w/o SRH it seems they both
would interoperate nicely as both use native IPv6 forwarding plane.

Maybe down the road a separate draft on interoperability of IP flex algo
with SR and RSVP-TE if you think that is feasible.

All,

With SRv6 and IP based flex algo a generic question as it applies to both.
Is it possible to have within a single IGP domain different sets of nodes
or segments of the network running different algorithms.  From both drafts
it sounds like all nodes have to agree on same algorithm similar to concept
of metric and reference bandwidth all have to have the same style metric
and play to the same sheet of music.  If there was a way to use multiple
algorithms simultaneously based on SFC or services and instantiation of
specific algorithm based on service to be rendered.  Doing so without
causing a routing loop or sub optimal routing.  I thought with flex algo
that there exists a feature that on each hop there is a way to specify
which algo to use hop by hop similar to a hop by hop policy based routing.


Kind Regards

Gyan

On Thu, Oct 1, 2020 at 2:45 PM Ron Bonica <rbonica=
40juniper.net@dmarc.ietf.org> wrote:

>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Good point!!
>
>
>
>
>
>
>
>
>
>
>
>
>
> Juniper Business Use Only
>
>
>
>
>
>
> *From:* Jeff Tantsura <jefftant.ietf@gmail.com>
>
>
> *Sent:* Thursday, October 1, 2020 2:08 AM
>
>
> *To:* Ron Bonica <rbonica@juniper.net>
>
>
> *Cc:* lsr@ietf.org
>
>
> *Subject:* Re: [Lsr] FW: New Version Notification for
> draft-bonica-lsr-ip-flexalgo-00.txt
>
>
>
>
>
>
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
>
>
>
>
>
>
>
>
> Hi Ron,
>
>
>
>
>
> the readers would benefit if the draft would state that in order for the
> technology to work properly, there must be a contiguous set of connected
> routers that support it between the S/D, since lookup (route installed in
> context of the algo it is associated
>
> with) is done per hop.
>
>
>
>
>
>
>
>
>
>
>
>
>
> Cheers,
>
>
>
>
> Jeff
>
>
>
>
>
>
>
>
>
>
> On Sep 30, 2020, 9:03 AM -0700, Ron Bonica <
> rbonica=40juniper.net@dmarc.ietf.org>, wrote:
>
>
>
>
>
>
> Hi Muthu,
>
>
>
>
>
> Thanks for the review.
>
>
>
>
>
> An interface can be associated with, at most, one Flexible Algorithm.
> Likewise, an IP address can be associated with, at most, one Flexible
> Algorithm.
>
>
>
>
>
> I tried to express this in the text below, but probably didn’t do a very
> good job. If you can think of a better way to say it, I would appreciate
> suggestions.
>
>
>
>
>
>                                                   Ron
>
>
>
>
>
> Text from draft
>
>
> ============
>
>
>
>
>
> Network operators configure multiple loopback interfaces on an egress
>
>
>    node.  They can associate each loopback interface with:
>
>
>
>
>
>    o  Zero or more IP addresses.
>
>
>
>
>
>    o  Zero or one Flexible Algorithms.
>
>
>
>
>
>    If an IP address and a Flexible Algorithm are associated with the
>
>
>    same interface, they are also associated with one another.  An IP
>
>
>    address MAY be associated with, at most, one interface.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Juniper Business Use Only
>
>
>
>
>
>
> *From:* Muthu Arul Mozhi Perumal <muthu.arul@gmail.com>
>
>
> *Sent:* Wednesday, September 30, 2020 9:59 AM
>
>
> *To:* Ron Bonica <rbonica@juniper.net>
>
>
> *Cc:* lsr@ietf.org
>
>
> *Subject:* Re: [Lsr] FW: New Version Notification for
> draft-bonica-lsr-ip-flexalgo-00.txt
>
>
>
>
>
>
>
>
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
>
>
>
>
>
>
> A quick question:
>
>
>
>
>
>
>    If an IP address and a Flexible Algorithm are associated with the
>
>
>
>    same interface, they are also associated with one another.  An IP
>
>
>
>    address MAY be associated with, at most, one interface.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> If multiple IP addresses and multiple flexible algorithms are associated
> with a loopback interface, is each IP address associated
>
> with all flexible algorithms? What matters is the association b/w an IP
> address and a flexalgo, so the relationship should be defined in a direct
> way rather than each being associated with an interface, right?
>
>
>
>
>
>
>
>
>
>
>
>
>
> Regards,
>
>
>
>
>
>
> Muthu
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Tue, Sep 29, 2020 at 7:07 PM Ron Bonica <rbonica=
> 40juniper.net@dmarc.ietf.org> wrote:
>
>
>
>
>
>
>
> Please review and comment
>
>
>
>
>
>                                        Ron
>
>
>
>
>
>
>
>
>
>
>
> Juniper Business Use Only
>
>
>
>
>
> > -----Original Message-----
>
>
> > From: internet-drafts@ietf.org <internet-drafts@ietf.org>
>
>
> > Sent: Tuesday, September 29, 2020 9:36 AM
>
>
> > To: Parag Kaneriya <pkaneria@juniper.net>; Shraddha Hegde
>
>
> > <shraddha@juniper.net>; Ron Bonica <rbonica@juniper.net>; Rajesh M
>
>
> > <mrajesh@juniper.net>; William Britto A J <bwilliam@juniper.net>
>
>
> > Subject: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt
>
>
> >
>
>
> > [External Email. Be cautious of content]
>
>
> >
>
>
> >
>
>
> > A new version of I-D, draft-bonica-lsr-ip-flexalgo-00.txt
>
>
> > has been successfully submitted by Ron Bonica and posted to the IETF
>
>
> > repository.
>
>
> >
>
>
> > Name:           draft-bonica-lsr-ip-flexalgo
>
>
> > Revision:       00
>
>
> > Title:          IGP Flexible Algorithms (Flexalgo) In IP Networks
>
>
> > Document date:  2020-09-29
>
>
> > Group:          Individual Submission
>
>
> > Pages:          14
>
>
> > URL:
>
> https://urldefense.com/v3/__https://www.ietf.org/id/draft-bonica-
> <https://urldefense.com/v3/__https:/www.ietf.org/id/draft-bonica->
>
>
> > lsr-ip-flexalgo-00.txt__;!!NEt6yMaO-gk!X7PVDP-
>
>
> > FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck80Zbjoij$
>
>
> > Status:
>
>
> >
>
>
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-bonica-lsr-
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-bonica-lsr->
>
>
> > ip-flexalgo/__;!!NEt6yMaO-gk!X7PVDP-
>
>
> > FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck8x7e5ZqI$
>
>
> > Htmlized:
>
>
> >
>
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft->
>
>
> > bonica-lsr-ip-flexalgo__;!!NEt6yMaO-gk!X7PVDP-
>
>
> > FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck82w_6CyU$
>
>
> > Htmlized:
> https://urldefense.com/v3/__https://tools.ietf.org/html/draft-
> <https://urldefense.com/v3/__https:/tools.ietf.org/html/draft->
>
>
> > bonica-lsr-ip-flexalgo-00__;!!NEt6yMaO-gk!X7PVDP-
>
>
> > FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck81_QrJ_p$
>
>
> >
>
>
> >
>
>
> > Abstract:
>
>
> >    An IGP Flexible Algorithm computes a constraint-based path and maps
>
>
> >    that path to an identifier.  As currently defined, Flexalgo can only
>
>
> >    map the paths that it computes to Segment Routing (SR) identifiers.
>
>
> >    Therefore, Flexalgo cannot be deployed in the absence of SR.
>
>
> >
>
>
> >    This document extends Flexalgo, so that it can map the paths that it
>
>
> >    computes to IP addresses.  This allows Flexalgo to be deployed in any
>
>
> >    IP network, even in the absence of SR.
>
>
> >
>
>
> >
>
>
> >
>
>
> >
>
>
> > Please note that it may take a couple of minutes from the time of
> submission
>
>
> > until the htmlized version and diff are available at
>
> tools.ietf.org
> <https://urldefense.com/v3/__http:/tools.ietf.org__;!!NEt6yMaO-gk!VQoAwwHICHoY23KWJbKL7SpeHYGiY6hT9pSpTh7Mfn5lQyaC9E5JcOlvhG1kuR-O$>
> .
>
>
> >
>
>
> > The IETF Secretariat
>
>
> >
>
>
> _______________________________________________
>
>
> Lsr mailing list
>
>
> Lsr@ietf.org
>
>
> https://www.ietf.org/mailman/listinfo/lsr
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!VQoAwwHICHoY23KWJbKL7SpeHYGiY6hT9pSpTh7Mfn5lQyaC9E5JcOlvhOxbdTsH$>
>
>
>
>
> _______________________________________________
>
>
> Lsr mailing list
>
>
> Lsr@ietf.org
>
>
> https://www.ietf.org/mailman/listinfo/lsr
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
>
> Lsr mailing list
>
> Lsr@ietf.org
>
> https://www.ietf.org/mailman/listinfo/lsr
>
> --

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

*Gyan Mishra*

*Network Solutions A**rchitect *



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