Re: [Lsr] Generic metric: application-specific vs application-independent

[Les Ginsberg (ginsberg)]

Tony -

I assure you I am not talking about ASLA vs non-ASLA.
I am responding to your statement:

" That does not need to be signaled.  Configuration information SHOULD NOT be 
signaled."

Where "that" refers to the mapping of link attributes to an application.

I am saying not advertising this association is an interoperability disaster 
and has been proven to be so - and I pointed to the summary of cross-vendor 
RSVP-TE behavior as a definitive example of one such disaster.

If we disagree on that - so be it - but it is important to understand on what 
we disagree - otherwise the arguments we make on the consequences of that 
choice make no sense to each other.

   Les



> -Original Message-
> From: Tony Li  On Behalf Of Tony Li
> Sent: Friday, July 30, 2021 1:08 PM
> To: Les Ginsberg (ginsberg) 
> Cc: Peter Psenak (ppsenak) ; Shraddha Hegde
> ; Robert Raszuk ; Van De
> Velde, Gunter (Nokia - BE/Antwerp) ;
> lsr@ietf.org
> Subject: Re: [Lsr] Generic metric: application-specific vs application-
> independent
> 
> 
> Les,
> 
> >> That does not need to be signaled.  Configuration information SHOULD
> NOT
> >> be signaled. Yes, I realize that there is a great deal of precedent. No, I
> don’t
> >> agree with it.  It’s a lot of unnecessary development overhead.
> >>
> >>
> > [LES:] You are taking us back 20 years in time and reintroducing the
> problems that ASLA was defined to solve.
> >
> > It would be instructive to look at Figure 1 in
> https://datatracker.ietf.org/doc/html/draft-hegde-isis-advertising-te-
> protocols-03#section-1 .
> > The authors did a great job of documenting the state of affairs regarding
> RSVP-TE.
> > As you can see, implementations do not agree on what the necessary
> conditions are to consider a link as enabled for RSVP-TE.
> > Why didn’t we have interoperability issues?
> > The answer is that we did have interoperability issues. But
> vendors/customers managed to figure out what to configure to allow Vendor
> X to interoperate with Vendor Y.
> > It wasn't pretty.
> >
> > Keeping things that are needed for interoperability local is a recipe for
> trouble.
> >
> > I ask you (again) to read the Introduction to RFC 8919/8920 - which details
> the problems ASLA is trying to solve. These are not imaginary issues - they
> are issues actually encountered in real deployments.
> 
> 
> 
> We’re talking past each other.  I objected to ASLA in it’s entirety.  I have 
> been
> reprimanded by Acee and am trying to comply. Please consider that closed.
> 
> 
>  I am now trying to make a different point entirely.  Please hear this.
> 
> 
> My understanding is that we are still allowed to create TLVs outside of ASLA.
> If not, then we have a much bigger discussion.  ;-)
> 
> Assuming that you agree that we are allowed to do some things outside of
> ASLA, then we need to decide whether generic metrics should be inside or
> outside of ASLA. The point that I’m trying to make is that
> there is no practical benefit to putting it inside of ASLA.  With 256 
> different
> metrics, there is enough room to play. We do not need 256 metrics for RSVP,
> 256 for FlexAlgo, etc. etc.
> 
> Yes, I will happily stipulate that you COULD do it that way, but you don’t 
> have
> to and it adds overhead, so why would you?
> 
> 
> > [LES:] So you are proposing that all metrics - now and in the future - be
> restricted to Generic-Metric format?
> > I do not see why that is necessary - but if that is your intent, please 
> > state
> that explicitly in the draft so the WG can make an explicit call as to whether
> that is what we want to agree to do.
> > In the meantime, we already have three metric types (IGP, TE, Delay)
> which cannot be encoded in Generic-Metric - please document that in the
> draft.
> 
> 
> This is wholly orthogonal to the point of the discussion, so I will take this 
> to a
> separate thread.
> 
> Tony

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

Re: [Lsr] Generic metric: application-specific vs application-independent

[Les Ginsberg (ginsberg)]

Tony -

> -Original Message-
> From: Tony Li  On Behalf Of Tony Li
> Sent: Friday, July 30, 2021 11:25 AM
> To: Les Ginsberg (ginsberg) 
> Cc: Peter Psenak (ppsenak) ; Shraddha Hegde
> ; Robert Raszuk ; Van De
> Velde, Gunter (Nokia - BE/Antwerp) ;
> lsr@ietf.org
> Subject: Re: [Lsr] Generic metric: application-specific vs application-
> independent
> 
> Les,
> 
> >> If you don’t want application B to use metric M, then you create metric N
> and
> >> use that for application B.
> >
> > [LES:] The issue is...how do I indicate that Metric M is for App A (and NOT
> for App B) and that Metric N is for App B (and not for App A)?
> 
> 
> That does not need to be signaled.  Configuration information SHOULD NOT
> be signaled. Yes, I realize that there is a great deal of precedent. No, I 
> don’t
> agree with it.  It’s a lot of unnecessary development overhead.
> 
> 
[LES:] You are taking us back 20 years in time and reintroducing the problems 
that ASLA was defined to solve.

It would be instructive to look at Figure 1 in 
https://datatracker.ietf.org/doc/html/draft-hegde-isis-advertising-te-protocols-03#section-1
 .
The authors did a great job of documenting the state of affairs regarding 
RSVP-TE.
As you can see, implementations do not agree on what the necessary conditions 
are to consider a link as enabled for RSVP-TE.
Why didn’t we have interoperability issues?
The answer is that we did have interoperability issues. But vendors/customers 
managed to figure out what to configure to allow Vendor X to interoperate with 
Vendor Y.
It wasn't pretty.

Keeping things that are needed for interoperability local is a recipe for 
trouble. 

I ask you (again) to read the Introduction to RFC 8919/8920 - which details the 
problems ASLA is trying to solve. These are not imaginary issues - they are 
issues actually encountered in real deployments.



> > For Flex-algo this is possible because there is a FAD which specifies 
> > metric-
> type.
> > But in general, applications do NOT have the equivalent of FAD.
> 
> 
> Correct.  Future applications can be configured on a per-node basis as to
> what metric to use.
> 
> 
> > ASLA exists to address the generic problem of how do I establish the
> association of a link attribute with an application - NOT just how do I do 
> this
> for Flex.
> 
> 
> It exists to mask over a problem by creating separate spaces of attributes for
> identical TLVs.
> 
> In the case of the generic metric, you do NOT need separate spaces because
> you don’t have an issue with overlap.
> 
> 
> >> The generic metric is NOT one metric.  It’s a whole host of them.  Plenty 
> >> to
> go
> >> around. Multiple metrics per application, all out of the single space.
> >
> > [LES:] Sooo, why do we actually need a "Generic Metric sub-TLV"?
> 
> 
> I believe that the draft explained the desire to route on bandwidth pretty
> well. From there, it seemed best to generalize.  If we are going to have an
> additional metric, why should we add them one at a time?
> Computer science rule 2: One, two, many.  We’re past two.  :)
> 
> 
> > We could do the same thing by defining a new sub-TLV code point for each
> new metric-type that gets defined.
> 
> 
> Yes, but that seems pretty silly.  Let’s just create a space and allow
> administrators to route on any metric that they come up with.  Dollars per
> mile might well be a good metric. :-)
> 
> 
> > The only thing the generic metric sub-TLV does for us is allow a single sub-
> TLV codepoint to be used and let the metric-type within the Generic-Metric
> sub-TLV specify which metric type it is.
> > But this also comes with limitations. You can only use the Generic Metric
> advertisement for metric types which are represented by an integer metric
> value. If we look at the existing metrics defined in the IGP Metric Types
> Registry we see that not all metric types match - for example you cannot
> encode delay metric in the Generic Metric sub-TLV. The draft does not
> discuss this point - but it surely needs to do so.
> 
> 
> You could encode delay as an integer.  Just use the correct units.  Number of
> microseconds or nanoseconds might be appropriate.
> 
[LES:] So you are proposing that all metrics - now and in the future - be 
restricted to Generic-Metric format?
I do not see why that is necessary - but if that is your intent, please state 
that explicitly in the draft so the WG can make an explicit call as to whether 
that is what we want to agree to do.
In the meantime, we already have three metric types (IGP, TE, Delay) which 
cannot be encoded in Generic-Metric - please document that in the draft.

   Les

> 
> > I do not

Re: [Lsr] Generic metric: application-specific vs application-independent

[Les Ginsberg (ginsberg)]

Tony -

> -Original Message-
> From: Tony Li  On Behalf Of Tony Li
> Sent: Friday, July 30, 2021 9:55 AM
> To: Peter Psenak (ppsenak) 
> Cc: Shraddha Hegde ; Robert Raszuk
> ; Van De Velde, Gunter (Nokia - BE/Antwerp)
> ; Les Ginsberg (ginsberg)
> ; lsr@ietf.org
> Subject: Re: [Lsr] Generic metric: application-specific vs application-
> independent
> 
> 
> 
> > imagine you have an application A and B and a link X. You advertise
> application independent metric M on that link X because you want
> application A to use it.
> >
> > Application B is also enabled to use the metric M, but you do not want
> application B to use metric M on the link X (because you do not want
> application B to include the link X in its topology). How do you do that 
> without
> ASLA? The answer is you can’t
> 
> 
> That’s ok, because doing that would be silly.
> 
> If you don’t want application B to use metric M, then you create metric N and
> use that for application B.

[LES:] The issue is...how do I indicate that Metric M is for App A (and NOT for 
App B) and that Metric N is for App B (and not for App A)?

For Flex-algo this is possible because there is a FAD which specifies 
metric-type. 
But in general, applications do NOT have the equivalent of FAD.

ASLA exists to address the generic problem of how do I establish the 
association of a link attribute with an application - NOT just how do I do this 
for Flex.

> 
> The generic metric is NOT one metric.  It’s a whole host of them.  Plenty to 
> go
> around. Multiple metrics per application, all out of the single space.

[LES:] Sooo, why do we actually need a "Generic Metric sub-TLV"?

We could do the same thing by defining a new sub-TLV code point for each new 
metric-type that gets defined.
The only thing the generic metric sub-TLV does for us is allow a single sub-TLV 
codepoint to be used and let the metric-type within the Generic-Metric sub-TLV 
specify which metric type it is.
But this also comes with limitations. You can only use the Generic Metric 
advertisement for metric types which are represented by an integer metric 
value. If we look at the existing metrics defined in the IGP Metric Types 
Registry we see that not all metric types match - for example you cannot encode 
delay metric in the Generic Metric sub-TLV. The draft does not discuss this 
point - but it surely needs to do so.

I do not object to the Generic Metric sub-TLV definition, but you need to 
understand that it is not usable for all types of metrics that may be defined.

Les

> 
> Tony

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

Re: [Lsr] draft-decraene-lsr-isis-flooding-speed & IETF 111

[Les Ginsberg (ginsberg)]

Guillaume –

Please see LES2: inline.

From: guillaume.solig...@orange.com<mailto:guillaume.solig...@orange.com> 
mailto:guillaume.solig...@orange.com>>
Sent: Thursday, July 29, 2021 10:34 AM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; 
bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>; 
lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>
Subject: Re: [Lsr] draft-decraene-lsr-isis-flooding-speed & IETF 111


Les,

Thanks for taking your time to answer.
Le 29/07/2021 à 18:26, Les Ginsberg (ginsberg) a écrit :
Guillaume –

Thanx for the thoughtful response.
Responses inline.

From: guillaume.solig...@orange.com<mailto:guillaume.solig...@orange.com> 
<mailto:guillaume.solig...@orange.com>
Sent: Thursday, July 29, 2021 3:20 AM
To: Les Ginsberg (ginsberg) <mailto:ginsb...@cisco.com>; 
bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>; 
lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>
Subject: Re: [Lsr] draft-decraene-lsr-isis-flooding-speed & IETF 111

Hello Les,

Jumping in since I have some insight as well.
Le 29/07/2021 à 08:51, Les Ginsberg (ginsberg) a écrit :
Bruno –

Resuming this thread…

I assure you that we have the same goals.
We are not yet in agreement on the best way to achieve those goals.
Your slides show indeed we have the same goal, and we agree on one way to deal 
with the matter (congestion control).



Looking forward to the WG discussion on Friday.

To get some discussion going in advance – if you have time to do so (which I 
know is challenging especially during IETF week) – I call your attention to 
slides 15-18 in the presentation we have prepared:

https://datatracker.ietf.org/meeting/111/materials/slides-111-lsr-21-isis-flood-scale-00

I do not intend to present these slides during my portion of the presentation 
time – but I included them as potential points of discussion during the 
discussion portion of the meeting (though the WG chairs will decide how best to 
direct that portion of the time).
I call your attention specifically to Slide 16, which discusses the functional 
elements in the input path typically seen on router platforms.
Each of these elements has controls associated with it – from queue sizes to 
punt rates, etc. that play a significant role in delivery of incoming IS-IS 
PDUs to the protocol running in the control plan.

Your slides – 
https://datatracker.ietf.org/meeting/111/materials/slides-111-lsr-22-flow-congestion-control-00
 focus only on the direct input queue to IS-IS in the control plane. I do not 
see how the state of the other staging elements on the path from PDU ingress to 
IS-IS implementation reading the PDUs in the control plane is known and/or used 
in determining the flow control state signaled to the transmitting neighbor. 
If, for example, PDUs were being dropped on ingress and never made it to IS-IS 
in the control plane, how would your algorithm be aware of this and react to 
this?

In my experience, the state of these lower level staging elements plays a 
significant role.

I can imagine that some form of signaling from the dataplane to the control 
plane about the state of these lower level elements could be possible – and 
that signaling could be used as input to a receiver based control algorithm. 
However, given the differences as to how individual platforms implement these 
lower level elements,  I see it as challenging to get each platform to provide 
the necessary signaling in real time and to normalize it in a way so that IS-IS 
flow control logic in the control plane can use the data in a platform 
independent way. I believe this represents a significant bar to successful 
deployment of receiver-based flow control.

That's one point we want to clarify, the flow control algorithm does not focus 
on the "IO path" between the line card and the control plane. There is no magic 
there, it does not directly deals with congestion on the IO path. It happens it 
has some nice properties even in case of drops before reaching the control 
plane, but it's arguably not sufficient. That's why we also propose a 
congestion control algorithm. While it is not necessary to establish a standard 
since it's only local, it helps having a baseline if one does not want to spend 
time re-developing its own algorithm.

Our slides also show the result of our congestion control algorithm, which is 
the part that deals with IO path losses. Very much like your algorithm, ours 
sees this IO path as a black box.

[LES:] This is an aspect on which I need further clarification.

From the POV of the control plane, in the absence of enhanced signaling (which 
I believe is problematic to implement – and you seem to agree) you simply have 
no knowledge as to whether incoming PDUs have been dropped or are simply 
delayed.
[GS] From the receiver side, absolutely.
[LES2:] T

Re: [Lsr] draft-decraene-lsr-isis-flooding-speed & IETF 111

[Les Ginsberg (ginsberg)]

Guillaume –

Thanx for the thoughtful response.
Responses inline.

From: guillaume.solig...@orange.com 
Sent: Thursday, July 29, 2021 3:20 AM
To: Les Ginsberg (ginsberg) ; bruno.decra...@orange.com; 
lsr-cha...@ietf.org
Cc: lsr@ietf.org
Subject: Re: [Lsr] draft-decraene-lsr-isis-flooding-speed & IETF 111

Hello Les,

Jumping in since I have some insight as well.
Le 29/07/2021 à 08:51, Les Ginsberg (ginsberg) a écrit :
Bruno –

Resuming this thread…

I assure you that we have the same goals.
We are not yet in agreement on the best way to achieve those goals.
Your slides show indeed we have the same goal, and we agree on one way to deal 
with the matter (congestion control).


Looking forward to the WG discussion on Friday.

To get some discussion going in advance – if you have time to do so (which I 
know is challenging especially during IETF week) – I call your attention to 
slides 15-18 in the presentation we have prepared:

https://datatracker.ietf.org/meeting/111/materials/slides-111-lsr-21-isis-flood-scale-00

I do not intend to present these slides during my portion of the presentation 
time – but I included them as potential points of discussion during the 
discussion portion of the meeting (though the WG chairs will decide how best to 
direct that portion of the time).
I call your attention specifically to Slide 16, which discusses the functional 
elements in the input path typically seen on router platforms.
Each of these elements has controls associated with it – from queue sizes to 
punt rates, etc. that play a significant role in delivery of incoming IS-IS 
PDUs to the protocol running in the control plan.

Your slides – 
https://datatracker.ietf.org/meeting/111/materials/slides-111-lsr-22-flow-congestion-control-00
 focus only on the direct input queue to IS-IS in the control plane. I do not 
see how the state of the other staging elements on the path from PDU ingress to 
IS-IS implementation reading the PDUs in the control plane is known and/or used 
in determining the flow control state signaled to the transmitting neighbor. 
If, for example, PDUs were being dropped on ingress and never made it to IS-IS 
in the control plane, how would your algorithm be aware of this and react to 
this?

In my experience, the state of these lower level staging elements plays a 
significant role.

I can imagine that some form of signaling from the dataplane to the control 
plane about the state of these lower level elements could be possible – and 
that signaling could be used as input to a receiver based control algorithm. 
However, given the differences as to how individual platforms implement these 
lower level elements,  I see it as challenging to get each platform to provide 
the necessary signaling in real time and to normalize it in a way so that IS-IS 
flow control logic in the control plane can use the data in a platform 
independent way. I believe this represents a significant bar to successful 
deployment of receiver-based flow control.

That's one point we want to clarify, the flow control algorithm does not focus 
on the "IO path" between the line card and the control plane. There is no magic 
there, it does not directly deals with congestion on the IO path. It happens it 
has some nice properties even in case of drops before reaching the control 
plane, but it's arguably not sufficient. That's why we also propose a 
congestion control algorithm. While it is not necessary to establish a standard 
since it's only local, it helps having a baseline if one does not want to spend 
time re-developing its own algorithm.

Our slides also show the result of our congestion control algorithm, which is 
the part that deals with IO path losses. Very much like your algorithm, ours 
sees this IO path as a black box.

[LES:] This is an aspect on which I need further clarification.

From the POV of the control plane, in the absence of enhanced signaling (which 
I believe is problematic to implement – and you seem to agree) you simply have 
no knowledge as to whether incoming PDUs have been dropped or are simply 
delayed.

On Slide 6 you say: “Sender will never send more than RWin unacknowledged 
LSPs”. On Slide 7 you describe how to choose RWIN. But all of these methods are 
fixed in size – not adaptive. And since the input queue of packets to IS-IS is 
not “per interface”, the number you choose for RWIN seems to have nothing at 
all to do with current state/neighbor.

You then go on to discuss RTT (which seems to be a configured or pre-determined 
value??) and LPP (LSPs acked/PSNP) – which is only meaningful for the LSPs that 
have actually made their way to IS-IS – no way to account for those that have 
been dropped or delayed.

So it is difficult for me to understand how you are actually accounting for the 
current state of the I/O path in real time on a per neighbor basis.

This is one major reason why we prefer a Tx based flow control mechanism. Tx 
based flow control simply focuses on the 

Re: [Lsr] draft-decraene-lsr-isis-flooding-speed & IETF 111

[Les Ginsberg (ginsberg)]

Bruno –

Resuming this thread…

I assure you that we have the same goals.
We are not yet in agreement on the best way to achieve those goals.

Looking forward to the WG discussion on Friday.

To get some discussion going in advance – if you have time to do so (which I 
know is challenging especially during IETF week) – I call your attention to 
slides 15-18 in the presentation we have prepared:

https://datatracker.ietf.org/meeting/111/materials/slides-111-lsr-21-isis-flood-scale-00

I do not intend to present these slides during my portion of the presentation 
time – but I included them as potential points of discussion during the 
discussion portion of the meeting (though the WG chairs will decide how best to 
direct that portion of the time).
I call your attention specifically to Slide 16, which discusses the functional 
elements in the input path typically seen on router platforms.
Each of these elements has controls associated with it – from queue sizes to 
punt rates, etc. that play a significant role in delivery of incoming IS-IS 
PDUs to the protocol running in the control plan.

Your slides – 
https://datatracker.ietf.org/meeting/111/materials/slides-111-lsr-22-flow-congestion-control-00
 focus only on the direct input queue to IS-IS in the control plane. I do not 
see how the state of the other staging elements on the path from PDU ingress to 
IS-IS implementation reading the PDUs in the control plane is known and/or used 
in determining the flow control state signaled to the transmitting neighbor. 
If, for example, PDUs were being dropped on ingress and never made it to IS-IS 
in the control plane, how would your algorithm be aware of this and react to 
this?

In my experience, the state of these lower level staging elements plays a 
significant role.

I can imagine that some form of signaling from the dataplane to the control 
plane about the state of these lower level elements could be possible – and 
that signaling could be used as input to a receiver based control algorithm. 
However, given the differences as to how individual platforms implement these 
lower level elements,  I see it as challenging to get each platform to provide 
the necessary signaling in real time and to normalize it in a way so that IS-IS 
flow control logic in the control plane can use the data in a platform 
independent way. I believe this represents a significant bar to successful 
deployment of receiver-based flow control.

This is one major reason why we prefer a Tx based flow control mechanism. Tx 
based flow control simply focuses on the relative rates of LSP transmission and 
reception of Acknowledgments. Whether slower acks are due to PDU drops at 
ingress, slow punt path operation, lack of CPU time for IS-IS to process the 
incoming packets, etc. matters not. Whatever the reason, if acks are not 
keeping pace with transmission we know we have to slow down.

Please comment on these points as you have time.

Thanx.

   Les

From: bruno.decra...@orange.com 
Sent: Monday, July 12, 2021 1:48 AM
To: Les Ginsberg (ginsberg) ; lsr-cha...@ietf.org
Cc: lsr@ietf.org
Subject: RE: draft-decraene-lsr-isis-flooding-speed & IETF 111

Les,

Faster flooding may be achieved without protocol extension. But if we are at 
changing flooding, it would be reasonable to try to make it good (rather than 
just faster than today).
In particular some goals are:
- faster flooding when the receiver has free cycles
- slower flooding when the receiver is busy/congested (either by flooding, or 
any CPU computation including not coming from IS-IS)
- avoiding/minimizing the parameters that the network operator is been asked to 
tune
- avoiding/minimizing the loss of LSPs
- robust to a wide variety of conditions (good ones and bad ones)

You seem to agree on changing the flooding behaviour on both the sender and the 
receiver so that they can better cooperate. That’s protocol extension to me 
(and IMHO much bigger than the sending of info in one TLV)

Bruno

From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Friday, July 9, 2021 7:49 PM
To: DECRAENE Bruno INNOV/NET 
mailto:bruno.decra...@orange.com>>; 
lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>
Subject: RE: draft-decraene-lsr-isis-flooding-speed & IETF 111

Bruno –

Neither of us has presented anything new of substance in the last few IETFs.
There were two presentations recently - one by Arista and one by Huawei – each 
of which simply demonstrated that it is possible to flood faster - and that in 
order to do so it is helpful to send acks faster - both points on which there 
is no disagreement.

To have a productive discussion we both need to present new data - which is why 
having the discussion as part of the meeting at which the presentations occur 
makes sense to me.

We removed the example(sic) algorithm from our draft because it was only an 
example, is not normative, and we did not want the discussion of 

Re: [Lsr] Generic metric: application-specific vs application-independent

[Les Ginsberg (ginsberg)]

Tony –

You ask very important questions – but – as Acee has answered in a subsequent 
email – all of these questions were openly debated in the WG during the work on 
what became RFC8919/8920. This debate was contentious, took years, and the WG 
eventually reached consensus on what became the two RFCs.

If every time a new attribute is defined we reopen the original debate, then we 
will never move forward and we will have great difficulty in deploying 
interoperable implementations.

I can respect that you might have preferred a different conclusion on the part 
of the WG – but I hope you will also acknowledge that this is now a resolved 
issue and we need to move forward following the existing RFCs.

Parenthetically, I do believe that answers to your questions can be found in 
the RFCs. The answers may not satisfy you – but we did attempt to include the 
context which drove the ASLA solution.
Thanx.

Les


From: Lsr  On Behalf Of Tony Li
Sent: Wednesday, July 28, 2021 1:06 PM
To: Les Ginsberg (ginsberg) 
Cc: lsr@ietf.org; Shraddha Hegde 
Subject: Re: [Lsr] Generic metric: application-specific vs 
application-independent


Les,

ASLA exists to support the advertisement of attributes which can be used in 
application specific ways.


Why do we need separate and different copies of attributes for different 
applications?

The SRLG tries to capture the risk relationships between multiple links. Those 
relationships don’t change depending on the application.

Link attributes don’t require the variability that ASLA provides, and the 
overhead is high.  How does this cost/benefit ratio make sense?



In any particular deployment case, a given attribute advertisement might be 
used by one app, multiple apps, or all apps.
ASLA allows to unambiguously support all of these cases with a single 
advertisement encoding format.

The correct question to be resolving here is indeed the question which has been 
discussed in an earlier thread: Is Generic Metric a link attribute which can 
have application specific use cases? I think the question to that is 
unquestionably “yes”.
That should be enough (IMO of course) to close the discussion.


Well, one nice thing is that there is an entire space of metrics available.  If 
application A wants to use metric 16 and application B wants to use metric 122, 
that’s already doable.

Why do we need a separate space per application

Tony

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

Re: [Lsr] Generic metric: application-specific vs application-independent

[Les Ginsberg (ginsberg)]

Tony –

IMO, you are asking the wrong question. 

ASLA exists to support the advertisement of attributes which can be used in 
application specific ways.
In any particular deployment case, a given attribute advertisement might be 
used by one app, multiple apps, or all apps.
ASLA allows to unambiguously support all of these cases with a single 
advertisement encoding format.

The correct question to be resolving here is indeed the question which has been 
discussed in an earlier thread: Is Generic Metric a link attribute which can 
have application specific use cases? I think the question to that is 
unquestionably “yes”.
That should be enough (IMO of course) to close the discussion.

   Les

From: Lsr  On Behalf Of Tony Li
Sent: Wednesday, July 28, 2021 11:23 AM
To: Shraddha Hegde 
Cc: lsr@ietf.org
Subject: Re: [Lsr] Generic metric: application-specific vs 
application-independent


FWIW, I think that this is the wrong question.

I think that a better question is: Is there a usecase that is so overwhelmingly 
compelling that the added complexity of ASLA is warranted?

Tony



On Jul 28, 2021, at 11:18 AM, Shraddha Hegde 
mailto:shraddha=40juniper@dmarc.ietf.org>>
 wrote:

WG,

   Generic metric as described in 
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-bw-con
   can advertise multiple metric-types and values and be used
   by any application. All the use cases that I heard from network
   operators while writing the draft could be solved
   using generic-metric advertised in an application-independent way.

   I am looking for clear description of use cases that would benefit from 
advertising
   generic metric in an application specific way. Can any one provide such a 
usecase?

Rgds
Shraddha

Juniper Business Use Only
___
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] draft-ietf-lsr-flex-algo-17 (was: I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt)

[Les Ginsberg (ginsberg)]

Ron -

Link attributes have since Day 1 (i.e., publication of RFC 3784 (precursor to 
RFC 5305)) been associated with sub-TLV advertisements.
Both RFC 8919 and the Flex Algo draft are discussing attributes advertised in 
sub-TLVs.

IGP metric has never been advertised in a sub-TLV (or even proposed to be). 
Therefore it isn’t at all clear to me why you think anything regarding encoding 
of link attributes discussed in the above documents could or should be applied 
to IGP metric advertisement.

It may be true that "link attributes" could be interpreted to apply to aspects 
advertised in TLV 22 base encoding. This includes: Neighbor system-id and IGP 
metric.
Are you confused about both of these? Do you believe that ASLA/Flex documents 
could be interpreted to apply to Neighbor ID as well as IGP metric?
If so, then you need to explain how you reached this conclusion as I do not 
understand it.

   Les


> -Original Message-
> From: Ron Bonica 
> Sent: Monday, July 26, 2021 11:31 AM
> To: Peter Psenak (ppsenak) ; Acee Lindem (acee)
> ; Les Ginsberg (ginsberg)
> ; Shraddha Hegde ;
> gregory.mir...@ztetx.com; lsr@ietf.org
> Cc: draft-ietf-lsr-flex-algo-bw-con.auth...@ietf.org
> Subject: RE: draft-ietf-lsr-flex-algo-17 (was: [Lsr] I-D Action: 
> draft-ietf-lsr-
> flex-algo-bw-con-01.txt)
> 
> Peter,
> 
> I think that we are using the term "link attribute" differently. IMO, a link
> attribute is any attribute of a link, regardless of whether it is advertised 
> in the
> fixed portion of a link advertisement or in a TLV.
> 
> Are you assuming otherwise? If so, why?
> 
>Ron
> 
> 
> 
> Juniper Business Use Only
> 
> -Original Message-
> From: Peter Psenak 
> Sent: Monday, July 26, 2021 1:31 PM
> To: Ron Bonica ; Acee Lindem (acee)
> ; Les Ginsberg (ginsberg)
> ; Shraddha Hegde ;
> gregory.mir...@ztetx.com; lsr@ietf.org
> Cc: draft-ietf-lsr-flex-algo-bw-con.auth...@ietf.org
> Subject: Re: draft-ietf-lsr-flex-algo-17 (was: [Lsr] I-D Action: 
> draft-ietf-lsr-
> flex-algo-bw-con-01.txt)
> 
> [External Email. Be cautious of content]
> 
> 
> Hi Ron,
> 
> On 26/07/2021 18:36, Ron Bonica wrote:
> > Acee,
> >
> > We may also need to clean up an inconsistency in 
> > draft-ietf-lsr-flex-algo-17.
> Section 12 of that document says:
> >
> > "   Link attribute advertisements that are to be used during Flex-
> > Algorithm calculation MUST use the Application-Specific Link
> > Attribute (ASLA) advertisements defined in [RFC8919] or [RFC8920],
> > unless, in the case of IS-IS, the L-Flag is set in the ASLA
> > advertisement.  If the L-Flag is set, as defined in [RFC8919]
> > Section 4.2 subject to the constraints discussed in Section 6 of the
> > [[RFC8919], then legacy advertisements are to be used instead. "
> >
> > However, Flex-Algorithm calculations include the IGP metric.
> 
> 
> IGP metric is not advertised as a link attribute, it is part of the fixed 
> portion of
> the link advertisement. So the above text is not affecting the usage if the 
> IGP
> metric.
> 
> thanks,
> Peter
> 
> 
> >
> >
> > Ron
> >
> >
> >
> > Juniper Business Use Only
> >
> > -Original Message-
> > From: Acee Lindem (acee) 
> > Sent: Friday, July 23, 2021 10:13 AM
> > To: Ron Bonica ; Les Ginsberg (ginsberg)
> > ; Shraddha Hegde ;
> > gregory.mir...@ztetx.com; Peter Psenak (ppsenak)
> ;
> > lsr@ietf.org
> > Cc: draft-ietf-lsr-flex-algo-bw-con.auth...@ietf.org
> > Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt
> >
> > [External Email. Be cautious of content]
> >
> >
> > Hi Ron,
> >
> > So perhaps, generic metric is not a legacy advertisement as strictly 
> > defined.
> However, we don't want to go down the path of treating new attributes in
> the same manner as legacy attributes. It seems the discussion is progressing
> and hopefully we will have a resolution.
> >
> > Thanks,
> > Acee
> >
> > On 7/22/21, 1:28 PM, "Ron Bonica"
>  wrote:
> >
> >  Acee,
> >
> >  I don't think that draft-ietf-lsr-flex-algo-bw-con violates RFC 8919.
> >
> >  Section 6.1 of RFC 8919 says:
> >
> >  " New applications that future documents define to make use of the
> > advertisements defined in this document MUST NOT make use of
> legacy
> > advertisements.  This simplifies deployment of new applications by
> > eliminating the need 

Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt

[Les Ginsberg (ginsberg)]

Gyan –

I do not see Generic Metric as an application independent link attribute.
It is an attribute that could be used by multiple applications – in which case 
you would advertise it in ASLA with the logical OR of all of the applications 
using it.

The only existing example of an application independent attribute is Maximum 
Link Bandwidth. This is an attribute of the physical link – independent of the 
application(s) which use it – in which case 
https://www.rfc-editor.org/rfc/rfc8919.html#section-4.2.1 applies.
If some other attribute is ever defined which has the same characteristic, then 
I would expect the same advertisement model to be used.

Metric – in all its forms (whether TE, Delay, or now Generic) – is not a 
property of the physical link. It is – as Peter has described - a value that is 
configured or computed to be used by one or more applications. I do not see the 
need to define an application independent method of advertising it.

If one believes that legacy applications such as RSVP-TE will be extended to 
support Generic Metric, then a valid argument can be made for supporting 
advertisement of Generic Metric as a direct sub-TLV in TLVs 22 et al as well as 
ASLA. I would be somewhat surprised if RSVP-TE were extended in this way, but 
that is up to the marketplace to decide.

   Les

From: Gyan Mishra 
Sent: Friday, July 23, 2021 11:44 AM
To: Peter Psenak (ppsenak) 
Cc: Acee Lindem (acee) ; Les Ginsberg (ginsberg) 
; Ron Bonica ; Shraddha Hegde 
; draft-ietf-lsr-flex-algo-bw-con.auth...@ietf.org; 
gregory.mir...@ztetx.com; lsr@ietf.org
Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt


Peter

How would you advertise Generic metric link attribute in Flex Algo as both ASLA 
and application independent?

For ASLA you set the bit vector but application independent in ASLA what do you 
do?

Kind Regards

Gyan

On Fri, Jul 23, 2021 at 4:19 AM Peter Psenak 
mailto:40cisco@dmarc.ietf.org>> wrote:
Hi Ron,

keeping the normative statements aside.

We are defining a Generic Metric TLV.

1. The first and only defined usage at this point is for Flex-algo.

2. Generic Metric is not something that must be defined as application
independent, on the contrary, it's a value that is either assigned by
operator or computed somehow. Advertising application specific values
not only make sense, but would add value. TE metric is an example which
is very close to Generic Metric and is supported in ASLA.

3. Flex-algo is an application from the ASLA framework perspective and
so far is only using ASLA encoded link attributes. It would make sense
to continue to do so for Generic Metric.

4. If you feel you need the Generic Metric also as an application
independent value, I'm fine, although I do not see the immediate use case.

Given the above, would not you thing that advertising Generic Metric in
ASLA make sense?

thanks,
Peter








On 23/07/2021 06:13, Ron Bonica wrote:
> Les,
>
> Please, let us avoid discussion of whether my message is disingenuous. As 
> Acee will agree, discussion of my internal motivations and moral deficiencies 
> is beyond the scope of the LSR WG.
>
> Now, let us address my point and your counter points. My point was that 
> draft-ietf-lsr-flex-algo-bw-con does not violate RFC 8919. Nothing more, 
> nothing less.
>
> In your counterpoint #1, you point out tension between 
> draft-ietf-lsr-flex-algo-bw-con and draft-ietf-lsr-flex-algo. While this 
> point deserves discussion, it is orthogonal to my point. It is entirely 
> possible that both of the following statements are true:
>
> - draft-ietf-lsr-flex-algo-bw-con does not violate RFC 8919
> - there is tension between draft-ietf-lsr-flex-algo-bw-con and 
> draft-ietf-lsr-flex-algo
>
> In your counterpoint #2, you talk about the "clear intent" of RFC 8919. 
> Section 6.1 of RFC 8919 reduces that intent to a few very clear normative 
> statements. Draft-ietf-lsr-flex-algo-bw-con does not violate any of those 
> normative statements. Therefore, it does not violate RFC 8919.
>
> You may say:
>
> - Section 6.1 should have included more prohibitions
> - The authors had additional prohibitions in mind when they wrote the draft, 
> but failed to add them to Section 6.1
>
> That's all fine, but the community agreed only to the words on the page, not 
> the authors larger intent.
>
>       
>  Ron
>
>
>
>
>
> Juniper Business Use Only
>
> -Original Message-
> From: Les Ginsberg (ginsberg) 
> mailto:40cisco@dmarc.ietf.org>>
> Sent: Thursday, July 22, 2021 2:49 PM
> To: Ron Bonica mailto:rbon...@juniper.net>>; Acee Lindem 
> (acee) mailto:a...@cisco.com>>; Shraddha Hegde 
> mailto:shrad...@juniper.net>>; 
> gregory.mir...@zt

Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt

[Les Ginsberg (ginsberg)]

Gyan –

This question has been clearly addressed by Peter in his most recent post:


2. Generic Metric is not something that must be defined as application
independent, on the contrary, it's a value that is either assigned by
operator or computed somehow. Advertising application specific values
not only make sense, but would add value. TE metric is an example which
is very close to Generic Metric and is supported in ASLA.


Please read his email for the complete response.

   Les

From: Gyan Mishra 
Sent: Friday, July 23, 2021 8:26 AM
To: Les Ginsberg (ginsberg) 
Cc: Acee Lindem (acee) ; Peter Psenak (ppsenak) 
; Ron Bonica ; Shraddha Hegde 
; draft-ietf-lsr-flex-algo-bw-con.auth...@ietf.org; 
gregory.mir...@ztetx.com; lsr@ietf.org
Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt



I believe the gap is whether or not the Generic metric is like maximum 
bandwidth link attribute which is application independent and based on the use 
case in this draft of the WG can be convinced that this use case is for 
application independent.

In RFC 8919 and RFC 8920 the normative language was chosen precisely for that 
purpose so that on a case by case basis for a an link attribute to be deemed 
ASLA or application independent.

Kind Regards

Gyan

On Thu, Jul 22, 2021 at 3:44 PM Gyan Mishra 
mailto:hayabusa...@gmail.com>> wrote:

As stated nicely by Les, the  goal and intent of RFC 8919 and 8920 as stated 
clearly was meant to fix a ambiguities  related to cases where multiple 
applications RSVP-TE, SR, Flex Algo making use of link attributes by creating 
ASLA for a  list of link attributes sub-tlv’s that existed at time of writing 
the document, however moving forward that all new link attributes defined MUST 
now be advertised using ASLA sub tlv.

By not doing do you are perpetuating the problem all over again.

The chairs and other in the WG would like to draw a line in the sand that any 
new link attribute MUST be advertised using ASLA SUB-TLV encoding.

RFC 8919 -Last paragraph in the introduction


   This document defines extensions that address these issues.  Also, as

   evolution of use cases for link attributes can be expected to

   continue in the years to come, this document defines a solution that

   is easily extensible to the introduction of new applications and new

   use cases.



RFC 8920- Last paragraph in the introduction



   This document defines extensions that address these issues.  Also, as

   evolution of use cases for link attributes can be expected to

   continue in the years to come, this document defines a solution that

   is easily extensible for the introduction of new applications and new

   use cases.



The key is the extensibility of RFC 8919 and RFC   8920 for all future link 
attributes and not just the ones defined when the draft was written.

Kind Regards

Gyan






On Thu, Jul 22, 2021 at 2:49 PM Les Ginsberg (ginsberg) 
mailto:40cisco@dmarc.ietf.org>> wrote:
Ron -

With respect, it is hard to read your email without feeling that it is 
disingenuous.

But, let's cover the relevant points nonetheless.

Point #1:

https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-17#section-12 
states:

" Link attribute advertisements that are to be used during Flex-
   Algorithm calculation MUST use the Application-Specific Link
   Attribute (ASLA) advertisements defined in [RFC8919] or [RFC8920]..."

As the new generic-metric is intended for use by flex-algo it needs to conform 
to this normative statement.

Point #2:

RFC 8919 and 8920 were written to address ambiguities associated with the use 
of multiple applications.
The Introduction sections of both documents discuss this in some detail.

The clear intent is to make use of ASLA going forward - not to restrict ASLA 
only to the set of link attributes defined at the time of the writing of the 
RFCs. Failure to do so would reintroduce the same set of issues that RFC 
8919/8920 were written to address.
Your attempt to infer that because Generic-Metric was not defined at the time 
that RFC 8919/8920 were written that the RFCs don’t apply to it makes no sense.
ASLA is in fact a revision to the link attribute architecture and is meant to 
be used going forward.

The more appropriate question to ask is why we need to define a legacy style 
sub-TLV for new link attributes? Ketan has made this point in his post on this 
thread and I have sympathy with his position.

We do understand that legacy applications such as RSVP-TE may continue to be 
deployed in networks for some time to come. It is not reasonable to expect that 
legacy application implementations will be updated to use ASLA, which is why I 
do not object to defining a legacy style encoding for Generic Metric if folks 
believe that legacy applications may be enhanced to support new link attributes.

I strongly disagree with your interpretation that ASLA is limited only to the 
code points defined in RFC 8919/8920.

  

Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt

[Les Ginsberg (ginsberg)]

Ron -

Dealing simply with the language in the RFCs, both RFCs discuss the problems 
the RFCs are aimed at solving in the Introduction. Those problems are not 
specific to the set of link attributes defined at the time of writing the RFCs. 
Which is why the Introduction concludes with:

"...as evolution of use cases for link attributes can be expected to
   continue in the years to come, this document defines a solution that
   is easily extensible to the introduction of new applications and new
   use cases."

Which is exactly what is being introduced in draft-ietf-lsr-flex-algo-bw-con.

There is then the more important question as to why new attributes - and 
Generic Metric specifically - should NOT follow the ASLA model. The same issues 
discussed in the RFCs that motivated the ASLA solution certainly apply to 
Generic Metric. This has been made clear by others in their responses to this 
thread - and each of the arguments Shraddha has made have been countered by 
responses in this thread. The substance of what is being discussed here is not 
(and should not be) whether there is a violation of the "letter of the law" - 
but whether there is a behavioral aspect of the new attribute that makes ASLA 
unsuitable. On that point I think clear and cogent arguments have been made 
that ASLA is appropriate and necessary.

If the WG feels that more explicit language is needed to prevent such debates 
in the future, I am happy to work on an Errata - but that isn’t the substance 
of this discussion and I would much prefer that any future posts on this thread 
focus on the substantive issues. We can address improving the RFC language 
separately.

   Les


> -Original Message-
> From: Ron Bonica 
> Sent: Thursday, July 22, 2021 9:13 PM
> To: Les Ginsberg (ginsberg) ; Acee Lindem (acee)
> ; Shraddha Hegde ;
> gregory.mir...@ztetx.com; Peter Psenak (ppsenak) ;
> lsr@ietf.org
> Cc: draft-ietf-lsr-flex-algo-bw-con.auth...@ietf.org
> Subject: RE: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt
> 
> Les,
> 
> Please, let us avoid discussion of whether my message is disingenuous. As
> Acee will agree, discussion of my internal motivations and moral deficiencies
> is beyond the scope of the LSR WG.
> 
> Now, let us address my point and your counter points. My point was that
> draft-ietf-lsr-flex-algo-bw-con does not violate RFC 8919. Nothing more,
> nothing less.
> 
> In your counterpoint #1, you point out tension between draft-ietf-lsr-flex-
> algo-bw-con and draft-ietf-lsr-flex-algo. While this point deserves 
> discussion,
> it is orthogonal to my point. It is entirely possible that both of the 
> following
> statements are true:
> 
> - draft-ietf-lsr-flex-algo-bw-con does not violate RFC 8919
> - there is tension between draft-ietf-lsr-flex-algo-bw-con and draft-ietf-lsr-
> flex-algo
> 
> In your counterpoint #2, you talk about the "clear intent" of RFC 8919.
> Section 6.1 of RFC 8919 reduces that intent to a few very clear normative
> statements. Draft-ietf-lsr-flex-algo-bw-con does not violate any of those
> normative statements. Therefore, it does not violate RFC 8919.
> 
> You may say:
> 
> - Section 6.1 should have included more prohibitions
> - The authors had additional prohibitions in mind when they wrote the draft,
> but failed to add them to Section 6.1
> 
> That's all fine, but the community agreed only to the words on the page, not
> the authors larger intent.
> 
>       
> Ron
> 
> 
> 
> 
> 
> Juniper Business Use Only
> 
> -Original Message-
> From: Les Ginsberg (ginsberg) 
> Sent: Thursday, July 22, 2021 2:49 PM
> To: Ron Bonica ; Acee Lindem (acee)
> ; Shraddha Hegde ;
> gregory.mir...@ztetx.com; Peter Psenak (ppsenak) ;
> lsr@ietf.org
> Cc: draft-ietf-lsr-flex-algo-bw-con.auth...@ietf.org
> Subject: RE: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt
> 
> [External Email. Be cautious of content]
> 
> 
> Ron -
> 
> With respect, it is hard to read your email without feeling that it is
> disingenuous.
> 
> But, let's cover the relevant points nonetheless.
> 
> Point #1:
> 
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-
> ietf-lsr-flex-algo-17*section-12__;Iw!!NEt6yMaO-gk!XOCcoj-
> YdMkhznRiGAo1oeY1A6HMHuk5BDmsYqHAUf_hYgKb9tlp_Umpu3UxZFFM$
> states:
> 
> " Link attribute advertisements that are to be used during Flex-
>Algorithm calculation MUST use the Application-Specific Link
>Attribute (ASLA) advertisements defined in [RFC8919] or [RFC8920]..."
> 
> As the new generic-metric is intended for use by flex-algo it needs to
> conform to this no

Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt

[Les Ginsberg (ginsberg)]

Ron -

With respect, it is hard to read your email without feeling that it is 
disingenuous.

But, let's cover the relevant points nonetheless.

Point #1:

https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-17#section-12 
states:

" Link attribute advertisements that are to be used during Flex-
   Algorithm calculation MUST use the Application-Specific Link
   Attribute (ASLA) advertisements defined in [RFC8919] or [RFC8920]..."

As the new generic-metric is intended for use by flex-algo it needs to conform 
to this normative statement.

Point #2:

RFC 8919 and 8920 were written to address ambiguities associated with the use 
of multiple applications.
The Introduction sections of both documents discuss this in some detail.

The clear intent is to make use of ASLA going forward - not to restrict ASLA 
only to the set of link attributes defined at the time of the writing of the 
RFCs. Failure to do so would reintroduce the same set of issues that RFC 
8919/8920 were written to address.
Your attempt to infer that because Generic-Metric was not defined at the time 
that RFC 8919/8920 were written that the RFCs don’t apply to it makes no sense.
ASLA is in fact a revision to the link attribute architecture and is meant to 
be used going forward.

The more appropriate question to ask is why we need to define a legacy style 
sub-TLV for new link attributes? Ketan has made this point in his post on this 
thread and I have sympathy with his position.

We do understand that legacy applications such as RSVP-TE may continue to be 
deployed in networks for some time to come. It is not reasonable to expect that 
legacy application implementations will be updated to use ASLA, which is why I 
do not object to defining a legacy style encoding for Generic Metric if folks 
believe that legacy applications may be enhanced to support new link 
attributes. 

I strongly disagree with your interpretation that ASLA is limited only to the 
code points defined in RFC 8919/8920.

   Les


> -Original Message-
> From: Ron Bonica 
> Sent: Thursday, July 22, 2021 10:28 AM
> To: Acee Lindem (acee) ; Les Ginsberg (ginsberg)
> ; Shraddha Hegde ;
> gregory.mir...@ztetx.com; Peter Psenak (ppsenak) ;
> lsr@ietf.org
> Cc: draft-ietf-lsr-flex-algo-bw-con.auth...@ietf.org
> Subject: RE: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt
> 
> Acee,
> 
> I don't think that draft-ietf-lsr-flex-algo-bw-con violates RFC 8919.
> 
> Section 6.1 of RFC 8919 says:
> 
> " New applications that future documents define to make use of the
>advertisements defined in this document MUST NOT make use of legacy
>advertisements.  This simplifies deployment of new applications by
>eliminating the need to support multiple ways to advertise attributes
>for the new applications."
> 
> Section 3 of RFC 8919 defines legacy advertisements. The definition of legacy
> advertisements does not include new attributes such as
> generic metric. Therefore draft-ietf-lsr-flex-algo-bw-con does not
> violate RFC 8919
> 
> Relevant text from Section 3 of RFC 8919 is included below for convenience.
> 
>   Ron
> 
> 
> RFC 8919, Section 3
> ---
> 3.  Legacy Advertisements
> 
> 
> Existing advertisements used in support of RSVP-TE include sub-TLVs
>for TLVs 22, 23, 25, 141, 222, and 223 and TLVs for Shared Risk Link
>Group (SRLG) advertisement.
> 
>Sub-TLV values are defined in the "Sub-TLVs for TLVs 22, 23, 25, 141,
>222, and 223" registry.
> 
>TLVs are defined in the "TLV Codepoints Registry".
> 
> 3.1.  Legacy Sub-TLVs
> 
>+==++
>| Type | Description|
>+==++
>| 3| Administrative group (color)   |
>+--++
>| 9| Maximum link bandwidth |
>+--++
>| 10   | Maximum reservable link bandwidth  |
>+--++
>| 11   | Unreserved bandwidth   |
>+--++
>| 14   | Extended Administrative Group  |
>+--++
>| 18   | TE Default Metric  |
>+--++
>| 33   | Unidirectional Link Delay  |
>+--++
>| 34   | Min/Max Unidirectional Link Delay  |
>+--++
>| 35   | Unidirectional Delay Variation |
>+--++
> 

Re: [Lsr] WG Last Call for IGP extension for PCEP security capability support in the PCE discovery - draft-ietf-lsr-pce-discovery-security-support-05

[Les Ginsberg (ginsberg)]

I support progression of this document.

Regarding the new registry being requested in Section 8.2, given that the 
registry applies to both OSPF and IS-IS codepoints, I think it would make more 
sense to place the registry under Interior Gateway Protocol (IGP) Parameters 
rather than under OSPF.

   Les


From: Lsr  On Behalf Of Acee Lindem (acee)
Sent: Wednesday, July 21, 2021 9:46 AM
To: lsr@ietf.org
Cc: draft-ietf-lsr-pce-discovery-security-supp...@ietf.org
Subject: [Lsr] WG Last Call for IGP extension for PCEP security capability 
support in the PCE discovery - draft-ietf-lsr-pce-discovery-security-support-05

This begins a 3-week WG Last Call, ending on August 4th, 2021, for 
draft-ietf-lsr-pce-discovery-security-support. Please indicate your support or 
objection to this list before the end of the WG last call. The longer WG last 
call is to account for IETF week.

  
https://datatracker.ietf.org/doc/draft-ietf-lsr-pce-discovery-security-support/


Thanks,
Acee


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

Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt

[Les Ginsberg (ginsberg)]

Shraddha -

With respect, the issue here is very simple and does not warrant the long email.

As per RFC 8919/8920, any link attribute used by applications defined with an 
ASLA bit (other than the legacy applications RSVP-TE, SRTE, and LFA) MUST use 
ASLA advertisements.
As you propose to use the new metric for Flex-Algo - which is a "new 
application" with an ASLA assigned bit - you MUST support ASLA encoding.
You can also support encoding in a sub-TLV under TLV22 (etc.).

There is nothing to discuss here - it is simply a matter of conforming to the 
normative statements in existing RFCs.

Please correct the draft as requested.

   Les


> -Original Message-
> From: Shraddha Hegde 
> Sent: Monday, July 19, 2021 11:05 AM
> To: gregory.mir...@ztetx.com; ppsenak=40cisco@dmarc.ietf.org;
> lsr@ietf.org
> Cc: Les Ginsberg (ginsberg) ; draft-ietf-lsr-flex-algo-
> bw-con.auth...@ietf.org
> Subject: RE: Re:[Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt
> 
> Hi All,
> 
> Generic metric was allowed to be advertised in TLV 22/ ELO LSA
> as well as ASLA TLV before the draft was called for adoption.
> During the recent WG adoption review, it was pointed out that
> ASLA architecture does not allow an attribute to be advertised
> in both application-specific and application-independent manner.
> 
> As a result of this Generic metric has been made an
> application-independent attribute in the latest version.
> The reasons are below
> 
> 1.Generic metric is required to be advertised in an application-independent
> manner
> that is metric-type 128 is advertised for a link and any application
> like flex-algo, SR-TE, RSVP LFA can make use of it.
> Metric has scope outside of an IGP domain. It gets advertised
> in BGP-LU and gets accumulated across domains.
> There are many usecases that will benefit from advertising generic-metric
> in an application-independent manner.
> 
> 2.The recent case of te-metric usecase that I came across
> where ASLA was being used, really wanted to
> use a different metric-type for flex-algo and not really
> different values for same metric type.
> (Peter, coincidently we may be talking of the same recent
> usecase which you claimed to be using ASLA)
> 
> 3.Advertising generic metric in an application independent manner in legacy
> TLV 22 and ELO LSA
> does not violate RFC 8919/8920. Application-independent attributes are not
> expected to use RFC 8919/8920
> mechanisms. Generic metric is like igp cost. IGP-cost is never advertised in
> ASLA but it gets used in flex-algo
> and generic-metric is being modeled based on igp-cost.
> As currently written, this document is compliant to every RFC and draft that
> has
> been out there and not violating any of them.
> 
> 4.Generic metric is very flexible. It allows for finest granularity of
> metric advertisement.
> Usecase:
> Lets say flex-algo 128 wants to use metric-type 128 and flex-algo 129
> wants to use metric-type 129. An year later operator decides to deploy
> SR-TE with red LSPs using metric-type 128 and Blue LSPs using metric-type
> 129.
> 
> Using generic metric in application-independent manner:
> 1.configure metric-type 128 and 129 and value pair on each link
> 2. set flex-algo 128 FAD to use metric-type 128 and flex-algo FAD 129 to use
> metric-type 129
> 3. An year later configure Red LSPs to use metric-type 128 and Blue LSPs to
> use metric-type 129
> 
> Using generic metric with ASLA:
> 1. Define user defined bit-masks for flex-algo 128 and flex-algo 129 and
> configure on every router
> 2. configure metric-type 128 and 129 on every link
> 3. An year later, define user defined bit masks  for SR-TE Red LSPs and SR-TE
> blue LSPs
> 4. Configure the bit masks on all head-end routers
> 5. Associate the new bit masks with the metric-types on every router on
> every link.
> 
> The most common cases look operationally very complex with ASLA while
> they look very
> simple operationally with generic-metric being advertised in an application-
> independent
> manner. It looks reasonable approach to allow the option of application-
> independent
> advertisements for operators who are looking to simplify operations.
> 
> 
> In order to decide  how the generic-metric should be advertised, it would
> be good to get input from the WG on below point.
>  Do you have usecases in mind that you would like to deploy that cannot be
> solved
> with advertising generic-metric in an application-independent manner?
> 
> 
> Looking forward to more discussions during LSR WG meeting.
> 
> 
> Rgds
> Shraddha
> 
> 
> Juniper Business Use Only
> 
> -Original Message-
> From: gregory.mir...@ztetx.com 
> Sent: Sunday, July 18, 2021

Re: [Lsr] IP layer metrics collected by Edge routers - draft-dunbar-lsr-5g-edge-compute-ospf-ext (was: LSR Presentation Slot request)

[Les Ginsberg (ginsberg)]

Linda -

I think Acee's objections (which I support) make progressing your draft 
unlikely - which makes resolution of your questions somewhat moot.

However, please find responses inline.

From: Linda Dunbar 
Sent: Tuesday, July 13, 2021 1:02 PM
To: Les Ginsberg (ginsberg) ; Acee Lindem (acee) 
; Yingzhen Qu ; 
lsr@ietf.org
Cc: lsr-cha...@ietf.org
Subject: RE: [Lsr] IP layer metrics collected by Edge routers - 
draft-dunbar-lsr-5g-edge-compute-ospf-ext (was: LSR Presentation Slot request)

Les,

Thank you for the comments.
Replies are inserted below:


From: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Sent: Monday, July 12, 2021 8:32 PM
To: Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
Linda Dunbar mailto:linda.dun...@futurewei.com>>; 
Yingzhen Qu mailto:yingzhen.i...@gmail.com>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Cc: lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>
Subject: RE: [Lsr] IP layer metrics collected by Edge routers - 
draft-dunbar-lsr-5g-edge-compute-ospf-ext (was: LSR Presentation Slot request)

Linda -

Picking up on this comment from Acee:

"Note that routes are based on IP prefixes and not applications while the draft 
uses these two interchangeably. "
[Linda] Yes, the application is identified by their IP addresses.

As regards how to advertise the new metric, to the best of my understanding 
what you want to advertise is the cost to reach an anycast address - which 
argues for a prefix Reachability advertisement. And indeed, that is what you 
chose to use for OSPF. It therefore makes no sense to me why you would use a 
link attribute advertisement when advertising the same information in IS-IS.
[Linda]  Is it better to use the TLV 22 (Extended IS Reachability) to carry the 
Site-Cost subTLVs specified in the draft?  Or is TLV 23  (IS Neighbor Attribute 
) more appropriate?

[LES:] Prefic reachability is advertised using TLVs 135, 235, 236, and 237. If 
appropriate, new sub-TLVs can be defined for these TLVs - which would be 
analogous to how you proposed to extend OSPF.

I also think you are quite confused about the application part of "ASLA" as 
defined in RFC 8919/8920. The application identifies which applications are 
using the link attribute advertisements - it does not define the attribute 
itself - which potentially could be used by any application.
[Linda] since not every node will utilize the detailed IP Layer Metrics carried 
in the Site-COST,  the BIT MASK is to indicate if a Node should even process 
the detailed IP layer metrics. Is "ASLA"  intended to be?

[LES:] The ASLA bit masks identify the application(s) to which the attribute 
advertisements apply.
If a node does not support a given application, then it simply ignores these 
advertisements.
But, as per my previous response, link attributes isn't the right place to 
advertise what seems to be a prefix attribute - which means ASLA isn't relevant 
for you.

   Les

If you need to advertise a new type of metric, the identification of that 
metric derives from the (sub-)TLV codepoint used - not from any of the 
applications bits. Your proposal to define a new application "C" therefore 
seems inappropriate.

+1 to Acee's other comments.

   Les


From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Acee 
Lindem (acee)
Sent: Monday, July 12, 2021 5:06 PM
To: Linda Dunbar 
mailto:linda.dun...@futurewei.com>>; Yingzhen Qu 
mailto:yingzhen.i...@gmail.com>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Cc: lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>
Subject: Re: [Lsr] IP layer metrics collected by Edge routers - 
draft-dunbar-lsr-5g-edge-compute-ospf-ext (was: LSR Presentation Slot request)

Hi Linda,

From: Linda Dunbar 
mailto:linda.dun...@futurewei.com>>
Date: Monday, July 12, 2021 at 5:41 PM
To: Acee Lindem mailto:a...@cisco.com>>, Yingzhen Qu 
mailto:yingzhen.i...@gmail.com>>, 
"lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>
Cc: "lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>" 
mailto:lsr-cha...@ietf.org>>
Subject: IP layer metrics collected by Edge routers - 
draft-dunbar-lsr-5g-edge-compute-ospf-ext (was: LSR Presentation Slot request)

Acee,

The draft-dunbar-lsr-5g-edge-compute-ospf-ext has two parts:

-  Aggregated Cost Advertisement

-  IP Layer App-Metrics Advertisements by OSPF

"Aggregated Cost" is only applicable to scenario where all the A-ER can have a 
consistent algorithm to compute the Aggregated cost.

When it is not possible for all the egress edge routers to have a consistent 
algorithm to compute the aggregated cost or some routers need all the detailed 
IP Layer metrics for the App Servers for other purposes, the raw IP layer 
metrics collected A-ER will be distributed. Only the nodes that are capable of 
utilizing the metrics will process the sub-TLV.

So, why would these &quo

Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt

[Les Ginsberg (ginsberg)]

Draft authors -

I note that the new version has altered the advertisement of the Generic Metric 
sub-TLV so that it is no longer supported in the ASLA sub-TLV.
This is in direct violation of RFC 8919/8920.

For example, https://www.rfc-editor.org/rfc/rfc8919.html#section-6.1 states:

"New applications that future documents define to make use of the 
advertisements defined in this document MUST NOT make use of legacy 
advertisements."

Flex-algo is a "new application" in the scope of these RFCs.

Please correct this error.

Thanx.

   Les


> -Original Message-
> From: Lsr  On Behalf Of internet-dra...@ietf.org
> Sent: Monday, July 12, 2021 9:12 AM
> To: i-d-annou...@ietf.org
> Cc: lsr@ietf.org
> Subject: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt
> 
> 
> 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   : Flexible Algorithms: Bandwidth, Delay, Metrics and
> Constraints
> Authors : Shraddha Hegde
>   William Britto A J
>   Rajesh Shetty
>   Bruno Decraene
>   Peter Psenak
>   Tony Li
>   Filename: draft-ietf-lsr-flex-algo-bw-con-01.txt
>   Pages   : 27
>   Date: 2021-07-12
> 
> Abstract:
>Many networks configure the link metric relative to the link
>capacity.  High bandwidth traffic gets routed as per the link
>capacity.  Flexible algorithms provides mechanisms to create
>constraint based paths in IGP.  This draft documents a generic metric
>type and set of bandwidth related constraints to be used in Flexible
>Algorithms.
> 
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo-bw-con/
> 
> There is also an htmlized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-bw-con-01
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-flex-algo-bw-con-01
> 
> 
> 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 mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] IP layer metrics collected by Edge routers - draft-dunbar-lsr-5g-edge-compute-ospf-ext (was: LSR Presentation Slot request)

[Les Ginsberg (ginsberg)]

Linda –

Picking up on this comment from Acee:

“Note that routes are based on IP prefixes and not applications while the draft 
uses these two interchangeably. “

As regards how to advertise the new metric, to the best of my understanding 
what you want to advertise is the cost to reach an anycast address – which 
argues for a prefix Reachability advertisement. And indeed, that is what you 
chose to use for OSPF. It therefore makes no sense to me why you would use a 
link attribute advertisement when advertising the same information in IS-IS.

I also think you are quite confused about the application part of “ASLA” as 
defined in RFC 8919/8920. The application identifies which applications are 
using the link attribute advertisements – it does not define the attribute 
itself – which potentially could be used by any application.
If you need to advertise a new type of metric, the identification of that 
metric derives from the (sub-)TLV codepoint used – not from any of the 
applications bits. Your proposal to define a new application “C” therefore 
seems inappropriate.

+1 to Acee’s other comments.

   Les


From: Lsr  On Behalf Of Acee Lindem (acee)
Sent: Monday, July 12, 2021 5:06 PM
To: Linda Dunbar ; Yingzhen Qu 
; lsr@ietf.org
Cc: lsr-cha...@ietf.org
Subject: Re: [Lsr] IP layer metrics collected by Edge routers - 
draft-dunbar-lsr-5g-edge-compute-ospf-ext (was: LSR Presentation Slot request)

Hi Linda,

From: Linda Dunbar 
mailto:linda.dun...@futurewei.com>>
Date: Monday, July 12, 2021 at 5:41 PM
To: Acee Lindem mailto:a...@cisco.com>>, Yingzhen Qu 
mailto:yingzhen.i...@gmail.com>>, 
"lsr@ietf.org" mailto:lsr@ietf.org>>
Cc: "lsr-cha...@ietf.org" 
mailto:lsr-cha...@ietf.org>>
Subject: IP layer metrics collected by Edge routers - 
draft-dunbar-lsr-5g-edge-compute-ospf-ext (was: LSR Presentation Slot request)

Acee,

The draft-dunbar-lsr-5g-edge-compute-ospf-ext has two parts:

-  Aggregated Cost Advertisement

-  IP Layer App-Metrics Advertisements by OSPF

“Aggregated Cost” is only applicable to scenario where all the A-ER can have a 
consistent algorithm to compute the Aggregated cost.

When it is not possible for all the egress edge routers to have a consistent 
algorithm to compute the aggregated cost or some routers need all the detailed 
IP Layer metrics for the App Servers for other purposes, the raw IP layer 
metrics collected A-ER will be distributed. Only the nodes that are capable of 
utilizing the metrics will process the sub-TLV.

So, why would these “capable” nodes have a consistent algorithm for using this 
complex set of metrics but the A-ERs would not have a consistent algorithm for 
aggregating the cost?

Since only a subset of routers within an IGP domain need to know those detailed 
metrics, the draft used your suggested  OSPFv2 Extended Prefix Opaque LSA for 
IPv4 and OSPFv3 Extended LSA with Intra-Area-Prefix TLV to carry the detailed 
sub-TLVs.  For routers that don’t care about those metrics, they can ignore 
them very easily.

This just doesn’t work. All routers in an IGP domain must use the same 
algorithm. You can’t just draw a picture with an LDN directly connected to a 
couple A-ERs say that the LDNs can use your metrics to route application 
specific traffic. The problem could possibly be solved with flex algorithm but 
it would require a lot more specification. I guess with your simple topology 
different LDNs could use the metrics differently as well? This would explain 
why you are not concerned with “consistency”…

It worth noting that not all hosts (prefix) attached to an A-ER are ANYCAST 
servers that need network optimization. An A-ER only needs to advertise the 
App-Metrics for the ANYCAST addresses that match with the configured ACLs.

Note that routes are based on IP prefixes and not applications while the draft 
uses these two interchangeably.

Thanks,
Acee


Any other concerns?

Thank you
Linda Dunbar

From: Acee Lindem (acee) mailto:a...@cisco.com>>
Sent: Monday, July 12, 2021 4:04 PM
To: Linda Dunbar 
mailto:linda.dun...@futurewei.com>>; Yingzhen Qu 
mailto:yingzhen.i...@gmail.com>>; 
lsr@ietf.org
Cc: lsr-cha...@ietf.org
Subject: Re: [Lsr] LSR Presentation Slot Requests - IETF111

Speaking as WG member:

Hi Linda,
Even if you’ve added some IS-IS encodings, the draft still suffers from the 
fundamental problem of the previous draft. If you can’t rely on the A-ERs to 
consistently calculate an aggregated metric, how can you rely on all the 
routers in the IGP routing domain to use complex set of metrics to reach the 
least-loaded app server? Do we really want to talk about this again?
Thanks,
Acee

From: Linda Dunbar 
mailto:linda.dun...@futurewei.com>>
Date: Monday, July 12, 2021 at 4:27 PM
To: Yingzhen Qu mailto:yingzhen.i...@gmail.com>>, 
"lsr@ietf.org" mailto:lsr@ietf.org>>
Cc: 

Re: [Lsr] draft-decraene-lsr-isis-flooding-speed & IETF 111

[Les Ginsberg (ginsberg)]

Chris –

As regards a meeting specifically targeted for the flooding speed topic, here 
is my personal request/requirement:

The meeting MUST allow at least 50 % of the allocated meeting time for open 
discussion.
If all we do at the interim meeting is fill the time with presentations, we 
will not have accomplished much.

However you (as WG chair) go about building an agenda, please ensure that this 
happens.
Thanx.

Les


From: Lsr  On Behalf Of Christian Hopps
Sent: Monday, July 12, 2021 9:53 AM
To: Les Ginsberg (ginsberg) 
Cc: lsr@ietf.org; bruno.decra...@orange.com; lsr-cha...@ietf.org
Subject: Re: [Lsr] draft-decraene-lsr-isis-flooding-speed & IETF 111




On Jul 9, 2021, at 11:00 AM, Les Ginsberg (ginsberg) 
mailto:ginsb...@cisco.com>> wrote:

I agree with Bruno that the time available in the WG meeting will likely be 
inadequate to present full updates for both drafts. In addition, I think it is 
important that the WG have
an opportunity to discuss publicly in an interactive way, the merits of each 
proposal. The likelihood that time will be available in the scheduled WG 
meeting for that discussion as well seems low.

How about we use the time in the IETF WG meeting to give a high level summary 
of what would be presented in more depth at the interim, and then we can have 
discussion to decide what else might should go in the interim. Perhaps others 
will feel inspired to also present during the interim after hearing the high 
level summary! :) It shouldn’t be hard to schedule a follow on interim shortly 
after IETF wraps even if we wait.

Thanks,
Chris (co-chair hat)
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] draft-decraene-lsr-isis-flooding-speed & IETF 111

[Les Ginsberg (ginsberg)]

As is well known, there are two drafts in this problem space:

https://datatracker.ietf.org/doc/draft-decraene-lsr-isis-flooding-speed/
and
https://datatracker.ietf.org/doc/draft-ginsberg-lsr-isis-flooding-scale/


Regarding the latter, we also have a working implementation and we also have 
requested a presentation slot for IETF 111 LSR WG meeting.

I agree with Bruno that the time available in the WG meeting will likely be 
inadequate to present full updates for both drafts. In addition, I think it is 
important that the WG have
an opportunity to discuss publicly in an interactive way, the merits of each 
proposal. The likelihood that time will be available in the scheduled WG 
meeting for that discussion as well seems low.

I therefore join w Bruno in suggesting that an interim meeting dedicated to the 
flooding speed topic be organized.
Given the short time available before IETF 111, I would suggest that we look at 
scheduling an interim meeting after IETF 111 - but I leave it to the WG chairs 
to decide when to schedule this.

I also think it would be prudent to delay WG adoption calls for either draft 
until after such an interim meeting is held. In that way the WG can make a more 
informed decision.

   Les

From: Lsr  On Behalf Of bruno.decra...@orange.com
Sent: Friday, July 9, 2021 2:01 AM
To: lsr-cha...@ietf.org; lsr@ietf.org
Subject: [Lsr] draft-decraene-lsr-isis-flooding-speed & IETF 111

Hi chairs, WG,

Over the last two years, we have presented and the WG discussed 
draft-decraene-lsr-isis-flooding-speed at IETF 105 and "107"
IETF 105: https://datatracker.ietf.org/meeting/105/proceedings#lsrNote: 
that the presentation is in first slot/video but a large part of the discussion 
is in the second one.
IETF 107/interim: 
https://datatracker.ietf.org/meeting/interim-2020-lsr-02/materials/agenda-interim-2020-lsr-02-lsr-01-07.html

The goal is to improve flooding performance and robustness to make it both 
faster when the receiver have free cycles, and slower when the receiver is 
congested.

In addition to technical discussions, a feedback was that implementation and 
tests/evaluation would be good in order to evaluate the proposal.

We are reporting that we have an implementation of [1] based on the open source 
Free Range Routing implementation.
We are now ready to report the evaluation to the WG. We have a lot of data so 
ideally would need around an hour in order to cover the whole picture.

We have requested a slot for IETF 111 LSR meeting. If the IETF 111 slot is 
short, we'd like to request for an interim meeting. In order to keep the 
context, the sooner/closer to IETF 111 seems the better.

Since we have an implementation, we have requested for a code point, in order 
to avoid squatting on one. This is currently under review by the designed 
experts.

Finally, given the two-years work, the specification, the implementation and 
extensive evaluation, we'd like to ask for WG adoption.

Thanks,
Regards,
--Bruno


[1] https://datatracker.ietf.org/doc/html/draft-decraene-lsr-isis-flooding-speed


_



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.



This message and its attachments may contain confidential or privileged 
information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete 
this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.

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

Re: [Lsr] Second Working Last Call for draft-ietf-lsr-flex-algo

[Les Ginsberg (ginsberg)]

I support progressing this document.
Flex-algo has already been demonstrated to be useful with a number of 
implementations/deployments.

   Les


From: Lsr  On Behalf Of Acee Lindem (acee)
Sent: Wednesday, June 16, 2021 7:01 AM
To: lsr@ietf.org
Cc: lsr-...@ietf.org; Christian Hopps ; 
draft-ietf-lsr-flex-algo@ietf.org
Subject: [Lsr] Second Working Last Call for draft-ietf-lsr-flex-algo

After the first successful WG last call, the authors discovered that some 
re-work was needed for OSPF AS External route calculation – specifically with 
respect to the Flex Algorithm ASBR metrics and calculation. This was fixed and 
there were clarifications in the IANA section (see versions -14 and -15). The 
draft has been stable since April and we are now ready to WG last call the 
updated version.


Without further ado, this begins a 2 week WG Last Call, ending on July 1st, 
2021, for draft-ietf-lsr-flex-algo

  https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo/

All authors, please indicate by sending an email to the list, whether you aware 
of any other IPR beyond what is already posted:

  [From 
https://datatracker.ietf.org/ipr/search/?submit=draft=draft-ietf-lsr-flex-algo]

  https://datatracker.ietf.org/ipr/3910/
  https://datatracker.ietf.org/ipr/3248/

Thanks,
Chris & Acee.


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

Re: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt

[Les Ginsberg (ginsberg)]

Joel -

I have had concerns from the beginning as to whether this draft is really 
needed.
As I have commented previously, the only content of any significance is Section 
4 - and that only provides example settings of the management fields for this 
interface type.
I question whether a draft is required for this purpose. 
I will defer on this matter to folks more expert in this area than I, but, my 
opinion is that a draft solely for this purpose is not required.

I thought it polite to mention this before you spend the time and effort to 
produce a new version.

   Les


> -Original Message-
> From: Lsr  On Behalf Of tom petch
> Sent: Wednesday, June 23, 2021 1:43 AM
> To: Joel M. Halpern ; Harold Liu
> ; lsr@ietf.org
> Subject: Re: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt
> 
> From: Joel M. Halpern 
> Sent: 22 June 2021 09:57
> 
> Do Les' suggested edits address your concerns.
> We will apply yor changes to the IANA considerations section.
> 
> 
> I would go further than Les as I suggested on Tuesday.  Perhaps it is time for
> a new version to comment on.
> 
> Tom Petch
> 
> Yours,
> Joel
> 
> On 6/22/2021 4:34 AM, tom petch wrote:
> > From: Joel M. Halpern 
> > Sent: 21 June 2021 15:13
> >
> > Tom, 5309 did not define the ifType.  Go read 5309.  You seem to have
> > gotten confused by the fact that the IANA entry given to 303 points to
> > 5309.  That was done to have some reference (with the consent of the
> > experts).   What we are doing now is providing a better reference.  So
> > yes, this document defines how the ifType is defined.  With no criticism
> > of 5309, it does not define that, since it does not define the ifType.
> >
> > 
> > Stepping back a few e-mails,
> > I have read 5309 and did point out previously that there is no IANA
> Considerations in that RFC.  What I have said and repeat here is that 5309
> defines the p2pOverLan type.  That is what the RFC claims and that is what it
> does.  You seem to think that the definition of a type is incomplete without a
> numerical value assigned to it, the SMI ifType  or YANG identity.  The concept
> of the type exists whether or not a value has been assigned to it and this is
> one of the places where this I-D goes wrong..
> >
> > I would say
> > Abstract
> > The p2pOverLan interface type is described in RFC5309.
> > Subsequently, this interface type has been assigned a value of 303 by
> IANA, by Expert Review.
> > This memo 
> >
> > Well, what does it do?  Gives examples of its use?  I see nothing more.
> >
> > Tom Petch
> >
> > We are explicit in this draft that one of the obvious uses for this
> > ifType is to trigger 5309 behavior.
> >
> > Yours,
> > Joel
> >
> > On 6/21/2021 4:41 AM, tom petch wrote:
> >> From: Lsr  on behalf of Harold Liu
> 
> >> Sent: 21 June 2021 02:01
> >>
> >> Hi Med and All:
> >>  Thanks for your helpful comments, I have updated a new version 01
> to follow the comments;
> >>  The main updating is:
> >>  1. More clearly described the intend of this draft in the 
> >> introduction;
> >>  2. Change the reference style;
> >>  3. Refactor the reference section to make it more reasonable;
> >>  4. I haven't change "IANA Consideration" at the moment given there
> is lots of discussion in this part and it is still up in the air, I will 
> change this
> section next update the document once this part is finalized;
> >>
> >> 
> >> I still think that this is an unsatisfactory I-D and would oppose adoption 
> >> in
> its present form,
> >>
> >> It is a question of veracity.  It claims to do what others have already 
> >> done
> and does so without reference, without acknowledgement.  Having the
> same data defined in more than one place can only create confusion, in
> future if not now.
> >>
> >> This is a pattern and starts with the Abstract and continues throughout
> the I-D.
> >>
> >> Thus the Abstract claims 'this defines point-to-point interface type'.  No.
> This type was defined in RFC5309 and you need to say that and to say what if
> anything you are changing in that definition.  You should not reproduce text
> from that RFC unless you have to and then you should make it clear you are
> quoting.
> >>
> >> You do the same with Figure 1.  This is a copy, may be accurate may be
> not, it does not matter, from RFC8343 with no mention thereof.  You should
> not be reproducing such text without a good reason and then you should
> make it clear what is reproduced, from where and why.
> >>
> >> And as I have said already, IANA Considerations is yet again claiming to do
> what has already happened which can only confuse.  All that is needed as I
> said in a separate note  is to ask IANA to update two references, nothing
> more.
> >>
> >> Tom Petch
> >>
> >>  And I would like to share more background information for this
> internet draft:
> >>  As Joel mentioned, we requested and received an IF Type
> assignment from IANA (with expert 

Re: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt

[Les Ginsberg (ginsberg)]

Joel -

In addition to the IANA section changes,

1)Please be sure that the text consistently refers to "Point to Point (P2P) 
Interface over LAN" - not simply "Point to Point"

2)I think the abstract/introduction should make it clear that this draft is 
specifying the management mappings for the " Point to Point (P2P) Interface 
over LAN".
It is NOT defining Point to Point (P2P) Interface over LAN operation - that 
clearly was already done by RFC 5309.

3)I don’t know if Section 3 is really needed. I tend to think not.
But if you do want to keep it, please Reference RFC 8343 Section 4 as this is 
clearly a copy of the Figure in that document/section.

   Les



> -Original Message-
> From: Joel Halpern Direct 
> Sent: Monday, June 21, 2021 8:47 AM
> To: Les Ginsberg (ginsberg) ; tom petch
> ; Harold Liu
> ; lsr@ietf.org
> Subject: Re: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt
> 
> The change Tom has proposed to the IANA considerations section is fine
> with me.
> 
> If there are other specific changes that will make it clearer, I and my
> co-authors are happy to make those.   I have tried looking at the text.
>   Even before you found it misleading, I did conclude that Tom getting
> the wrong impression meant it needs to be clarified.  But as I am having
> trouble seeing what misled you, I can not suggest wording improvements
> to my co-authors.
> 
> I presume from your phrasing that you want more changes than just to the
> IANA considerations section.  I presume I am just being dense in not
> seeing the rest.  I apologize, but that does not make me less dense.
> Sorry.
> 
> Help?
> Joel
> 
> On 6/21/2021 11:28 AM, Les Ginsberg (ginsberg) wrote:
> > Joel -
> >
> > I am not objecting to the draft.
> > I am simply asking for it to be both clear and accurate in what it is 
> > actually
> doing.
> >
> > I think Tom has done an excellent job of pointing out the inaccuracies and
> in some cases providing proposed revised text.
> >
> > I would ask you to reread your own draft in the context that at least two
> people have read it and found it inaccurate and both of us have made very
> explicit points about what language is confusing.
> >
> > Les
> >
> >> -Original Message-
> >> From: Joel Halpern Direct 
> >> Sent: Monday, June 21, 2021 8:13 AM
> >> To: Les Ginsberg (ginsberg) ; tom petch
> >> ; Harold Liu
> >> ; lsr@ietf.org
> >> Subject: Re: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt
> >>
> >> Les, I am missing something ion both your and Tom's comments.  5309
> >> didn't define the ifType.  If you look at 5309, it has no IANA
> >> considerations at all.
> >>
> >> Yes, this document should talk about 5309 as one of the cases that the
> >> ifType simplifies.  And it does.
> >>
> >> This documents follows the lead of 8343 in defining this specific ifType.
> >>
> >> Let's be clear.  We were asked, quite reasoanbly, by the expert, when we
> >> requested the IANA code point, to please submit a document describing
> >> how the dcode point would be used, rather than merely pointing at 5309
> >> and assuming everyone could guess correctly.  (Guessing is not good for
> >> standards.)
> >> So we are trying to do so.
> >>
> >> You seem to be objecting to our doing so.  Why?
> >>
> >> If the working group really doesn't want a description, we can go away.
> >>We have the code point we felt was useful.  But it seems much more
> >> useful to actually provide meaningful documentation.
> >>
> >> Yours,
> >> Joel
> >>
> >>
> >>
> >> On 6/21/2021 10:58 AM, Les Ginsberg (ginsberg) wrote:
> >>> I am in complete agreement with the points Tom has made.
> >>>
> >>> AFAICT, the only new content in this draft is Section 4 - the rest is 
> >>> either
> >> boilerplate or a repetition of text already present in RFC 5309 or RFC 
> >> 8343.
> >>> Neither the Abstract nor the Introduction makes that clear.
> >>> The abstract actually claims to
> >>>
> >>>   "defines point-to-point interface type"
> >>>
> >>> which is both FALSE (already defined in RFC 5309) and incorrectly named
> -
> >> since the document is actually discussing "point-to-point operation over
> >> LAN".
> >>>
> >>> Regarding the IANA section, it is clear that the draft is NOT creating new
> >> entries

Re: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt

[Les Ginsberg (ginsberg)]

Joel -

I am not objecting to the draft.
I am simply asking for it to be both clear and accurate in what it is actually 
doing.

I think Tom has done an excellent job of pointing out the inaccuracies and in 
some cases providing proposed revised text.

I would ask you to reread your own draft in the context that at least two 
people have read it and found it inaccurate and both of us have made very 
explicit points about what language is confusing.

   Les

> -Original Message-
> From: Joel Halpern Direct 
> Sent: Monday, June 21, 2021 8:13 AM
> To: Les Ginsberg (ginsberg) ; tom petch
> ; Harold Liu
> ; lsr@ietf.org
> Subject: Re: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt
> 
> Les, I am missing something ion both your and Tom's comments.  5309
> didn't define the ifType.  If you look at 5309, it has no IANA
> considerations at all.
> 
> Yes, this document should talk about 5309 as one of the cases that the
> ifType simplifies.  And it does.
> 
> This documents follows the lead of 8343 in defining this specific ifType.
> 
> Let's be clear.  We were asked, quite reasoanbly, by the expert, when we
> requested the IANA code point, to please submit a document describing
> how the dcode point would be used, rather than merely pointing at 5309
> and assuming everyone could guess correctly.  (Guessing is not good for
> standards.)
> So we are trying to do so.
> 
> You seem to be objecting to our doing so.  Why?
> 
> If the working group really doesn't want a description, we can go away.
>   We have the code point we felt was useful.  But it seems much more
> useful to actually provide meaningful documentation.
> 
> Yours,
> Joel
> 
> 
> 
> On 6/21/2021 10:58 AM, Les Ginsberg (ginsberg) wrote:
> > I am in complete agreement with the points Tom has made.
> >
> > AFAICT, the only new content in this draft is Section 4 - the rest is either
> boilerplate or a repetition of text already present in RFC 5309 or RFC 8343.
> > Neither the Abstract nor the Introduction makes that clear.
> > The abstract actually claims to
> >
> >  "defines point-to-point interface type"
> >
> > which is both FALSE (already defined in RFC 5309) and incorrectly named -
> since the document is actually discussing "point-to-point operation over
> LAN".
> >
> > Regarding the IANA section, it is clear that the draft is NOT creating new
> entries - rather it is modifying existing entries. And it isn’t modifying the 
> code
> points, the names, or the descriptions - it only seeks to modify the
> references to include "this document".
> > But the text in the IANA section states otherwise:
> >
> > " IANA need to update the "Interface Types(ifType)" registry...with the
> following status types"
> >
> > I don’t know whether the content in Section 4 is sufficient to claim a
> reference, but if it is it should only be in addition to the existing 
> reference.
> >
> > Les
> >
> >> -Original Message-
> >> From: Lsr  On Behalf Of Joel M. Halpern
> >> Sent: Monday, June 21, 2021 7:13 AM
> >> To: tom petch ; Harold Liu
> >> ; lsr@ietf.org
> >> Subject: Re: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt
> >>
> >> Tom, 5309 did not define the ifType.  Go read 5309.  You seem to have
> >> gotten confused by the fact that the IANA entry given to 303 points to
> >> 5309.  That was done to have some reference (with the consent of the
> >> experts).   What we are doing now is providing a better reference.  So
> >> yes, this document defines how the ifType is defined.  With no criticism
> >> of 5309, it does not define that, since it does not define the ifType.
> >>
> >> We are explicit in this draft that one of the obvious uses for this
> >> ifType is to trigger 5309 behavior.
> >>
> >> Yours,
> >> Joel
> >>
> >> On 6/21/2021 4:41 AM, tom petch wrote:
> >>> From: Lsr  on behalf of Harold Liu
> >> 
> >>> Sent: 21 June 2021 02:01
> >>>
> >>> Hi Med and All:
> >>>  Thanks for your helpful comments, I have updated a new version 01
> to
> >> follow the comments;
> >>>  The main updating is:
> >>>  1. More clearly described the intend of this draft in the 
> >>> introduction;
> >>>  2. Change the reference style;
> >>>  3. Refactor the reference section to make it more reasonable;
> >>>  4. I haven't change "IANA Consideration" at the mo

Re: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt

[Les Ginsberg (ginsberg)]

I am in complete agreement with the points Tom has made.

AFAICT, the only new content in this draft is Section 4 - the rest is either 
boilerplate or a repetition of text already present in RFC 5309 or RFC 8343.
Neither the Abstract nor the Introduction makes that clear.
The abstract actually claims to 

"defines point-to-point interface type" 

which is both FALSE (already defined in RFC 5309) and incorrectly named - since 
the document is actually discussing "point-to-point operation over LAN".

Regarding the IANA section, it is clear that the draft is NOT creating new 
entries - rather it is modifying existing entries. And it isn’t modifying the 
code points, the names, or the descriptions - it only seeks to modify the 
references to include "this document".
But the text in the IANA section states otherwise:

" IANA need to update the "Interface Types(ifType)" registry...with the 
following status types"

I don’t know whether the content in Section 4 is sufficient to claim a 
reference, but if it is it should only be in addition to the existing reference.

   Les

> -Original Message-
> From: Lsr  On Behalf Of Joel M. Halpern
> Sent: Monday, June 21, 2021 7:13 AM
> To: tom petch ; Harold Liu
> ; lsr@ietf.org
> Subject: Re: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt
> 
> Tom, 5309 did not define the ifType.  Go read 5309.  You seem to have
> gotten confused by the fact that the IANA entry given to 303 points to
> 5309.  That was done to have some reference (with the consent of the
> experts).   What we are doing now is providing a better reference.  So
> yes, this document defines how the ifType is defined.  With no criticism
> of 5309, it does not define that, since it does not define the ifType.
> 
> We are explicit in this draft that one of the obvious uses for this
> ifType is to trigger 5309 behavior.
> 
> Yours,
> Joel
> 
> On 6/21/2021 4:41 AM, tom petch wrote:
> > From: Lsr  on behalf of Harold Liu
> 
> > Sent: 21 June 2021 02:01
> >
> > Hi Med and All:
> > Thanks for your helpful comments, I have updated a new version 01 to
> follow the comments;
> > The main updating is:
> > 1. More clearly described the intend of this draft in the 
> > introduction;
> > 2. Change the reference style;
> > 3. Refactor the reference section to make it more reasonable;
> > 4. I haven't change "IANA Consideration" at the moment given there 
> > is
> lots of discussion in this part and it is still up in the air, I will change 
> this section
> next update the document once this part is finalized;
> >
> > 
> > I still think that this is an unsatisfactory I-D and would oppose adoption 
> > in its
> present form,
> >
> > It is a question of veracity.  It claims to do what others have already done
> and does so without reference, without acknowledgement.  Having the
> same data defined in more than one place can only create confusion, in
> future if not now.
> >
> > This is a pattern and starts with the Abstract and continues throughout the
> I-D.
> >
> > Thus the Abstract claims 'this defines point-to-point interface type'.  No.
> This type was defined in RFC5309 and you need to say that and to say what if
> anything you are changing in that definition.  You should not reproduce text
> from that RFC unless you have to and then you should make it clear you are
> quoting.
> >
> > You do the same with Figure 1.  This is a copy, may be accurate may be not,
> it does not matter, from RFC8343 with no mention thereof.  You should not
> be reproducing such text without a good reason and then you should make it
> clear what is reproduced, from where and why.
> >
> > And as I have said already, IANA Considerations is yet again claiming to do
> what has already happened which can only confuse.  All that is needed as I
> said in a separate note  is to ask IANA to update two references, nothing
> more.
> >
> > Tom Petch
> >
> > And I would like to share more background information for this 
> > internet
> draft:
> > As Joel mentioned, we requested and received an IF Type assignment
> from IANA (with expert review) for point-to-point over Ethernet links several
> weeks ago and the p2pOverLan type is already added to IANA registry now;
> > During the discussion around the assignment we noticed a doc
> describing why that is needed and how to use that would be helpful;
> > For example, if no entry saying p2pOverLan layer over ethernet, the
> management will suffer since lose the ability to get to the Ethernet-specific
> management properties (Ethernet MIB or YANG model) via many tools; So
> we propose this draft to define a complete p2pOverLan ifStack(Including
> higher layer and lower layer);
> >
> > Brs
> >
> > -Original Message-
> > From: mohamed.boucad...@orange.com
> 
> > Sent: Thursday, June 17, 2021 2:16 PM
> > To: Joel M. Halpern ; draft-liu-lsr-
> p2pover...@ietf.org
> > Subject: RE: [Lsr] Fwd: I-D Action: 

Re: [Lsr] Proposed Errata for RFCs 8919/8920

[Les Ginsberg (ginsberg)]

Shraddha -

New text will be added to RFC 8919 Section 4.2 immediately after the existing 
text:

"If the SABM or UDABM Length in the Application Identifier Bit Mask is
   greater than 8, the entire sub-TLV MUST be ignored."

Additional Text:

"When SABM or UDABM Length is non-zero and the L-flag is NOT set, all 
applications
specified in the bit mask MUST use the link attribute advertisements in the 
sub-TLV."

Here is why I prefer this change to your proposed text:

Clarification of when advertisements with non-zero ABM length are to be used is 
independent of zero length ABM advertisements i.e., even if we had never 
specified the ability to send zero length ABM advertisements, the above 
clarification would be meaningful.
I therefore do not want to tie this new text to the text discussing when zero 
length ABM advertisements are to be used/not used.

The presentation in Section 4.2 then can be summarized as:

1)Define the ASLA format
2)Define  when nonzero length ABM advertisements MUST be used (new text)
3)Discuss L-bit
4)Discuss zero-length ABM (with new text previously  proposed)

I think this is a clear and logical presentation which also addresses your 
concern.

Thanx.

   Les



From: Shraddha Hegde 
Sent: Wednesday, June 16, 2021 10:05 PM
To: Les Ginsberg (ginsberg) ; Les Ginsberg 
(ginsberg) ; lsr@ietf.org
Cc: DECRAENE Bruno IMT/OLN ; Van De Velde, Gunter 
(Nokia - BE/Antwerp) 
Subject: RE: Proposed Errata for RFCs 8919/8920

Hi Les,

I am proposing to include the text I sent along with your text.

You basically want to imply that when there is an ASLA advertised with an 
application bit set
That application MUST use all link attributes that can appear in ASLA from only 
ASLAs
having the specific application bit set and MUST NOT use from zero ABM ASLAs. I 
agree it is possible to
Derive this from your latest text but I would prefer re-iterating this fact 
more directly than
Let the readers derive this information from current text.

Link attributes MAY be advertised associated with zero-length Application 
Identifier Bit Masks for both standard applications and user-defined 
applications.
Such advertisements MUST be used by standard applications and/or user defined 
applications when no link attribute advertisements with a non-zero-length
Application Identifier Bit Mask and a matching Application Identifier Bit set 
are present for a given link. Otherwise, such advertisements MUST NOT be used.
In other words,
When an application specific link Attribute sub-TLV is advertised for a link 
with one or more specific
standard application or user defined application bits set, all link attributes 
that are allowed in ASLA MUST
be used from the ASLA sub-TLVs having that specific application bit set for 
that link.
For the purposes of such applications, link attributes MUST NOT be used from
ASLA sub-TLV with zero SABM & UDABM length.

Rgds
Shraddha



Juniper Business Use Only
From: Les Ginsberg (ginsberg) 
mailto:ginsberg=40cisco@dmarc.ietf.org>>
Sent: Wednesday, June 16, 2021 10:26 PM
To: Shraddha Hegde mailto:shrad...@juniper.net>>; Les 
Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Cc: DECRAENE Bruno IMT/OLN 
mailto:bruno.decra...@orange.com>>; Van De Velde, 
Gunter (Nokia - BE/Antwerp) 
mailto:gunter.van_de_ve...@nokia.com>>
Subject: RE: Proposed Errata for RFCs 8919/8920

[External Email. Be cautious of content]

Shraddha -

I believe we are in agreement on when zero length ABM ASLA sub-TLVs can be used 
and when they cannot.

The new text we proposed is:

"Link attributes MAY be advertised associated with zero-length Application 
Identifier Bit Masks for both standard applications and user-defined 
applications.
Such advertisements MUST be used by standard applications and/or user defined 
applications when no link attribute advertisements with a non-zero-length
Application Identifier Bit Mask and a matching Application Identifier Bit set 
are present for a given link. Otherwise, such advertisements MUST NOT be used."

This states both when zero-length ABM advertisements MUST be used and when they 
MUST NOT be used.

You have proposed different text:

"When an application specific link Attribute sub-TLV is advertised with one or 
more specific
standard application or user defined application bits set, all link attributes 
that are allowed in ASLA MUST
be used from the ASLA sub-TLVs having that specific application bit set.
For the purposes of such applications, link attributes MUST NOT be used from
ASLA sub-TLV with zero SABM & UDABM length."

This states when zero-length ABM advertisements MUST NOT be used - but it does 
not state when they MUST be used.
Instead, it states when non-zero length ABM advertisements MUST be used.
So this does not seem to be as complete as regards zero length ABM.

You seem to feel that there is confusion as to when non-zero ABM ASLA 
adv

Re: [Lsr] Proposed Errata for RFCs 8919/8920

[Les Ginsberg (ginsberg)]

Gunter -

There is no relationship between the ASLA SRLG TLV and IS-Neighbor TLV.
I do not understand why you would think that there is.

Whether ASLA sub-TLV is present in IS-Neighbor TLV and whether it has 
zero-length ABM on non-zero-length ABM is irrelevant to the use of ASLA SRLG 
TLV - and vice versa.

   Les


From: Van De Velde, Gunter (Nokia - BE/Antwerp) 
Sent: Wednesday, June 16, 2021 9:07 AM
To: Shraddha Hegde ; Les Ginsberg (ginsberg) 
; lsr@ietf.org
Cc: DECRAENE Bruno IMT/OLN 
Subject: RE: Proposed Errata for RFCs 8919/8920

Another item of ambiguity is whether "wildcarding" applies also to the ISIS 
TE-Appl-Spec-SRLG TLV.
It seems that the RFC8919 does not specify it.
Note: for OSPF the wildcarding also applies to SRLG info because it is 
transported via the same container TLV as the other TE attributes.

Example 1
TE-IS-NBRs TLV
 Link x
  ASLA TLV
  SABML 0, UDABML 0 (= All Appl)
  TE-Metric 20
TE-Appl-Spec-SRLG TLV
Link x
SABML 1, UDABML 0, Bitmap Flex-Algo
   SRLG 1 2 3

Should TE-Metric 20 be used for Flex-Algo or not ?
In other words, is the wildcard ASLA TLV overruled by the specific 
TE-Appl-Spec_SRLG TLV or not ?

Example 2
Maybe this is an invalid example if wildcarding does not apply for the 
TE-Appl-SRLG TLV.
TE-IS-NBRs
 Link x
  ASLA TLV
  SABML 1, UDABML 0, Bitmap Flex-Algo
  TE-Metric 20
TE-Appl-Spec-SRLG
Link x
SABML 0, UDABML 0 (= All Appl)
   SRLG 1 2 3

Should SRLG 1 2 3 be used for Flex-Algo or not ?

What is your opinion ?

G/


From: Shraddha Hegde mailto:shrad...@juniper.net>>
Sent: Wednesday, June 16, 2021 4:46 PM
To: Les Ginsberg (ginsberg) 
mailto:ginsberg=40cisco@dmarc.ietf.org>>;
 lsr@ietf.org<mailto:lsr@ietf.org>
Cc: DECRAENE Bruno IMT/OLN 
mailto:bruno.decra...@orange.com>>; Van De Velde, 
Gunter (Nokia - BE/Antwerp) 
mailto:gunter.van_de_ve...@nokia.com>>
Subject: RE: Proposed Errata for RFCs 8919/8920

Hi,

I think that there may still be some ambiguity arising from the text below due 
to the fact that
There are attributes such as maximum-link-bandwidth which have special 
behaviour mentioned in later sections.

"Link attributes MAY be advertised associated with zero-length Application 
Identifier Bit Masks for both standard applications and user-defined 
applications.
Such advertisements MUST be used by standard applications and/or user defined 
applications when no link attribute advertisements with a non-zero-length
Application Identifier Bit Mask and a matching Application Identifier Bit set 
are present for a given link. Otherwise, such advertisements MUST NOT be used."


For example, If max link bandwidth attribute comes in a
Zero length SABM & UDABM and we have a Flex-algo specific ASLA
that does not have the max-link-bandwidth advertised, can
Flex-algo use max-link-bandwidth attribute?

My interpretation from modified text for ISIS is that,  it cannot use it.
I think there is no harm in re-iterating in order to avoid people reading is 
differently.

Link attributes MAY be advertised associated with zero-length Application 
Identifier Bit Masks for both standard applications and user-defined 
applications.
Such advertisements MUST be used by standard applications and/or user defined 
applications when no link attribute advertisements with a non-zero-length
Application Identifier Bit Mask and a matching Application Identifier Bit set 
are present for a given link. Otherwise, such advertisements MUST NOT be used.
In other words,
When an application specific link Attribute sub-TLV is advertised with one or 
more specific
standard application or user defined application bits set, all link attributes 
that are allowed in ASLA MUST
be used from the ASLA sub-TLVs having that specific application bit set.
For the purposes of such applications, link attributes MUST NOT be used from
ASLA sub-TLV with zero SABM & UDABM length.


Rgds
Shraddha



Juniper Business Use Only
From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Les 
Ginsberg (ginsberg)
Sent: Tuesday, June 15, 2021 8:55 PM
To: lsr@ietf.org<mailto:lsr@ietf.org>
Cc: DECRAENE Bruno IMT/OLN 
mailto:bruno.decra...@orange.com>>; Van De Velde, 
Gunter (Nokia - BE/Antwerp) 
mailto:gunter.van_de_ve...@nokia.com>>
Subject: [Lsr] Proposed Errata for RFCs 8919/8920

[External Email. Be cautious of content]


Folks -



Recent discussions on the list have highlighted some unintentional ambiguity in 
how ASLA advertisements are to be used. Please see 
https://mailarchive.ietf.org/arch/msg/lsr/prSLJDkMUnHm6h7VuCdn_Q7-1vg/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/lsr/prSLJDkMUnHm6h7VuCdn_Q7-1vg/__;!!NEt6yMaO-gk!RK_eZNNu1y0aJvAqIaNwHTIFAjHWFJwW1UqyOO8ACxB0kof3jmD_dRkiPkbVLJyA$>



The following proposed Errata address this ambiguity and aligns language in the 
two RFCs.



We welcome comments on the proposed Erra

Re: [Lsr] Proposed Errata for RFCs 8919/8920

[Les Ginsberg (ginsberg)]

Shraddha -

I believe we are in agreement on when zero length ABM ASLA sub-TLVs can be used 
and when they cannot.

The new text we proposed is:

"Link attributes MAY be advertised associated with zero-length Application 
Identifier Bit Masks for both standard applications and user-defined 
applications.
Such advertisements MUST be used by standard applications and/or user defined 
applications when no link attribute advertisements with a non-zero-length
Application Identifier Bit Mask and a matching Application Identifier Bit set 
are present for a given link. Otherwise, such advertisements MUST NOT be used."

This states both when zero-length ABM advertisements MUST be used and when they 
MUST NOT be used.

You have proposed different text:

"When an application specific link Attribute sub-TLV is advertised with one or 
more specific
standard application or user defined application bits set, all link attributes 
that are allowed in ASLA MUST
be used from the ASLA sub-TLVs having that specific application bit set.
For the purposes of such applications, link attributes MUST NOT be used from
ASLA sub-TLV with zero SABM & UDABM length."

This states when zero-length ABM advertisements MUST NOT be used - but it does 
not state when they MUST be used.
Instead, it states when non-zero length ABM advertisements MUST be used.
So this does not seem to be as complete as regards zero length ABM.

You seem to feel that there is confusion as to when non-zero ABM ASLA 
advertisements MUST be used - but I do not understand why that is the case.
You mention Maximum-Link-Bandwidth - for which there is a dedicated Section 
(4.2.1). The need for that section arises in order to make clear that different 
values for maximum-link-bandwidth are nonsensical and if they occur they all 
should be ignored.
But Section 4.2.1 also references Sections 4.2 and 6.2 to make clear that the 
same constraints regarding the use of zero length ABM advertisements apply to 
maximum-link-bandwidth.

So, I am not clear on what text is currently confusing, nor do I understand how 
your proposed text clarifies this confusion.

I am open to revising the proposed text - but I need more help from you to 
understand the source of confusion.

   Les


From: Lsr  On Behalf Of Shraddha Hegde
Sent: Wednesday, June 16, 2021 7:46 AM
To: Les Ginsberg (ginsberg) ; lsr@ietf.org
Cc: DECRAENE Bruno IMT/OLN ; Van De Velde, Gunter 
(Nokia - BE/Antwerp) 
Subject: Re: [Lsr] Proposed Errata for RFCs 8919/8920

Hi,

I think that there may still be some ambiguity arising from the text below due 
to the fact that
There are attributes such as maximum-link-bandwidth which have special 
behaviour mentioned in later sections.

"Link attributes MAY be advertised associated with zero-length Application 
Identifier Bit Masks for both standard applications and user-defined 
applications.
Such advertisements MUST be used by standard applications and/or user defined 
applications when no link attribute advertisements with a non-zero-length
Application Identifier Bit Mask and a matching Application Identifier Bit set 
are present for a given link. Otherwise, such advertisements MUST NOT be used."


For example, If max link bandwidth attribute comes in a
Zero length SABM & UDABM and we have a Flex-algo specific ASLA
that does not have the max-link-bandwidth advertised, can
Flex-algo use max-link-bandwidth attribute?

My interpretation from modified text for ISIS is that,  it cannot use it.
I think there is no harm in re-iterating in order to avoid people reading is 
differently.

Link attributes MAY be advertised associated with zero-length Application 
Identifier Bit Masks for both standard applications and user-defined 
applications.
Such advertisements MUST be used by standard applications and/or user defined 
applications when no link attribute advertisements with a non-zero-length
Application Identifier Bit Mask and a matching Application Identifier Bit set 
are present for a given link. Otherwise, such advertisements MUST NOT be used.
In other words,
When an application specific link Attribute sub-TLV is advertised with one or 
more specific
standard application or user defined application bits set, all link attributes 
that are allowed in ASLA MUST
be used from the ASLA sub-TLVs having that specific application bit set.
For the purposes of such applications, link attributes MUST NOT be used from
ASLA sub-TLV with zero SABM & UDABM length.


Rgds
Shraddha



Juniper Business Use Only
From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Les 
Ginsberg (ginsberg)
Sent: Tuesday, June 15, 2021 8:55 PM
To: lsr@ietf.org<mailto:lsr@ietf.org>
Cc: DECRAENE Bruno IMT/OLN 
mailto:bruno.decra...@orange.com>>; Van De Velde, 
Gunter (Nokia - BE/Antwerp) 
mailto:gunter.van_de_ve...@nokia.com>>
Subject: [Lsr] Proposed Errata for RFCs 8919/8920

[External Email. Be cautious of content]


Folks -



Recent discussions on t

Re: [Lsr] Proposed Errata for RFCs 8919/8920

[Les Ginsberg (ginsberg)]

Bruno -

Thanx for the prompt review.
I will incorporate your suggested change.

   Les


From: bruno.decra...@orange.com 
Sent: Tuesday, June 15, 2021 9:33 AM
To: Les Ginsberg (ginsberg) ; lsr@ietf.org
Cc: Van De Velde, Gunter (Nokia - BE/Antwerp) 
Subject: RE: Proposed Errata for RFCs 8919/8920

Les, Peter,

Thank you for agreeing to clarify the sentence and for the effort put in 
proposing a new text.

Proposed text looks much better to me. I particularly like the either MUST or 
MUST NOT statement.

I have one comment.
In the RFC, the term "advertisement" is used to refer both to sub-TLV [1] and 
to ASLA attribute [2]
[1] https://www.rfc-editor.org/rfc/rfc8919.html#name-legacy-advertisements
[2] https://www.rfc-editor.org/rfc/rfc8919.html#name-advertising-application-spe

As such, I would have a slight preference to be explicit about the type of 
advertisement which is meant. Especially since Gunter, an AD and myself raised 
that exact point, and that OSPF and IS-IS did not seemed aligned on this.

I would propose the following change in RFC 8919 section 4.2 & RFC 8920 section 
5
OLD: Such advertisements MUST
NEW: Such link attribute advertisements MUST

(I'm aware that the previous sentence starts with "Link attributes MAY be 
advertised", which in general should be a clear enough reference. But since we 
are clarifying, IMHO the more straightforward the clarification, the better, 
especially for the OSPF document which seemed to use the alternative 
understanding)


I definitely agree that this wording affects interoperability and must be fixed.
I'm not taking position (and don't care) whether an errata is the appropriate 
way. I'm happy to leave this to the chairs and AD. But my understanding is that 
if the errata is not classified as "Verified", then we'll need a bis document.

Thanks,
Regards,
--Bruno

From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Tuesday, June 15, 2021 5:25 PM
To: lsr@ietf.org<mailto:lsr@ietf.org>
Cc: DECRAENE Bruno INNOV/NET 
mailto:bruno.decra...@orange.com>>; Van De Velde, 
Gunter (Nokia - BE/Antwerp) 
mailto:gunter.van_de_ve...@nokia.com>>
Subject: Proposed Errata for RFCs 8919/8920


Folks -



Recent discussions on the list have highlighted some unintentional ambiguity in 
how ASLA advertisements are to be used. Please see 
https://mailarchive.ietf.org/arch/msg/lsr/prSLJDkMUnHm6h7VuCdn_Q7-1vg/



The following proposed Errata address this ambiguity and aligns language in the 
two RFCs.



We welcome comments on the proposed Errata before officially filing them.



  Les and Peter


Errata Explanation

Both RFC 8919 and RFC 8920 define advertising link attributes with zero length 
Standard Application Bit Mask (SABM) and zero length User Defined Application 
Bit Mask (UDABM)
as a means of advertising link attributes that can be used by any application. 
However, the text uses the word "permitted", suggesting that the use of such 
advertisements is "optional".
Such an interpretation could lead to interoperability issues and is not what 
was intended.

The replacement text below makes explicit the specific conditions when such 
advertisements MUST be used and the specific conditions under which they MUST 
NOT be used.

RFC 8919 Section 4.2:

OLD

"If link attributes are advertised associated with zero-length Application 
Identifier Bit Masks for both standard applications and user-defined 
applications,
then any standard application and/or any user-defined application is permitted 
to use that set of link attributes so long as there is not another set of 
attributes
advertised on that same link that is associated with a non-zero-length 
Application Identifier Bit Mask with a matching Application Identifier Bit set."

NEW

"Link attributes MAY be advertised associated with zero-length Application 
Identifier Bit Masks for both standard applications and user-defined 
applications.
Such advertisements MUST be used by standard applications and/or user defined 
applications when no link attribute advertisements with a non-zero-length
Application Identifier Bit Mask and a matching Application Identifier Bit set 
are present for a given link. Otherwise, such advertisements MUST NOT be used."

RFC 8919 Section 6.2

OLD

"Link attribute advertisements associated with zero-length Application 
Identifier Bit Masks for both standard applications and user-defined 
applications are usable
by any application, subject to the restrictions specified in Section 4.2. If 
support for a new application is introduced on any node in a network in the 
presence of such
advertisements, these advertisements are permitted to be used by the new 
application. If this is not what is intended, then existing advertisements MUST 
be readvertised
with an explicit set of applications specified before a new application is 
introduced."


NEW

"Link attribute advertisements associated with 

Re: [Lsr] draft-ietf-lsr-flex-algo

[Les Ginsberg (ginsberg)]

Gunter -

Thanx for digging into the origins of some of the ambiguity.

I have just sent proposed Errata for RFC 8919/8920 which addresses the issues 
raised and better aligns the text in the two RFCs.
Please review and comment on that new thread.

For the record, Option #1 is what is specified - and this is always what was 
intended.

   Les


From: Lsr  On Behalf Of Van De Velde, Gunter (Nokia - 
BE/Antwerp)
Sent: Tuesday, June 15, 2021 7:45 AM
To: bruno.decra...@orange.com; draft-ietf-lsr-flex-a...@ietf.org; lsr@ietf.org
Subject: Re: [Lsr] draft-ietf-lsr-flex-algo


Thanks for this interesting discussion. May I show a simple example to clarify 
a confusion, and I hope this helps to clarify implementation behavior:

Example: 2 ASLA TLV's are received for 1 link:

  *   ASLA TLV for all applications (SABML AND UDBML = 0) containing TE-Metric 
5 and Admin Group 7
  *   ASLA TLV with Flex-Algo bit set containing TE-Metric 10

What would the implementation have to follow?
Option 1: TE-Metric 10 used for Flex-algo, while Admin-Group 7 is not used. 
I.e. the overruling is done on ASLA TLV basis.
Option 2: TE-Metric 10, Admin-Group 7 have to be used for Flex-Algo. I.e. the 
overruling is done on a per attribute basis.

if you read the related ISIS and OSPF RFC's, they seem to contradict (as 
pointer out by Bruno Decraene):

  *   ISIS seems to expect Option 1
  *   OSPF seems to expect Option 2

Now, if we look all the way back to a year ago (12 June 2020):
https://mailarchive.ietf.org/arch/msg/lsr/TsjdMZmegf1SDO5B-X7y04mkgCM/
Then that conclusion of the DISCUSS seems to indicate Option 2.

snip
An application specific advertisement (Application Identifier Bit
Mask with a matching Application Identifier Bit set) for an attribute
MUST always be preferred over the advertisement of the same attribute
with the zero length Application Identifier Bit Masks for both
standard applications and user defined applications on the same link.
End Snip

This reads as option 2 seems to be the implementation of choice and overruling 
is done on a per attribute basis.

A fine question is what Les specifically means with "matching ASLA 
advertisements" ?
That can easily be read as the expected result is Option 1.

Long story short, what is the expected implementation behavior?
The DISCUSS indicate behavior as Option 2 (the overruling is done on a per 
attribute basis.)

G/

From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
bruno.decra...@orange.com
Sent: Friday, June 4, 2021 11:03 AM
To: 
draft-ietf-lsr-flex-a...@ietf.org; 
lsr@ietf.org
Subject: [Lsr] draft-ietf-lsr-flex-algo

Hi all,

I think that I may have an issue with the way FlexAlgo [2] uses ASLA [1]

FlexAlgo is distributed routing computation so it's required that all routers 
use exactly the same data to compute the routes/SPF.

FlexAlgo is clear that ASLA MUST be used:

"Link attribute advertisements that are to be used during Flex-

   Algorithm calculation MUST use the Application-Specific Link

   Attribute (ASLA) advertisements defined in 
[RFC8919] or 
[RFC8920],"

However ASLA provides multiple ways to advertise IGP attributes and does not 
seem precise enough in its specification.
"If link attributes are advertised associated with zero-length Application 
Identifier Bit Masks for both standard applications and user-defined 
applications, then any standard application and/or any user-defined application 
is permitted to use that set of link attributes"

My issue is the use of the term "permitted" which

  1.  is not a normative keyword
  2.  IMHO translates to MAY hence also MAY NOT. While we need a MUST to ensure 
a consistent SPF.



One example of issue is when FlexAlgo uses a metric different from the IGP 
(e.g. TE-metric) , and one node advertises this TE-metric in an ASLA with 
zero-length Bit Mask.
- If one node uses this TE-metric (since it is permitted to) it includes that 
link in its SPF
- If another node does not use this TE-metric (since it is not required to) it 
prunes that link from its SPF
I think it's self-evident that we would end up with a permanent routing loop.

Ideally, I would probably have preferred ALSA to be specific about the 
behaviour but ASLA is already published as RFC so it's a bit late
So at this point, I think that the burden is on FlexAlgo to specify the precise 
behaviour as a MUST in section 12. [2]

The smallest change from FlexAlgo draft standpoint may be to _require_ the use 
of the ASLA _with the X-Flag set_ . But I'm fine with whatever interoperable 
behaviour (well for me, ideally I'd prefer the behaviour already implemented by 
the implementations that I've deployed ;-) but that would be a selfish 
requirement).

Note that there are existing implementations and this would impact them. That 

[Lsr] Proposed Errata for RFCs 8919/8920

[Les Ginsberg (ginsberg)]

Folks -



Recent discussions on the list have highlighted some unintentional ambiguity in 
how ASLA advertisements are to be used. Please see 
https://mailarchive.ietf.org/arch/msg/lsr/prSLJDkMUnHm6h7VuCdn_Q7-1vg/



The following proposed Errata address this ambiguity and aligns language in the 
two RFCs.



We welcome comments on the proposed Errata before officially filing them.



  Les and Peter


Errata Explanation

Both RFC 8919 and RFC 8920 define advertising link attributes with zero length 
Standard Application Bit Mask (SABM) and zero length User Defined Application 
Bit Mask (UDABM)
as a means of advertising link attributes that can be used by any application. 
However, the text uses the word "permitted", suggesting that the use of such 
advertisements is "optional".
Such an interpretation could lead to interoperability issues and is not what 
was intended.

The replacement text below makes explicit the specific conditions when such 
advertisements MUST be used and the specific conditions under which they MUST 
NOT be used.

RFC 8919 Section 4.2:

OLD

"If link attributes are advertised associated with zero-length Application 
Identifier Bit Masks for both standard applications and user-defined 
applications,
then any standard application and/or any user-defined application is permitted 
to use that set of link attributes so long as there is not another set of 
attributes
advertised on that same link that is associated with a non-zero-length 
Application Identifier Bit Mask with a matching Application Identifier Bit set."

NEW

"Link attributes MAY be advertised associated with zero-length Application 
Identifier Bit Masks for both standard applications and user-defined 
applications.
Such advertisements MUST be used by standard applications and/or user defined 
applications when no link attribute advertisements with a non-zero-length
Application Identifier Bit Mask and a matching Application Identifier Bit set 
are present for a given link. Otherwise, such advertisements MUST NOT be used."

RFC 8919 Section 6.2

OLD

"Link attribute advertisements associated with zero-length Application 
Identifier Bit Masks for both standard applications and user-defined 
applications are usable
by any application, subject to the restrictions specified in Section 4.2. If 
support for a new application is introduced on any node in a network in the 
presence of such
advertisements, these advertisements are permitted to be used by the new 
application. If this is not what is intended, then existing advertisements MUST 
be readvertised
with an explicit set of applications specified before a new application is 
introduced."


NEW

"Link attribute advertisements associated with zero-length Application 
Identifier Bit Masks for both standard applications and user-defined 
applications are usable
by any application, subject to the restrictions specified in Section 4.2. If 
support for a new application is introduced on any node in a network in the 
presence of such
advertisements, the new application will use these advertisements, when the 
aforementioned restrictions are met. If this is not what is intended, then 
existing
advertisements MUST be readvertised with an explicit set of applications 
specified before a new application is introduced."



RFC 8920 Section 5

OLD

"If link attributes are advertised with zero-length Application Identifier Bit 
Masks for both standard applications and user-defined applications,
then any standard application and/or any user-defined application is permitted 
to use that set of link attributes. If support for a new application
is introduced on any node in a network in the presence of such advertisements, 
these advertisements are permitted to be used by the new
application. If this is not what is intended, then existing advertisements MUST 
be readvertised with an explicit set of applications specified
before a new application is introduced.

An application-specific advertisement (Application Identifier Bit Mask with a 
matching Application Identifier Bit set) for an attribute MUST
always be preferred over the advertisement of the same attribute with the 
zero-length Application Identifier Bit Masks for both standard
applications and user-defined applications on the same link."

NEW

"Link attributes MAY be advertised associated with zero-length Application 
Identifier Bit Masks for both standard applications and user-defined 
applications.
Such advertisements MUST be used by standard applications and/or user defined 
applications when no link attribute advertisements with a non-zero-length
Application Identifier Bit Mask and a matching Application Identifier Bit set 
are present for a given link. Otherwise, such advertisements MUST NOT be used."



RFC 8920 New Section between 12.1 and 12.2. Current sections following this new 
section will need to be renumbered.


12.2 Use of Zero-Length Application Identifier Bit Masks

"Link attribute advertisements associated with 

Re: [Lsr] draft-ietf-lsr-flex-algo

[Les Ginsberg (ginsberg)]

Bruno -

The intent of the RFC 8919 language is to say:

1)If there are ASLA advertisements w non-zero SABM/UABM matching the 
application,  these MUST be used
2)If there are no matching ASLA advertisements as per #1, then ASLA 
advertisements w zero length SABM/UABM (if present) MUST be used

There is no intent of making these rules "optional".

Peter and I are working on revised language that will make this more explicit 
(as well as resolving the unintentional discrepancies between the IS-IS/OSPF 
RFCs that you pointed out in an earlier thread).
Once language is agreed upon, these will be filed as Errata.
But it is important to note that this is a clarification - not a change in 
intended behavior.

Hope this is sufficient to address your concern.
Thanx for helping us to improve the quality of the RFCs.

   Les

From: Lsr  On Behalf Of bruno.decra...@orange.com
Sent: Friday, June 4, 2021 2:03 AM
To: draft-ietf-lsr-flex-a...@ietf.org; lsr@ietf.org
Subject: [Lsr] draft-ietf-lsr-flex-algo

Hi all,

I think that I may have an issue with the way FlexAlgo [2] uses ASLA [1]

FlexAlgo is distributed routing computation so it's required that all routers 
use exactly the same data to compute the routes/SPF.

FlexAlgo is clear that ASLA MUST be used:

"Link attribute advertisements that are to be used during Flex-

   Algorithm calculation MUST use the Application-Specific Link

   Attribute (ASLA) advertisements defined in 
[RFC8919] or 
[RFC8920],"

However ASLA provides multiple ways to advertise IGP attributes and does not 
seem precise enough in its specification.
"If link attributes are advertised associated with zero-length Application 
Identifier Bit Masks for both standard applications and user-defined 
applications, then any standard application and/or any user-defined application 
is permitted to use that set of link attributes"

My issue is the use of the term "permitted" which

  1.  is not a normative keyword
  2.  IMHO translates to MAY hence also MAY NOT. While we need a MUST to ensure 
a consistent SPF.



One example of issue is when FlexAlgo uses a metric different from the IGP 
(e.g. TE-metric) , and one node advertises this TE-metric in an ASLA with 
zero-length Bit Mask.
- If one node uses this TE-metric (since it is permitted to) it includes that 
link in its SPF
- If another node does not use this TE-metric (since it is not required to) it 
prunes that link from its SPF
I think it's self-evident that we would end up with a permanent routing loop.

Ideally, I would probably have preferred ALSA to be specific about the 
behaviour but ASLA is already published as RFC so it's a bit late
So at this point, I think that the burden is on FlexAlgo to specify the precise 
behaviour as a MUST in section 12. [2]

The smallest change from FlexAlgo draft standpoint may be to _require_ the use 
of the ASLA _with the X-Flag set_ . But I'm fine with whatever interoperable 
behaviour (well for me, ideally I'd prefer the behaviour already implemented by 
the implementations that I've deployed ;-) but that would be a selfish 
requirement).

Note that there are existing implementations and this would impact them. That 
been said, we do need the interop behaviour so if there are already 
inconsistent behaviours, some implementations will need to be changed (and 
hence become non interoperable with themselves)

Thanks,
Regards,
--Bruno


[1] https://www.rfc-editor.org/rfc/rfc8919.html
[2] https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-16#section-12


_



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.



This message and its attachments may contain confidential or privileged 
information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete 
this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.

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

Re: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID Advertisement"

[Les Ginsberg (ginsberg)]

I support adoption of this draft.

I believe that there are use cases for algorithm specific adjacency-sids - 
primarily (and non-controversially) to provide algorithm specific repair paths.

As others have commented, other use cases mentioned in this draft involve 
introducing significant new functionality which has not been discussed or 
accepted by the WG (e.g., resource allocation). This topic deserves to be 
reviewed by the WG on its own merit in a separate draft.

This draft should confine itself to defining the new advertisements required to 
support algorithm specific adjacency-sids and discussing the repair path use 
case.

I would also like to see some discussion of deployment considerations including:

a)When to allocate/advertise algorithm specific adjacency-sids vs when to 
continue to use algorithm independent adjacency sids.
b)Strict-SID algo-sids are not useful
c)Use case should drive the type(s) of algorithm specific adjacency-sids 
allocated/advertised. For example,  if primary use case is for algorithm 
specific repair paths, then only sids with B flag set ("eligible for 
protection") are required.

Simply allocating algorithm specific adjacency SIDs for all supported 
algorithms all the time is a recipe for bloating the protocol link 
advertisements unnecessarily.

   Les

> -Original Message-
> From: Lsr  On Behalf Of Christian Hopps
> Sent: Wednesday, May 26, 2021 1:57 PM
> To: lsr@ietf.org
> Cc: cho...@chopps.org
> Subject: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID
> Advertisement"
> 
> 
> Hi Folks,
> 
> This begins a 2 week WG Adoption Call for the following draft:
> 
> https://datatracker.ietf.org/doc/draft-peng-lsr-algorithm-related-adjacency-
> sid/
> 
> Please indicate your support or objections by June 9th, 2021
> 
> Authors, please respond to the list indicating whether you are aware of any 
> IPR
> that applies to this draft.
> 
> Thanks,
> Acee and Chris.
> 
> ___
> 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] John Scudder's No Objection on draft-ietf-lsr-isis-srv6-extensions-14: (with COMMENT)

[Les Ginsberg (ginsberg)]

Alvaro -

I don’t find the referenced draft relevant to this case.

Our difference of opinion has to do with the function of a codepoint registry.
Registries are created as a place to both document existing codepoints and to 
be updated when the need for additional codepoints arises.
There is no benefit or need (IMO of course) for an RFC which initially created 
the registry to be marked as "updated" when new codepoints are added to the 
registry - which is really all that is happening here.

Is there anything in RFC 7370 that states or implies that the name of the 
registry is not subject to change?
Is there anything in RFC 7370 that states or implies that the set of TLVs under 
the purview of the registry is not subject to change?
Why are either of these cases functionally any different from adding a new 
sub-TLV codepoint to the registry?

I do agree that this is not worth the time being spent on it. So, you have my 
input. I leave it to the ADs/WG chairs/IESG review to close this issue.
Thanx for listening.

   Les


> -Original Message-
> From: Alvaro Retana 
> Sent: Wednesday, May 19, 2021 6:55 AM
> To: Les Ginsberg (ginsberg) ; Acee Lindem (acee)
> ; Peter Psenak (ppsenak) ; John
> Scudder 
> Cc: John Scudder via Datatracker ; draft-ietf-lsr-isis-srv6-
> extensi...@ietf.org; Christian Hopps ; lsr-
> cha...@ietf.org; lsr@ietf.org; The IESG 
> Subject: RE: John Scudder's No Objection on draft-ietf-lsr-isis-srv6-
> extensions-14: (with COMMENT)
> 
> Les:
> 
> Hi!
> 
> In this case the name is being changed, a new column is added, and all
> the existing code points are updated in light of the new column.
> 
> I realize this may not be enough for you.  Instead of all of us
> discussing this specific case, we should focus our energy on clearly
> defining what “Updates” means — there’s a proposal that could be a
> starting point [1].
> 
> Thanks!
> 
> Alvaro.
> 
> [1] https://datatracker.ietf.org/doc/html/draft-kuehlewind-update-tag
> 
> 
> 
> On May 19, 2021 at 12:33:27 AM, Les Ginsberg wrote:
> 
> > The only legitimate reason to update an older
> > document would be if we are actually changing
> > in some way one or more of the existing codepoints
> > already defined in the registry. That is not
> > happening here.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] John Scudder's No Objection on draft-ietf-lsr-isis-srv6-extensions-14: (with COMMENT)

[Les Ginsberg (ginsberg)]

Sorry folks - one more attempt to correct what I see as inappropriate 
dependencies.

Codepoint registries are created in part precisely to avoid having to update 
pre-existing documents when we need to add additional codepoints to the 
registry. The registry is the living entity and when additions are required we 
update the registry - not older documents which have contributed to the 
existing contents of the registry. Nor do we have to generate a new document to 
present the updated contents of the registry. All of that is handled simply by 
updating the registry.

The only legitimate reason to update an older document would be if we are 
actually changing in some way one or more of the existing codepoints already 
defined in the registry. That is not happening here.

The suggestion that RFC 7370 needs to be "updated" because 
draft-ietf-lsr-isis-srv6-extensions requires additions to an existing registry 
first created by RFC 7370 stands the dependency relationship between a registry 
and the document(s) which specify entries in the registry on its head.

The argument here seems to be that we are "changing the name of the registry" - 
hence the document that first created the registry with the existing name has 
to be considered as updated. This is illogical. The renaming of the registry in 
no way alters any of the existing codepoints.
This is certainly not what was done when RFC 8668 modified 
https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-22-23-25-141-222-223
  - another registry created by RFC 7370.

Perhaps the somewhat unfortunate choice of the name of the registry - which 
inserts the codepoint for all the TLVs supported by the registry into the 
registry name - feeds into this confusion.
If so, I would suggest renaming the registry to:  "Sub-TLVs for TLVs 
advertising NLRI".
The registry name would then never have to be changed and we could more easily 
avoid being drawn into an inappropriate use of "update".

   Les



> -Original Message-
> From: Acee Lindem (acee) 
> Sent: Monday, May 17, 2021 7:03 AM
> To: Peter Psenak (ppsenak) ; John Scudder
> 
> Cc: Alvaro Retana ; Les Ginsberg (ginsberg)
> ; John Scudder via Datatracker ;
> draft-ietf-lsr-isis-srv6-extensi...@ietf.org; lsr@ietf.org; 
> lsr-cha...@ietf.org;
> The IESG ; Christian Hopps 
> Subject: Re: John Scudder's No Objection on draft-ietf-lsr-isis-srv6-
> extensions-14: (with COMMENT)
> 
> Hi Peter,
> 
> On 5/17/21, 9:07 AM, "Peter Psenak"  wrote:
> 
> Hi Acee,
> 
> On 17/05/2021 14:56, Acee Lindem (acee) wrote:
> > Hi John,
> >
> > Yes – I think “updates” should be removed. Registries are created
> > explicitly for the purpose of tracking extensions and every document
> > that adds to a registry should not update the document creating that
> > registry. Now if the definition or application of the registry were
> > changed, which I don’t believe is the case here, then we could consider
> > “updates”.
> 
> RFC 7370 created the registry by merging multiple existing registries.
> It did not really defined any new functionality.
> 
> We are changing the name of that merged registry. Given that RFC 7370
> did not define anything new, just defined the merged registry, one can
> consider the name change as an update to RFC 7370.
> 
> Ok - I missed that. I agree with that it updates RFC 7370 since the registry
> name changed as opposed to simply adding code points.
> 
> Thanks,
> Acee
> 
> thanks,
> Peter
>     >
> > Thanks,
> >
> > Acee
> >
> > *From: *John Scudder 
> > *Date: *Monday, May 17, 2021 at 8:48 AM
> > *To: *Acee Lindem 
> > *Cc: *Alvaro Retana , "Les Ginsberg
> (ginsberg)"
> > , "Peter Psenak (ppsenak)"
> , John
> > Scudder via Datatracker ,
> > "draft-ietf-lsr-isis-srv6-extensi...@ietf.org"
> > , "lsr@ietf.org"
> > , "lsr-cha...@ietf.org" , The IESG
> > , Christian Hopps 
> > *Subject: *Re: John Scudder's No Objection on
> > draft-ietf-lsr-isis-srv6-extensions-14: (with COMMENT)
> >
> > Acee,
> >
> > I think you are saying you prefer to remove the “updates”. Is that
> > right? It was a little confusing given the reply chain.
> >
> > (I’ve already given my opinion but said I’m not going to go to the mat
> > over it.)
> >
> > —John
> >
> >
> >
> > On May 17, 2021, at 8:21 AM, Acee Lindem (acee)
> >  wrote:
> >
&g

Re: [Lsr] John Scudder's No Objection on draft-ietf-lsr-isis-srv6-extensions-14: (with COMMENT)

[Les Ginsberg (ginsberg)]

Alvaro –

FWIW, I agree w John here.

There are many examples – to cite a few:

Sub-TLVs for TLVs 22, 23, 25, 141, 222, and 223 (Extended IS reachability, IS 
Neighbor Attribute, L2 Bundle Member Attributes, inter-AS reachability 
information, MT-ISN, and MT IS Neighbor Attribute TLVs)
…
Reference
[RFC5305][RFC5316][RFC7370][RFC8668]

RFC 8868 is not marked as updating RFC 7370.
RFC 7370 is not marked as updating RFC 5316/RFC 5305.

Sub-TLVs for TLVs 135, 235, 236, and 237 (Extended IP reachability, MT IP. 
Reach, IPv6 IP. Reach, and MT IPv6 IP. Reach TLVs)
…
Reference
[RFC5305][RFC7370]

Again, RFC7370 is not marked as updating RFC 5305.

I think it is sufficient to request that IANA add the new RFC to the list of 
References for the modified registry.

   Les


From: Lsr  On Behalf Of John Scudder
Sent: Thursday, May 13, 2021 11:00 AM
To: Alvaro Retana 
Cc: John Scudder via Datatracker ; Christian Hopps 
; lsr-cha...@ietf.org; The IESG ; 
draft-ietf-lsr-isis-srv6-extensi...@ietf.org; lsr@ietf.org
Subject: Re: [Lsr] John Scudder's No Objection on 
draft-ietf-lsr-isis-srv6-extensions-14: (with COMMENT)

On May 13, 2021, at 1:20 PM, Alvaro Retana 
mailto:aretana.i...@gmail.com>> wrote:

  This documents updates RFC 7370 by modifying an existing registry.

Also, this doesn’t seem to me like an update to RFC 7370. It’s normal for an
RFC to update an IANA registry, without saying it updates a previous RFC that
established that registry. I think the “updates” just confuses matters and
clutters things up, and should be removed.

In this case the document is not only registering a value.  It is
changing the name of the registry, adding an extra column, and
updating all the other entries (§11.1.*).  The Updates tag is used
because it significantly changes the registry.

Still seems unnecessary to me, registries are moving targets, citation of all 
the relevant RFCs in their references should be sufficient. So, the registry 
would be updated so that it cited both this spec and 7370, and someone wanting 
to know “how did the registry get this way?” would be able to work it out.

I’m not going to fight about it; the “updates” is not very harmful. I say “not 
very” because the diligent reader might be led to think they need to go read 
RFC 7370 in order to properly understand this spec, and waste some time 
realizing that isn’t true. Since for better or worse we don’t have a firm 
definition of when we do, and don’t, use “updates”, it comes down to a matter 
of personal taste in the end.

$0.02,

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

Re: [Lsr] Last Call: (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed Standard

[Les Ginsberg (ginsberg)]

Alvaro (and everyone) - 

I think we can do better than this.

Prefix-attributes sub-TLV is necessary when a prefix is leaked between levels - 
and more specifically when leaked upwards in the hierarchy.
(We have the "D" bit in the TLV itself when leaked downwards.)

While I would prefer that we simplify things and simply require the sub-TLV all 
the time, I think we can be more generous and still be functional.

1)Prefix-attributes SHOULD be included in Locator TLV
2)Prefix-attributes MUST be included when TLV is leaked upwards in the hierarchy
3)Prefix-attributes sub-TLV MUST be included when the advertisement is 
"redistributed" from another protocol

Note that because the sub-TLV is not mandatory, if #2 and #3 are NOT followed, 
receivers will be unable to determine the correct source of the advertisement 
and may do the "wrong thing". And the receivers will be unable to detect the 
violation.

Finally, RFC 7794 was published over 5 years ago.
Vendors make their own choices as to what protocol extensions they choose to 
support. But given the usefulness of the information in prefix-attributes 
sub-TLV I would encourage implementations which do not yet support the sub-TLV 
to add it.

   Les


> -Original Message-
> From: Alvaro Retana 
> Sent: Wednesday, May 12, 2021 7:17 AM
> To: Gengxuesong (Geng Xuesong) ; Peter
> Psenak (ppsenak) ; bruno.decra...@orange.com
> Cc: Van De Velde, Gunter (Nokia - BE/Antwerp)
> ; draft-ietf-lsr-isis-srv6-
> extensi...@ietf.org; Les Ginsberg (ginsberg) ;
> Shraddha Hegde ; lsr@ietf.org;
> cho...@chopps.org
> Subject: Re: [Lsr] Last Call:  
> (IS-IS
> Extension to Support Segment Routing over IPv6 Dataplane) to Proposed
> Standard
> 
> Peter:
> 
> 
> Hi!
> 
> As Xuesong suggested earlier, could you/we live with “SHOULD send”?
> The mitigating circumstance (recommend vs require) is precisely the
> lack of support.  I think your original reply to Gunter about how it
> could be hard to mandate the Flags TLV at this point is spot on.
> 
> Thanks!
> 
> Alvaro.
> 
> 
> 
> On May 12, 2021 at 4:49:58 AM, Peter Psenak wrote:
> 
> > as I said, if we want to mandate the presence of the Prefix Attribute
> > sub-TLV, we MUST ignore Locators without it. If we don't, then the MUST
> > on the originator does not mean anything.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Last Call: (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed Standard

[Les Ginsberg (ginsberg)]

Shraddha/ Xuesong -

Since Prefix Attributes sub-TLV is required for correct operation when a 
Locator is leaked, would it be safe to assume that your implementations either 
do not leak Locators or you advise your customers not to deploy this feature 
with multiple levels?

The problem with allowing the sub-TLV to be optional is that if the sub-TLV is 
omitted you cannot tell whether the Locator has been leaked - so you don't know 
whether you have a problem or not.

The safest thing to do is require prefix-attributes sub-TLV always - then you 
can guarantee that if the prefix is leaked the necessary information will be 
present.
Anything else leaves us vulnerable.

We all appreciate interoperability considerations, but frankly this is a gap 
that needs to be closed to support correct operation.

   Les

From: Lsr  On Behalf Of Shraddha Hegde
Sent: Tuesday, May 11, 2021 8:21 AM
To: Alvaro Retana ; Peter Psenak (ppsenak) 
; lsr@ietf.org
Cc: cho...@chopps.org; draft-ietf-lsr-isis-srv6-extensi...@ietf.org; Van De 
Velde, Gunter (Nokia - BE/Antwerp) 
Subject: Re: [Lsr] Last Call:  
(IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed 
Standard

Juniper has an  implementation of SRv6 that does not support Prefix attributes 
sub-tlv in locator TLV.
We would prefer not to change the optional sub-TLV to MUST.

Rgds
Shraddha




Juniper Business Use Only
From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
Alvaro Retana
Sent: Friday, May 7, 2021 7:23 PM
To: Peter Psenak mailto:ppse...@cisco.com>>; 
lsr@ietf.org
Cc: cho...@chopps.org; 
draft-ietf-lsr-isis-srv6-extensi...@ietf.org;
 Van De Velde, Gunter (Nokia - BE/Antwerp) 
mailto:gunter.van_de_ve...@nokia.com>>
Subject: Re: [Lsr] Last Call:  
(IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed 
Standard

[External Email. Be cautious of content]

On May 3, 2021 at 5:17:58 AM, Peter Psenak wrote:

> Technically I agree with you and if everybody agrees, I'm fine to
> enforce the presence of the Prefix Attribute Flags TLV in the Locator TLV.

So...what does everyone else think?

We need to close on this point before the IESG evaluates the document.  I'm 
requesting it to be put on the May/20 telechat, which means that we should have 
a resolution and updated draft by the end of next week.


Thanks!

Alvaro.



On May 3, 2021 at 5:17:58 AM, Peter Psenak 
(ppse...@cisco.com) wrote:
Hi Gunter,

Prefix Attribute Flags Sub-TLV has been defined as an optional Sub-TLV.
The problem you describe is not specific to Locator TLV, same applies to
regular IPv4/v6 prefixes (forget SR MPLS for a while) - if the Prefix
Attribute Flags TLV is not included, one can not tell whether the prefix
has been propagated (L1->L2) or generated as a result of the local
interface attached on the originator. Same applies to redistribution and
R-flag for IPv4 prefix TLVs.

SRv6 Locator TLV has been defined a while back and the Prefix Attribute
Flags Sub-TLV has always been an optional Sub-TLV of it. I'm not sure we
can start to mandate the Prefix Attribute Flags TLV at this point.

Technically I agree with you and if everybody agrees, I'm fine to
enforce the presence of the Prefix Attribute Flags TLV in the Locator TLV.

thanks,
Peter


On 03/05/2021 10:45, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote:
> Hi Peter, All,
>
> Could we update to "draft-ietf-lsr-isis-srv6-extensions" that the 
> prefix-attribute tlv is mandatory when a locator is redistributed?
>
> Why?
> *When calculating a LFA for an SRv6 End.SID we better know if the locator has 
> been redistributed or not for a correct operation.
>
> Reasoning:
> * A locator has the D bit. This one is set when we redistribute from L2 to L1.
> ** So this end-sid will not be used as we know that it is redistributed.
>
> * In the other direction (L1-L2), we only know that a locator is 
> redistributed from L1 to L2 if the prefix-attribute sub-tlv is advertised.
> ** This means if the operator does not configure advertisement of the 
> prefix-attribute tlv, ISIS could potentially use an end-sid which does not 
> terminate on the expected node.
>
> * Compared to sr-mpls, a prefix-sid has the R flag indicating it is 
> redistributed.
> * We don't have that for locator end-sids.
>
> Relevant snip from " draft-ietf-lsr-isis-srv6-extensions"
>
> 7.1. SRv6 Locator TLV Format
>
> The SRv6 Locator TLV has the following format:
>
> 0 1 2 3
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Type | Length |R|R|R|R| MT ID |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> Type: 27
>
> Length: variable.
>
> R bits: reserved for future use. They MUST be
> set to zero on transmission and MUST be ignored on receipt.
>
> MT ID: Multitopology Identifier as defined in [RFC5120].
> Note 

Re: [Lsr] Last Call: (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed Standard

[Les Ginsberg (ginsberg)]

As has been mentioned in this thread, the need for the prefix-attributes 
sub-TLV to correctly process leaked advertisements is not unique to the Locator 
TLV. The reason prefix-attributes TLV was created was to address the same gap 
with IP/IPv6 reachability advertisements.
And I think by now implementations (certainly ones that support newer 
functionality like SRv6) should have added support for prefix-attributes 
sub-TLV .

In the case of the Locator TLV  – since this is new functionality – we have the 
option of mandating prefix-attributes sub-TLV – something we could not do with 
IP/IPv6 Reachability since that has been deployed for many years.

But,  please recognize two consequences of the MUST option:

1)Implementations may have to deal w  backwards compatibility w early 
deployments of SRv6. This would only be an issue if there are implementations 
that currently do NOT send prefix-attributes sub-TLV w Locator TLV.
Are there any such implementations??

2)In the case where the deployment is a single level, it could be argued that 
prefix-attributes sub-TLV isn’t needed.
I personally would NOT make such an argument, but we should understand that 
MUST applies to this case as well.

If everyone is OK with these consequences (personally I am OK) then I think it 
is fine to go with MUST.

   Les


From: Lsr  On Behalf Of Ketan Talaulikar (ketant)
Sent: Friday, May 07, 2021 7:00 AM
To: Alvaro Retana ; Peter Psenak (ppsenak) 
; lsr@ietf.org
Cc: cho...@chopps.org; draft-ietf-lsr-isis-srv6-extensi...@ietf.org; Van De 
Velde, Gunter (Nokia - BE/Antwerp) 
Subject: Re: [Lsr] Last Call:  
(IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed 
Standard

Hi Peter,

I agree that the support for the Prefix Attribute Flags TLV is required in the 
Locator TLV.

Thanks,
Ketan

From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
Alvaro Retana
Sent: 07 May 2021 19:23
To: Peter Psenak (ppsenak) mailto:ppse...@cisco.com>>; 
lsr@ietf.org
Cc: cho...@chopps.org; 
draft-ietf-lsr-isis-srv6-extensi...@ietf.org;
 Van De Velde, Gunter (Nokia - BE/Antwerp) 
mailto:gunter.van_de_ve...@nokia.com>>
Subject: Re: [Lsr] Last Call:  
(IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed 
Standard

On May 3, 2021 at 5:17:58 AM, Peter Psenak wrote:

> Technically I agree with you and if everybody agrees, I'm fine to
> enforce the presence of the Prefix Attribute Flags TLV in the Locator TLV.

So...what does everyone else think?

We need to close on this point before the IESG evaluates the document.  I'm 
requesting it to be put on the May/20 telechat, which means that we should have 
a resolution and updated draft by the end of next week.


Thanks!

Alvaro.



On May 3, 2021 at 5:17:58 AM, Peter Psenak 
(ppse...@cisco.com) wrote:
Hi Gunter,

Prefix Attribute Flags Sub-TLV has been defined as an optional Sub-TLV.
The problem you describe is not specific to Locator TLV, same applies to
regular IPv4/v6 prefixes (forget SR MPLS for a while) - if the Prefix
Attribute Flags TLV is not included, one can not tell whether the prefix
has been propagated (L1->L2) or generated as a result of the local
interface attached on the originator. Same applies to redistribution and
R-flag for IPv4 prefix TLVs.

SRv6 Locator TLV has been defined a while back and the Prefix Attribute
Flags Sub-TLV has always been an optional Sub-TLV of it. I'm not sure we
can start to mandate the Prefix Attribute Flags TLV at this point.

Technically I agree with you and if everybody agrees, I'm fine to
enforce the presence of the Prefix Attribute Flags TLV in the Locator TLV.

thanks,
Peter


On 03/05/2021 10:45, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote:
> Hi Peter, All,
>
> Could we update to "draft-ietf-lsr-isis-srv6-extensions" that the 
> prefix-attribute tlv is mandatory when a locator is redistributed?
>
> Why?
> *When calculating a LFA for an SRv6 End.SID we better know if the locator has 
> been redistributed or not for a correct operation.
>
> Reasoning:
> * A locator has the D bit. This one is set when we redistribute from L2 to L1.
> ** So this end-sid will not be used as we know that it is redistributed.
>
> * In the other direction (L1-L2), we only know that a locator is 
> redistributed from L1 to L2 if the prefix-attribute sub-tlv is advertised.
> ** This means if the operator does not configure advertisement of the 
> prefix-attribute tlv, ISIS could potentially use an end-sid which does not 
> terminate on the expected node.
>
> * Compared to sr-mpls, a prefix-sid has the R flag indicating it is 
> redistributed.
> * We don't have that for locator end-sids.
>
> Relevant snip from " draft-ietf-lsr-isis-srv6-extensions"
>
> 7.1. SRv6 Locator TLV Format
>
> The SRv6 Locator TLV has the following format:
>
> 0 1 2 3
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> 

Re: [Lsr] Doubt regarding A bit set/clear

[Les Ginsberg (ginsberg)]

Gurusiddesh -

From: Gurusiddesh Nidasesi 
Sent: Friday, April 23, 2021 5:58 AM
To: Les Ginsberg (ginsberg) 
Cc: Acee Lindem (acee) ; lsr@ietf.org; 
spencer.giacal...@gmail.com; stef...@previdi.net; Dona Maria John 
; Vikram Agrawal ; 
Mahalakshmi Kumar 
Subject: Re: [Lsr] Doubt regarding A bit set/clear

Hi Les,

Thank you very much for your response.
On top of your response, I have a few more queries. Please find them below.

1. For Min/Max Unidirectional Link Delay Sub-TLV, there is only one A-bit.



 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|   Type| Length|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|A| RESERVED|   Min Delay   |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|   RESERVED|   Max Delay   |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Does this mean A-bit is applicable only for Min-delay?

[Les:] The RFC states in Section 4.2 (emphasis added):



“A bit:  This field represents the Anomalous (A) bit.  The A bit is

  set when one or more measured values exceed a configured maximum

  threshold…”



I think the rest you can figure out for yourself.



   Les







IF not, then should we maintain 2 different maximum threshold and reuse 
thresholds?

And if both min-delay and max-delay values fall below reuse threshold we have 
clear A-bit.



Will below example follow the RFC?
min-delay reuse threshold : 50 usec
min-delay maximum threshold : 100 usec

max-delay reuse threshold : 200 usec
max-delay maximum threshold : 300 usec



1st measured value:

min-delay: 110 usec

max-delay: 190 usec

conclusion: Set A bit. (As min-delay value has exceeded max-threshold value?)

2nd measured value :

min-delay: 40 usec

max-delay: 320 usec



conclusion : Do nothing (Maintain pervious state of A bit as max-delay value 
has exceeded max-threshold value?)

3rd measured value :

min-delay: 40 usec

max-delay: 150 usec

conclusion : Clear A bit (As both min-delay and max-delay values are falling 
below resue threshold?)



Thanks & Regards,

Gurusiddesh V N


On Fri, Apr 23, 2021 at 4:51 PM Les Ginsberg (ginsberg) 
mailto:ginsb...@cisco.com>> wrote:
Gurusiddesh –

The short answer to all your questions is “yes”.
More inline.

From: Gurusiddesh Nidasesi 
mailto:gurusiddesh.nidas...@ipinfusion.com>>
Sent: Thursday, April 22, 2021 10:33 PM
To: Acee Lindem (acee) mailto:a...@cisco.com>>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>; 
spencer.giacal...@gmail.com<mailto:spencer.giacal...@gmail.com>; 
stef...@previdi.net<mailto:stef...@previdi.net>; Les Ginsberg (ginsberg) 
mailto:ginsb...@cisco.com>>; Dona Maria John 
mailto:dona.j...@ipinfusion.com>>; Vikram Agrawal 
mailto:vikram.agra...@ipinfusion.com>>; 
Mahalakshmi Kumar 
mailto:mahalakshmi.udh...@ipinfusion.com>>
Subject: Re: [Lsr] Doubt regarding A bit set/clear

Hi All.

Gentle Reminder!

Regards,
Gurusiddesh V N

On Mon, Apr 19, 2021 at 6:54 PM Acee Lindem (acee) 
mailto:a...@cisco.com>> wrote:
Gurusiddesh,

I’ll defer to the RFC authors on your question. However, please refrain from 
referring to bits as being “unset”. They are set or clear.

Thanks,
Acee

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of 
Gurusiddesh Nidasesi 
mailto:gurusiddesh.nidas...@ipinfusion.com>>
Date: Monday, April 19, 2021 at 6:13 AM
To: "lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>
Cc: Spencer Giacalone 
mailto:spencer.giacal...@gmail.com>>, Stefano 
Previdi mailto:stef...@previdi.net>>, "Les Ginsberg 
(ginsberg)" mailto:ginsb...@cisco.com>>, Dona Maria John 
mailto:dona.j...@ipinfusion.com>>, Vikram Agrawal 
mailto:vikram.agra...@ipinfusion.com>>, 
Mahalakshmi Kumar 
mailto:mahalakshmi.udh...@ipinfusion.com>>
Subject: [Lsr] Doubt regarding A bit set/unset

Hi All,

I had a query regarding setting/unsetting A bit.

https://tools.ietf.org/html/rfc8570#section-4.1 states that

A bit:  This field represents the Anomalous (A) bit.  The A bit is

  set when the measured value of this parameter exceeds its

  configured maximum threshold.  The A bit is cleared when the

  measured value falls below its configured reuse threshold.  If the

  A bit is cleared, the sub-TLV represents steady-state link

  performance.



So does it mean we have to have two configurations one for reuse and another 
for maximum threshold?

[Les:] Yes. The goal is to prevent altering the advertisement due to small 
oscillations of the advertisement. If you had a single value then if the 
measured value bounced between (for example) +1/-1 of the threshold) the 
advertisement of the A-bit would change rapidly – this is undesirable.

So the max threshold triggers setting

Re: [Lsr] Doubt regarding A bit set/clear

[Les Ginsberg (ginsberg)]

Gurusiddesh –

The short answer to all your questions is “yes”.
More inline.

From: Gurusiddesh Nidasesi 
Sent: Thursday, April 22, 2021 10:33 PM
To: Acee Lindem (acee) 
Cc: lsr@ietf.org; spencer.giacal...@gmail.com; stef...@previdi.net; Les 
Ginsberg (ginsberg) ; Dona Maria John 
; Vikram Agrawal ; 
Mahalakshmi Kumar 
Subject: Re: [Lsr] Doubt regarding A bit set/clear

Hi All.

Gentle Reminder!

Regards,
Gurusiddesh V N

On Mon, Apr 19, 2021 at 6:54 PM Acee Lindem (acee) 
mailto:a...@cisco.com>> wrote:
Gurusiddesh,

I’ll defer to the RFC authors on your question. However, please refrain from 
referring to bits as being “unset”. They are set or clear.

Thanks,
Acee

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of 
Gurusiddesh Nidasesi 
mailto:gurusiddesh.nidas...@ipinfusion.com>>
Date: Monday, April 19, 2021 at 6:13 AM
To: "lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>
Cc: Spencer Giacalone 
mailto:spencer.giacal...@gmail.com>>, Stefano 
Previdi mailto:stef...@previdi.net>>, "Les Ginsberg 
(ginsberg)" mailto:ginsb...@cisco.com>>, Dona Maria John 
mailto:dona.j...@ipinfusion.com>>, Vikram Agrawal 
mailto:vikram.agra...@ipinfusion.com>>, 
Mahalakshmi Kumar 
mailto:mahalakshmi.udh...@ipinfusion.com>>
Subject: [Lsr] Doubt regarding A bit set/unset

Hi All,

I had a query regarding setting/unsetting A bit.

https://tools.ietf.org/html/rfc8570#section-4.1 states that

A bit:  This field represents the Anomalous (A) bit.  The A bit is

  set when the measured value of this parameter exceeds its

  configured maximum threshold.  The A bit is cleared when the

  measured value falls below its configured reuse threshold.  If the

  A bit is cleared, the sub-TLV represents steady-state link

  performance.



So does it mean we have to have two configurations one for reuse and another 
for maximum threshold?

[Les:] Yes. The goal is to prevent altering the advertisement due to small 
oscillations of the advertisement. If you had a single value then if the 
measured value bounced between (for example) +1/-1 of the threshold) the 
advertisement of the A-bit would change rapidly – this is undesirable.

So the max threshold triggers setting of the A-bit and the reuse threshold 
triggers clearing of the bit. The reuse threshold provides some confidence that 
the measurement has stabilized below the maximum anomalous threshold.





Will below example follow the RFC?

reuse threshold : 50 usec

maximum threshold : 100 usec

1st measured value : 110 usec

conclusion: Set A bit.



2nd measured value : 75 usec

conclusion : Do nothing (Maintain pervious state of A bit as the value is less 
than reuse or greater than threshold)



3rd measurement value : 30 usec

conclusion: Unset A bit.



[Les:] Yes this conforms to specified behavior.



 If we have to have two configuration for threshold to set/unset A bit, will 
they be different from the threshold that we use for advertisements?

[Les:] Yes .  This is clearly stated in Section 5:



“4.  For sub-TLVs that include an A bit, an additional threshold

   SHOULD be included corresponding to the threshold for which the

   performance is considered anomalous (and sub-TLVs with the A bit

   are sent)…”
   Les



Regards,
Gurusiddesh V N

.


--
Thanks,
Gurusiddesh V N

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

Re: [Lsr] Guidance for IANA flags field registry creation.

[Les Ginsberg (ginsberg)]

Tony -

Because this is shared between OSPF and IS-IS the related registry is in a 
different location.

https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml#link-attribute-application-identifiers

as defined in 

https://www.rfc-editor.org/rfc/rfc8919.html#section-7.4 

For me, this falls into the same category as 
https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#prefix-attribute-flags
 . 
It is a general purpose flags field that was expected to be updated by a 
variety of otherwise unrelated documents and so we defined a registry for it.
This category of flags field was never under discussion - I thought you and I 
had agreed on this explicitly early on.

   Les


> -Original Message-
> From: Tony Li 
> Sent: Wednesday, April 21, 2021 7:47 AM
> To: Les Ginsberg (ginsberg) 
> Cc: Christian Hopps ; lsr@ietf.org; lsr-...@ietf.org; lsr-
> cha...@ietf.org
> Subject: Re: [Lsr] Guidance for IANA flags field registry creation.
> 
> 
> Les,
> 
> > I did (an admittedly casual) review of such fields in all TLVs defined 
> > during
> the existence of the IS-IS/LSR WGs - which covers over 20 years. I did not 
> find
> a single occurrence where the flags field ever got extended.
> 
> 
> draft-ietf-isis-te-app defines the Application Specific Link Attributes TLV.
> That includes the Standard Application Identifier Bit Mask and defines three
> bits.
> 
> draft-ietf-lsr-flex-algo extends this with one bit for FlexAlgo.
> 
> So there is one example.
> 
> Tony

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

Re: [Lsr] Guidance for IANA flags field registry creation.

[Les Ginsberg (ginsberg)]

Chris -

I don’t mean to argue the point. If you are not actually inviting 
discussion...OK.

But since you say:

" After some experience with the guidance, we could then choose to make it
or some variation, the policy if that was still needed."

I will provide you with this datapoint.

I did (an admittedly casual) review of such fields in all TLVs defined during 
the existence of the IS-IS/LSR WGs - which covers over 20 years. I did not find 
a single occurrence where the flags field ever got extended.
So I do not know why we should expect that experience during the next 20 years 
will be significantly different. This, to me, argues that Tony's proposal is 
better.

Anyways, I am done...thanx for listening.

   Les


> -Original Message-
> From: Christian Hopps 
> Sent: Wednesday, April 21, 2021 7:05 AM
> To: Les Ginsberg (ginsberg) 
> Cc: lsr@ietf.org; lsr-cha...@ietf.org; lsr-...@ietf.org
> Subject: Re: [Lsr] Guidance for IANA flags field registry creation.
> 
> Hi Les,
> 
> This isn't a proposal, it is the guidance we have come up with based on what
> we read in the WG discussion.
> 
> We were asked to make this call so as to unblock the srv6 document, and so
> we did.
> 
> I’m not sure how we officially document this. It *is* meant to be revisited
> after gaining some experience. The WG website seems like a good idea.
> 
> Thanks,
> Chris.
> 
> > On Apr 21, 2021, at 9:57 AM, Les Ginsberg (ginsberg)
>  wrote:
> >
> > Chris/Acee -
> >
> > Thanx for putting this proposal together.
> >
> > As I have previously stated, I prefer no registries at all for this case. 
> > But if
> we are to have registries, I much prefer Tony Li's proposal:
> >
> > 
> > When a potentially shared field is created, the defining document specifies
> the name of a future registry, but does NOT request IANA create the registry
> at this time. When any document wishes
> > to update the field, it requests that IANA create it and populate it with 
> > both
> legacy and updated values.
> > 
> >
> > The problem I have with your proposal is that it requires a degree of
> clairvoyance on the part of the original draft authors.
> > Tony's proposal avoids that.
> >
> > One other question - where/how will the final version of this guidance be
> documented?
> > Historically, an RFC gets written for such things - but I would hope there 
> > is a
> lighter weight solution. Is it possible to have a "WG Policy" which is
> documented somewhere on the WG website?
> >
> >   Les
> >
> >
> >> -Original Message-
> >> From: Lsr  On Behalf Of Christian Hopps
> >> Sent: Tuesday, April 20, 2021 5:24 PM
> >> To: lsr@ietf.org
> >> Cc: lsr-cha...@ietf.org; lsr-...@ietf.org
> >> Subject: [Lsr] Guidance for IANA flags field registry creation.
> >>
> >> LSR WG,
> >>
> >> After going through the various emails on whether and when to allocate
> >> an IANA registry for a flags field, the chairs do not believe we have a
> >> strong enough consensus to choose a policy as of yet; however, we feel
> >> we do have a rough consensus that would allow us to issue guidance.
> >> After some experience with the guidance, we could then choose to make
> it
> >> or some variation, the policy if that was still needed.
> >>
> >> Guidance on IANA registry creation for flags fields:
> >>
> >> - If a flags/bits field is intended for use by the defining document
> >>  only, and future expansion would be expected to take place in a
> >>  revision of said document (a "bis"), then no IANA registry creation
> >>  should be required.
> >>
> >> - Otherwise, there is some belief that secondary documents (ones that
> >>  would "update" rather than "replace" the defining base document) may
> >>  add flags to this field and, hence, an IANA registry should be created
> >>  by the defining document.
> >>
> >> - If one has trouble picking, look at other protocol encodings with
> >>  similar meanings (headers/[sub-]TLVs) to see how they have been
> >>  expanded historically. For example, if one is defining a Capabilities
> >>  TLV with a flags field, one could look at other Capability TLVs with
> >>  flags fields to see what has occurred there.
> >>
> >> - As it is better to have the registry identified in the base document
> >>  than elsewhere, one should err on the side of registry creation if
> >>  there is some doubt as to which to pick.
> >>
> >> Thanks,
> >> Acee and Chris.
> >
> > ___
> > 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] Guidance for IANA flags field registry creation.

[Les Ginsberg (ginsberg)]

Chris/Acee -

Thanx for putting this proposal together.

As I have previously stated, I prefer no registries at all for this case. But 
if we are to have registries, I much prefer Tony Li's proposal:


When a potentially shared field is created, the defining document specifies the 
name of a future registry, but does NOT request IANA create the registry at 
this time. When any document wishes
to update the field, it requests that IANA create it and populate it with both 
legacy and updated values.


The problem I have with your proposal is that it requires a degree of 
clairvoyance on the part of the original draft authors.
Tony's proposal avoids that.

One other question - where/how will the final version of this guidance be 
documented?
Historically, an RFC gets written for such things - but I would hope there is a 
lighter weight solution. Is it possible to have a "WG Policy" which is 
documented somewhere on the WG website?

   Les


> -Original Message-
> From: Lsr  On Behalf Of Christian Hopps
> Sent: Tuesday, April 20, 2021 5:24 PM
> To: lsr@ietf.org
> Cc: lsr-cha...@ietf.org; lsr-...@ietf.org
> Subject: [Lsr] Guidance for IANA flags field registry creation.
> 
> LSR WG,
> 
> After going through the various emails on whether and when to allocate
> an IANA registry for a flags field, the chairs do not believe we have a
> strong enough consensus to choose a policy as of yet; however, we feel
> we do have a rough consensus that would allow us to issue guidance.
> After some experience with the guidance, we could then choose to make it
> or some variation, the policy if that was still needed.
> 
> Guidance on IANA registry creation for flags fields:
> 
> - If a flags/bits field is intended for use by the defining document
>   only, and future expansion would be expected to take place in a
>   revision of said document (a "bis"), then no IANA registry creation
>   should be required.
> 
> - Otherwise, there is some belief that secondary documents (ones that
>   would "update" rather than "replace" the defining base document) may
>   add flags to this field and, hence, an IANA registry should be created
>   by the defining document.
> 
> - If one has trouble picking, look at other protocol encodings with
>   similar meanings (headers/[sub-]TLVs) to see how they have been
>   expanded historically. For example, if one is defining a Capabilities
>   TLV with a flags field, one could look at other Capability TLVs with
>   flags fields to see what has occurred there.
> 
> - As it is better to have the registry identified in the base document
>   than elsewhere, one should err on the side of registry creation if
>   there is some doubt as to which to pick.
> 
> Thanks,
> Acee and Chris.

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

Re: [Lsr] AD Review of draft-ietf-lsr-isis-srv6-extensions-11

[Les Ginsberg (ginsberg)]

Alvaro/Peter -

In regards to:

> ...
> > 906 12.5. Sub-Sub-TLVs for SID Sub-TLVs
> >
> > 908 This document requests a new IANA registry be created under the IS-IS
> > 909 TLV Codepoints Registry to control the assignment of sub-TLV types
> > 910 for the SID Sub-TLVs specified in this document - Section 7.2,
> > 911 Section 8.1, Section 8.2. The suggested name of the new registry is
> > 912 "Sub-Sub-TLVs for SID Sub-TLVs". The registration procedure is
> > 913 "Expert Review" as defined in [RFC8126]. The following assignments
> > 914 are made by this document:
> >
> > [minor] In line with the name of other registries; suggestion:
> > "Sub-sub-TLVs for sub-TLVs 5, 43 and 44 (SRv6 End SID , SRv6 End.X SID
> > and SRv6 LAN End.X SID)".
> >
> >
> > ##PP2
> > I find that confusing as the sub-TLVs 5 is a locator Sub-TLV, while
> > Sub-TLVs 43 and 44 are IS reachability sub-TLVs.
> > What about:
> >
> > "Sub-Sub-TLVs for SID Sub-TLVs (SRv6 End SID, SRv6 End.X SID
> > and SRv6 LAN End.X SID)"
> 
> Most of the other registries include the number of the TLV.  So I
> think it would be good to remain consistent.  Maybe we should ask the
> current DEs: Chris, Hannes and Les.
> 

I think this is an odd situation.
You have three new sub-TLVs:

SRv6 End SID sub-TLV(5) which is a sub-TLV of TLVs 27, 135, 235, 236 and 237 
(only allowed in TLV 27)

SRv6 End.X SID(43) and SRv6 LAN End.X SID(44) sub-TLVs which are sub-TLVs of 
TLVs 22, 23, 25, 141, 222 and 223 (allowed in all TLVs)

You propose to create a single registry common to all three of these sub-TLVs 
to share codepoints for sub-sub-TLVs. This is motivated by the one defined 
sub-sub-TLV SRv6 SID Structure Sub-Sub-TLV(1) which is applicable to all three 
new sub-TLVs.

Such a registry  (code points for sub-sub-TLVs associated with sub-TLVs in 
different parent TLVs) has not been defined before. Closest we have come is the 
"Sub-sub-TLV Codepoints for Application-Specific Link Attributes" which exists 
separately from " sub-TLVs of TLVs 22, 23, 25, 141, 222 and 223" but comes with 
the advisory:

"If a link attribute can be advertised both as a sub-TLV of TLVs
22, 23, 25, 141, 222, and 223 and as a sub-sub-TLV of the 
Application-Specific Link Attributes sub-TLV defined in 
[RFC8919], then the same numerical code
should be assigned to the link attribute whenever possible."

You could elect to do the same thing here i.e., create two new registries but 
include a Note saying codepoints in the two should be the same whenever it 
makes sense to do so.
Or, you could do something new and create a single registry even though the 
grandparent TLVs are different.

I don’t have a strong opinion here, but if it is anticipated that most of the 
sub-sub-TLVs would be shared then a single registry is easier to manage.

The name however becomes quite a mouthful - something like:

"sub-sub-TLVs for SRv6EndSID(5) (sub-TLV of TLVs 27, 135, 235, 236 and 237) and 
SRv6 End.X SID(43)/SRv6 LAN End.X SID(44) (sub-TLVs of TLVs 27, 135, 235, 236 
and 237)"

And you would need to create columns (analogous to the columns in existing 
registries which have multiple parent TLVs) to show in which parents a given 
sub-sub-TLV is allowed.

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

Re: [Lsr] When is an IANA Registry Required

[Les Ginsberg (ginsberg)]

Tony –

I hope I can be forgiven for one more post on this subject. In any case, here 
it is.

First, at the risk of some repetition, I want to emphasize that the reason I 
started this thread was to define a consistent policy. Currently we do not have 
registries for the flags fields in various TLVs. In recent document reviews, 
Alvaro strongly suggested that we introduce a registry for the flag field in 
the new TLV(s) which were being defined. I do not think the policy should be 
inconsistent in this regard, so I started this thread to get the WG to agree on 
what the policy will be across all such fields in all TLVs. Whatever the 
outcome of this discussion (i.e., to have such registries or to NOT have them), 
so long as there is a consistent policy, this thread will have served the 
purpose and I will be satisfied. (For those of you who may be fans of Ralph 
Waldo Emerson, I consider this to be NOT a “foolish consistency”.  )

Now, as regards the potential usefulness of such registries, I think this has 
nothing to do with “memory”.  I can assure you that I refer to the existing 
registries with great frequency and do not trust my memory on such things.

Registries exist today (and are very useful) for number spaces for which 
requests come from a large number of largely unrelated documents. So, for top 
level TLVs, almost every IS-IS related RFC which has been published defines one 
or more codepoints. Without a registry our ability to track what is currently 
allocated and what is available would be severely compromised. Similarly for 
sub-TLVs and the other registries under the TLV Codepoints umbrella. However, 
in regards to flags fields which are part of the fixed portion of a TLV format 
definition, tracking bit allocation has not been an issue – and I argue that it 
is best tracked in other ways which are already defined. To be specific:

If an additional flag bit for an existing  TLV is defined in the future, there 
are two possible ways of doing this:

1)A bis document is written. The new document then contains all normative 
content from the original document as well as the new content (in this example 
an additional flag bit). The new document is required to be marked as 
“obsoleting” the original version. Once the document is published, the original 
document is marked as “obsoleted by xxx” and the existing entry for the 
affected code point in 
https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml 
is marked to point to the new document.

2)A separate document is written focused only on the additions to the base 
definition for the TLV. The new document is required to be clearly marked as 
“updating” the original document. The original document is marked as “updated 
by new document”. In addition, the existing entry in 
https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml 
would be updated to point to both the original document and the new document.

This seems to me be fully functional and easy to use. Even if your memory on 
such matters is not fresh, by simply bookmarking 
https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml 
you will easily be able to find whatever information you need.

The addition of a separate registry for each flags field is then redundant at 
best. And redundancy in such matters introduces additional work and the 
possibility of unintentional inconsistency which I find hard to justify. Hence 
my conclusion that the value of such additional registries does not justify 
their creation.

You (and others) may still disagree. And I assure you that as my primary 
motivation for this thread was to have a consistent WG policy for such fields, 
I will abide by whatever policy is chosen by the WG even if it is not my 
preferred choice. But I do think the arguments being made for the creation of 
such registries bear closer scrutiny. Just my opinion of course…

Thanx (again) for listening.

   Les


From: Tony Li  On Behalf Of Tony Li
Sent: Thursday, March 18, 2021 8:24 AM
To: Les Ginsberg (ginsberg) 
Cc: Alvaro Retana ; 
draft-ietf-lsr-isis-srv6-extensi...@ietf.org; lsr@ietf.org; John Scudder 
; Christian Hopps ; lsr-cha...@ietf.org
Subject: Re: [Lsr] When is an IANA Registry Required


Les,



IMO, there is no need for registries for the first category. The WG has been 
alive for over 20 years, defined many new TLVs with flags fields, and I am not 
aware of any confusion – so if it ain’t broke don’t fix it.


With all due respect Les, you appear to operate with an eidetic memory of all 
things IS-IS, so I think that you discount the confusion that the rest of us 
live in.

If a field has values defined in two documents, then there’s confusion. Even 
just finding both is a challenge.

Regards,
Tony


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

Re: [Lsr] When is an IANA Registry Required

[Les Ginsberg (ginsberg)]

Tony –

In this context I don’t find the use of a registry of value. The primary issue 
for me for these fields is not managing the bit assignments but understanding 
the functionality – and for that I need to look at the document(s) which have 
that definition. A registry in these cases provides little value and adds 
process and a possibility for inconsistency.

But, I am not expecting that there is anything I can say to change your opinion 
– nor vice versa. So I appreciate that you have made your POV clear and the 
reasons for it – and I am not trying to change your opinion.

I started this thread because I did not think a change in WG policy should be 
made solely based on a single document review comment from one individual – 
even one as highly respected as Alvaro.
Thus far we have a handful of opinions – I am hoping more members of the WG 
will respond to the thread and then we can proceed appropriately.

   Les

From: Tony Li  On Behalf Of Tony Li
Sent: Thursday, March 18, 2021 8:24 AM
To: Les Ginsberg (ginsberg) 
Cc: Alvaro Retana ; 
draft-ietf-lsr-isis-srv6-extensi...@ietf.org; lsr@ietf.org; John Scudder 
; Christian Hopps ; lsr-cha...@ietf.org
Subject: Re: [Lsr] When is an IANA Registry Required


Les,



IMO, there is no need for registries for the first category. The WG has been 
alive for over 20 years, defined many new TLVs with flags fields, and I am not 
aware of any confusion – so if it ain’t broke don’t fix it.


With all due respect Les, you appear to operate with an eidetic memory of all 
things IS-IS, so I think that you discount the confusion that the rest of us 
live in.

If a field has values defined in two documents, then there’s confusion. Even 
just finding both is a challenge.

Regards,
Tony


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

Re: [Lsr] When is an IANA Registry Required

[Les Ginsberg (ginsberg)]

Tony –

IMO, there is no need for registries for the first category. The WG has been 
alive for over 20 years, defined many new TLVs with flags fields, and I am not 
aware of any confusion – so if it ain’t broke don’t fix it.

But, if the WG consensus turns out to be to create registries in such cases, so 
be it – though it raises the question of what to do about existing flags fields 
which don’t have a registry (all of them currently). But I guess your 
“registry-on-write” policy could be used to address that - meaning no need to 
backtrack – just create registries when any new flag definitions come along.

I will leave it to the WG chairs as to how to determine WG consensus. Just hope 
we don’t have to write an RFC to define the WG policy on this. 

Thanx.

   Les


From: Tony Li  On Behalf Of Tony Li
Sent: Wednesday, March 17, 2021 1:56 PM
To: Les Ginsberg (ginsberg) 
Cc: Alvaro Retana ; 
draft-ietf-lsr-isis-srv6-extensi...@ietf.org; lsr@ietf.org; John Scudder 
; Christian Hopps ; lsr-cha...@ietf.org
Subject: Re: [Lsr] When is an IANA Registry Required


Les,


[Les:] The question here is whether there is a qualitative difference between 
two classes of bit fields.


That is indeed the key question. IMHO, there is not.

I don’t much care if a field is updated by a bis document or a related 
document. Regardless of the cause, as soon as there is more than one source of 
truth about the field, we are
creating ambiguity and confusion.

At the same time, I see no point in a registry with contents that never change. 
Thus, I will propose an alternative: by analogy to copy-on-write shared memory 
semantics, I propose that
we apply ‘registry-on-write’ semantics.

Specifics: When a potentially shared field is created, the defining document 
speciifies the name of a future registry, but does NOT request IANA create the 
registry at this time. When any document wishes
to update the field, it requests that IANA create it and populate it with both 
legacy and updated values.

Implementors that come along either document know where the source of truth is. 
 If the registry has not been created, then there is no ambiguity. If it has 
been, then there is no ambiguity.

Thoughts?

Tony

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

Re: [Lsr] When is an IANA Registry Required

[Les Ginsberg (ginsberg)]

Tony -

> -Original Message-
> From: Tony Li  On Behalf Of Tony Li
> Sent: Wednesday, March 17, 2021 11:37 AM
> To: Alvaro Retana 
> Cc: Les Ginsberg (ginsberg) ; draft-ietf-lsr-isis-srv6-
> extensi...@ietf.org; lsr@ietf.org; John Scudder ;
> Christian Hopps ; lsr-cha...@ietf.org
> Subject: Re: [Lsr] When is an IANA Registry Required
> 
> 
> 
> > I don't know that you and I are getting anywhere.  I know Robert also
> > cares about this topic, I hope others do too.
> 
> 
> I care.
> 
> It seems to me that we have registries where we have different documents
> allocating values from the same space. This makes sense: we need to
> coordinate things.
> 
> IMHO, whether that space is a set of bit values, octets, shorts, longs, or
> strings doesn’t matter at all.
> 
> It should be tracked and coordinated so that we don’t have collisions. Shared
> namespaces are fine, but anything shared needs to be managed.
> 
[Les:] The question here is whether there is a qualitative difference between 
two classes of bit fields.

Category 1 
Flags field in TLVs/sub-TLVs  used for a specific purpose. Addition of new 
flags to these TLVs would be defined either in a bis draft or a draft which 
updates the corresponding base draft.
Currently we do not have registries for these cases.

A few examples (there are many more):
1)Flags field in TLV 236 (RFC 5308)
2)Flags field in Prefix Segment Identifier (Prefix-SID) Sub-TLV ( 
https://www.rfc-editor.org/rfc/rfc8667.html#section-2.1 )
3)Flags field in SRv6 Locator TLV ( 
https://tools.ietf.org/html/draft-ietf-lsr-isis-srv6-extensions-11#section-7.1 )

Category 2

Flag fields available for use by a variety of unrelated applications.  There 
are currently two existing examples - both of which have registries.

 
https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#prefix-attribute-flags

 
https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-19of22

As you can see from the current assignments, in both cases bit definitions 
occur in the context of drafts which are otherwise unrelated.

The question here is whether bit registries are also appropriate for category 1.

If you could clarify your opinion to speak to this more specific question that 
would be helpful - at least to me.

Thanx.

   Les


> Tony

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

Re: [Lsr] When is an IANA Registry Required

[Les Ginsberg (ginsberg)]

Alvaro -

Inline.

> -Original Message-
> From: Alvaro Retana 
> Sent: Wednesday, March 17, 2021 7:04 AM
> To: Les Ginsberg (ginsberg) ; draft-ietf-lsr-isis-srv6-
> extensi...@ietf.org
> Cc: John Scudder ; lsr-cha...@ietf.org; lsr@ietf.org;
> Christian Hopps 
> Subject: RE: When is an IANA Registry Required
> 
> On March 16, 2021 at 6:24:22 PM, Les Ginsberg wrote:
> 
> 
> Les:
> 
> Hi!
> 
> 
> > But one thing I find missing in your response is some info on what problem
> > YOU think needs to be addressed?
> 
> 
> I simply think that the specifications are not complete without
> guidance on how to use/assign the unused bits.  I rather try to close
> that door before a potential problem may come up.
> 
[Les:] Specifications typically say:

"Remaining bits are RESERVED. SHOULD/MUST be transmitted as 0 and MUST be 
ignored on receipt."

And the same wording is used for bits covered by a registry.
Consider https://www.rfc-editor.org/rfc/rfc7794.html#section-2.1 (for which we 
do have a registry):

"Undefined bits MUST be transmitted as 0 and MUST be ignored on
   receipt."

> In the extreme case anyone can make use of the bits, through the ISE
> or a different SDO -- ideally we will be paying attention, but may
> not.  Sure, a registry doesn't stop implementations from squatting on
> codepoints either (even inside the IETF), but at least people have to
> want to bypass the allocation rules.
> 

[Les:] When a specification says "all other bits are reserved, MUST be sent as 
0 and MUST be ignored on receipt", I do not see how anyone can assume they can 
use them - nor why the existence of a  registry would prevent such a squatter 
from doing whatever they want outside of normal channels.
Are you suggesting that normative statements in RFCs simply don’t mean anything?

Sorry, don’t mean to be argumentative. Just expressing why I am not 
understanding/agreeing w your POV.

   Les

> My 1c.
> 
> Alvaro.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] When is an IANA Registry Required

[Les Ginsberg (ginsberg)]

Robert –

My experience with Wireshark does not match yours.

In my experience, packet decoders aren’t always up on the latest spec revisions 
– it is always a catchup game – but it isn’t true that only values from an IANA 
registry are displayed.
And from an implementation standpoint, the engineer writing the decoder always 
has to look at the draft/RFC. An IANA Registry does not provide the format of 
the fixed fields (e.g., prefix, metric) – so I have a hard time agreeing with 
your perception that implementors only look at IANA registries.
I actually think it is the other way round – they look at drafts/RFCs and only 
look at registries when the document points to them. 

Les


From: Robert Raszuk 
Sent: Tuesday, March 16, 2021 4:46 PM
To: Les Ginsberg (ginsberg) 
Cc: Alvaro Retana ; lsr@ietf.org; Christian Hopps 

Subject: Re: [Lsr] When is an IANA Registry Required

Hi Les,

I would like to share my personal experience that when debugging network issues 
say using wireshark or tcpdump often dissectors only decode what is in IANA 
registry. Anything beyond they print as hex.

Sure if someone needs to decode it he or she will find an RFC where all fields 
are described. But this usually requires manual labor we as lazy humans are not 
always best at.

So just from pure convenience (while I do understand heavy labor to move all 
flags to IANA) there is some operational value I could see doing it.

Best,
Robert.


On Tue, Mar 16, 2021 at 11:24 PM Les Ginsberg (ginsberg) 
mailto:40cisco@dmarc.ietf.org>> wrote:

Alvaro -



Thanx - as always - for the thoughtful response.



I would like to state up front that I would never consider you to be a "casual 
reader". 



I am also glad you are opening this topic up to comments from others - that was 
my intent as well.



But one thing I find missing in your response is some info on what problem YOU 
think needs to be addressed?

Do you think there have already been cases where assignment of the bits in the 
flags field associated w a prefix or a neighbor or other object comparable to 
the new TLVs defined in draft-ietf-lsr-isis-srv6-extensions (e.g., Locator) has 
become confusing due to the lack of a registry?

I'd like to think you are motivated by more than a theoretical concern but have 
at least one example based on your many years of experience working on 
protocols.

Such an example would help me understand your motivation better and might even 
convince me that this is a good idea.



Thanx.



   Les







> -Original Message-

> From: Alvaro Retana mailto:aretana.i...@gmail.com>>

> Sent: Tuesday, March 16, 2021 12:39 PM

> To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; 
> draft-ietf-lsr-isis-srv6-

> extensi...@ietf.org<mailto:extensi...@ietf.org>

> Cc: John Scudder mailto:j...@juniper.net>>; 
> lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>; 
> lsr@ietf.org<mailto:lsr@ietf.org>;

> Christian Hopps mailto:cho...@chopps.org>>

> Subject: Re: When is an IANA Registry Required

>

> On February 27, 2021 at 12:57:12 PM, Les Ginsberg wrote:

>

>

> Les:

>

> Hi!

>

> Sorry for the delay...

>

> §4/rfc8126 presents some general arguments for creating registries.

> But let's talk about this specific case.

>

>

> I'm taking the liberty of summarizing your message this way:

>

> > Historically, we have created IANA registries for identifiers which are

> > likely to be needed by a variety of unrelated features supported by the

> > protocol. The expectation in these cases is that multiple documents -

> > largely unrelated to each other - might need to allocate an ID from the

> same

> > space.

> ...

> > What we have NOT done, historically, is create a registry for a flags field

> > which is not provided as a general purpose mechanism, but is specifically

> > scoped for use only within the context of the feature which defined the

> > TLV/sub-TLV. (There are many examples.)

> >

> > It is expected in these cases that if an additional flag is required, that

> > it will be defined in a document directly related to the original feature –

> > either a bis version of the original document or a new document which is

> > marked specifically as an update to the original document.

>

>

> In general, the expectations about the future use of a specific field

> (as you describe them) are not always obvious to the casual reader[*].

> If the intent was clear, and the expectation ("bis...an update") is

> spelled out in the document then I would not ask about the management

> of the bits.  And even better, future specifications (when maybe none

> of us are around anymore) would have clear guidance.

>

> Having said that, and knowing that I am not the 

Re: [Lsr] When is an IANA Registry Required

[Les Ginsberg (ginsberg)]

Alvaro -



Thanx - as always - for the thoughtful response.



I would like to state up front that I would never consider you to be a "casual 
reader". 



I am also glad you are opening this topic up to comments from others - that was 
my intent as well.



But one thing I find missing in your response is some info on what problem YOU 
think needs to be addressed?

Do you think there have already been cases where assignment of the bits in the 
flags field associated w a prefix or a neighbor or other object comparable to 
the new TLVs defined in draft-ietf-lsr-isis-srv6-extensions (e.g., Locator) has 
become confusing due to the lack of a registry?

I'd like to think you are motivated by more than a theoretical concern but have 
at least one example based on your many years of experience working on 
protocols.

Such an example would help me understand your motivation better and might even 
convince me that this is a good idea.



Thanx.



   Les







> -Original Message-

> From: Alvaro Retana 

> Sent: Tuesday, March 16, 2021 12:39 PM

> To: Les Ginsberg (ginsberg) ; draft-ietf-lsr-isis-srv6-

> extensi...@ietf.org

> Cc: John Scudder ; lsr-cha...@ietf.org; lsr@ietf.org;

> Christian Hopps 

> Subject: Re: When is an IANA Registry Required

>

> On February 27, 2021 at 12:57:12 PM, Les Ginsberg wrote:

>

>

> Les:

>

> Hi!

>

> Sorry for the delay...

>

> §4/rfc8126 presents some general arguments for creating registries.

> But let's talk about this specific case.

>

>

> I'm taking the liberty of summarizing your message this way:

>

> > Historically, we have created IANA registries for identifiers which are

> > likely to be needed by a variety of unrelated features supported by the

> > protocol. The expectation in these cases is that multiple documents -

> > largely unrelated to each other - might need to allocate an ID from the

> same

> > space.

> ...

> > What we have NOT done, historically, is create a registry for a flags field

> > which is not provided as a general purpose mechanism, but is specifically

> > scoped for use only within the context of the feature which defined the

> > TLV/sub-TLV. (There are many examples.)

> >

> > It is expected in these cases that if an additional flag is required, that

> > it will be defined in a document directly related to the original feature –

> > either a bis version of the original document or a new document which is

> > marked specifically as an update to the original document.

>

>

> In general, the expectations about the future use of a specific field

> (as you describe them) are not always obvious to the casual reader[*].

> If the intent was clear, and the expectation ("bis...an update") is

> spelled out in the document then I would not ask about the management

> of the bits.  And even better, future specifications (when maybe none

> of us are around anymore) would have clear guidance.

>

> Having said that, and knowing that I am not the responsible AD for lsr

> anymore, I would be very happy if the WG decided on requiring future

> documents to be clear about the intended use and any requirements for

> the allocation of flags or other unassigned bits.

>

>

> Thanks for starting this discussion!  I hope to see other opinions.

>

> Alvaro.

>

> [*] Anyone else besides maybe the authors themselves, including me.

>

>

>

> > Alvaro -

> >

> > In your review of draft-ietf-lsr-isis-srv6-extensions you requested the

> > authors to

> >

> > "Please ask IANA to set up a registry for the Flags."

> >

> > in multiple cases e.g., the flags field defined in the new SRv6 Capabilities

> > sub-TLV.

> >

> > This isn't the first time you have made such a request (I believe I argued

> > against this in the past and you relented – but only temporarily it seems.

> 

> > ).

> >

> > As it is a deviation from historical practice, I think it would be better if

> > the WG discussed whether there is a good reason to change our practices

> > rather than have this request be made based on the personal preference

> of the

> > current AD.

> >

> > Historically, we have created IANA registries for identifiers which are

> > likely to be needed by a variety of unrelated features supported by the

> > protocol. The expectation in these cases is that multiple documents -

> largely

> > unrelated to each other - might need to allocate an ID from the same

> space.

> >

> > Obvious examples are TLV/sub-TLV code points.

> >

> > In the case of flags, there are currently only two such registries

Re: [Lsr] I-D Action: draft-ietf-lsr-isis-rfc5316bis-02.txt

[Les Ginsberg (ginsberg)]

Folks -

This revision addresses comments from Dhruv, Alvaro, Donald, and Acee.
Thanx to all for their careful review.

   Les


> -Original Message-
> From: Lsr  On Behalf Of internet-dra...@ietf.org
> Sent: Wednesday, March 10, 2021 7:57 AM
> To: i-d-annou...@ietf.org
> Cc: lsr@ietf.org
> Subject: [Lsr] I-D Action: draft-ietf-lsr-isis-rfc5316bis-02.txt
> 
> 
> 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   : IS-IS Extensions in Support of Inter-Autonomous 
> System (AS)
> MPLS and GMPLS Traffic Engineering
> Authors : Mach(Guoyi) Chen
>   Les Ginsberg
>   Stefano Previdi
>   Xiaodong Duan
>   Filename: draft-ietf-lsr-isis-rfc5316bis-02.txt
>   Pages   : 21
>   Date: 2021-03-10
> 
> Abstract:
>This document describes extensions to the Intermediate System to
>Intermediate System (IS-IS) protocol to support Multiprotocol Label
>Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering
>(TE) for multiple Autonomous Systems (ASs).  It defines IS-IS
>extensions for the flooding of TE information about inter-AS links,
>which can be used to perform inter-AS TE path computation.
> 
>No support for flooding information from within one AS to another AS
>is proposed or defined in this document.
> 
>This document obsoletes RFC 5316.
> 
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-rfc5316bis/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-lsr-isis-rfc5316bis-02
> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-rfc5316bis-02
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-isis-rfc5316bis-02
> 
> 
> 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 mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] New Version Notification for draft-wang-lsr-isis-mfi-00.txt

[Les Ginsberg (ginsberg)]

Sooo, I have been reluctant to comment on the shortcomings of this draft 
because I feel there was no need for the draft to be written in the first place.
I had hoped that the authors would think about this a bit more and realize the 
flaws in the proposed solution – or – as Acee suggested during the WG meeting – 
they would attempt an implementation and discover what had not yet been 
realized. This then would end the time the WG is spending on this – which IMO 
is the right outcome.

As that has not yet happened, perhaps some comments can speed this process 
along.

The goal of the draft is to support per-MFI LSDBs in the standard instance of 
IS-IS.  Since it is not possible for a legacy node to differentiate LSP.xx-yy w 
MFI #1 from the same LSP with MFI #2 (or with no MFI at all), it is clear that 
an MFI LSP cannot be flooded to a legacy node EVER!!
In order to prevent this, a node has to know whether a given neighbor supports 
MFI or not. But since the draft defines no signaling in hellos, it cannot tell 
whether the neighbor supports MFI (not to mention which MFIs – which is 
important for avoiding flooding MFI LSPs to nodes that aren’t interested in 
that MFI) you are forced to rely on receiving LSPs (or SNPs) – which brings us 
to the chicken/egg problem. Neither I nor my neighbor can send an MFI LSP out 
of fear that the receiver does not support MFI. So MFI flooding is blocked.

This problem can be solved by including the MFI TLV in hellos (analogous to 
what MI(RFRC 8202) does). But this is not the end of your issues. If you have a 
LAN, you could have a mix of legacy routers and MFI routers – and again you 
cannot allow legacy routers to receive MFI LSPs as they will look just like 
legacy LSPs to the legacy nodes. This means you will have to find a way to 
avoid ever having MFI PDUs received by legacy nodes (RFC 8202 uses different 
MAC multicast addresses).

Sooo, once you have addressed both of these issues you will have repeated what 
RFC 8202 already does. No new benefits here.

This then leaves you with one possible use case: support a single LSDB for all 
MFIs in the standard IS-IS instance. But, this use case is already provided for 
(though strongly discouraged) by https://tools.ietf.org/html/rfc6823#section-5 .

I do understand that some folks want to advertise VTN info in IGPs and that the 
WG will be discussing this. I am not in favor of doing this – but I recognize 
it is a legitimate topic for discussion. And if the WG were to approve such 
functionality we have MI available to be used to provide separation.
(Note that MI has been implemented and successfully deployed by multiple 
vendors.)

draft-wang-lsr-isis-mfi is an unnecessary proposal, seriously flawed, and not 
achieving any of the goals stated in its introduction.
I ask that the authors abandon this proposal.

   Les


From: Lsr  On Behalf Of Gyan Mishra
Sent: Friday, March 05, 2021 8:11 AM
To: Peter Psenak (ppsenak) 
Cc: Robert Raszuk ; Huzhibo ; Aijun Wang 
; Tony Li ; lsr ; 
Tianran Zhou ; wangyali 
Subject: Re: [Lsr] New Version Notification for draft-wang-lsr-isis-mfi-00.txt

Hi Peter

On Fri, Mar 5, 2021 at 10:56 AM Peter Psenak 
mailto:ppse...@cisco.com>> wrote:
Gyan,

On 05/03/2021 16:46, Gyan Mishra wrote:
> Yali
>
> I agree with a Peter.
>
> As for resource isolation and provisioning of a VTN I think you really
> need separate LSDB instances provided by MT or MI as better suited for
> network slicing.

MT does not provide LSDB separation, only MI does.

thanks,
Peter

   I thought that each MT topology was a separate RIB meaning separate LSDB.  
The RFC is confusing.

https://tools.ietf.org/html/rfc5120

6.  MT SPF Computation





   Each MT MUST run its own instance of the decision process.  The

   pseudo-node LSPs are used by all topologies during computation.  Each

   non-default topology MAY have its attached bit and overload bit set

   in the MT TLV.  A reverse-connectivity check within SPF MUST follow

   the according MT to assure the bi-directional reachability within the

   same MT.



   The results of each computation SHOULD be stored in a separate

   Routing Information Base (RIB), in normal cases, otherwise

   overlapping addresses in different topologies could lead to

   undesirable routing behavior, such as forwarding loops.  The

   forwarding logic and configuration need to ensure the same MT is

   traversed from the source to the destination for packets.  The

   nexthops derived from the MT SPF MUST belong to the adjacencies



conforming to the same MT for correct forwarding.  It is recommended

   for the administrators to ensure consistent configuration of all

   routers in the domain to prevent undesirable forwarding behavior.



   No attempt is made in this document to allow one topology to

   calculate routes using the routing information from another topology

   inside SPF.  Even though it is possible to redistribute and 

Re: [Lsr] [Teas] WG Last Call for draft-ietf-lsr-isis-rfc5316bis

[Les Ginsberg (ginsberg)]

Alvaro -

Thanx for the clarification.
I will address this in the next revision.

   Les


> -Original Message-
> From: Alvaro Retana 
> Sent: Thursday, March 04, 2021 9:10 AM
> To: Les Ginsberg (ginsberg) ; Christian Hopps
> ; Dhruv Dhody 
> Cc: TEAS WG Chairs ; lsr-...@ietf.org; TEAS WG
> (t...@ietf.org) ; lsr-cha...@ietf.org; lsr@ietf.org; teas-
> a...@ietf.org
> Subject: RE: [Lsr] [Teas] WG Last Call for draft-ietf-lsr-isis-rfc5316bis
> 
> On March 3, 2021 at 6:29:28 PM, Les Ginsberg wrote:
> 
> 
> Les:
> 
> Hi!
> 
> 
> ...
> > Now, can you respond to my comment regarding the lack of clarity in using
> > quotes?
> 
> Sure.
> 
> I guess you mean this comment: "But I have to say that for me as a
> reader the use of quotes as you suggest does not aid clarity."
> 
> 
> Dhruv's comment was about using normative language in the appendix:
> 
> > > (1) Is it wise to use normative keywords MUST and SHOULD in the
> appendix?
> > > The text is from section 3.1 but can it be reworded in the appendix?
> 
> He is absolutely correct in suggesting that the appendix could use
> different words.  As I mentioned before, the appendix is just an
> informative section, a good/nice-to-have explanation for the reader.
> That means that it doesn't have to be an exact transcription of the
> text (which you didn't have to start with), and it can simply be an
> explanation.
> 
> The way I see it, using normative language in an informational
> appendix is what makes the text lack clarity -- the quotes were meant
> to help a little without asking you to make too many changes.  That
> way it would at least be clear that the specification is made
> elsewhere.
> 
> I know we may never agree on which direction to look at clarity.  We
> have already spent too much time on this.
> 
> Alvaro.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03

[Les Ginsberg (ginsberg)]

Chongfeng –

Just to clarify my position…

IMO there is no substantive content in this draft that warrants it becoming an 
RFC – Informational track or otherwise. It is simply a set of pointers to other 
documents/registries.

If the authors find the content in some way helpful, I think the more suitable 
path for you is to publish a white paper and post it on whatever web site seems 
appropriate to you.
I just do not see any content in the draft that warrants a standards body like 
IETF producing a new document.

Thanx.

   Les


From: Chongfeng Xie 
Sent: Thursday, March 04, 2021 5:04 AM
To: Les Ginsberg (ginsberg) ; Acee Lindem (acee) 
; lsr@ietf.org
Subject: Re: Re: [Lsr]WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for 
Segment Routing based Virtual Transport Network” - 
draft-xie-lsr-isis-sr-vtn-mt-03


Hi， Les,

Thanks for the review of this document.

As the current document type is informational, it does not introduce new TLV to 
IS-IS. While it describes the mechanisms of using existing TLVs to distribute 
the information of SR based VTNs, which can have customized topology and a set 
of dedicated network resources. It also describes the forwarding behaviors 
based on the SIDs and the resources allocated to each VTN.

IS-IS MT as defined in RFC 5120 provides the mechanisms to build multiple 
logical topologies and perform independent path computation for each topology. 
RFC 5120 mentions that the TE attributes TLVs can be inherited by the MT TLVs 
“if traffic engineering or some other applications are being applied per 
topology level later”. While it does not specify what the topology-specific TE 
attributes mean, and how traffic in different topologies are forwarded on a 
shared outgoing interface. These are described in section 3 and section 4 of 
this document.

RFC8667 and draft-ietf-lsr-isis-srv6-extensions defines the encoding of SR 
SIDs/SRv6 Locators in IS-IS, while the usage of the topology-specific SIDs and 
Locators are not specified, especially when the SIDs are associated with 
different set of network resources.

Section 5 gives the analysis about the scalability of this mechanism, and talks 
about a case where two VTNs have the same logical topology, but with different 
set of resources.

IMO the value of this document is that it provides an option to build SR VTNs 
with no IS-IS protocol extensions, which could be useful for some network 
scenarios.

Best regards,
Chongfeng


chongfeng@foxmail.com<mailto:chongfeng@foxmail.com>

发件人： Les Ginsberg \(ginsberg\)<mailto:ginsberg=40cisco@dmarc.ietf.org>
发送时间： 2021-03-04 11:52
收件人： Acee Lindem (acee)<mailto:acee=40cisco@dmarc.ietf.org>; 
lsr@ietf.org<mailto:lsr@ietf.org>
主题： Re: [Lsr]WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment 
Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03
I oppose WG adoption for this draft.

I note that the authors – following significant comments received on V0 - have 
removed much of the material that was considered confusing and/or inappropriate 
– notably discussion of L2 bundle link members.
I also note the draft has moved from Standards track to Informational track.

Let’s consider what content remains (ignoring boilerplate sections):

Section 2 notes that MT TLVs (RFC 5120) can support:
   o Topology specific SR-MPLS SIDs (defined in RFC 8667)
   o Topology specific SRv6 Locators and SIDs (defined in 
draft-ietf-lsr-isis-srv6-extensions)

Section 3 notes that MT TLVs can also support link attribute advertisements 
(defined in RFC 5305 and RFC 8570)

Also note that the IANA registries:

https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-22-23-25-141-222-223
 and
https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-135-235-236-237

also clearly document what is discussed in Sections 2 and 3.

Section 4 notes that topology specific forwarding entries can be installed in 
the forwarding plane based on topology specific routing calculations – 
something which was discussed in RFC 5120.

Section 5 notes that two different MTIDs could operate on the same physical 
topology - something clearly discussed in RFC 5120.

All of this adds nothing new to our understanding of the protocol. The only 
“new” content is the statement that VTNs could map to MTIDs.
But the substance of VTN and how it might be used is better discussed in a 
number of other drafts including:

   draft-ietf-spring-sr-for-enhanced-vpn
   draft-ietf-teas-enhanced-vpn
   draft-dong-lsr-sr-enhanced-vpn

The last draft is most notable because it proposes new IGP protocol encodings 
in support of VTN. Whether the encodings in that draft are accepted as 
currently defined or evolve to something different – it would be the 
authoritative draft on VTN IGP extensions.

The end result is that there is no meaningful content in 
draft-xie-

Re: [Lsr] [Teas] WG Last Call for draft-ietf-lsr-isis-rfc5316bis

[Les Ginsberg (ginsberg)]

Dhruv –


This gives an impression (to me) that *all* changes made are listed here. Since 
that is not what is happening here, I suggested calling it - Important or Major 
or Motivation to update RFC 5316, whatever you like


Got it.
I will make that clear in the next revision.

Thanx.

   Les

From: Dhruv Dhody 
Sent: Wednesday, March 03, 2021 10:34 PM
To: Les Ginsberg (ginsberg) 
Cc: Christian Hopps ; TEAS WG Chairs ; 
teas-...@ietf.org; TEAS WG (t...@ietf.org) ; 
lsr-cha...@ietf.org; lsr@ietf.org; lsr-...@ietf.org
Subject: Re: [Lsr] [Teas] WG Last Call for draft-ietf-lsr-isis-rfc5316bis

Hi Les,
On Thu, Mar 4, 2021 at 1:17 AM Les Ginsberg (ginsberg) 
mailto:ginsb...@cisco.com>> wrote:

Dhruv -



Thanx for reviewing/supporting the draft.

Please see inline.



> -Original Message-

> From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
> Dhruv Dhody

> Sent: Wednesday, March 03, 2021 2:09 AM

> To: Christian Hopps mailto:cho...@chopps.org>>

> Cc: TEAS WG Chairs mailto:teas-cha...@ietf.org>>; 
> teas-...@ietf.org<mailto:teas-...@ietf.org>; TEAS WG

> (t...@ietf.org<mailto:t...@ietf.org>) mailto:t...@ietf.org>>; 
> lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>; 
> lsr@ietf.org<mailto:lsr@ietf.org>; lsr-

> a...@ietf.org<mailto:a...@ietf.org>

> Subject: Re: [Lsr] [Teas] WG Last Call for draft-ietf-lsr-isis-rfc5316bis

>

> Hi,

>

> I went through the diff with RFC5316. The changes look good. Some

> minor comments -

>

> (1) Is it wise to use normative keywords MUST and SHOULD in the

> appendix? The text is from section 3.1 but can it be reworded in the

> appendix? Also wondering if other changes (IANA, nits) could be listed

> or we could call it "major change" :)



[Les:] I personally do not have an issue using the normative keywords in the 
Appendix. Not doing so I think might trigger someone to ask if there is some 
inconsistency between the Appendix text and the text in the body of the draft. 

If you know of some prohibition against using such keywords in an Appendix 
please provide the reference.


[Dhruv]: To me, the usefulness of this appendix is to find out what has changed 
in this bis. Very useful for any reviewer or implementor. The other option is 
to do rfcdiff :(

So in this context, I provided the above comments suggesting rewording the text 
as a list of changes with rewording. Adding a reference to the relevant section 
could be useful too. Feel free to ignore, if you think this adds no value!

The IANA change is a consequence of the introduction pf new  IPv6 Local ASBR 
identifier sub-TLV. I do not see the need to mention it in the Appendix.



I do not understand your comment about "major change". Could you explain?
[Dhruv]: The current text says -

Appendix A.  Changes to RFC 5316

   This document makes the following changes to RFC 5316.


This gives an impression (to me) that *all* changes made are listed here. Since 
that is not what is happening here, I suggested calling it - Important or Major 
or Motivation to update RFC 5316, whatever you like




>

> (2) IPv6 Local ASBR ID and IPv6 Router ID is used interchangeably i.e.

> table in IANA section 6.2 does not use the same name as the table in

> section 3.1

>



[Les:] The use of " IPv6 Router ID" in Section 3.1 is inconsistent. I will fix 
that.

Thanx for pointing that out.



Thanks!
Dhruv


   Les



> Hope this helps!

>

> Thanks!

>

> Dhruv

>

>

>

> On Wed, Feb 17, 2021 at 9:00 PM Christian Hopps 
> mailto:cho...@chopps.org>>

> wrote:

> >

> > Hi LSR and TEAS,

> >

> > This begins a joint WG last call for:

> >

> >   https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-rfc5316bis/

> >

> > Please discuss any issues on the LSR mailing list. The WGLC will end March

> 3, 2021.

> >

> > Authors, please indicate wether you are aware of any IPR related to this

> document to the list.

> >

> > Thanks,

> > Chris, Acee, (Lou and Pavan).

> > ___

> > Teas mailing list

> > t...@ietf.org<mailto:t...@ietf.org>

> > https://www.ietf.org/mailman/listinfo/teas

>

> ___

> Lsr mailing list

> Lsr@ietf.org<mailto: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] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03

[Les Ginsberg (ginsberg)]

I oppose WG adoption for this draft.

I note that the authors – following significant comments received on V0 - have 
removed much of the material that was considered confusing and/or inappropriate 
– notably discussion of L2 bundle link members.
I also note the draft has moved from Standards track to Informational track.

Let’s consider what content remains (ignoring boilerplate sections):

Section 2 notes that MT TLVs (RFC 5120) can support:
   o Topology specific SR-MPLS SIDs (defined in RFC 8667)
   o Topology specific SRv6 Locators and SIDs (defined in 
draft-ietf-lsr-isis-srv6-extensions)

Section 3 notes that MT TLVs can also support link attribute advertisements 
(defined in RFC 5305 and RFC 8570)

Also note that the IANA registries:

https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-22-23-25-141-222-223
 and
https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-135-235-236-237

also clearly document what is discussed in Sections 2 and 3.

Section 4 notes that topology specific forwarding entries can be installed in 
the forwarding plane based on topology specific routing calculations – 
something which was discussed in RFC 5120.

Section 5 notes that two different MTIDs could operate on the same physical 
topology - something clearly discussed in RFC 5120.

All of this adds nothing new to our understanding of the protocol. The only 
“new” content is the statement that VTNs could map to MTIDs.
But the substance of VTN and how it might be used is better discussed in a 
number of other drafts including:

   draft-ietf-spring-sr-for-enhanced-vpn
   draft-ietf-teas-enhanced-vpn
   draft-dong-lsr-sr-enhanced-vpn

The last draft is most notable because it proposes new IGP protocol encodings 
in support of VTN. Whether the encodings in that draft are accepted as 
currently defined or evolve to something different – it would be the 
authoritative draft on VTN IGP extensions.

The end result is that there is no meaningful content in 
draft-xie-lsr-isis-sr-vtn-mt. What it states is either already stated in 
existing RFCs or will be stated authoritatively in whatever 
draft-dong-lsr-sr-enhanced-vpn  evolves to (if indeed this work on VTNs is 
adopted by the WG).

Let’s please not waste WG time on this draft.

   Les


From: Lsr  On Behalf Of Acee Lindem (acee)
Sent: Tuesday, March 02, 2021 3:28 PM
To: lsr@ietf.org
Subject: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for 
Segment Routing based Virtual Transport Network” - 
draft-xie-lsr-isis-sr-vtn-mt-03

This information draft describes how MT could be used for VTN segmentation. The 
authors have asked for WG adoption.

This begins a three week LSR Working Group Adoption Poll for “Using IS-IS 
Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - 
draft-xie-lsr-isis-sr-vtn-mt-03. I’m giving it three weeks due to the IETF next 
week. Please register your support or objection on this list prior to the end 
of the adoption poll on 3/24/2020.

Thanks,
Acee


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

Re: [Lsr] [Teas] WG Last Call for draft-ietf-lsr-isis-rfc5316bis

[Les Ginsberg (ginsberg)]

Alvaro –

Your comment was to put quotes:


I would recommend using quotes in the appendix:

OLD>
   1.  The Router ID SHOULD be identical to the value advertised in the
   Traffic Engineering Router ID TLV (134) if available.

NEW>
   1.  The "Router ID SHOULD be identical" to the value advertised in the
   Traffic Engineering Router ID TLV (134) if available (Section 3.1).




My response was:


[Les:] So I am willing to make the change. But I have to say that for me as a 
reader the use of quotes as you suggest does not aid clarity.
I have no idea why the entire sentence should not be quoted as without the 
unquoted portion of the sentence the meaning of the quoted part is incomplete.


Now you point out that the body of the text says “[RFC5305]” whereas the 
appendix says “TLV 134”.
Fine – I can make them consistent.
Now, can you respond to my comment regarding the lack of clarity in using 
quotes?

Thanx.

   Les


From: Alvaro Retana 
Sent: Wednesday, March 03, 2021 1:09 PM
To: Les Ginsberg (ginsberg) ; Dhruv Dhody 
; Christian Hopps 
Cc: TEAS WG Chairs ; lsr-...@ietf.org; teas-...@ietf.org; 
lsr-cha...@ietf.org; lsr@ietf.org; TEAS WG (t...@ietf.org) 
Subject: RE: [Lsr] [Teas] WG Last Call for draft-ietf-lsr-isis-rfc5316bis

Les:

The text is not the same:

§3.1 reads: "The Router ID SHOULD be identical to the value advertised in the 
Traffic Engineering Router ID TLV [RFC5305].”

I’m sure you’ll do the right thing.

Thanks!

Alvaro.


On March 3, 2021 at 3:54:42 PM, Les Ginsberg (ginsberg) 
(ginsb...@cisco.com<mailto:ginsb...@cisco.com>) wrote:
> OLD>
>1.  The Router ID SHOULD be identical to the value advertised in the
>Traffic Engineering Router ID TLV (134) if available.
>
> NEW>
>1.  The "Router ID SHOULD be identical" to the value advertised in the
>Traffic Engineering Router ID TLV (134) if available (Section 3.1).
>

[Les:] So I am willing to make the change. But I have to say that for me as a 
reader the use of quotes as you suggest does not aid clarity.
I have no idea why the entire sentence should not be quoted as without the 
unquoted portion of the sentence the meaning of the quoted part is incomplete.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] [Teas] WG Last Call for draft-ietf-lsr-isis-rfc5316bis

[Les Ginsberg (ginsberg)]

Alvaro -

Thanx for chiming in.
Inline.

> -Original Message-
> From: Alvaro Retana 
> Sent: Wednesday, March 03, 2021 12:06 PM
> To: Les Ginsberg (ginsberg) ; Christian Hopps
> ; Dhruv Dhody 
> Cc: TEAS WG Chairs ; lsr@ietf.org; lsr-...@ietf.org; 
> lsr-
> cha...@ietf.org; TEAS WG (t...@ietf.org) ; teas-
> a...@ietf.org
> Subject: RE: [Lsr] [Teas] WG Last Call for draft-ietf-lsr-isis-rfc5316bis
> 
> On March 3, 2021 at 2:47:38 PM, Les Ginsberg wrote:
> > > From: Lsr On Behalf Of Dhruv Dhody
> 
> Les:
> 
> Hi!
> 
> ...
> > > (1) Is it wise to use normative keywords MUST and SHOULD in the
> > > appendix? The text is from section 3.1 but can it be reworded in the
> > > appendix? Also wondering if other changes (IANA, nits) could be listed
> > > or we could call it "major change" :)
> >
> > [Les:] I personally do not have an issue using the normative keywords in
> > the Appendix. Not doing so I think might trigger someone to ask if there is
> > some inconsistency between the Appendix text and the text in the body of
> the
> > draft. 
> >
> > If you know of some prohibition against using such keywords in an
> Appendix
> > please provide the reference.
> 
> There's no specific prohibition against it -- in fact, sometimes an
> appendix can be normative so it is completely appropriate to have
> normative language.
> 
> In this case, the appendix is informative and the normative text is
> only reflecting what the main body of the draft says (which is where
> the specification is).  To avoid confusion about which piece of text
> is normative, and keep consistency, I would recommend using quotes in
> the appendix:
> 
> OLD>
>    1.  The Router ID SHOULD be identical to the value advertised in the
>    Traffic Engineering Router ID TLV (134) if available.
> 
> NEW>
>    1.  The "Router ID SHOULD be identical" to the value advertised in the
>    Traffic Engineering Router ID TLV (134) if available (Section 3.1).
> 

[Les:] So I am willing to make the change. But I have to say that for me as a 
reader the use of quotes as you suggest does not aid clarity.
I have no idea why the entire sentence should not be quoted as without the 
unquoted portion of the sentence the meaning of the quoted part is incomplete.

??

   Les

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

Re: [Lsr] WG Last Call for draft-ietf-lsr-isis-rfc5316bis

[Les Ginsberg (ginsberg)]

OK

   Les

> -Original Message-
> From: Lsr  On Behalf Of Acee Lindem (acee)
> Sent: Wednesday, March 03, 2021 10:41 AM
> To: Donald Eastlake ; Christian Hopps
> 
> Cc: teas-cha...@ietf.org; teas-...@ietf.org; t...@ietf.org; lsr-
> cha...@ietf.org; lsr@ietf.org; lsr-...@ietf.org
> Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-isis-rfc5316bis
> 
> Speaking as WG member:
> 
> As long as we are revising, I'd suggest changing "ISIS" in the title and 
> several
> times in the text to "IS-IS" consistent with other IS-IS RFCs (at least the
> newer ones).
> Thanks,
> Acee
> 
> On 3/3/21, 1:32 PM, "Donald Eastlake"  wrote:
> 
> Hi,
> 
> I have a few comments. Sorry to send these so late in the process. I
> support publication of this draft regardless of whether any action is
> taken on my comments.
> 
> 1. Since there are non-allocation actions, I suggest that the first
> sentence of Section 6 be more like "IANA is requested to take the
> following actions."
> 
> 2. It should be called out as an explicit IANA action to replace all
> References to "[RFC5316]" on the IANA IS-IS TLV Codepoints web page
> with References to "[this document]".
> 
> 3. Use of "new" throughout the document for codepoints that were
> assigned for RFC 5316 more than a decade ago should be eliminated.
> 
> 4. I generally think it is better for implementation requirements to
> be in the main text rather than the IANA Considerations, so I suggest
> moving "Note that all four sub-TLVs SHOULD NOT appear in TLVs 22, 23,
> 25, 222, or 223 and MUST be ignored if they are included in any of
> these TLVs." up to near the end of Section 3.1.
> 
> 2. I like diagrams and enjoy doing ASCII art, so I suggest replacing
> the prose table at the beginning of 3.1 with the following. In any
> case note that the usual IETF admonition regarding the reserved bits,
> that they MUST be sent as zero and ignored on receipt, seems to be
> missing in the document.
> 
> 0   1   2   3
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>|   Router ID (4 octets)|
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>|   default metric  | (3 octets)
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>|S|D| Rsvd  | (1 octet)
>+-+-+-+-+-+-+-+-+
>|sub-TLVs length| (1 octet)
>+-+-+-+-+-+-+-+-+-+-+-+-
>| sub-TLVs ...(0-246 octets)
>+-+-+-+-+-+-+-+-+-+-+-+-
> 
>  - S, D: Flooding-scope and up/down information discussed below.
>  - Rsvd: 6 reserved bits that MUST be sent as zero and ignored
>  on receipt.
>  - sub-TLVs length: gives the total number of octets of sub-TLVs,
>  which is variable from zero to 246 octets, as an unsigned
>  integer. sub-TLVs are structured as shown below. sub-TLVs
>  with an unknown type MUST be ignored. If the value of the
>  sub-TLVs length field is larger than 246, or the last
>  sub-TLV extends beyond the sub-TLVs length, the TLV is
>  malformed and MUST be ignored.
> 
>+-+-+-+-+-+-+-+-+
>| sub-type  | (1 octet)
>+-+-+-+-+-+-+-+-+
>| sub-TLV length| (1 octet)
>+-+-+-+-+-+-+-+-+-+-+-+-
>| sub-TLV value ...   (variable)
>+-+-+-+-+-+-+-+-+-+-+-+-
> 
> 
> Thanks,
> Donald
> ===
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  2386 Panoramic Circle, Apopka, FL 32703 USA
>  d3e...@gmail.com
> 
> On Wed, Feb 17, 2021 at 10:30 AM Christian Hopps 
> wrote:
> >
> > Hi LSR and TEAS,
> >
> > This begins a joint WG last call for:
> >
> >   https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-rfc5316bis/
> >
> > Please discuss any issues on the LSR mailing list. The WGLC will end 
> March
> 3, 2021.
> >
> > Authors, please indicate wether you are aware of any IPR related to this
> document to the list.
> >
> > Thanks,
> > Chris, Acee, (Lou and Pavan).
> 
> ___
> 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] WG Last Call for draft-ietf-lsr-isis-rfc5316bis

[Les Ginsberg (ginsberg)]

Donald -

Thanx for your careful review and your support of the draft.
Replies inline.

> -Original Message-
> From: Lsr  On Behalf Of Donald Eastlake
> Sent: Wednesday, March 03, 2021 10:32 AM
> To: Christian Hopps 
> Cc: teas-cha...@ietf.org; teas-...@ietf.org; t...@ietf.org; lsr-
> cha...@ietf.org; lsr@ietf.org; lsr-...@ietf.org
> Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-isis-rfc5316bis
> 
> Hi,
> 
> I have a few comments. Sorry to send these so late in the process. I
> support publication of this draft regardless of whether any action is
> taken on my comments.
> 
> 1. Since there are non-allocation actions, I suggest that the first
> sentence of Section 6 be more like "IANA is requested to take the
> following actions."
> 

[Les:] I understand your point.
However, in this case we are inheriting allocations made by RFC5316 AND adding 
a new code point for the new IPv6 local ASBR identifier sub-TLV.
Being 100% accurate requires identifying what has been done already vs what is 
new.
But once the RFC is published the text will change to " IANA has made..." (as 
it is in RFC 5316) for all the code points (new and old).
Having worked w IANA folks many times, I have great confidence that they will 
get things right even with the current less than 100% strictly accurate text - 
so I prefer not to invest time here.
Hope that is OK with you.


> 2. It should be called out as an explicit IANA action to replace all
> References to "[RFC5316]" on the IANA IS-IS TLV Codepoints web page
> with References to "[this document]".
> 

[Les:] OK

> 3. Use of "new" throughout the document for codepoints that were
> assigned for RFC 5316 more than a decade ago should be eliminated.
> 

[Les:] Well, this document replaces RFC 5316. Which means future readers need 
not ever look at RFC 5316. In which case the distinction between what was "new" 
in 5316 and what is "new" in 5316bis becomes moot. 
So while I agree that strictly speaking you are correct I am not convinced that 
doing as you suggest aids clarity. 

> 4. I generally think it is better for implementation requirements to
> be in the main text rather than the IANA Considerations, so I suggest
> moving "Note that all four sub-TLVs SHOULD NOT appear in TLVs 22, 23,
> 25, 222, or 223 and MUST be ignored if they are included in any of
> these TLVs." up to near the end of Section 3.1.

[Les:] I have looked at other documents with similar cases (i.e., a sub-TLV 
that is permitted in only a subset of the TLVs in the combined registry) and 
they do not have such a statement at all. The "N" indication in the registry 
columns is deemed sufficient.
I am therefore inclined to remove the Note altogether.

> 
> 2. I like diagrams and enjoy doing ASCII art, so I suggest replacing
> the prose table at the beginning of 3.1 with the following. In any
> case note that the usual IETF admonition regarding the reserved bits,
> that they MUST be sent as zero and ignored on receipt, seems to be
> missing in the document.
> 
> 0   1   2   3
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>|   Router ID (4 octets)|
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>|   default metric  | (3 octets)
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>|S|D| Rsvd  | (1 octet)
>+-+-+-+-+-+-+-+-+
>|sub-TLVs length| (1 octet)
>+-+-+-+-+-+-+-+-+-+-+-+-
>| sub-TLVs ...(0-246 octets)
>+-+-+-+-+-+-+-+-+-+-+-+-
> 
>  - S, D: Flooding-scope and up/down information discussed below.
>  - Rsvd: 6 reserved bits that MUST be sent as zero and ignored
>  on receipt.
>  - sub-TLVs length: gives the total number of octets of sub-TLVs,
>  which is variable from zero to 246 octets, as an unsigned
>  integer. sub-TLVs are structured as shown below. sub-TLVs
>  with an unknown type MUST be ignored. If the value of the
>  sub-TLVs length field is larger than 246, or the last
>  sub-TLV extends beyond the sub-TLVs length, the TLV is
>  malformed and MUST be ignored.
> 
>+-+-+-+-+-+-+-+-+
>| sub-type  | (1 octet)
>+-+-+-+-+-+-+-+-+
>| sub-TLV length| (1 octet)
>+-+-+-+-+-+-+-+-+-+-+-+-
>| sub-TLV value ...   (variable)
>+-+-+-+-+-+-+-+-+-+-+-+-

[Les:] OK
It was not done this way in RFC 5316. When writing bis documents I am biased to 
NOT changing existing presentation if there is no actual change in 
functionality to that section.
But I agree diagrams are easier to read and it would be more consistent with 
other 

Re: [Lsr] [Teas] WG Last Call for draft-ietf-lsr-isis-rfc5316bis

[Les Ginsberg (ginsberg)]

Dhruv -



Thanx for reviewing/supporting the draft.

Please see inline.



> -Original Message-

> From: Lsr  On Behalf Of Dhruv Dhody

> Sent: Wednesday, March 03, 2021 2:09 AM

> To: Christian Hopps 

> Cc: TEAS WG Chairs ; teas-...@ietf.org; TEAS WG

> (t...@ietf.org) ; lsr-cha...@ietf.org; lsr@ietf.org; lsr-

> a...@ietf.org

> Subject: Re: [Lsr] [Teas] WG Last Call for draft-ietf-lsr-isis-rfc5316bis

>

> Hi,

>

> I went through the diff with RFC5316. The changes look good. Some

> minor comments -

>

> (1) Is it wise to use normative keywords MUST and SHOULD in the

> appendix? The text is from section 3.1 but can it be reworded in the

> appendix? Also wondering if other changes (IANA, nits) could be listed

> or we could call it "major change" :)



[Les:] I personally do not have an issue using the normative keywords in the 
Appendix. Not doing so I think might trigger someone to ask if there is some 
inconsistency between the Appendix text and the text in the body of the draft. 

If you know of some prohibition against using such keywords in an Appendix 
please provide the reference.



The IANA change is a consequence of the introduction pf new  IPv6 Local ASBR 
identifier sub-TLV. I do not see the need to mention it in the Appendix.



I do not understand your comment about "major change". Could you explain?



>

> (2) IPv6 Local ASBR ID and IPv6 Router ID is used interchangeably i.e.

> table in IANA section 6.2 does not use the same name as the table in

> section 3.1

>



[Les:] The use of " IPv6 Router ID" in Section 3.1 is inconsistent. I will fix 
that.

Thanx for pointing that out.



   Les



> Hope this helps!

>

> Thanks!

>

> Dhruv

>

>

>

> On Wed, Feb 17, 2021 at 9:00 PM Christian Hopps 
> mailto:cho...@chopps.org>>

> wrote:

> >

> > Hi LSR and TEAS,

> >

> > This begins a joint WG last call for:

> >

> >   https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-rfc5316bis/

> >

> > Please discuss any issues on the LSR mailing list. The WGLC will end March

> 3, 2021.

> >

> > Authors, please indicate wether you are aware of any IPR related to this

> document to the list.

> >

> > Thanks,

> > Chris, Acee, (Lou and Pavan).

> > ___

> > Teas mailing list

> > t...@ietf.org

> > https://www.ietf.org/mailman/listinfo/teas

>

> ___

> 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

[Lsr] When is an IANA Registry Required

[Les Ginsberg (ginsberg)]

Alvaro -



In your review of draft-ietf-lsr-isis-srv6-extensions you requested the authors 
to



"Please ask IANA to set up a registry for the Flags."



in multiple cases e.g., the flags field defined in the new SRv6 Capabilities 
sub-TLV.



This isn't the first time you have made such a request (I believe I argued 
against this in the past and you relented – but only temporarily it seems.  ).

As it is a deviation from historical practice, I think it would be better if 
the WG discussed whether there is a good reason to change our practices rather 
than have this request be made based on the personal preference of the current 
AD.



Historically, we have created IANA registries for identifiers which are likely 
to be needed by a variety of unrelated features supported by the protocol. The 
expectation in these cases is that multiple documents - largely unrelated to 
each other - might need to allocate an ID from the same space.

Obvious examples are TLV/sub-TLV code points.

In the case of flags, there are currently only two such registries:



link-attribute bit values for sub-TLV 19 of TLV 
22



Bit Values for Prefix Attribute Flags 
Sub-TLV



In both of these cases the sub-TLVs were defining a general purpose bit field.  
It was expected (and it has happened) that unrelated documents had a need to 
allocate a bit in these fields.



What we have NOT done, historically, is create a registry for a flags field 
which is not provided as a general purpose mechanism,  but is specifically 
scoped for use only within the context of the feature which defined the 
TLV/sub-TLV. (There are many examples.)

It is expected in these cases that if an additional flag is required, that it 
will be defined in a document directly related to the original feature – either 
a bis version of the original document or a new document which is marked 
specifically as an update to the original document.

Management of the flag space in such cases has never required the overhead of a 
registry.



You seem to want to change that and I would like to know why?

What problem exists that you are trying to solve?



IMO, such a policy is not needed, does not add value, but does add additional 
overhead to what is already a considerable set of hoops which drafts must 
navigate on their way to becoming an RFC.

The number of existing TLV/sub-TLVs which have flags fields is significant – 
and the lack of a registry for these fields has not yet caused any problem.



Appreciate if we could have open discussion on this.



   Les






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

Re: [Lsr] Fwd: New Version Notification for draft-acee-lsr-ospf-transport-instance-02.txt

[Les Ginsberg (ginsberg)]

Yingzhen -

Thanx for incorporating my suggestion to use the Application Identifiers 
Registry created in RFC 6823 ( 
https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#app-ids-251
 ) to allow sharing of application IDs between IS-IS and OSPF.
I think, however, that we may well want to revise the format of this registry - 
which is currently very IS-IS centric. Things we may want to consider 
requesting from IANA:

Specifying whether the ID can be used by OSPF, IS-IS, or both.
Moving the registry from the IS-IS TLV Codepoints registry to Interior Gateway 
Protocol (IGP) Parameters 
(https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml )

Happy to work with you folks on this.

Some editorial nits in Section 3.3

"In some cases, it is desirable to limit the number of BGP-LS
   [RFC5572] sessions with a controller to the a one or two routers in

s/to the a/to

   an OSPF domain.  However, many times those router(s) do not have full
   visibility to the complete topology of all the areas.  To solve this
   problem without extended the BGP-LS domain, the OSPF LSAs for non-

s/extended/extending

   local area could be flooded over the OSPF transport instance topology
   using remote neighbors Section 4.7.1."


   Les

From: Lsr  On Behalf Of Yingzhen Qu
Sent: Monday, February 22, 2021 12:31 PM
To: lsr@ietf.org
Cc: Abhay Roy ; Acee Lindem (acee) ; Sina 
Mirtorabi 
Subject: [Lsr] Fwd: New Version Notification for 
draft-acee-lsr-ospf-transport-instance-02.txt

Hi,

We submitted a new version of this draft with detailed OSPFv2 and OSPFv3 
encodings. Please review and send your comments.

Thanks,
Yingzhen




From: internet-dra...@ietf.org 
mailto:internet-dra...@ietf.org>>
Sent: Sunday, February 21, 2021 11:21 AM
To: Abhay Roy mailto:ab...@arrcus.com>>; Acee Lindem 
mailto:a...@cisco.com>>; Sina Mirtorabi 
mailto:smirt...@cisco.com>>; Yingzhen Qu 
mailto:yingzhen...@futurewei.com>>
Subject: New Version Notification for 
draft-acee-lsr-ospf-transport-instance-02.txt


A new version of I-D, draft-acee-lsr-ospf-transport-instance-02.txt
has been successfully submitted by Yingzhen Qu and posted to the
IETF repository.

Name:   draft-acee-lsr-ospf-transport-instance
Revision:   02
Title:  OSPF Transport Instance Extensions
Document date:  2021-02-19
Group:  Individual Submission
Pages:  14
URL:   
https://www.ietf.org/archive/id/draft-acee-lsr-ospf-transport-instance-02.txt
Status: 
https://datatracker.ietf.org/doc/draft-acee-lsr-ospf-transport-instance/
Htmlized:  
https://datatracker.ietf.org/doc/html/draft-acee-lsr-ospf-transport-instance
Diff:  
https://www.ietf.org/rfcdiff?url2=draft-acee-lsr-ospf-transport-instance-02

Abstract:
   OSPFv2 and OSPFv3 include a reliable flooding mechanism to
   disseminate routing topology and Traffic Engineering (TE) information
   within a routing domain.  Given the effectiveness of these
   mechanisms, it is convenient to envision using the same mechanism for
   dissemination of other types of information within the domain.
   However, burdening OSPF with this additional information will impact
   intra-domain routing convergence and possibly jeopardize the
   stability of the OSPF routing domain.  This document presents
   mechanism to relegate this ancillary information to a separate OSPF
   instance and minimize the impact.




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.

The IETF Secretariat

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

Re: [Lsr] New Version Notification for draft-wang-lsr-isis-mfi-00.txt

[Les Ginsberg (ginsberg)]

IMO there is no need for this draft to exist.

Before a need for such a draft can be established two things have to happen in 
the following order:

1)There has to be WG consensus that application info such as VTN should be 
advertised by the IGPs.
To date no such consensus exists and there has been significant resistance to 
doing so.

2)If such consensus is reached there is already a defined/implemented solution 
- RFC 8202. Therefore, the need for a different set of protocol extensions 
would first require WG consensus that there are significant shortcomings to the 
RFC 8202 solution.
No such consensus exists nor has any discussion on this point taken place.

If the authors of this new draft want to start by discussing point #1 on the 
list - fair enough. But the starting point for that discussion should NOT be 
this draft. Therefore, I will make no comment on the content of the draft.

Authors - if your response is to try to explain to me why this draft is needed, 
then you have not understood what I am saying.

   Les


> -Original Message-
> From: Lsr  On Behalf Of wangyali
> Sent: Monday, February 22, 2021 11:11 PM
> To: lsr@ietf.org
> Cc: Huzhibo ; Aijun Wang
> ; Tianran Zhou 
> Subject: Re: [Lsr] New Version Notification for draft-wang-lsr-isis-mfi-00.txt
> 
> Hi all,
> 
> In order to separate multiple flooding instances for dissemination of routing
> information and other types of application-specific information to minimizes
> the impact of non-routing information flooding on the routing convergence
> and stability, We submitted a new IS-IS flooding mechanism implemented in
> the zero IS-IS instance, named as IS-IS Multi-flooding Instances (MFIs).
> 
>  An encoding format for IS-IS MFI-ID TLV and MFIs Update Process defined in
> this draft could be found in https://datatracker.ietf.org/doc/draft-wang-lsr-
> isis-mfi/ .
> 
> Any questions and comments are welcome.
> 
> Thanks,
> Yali
> 
> -Original Message-
> From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
> Sent: Monday, February 22, 2021 9:59 AM
> To: Aijun Wang ; Tianran Zhou
> ; wangyali ; Huzhibo
> 
> Subject: New Version Notification for draft-wang-lsr-isis-mfi-00.txt
> 
> 
> A new version of I-D, draft-wang-lsr-isis-mfi-00.txt has been successfully
> submitted by Yali Wang and posted to the IETF repository.
> 
> Name: draft-wang-lsr-isis-mfi
> Revision: 00
> Title:IS-IS Multi-Flooding Instances
> Document date:2021-02-20
> Group:Individual Submission
> Pages:7
> URL:https://www.ietf.org/archive/id/draft-wang-lsr-isis-mfi-00.txt
> Status: https://datatracker.ietf.org/doc/draft-wang-lsr-isis-mfi/
> Htmlized:   https://datatracker.ietf.org/doc/html/draft-wang-lsr-isis-mfi
> Htmlized:   https://tools.ietf.org/html/draft-wang-lsr-isis-mfi-00
> 
> 
> Abstract:
>This document proposes a new IS-IS flooding mechanism which separates
>multiple flooding instances for dissemination of routing information
>and other types of application-specific information to minimizes the
>impact of non-routing information flooding on the routing convergence
>and stability.  Due to different flooding information has different
>requirements on the flooding rate, these multi-flooding instances
>should be given various priorities and flooding parameters.  An
>encoding format for IS-IS Multi-Flooding Instance Identifier (MFI-ID)
>TLV and Update Process are specified in this document.
> 
> 
> 
> 
> 
> 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.
> 
> The IETF Secretariat
> 
> 
> ___
> 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] WG Last Call for draft-ietf-lsr-isis-rfc5316bis

[Les Ginsberg (ginsberg)]

Acee -



Thanx for your - as always - meticulous review. I have posted an updated 
version incorporating your comments.



Have you considered adding yourself to the IDNITs check?  



   Les



> -Original Message-

> From: Lsr  On Behalf Of Acee Lindem (acee)

> Sent: Thursday, February 18, 2021 11:24 AM

> To: Christian Hopps ; lsr@ietf.org

> Cc: lsr-cha...@ietf.org; lsr-...@ietf.org; teas-cha...@ietf.org; teas-

> a...@ietf.org; t...@ietf.org

> Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-isis-rfc5316bis

>

> Speaking as WG member, I support publication. I've attached an rfcdiff with

> RFC 5313 to aid others in their review.

>

> I have the following editorial comments on the changed lines:

>

> *** draft-ietf-lsr-isis-rfc5316bis-00.txt.orig   Thu Feb 18 13:58:31 2021

> --- draft-ietf-lsr-isis-rfc5316bis-00.txt   Thu Feb 18 14:20:54 2021

> ***

> *** 519,525 

>114   IPv4 TE Router ID

>12   16   IPv6 TE Router ID

>

> !Detailed definitions of the new sub-TLV are described in

>  Section 3.4.1 and 3.4.2.

>

>   3.3.  Sub-TLVs for Inter-AS Reachability TLV

> --- 519,525 

>114   IPv4 TE Router ID

>12   16   IPv6 TE Router ID

>

> !Detailed definitions of the new sub-TLVs are described in

>  Section 3.4.1 and 3.4.2.

>

>   3.3.  Sub-TLVs for Inter-AS Reachability TLV

> ***

> *** 905,911 

>

>   6.1.  Inter-AS Reachability TLV

>

> !This document defines the following new ISI-IS TLV type, described in

>  Section 3.1, which has been registered in the IS-IS TLV codepoint

>  registry:

>

> --- 905,911 

>

>   6.1.  Inter-AS Reachability TLV

>

> !This document defines the following IS-IS TLV type, described in

>  Section 3.1, which has been registered in the IS-IS TLV codepoint

>  registry:

>

> ***

> *** 936,942 

>

>  As described above in Section 3.1, the sub-TLVs which are defined in

>  [RFC5305], [RFC6119] and other documents for describing the TE

> !properties of an TE link are applicable to describe an inter-AS TE

>  link and MAY be included in the inter-AS reachability TLV when

>  adverting inter-AS TE links.

>

> --- 936,942 

>

>  As described above in Section 3.1, the sub-TLVs which are defined in

>  [RFC5305], [RFC6119] and other documents for describing the TE

> !properties of a TE link are applicable to describe an inter-AS TE

>  link and MAY be included in the inter-AS reachability TLV when

>  adverting inter-AS TE links.

>

> Thanks,

> Acee

>

> On 2/17/21, 10:31 AM, "Christian Hopps" 
> mailto:cho...@chopps.org>> wrote:

>

> Hi LSR and TEAS,

>

> This begins a joint WG last call for:

>

>   https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-rfc5316bis/

>

> Please discuss any issues on the LSR mailing list. The WGLC will end March

> 3, 2021.

>

> Authors, please indicate wether you are aware of any IPR related to this

> document to the list.

>

> Thanks,

> Chris, Acee, (Lou and Pavan).


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

Re: [Lsr] WG Last Call for draft-ietf-lsr-isis-rfc5316bis

[Les Ginsberg (ginsberg)]

I am not aware of any IPR related to this draft.

   Les

> -Original Message-
> From: Lsr  On Behalf Of Christian Hopps
> Sent: Wednesday, February 17, 2021 7:30 AM
> To: lsr@ietf.org
> Cc: Christian Hopps ; teas-cha...@ietf.org; teas-
> a...@ietf.org; t...@ietf.org; lsr-cha...@ietf.org; lsr-...@ietf.org
> Subject: [Lsr] WG Last Call for draft-ietf-lsr-isis-rfc5316bis
> 
> Hi LSR and TEAS,
> 
> This begins a joint WG last call for:
> 
>   https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-rfc5316bis/
> 
> Please discuss any issues on the LSR mailing list. The WGLC will end March 3,
> 2021.
> 
> Authors, please indicate wether you are aware of any IPR related to this
> document to the list.
> 
> Thanks,
> Chris, Acee, (Lou and Pavan).

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

Re: [Lsr] I-D Action: draft-ietf-lsr-isis-rfc5316bis-00.txt

[Les Ginsberg (ginsberg)]

Folks -

On behalf of the draft authors I am requesting WG last call on this document.
It is a very minor and non-controversial change to allow GMPLS/TE InterAS 
extensions to work in an IPv6 only network.
Summary of the changes can be found in 
https://tools.ietf.org/html/draft-ietf-lsr-isis-rfc5316bis-00#appendix-A .

First version of this was actually published over 5 years ago - but the authors 
failed to aggressively progress the document until recently.
It is long past time to complete this work.

WG chairs - please consider starting WG Last Call ASAP.

Thanx.

   Les


> -Original Message-
> From: Lsr  On Behalf Of internet-dra...@ietf.org
> Sent: Sunday, November 15, 2020 8:58 AM
> To: i-d-annou...@ietf.org
> Cc: lsr@ietf.org
> Subject: [Lsr] I-D Action: draft-ietf-lsr-isis-rfc5316bis-00.txt
> 
> 
> 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   : ISIS Extensions in Support of Inter-Autonomous 
> System (AS)
> MPLS and GMPLS Traffic Engineering
> Authors : Mach(Guoyi) Chen
>   Les Ginsberg
>   Stefano Previdi
>   Xiaodong Duan
>   Filename: draft-ietf-lsr-isis-rfc5316bis-00.txt
>   Pages   : 20
>   Date: 2020-11-15
> 
> Abstract:
>This document describes extensions to the Intermediate System to
>Intermediate System (IS-IS) protocol to support Multiprotocol Label
>Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering
>(TE) for multiple Autonomous Systems (ASs).  It defines IS-IS
>extensions for the flooding of TE information about inter-AS links,
>which can be used to perform inter-AS TE path computation.
> 
>No support for flooding information from within one AS to another AS
>is proposed or defined in this document.
> 
>This document obsoletes RFC 5316.
> 
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-rfc5316bis/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-lsr-isis-rfc5316bis-00
> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-rfc5316bis-00
> 
> 
> 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 mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG adoption call for draft-acee-lsr-isis-yang-augmentation-v1-03

[Les Ginsberg (ginsberg)]

Support.
These additional aspects of the protocol certainly need to be included in the 
model.

   Les

> -Original Message-
> From: Lsr  On Behalf Of Christian Hopps
> Sent: Tuesday, January 05, 2021 1:20 AM
> To: lsr@ietf.org
> Cc: lsr-cha...@ietf.org; Christian Hopps 
> Subject: [Lsr] WG adoption call for draft-acee-lsr-isis-yang-augmentation-v1-
> 03
> 
> This begins a 2 week WG adoption call for the following draft:
> 
>   https://datatracker.ietf.org/doc/draft-acee-lsr-isis-yang-augmentation-v1/
> 
> Please indicate your support or objection by January 19th, 2021.
> 
> Authors, please respond to the list indicating whether you are aware of any
> IPR that applies to this draft.
> 
> Thanks,
> Chris.

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

Re: [Lsr] WG adoption call for draft-acee-lsr-ospf-admin-tags-07

[Les Ginsberg (ginsberg)]

I support WG adoption.
This functionality has proven very useful in IS-IS. OSPF should have the same 
capabilities.

   Les

> -Original Message-
> From: Lsr  On Behalf Of Christian Hopps
> Sent: Tuesday, January 05, 2021 1:17 AM
> To: lsr@ietf.org
> Cc: lsr-cha...@ietf.org; Christian Hopps 
> Subject: [Lsr] WG adoption call for draft-acee-lsr-ospf-admin-tags-07
> 
> This begins a 2 week WG adoption call for the following draft:
> 
>   https://datatracker.ietf.org/doc/draft-acee-lsr-ospf-admin-tags/
> 
> Please indicate your support or objection by January 19th, 2021.
> 
> Authors, please respond to the list indicating whether you are aware of any
> IPR that applies to this draft.
> 
> Thanks,
> Chris.

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

Re: [Lsr] New Version Notification for draft-white-lsr-distoptflood-00.txt

[Les Ginsberg (ginsberg)]

Russ -



I think you have too many email addresses. 

Inline.



> -Original Message-

> From: op...@riw.us 

> Sent: Monday, January 04, 2021 10:01 AM

> To: Les Ginsberg (ginsberg) ; 7ri...@gmail.com;

> 'Shraddha Hegde' ; lsr@ietf.org

> Subject: RE: [Lsr] New Version Notification for draft-white-lsr-distoptflood-

> 00.txt

>

>

> > [Les:] Signaling is required in your solution to indicate whether the

> neighbor

> > should/should not propagate the LSP(s) received from a given neighbor.

> > But Circuit Scoped LSPs as defined in RFC 7356 do not provide this

> functionality.

> >

> > A Circuit Scoped LSP is to be used to send information originated by a node

> to a

> > specific neighbor of that node. This information has circuit scope - meaning

> it is

> > NEVER meant to be flooded on other circuits.

> > It is not an encapsulation mechanism to forward area/domain scoped LSPs

> > originated by other nodes in the network.

>

> I guess I'm not seeing the conflict here ... I'm okay with defining a new way 
> to

> signal an LSP should not be reflooded, but it seems like re-using the existing

> mechanism is a better way to move forward.

>



[Les:] There is no "existing mechanism".

Please look a bit closer.



https://www.rfc-editor.org/rfc/rfc7356.html#section-3.1 defines the format of 
the header of a FS-LSP. In particular, the LSP-ID is defined as:





 +-+

 |   Source ID | ID Length

 +-+

 | Pseudonode ID   | 1

 +-+

 | FS LSP Number   | 1

 +-+



Now, suppose node A needs to originate both:



a)A Level-1 LSP (Scope 4)

b)A Level-1 Circuit Scoped LSP (Scope 1)



The LSP-ID for both of these LSPs will be: A.00-00



Since you propose that both of these LSPs be sent as a Circuit Scoped LSP the 
receiver will be unable to tell the difference.



You simply cannot do what you propose.





> > [Les:] I assume what you are referring to here is MANET and the Multipoint

> > Relay (MPR) functionality.

>

> No -- RFC5820, which was implemented by Cisco, and is widely deployed.



[Les:] RFC5820 is titled  “Extensions to OSPF to Support Mobile Ad Hoc 
Networking”

And there are signaling extensions defined in the RFC for which you jave no 
equivalents in your draft.



As I previously commented, in your proposal, how do you know whether a node 
supports the extensions or not?

This seems quite necesssary to your proposal.



>

> > [Les:] It does seem that you do NOT want to use dynamic flooding

> extensions.

> > Which makes me wonder why you suggest (Section 3) the election of an

> Area

> > Leader. What purpose does this serve in your solution?

>

> When this draft was first proposed, I received several emails stating it MUST

> fit within the framework of the larger framework document, so I proposed a

> way to indicate this type of flooding reduction within that larger framework.

> There is no "leader" in this draft of any kind.

>

> There seem to be two general criticisms here. The first is that it doesn't fit

> into the general pattern of "elect a leader of some kind." IMHO, this is not a

> bug but a feature. The method described in this draft has been proven to

> work--there are two implementations, both of which show large reductions

> in flooding. Further, the general concept has been proven to work in

> implementations deployed in the real world. I'm not entirely certain what to

> make of this criticism -- we aren't trying to replace the existing proposals, 
> but

> rather provide a complimentary option. I don't see why it should be that

> every possible solution must elect a leader in some way to be valid or

> acceptable.

>



[Les:] If your intention is NOT to fit into dynamic flooding framework, you can 
state that. But stating that and then saying “go ahead and elect an Area Leader 
if your want” makes no sense.

Pleasel be clear and internally consistent.



   Les



> The second criticism seems to be that it doesn't use signaling correctly ...

> While I don't really understand this criticism, I think we can work together 
> to

> resolve it.

>

>  /r


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

Re: [Lsr] New Version Notification for draft-white-lsr-distoptflood-00.txt

[Les Ginsberg (ginsberg)]

Russ -

Happy New Year.
Responses inline.

> -Original Message-
> From: Lsr  On Behalf Of 7ri...@gmail.com
> Sent: Saturday, December 19, 2020 4:49 AM
> To: 'Les Ginsberg (ginsberg)' ;
> 'Shraddha Hegde' ; lsr@ietf.org
> Subject: Re: [Lsr] New Version Notification for draft-white-lsr-distoptflood-
> 00.txt
> 
> 
> 
> > Given the base work defined in draft-ietf-lsr-dynamic-flooding why is
> > the use of Circuit Scoped LSPs required/useful?
> 
> Circuit scoped flooding is required to prevent unnecessary floods from being
> carried beyond where they are needed in the network.
> 

[Les:] Signaling is required in your solution to indicate whether the neighbor 
should/should not propagate the LSP(s) received from a given neighbor.
But Circuit Scoped LSPs as defined in RFC 7356 do not provide this 
functionality.

A Circuit Scoped LSP is to be used to send information originated by a node to 
a specific neighbor of that node. This information has circuit scope - meaning 
it is NEVER meant to be flooded on other circuits. 
It is not an encapsulation mechanism to forward area/domain scoped LSPs 
originated by other nodes in the network.

The obvious conflict arises when a given Node needs to originate circuit scoped 
information. The LSP-ID associated with this information will be 
indistinguishable from the LSP-ID of an area/domain scoped LSP originated by 
that same node.
So your overloaded use case cannot be supported.

BTW, this isn't simply a theoretical issue. One of the documented use cases for 
Circuit Scoped LSPs is defined in 
https://tools.ietf.org/html/draft-ietf-lsr-isis-spine-leaf-ext-02 - which might 
well be relevant to the same deployment cases this draft targets.

> One thought ... the way I originally worded the draft was not to have two
> separate databases, but rather just to insert LSPs received as circuit local
> in the normal database and then clear the SRM for those LSPs, so the local
> flooding process believes they have already been flooded, but they will be
> included in the CSNP, etc., as normal. I'm not certain why we need two
> databases here.
> 
> > [Les:] If you use the mechanisms defined in
> > draft-ietf-lsr-dynamic-flooding there would be no need to use Circuit
> > Scoped Flooding to send normal area scoped LSPs.
> 
> > Each node in the topology would know to which neighbors it should have
> > flooding enabled - either because you operate in centralized mode and
> > the Area Leader distributes the flooding topology or because you operate
> > in distributed mode and all nodes employ the same algorithm. (The latter
> 
> Using an area leader, even to centrally calculate a flooding topology,
> breaks the distributed nature of the solutions, and creates a much more
> complex solution. If you operate in distributed mode, with a common
> algorithm, I think you still need to specify what that algorithm is ... this
> draft describes such an algorithm ... I think ... ??
> 
> > The fact that you apparently do NOT want to use the extensions defined
> > in the dynamic-flooding draft means that (as you agree above) you have
> > to introduce additional protocol extensions which aren't really
> > necessary. This makes the solution much less appealing to me -
> > independent of the merits/demerits of the algorithm itself.
> 
> Not really... we are modifying already existing protocol extensions, rather
> than creating new ones.

[Les:] What you have done is abuse an existing mechanism and try to use it in a 
way which conflicts with its defined functionality.

> 
> The process described in this draft has already been tested, and is widely
> used, in OSPF, btw (and doesn't use two databases there).
> 
[Les:] I assume what you are referring to here is MANET and the Multipoint 
Relay (MPR) functionality.
But MPR depends upon enhanced signaling of a node's willingness to participate 
in enhanced flooding - which you have not defined.
So in addition to abusing Circuit Scoped LSP functionality, you haven't defined 
a means to operate with partial deployment of the extensions or even to know 
whether a node supports the extensions.

Seems to me you have skipped some key steps here.

> > The use of Circuit Scoped LSPs to send traditional area scoped LSPs is
> > not at all what RFC 7356 intends. And it causes difficulties (as you
> > have noted above) in what the content of CSNPs should be and how the
> > different LSPDBs are used internally.
> 
> > The dynamic flooding draft wasn't in existence when Russ wrote the
> > early versions of this draft. I am suggesting you might want to rethink
> > your approach to take advantage of what dynamic flooding draft has
> > defined.
> 
> The dynamic flooding draft assumes an area leader, which is what this draft
&

Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

[Les Ginsberg (ginsberg)]

Zhenqiang -

In regards to:


[Zhenqiang]Since paths for IP flex-algo are calculated within specific MT, I 
think one new top-level TLV for ISIS is enough to advertise prefix reachability 
associated with a Flex-Algorithm, that is the one defined in section 6.1. MTID 
can be used to indicate it is for IPv4 or IPv6.


You have misunderstood RFC 5120.
It is true that the reserved MTIDs defined in 
https://www.rfc-editor.org/rfc/rfc5120.html Section 7.5  are restricted to 
support only a single AFI/SAFI, but non-reserved MTIDs are NOT subject to this 
restriction. It is quite possible to use one of the unreserved MTIDs and 
support forwarding of both IPv4 and IPv6 address families on the topology 
associated with that MTID. Therefore, it is necessary to define AF specific 
TLVs. And that is why RFC 5120 did so and why this draft also must do so.

Draft authors -

https://tools.ietf.org/html/draft-bonica-lsr-ip-flexalgo-01#section-6.2 states:

"The ISIS IPv6 Algorithm Prefix Reachability TLV is identical to the
   ISIS IPv4 Algorithm Prefix Reachability TLV, except that it has a
   unique type."

But this is not completely accurate.
The existing Prefix Reachability TLVs for IPV4 (135, 235) and IPv6 (236, 237) 
have different flags formats.
See https://www.rfc-editor.org/rfc/rfc5305.html#section-4 and 
https://www.rfc-editor.org/rfc/rfc5308.html  Section 2 respectively.
And of course the legal ranges for prefix length are different.

I would expect these differences to be preserved in the new TLVs defined in 
this draft. It would therefore be better (and more accurate) if you replaced 
the above statement with a diagram for the new IPv6 TLV comparable to the one 
in Section 6.1.

Thanx.

   Les


From: Lsr  On Behalf Of li_zhenqi...@hotmail.com
Sent: Wednesday, December 09, 2020 8:04 PM
To: Peter Psenak ; Dongjie (Jimmy) 
; Acee Lindem (acee) ; 
lsr 
Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms 
(Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

Hello Peter,

follow-up questions with [Zhenqiang].

FA calculation is done for every MT topology independently.
For IPv4 it will take all routers participating in MT0 and run the FA
calculation on top of MT0.
For IPv6 it will take all routers participating in MT2 and run the FA
calculation on top of MT2.

[Zhenqiang] Could you please elaborate this explicitly in the draft? For 
example, in section 7, replace the setence "IP Flex-Algorithm application only 
considers participating nodes during the Flex-Algorithm calculation" with "IP 
Flex-Algorithm application only considers participating nodes within the same 
MTID during the Flex-Algorithm calculation".

[Zhenqiang]Since paths for IP flex-algo are calculated within specific MT, I 
think one new top-level TLV for ISIS is enough to advertise prefix reachability 
associated with a Flex-Algorithm, that is the one defined in section 6.1. MTID 
can be used to indicate it is for IPv4 or IPv6.

Best Regards,
Zhenqiang Li

li_zhenqi...@hotmail.com

From: Peter Psenak
Date: 2020-12-09 21:05
To: Dongjie (Jimmy); Acee Lindem 
(acee); lsr
Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms 
(Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01
Hi Jimmy,

On 09/12/2020 13:52, Dongjie (Jimmy) wrote:
> Hi Peter,
>
>> -Original Message-
>> From: Peter Psenak [mailto:ppse...@cisco.com]
>> Sent: Wednesday, December 9, 2020 6:45 PM
>> To: Dongjie (Jimmy) mailto:jie.d...@huawei.com>>; Acee 
>> Lindem (acee)
>> mailto:acee=40cisco@dmarc.ietf.org>>; 
>> lsr mailto:lsr@ietf.org>>
>> Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms
>> (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01
>>
>> Jimmy,
>>
>> On 09/12/2020 11:10, Dongjie (Jimmy) wrote:
>>> Hi authors,
>>>
>>> Here is one comment following the previous discussion on the mail list
>>> and the IETF meeting.
>>>
>>> The IP Algorithm TLV is defined to advertise the IP Flex-Algorithm
>>> participation information, there is no separate TLV for IPv4 or IPv6
>>> Flex-Algo participation.
>>
>> the draft clearly says:
>>
>>  "The IP Flex-Algorithm participation advertised in ISIS IP Algorithm
>>  Sub-TLV is topology independent."
>
> This does not answer my question.
>
> Section 7 gives the rules of IP Flex-Algo Path calculation:
>
> " IP Flex-Algorithm application only considers participating nodes during the 
> Flex-Algorithm calculation.  When computing paths for a given Flex-Algorithm, 
> all nodes that do not advertise participation for IP Flex-Algorithm, as 
> described in Section 5, MUST be pruned from the topology."
>
>>From IP Algorithm TLV, one cannot tell whether a node participates in 
>>Flex-Algo 128 for IPv4, IPv6 or both. This would cause the problem described 
>>below: 

Re: [Lsr] New Version Notification for draft-white-lsr-distoptflood-00.txt

[Les Ginsberg (ginsberg)]

Shraddha -

Thanx for the responses.

Please see inline.

From: Shraddha Hegde 
Sent: Wednesday, December 02, 2020 9:30 AM
To: Les Ginsberg (ginsberg) ; lsr@ietf.org
Subject: RE: New Version Notification for draft-white-lsr-distoptflood-00.txt

Hi Les,

Thanks for the review and comments.
Pls see inline for replies.



Juniper Business Use Only
From: Les Ginsberg (ginsberg) 
mailto:ginsberg=40cisco@dmarc.ietf.org>>
Sent: Monday, November 30, 2020 11:44 AM
To: Shraddha Hegde mailto:shrad...@juniper.net>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Subject: RE: New Version Notification for draft-white-lsr-distoptflood-00.txt

[External Email. Be cautious of content]


Draft authors -



I note that as the draft has evolved over the years a number of mechanisms have 
been removed (revised adjacency formation and auto tier detection) and the 
draft now focuses exclusively on flooding optimizations.

The draft now also references the recent work done in 
draft-ietf-lsr-dynamic-flooding.



A couple of things are not clear to me.



1)Is it your intent to use the mechanisms defined in 
draft-ietf-lsr-dynamic-flooding? I am specifically - though not exclusively - 
referring to how flooding adapts to topology changes.

It isn't clear from Section 3 whether you are actually intending to use the 
mechanisms defined in 
https://tools.ietf.org/html/draft-ietf-lsr-dynamic-flooding-07#section-6.8<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-lsr-dynamic-flooding-07*section-6.8__;Iw!!NEt6yMaO-gk!VproGis8uUGmcl-cCplFMwuNceAo-3roUZT7ZdTlwvY7nJSszUo9AeWXymgguZIt$>
 or whether you simply want to use the Flooding sub-TLV defined in 
draft-ietf-lsr-dynamic-flooding to (optionally??) advertise your algorithm and 
all other procedures are specific to your algorithm.

 We want to use the " IS-IS Dynamic Flooding Sub-TLV" defined in sec 
5.1.2 of the lsr-dynamic-flooding draft just to flood the information
that nodes support the algorithm specified in draft-white-lsr-distoptflood. I 
agree it's not writen very well. I'll update that section in next version.





2)The text at the end of 
https://tools.ietf.org/html/draft-white-lsr-distoptflood-00#section-2.1<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-white-lsr-distoptflood-00*section-2.1__;Iw!!NEt6yMaO-gk!VproGis8uUGmcl-cCplFMwuNceAo-3roUZT7ZdTlwvY7nJSszUo9AeWXyucq9YRN$>
 states:



" LSPs transmitted to adjacent

   neighbors on the DNR list, however, MUST be transmitted using a

   circuit scope PDU as described in [RFC7356]."



Although this text is not new to this revision, it raises a number of 
questions/concerns - some of which relate to how this draft fits with 
draft-ietf-lsr-dynamic-flooding.



For "DNR neighbors", although a circuit scoped LSP was received, the actual 
content is a traditional area scoped LSP.

 yes.

This presumably needs to be used internally (e.g., when running the Decision 
Process) in the same way as an area scoped LSP.

 yes.

So there are now two internal databases (traditional area LSPs and Circuit 
Scoped LSPs) which have to be used as if they are a single database?

 Yes that is correct

When a node sends a traditional CSNP does it include the LSPs it received as 
Circuit-Scoped LSPs?

If not, how is resynchronization achieved when necessary?

 yes. CSNPs includes circuit scoped LSPs.

Since you raised this point, I am thinking that we need a protocol extension to 
indicate that "this circuit scoped LSP" should be treated

In this special way.



Given the base work defined in draft-ietf-lsr-dynamic-flooding why is the use 
of Circuit Scoped LSPs required/useful?

 I am not sure which base work you are suggesting to use. Could you 
pls provide details?

The flooding algorithm as written in the draft breaks if circuit scoped 
flooding is not done.

Because, the distributed algorithm does not flood the LSP back in the direction 
from where it was originated.



[Les:] If you use the mechanisms defined in draft-ietf-lsr-dynamic-flooding 
there would be no need to use Circuit Scoped Flooding to send normal area 
scoped LSPs.

Each node in the topology would know to which neighbors it should have flooding 
enabled - either because you operate in centralized mode and the Area Leader 
distributes the flooding topology or because you operate in distributed mode 
and all nodes employ the same algorithm. (The latter assumes the algorithm 
supports deterministic choices for each node.) And when topology changes occur 
the mechanisms defined in 
https://tools.ietf.org/html/draft-ietf-lsr-dynamic-flooding-07#section-6.8<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-lsr-dynamic-flooding-07*section-6.8__;Iw!!NEt6yMaO-gk!VproGis8uUGmcl-cCplFMwuNceAo-3roUZT7ZdTlwvY7nJSszUo9AeWXymgguZIt$>
 assure that flooding continues to be reliable during the transition period 
(i.e., until a new flooding topology is calculated).



The fact t

Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

[Les Ginsberg (ginsberg)]

I support WG adoption.
This is another useful tool to support traffic engineering in real world 
deployments.

  Les


From: Lsr  On Behalf Of Acee Lindem (acee)
Sent: Tuesday, December 01, 2020 1:13 PM
To: lsr 
Subject: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) 
In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

This IP Flex Algorithm draft generated quite a bit of discussion on use cases 
and deployment prior to IETF 109 and there was generally support for WG 
adoption. This begins a two week WG adoption call. Please indicate your support 
or objection to WG adoption on this list prior to 12:00 AM UTC on December 
16th, 2020. Also, review comments are certainly welcome.
Thanks,
Acee


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

Re: [Lsr] Working Group Last Call for "YANG Module for IS-IS Reverse Metric" - draft-ietf-lsr-yang-isis-reverse-metric-01

[Les Ginsberg (ginsberg)]

I have reviewed the draft and support progressing this document.

   Les

From: Lsr  On Behalf Of Acee Lindem (acee)
Sent: Monday, November 30, 2020 10:15 AM
To: lsr@ietf.org
Subject: [Lsr] Working Group Last Call for "YANG Module for IS-IS Reverse 
Metric" - draft-ietf-lsr-yang-isis-reverse-metric-01

As stated as the IETF 109 LSR WG meeting, we feel the IS-IS reverse metric 
augmentation is ready for publication. This begins a two week last call for the 
subject draft. Please indicate your support or objection on this list prior to 
12:00 AM UTC on December 15th, 2020. Also, review comments are certainly 
welcome.
Thanks,
Acee

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

Re: [Lsr] New Version Notification for draft-white-lsr-distoptflood-00.txt

[Les Ginsberg (ginsberg)]

Draft authors -



I note that as the draft has evolved over the years a number of mechanisms have 
been removed (revised adjacency formation and auto tier detection) and the 
draft now focuses exclusively on flooding optimizations.

The draft now also references the recent work done in 
draft-ietf-lsr-dynamic-flooding.



A couple of things are not clear to me.



1)Is it your intent to use the mechanisms defined in 
draft-ietf-lsr-dynamic-flooding? I am specifically - though not exclusively - 
referring to how flooding adapts to topology changes.

It isn't clear from Section 3 whether you are actually intending to use the 
mechanisms defined in 
https://tools.ietf.org/html/draft-ietf-lsr-dynamic-flooding-07#section-6.8 or 
whether you simply want to use the Flooding sub-TLV defined in 
draft-ietf-lsr-dynamic-flooding to (optionally??) advertise your algorithm and 
all other procedures are specific to your algorithm.



2)The text at the end of 
https://tools.ietf.org/html/draft-white-lsr-distoptflood-00#section-2.1 states:



" LSPs transmitted to adjacent

   neighbors on the DNR list, however, MUST be transmitted using a

   circuit scope PDU as described in [RFC7356]."



Although this text is not new to this revision, it raises a number of 
questions/concerns - some of which relate to how this draft fits with 
draft-ietf-lsr-dynamic-flooding.



For "DNR neighbors", although a circuit scoped LSP was received, the actual 
content is a traditional area scoped LSP. This presumably needs to be used 
internally (e.g., when running the Decision Process) in the same way as an area 
scoped LSP. So there are now two internal databases (traditional area LSPs and 
Circuit Scoped LSPs) which have to be used as if they are a single database?

When a node sends a traditional CSNP does it include the LSPs it received as 
Circuit-Scoped LSPs?

If not, how is resynchronization achieved when necessary?

Given the base work defined in draft-ietf-lsr-dynamic-flooding why is the use 
of Circuit Scoped LSPs required/useful?



In general, it would be helpful to more completely define the relationship 
between this draft and draft-ietf-lsr-dynamic-flooding.



Thanx.



   Les





> -Original Message-

> From: Lsr  On Behalf Of Shraddha Hegde

> Sent: Sunday, November 29, 2020 8:36 PM

> To: lsr@ietf.org

> Subject: [Lsr] FW: New Version Notification for draft-white-lsr-distoptflood-

> 00.txt

>

> WG members,

>

>

> We have posted new version of the draft-white-lsr-distoptflood.

> This draft has been around for sometime by name openfabric and

> draft-white-distoptflood. The current revision has the name changed

> to reflect LSR WG.

> This draft describes a flood reduction mechanism in ISIS which is based on

> similar mechanisms implemented in OSPF for mobile-ad-hoc Networks

> ([RFC5449], [RFC5614], and [RFC7182]).

>

> Request working group to review and provide inputs.

>

> Rgds

> Shraddha

>

>

> Juniper Business Use Only

>

> -Original Message-

> From: internet-dra...@ietf.org 
> mailto:internet-dra...@ietf.org>>

> Sent: Monday, November 30, 2020 9:59 AM

> To: Shraddha Hegde mailto:shrad...@juniper.net>>; Russ 
> White mailto:r...@riw.us>>;

> Shawn Zandi mailto:sza...@linkedin.com>>

> Subject: New Version Notification for draft-white-lsr-distoptflood-00.txt

>

> [External Email. Be cautious of content]

>

>

> A new version of I-D, draft-white-lsr-distoptflood-00.txt

> has been successfully submitted by Shraddha Hegde and posted to the IETF

> repository.

>

> Name:   draft-white-lsr-distoptflood

> Revision:   00

> Title:  IS-IS Optimal Distributed Flooding for Dense Topologies

> Document date:  2020-11-29

> Group:  Individual Submission

> Pages:  12

> URL:

> https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-white-

> lsr-distoptflood-00.txt__;!!NEt6yMaO-

> gk!T5HX4Enn7jt3zwKoZBiA85YlysK0tdcELjk7Fy829PRSockmshBtqxzkSEm2FfjO

> $

> Status:

> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-white-

> 

Re: [Lsr] Early Allocation for IS-IS TTZ

[Les Ginsberg (ginsberg)]

FYI –

This has been approved by the DEs and IANA has updated the registry.

   Les



From: Lsr  On Behalf Of Les Ginsberg (ginsberg)
Sent: Wednesday, November 18, 2020 1:45 PM
To: Acee Lindem (acee) ; Huaimo Chen 
; Christian Hopps ; Hannes 
Gredler 
Cc: lsr@ietf.org; Alvaro Retana 
Subject: Re: [Lsr] Early Allocation for IS-IS TTZ

Request noted.

Chris/Hannes/myself will discuss and get back to you.

   Les

From: Acee Lindem (acee) mailto:a...@cisco.com>>
Sent: Wednesday, November 18, 2020 12:21 PM
To: Huaimo Chen mailto:huaimo.c...@futurewei.com>>; 
Christian Hopps mailto:cho...@chopps.org>>; Hannes Gredler 
mailto:han...@gredler.at>>; Les Ginsberg (ginsberg) 
mailto:ginsb...@cisco.com>>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>; Alvaro Retana 
mailto:aretana.i...@gmail.com>>
Subject: Re: Early Allocation for IS-IS TTZ

+LSR list and Alvaro for information.

I have no problems with this allocation. This needs to go to IS-IS designated 
experts (Chris, Les, Hannes).

Thanks,
Acee

From: Huaimo Chen mailto:huaimo.c...@futurewei.com>>
Date: Wednesday, November 18, 2020 at 2:34 PM
To: Acee Lindem mailto:a...@cisco.com>>, Christian Hopps 
mailto:cho...@chopps.org>>
Subject: Early Allocation for IS-IS TTZ

Hi Acee and Chris,

We would like to request an early allocation of "IS-IS TLV Codepoints" for 
IS-IS TTZ  https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-ttz/

 28 (suggested) - IS-IS Zone ID TLV

Thank you very much for your consideration.

Best Regards,
Huaimo
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Early Allocation for IS-IS TTZ

[Les Ginsberg (ginsberg)]

Request noted.

Chris/Hannes/myself will discuss and get back to you.

   Les

From: Acee Lindem (acee) 
Sent: Wednesday, November 18, 2020 12:21 PM
To: Huaimo Chen ; Christian Hopps 
; Hannes Gredler ; Les Ginsberg 
(ginsberg) 
Cc: lsr@ietf.org; Alvaro Retana 
Subject: Re: Early Allocation for IS-IS TTZ

+LSR list and Alvaro for information.

I have no problems with this allocation. This needs to go to IS-IS designated 
experts (Chris, Les, Hannes).

Thanks,
Acee

From: Huaimo Chen mailto:huaimo.c...@futurewei.com>>
Date: Wednesday, November 18, 2020 at 2:34 PM
To: Acee Lindem mailto:a...@cisco.com>>, Christian Hopps 
mailto:cho...@chopps.org>>
Subject: Early Allocation for IS-IS TTZ

Hi Acee and Chris,

We would like to request an early allocation of "IS-IS TLV Codepoints" for 
IS-IS TTZ  https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-ttz/

 28 (suggested) - IS-IS Zone ID TLV

Thank you very much for your consideration.

Best Regards,
Huaimo
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 11/16/2020)

[Les Ginsberg (ginsberg)]

Zhibo –

It is good of you to “keep me honest” as regards my past comments.

In reviewing the relevant material, the best I can say as regards my comments 
from 2 years ago is that they were made with insufficient diligence. Apologies 
for any resulting confusion.

https://www.rfc-editor.org/rfc/rfc7176.html#section-2.4 clearly indicates that 
the advertised value is dependent on the results of MTU-probe testing as 
specified in https://www.rfc-editor.org/rfc/rfc6325#section-4.3.2 .

Particularly relevant is the statement:

“o  MTU: This field is set to the largest successfully tested MTU size
  for this link or zero if it has not been tested, as specified in
  Section 4.3.2 of [RFC6325].”

So, as currently defined, IS-IS is not allowed to advertise a non-zero MTU 
value unless MTU-probes/acks have been exchanged.

https://www.rfc-editor.org/rfc/rfc7177#section-5 further clarifies that:

“The purpose of MTU testing is to ensure that the links used in the
   campus topology can pass TRILL IS-IS packets, particularly LSP PDUs,
   at the TRILL campus MTU.”

So the stated purpose of the TRILL definitions is NOT to provide assurances of 
data packet MTU, but more specifically to ensure that the IS-IS protocol can 
function correctly.

Could the MTU sub-TLV be repurposed to meet the requirements being discussed in 
the context of draft-zhu-idr-bgp-ls-path-mtu? Yes – I think that is possible - 
but it requires further  work.

draft-hu-lsr-isis-path-mtu was published over two years ago to define IS-IS 
extensions to advertise MTU. As you have noted, you received feedback from both 
Acee and myself which suggested that the TRILL defined MTU sub-TLV might be a 
better choice than the node property you had proposed. It seems based on that 
feedback you abandoned draft-hu-lsr-isis-path-mtu and focused only on 
draft-zhu-idr-bgp-ls-path-mtu. But as others have also noted, there is a gap 
regarding IGP support. OSPF has no ability to support MTU advertisement 
currently and – as this thread explains – even in IS-IS there is work to be 
done.

I would like to restate that I am – like others – supportive of this work – but 
I think WG adoption at this stage (in ANY WG) is premature.

   Les


From: Huzhibo 
Sent: Friday, November 13, 2020 7:20 PM
To: Les Ginsberg (ginsberg) ; Ketan Talaulikar (ketant) 
; Susan Hares ; 'Jeff Tantsura' 
; Stephane Litkowski (slitkows) ; 
i...@ietf.org; Acee Lindem (acee) 
Cc: lsr@ietf.org
Subject: 答复: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 
11/16/2020)

Hi Les, Acee:

Actually we have already discussed about this and reached agreements about two 
years ago. You may have forgotten. Please find the archives below.

https://mailarchive.ietf.org/arch/msg/lsr/C2bhd2ff2UJf4e_Gr-7j2W0g-SU/

I have followed your advice: "there already is a per link MTU sub-TLV defined 
by RFC 7176 ... in which case the existing sub-TLV is a perfect fit ...  IS-IS 
already has what is needed and therefore does not need any additional protocol 
extension". So we let our draft on ISIS extensions for MTU expired, i.e. 
draft-hu-lsr-isis-path-mtu. To be honest, I am a bit surprised when I saw your 
comments.

In this draft we focused on the extensions of BGP_LS for MTU only, which does 
not have to be feed by IGP LSDB. This draft has been discussed and revised a 
few rounds, based on the feedbacks both on ietf meetings and mail list, this 
document has good maturity to move forward.

Thanks
Zhibo


发件人: Idr [mailto:idr-boun...@ietf.org] 代表 Les Ginsberg (ginsberg)
发送时间: 2020年11月14日 7:58
收件人: Ketan Talaulikar (ketant) 
mailto:ketant=40cisco@dmarc.ietf.org>>; 
Susan Hares mailto:sha...@ndzh.com>>; 'Jeff Tantsura' 
mailto:jefftant.i...@gmail.com>>; 'Stephane Litkowski 
(slitkows)' 
mailto:slitkows=40cisco@dmarc.ietf.org>>;
 i...@ietf.org<mailto:i...@ietf.org>; 'Acee Lindem (acee)' 
mailto:acee=40cisco@dmarc.ietf.org>>
抄送: lsr@ietf.org<mailto:lsr@ietf.org>
主题: Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 
11/16/2020)

The points which Ketan has made regarding the use of MTU advertisements defined 
in RFC 7176 are very valid. Indeed, the contents of the sub-TLV defined in 
https://www.rfc-editor.org/rfc/rfc7176.html#section-2.4 depend upon the TRILL 
specific MTU-probe/MTU-ack procedures defined in 
https://www.rfc-editor.org/rfc/rfc6325#section-4.4.3. These procedures are not 
currently applicable to non-TRILL environments.

So, there are no existing IGP advertisements defined which can support the 
goals of this draft.

As Ketan has also indicated, there is no discussion in the draft of how a BGP 
only network (for example) could provide the information of interest.

From my perspective, WG adoption of this draft in ANY WG is premature.
This might be a useful functionality to have – but at the moment we simply have 
an idea with no definition of how to implement/deploy it.

So I therefore 

Re: [Lsr] [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 11/16/2020)

[Les Ginsberg (ginsberg)]

The points which Ketan has made regarding the use of MTU advertisements defined 
in RFC 7176 are very valid. Indeed, the contents of the sub-TLV defined in 
https://www.rfc-editor.org/rfc/rfc7176.html#section-2.4 depend upon the TRILL 
specific MTU-probe/MTU-ack procedures defined in 
https://www.rfc-editor.org/rfc/rfc6325#section-4.4.3. These procedures are not 
currently applicable to non-TRILL environments.

So, there are no existing IGP advertisements defined which can support the 
goals of this draft.

As Ketan has also indicated, there is no discussion in the draft of how a BGP 
only network (for example) could provide the information of interest.

From my perspective, WG adoption of this draft in ANY WG is premature.
This might be a useful functionality to have – but at the moment we simply have 
an idea with no definition of how to implement/deploy it.

So I therefore oppose WG adoption of this draft by IDR.

Continuing the discussion is certainly useful – and I would encourage the 
current authors to investigate and propose relevant mechanisms in all the 
protocols of interest in some future version of the draft.
At that point we could then have a far more meaningful WG adoption call.

   Les


From: Idr  On Behalf Of Ketan Talaulikar (ketant)
Sent: Friday, November 13, 2020 1:35 AM
To: Susan Hares ; 'Jeff Tantsura' ; 
'Stephane Litkowski (slitkows)' ; 
i...@ietf.org; 'Acee Lindem (acee)' 
Cc: lsr@ietf.org
Subject: Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 
11/16/2020)

Hi Authors,

I believe this work is useful and should be taken up. It has value in providing 
the link MTU as part of the topology information via BGP-LS. However, as 
pointed out by others on this thread, the draft should remain scoped to just 
that – i.e. providing link MTU information. The discussion related to Path MTU 
and applicability to SR networks are best left outside the scope of this 
standards track draft.

Hi Sue,

I would support the points made by Acee for not taking up this draft in IDR WG 
and instead doing this in LSR.

Besides the missing coverage for OSPFv2/v3, there are also issues with how this 
would work with ISIS. The reference to the ISIS Trill specification points to 
this TLV https://tools.ietf.org/html/rfc7176#section-2.4 – if you see, there is 
more here than just the MTU value. What is more critical is the ISIS procedures 
(in non-Trill deployments) on how this value is determined. Please do not mix 
the following :

The MTU sub-TLV is used to optionally announce the MTU of a link as
   specified in [RFC6325], Section 
4.2.4.4.

Are the authors trying to specify that these Trill procedures for testing MTU 
need to be adopted for regular ISIS deployments.

My take is that while the ISIS TLV defined for Trill may be re-used in normal 
ISIS deployments, its usage and procedures need to be specified. Copying the 
LSR WG so that I may be corrected if I am wrong here.

Coming to the point of BGP-only networks, the draft has zero text related to 
that scenario. Moreover, the procedures for BGP-LS advertisements in BGP only 
fabric need to be specified as a base. The 
https://datatracker.ietf.org/doc/draft-ketant-idr-bgp-ls-bgp-only-fabric/ was 
my attempt to specify those procedures and it would be great if the IDR WG 
could review and provide feedback to this document and consider for adoption so 
we can cover the BGP-only networks.

I would also like to offer support/help to the authors in adding the necessary 
OSPFv2/v3 support for the same in an LSR draft where we could tackle both the 
IGPs and BGP-LS encoding and procedures together.

Thanks,
Ketan

From: Idr mailto:idr-boun...@ietf.org>> On Behalf Of 
Susan Hares
Sent: 13 November 2020 00:20
To: 'Jeff Tantsura' mailto:jefftant.i...@gmail.com>>; 
'Stephane Litkowski (slitkows)' 
mailto:slitkows=40cisco@dmarc.ietf.org>>;
 i...@ietf.org; 'Acee Lindem (acee)' 
mailto:acee=40cisco@dmarc.ietf.org>>
Subject: Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 
11/16/2020)

Jeff and Authors of draft-zhu-idr-bgp-ls-path-mtu:

I do believe the authors agreed to renaming the draft.

Does the name:   draft-xxx-idr-bgp-ls-link-mtu work for
the authors and interested IDR participants.

As the end of 12 days of the 14 day WG LC, this draft appears
to have general consensus from the WG as a useful draft.

I plan to allow 2 more days of comment, but at this point
it appears the WG wishes to adopt this draft.

Here’s my understanding of the best way forward:

If LSR adopts a version of the draft, IDR will allow the
LSR WG to be the main source as long as cross-working
review occurs so the BGP-only function can be reviewed.

Please continue to comment on the draft and
the planned progression.

Cheers,  Sue

From: Jeff Tantsura [mailto:jefftant.i...@gmail.com]
Sent: Thursday, November 12, 2020 12:53 PM
To: Susan Hares; Stephane Litkowski 

Re: [Lsr] WG Adoption Call for "ISIS Extensions in Support of Inter-AS MPLS and GMPLS TE" - draft-chen-lsr-isis-rfc5316bis-02

[Les Ginsberg (ginsberg)]

This simple extension to RFC 5316 is analogous to the extension to RFC 4971 
defined in RFC 7981. As Acee indicated, this is needed to support operation in 
IPv6 only networks.

I support WG adoption as a co-author.
I would appreciate WG support so we can complete this necessary extension.

   Les


From: Lsr  On Behalf Of Acee Lindem (acee)
Sent: Friday, October 23, 2020 7:43 AM
To: lsr@ietf.org
Subject: [Lsr] WG Adoption Call for "ISIS Extensions in Support of Inter-AS 
MPLS and GMPLS TE" - draft-chen-lsr-isis-rfc5316bis-02

This is simple BIS update to RFC 5316 is required to support IS-IS Inter-AS TE 
in IPv6 only networks. The authors have asked for WG adoption.

This begins a two week LSR Working Group Adoption Poll for “ISIS Extensions in 
Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering” - 
draft-chen-lsr-isis-rfc5316bis-02. The poll will end at 12:00 AM UTC on 
November 7th, 2020. Please indicate your support of objection on this list 
prior to the end of the adoption poll.

Thanks,
Acee

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

Re: [Lsr] IPR Call for "ISIS Extensions in Support of Inter-AS MPLS and GMPLS TE" - draft-chen-lsr-isis-rfc5316bis-02

[Les Ginsberg (ginsberg)]

I am not aware of any relevant undisclosed IPR associated with the bis draft.

   Les


From: Acee Lindem (acee) 
Sent: Friday, October 23, 2020 7:50 AM
To: draft-chen-lsr-isis-rfc5316...@ietf.org
Cc: lsr@ietf.org
Subject: IPR Call for "ISIS Extensions in Support of Inter-AS MPLS and GMPLS 
TE" - draft-chen-lsr-isis-rfc5316bis-02

Hi Mach, Les, Stefano, Xiaodong,

Are you aware of any IPR associated with the subject draft.

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

Re: [Lsr] Rtg-Dir Last Call review of draft-ietf-lsr-flex-algo

[Les Ginsberg (ginsberg)]

Eric –

Always appreciate the time reviewers put in – so apologies if my response came 
off as an overreaction.

As you understood that OSPF addresses backwards compatibility by ignoring 
unknown TLVs I wanted to emphasize that IS-IS has the same policy.

As regards the section on backwards compatibility, Peter has already suggested 
some text that seems to do what you have suggested. I am sure you will let him 
know if it is adequate.

I do understand that the compatibility concerns have to do with networks where 
some nodes support the new functionality and some don’t. But I think the real 
deployment issue is not “compatibility” but that in order for algo specific 
forwarding to work you must have a connected sub-topology of routers that 
support the desired algo. I would not use the term “compatibility” to describe 
that – but if we understand each other then we can leave it at that.

   Les


From: Eric Gray 
Sent: Tuesday, October 20, 2020 6:39 PM
To: Les Ginsberg (ginsberg) ; rtg-...@ietf.org; 
lsr-cha...@ietf.org
Cc: rtg-...@ietf.org; lsr@ietf.org
Subject: RE: Rtg-Dir Last Call review of draft-ietf-lsr-flex-algo

Les,

  Thanks for your helpful feedback on my minor comments.

  I think you may have misunderstood my comments.

  I do not have concerns about backward compatibility with respect 
to the flex-algo ID.

  What I was making a minor comment on was the dismissive approach 
the draft takes with respect to concerns about backward compatibility.

  It simply says that this draft does not introduce any new 
backward compatibility issues – which, going back to when IDs used to say 
pretty much the same thing about Security, is often not quite good enough.

  I feel the draft would make a better RFC if it said just a bit 
more about why the new TLV(s) and Sub-TLVs do not introduce backward 
compatibility issues.  It could even summarize how the extensions in this draft 
are (or are not) impacted by deployment in an environment where not all routers 
are able to participate in any specific flex-algorithm.

  For example, your own statement about why it is not an issue with 
IS-IS would be a useful addition to the section on backward compatibility.

  Maybe you and others disagree that this is useful, and that’s 
fine with me.

  I am happy to take your word for it about configuration, though I 
suspect that you also missed the point I was making about that specific aspect 
of compatibility of newer nodes (that can participate in a flex-algorithm) with 
others (that cannot – likely including existing and deployed routers).

  This point is not very important, so the authors can address it 
any way they want (including doing nothing at all).

  I see these reviews as an opportunity to improve our work, and 
have no other personal investment in my comments.

--
Eric


From: Les Ginsberg (ginsberg) 
mailto:ginsberg=40cisco@dmarc.ietf.org>>
Sent: Friday, October 16, 2020 3:59 PM
To: Eric Gray mailto:eric.g...@ericsson.com>>; 
rtg-...@ietf.org<mailto:rtg-...@ietf.org>; 
lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>
Cc: rtg-...@ietf.org<mailto:rtg-...@ietf.org>; lsr@ietf.org<mailto:lsr@ietf.org>
Subject: RE: Rtg-Dir Last Call review of draft-ietf-lsr-flex-algo
Importance: High

Eric –

I will let the draft authors respond to the bulk of your comments. But in 
regards to your question/comment:

“I assume (but do not actually know) that a similar situation exists for the 
new ISIS FAD Sub-TLV of the existing TLV Type 242 - i.e. - ISIS presumably has 
well defined handling for sub-TLVs (of at least type 242) that are not 
recognized.  If so, than the new Sub-TLV types defined are also not an issue.”

Indeed, base behavior for the IS-IS protocol as defined in ISO 10589 is to 
ignore unrecognized TLVs - and this extends to unrecognized sub-TLVs as well. 
This is key to the ability to introduce the many extensions that have been 
defined by the plethora of IS-IS RFCs over the last 20+ years.
This point is further discussed in the recently published:

https://www.rfc-editor.org/rfc/rfc8918.html#name-handling-of-disallowed-tlvs<https://protect2.fireeye.com/v1/url?k=560d142b-08bccf4b-560d54b0-86e2237f51fb-24dfc414d340a7cc=1=7cda84da-f086-4e37-8611-0a5c60f9a87b=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc8918.html%23name-handling-of-disallowed-tlvs>

So I think your concerns about backwards compatibility are unwarranted. In 
particular the statement:

“[backwards compatibility] apparently relies on configuration of those routers 
that _do_ support the extensions to address this”

Is not correct.

   Les

From: rtg-dir mailto:rtg-dir-boun...@ietf.org>> On 
Behalf Of Eric Gray
Sent: Friday, October 16, 2020 11:49 AM
To: rtg-...@ietf.org<mailto:rtg-...@ietf.org>; 
lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>
Cc: rtg-..

Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

[Les Ginsberg (ginsberg)]

Aijun -

I am not going to continue these side discussions with you.

The primary purpose of the protocol extensions are as stated in the draft 
Introduction. This is analogous to the use cases for the equivalent extensions 
for IS-IS already approved in RFC 7794. We need the equivalent in OSPF.

You can show that you are listening to the concerns of WG members by removing 
the Appendices - in which case you have (I believe) broad support for moving 
the draft forward.
You can then write a separate draft to discuss other use cases and allow the WG 
to discuss those other use cases w/o preventing the extensions from being 
approved and deployed for the use cases which have already been demonstrated as 
useful by IS-IS.

If you remove the Appendices I can support the draft.
If you do not remove the Appendices I cannot support the draft.

Please discuss this with your co-authors and come to consensus on your next 
step.

   Les


> -Original Message-
> From: Aijun Wang 
> Sent: Monday, October 19, 2020 12:06 AM
> To: Les Ginsberg (ginsberg) ; 'Christian Hopps'
> 
> Cc: 'John E Drake' ; lsr-cha...@ietf.org; lsr@ietf.org;
> 'Jeff Tantsura' ; draft-ietf-lsr-ospf-prefix-
> origina...@ietf.org; lsr-...@ietf.org
> Subject: RE: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06
> 
> Hi, Les:
> 
> As I stated clearly before, the appendix described in the draft is not the new
> use case. It is the start point of this draft.
> Have you noticed that the introduction part is not the final usage of such
> protocol extension information?
> Certainly, we will not expand all the possible use cases in very detail, but
> putting some of them(some interesting, prominent use cases) in the
> appendix will not hamper the protocol extension itself.
> 
> If the statements/descriptions in the appendix are not correct, we can fix it,
> or remove it finally.  If not, why not let it be for reference to the user of 
> such
> protocol extension?
> For the body part of this draft, we are also welcome comments.
> 
> More replies inline below[WAJ]
> 
> Best Regards
> 
> Aijun Wang
> China Telecom
> 
> -----Original Message-
> From: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] On Behalf Of Les
> Ginsberg (ginsberg)
> Sent: Monday, October 19, 2020 2:15 PM
> To: Aijun Wang ; 'Christian Hopps'
> 
> Cc: 'John E Drake' ; lsr-cha...@ietf.org; 'Les Ginsberg
> (ginsberg)' ; lsr@ietf.org; 'Jeff
> Tantsura' ; draft-ietf-lsr-ospf-prefix-
> origina...@ietf.org; lsr-...@ietf.org
> Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06
> 
> Aijun -
> 
> The "use case" for the protocol extensions is clearly stated in the
> Introduction:
> 
> "The primary use case for the extensions proposed in this document is
>to be able to identify the originator of the prefix in the network.
>In cases where multiple prefixes are advertised by a given router, it
>is also useful to be able to associate all these prefixes with a
>single router even when prefixes are advertised outside of the area
>in which they originated.  It also helps to determine when the same
>prefix is being originated by multiple routers across areas."
> 
> This is equivalent to language in RFC 7794 which defines the analogous
> extensions for IS-IS.
> 
> Everything you have in the Appendix is not related to the primary use case -
> and is fact a use case which many of us have objected to.
> [WAJ] Very glad to know the false statements in the appendix.
> 
> You are entitled to write another draft advocating for your new use case if
> you wish, but requiring that the protocol extensions in support of the
> primary use case not go forward without your new use case is - as Chris has
> stated very clearly - holding approval of the protocol extensions hostage to
> your new use case.
> [WAJ] It is not new use case. As I sated before, I am open to this part, but
> should on the conditions that the statements in this part are incorrect.
> 
> I am asking you (yet again) not to do this.
> 
> I cannot support the document moving forward with the content in the
> Appendices included.
> [WAJ] Would like to hear more technical analysis.
> 
>Les
> 
> 
> > -Original Message-
> > From: Lsr  On Behalf Of Aijun Wang
> > Sent: Sunday, October 18, 2020 7:08 PM
> > To: 'Christian Hopps' 
> > Cc: 'John E Drake' ; lsr-cha...@ietf.org; 'Les
> > Ginsberg (ginsberg)' ;
> > lsr@ietf.org; 'Jeff Tantsura' ;
> > draft-ietf-lsr-ospf-prefix- origina...@ietf.org; lsr-...@ietf.org
> > Subject: Re: [Lsr] WG Last Call
> > draft-ietf-lsr-ospf-prefix-originator-06
> >
> > Hi, Chris:
> >
> > I think we have "p

Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

[Les Ginsberg (ginsberg)]

Aijun -

The "use case" for the protocol extensions is clearly stated in the 
Introduction:

"The primary use case for the extensions proposed in this document is
   to be able to identify the originator of the prefix in the network.
   In cases where multiple prefixes are advertised by a given router, it
   is also useful to be able to associate all these prefixes with a
   single router even when prefixes are advertised outside of the area
   in which they originated.  It also helps to determine when the same
   prefix is being originated by multiple routers across areas."

This is equivalent to language in RFC 7794 which defines the analogous 
extensions for IS-IS.

Everything you have in the Appendix is not related to the primary use case - 
and is fact a use case which many of us have objected to.

You are entitled to write another draft advocating for your new use case if you 
wish, but requiring that the protocol extensions in support of the primary use 
case not go forward without your new use case is - as Chris has stated very 
clearly - holding approval of the protocol extensions hostage to your new use 
case.

I am asking you (yet again) not to do this.

I cannot support the document moving forward with the content in the Appendices 
included.

   Les


> -Original Message-
> From: Lsr  On Behalf Of Aijun Wang
> Sent: Sunday, October 18, 2020 7:08 PM
> To: 'Christian Hopps' 
> Cc: 'John E Drake' ; lsr-cha...@ietf.org; 'Les Ginsberg
> (ginsberg)' ; lsr@ietf.org; 'Jeff
> Tantsura' ; draft-ietf-lsr-ospf-prefix-
> origina...@ietf.org; lsr-...@ietf.org
> Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06
> 
> Hi, Chris:
> 
> I think we have "put the cart before the horse". For protocol extension draft,
> the origin is the use case.
> And I think we will not expand OSPF protocol, just because it lack something
> as compared with ISIS, right?
> 
> As I stated before, the use case in current appendix is the main motivation of
> this draft, you can see this in main body of the earlier version of this
> draft(from version 0 to version 5).
> The reason that we move this part to the appendix, as that you said, is to let
> person focus on the protocol extension itself.
> 
> Moving this part to appendix is acceptable, but removing it from the draft 
> will
> erase the origin of this document.
> Is it reasonable that one document discusses the "origin"(of the prefix), 
> can't
> keep its origin?
> 
> More replies inline below[WAJ].
> 
> Best Regards
> 
> Aijun Wang
> China Telecom
> 
> 
> -Original Message-
> From: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] On Behalf Of
> Christian Hopps
> Sent: Friday, October 16, 2020 10:47 PM
> To: 王爱俊 
> Cc: John E Drake ; Christian Hopps
> ; lsr-cha...@ietf.org; Les Ginsberg (ginsberg)
> ; lsr@ietf.org; Jeff Tantsura
> ; draft-ietf-lsr-ospf-prefix-origina...@ietf.org; 
> lsr-
> a...@ietf.org
> Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06
> 
> Isn't this just adding an analogous extension that already exists in RFC7794?
> [WAJ] No. RFC7794 is just one example that to illustrate, as the companion
> IGP protocol, OSPF can also accomplish this. And, actually, there are
> differences consideration in this draft for the protocol extension.
> 
> I don't think we need to do a lot of convincing at this point. I agree with 
> Les, if
> you want to talk about use cases (especially ones that are controversial!)
> then the correct place for that is in a new informative draft.
> [WAJ] we have discussed the use case before and state the discussion
> results at the appendix part. We will not emphasis and expand the use case
> more. If one does not agree the statement of this appendix, we can discuss
> online or offline. We just need to make the statement in appendix is correct.
> 
> Otherwise, especially if the cases are controversial, this can be seen as 
> doing
> an "end-run" to avoid the debate b/c people want the extension, but maybe
> don't agree with your use case.
> [WAJ] One should point out which statement in the appendix is
> controversial, we can correct it. This use case is the origin of this draft, 
> not
> the results.
> 
> Legislators do this sometimes adding things they want personally to popular
> bills, that other people may not want, but since people want the main bill
> they vote for it anyway, in the US it's called "adding pork" or "pork barrel
> politics". :)
> [WAJ] The appendix is not added later, but exist at the first beginning. This 
> is
> the origin of the bills.
> 
> Thanks,
> Chris.
> 
> > On Oct 16, 2020, at 10:37 AM, 王爱俊 
> wrote:
> >
> >

Re: [Lsr] Rtg-Dir Last Call review of draft-ietf-lsr-flex-algo

[Les Ginsberg (ginsberg)]

Eric –

I will let the draft authors respond to the bulk of your comments. But in 
regards to your question/comment:

“I assume (but do not actually know) that a similar situation exists for the 
new ISIS FAD Sub-TLV of the existing TLV Type 242 - i.e. - ISIS presumably has 
well defined handling for sub-TLVs (of at least type 242) that are not 
recognized.  If so, than the new Sub-TLV types defined are also not an issue.”

Indeed, base behavior for the IS-IS protocol as defined in ISO 10589 is to 
ignore unrecognized TLVs - and this extends to unrecognized sub-TLVs as well. 
This is key to the ability to introduce the many extensions that have been 
defined by the plethora of IS-IS RFCs over the last 20+ years.
This point is further discussed in the recently published:

https://www.rfc-editor.org/rfc/rfc8918.html#name-handling-of-disallowed-tlvs

So I think your concerns about backwards compatibility are unwarranted. In 
particular the statement:

“[backwards compatibility] apparently relies on configuration of those routers 
that _do_ support the extensions to address this”

Is not correct.

   Les

From: rtg-dir  On Behalf Of Eric Gray
Sent: Friday, October 16, 2020 11:49 AM
To: rtg-...@ietf.org; lsr-cha...@ietf.org
Cc: rtg-...@ietf.org; lsr@ietf.org
Subject: [RTG-DIR] Rtg-Dir Last Call review of draft-ietf-lsr-flex-algo


Hello,

I have been selected as the Routing Directorate reviewer for this draft. The 
Routing Directorate seeks to review all routing or routing-related drafts as 
they pass through IETF last call and IESG review, and sometimes on special 
request. The purpose of the review is to provide assistance to the Routing ADs. 
For more information about the Routing Directorate, please see 
https://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir.



Although these comments are primarily for the use of the Routing ADs, it would 
be helpful if you could consider them along with any other IETF Last Call 
comments that you receive, and strive to resolve them through discussion or by 
updating the draft.



Document: draft-ietf-lsr-flex-algo-12.txt



Reviewer: Eric Gray

Review Date: 16 October, 2020

IETF LC End Date: Unknown

Intended Status: Standards Track



Summary:

This document is well organized, relatively easy to read, and probably ready 
for publication, but has one potential minor issue and a very small number of 
NITs that might be considered prior to publication.



Major Issues:

None



Minor Issues:

The statement in section 15 (Backward Compatibility) - "This extension brings 
no new backward compatibility issues" - seems somewhat flip.



I suspect that a tiny bit of analysis would not hurt.



The extensions in this draft are clearly intended to work in an environment 
where routers that _do_not_ support these extensions are also deployed, but 
apparently relies on configuration of those routers that _do_ support the 
extensions to address this.



That seems correct.



From my reading of the draft (which I have not closely followed for its entire 
development), while it introduces at least one new TLV, the OSPF routing 
protocol has well defined handling for TLVs that are not understood - hence the 
introduction of one or more new TLVs should not present a problem in OSPF.



Obviously Sub-TLVs of the new OSPF TLV type will not introduce compatibility 
issues.



I assume (but do not actually know) that a similar situation exists for the new 
ISIS FAD Sub-TLV of the existing TLV Type 242 - i.e. - ISIS presumably has well 
defined handling for sub-TLVs (of at least type 242) that are not recognized.  
If so, than the new Sub-TLV types defined are also not an issue.



Shouldn't this section say something along these lines?  I suspect that it 
would be more helpful if verifying the content of the "considerations" sections 
were not left as an exercise for the reader.  



NITs:

In the Introduction, the phrase "must often be replaced" seems very slightly 
problematic (especially given this is a standards track RFC wanna-be).  Would 
it be better to say "is often replaced" instead?



In section 17.1.2 and 17.2 - '... a "Interior Gateway ...' should probably be 
'... an "Interior Gateway ..." in both cases.



--

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

Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

[Les Ginsberg (ginsberg)]

> -Original Message-
> From: Lsr  On Behalf Of Aijun Wang
> Sent: Friday, October 16, 2020 1:48 AM
> To: Les Ginsberg (ginsberg) 
> Cc: John E Drake ; Christian Hopps
> ; lsr-cha...@ietf.org; lsr@ietf.org; Jeff Tantsura
> ; draft-ietf-lsr-ospf-prefix-origina...@ietf.org; 
> lsr-
> a...@ietf.org
> Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06
> 
> Hi, Les and experts in LSR:
> 
> I am open to the removal of the this appendix to forward this draft.

[Les:] Great!! Please do so.

   Les


> But as stated in previous mail, providing this can assist the user/reader of 
> the
> draft. We often encounter the questions in the mail list that what the usage
> of protocol/bit definition in some drafts.
> 
> Actually, we did not expand the discussion of this part in this draft. The
> description of this part is very concise.
> 
> If you insist this, I can update the draft in recent days, together with other
> comments on this draft.
> 
> Other comments are welcome also!
> 
> Aijun Wang
> China Telecom
> 
> > On Oct 16, 2020, at 13:51, Les Ginsberg (ginsberg) 
> wrote:
> >
> > Aijun -
> >
> > The point I am making is very focused.
> >
> > This draft is defining a protocol extension. As such it is necessary that 
> > this
> be Standards track as adhering to the normative statements in the draft are
> necessary for interoperability.
> >
> > What is discussed in the Appendix is a use case. It is not normative and
> there are strong opinions on both sides as to whether this is an appropriate
> use case or not.
> > In the context of this draft, I have no interest in trying to resolve our
> difference of opinion on this use case. I simply want the protocol extension
> to move forward so that we have another tool available.
> >
> > If you want to write a draft on the use case discussed in the Appendix
> please feel free to do so. That draft may very well not be normative -
> Informational or BCP may be more appropriate - because it will be discussing
> a deployment scenario and a proposal to use defined protocol extensions as
> one way to solve problems in that deployment scenario. Such a draft might
> also be more appropriate in another WG (e.g., TEAS). The merits of using
> prefix advertisements to build a topology could then be discussed on its own.
> >
> > Please do not try to avoid having a full discussion of the merits of using
> prefix advertisements to derive topology by adding it to a draft that is (and
> should be) focused on simple protocol extensions.
> >
> > Thanx.
> >
> >   Les
> >
> >
> >> -Original Message-
> >> From: Aijun Wang 
> >> Sent: Thursday, October 15, 2020 6:51 PM
> >> To: 'Jeff Tantsura' ; 'John E Drake'
> >> 
> >> Cc: 'Christian Hopps' ; lsr-cha...@ietf.org; Les
> Ginsberg
> >> (ginsberg) ; lsr@ietf.org; lsr-...@ietf.org; draft-
> ietf-
> >> lsr-ospf-prefix-origina...@ietf.org
> >> Subject: RE: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06
> >>
> >> Hi, Les, John and Jeff:
> >>
> >> Let's reply you all together.
> >> In my POV, The standard document should not define solely the protocol
> >> extension, but their usages in the network deployment. As I known,
> almost
> >> all the IETF documents following this style.
> >> And, before adopting one work, we have often intense discussion for
> what's
> >> their usages.
> >> Such discussion in the mail list and statements in the doc
> 
> ___
> 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] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

[Les Ginsberg (ginsberg)]

Aijun -

The point I am making is very focused.

This draft is defining a protocol extension. As such it is necessary that this 
be Standards track as adhering to the normative statements in the draft are 
necessary for interoperability.

What is discussed in the Appendix is a use case. It is not normative and there 
are strong opinions on both sides as to whether this is an appropriate use case 
or not.
In the context of this draft, I have no interest in trying to resolve our 
difference of opinion on this use case. I simply want the protocol extension to 
move forward so that we have another tool available.

If you want to write a draft on the use case discussed in the Appendix please 
feel free to do so. That draft may very well not be normative - Informational 
or BCP may be more appropriate - because it will be discussing a deployment 
scenario and a proposal to use defined protocol extensions as one way to solve 
problems in that deployment scenario. Such a draft might also be more 
appropriate in another WG (e.g., TEAS). The merits of using prefix 
advertisements to build a topology could then be discussed on its own. 

Please do not try to avoid having a full discussion of the merits of using 
prefix advertisements to derive topology by adding it to a draft that is (and 
should be) focused on simple protocol extensions.

Thanx.

   Les


> -Original Message-
> From: Aijun Wang 
> Sent: Thursday, October 15, 2020 6:51 PM
> To: 'Jeff Tantsura' ; 'John E Drake'
> 
> Cc: 'Christian Hopps' ; lsr-cha...@ietf.org; Les Ginsberg
> (ginsberg) ; lsr@ietf.org; lsr-...@ietf.org; draft-ietf-
> lsr-ospf-prefix-origina...@ietf.org
> Subject: RE: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06
> 
> Hi, Les, John and Jeff:
> 
> Let's reply you all together.
> In my POV, The standard document should not define solely the protocol
> extension, but their usages in the network deployment. As I known, almost
> all the IETF documents following this style.
> And, before adopting one work, we have often intense discussion for what's
> their usages.
> Such discussion in the mail list and statements in the document can certainly
> assist the reader/user of the document get the essence of the standard, and
> follow them unambiguously.
> 
> Regarding the contents of appendices, as stated in the section, "The
> Appendix A heuristic to rebuild the topology can normally be used if all links
> are numbered." I think this can apply almost most of the operator's network,
> and facilitate the inter-area TE path calculation for central controller, or 
> even
> for the head-end router that located in one area that different from the tail-
> end router.
> 
> Keeping the contents of appendices does not have the negative impact of
> the protocol extension, it is just one reference for the usage of this
> extension.
> One can select not refer to it, if their networks are deployed with large
> amount of unnumbered links. But for others, the heuristic applies.
> 
> Best Regards
> 
> Aijun Wang
> China Telecom
> 
> 
> 
> -Original Message-
> From: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] On Behalf Of Jeff
> Tantsura
> Sent: Friday, October 16, 2020 5:28 AM
> To: John E Drake 
> Cc: Christian Hopps ; lsr-cha...@ietf.org; Les Ginsberg
> (ginsberg) ; lsr@ietf.org; lsr-
> a...@ietf.org; draft-ietf-lsr-ospf-prefix-origina...@ietf.org
> Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06
> 
> +1
> 
> Regards,
> Jeff
> 
> > On Oct 15, 2020, at 11:33, John E Drake
>  wrote:
> >
> > Hi,
> >
> > I agree with Les.  This is a simple protocol extension for a specific 
> > purpose
> and there is no reason to include speculation about its use for other
> purposes, particularly when it is inherently not suited for them.
> >
> > Yours Irrespectively,
> >
> > John
> >
> >
> > Juniper Business Use Only
> >
> >> -Original Message-
> >> From: Lsr  On Behalf Of Les Ginsberg (ginsberg)
> >> Sent: Thursday, October 15, 2020 12:33 PM
> >> To: Christian Hopps ; lsr@ietf.org
> >> Cc: lsr-cha...@ietf.org; lsr-...@ietf.org;
> >> draft-ietf-lsr-ospf-prefix- origina...@ietf.org
> >> Subject: Re: [Lsr] WG Last Call
> >> draft-ietf-lsr-ospf-prefix-originator-06
> >>
> >> [External Email. Be cautious of content]
> >>
> >>
> >> I support moving this document forward.
> >> Similar functionality in IS-IS has proved useful.
> >>
> >> I would however like to repeat comments I made earlier in the review
> >> of this document.
> >> The content of the Appendices should be removed.
>

Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

[Les Ginsberg (ginsberg)]

I support moving this document forward.
Similar functionality in IS-IS has proved useful.

I would however like to repeat comments I made earlier in the review of this 
document.
The content of the Appendices should be removed.
The Appendices define and discuss deriving topology information from prefix 
advertisements - which is flawed and should not be done.
Perhaps more relevant, the purpose of the document is to define  protocol 
extensions supporting advertisement of the originators of a prefix 
advertisement. There is no need to discuss how this mechanism might be used to 
build topology information.
This document should confine itself to defining the protocol extensions - 
similar the RFC 7794.

If the authors do not agree to do this, I would encourage this point to be 
discussed during IESG review.

   Les

> -Original Message-
> From: Lsr  On Behalf Of Christian Hopps
> Sent: Wednesday, October 14, 2020 11:15 PM
> To: lsr@ietf.org
> Cc: draft-ietf-lsr-ospf-prefix-origina...@ietf.org; lsr-cha...@ietf.org; lsr-
> a...@ietf.org; Christian Hopps 
> Subject: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06
> 
> This begins a 2 week WG Last Call, ending after Oct 29th, 2020, for:
> 
>   https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-prefix-originator/
> 
> The following IPR has been filed https://datatracker.ietf.org/ipr/3448/
> 
> Authors,
> 
>   Please indicate to the list, your knowledge of any other IPR related to this
> work.
> 
> Thanks,
> Chris.

___
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] New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt

[Les Ginsberg (ginsberg)]

Ron -

Interesting proposal.

A few mundane - but I think still important - comments.

New IS-IS TLVs


There is no need to have two TLVs for each address-family - one for MTID #0 and 
one for all non-zero MTIDs. One TLV/AF will suffice.
The reason we have separate TLVs today is because MT (RFC 5120)  came along 
after TLV 135/236 had been defined/deployed.
Since you have a greenfield here you can simply have one TLV/AF and allow all 
MTIDs (including 0).

MTID is a 16 bit field with 4 reserved bits and 12 bits used for MTID value.  
(I believe someone else pointed this out as well.)
See RFC 5120.

You should specify that the new TLVs inherit the sub-TLV space defined in 
https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-135-235-236-237
 

The U-bit
-

I appreciate that there is precedence for calling this the U-bit based on RFC 
5308 - but I would prefer that you call it the D-bit.
Regardless of name, it MUST be consistent with existing usage - meaning it is 
set when the prefix is leaked downwards. Currently your text says:

"U (1 bit): Set indicates up.  Clear indicates down."

This needs to be reversed.

Constraints
---

I think you need to speak to various constraints including (but not limited to):

1)Algorithm is limited to flex-algo values (128-255)

I don't understand why Section 6 (main part - not the sub-sections) is there. 
What relevance do non-flex-algos have to this draft??

I also think the new sub-TLV would be better named "Native Flex-Algo Algorithm 
Sub-TLV".
Unless you are proposing to use this sub-TLV in ways not related to flex-algo - 
in which case I think you need to provide some explanation of the use case for 
this.

2)How to handle advertisement of same algo both in the new Algorithm sub-TLV 
and the existing SR Algorithm sub-TLV (prefer SR??)
Note that legacy routers may understand SR Algorithm Sub-TLV but not the new 
one.

   Les



> -Original Message-
> From: Lsr  On Behalf Of Ron Bonica
> Sent: Tuesday, September 29, 2020 6:38 AM
> To: lsr@ietf.org
> Subject: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-
> 00.txt
> 
> 
> Please review and comment
> 
>Ron
> 
> 
> 
> Juniper Business Use Only
> 
> > -Original Message-
> > From: internet-dra...@ietf.org 
> > Sent: Tuesday, September 29, 2020 9:36 AM
> > To: Parag Kaneriya ; Shraddha Hegde
> > ; Ron Bonica ; Rajesh M
> > ; William Britto A J 
> > 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-
> > lsr-ip-flexalgo-00.txt__;!!NEt6yMaO-gk!X7PVDP-
> > FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck80Zbjoij$
> > Status:
> > 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-
> > bonica-lsr-ip-flexalgo__;!!NEt6yMaO-gk!X7PVDP-
> > FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck82w_6CyU$
> > Htmlized:
> 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.
> >
> > The IETF Secretariat
> >
> ___
> 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] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

[Les Ginsberg (ginsberg)]

In support of what Tony has said, I think any comparison between what RIFT is 
doing and what is proposed in this draft is inappropriate.

RIFT is able to determine what destinations exist in the network but are not 
reachable via a certain subset of the topology – and then generate negative 
advertisements appropriately. There is also full determinism in knowing when 
the negative advertisement should be removed.

draft-wang-lsr-prefix-unreachable-announcement by contrast tries to provide an 
advertisement for a destination that no longer exists. This leads to the lack 
of determinism which necessitates arbitrary timers and creates problems for 
nodes who connect to the network after the disappearance of the destination.

Not comparable at all IMO…

   Les

From: Lsr  On Behalf Of Tony Przygienda
Sent: Friday, September 04, 2020 11:12 AM
To: Aijun Wang 
Cc: Gyan Mishra ; Robert Raszuk ; 
Huzhibo ; Aijun Wang ; Peter 
Psenak ; lsr ; Acee Lindem 
(acee) ; Xiaoyaqun 
Subject: Re: [Lsr] New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt

I read the draft since the longish thread triggered my interest. As Peter said 
very thin ice walking with magic soft-state-timers for (to me) entirely unclear 
benefit and lots of interesting questions completely omitted like e.g. what 
will happen if a mix of old and new routers are in the network.

RIFT works completely differently BTW (and I don't think we _also_ noticed the 
problem, AFAIK RIFT is the first protocol that defined the concept of at least 
negative disaggregation to deal with black-hole avoidance in presence of 
summaries). RIFT defines precisely how negative disaggregation state is 
transitively propagated (if necessary) and next-hop resolved via recursive 
inheritance to provide black-hole and loop free routing in case of links 
failures on IP fabrics. No soft-timers or undescribed magic there. However, to 
do what RIFT is doing a sense of direction on the graph is needed (this is 
relatively easy on semi-lattice RIFT supports but would precondition uniform 
topological sorting on generic graphs, probably ending up in RPL type of 
solutions [which still need a direction indicator on arc to work and would take 
out a lot of links out of the topology possibly {but Pascal is better to judge 
that}]).

-- tony

On Mon, Aug 24, 2020 at 11:11 AM Aijun Wang 
mailto:wangai...@tsinghua.org.cn>> wrote:
Hi, Gyan:

Sorry for replying you so late.
You are right about the summary address behavior, but the summary address is 
configured by manually, and if one of the specific prefix within this summary 
range is down, the black hole(route to this specific prefix) will be formed.  
PUA mechanism just want to amend this.
Glad to know Rift has also noticed such issues.  In OSPF/ISIS, such problem 
needs also be solved.

If you are interested this topic, welcome to join us to the solution.


Best Regards

Aijun Wang
China Telecom

From: lsr-boun...@ietf.org 
[mailto:lsr-boun...@ietf.org] On Behalf Of Gyan 
Mishra
Sent: Thursday, August 6, 2020 4:44 PM
To: Aijun Wang mailto:wangai...@tsinghua.org.cn>>
Cc: Peter Psenak 
mailto:40cisco@dmarc.ietf.org>>; Robert 
Raszuk mailto:rob...@raszuk.net>>; Huzhibo 
mailto:huzh...@huawei.com>>; Aijun Wang 
mailto:wang...@chinatelecom.cn>>; lsr 
mailto:lsr@ietf.org>>; Acee Lindem (acee) 
mailto:a...@cisco.com>>; Xiaoyaqun 
mailto:xiaoya...@huawei.com>>
Subject: Re: [Lsr] New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt

Hi Aijun and authors

I am catching up with this thread after reading through this draft.

I understand the concept that we are trying to send a PUA advertisement which 
sounds similar to Rift Negative Disaggregation prefix now with a  null setting 
when a longer match component prefix that is part of a summary range is down to 
detect prefix down conditions with longer match component prefixes that are 
part of a summary.

Basically how summarization works with both OSPF and ISIS is that at minimum a 
single longer match within the defined IA summary range must exist for the IA 
summary to be sent.  So the summary is sent conditionally similar to a BGP 
conditional advertisement or even a ospf default originate which requires a 
default in the RIB to exist before the advertisement is sent.  A good example 
of non conditional analogy with BGP if you have a null0 static for a summary 
for an exact match BGP advertisement the prefix is always advertised no matter 
what even if no component prefixes exist.  This can result in black hole 
routing. BGP has conditional feature to conditionally advertisement based on 
existence of a route advertisement of downstream neighbor in the BGP RIB.  So 
with ospf and Isis the summary is in fact conditional similar to a BGP 
conditional advertisement and in the example given in the draft in section 3.1 
when node T2 is down and pt2 becomes unreachable and let’s 

Re: [Lsr] I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt

[Les Ginsberg (ginsberg)]

Tony –

The statement “the … Prefix SID does NOT have the semantics that we want and 
causes deleterious side-effects” is FALSE.

Other than  that,  we understand each other and we disagree.
You have my input.

There is an alternative here:

Given that there isn’t any defined use case for the Area Prefix/SID, you could 
choose to defer its definition until such time as a use case arises.
I agree that the concept is appealing and is potentially useful – which is why 
I thought it worthwhile to invest time in defining it. But a conservative 
approach might be to wait until we actually need it before defining it. It is 
always possible that when the use case arises we will find that there are some 
other issues which have been overlooked which might alter how this would be 
advertised.

   Les


From: Tony Li  On Behalf Of tony...@tony.li
Sent: Thursday, August 27, 2020 8:19 AM
To: Les Ginsberg (ginsberg) 
Cc: lsr@ietf.org
Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt


Les,


[Les:] Thanx for clarifying this. A careful reading of the draft supports what 
you say, but as this point could be easily overlooked it might be worth 
emphasizing this in the draft.


Noted and enhanced.

We do NOT require that the Area Leader candidates have identical 
configurations.  In fact, if there is a configuration change, it may be 
beneficial to configure one candidate differently and then raise its priority.  
It’s a simple way of effecting an area-wide configuration change.

[Les:] Section 4.2 states:

“For consistency, all Area Leader candidates SHOULD be configured with
   the same Proxy System Id, Proxy Hostname, and any other information
   that may be inserted into the Proxy LSP.”

I would agree that the flexibility to easily propagate a config change to be 
reflected in the Proxy LSP content requires relaxation of this rule.


This is exactly why it says SHOULD and not MUST.



We want outside nodes to install forwarding entries on the Prefix SID.  This is 
entirely backward compatible.  How is that inappropriate?

[Les:] Installation of forwarding entries today is based on Prefix Reachability 
advertisements. You are proposing to extend that by requiring a forwarding 
entry to be installed based on the context of the Area Proxy TLV.
I would prefer that you not introduce this.


I am well aware of that.

Perhaps it would help if I tell you that I am 100% impervious to Persuasion by 
Repetition.  I understand what you want. I disagree with you on the tradeoffs.



In addition, since there will also be a Prefix Reachability Advertisement for 
the Area Prefix in the Proxy LSP, the IERs will have two sources of information 
for the SID associated with the Area prefix (Area SID sub-TLV from Area leader 
L2 LSP and Prefix Reachability advertisement in the Proxy LSP). Which 
introduces the possibility of inconsistency.


No, since the IERs are supposed to ignore the Proxy LSP for any purpose other 
than flooding. I’m adding an explicit statement to this effect. The only source 
of truth is the Area Proxy TLV generated by the Area Leader.


The existing ones do not have the required semantics.

[Les:] That’s wasn’t the point.



That is the entire point.  You insist that we advertise the Area SID as a 
Prefix SID in addition to the a prefix in the Area Proxy TLV.  The additional 
Prefix SID does NOT have the semantics that we want and causes deleterious 
side-effects.




The point was that when a SID is advertised in prefix reachability it is used 
in preference to advertisements in other TLVs.


Except when it is part of the Proxy LSP, in which case we want the Inside 
Routers to ignore it.  We do NOT want Inside Routers creating forwarding state 
or SPF state for every prefix and SID in the Proxy LSP.



[Les:] The semantics you require are functionally equivalent to anycast 
behavior – which is supported already.


Please point me to anycast semantics that will ONLY be selected by IERs.
[Les:] You have specified that only IERs and Outside Routers process Proxy LSP 
content.  So why do you ask this question?


You’re asking me to use another mechanism.  I don’t see how it applies.  I’m 
open to you educating me.

IERs do NOT process Proxy LSP content other than to flood it.

Tony


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

Re: [Lsr] I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt

[Les Ginsberg (ginsberg)]

Tony –

Inline.

From: Tony Li  On Behalf Of tony...@tony.li
Sent: Wednesday, August 26, 2020 8:56 PM
To: Les Ginsberg (ginsberg) 
Cc: lsr@ietf.org
Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt


Hi Les,

[Les:] Any one of the IERs can be elected Area Leader, therefore all of them 
have to be configured with the Area Prefix and associated SID.


The Area Leader may not be an IER.  In fact, in an important use case for us, 
the area is a leaf-spine topology.  The Area Leader is one of the spines.  The 
leaves are the edge routers.  For resource reasons, we do NOT want the Area 
Leader to be a leaf.

[Les:] Thanx for clarifying this. A careful reading of the draft supports what 
you say, but as this point could be easily overlooked it might be worth 
emphasizing this in the draft.
In any case this isn’t significant for the points we are debating here.

We do NOT require that the Area Leader candidates have identical 
configurations.  In fact, if there is a configuration change, it may be 
beneficial to configure one candidate differently and then raise its priority.  
It’s a simple way of effecting an area-wide configuration change.

[Les:] Section 4.2 states:

“For consistency, all Area Leader candidates SHOULD be configured with
   the same Proxy System Id, Proxy Hostname, and any other information
   that may be inserted into the Proxy LSP.”

I would agree that the flexibility to easily propagate a config change to be 
reflected in the Proxy LSP content requires relaxation of this rule.
But again, not significant for the points we are debating here.


Perhaps you are allowing that each IER could choose a different Area 
Prefix/SID. Not sure why you would want to do that – but even if you did, the 
behavior of the winning prefix/SID is analogous to an anycast address.
The difference here is that the advertisement of the Prefix Reachability 
associated with the area prefix is within the Proxy LSP – which appears to OERs 
as if it was originated by all of the IERs i.e., the set of IERs appears as a 
single node to the OERs. Still, all IERs are aware of the winning prefix 
reachability advertisement and will do what is required in forwarding based on 
that content.


They will not be aware of it unless we tell them via the Area Proxy TLV.  For 
obvious reasons, the Inside Nodes do NOT do anything with the Proxy LSP other 
than flood it.


Which is why we’re using the Prefix SID.

[Les:] You are using the prefix-SID, but the advertisement is not associated 
with a prefix reachability  advertisement, yet you want nodes to install 
forwarding entries based on this advertisement. This is what seems 
inappropriate.


We want outside nodes to install forwarding entries on the Prefix SID.  This is 
entirely backward compatible.  How is that inappropriate?

[Les:] Installation of forwarding entries today is based on Prefix Reachability 
advertisements. You are proposing to extend that by requiring a forwarding 
entry to be installed based on the context of the Area Proxy TLV.
I would prefer that you not introduce this.
In addition, since there will also be a Prefix Reachability Advertisement for 
the Area Prefix in the Proxy LSP, the IERs will have two sources of information 
for the SID associated with the Area prefix (Area SID sub-TLV from Area leader 
L2 LSP and Prefix Reachability advertisement in the Proxy LSP). Which 
introduces the possibility of inconsistency.
If you do NOT advertise the SID in the Area Proxy TLV then you both eliminate 
the introduction of installing forwarding entries based on non-reachability 
advertisements and you eliminate the possibility of inconsistency.
That is what I am asking you to do.


The only current case where a prefix-SID is advertised and is NOT associated 
with prefix reachability is in the Binding TLVs. This has two use cases:

  *   Advertising SIDs for prefixes associated with nodes which are NOT SR 
capable
  *   As an alternative to per prefix advertisement if the operator prefers to 
use a centralized SID assignment service

In both of these cases if a SID were to be advertised in prefix reachability 
TLV for the same prefix the SID in the prefix reachability advertisement would 
be preferred.
You don’t discuss this at all in the draft i.e., what happens if the SID in the 
prefix reachability advertisement for the Area Prefix differs from that 
advertised in the Area Proxy TLV. What I am pushing for is eliminating the need 
to do so by relying on the existing prefix SID advertisements and not 
introducing a new one in the Area Proxy TLV.


The existing ones do not have the required semantics.

[Les:] That’s wasn’t the point. The point was that when a SID is advertised in 
prefix reachability it is used in preference to advertisements in other TLVs.


[Les:] The semantics you require are functionally equivalent to anycast 
behavior – which is supported already.


Please point me to anycast semantics that will ONLY be selected by IERs.
[Les

Re: [Lsr] I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt

[Les Ginsberg (ginsberg)]

Tony –

Inline.

From: Tony Li  On Behalf Of tony...@tony.li
Sent: Wednesday, August 26, 2020 5:40 PM
To: Les Ginsberg (ginsberg) 
Cc: lsr@ietf.org
Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt


Les,

As per the draft:

Area Proxy TLV is advertised by IERs in their L2 LSP.
Area Proxy TLV is NOT advertised in the Proxy LSP.
So how do the OERs become aware of the

“prefix and  SID that represents the entirety of the Inside Area to the Outside 
 Area”

???

I assume that they learn this because the Proxy LSP (at least) contains a 
Prefix Reachability TLV with the same prefix/SID that was advertised in the 
Area Proxy TLV.
Is this correct? If not, please correct me.


That’s correct.  If this isn’t crystal clear from the draft, please work with 
me to get it clarified to your satisfaction.



Also explain why it is necessary for something other than a prefix reachability 
advertisement to cause an entry to be created in forwarding for a prefix – and 
ONLY when received in an L2 LSP?
This is unprecedented.



It is unprecedented because there we are proposing something unprecedented.  I 
repeat: "There is no other mechanism whereby system A can advertise a prefix 
SID to a number of other systems and have them install receive/POP forwarding 
entries.”

It is NOT creating forwarding TO a prefix.  It’s reception.


[Les:] Any one of the IERs can be elected Area Leader, therefore all of them 
have to be configured with the Area Prefix and associated SID.
Perhaps you are allowing that each IER could choose a different Area 
Prefix/SID. Not sure why you would want to do that – but even if you did, the 
behavior of the winning prefix/SID is analogous to an anycast address.
The difference here is that the advertisement of the Prefix Reachability 
associated with the area prefix is within the Proxy LSP – which appears to OERs 
as if it was originated by all of the IERs i.e., the set of IERs appears as a 
single node to the OERs. Still, all IERs are aware of the winning prefix 
reachability advertisement and will do what is required in forwarding based on 
that content.


If I am right, you then have  multiple TLVs which advertise duplicate 
advertisements – even if not in the same LSP - which exposes you to the 
problems I mentioned.
My goal is to have one – and only one – advertisement which creates forwarding 
state.


Well, I’m sorry, but your goal is unachievable.  The Proxy LSP is only relevant 
outside of the area.  The Inner Node LSPs aren’t circulated outside of the area.

[Les:] Agreed. Nothing I have asserted suggests otherwise.


My second goal is not to invent a new SID type/advertisement when the object 
associated with it (a prefix) already has a defined SID type.


Which is why we’re using the Prefix SID.

[Les:] You are using the prefix-SID, but the advertisement is not associated 
with a prefix reachability  advertisement, yet you want nodes to install 
forwarding entries based on this advertisement. This is what seems 
inappropriate.
The only current case where a prefix-SID is advertised and is NOT associated 
with prefix reachability is in the Binding TLVs. This has two use cases:

  *   Advertising SIDs for prefixes associated with nodes which are NOT SR 
capable
  *   As an alternative to per prefix advertisement if the operator prefers to 
use a centralized SID assignment service

In both of these cases if a SID were to be advertised in prefix reachability 
TLV for the same prefix the SID in the prefix reachability advertisement would 
be preferred.
You don’t discuss this at all in the draft i.e., what happens if the SID in the 
prefix reachability advertisement for the Area Prefix differs from that 
advertised in the Area Proxy TLV. What I am pushing for is eliminating the need 
to do so by relying on the existing prefix SID advertisements and not 
introducing a new one in the Area Proxy TLV.

What I object to – and am concerned about – is that you seem to invent your 
version of SR for Area Proxy even when you use the same object (a prefix) that 
SR already supports.


Again, SR does not support the semantics that we require.


[Les:] The semantics you require are functionally equivalent to anycast 
behavior – which is supported already.

   Les


As you know, I was prepared to support a new type of SID when you actually were 
defining a new object type. The fact that you decided NOT to invent a new 
object type is fine with me – but please do not claim that you need a new SID 
type when you don’t.


I’m sorry that you still don’t understand.  We do need something different.

Tony


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

Re: [Lsr] I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt

[Les Ginsberg (ginsberg)]

Tony –

Sigh…

I introduced the term “Area Destination” only as a means of demonstrating that 
this could have been something other than a prefix – as had been proposed in 
earlier versions of the draft. I am not asking you to introduce the term in the 
draft and as it seemed to confuse you I won’t use it any more in this thread.

As per the draft:

Area Proxy TLV is advertised by IERs in their L2 LSP.
Area Proxy TLV is NOT advertised in the Proxy LSP.
So how do the OERs become aware of the

“prefix and  SID that represents the entirety of the Inside Area to the Outside 
 Area”

???

I assume that they learn this because the Proxy LSP (at least) contains a 
Prefix Reachability TLV with the same prefix/SID that was advertised in the 
Area Proxy TLV.
Is this correct? If not, please correct me.  Also explain why it is necessary 
for something other than a prefix reachability advertisement to cause an entry 
to be created in forwarding for a prefix – and ONLY when received in an L2 LSP?
This is unprecedented.

If I am right, you then have  multiple TLVs which advertise duplicate 
advertisements – even if not in the same LSP - which exposes you to the 
problems I mentioned.
My goal is to have one – and only one – advertisement which creates forwarding 
state.
My second goal is not to invent a new SID type/advertisement when the object 
associated with it (a prefix) already has a defined SID type.

What I object to – and am concerned about – is that you seem to invent your 
version of SR for Area Proxy even when you use the same object (a prefix) that 
SR already supports.

As you know, I was prepared to support a new type of SID when you actually were 
defining a new object type. The fact that you decided NOT to invent a new 
object type is fine with me – but please do not claim that you need a new SID 
type when you don’t.

   Les

From: Tony Li  On Behalf Of tony...@tony.li
Sent: Wednesday, August 26, 2020 4:02 PM
To: Les Ginsberg (ginsberg) 
Cc: lsr@ietf.org
Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt



Hi Les,


You have chosen to assign a prefix as the “Area Destination”.


Are you sure you have the right document?  The word “Destination” does not 
appear anywhere within 
https://tools.ietf.org/html/draft-ietf-lsr-isis-area-proxy-03



This is fine with me. But having done that, forwarding should be based on the 
existing mechanisms for advertising a prefix and the associated prefix SID.


Which is exactly what we’re doing: we’re advertising a prefix SID in the Proxy 
LSP.


If you’re referring to the Area SID advertisement, then there is no existing 
mechanism for advertising that today, that’s why we’re having to create an 
additional subTLV.
There is no other mechanism whereby system A can advertise a prefix SID to a 
number of other systems and have them install receive/POP forwarding entries.



By doing that you avoid a number of problems:


  *   Duplicate SID advertisements for the same prefix and the possibility of 
inconsistency
  *   Differing forwarding behavior for routers (IERs) who understand the Area 
Proxy TLV and those routers which don’t (everyone else)

You can still include a sub-TLV in the Area Proxy TLV to identify the Area 
Prefix, but there is no need to also advertise the SID there. This makes the 
“Area Prefix” advertisement functionally equivalent to the “Router-ID” 
advertisement. It’s a convenient way to identify the prefix associated with the 
area, but it does not eliminate the need to also advertise prefix reachability 
information for that prefix in order to enable forwarding.


You seem to be asking that the Area Leader also advertise a Prefix SID in its 
own LSP, as well as a prefix in the Area Proxy TLV.  This is not just 
duplication of advertisement, it’s duplication plus a prefix.  By your own 
criteria, this suggestion is worse than what we’ve proposed.

All Inside Nodes need to understand the Area Proxy TLV and respond accordingly. 
 Only the Inside Edge Nodes need to install forwarding state for the Area SID.  
Advertising a separate Prefix SID to the Inside Nodes forces them to create 
additional forwarding state that may not be desired by the network 
administrator.



I have also suggested that an additional bit could be assigned in the 
Prefix-Attributes sub-TLV (RFC 7794) to mark a prefix as an Area Prefix if you 
wish.


Thank you, but no thanks. As you’ve seen, a large driver for doing it this way 
is backward compatibility. Adding a bit would not be helpful in that regard.



But advertising a prefix-SID in two different places is a bad idea.


Advertising it in 2.5 places is worse.



In an unrelated matter, 
https://tools.ietf.org/html/draft-ietf-lsr-isis-area-proxy-03#section-2 states:

“An Inside Edge Router may be elected the DIS for a Boundary
   LAN.  In this case using the Area Proxy System Id as the basis for
   the LAN pseudonode identifier could create a collision, so the
   Insider Edge Router SHOULD compose

Re: [Lsr] Fwd: I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt

[Les Ginsberg (ginsberg)]

Tony -

You have chosen to assign a prefix as the "Area Destination". This is fine with 
me. But having done that, forwarding should be based on the existing mechanisms 
for advertising a prefix and the associated prefix SID.
By doing that you avoid a number of problems:


  *   Duplicate SID advertisements for the same prefix and the possibility of 
inconsistency
  *   Differing forwarding behavior for routers (IERs) who understand the Area 
Proxy TLV and those routers which don't (everyone else)


You can still include a sub-TLV in the Area Proxy TLV to identify the Area 
Prefix, but there is no need to also advertise the SID there. This makes the 
"Area Prefix" advertisement functionally equivalent to the "Router-ID" 
advertisement. It's a convenient way to identify the prefix associated with the 
area, but it does not eliminate the need to also advertise prefix reachability 
information for that prefix in order to enable forwarding.

I have also suggested that an additional bit could be assigned in the 
Prefix-Attributes sub-TLV (RFC 7794) to mark a prefix as an Area Prefix if you 
wish.

But advertising a prefix-SID in two different places is a bad idea.

.

In an unrelated matter, 
https://tools.ietf.org/html/draft-ietf-lsr-isis-area-proxy-03#section-2 states:

"An Inside Edge Router may be elected the DIS for a Boundary
   LAN.  In this case using the Area Proxy System Id as the basis for
   the LAN pseudonode identifier could create a collision, so the
   Insider Edge Router SHOULD compose the pseudonode identifier using
   its native system identifier."

I understand the potential collision that could arise if the Area Proxy 
System-Id were to be used in the pseudonode-id. However, what you propose is 
incompatible with a strict interpretation of ISO 10589 Section 8.4.5:

"If this system, as a result of the Designated Intermediate System election 
process, considers itself to be designated Intermediate System, the LAN ID 
field shall be set to the concatenation of this system's own system ID and the 
locally assigned one octet Local Circuit ID."

This raises the possibility that some of the non-DIS neighbors might not honor 
the pseudo-node ID since it does not match the system-id associated with their 
adjacency to the pseudo-node.
At a minimum this possibility should be mentioned in the text.

One way to mitigate this is to have the IERs advertise a LAN Priority of 0 in 
their IIHs so as to avoid this case.

   Les

From: Lsr  On Behalf Of tony...@tony.li
Sent: Monday, August 24, 2020 10:02 AM
To: lsr@ietf.org
Subject: [Lsr] Fwd: I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt


Hi folks,

This updated draft has been published for a few weeks now.  We would like to 
solicit your opinion on this.  In particular, we have changed the encoding of 
the Area SID.  Do you find this encoding adequate and appropriate?

Thanks,
Tony



Begin forwarded message:

From: internet-dra...@ietf.org
Subject: I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt
Date: August 5, 2020 at 1:17:39 PM PDT
To: mailto:i-d-annou...@ietf.org>>
Cc: lsr@ietf.org
Reply-To: internet-dra...@ietf.org, 
lsr@ietf.org


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   : Area Proxy for IS-IS
   Authors : Tony Li
 Sarah Chen
 Vivek Ilangovan
 Gyan S. Mishra
 Filename: draft-ietf-lsr-isis-area-proxy-03.txt
 Pages   : 19
 Date: 2020-08-05

Abstract:
  Link state routing protocols have hierarchical abstraction already
  built into them.  However, when lower levels are used for transit,
  they must expose their internal topologies to each other, leading to
  scale issues.

  To avoid this, this document discusses extensions to the IS-IS
  routing protocol that would allow level 1 areas to provide transit,
  yet only inject an abstraction of the level 1 topology into level 2.
  Each level 1 area is represented as a single level 2 node, thereby
  enabling greater scale.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-area-proxy/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-lsr-isis-area-proxy-03
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-area-proxy-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-isis-area-proxy-03


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/

Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

[Les Ginsberg (ginsberg)]

Huaimo -

The question I and others have asked is "what can we do with zones that cannot 
be done with areas?".

>From the day several years ago when IS-IS TTZ was first presented,  your 
>answer has been "with zones you can hitlessly alter the topological 
>boundaries".
My response has consistently been "we can already do that with areas".

If you want to justify zones, you then need to provide some other use case that 
either cannot be done using areas or cannot be done hitlessly.
Continuing to focus on something that can already be done with areas isn't 
helping you.

   Les


From: Huaimo Chen 
Sent: Tuesday, August 18, 2020 3:18 PM
To: Les Ginsberg (ginsberg) ; Les Ginsberg (ginsberg) 
; Acee Lindem (acee) 
; lsr@ietf.org
Subject: Re: LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - 
draft-chen-isis-ttz-11.txt

Hi Les,

> It is possible to merge/split areas without adjacency flaps.
[HC]: While an existing area or zone is being abstracted as a single node 
or vice versa, there are the adjacency ups and downs. The areas 
merging/splitting without adjacency flaps has been done before this abstraction 
and will not reduce the service interruption during the abstraction.

Best Regards,
Huaimo
____
From: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Sent: Tuesday, August 18, 2020 5:59 PM
To: Huaimo Chen mailto:huaimo.c...@futurewei.com>>; 
Les Ginsberg (ginsberg) 
mailto:ginsberg=40cisco@dmarc.ietf.org>>;
 Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org> mailto:lsr@ietf.org>>
Subject: RE: LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - 
draft-chen-isis-ttz-11.txt


Huaimo -



It is possible to merge/split areas without adjacency flaps.

The technique has been known for many years.

It requires careful planning - but it is quite feasible and has been done.



You cannot justify the need for zones on this basis.



   Les





From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
Huaimo Chen
Sent: Tuesday, August 18, 2020 2:33 PM
To: Les Ginsberg (ginsberg) 
mailto:ginsberg=40cisco@dmarc.ietf.org>>;
 Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Subject: Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - 
draft-chen-isis-ttz-11.txt



Hi Les,



> I see no need for "abstraction at arbitrary boundaries". Areas work just fine.

> IS-IS already has smooth transition capability for merging/splitting areas..



[HC]: The smooth transition capability for merging/splitting areas in IS-IS 
will not reduce the service interruption while an existing area or zone is 
being abstracted as a single node because the adjacency ups and downs.



> Given both of the points above, I see no value in "smooth transition to/from 
> zone abstraction".



[HC]:  The "smooth transition to/from zone abstraction" will reduce the service 
interruption while an existing area or zone is being abstracted as a single 
node and vice versa.



Best Regards,

Huaimo



From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of Les 
Ginsberg (ginsberg) 
mailto:ginsberg=40cisco@dmarc.ietf.org>>
Sent: Tuesday, August 18, 2020 5:06 PM
To: Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org> mailto:lsr@ietf.org>>
Subject: Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - 
draft-chen-isis-ttz-11.txt



I see no need for "abstraction at arbitrary boundaries". Areas work just fine.



IS-IS already has smooth transition capability for merging/splitting areas.



Given both of the points above, I see no value in "smooth transition to/from 
zone abstraction".



If these are the principal distinguishing characteristics of TTZ as compared to 
area proxy (and I would agree they are), then I see no reason why this solution 
should be pursued as well.



I am therefore opposed to WG adoption of TTZ.



   Les







From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Acee 
Lindem (acee)
Sent: Tuesday, August 18, 2020 7:17 AM
To: lsr@ietf.org<mailto:lsr@ietf.org>
Subject: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - 
draft-chen-isis-ttz-11.txt





Based on the discussions in the last meeting and on the mailing list regarding 
draft-chen-isis-ttz-11, the chairs feel that there are enough differences with 
draft-ietf-lsr-isis-area-proxy-03 and in the community to consider advancing it 
independently on the experimental track.



These differences include abstraction at arbitrary boundaries and IS-IS 
extensions for smooth transition to/from zone abstraction.



We are now starting an LSR