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

[Gyan Mishra]

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.  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?

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

Kind Regards

Gyan

On Fri, Oct 2, 2020 at 6:25 PM Jeff Tantsura 
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 ,
> 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.
>
>
>
>
>
> Thanks,
>
>
> Yingzhen
>
>
>
>
>
> On 10/2/20, 9:43 AM, "Lsr on behalf of Peter Psenak" <
> lsr-boun...@ietf.org on behalf of ppsenak=40cisco@dmarc.ietf.org>
> 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%7C51dd940ab25d4ea19b1b08d866f23b6a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637372537869296887&sdata=R%2FI%2BAUkcw12FmgDtsh%2FBOL7zLjPF%2BwwRpqwnE2Ndv%2Fg%3D&reserved=0
>
>
>
>
>
>
>
>
>
>
>
> --



*Gyan Mishra*

*Network Solutions A**rchitect *



*M 301 502-134713101 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

[Gyan Mishra]

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)  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  On Behalf Of Christian Hopps
>
> > Sent: Friday, October 02, 2020 5:03 AM
>
> > To: lsr@ietf.org
>
> > Cc: lsr-cha...@ietf.org; Christian Hopps ;
> 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
>
> --



*Gyan Mishra*

*Network Solutions A**rchitect *



*M 301 502-134713101 Columbia Pike *Silver Spring, MD
___
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

[Jeff Tantsura]

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 , 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.
>
> Thanks,
> Yingzhen
>
> On 10/2/20, 9:43 AM, "Lsr on behalf of Peter Psenak"  behalf of ppsenak=40cisco@dmarc.ietf.org> 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%7C51dd940ab25d4ea19b1b08d866f23b6a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637372537869296887&sdata=R%2FI%2BAUkcw12FmgDtsh%2FBOL7zLjPF%2BwwRpqwnE2Ndv%2Fg%3D&reserved=0
>
___
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

[Les Ginsberg (ginsberg)]

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  On Behalf Of Christian Hopps
> Sent: Friday, October 02, 2020 5:03 AM
> To: lsr@ietf.org
> Cc: lsr-cha...@ietf.org; Christian Hopps ; 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

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

[Jeff Tantsura]

yes/support

Cheers,
Jeff
On Oct 2, 2020, 5:03 AM -0700, Christian Hopps , wrote:
> 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
___
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

[Yingzhen Qu]

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.

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%7C51dd940ab25d4ea19b1b08d866f23b6a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637372537869296887&sdata=R%2FI%2BAUkcw12FmgDtsh%2FBOL7zLjPF%2BwwRpqwnE2Ndv%2Fg%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

[Gyan Mishra]

Thanks Peter!

On Fri, Oct 2, 2020 at 12:42 PM 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.


   Gyan> Great.  As was noted on the thread that with SR-MPLS you can have
multiple labels and each label bound to a different algorithm for a service
prefix, however that is not possible with SRv6 as it’s a 1-1 binding
destination prefix to SRv6 sid.  With SRv6 standard longest prefix matching
 can you  also have different sets of nodes running different algorithms
within the same domain.  SRv6 has the advantage of LPM but SR-MPLS does
seem to have an advantage of being able to have multiple algorithms tied to
a label bound to the same FEC.  That does seem to be an advantageous
feature with SR-MPLS - MPLS data plane use of flex algo as compare to SRv6.

>
>
>
> > 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.
>

Gyan> Trying to picture how it would work if you had let’s say all
nodes in a single IGP domain or MT instance running let’s say 2 different
algorithms simultaneously.  Would it be like 2 different routing overlay
IGP instances or ISIS MT instance or ospf process.  Also would that work
with just SR-MPLS or would that also work with SRv6?  In the case where you
have groups of nodes running a different algorithm the adjacent border
nodes between the groupings would end up running multiple  algorithms.  So
it can work and not issue with routing loops or sub optimal routing.

>
>
>
> > 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.
>
> Gyan> Is there a flex algo use case draft?
>
>
>
> >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.
>
> Gyan>  Is the classification of interesting traffic base on QOS marking on
> ingress to map to a specific flex algo for a particular service?
>
> thanks,
>
> Peter
>
>
>
> >
>
>
>
> --



*Gyan Mishra*

*Network Solutions A**rchitect *



*M 301 502-134713101 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

[Acee Lindem (acee)]

Speaking as WG member:
 
I support WG adoption of this document. It is needed for IS-IS parity and there 
are already other non-WG documents referencing it. 

Thanks,
Acee

On 10/2/20, 8:05 AM, "Christian Hopps"  wrote:

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

[Peter Psenak]

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://www.ietf.org/mailman/listinfo/lsr

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

[Gyan Mishra]

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 .
Calculating Constraint-Based Paths

   Nodes calculate constraint-based paths as described in Section 12 of
   [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  wrote:

>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Good point!!
>
>
>
>
>
>
>
>
>
>
>
>
>
> Juniper Business Use Only
>
>
>
>
>
>
> *From:* Jeff Tantsura 
>
>
> *Sent:* Thursday, October 1, 2020 2:08 AM
>
>
> *To:* Ron Bonica 
>
>
> *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@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 

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

[Christian Hopps]

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.


signature.asc
Description: Message signed with OpenPGP
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-07.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Link State Routing WG of the IETF.

Title   : YANG Model for OSPFv3 Extended LSAs
Authors : Acee Lindem
  Sharmila Palani
  Yingzhen Qu
Filename: draft-ietf-lsr-ospfv3-extended-lsa-yang-07.txt
Pages   : 29
Date: 2020-10-02

Abstract:
   This document defines a YANG data model augmenting the IETF OSPF YANG
   model to provide support for OSPFv3 Link State Advertisement (LSA)
   Extensibility as defined in RFC 8362.  OSPFv3 Extended LSAs provide
   extensible TLV-based LSAs for the base LSA types defined in RFC 5340.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-extended-lsa-yang/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-lsr-ospfv3-extended-lsa-yang-07
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospfv3-extended-lsa-yang-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-ospfv3-extended-lsa-yang-07


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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


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

[Lsr] The LSR WG has placed draft-ketant-lsr-ospf-l2bundles in state "Call For Adoption By WG Issued"

[IETF Secretariat]

The LSR WG has placed draft-ketant-lsr-ospf-l2bundles in state
Call For Adoption By WG Issued (entered by Christian Hopps)

The document is available at
https://datatracker.ietf.org/doc/draft-ketant-lsr-ospf-l2bundles/


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

Re: [Lsr] Pre-writeup review comments

[Christian Hopps]

Thanks for the update, a couple issues remain.

[ ] 7.1 and 8.1

The reserved bits for "SRv6 Locator TLV" and "SRv6 End.X SID sub-TLV" are
defined differently (and probably incorrectly) than the other reserved bits.
Reserved bits "MUST" be set to zero, not "SHOULD", I believe.

[ ] 11.  Implementation Status

I know you mentioned that the section should be removed, but how about adding a 
note to the editor in the next revision e.g., "RFC Ed.: Please remove this 
section prior to publication"?

[ ] 12.5.  Sub-Sub-TLVs for SID Sub-TLVs

This section needs to better conform to registry creation standards (see
https://tools.ietf.org/html/rfc8126). In particular there is no guidance.

It looks like there is more discussion from Joel on this draft, so I will hold 
off on submission for that to resolve.

Thanks,
Chris.

> On Sep 23, 2020, at 4:36 PM, Peter Psenak 
>  wrote:
> 
> Hi Chris,
> 
> thanks for your comments.
> 
> Please see inline (##PP):
> 
> On 18/09/2020 16:08, Christian Hoppsprotocol= application/pgp-signature wrote:
>> During my review and while doing the Shepherd writeup for 
>> https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/ I came 
>> up with the following comments:
>> 4.3 - Maximum H.Encaps MSD Type:
>>   - what is the default if not advertised?
> 
> ##PP
> added "or no value is advertised" as for other MSD types.
> 
>> 6.  Advertising Anycast Property
>> Should "Locator that is advertised..." be:
>>   "An SRv6 Locator that is advertised..."?
>> or:
>>   "A prefix/SRv6 Locator that is advertised..."?
> 
> ##PP
> fixed.
> 
>> 7.1 SRv6 Locator TLV Format
>> The R fields and their handling, are not defined.
> 
> ##PP
> added
> 
> 
>> 8.  Advertising SRv6 Adjacency SIDs
>> "must be" "in order to be correctly applied" -> "are" and ""?
> 
> ##PP
> I replaced with:
> 
> Certain SRv6 Endpoint behaviors [I-D.ietf-spring-srv6-network-programming] 
> are associated with a particular adjacency.
> 
> 
>> 8.1.  SRv6 End.X SID sub-TLV
>> "Other bits" -> "Reserved bits" -- labels should match
> 
> ##PP
> fixed.
> 
>> 8.2.  SRv6 LAN End.X SID sub-TLV
>> I'm sympathetic to Bruno's comment, and so I think it would be better to say:
>> Diagram: "System ID (1-6 octets)" and in text:
>> "6 octets" -> "System ID: 1-6 octets"
>> I see no reason to mess with this even if the commonly-implemented value is 
>> 6 at
>> this point. IS-IS implementations that only support 6 octets are free to only
>> support 6 in this sub-TLV as well. They won't be talking with other IS-IS
>> routers that are configured to have a non-6 octet system ID value. What other
>> extension RFCs may or may-not do WRT this doesn't really matter I think.
> 
> ##PP
> I have updated the text to match what is being used in RFC8667, section 2.2.2
> 
> 
>> "Other bits" -> "Reserved bits" -- labels should match
> 
> ##PP
> fixed
> 
>> 11.  Implementation Status
>> Does this section need a "RFC Ed.: Please Remove prior to publications"? It
>> seems pretty wrong to document current status of implementations permanently 
>> in
>> an Standards Track RFC.
> 
> ##PP
> yes this section will be removed prior to publication. This is a standard 
> procedure we follow.
> 
>> 12. IANA Considerations
>> An odd space between "sub- TLV".
> 
> ##PP
> fixed
> 
>> 12.5.  Sub-Sub-TLVs for SID Sub-TLVs
>> This section needs to better conform to registry creation standards (see
>> https://tools.ietf.org/html/rfc8126).
> 
> ##PP
> I updated the IANA section format similar to RFC8667.
> 
> 
>> ID-NITS:
>>   There are 19 instances of too long lines in the document, the longest one
>>   being 5 characters in excess of 72.
> 
> ##PP
> fixed.
> 
>> References:
>>   Normative:
>> Published: RFC 8754 draft-6man-segment-routing-header
> 
> ##PP
> fixed.
> 
> 
>> Out of date reference: [I-D.ietf-6man-spring-srv6-oam]
>> Out of date reference: [I-D.ietf-spring-srv6-network-programming]
> 
> ##PP
> Whenever the new version of draft-ietf-lsr-isis-srv6-extension is published 
> it picks the latest version, but as these drafts keep changing the reference 
> may get out of date quickly.
> 
> 
> 
>>   Informative:
>> Published: RFC 8402 draft-ietf-spring-segment-routing
> 
> ##PP
> fixed
> 
> thanks,
> Peter
> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
> 



signature.asc
Description: Message signed with OpenPGP
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Review of draft-ietf-lsr-isis-ttz-00.txt

[Christian Hopps]

> On Sep 22, 2020, at 1:21 AM, Donald Eastlake  wrote:
> 
> 
> One final question: I may be confused but my understanding of IS-IS is
> that there are Level 1 links, Level 2 links, and links that are both
> Level 1 and 2. A border router between Level 1 and Level 2 is a router
> that has both types of links attached to it. Such a router is a part
> of each Level 1 Area to which it is linked and a part of Level 2. So,
> the Level 1 / Level 2 boundary is, in a real sense, internal to such a
> border router.

Actually IS-IS is different than this (your last 2 sentences). This is a key 
conceptual difference between OSPF and IS-IS. In OSPF an OSPF router (instance) 
can be attached to several areas. In IS-IS an L1 or L1L2 router (instance) 
resides belongs to only a single L1 area. Thus in OSPF area boundaries exist 
within the OSPF instance, while in IS-IS the L1 area boundaries exists on the 
wire between L2 adjacencies.

Thanks,
Chris.


signature.asc
Description: Message signed with OpenPGP
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] IPR Call on "IGP Flexible Algorithm" - draft-ietf-lsr-flex-algo-11.txt

[Peter Psenak]

Hi Acee,

I am not aware of any IPR other than the one already disclosed below.

thanks,
Peter

On 01/10/2020 22:24, Acee Lindem (acee) wrote:

Authors,

The following IPR has been disclosed (excerpted from 
https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-lsr-flex-algo): 



*Date*



*ID*



*Statement*

2018-08-08



3248



Cisco's Statement about IPR related to draft-ietf-lsr-flex-algo 



2019-12-05



3910



Huawei Technologies Co.,Ltd's Statement about IPR related to 
draft-ietf-lsr-flex-algo 


Are you aware of any other IPR that applies to draft-ietf-lsr-flex-algo?

If so, has this IPR been disclosed in compliance with IETF IPR rules

(see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as a document author or contributor please respond

to this email regardless of whether or not you are aware of any

relevant IPR. *The response needs to be sent to the LSR WG mailing

list.* The document will not advance to the next stage until a

response has been received from each author and contributor.

If you are on the LSR WG email list but are not listed as an author or

contributor, then please explicitly respond only if you are aware of

any IPR that has not yet been disclosed in conformance with IETF rules.

Thanks,

Acee



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