Re: [Lsr] WG adoption call for draft-ketant-lsr-ospf-l2bundles-01

[Ketan Talaulikar (ketant)]

Hi Gyan,

Thanks for your support and comments on the draft.

The proposed encoding for L2 Bundle members and their attributes in OSPF is 
different than the ISIS encodings in RFC8668. ISIS encodings have “tighter” LSP 
space considerations that OSPF. The authors have proposed a simpler encoding 
scheme for OSPF – feedback/inputs are welcome.

The list of attributes in Figure 2 and 3 also includes L2 Bundle member Adj 
SID. Since the encoding scheme is similar to Layer 3 attributes, we can re-use 
the same sub-TLVs.

Thanks,
Ketan

From: Lsr  On Behalf Of Gyan Mishra
Sent: 03 October 2020 04:07
To: Les Ginsberg (ginsberg) 
Cc: lsr@ietf.org; draft-ketant-lsr-ospf-l2bundles@ietf.org; Christian Hopps 
; lsr-cha...@ietf.org
Subject: Re: [Lsr] WG adoption call for draft-ketant-lsr-ospf-l2bundles-01


I support WG adoption of this draft.

I agree that OSPF needs the functionality equivalent to that defined for IS-IS 
in RFC 8668.

I think the draft should include similar to RFC 8668 section 3 parallel layer 3 
adjacencies 3 similar Sub TLVs mentioned flag for multiple parallel adjacencies.

Also maybe section 4 of RFC 8668 would apply as well to ospf advertisement of 
L2 bundle Adj sid.

Thanks

Gyan

On Fri, Oct 2, 2020 at 6:11 PM Les Ginsberg (ginsberg) 
mailto:40cisco@dmarc.ietf.org>> wrote:
I support WG adoption of this draft.

OSPF needs functionality equivalent to that defined for IS-IS in RFC 8668.



   Les





> -Original Message-

> From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
> Christian Hopps

> Sent: Friday, October 02, 2020 5:03 AM

> To: lsr@ietf.org

> Cc: lsr-cha...@ietf.org; Christian Hopps 
> mailto:cho...@chopps.org>>; draft-ketant-

> lsr-ospf-l2bundles@ietf.org

> Subject: [Lsr] WG adoption call for draft-ketant-lsr-ospf-l2bundles-01

>

> This begins a 2 week WG adoption call for the following draft:

>

>   https://datatracker.ietf.org/doc/draft-ketant-lsr-ospf-l2bundles/

>

> Please indicate your support or objection by October 16, 2020.

>

> Authors, please respond to the list indicating whether you are aware of any

> IPR that applies to this draft.

>

> Thanks,

> Chris and Acee.



___

Lsr mailing list

Lsr@ietf.org

https://www.ietf.org/mailman/listinfo/lsr
--

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]

Gyan Mishra

Network Solutions Architect

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG adoption call for draft-ketant-lsr-ospf-l2bundles-01

[Ketan Talaulikar (ketant)]

I support the adoption of this document by the WG and as an author, I am not 
aware of any IPR associated with it.

Thanks,
Ketan

-Original Message-
From: Christian Hopps  
Sent: 02 October 2020 17:33
To: lsr@ietf.org
Cc: Christian Hopps ; lsr-cha...@ietf.org; 
draft-ketant-lsr-ospf-l2bundles@ietf.org
Subject: WG adoption call for draft-ketant-lsr-ospf-l2bundles-01

This begins a 2 week WG adoption call for the following draft:

  https://datatracker.ietf.org/doc/draft-ketant-lsr-ospf-l2bundles/

Please indicate your support or objection by October 16, 2020.

Authors, please respond to the list indicating whether you are aware of any IPR 
that applies to this draft.

Thanks,
Chris and Acee.

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Gyan Mishra]

Thanks Peter!

On Sun, Oct 4, 2020 at 5:51 AM Peter Psenak  wrote:

> Hi Gyan,
>
>
>
> On 03/10/2020 18:54, Gyan Mishra wrote:
>
> >
>
> > Thanks Peter for the responses to help clear up my flex algo
> understanding!!
>
> >
>
> > On Sat, Oct 3, 2020 at 5:45 AM Peter Psenak 
> > > wrote:
>
> >
>
> > Gyan,
>
> >
>
> >
>
> >
>
> > On 03/10/2020 02:14, Gyan Mishra wrote:
>
> >
>
> >  >
>
> >
>
> >  > Hi  Jeff
>
> >
>
> >  >
>
> >
>
> >  >  From a domain perspective where you have a group of nodes and
>
> >
>
> >  > associated IP addressed and SID are part of a discrete underlay
>
> > instance
>
> >
>
> >  > flex algo topology.  On those same set of nodes you could have
>
> > another
>
> >
>
> >  > topology and associated address and SIDs for a different flex
> algo.
>
> >
>
> >
>
> >
>
> > above is right.
>
> >
>
> >
>
> > Gyan>  So per my response to Robert, what  I was thinking is that as
>
> > the algo 0 strict spf would be used as the base algo to provide
>
> > reachability to all nodes within the domain and all neighbors are formed
>
> > between all nodes in the domain to populate IGP rib providing base
>
> > connectivity reachability.  So then underneath of that you can have any
>
> > subset of nodes out of the superset all top layer domain nodes level
>
> >   that can run any other algo desired. Basically creating algo layers
>
> > under the top domain wide layer.
>
>
>
> pretty much.
>
>
>
>
>
> >
>
> >
>
> >
>
> >
>
> >  > How
>
> >
>
> >  > this would work is that the topologies would have to be
>
> > segregated from
>
> >
>
> >  > each other as different MT instances or routing process
>
> > instances.  Is
>
> >
>
> >  > that correct?
>
> >
>
> >
>
> >
>
> > no MT at all. You can think of each flex-algo as a set of constraints
>
> >
>
> > that is used to calculate the path over the common topology. You can
>
> >
>
> > have many such felx-algos running on a common topology.
>
> >
>
> >
>
> >  Gyan> Is it safe to say that we can think of it as RSVP TE “like”
>
> > cSPF constraints that we are build via traffic engineering PCALC
>
> > algorithms to run for dynamic LSP dyamic ERO that is built based on IGP
>
> > constraints from TEDs database of TE link attributes and TE or IGP
>
> > weights metric constraints to create the dynamic LSP path.
>
>
>
> you can think of a flex-algo as a TE like solution, but there are some
>
> major differences to RSVP-TE:
>
>
>
> - automatic calculation of flex-algo constrained based paths from any
>
> source to any destination. This is in contrast to p2p nature of RSVP-TE.
>
>
>
> - there is no TED, all information is stored in IGP LSDB.
>
>
>
>
>
>
>
>
>
> > So we could
>
> > think of in TE framework analogy to flex algo In the per VRF TE next hop
>
> > vpn coloring use case with different loopback next hop rewrite per VRF
>
> > that normal IGP non TE BAU VPNs traffic would be like the flex algo base
>
> > strict algo 0 and the non zero discrete algo would be like the per VRF
>
> > next hop loopback rewrite where each per VRF te loopback rewrite would
>
> > be a different steering non zero discrete flex algo all running in
>
> > parallel as ships in the night with the base algo 0.   Sorry for the
>
> > complex analogy but I think I am getting it!!😃
>
>
>
> steering the traffic to flex-algo paths can be done using different
>
> methods - per-destination, per flow, etc. Various coloring mechanism can
>
> be used as well, if needed.
>
>
>
>
>
> >
>
> > Does a flex algo use case draft exist and if not I would not mind using
>
> > the analogy I said above and build out a use case draft.  Cheers! 😊
>
>
>
>
>
> I'm not a fan of use case drafts. These should be vendor specific
>
> documents, no need to make them standards.
>
>
>
> thanks,
>
> Peter
>
> >
>
> >
>
> >
>
> >
>
> >  >
>
> >
>
> >  > Can two nodes that run two different flex algo become ospf or isis
>
> >
>
> >  > neighbors?
>
> >
>
> >
>
> >
>
> > absolutely.
>
> >
>
> >
>
> >
>
> > Peter
>
> >
>
> >
>
> >
>
> >  >
>
> >
>
> >  > Kind Regards
>
> >
>
> >  >
>
> >
>
> >  > Gyan
>
> >
>
> >  >
>
> >
>
> >  > On Fri, Oct 2, 2020 at 6:25 PM Jeff Tantsura
>
> > mailto:jefftant.i...@gmail.com>
>
> >
>
> >  > 
> > >> wrote:
>
> >
>
> >  >
>
> >
>
> >  >
>
> >
>
> >  >
>
> >
>
> >  >
>
> >
>
> >  >
>
> >
>
> >  >
>
> >
>
> >  >
>
> >
>
> >  >
>
> >
>
> >  >
>
> >
>
> >  >
>
> >
>
> >  >
>
> >
>
> >  >
>
> >
>
> >  >
>
> >
>
> >  > Hi Yingzhen,
>
> >
>
> >  >
>
> >
>
> >  >
>
> >
>
> >  >
>
> >
>
> >  >
>
> >
>
> >  >
>
> >
>
> >  > Yes, that’s the case.  The most important property of an algo
>
> >
>
> >  > computed path is that is has to be consecutive, as either SID
>
> > or IP
>
> >
>
> >

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

[Peter Psenak]

Yingzhen,

On 03/10/2020 20:08, Yingzhen Qu wrote:

Hi Peter,

Using flex-algo, a SRv6 locator can be associated with a single algo, which means an IPv6 or IPv4 address can also be associated with a single algo. So my understanding is Ron's proposal is making the configuration of flex-algo easier? 


no.


Instead of using the exclude or include list you can configure a loopback 
address to a flex-algo directly?


above has been done for SRv6 locators already. Now you can make that 
association for regular ipv4 and ipv6 prefixes.


thanks,
Peter




Thanks,
Yingzhen

On 10/3/20, 2:47 AM, "Peter Psenak"  wrote:

 Hi Yingzhen,

 On 02/10/2020 22:15, Yingzhen Qu wrote:
 > Hi Peter,
 >
 > My understanding of flex-algo is that for traffic destined to a prefix 
on a particular algo, it can only be routed on routers belong to that algo, which 
also means only routers in that algo calculates how to reach that prefix and 
install it into the routing table. It seems to me that using flex-algo (section 12 
of the draft) it's possible to have a loopback address associated with only one 
algo, please correct me if I'm missing or misunderstood something.

 you are right. That is exactly what is being done for flex-algo with
 SRv6 - locator is associated with a single algo only. The proposal uses
 the same concept.

 thanks,
 Peter

 >
 > Thanks,
 > Yingzhen
 >
 > On 10/2/20, 9:43 AM, "Lsr on behalf of Peter Psenak"  wrote:
 >
 >  Gyan,
 >
 >  On 02/10/2020 18:30, Gyan Mishra wrote:
 >  > 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.
 >
 >  absolutely.
 >
 >  > 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.
 >
 >  all participating nodes need to agree on the definition of the 
flex-algo
 >  and advertise the participation. That's it.
 >
 >  > 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.
 >
 >  you can certainly use multiple algorithms simultaneously and use 
algo
 >  specific paths to forward specific traffic over it. How that is done
 >  from the forwarding perspective depends in which forwarding plane 
you
 >  use. Flex-algo control plane is independent of the forwarding plane.
 >
 >
 >  >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.
 >
 >  no, there is no hop-by-hop classification, that is problematic and 
does
 >  not scale for high speeds. Classification is done at the ingress 
only.
 >
 >  thanks,
 >  Peter
 >
 >  >
 >
 >  ___
 >  Lsr mailing list
 >  Lsr@ietf.org
 >  
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr&data=02%7C01%7Cyingzhen.qu%40futurewei.com%7Cfe03124c6e414e067c2008d867816541%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637373152739865126&sdata=WI48cEAan%2FOkDPmVXGurEAjPItNGF9p9PDQIlD1ip0g%3D&reserved=0
 >
 >
 >






___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Peter Psenak]

Hi Gyan,

On 03/10/2020 18:54, Gyan Mishra wrote:


Thanks Peter for the responses to help clear up my flex algo understanding!!

On Sat, Oct 3, 2020 at 5:45 AM Peter Psenak > wrote:


Gyan,



On 03/10/2020 02:14, Gyan Mishra wrote:

 >

 > Hi  Jeff

 >

 >  From a domain perspective where you have a group of nodes and

 > associated IP addressed and SID are part of a discrete underlay
instance

 > flex algo topology.  On those same set of nodes you could have
another

 > topology and associated address and SIDs for a different flex algo.



above is right.


    Gyan>  So per my response to Robert, what  I was thinking is that as 
the algo 0 strict spf would be used as the base algo to provide 
reachability to all nodes within the domain and all neighbors are formed 
between all nodes in the domain to populate IGP rib providing base 
connectivity reachability.  So then underneath of that you can have any 
subset of nodes out of the superset all top layer domain nodes level 
  that can run any other algo desired. Basically creating algo layers 
under the top domain wide layer.


pretty much.







 > How

 > this would work is that the topologies would have to be
segregated from

 > each other as different MT instances or routing process
instances.  Is

 > that correct?



no MT at all. You can think of each flex-algo as a set of constraints

that is used to calculate the path over the common topology. You can

have many such felx-algos running on a common topology.


     Gyan> Is it safe to say that we can think of it as RSVP TE “like” 
cSPF constraints that we are build via traffic engineering PCALC 
algorithms to run for dynamic LSP dyamic ERO that is built based on IGP 
constraints from TEDs database of TE link attributes and TE or IGP 
weights metric constraints to create the dynamic LSP path.  


you can think of a flex-algo as a TE like solution, but there are some 
major differences to RSVP-TE:


- automatic calculation of flex-algo constrained based paths from any 
source to any destination. This is in contrast to p2p nature of RSVP-TE.


- there is no TED, all information is stored in IGP LSDB.




So we could 
think of in TE framework analogy to flex algo In the per VRF TE next hop 
vpn coloring use case with different loopback next hop rewrite per VRF 
that normal IGP non TE BAU VPNs traffic would be like the flex algo base 
strict algo 0 and the non zero discrete algo would be like the per VRF 
next hop loopback rewrite where each per VRF te loopback rewrite would 
be a different steering non zero discrete flex algo all running in 
parallel as ships in the night with the base algo 0.   Sorry for the 
complex analogy but I think I am getting it!!😃


steering the traffic to flex-algo paths can be done using different 
methods - per-destination, per flow, etc. Various coloring mechanism can 
be used as well, if needed.





Does a flex algo use case draft exist and if not I would not mind using 
the analogy I said above and build out a use case draft.  Cheers! 😊



I'm not a fan of use case drafts. These should be vendor specific 
documents, no need to make them standards.


thanks,
Peter





 >

 > Can two nodes that run two different flex algo become ospf or isis

 > neighbors?



absolutely.



Peter



 >

 > Kind Regards

 >

 > Gyan

 >

 > On Fri, Oct 2, 2020 at 6:25 PM Jeff Tantsura
mailto:jefftant.i...@gmail.com>

 > >> wrote:

 >

 >

 >

 >

 >

 >

 >

 >

 >

 >

 >

 >

 >

 >     Hi Yingzhen,

 >

 >

 >

 >

 >

 >     Yes, that’s the case.  The most important property of an algo

 >     computed path is that is has to be consecutive, as either SID
or IP

 >     address associated with a particular topology is only known
within

 >     that topology.

 >

 >

 >     Looking specifically at Ron’s draft (MPLS could be more
complex due

 >     to potential hierarchy) - the prefix itself defines the

 >     context(topology) and must be globally unique, since IPv4 header

 >     can’t have any additional meta-data attached.

 >

 >

 >

 >

 >

 >

 >

 >     Cheers,

 >

 >     Jeff

 >

 >

 >

 >

 >

 >

 >     On Oct 2, 2020, 1:15 PM -0700, Yingzhen Qu

 >     mailto:yingzhen...@futurewei.com>
>>, wrote:

 >

 >

 >>     Hi Peter,

 >>

 >>

 >>

 >>

 >>

 >>     My understanding of flex-algo is that for traffic destined to a

 >>     prefix on a particular algo, it can only be routed on routers

 >>     belong to that algo, which als