[Lsr] FW: Reminder: Survey on planning for possible online IETF meetings

[Acee Lindem (acee)]

Esteemed LSR WG members,

Virtual IETF meeting survey link below – please take the survey if you intend 
on participating in future virtual IETF meetings.

Thanks,
Acee

From: WGChairs  on behalf of Alissa Cooper 

Date: Tuesday, May 5, 2020 at 7:49 AM
To: IETF WG Chairs 
Subject: Fwd: Reminder: Survey on planning for possible online IETF meetings

Please circulate this to your working group lists. The survey data will be very 
important as we plan future IETF meetings.

Thanks,
Alissa


Begin forwarded message:

From: IETF Executive Director 
mailto:exec-direc...@ietf.org>>
Subject: Reminder: Survey on planning for possible online IETF meetings
Date: May 4, 2020 at 3:03:35 AM EDT
To: "IETF Announcement List" 
mailto:ietf-annou...@ietf.org>>
Reply-To: ietf108plann...@ietf.org

This is a reminder that we need the IETF community to help us plan for the 
possibility that one or more upcoming IETF meetings in 2020 and possibly 2021 
may not be able to go ahead in person.  You can help us with this by filling 
out the following survey:

https://www.surveymonkey.com/r/5328FFJ

So far we have 114 responses and we would ideally like 500 or more.

The survey contains the following pages and will take 15-20 minutes to complete:

1. Welcome
2. Online IETF 107 and the subsequent virtual interims
3. Replacing a cancelled in-person meeting
4. Online meeting format and timezone
5. Replicating humming
6. Replicating the hallway environment
7. Fees
8. Thanks and anything else

We run the survey in anonymous mode which means that we only see data that you 
explicitly provide.

Thank you in advance for your help.

--
Alissa Cooper, IETF Chair
Jay Daley, IETF Executive Director
Colin Perkins, IRTF Chair

___
IETF-Announce mailing list
ietf-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

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

Re: [Lsr] Genart last call review of draft-ietf-isis-mpls-elc-11

[Acee Lindem (acee)]

Hi Mohit,

From: Mohit Sethi M 
Date: Wednesday, April 29, 2020 at 2:29 AM
To: Acee Lindem , "gen-...@ietf.org" 
Cc: "lsr@ietf.org" , "draft-ietf-isis-mpls-elc@ietf.org" 
, "last-c...@ietf.org" 

Subject: Re: Genart last call review of draft-ietf-isis-mpls-elc-11


HI Acee,
On 4/24/20 3:38 PM, Acee Lindem (acee) wrote:

Hi Mohit,



Speaking as document shepherd. See inline.



On 4/24/20, 3:39 AM, "Mohit Sethi via Datatracker" 
<mailto:nore...@ietf.org> wrote:



Reviewer: Mohit Sethi

Review result: Ready with Nits



I am the assigned Gen-ART reviewer for this draft. The General Area

Review Team (Gen-ART) reviews all IETF documents being processed

by the IESG for the IETF Chair.  Please treat these comments just

like any other last call comments.



For more information, please see the FAQ at




<https://trac.ietf.org/trac/gen/wiki/GenArtfaq><https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.



Document: draft-ietf-isis-mpls-elc-11

Reviewer: Mohit Sethi

Review Date: 2020-04-24

IETF LC End Date: 2020-05-05

IESG Telechat date: Not scheduled for a telechat



Summary: This document specifies how Entropy Label Capability (ELC) and 
Entropy

Readable Label Depth (ERLD) are advertised using IS-IS. For advertising 
ELC, a

flag in the Prefix Attribute Flags is used. For advertising ERLD, a Node MSD

Advertisement is used.



Major issues:



Minor issues: The document is short and straightforward. For someone like me

who is not familiar with the routing area, would it make sense to explain 
why

signalling ELC information with MPLS is not sufficient (or what are the

benefits of advertising with IS-IS)?



I guess I'm wondering what you mean "signaling ELC information with MPLS"? With 
segment routing, the IGPs can be the only choice for signaling ELC capability. 
I don’t believe this comment requires any action.

I hope that you don't expect a gen-art reviewer to be an expert on every topic. 
I certainly am NOT on expert on routing. I interpreted the following text in 
the draft:

It also

   introduces the concept of Entropy Label Capability (ELC) and defines

   the signaling of this capability via MPLS signaling protocols.
to imply that signaling ELC information with MPLS is possible but this draft 
defines a mechanism for signaling the same information with IS-IS. Maybe the 
need for this is very obvious for those in the routing domain in which case 
ignoring my comment is perfectly fine.

Even though you are not an expert on routing, you should realize that “with 
MPLS” and “via MPLS signaling protocols” have very different connotations. If 
you reference section 3 of the reference document [RFC6790], you’ll the MPLS 
signaling protocols currently supporting ELC signaling. As I stated previously, 
with segment routing none of these protocols are required for deployment.

Thanks,
Acee

--Mohit



Thanks,

Acee





Nits/editorial comments:



In section 3, "used as the ECL  Flag" should perhaps be "used as the ELC 
Flag"?

In section 4, "IANA for EARLD-MSD" should perhaps be "IANA for ERLD-MSD"?

In section 6, "ECL Flag (E-flag)." should perhaps be "ELC Flag (E-flag)."?






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

Re: [Lsr] 答复: I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-01.txt

[Acee Lindem (acee)]

Hi Yali, 

See [Acee]. 

On 4/28/20, 6:10 AM, "wangyali"  wrote:

Hi Acee,

Please see inline [Yali]. Thanks.

-Original Message-
From: Acee Lindem (acee) [mailto:a...@cisco.com] 
Sent: Monday, April 27, 2020 8:27 PM
To: wangyali ; lsr@ietf.org
Subject: Re: [Lsr] 答复: I-D Action: 
draft-ietf-lsr-ospfv3-extended-lsa-yang-01.txt

Hi Yali, 

On 4/26/20, 10:34 PM, "Lsr on behalf of wangyali"  wrote:

Dear authors,

It's valuable work. After reading I have a clarifying question.

As you defined a Container unknown-tlv and Grouping unknown-sub-tlv in 
each OSPFv3 Extended LSAs defined in [RFC8362], are these used for extension of 
new OSPF Extended LSAs and new attributes in each extended LSA, respectively?

Yes. 

[Yali]: Could you give an example to illustrate how to use this model? And 
please add some words to introduce how to use these unkown-tlv and 
unknown-sub-tlv Container/Grouping?

[Acee] As the name implies, you'd use them for TLVs and Sub-TLVs that are not 
supported. 

For example, if other attributes associated with Link are extended to 
E-Router-LSA TLV for access via NETCONF, does it can be directly augmented leaf 
of the List sub-tlvs in this YANG module? 

If not, does it need to define a new YANG module used for other Link 
attributes can be accessed via NETCONF?

Yes. There are many features that utilize the OSPFv3 extended LSA format 
and these will correspond to new models. For example, OSPFv3 segment routing. 

[Yali]: For example, in RFC8666, the Prefix-SID sub-TLV is a sub-TLV of the 
Intra-Area Prefix TLV. And in draft [ospfv3-extended-lsa-yang-01], you also 
defined grouping intra-area-prefix-tlv which includes a list sub-tlvs. May 
question is that could we directly use the ospfv3-extended-lsa-yang model and 
augment a Prefix-SID sub-TLV leaf in the list sub-tlv and do not need to define 
a new model? If not, why?

[Acee] You'd use them if you supported the augmenting OSPFv3 YANG model. 
However, in that case, then they'd no longer be "unknown". OSPFv3 features 
adding new TLVs and Sub-TLVs will not automatically be supported by all routers 
OSPFv3 routers in the domain. In fact, due to timing there may be features that 
don't even have corresponding OSPFv3 Extended-LSA YANG model augmentations when 
the corresponding Extended-LSAs are advertised. 

[Yali]: Besides, considering NETCONF and BGP-LS are two parallel solutions 
for exportation, we suggest separate this draft 
[draft-wang-lsr-ifit-node-capability-advertisement-00]. One draft specifies IGP 
Extension for IFIT capability advertisement and others specify IFIT capability 
exportation via NETCONF and BGP-LS, respectively. Do you agree that?

[Acee] I agree that the NETCONF and YANG model should be separate. I didn't 
agree that it is needed in the IGPs. 

Thanks,
Acee

Thanks,
Acee

Best regards,
Yali

-邮件原件-
发件人: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
发送时间: 2020年4月25日 3:36
收件人: i-d-annou...@ietf.org
抄送: lsr@ietf.org
主题: [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-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   : YANG Model for OSPFv3 Extended LSAs
Authors : Acee Lindem
  Sharmila Palani
  Yingzhen Qu
Filename: draft-ietf-lsr-ospfv3-extended-lsa-yang-01.txt
Pages   : 30
Date: 2020-04-24

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


The IETF datatracker status page for this draft is:

https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-extended-lsa-yang/

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

https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospfv3-extended-lsa-yang-01

A diff from the previous version is available at:

https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-ospfv3-extended-lsa-yang-01


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] Flow Control Discussion for IS-IS Flooding Speed

[Acee Lindem (acee)]

Hi Bruno,

From: Lsr  on behalf of Bruno Decraene 

Date: Monday, April 27, 2020 at 8:15 AM
To: Robert Raszuk 
Cc: "Les Ginsberg (ginsberg)" , 
"lsr@ietf.org" , Tony Przygienda 
Subject: Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

Robert,

From: Robert Raszuk [mailto:rob...@raszuk.net]
Sent: Monday, April 27, 2020 12:09 PM
To: DECRAENE Bruno TGI/OLN
Cc: Tony Przygienda; Les Ginsberg (ginsberg); lsr@ietf.org
Subject: Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed


> Slow flooding increase the likelihood of multiple IGP SPF computations

True.

But if you keep your IGP nicely organized in area and levels, get rid of 
flooding anything incl. /32s domain wide to address bugs in MPLS architecture 
then your flooding radius is usually very small.
[Bruno] First of all, the use of areas/levels brings tradeoffs. Then, after 
their initial design, networks grow and change.

Coming back to flooding, if you have a core router with 50 IGP neighbors, the 
failure of this neighbor requires flooding 50 LSPs. At 33ms pacing between LSPs 
that’s a 1.6s delay/tax, before any computation & FIB update. As you see, it’s 
not related to the number of /32 nor the network diameter.
Some may be fine with this additional 1.6s. Some may not.

I’m not nearly as familiar with IS-IS deployments as OSPF. Are there any 
implementations that don’t offer configuration to override the 33ms inter-LSP 
interval? At Redback (circa 2000), our OSPF implementation defaulted to fast 
flooding and for the MinLSInterval and MinLSArrival OSPF values, you had to 
explicitly remove the fast flooding default if  you wanted to follow RFC 2328. 
Thanks,
Acee

Best
--Bruno


That in turn allows for both fast flooding and fast topology computation while 
only dealing with few external summaries. I am yet to see a practical case 
where a well designed network with today's ISIS requires flooding speedup.

Best,
R.




On Mon, Apr 27, 2020 at 10:34 AM 
mailto:bruno.decra...@orange.com>> wrote:

>  ISIS flooding churn (and room for optimization) becomes a problem when node 
> boots up (IMHO this is not a problem) and when node fails while having many 
> neighbors attached. Yes maybe second case could be improved but well designed 
> and operated network should have pre-programmed bypass paths against such 
> cases so IMO stressing IGP to "converge" faster while great in principle may 
> not be really needed in practice.


I don’t think that FRR is a replacement for “fast” (I’d rather say adequate) 
IGP convergence & flooding.

For multiple reasons such as:

-  Multiple ‘things’ depends on the IGP, such as BGP best path 
selection, CSPF/TE/PCE computations, FRR computations

-  Slow flooding increase the likelihood of multiple IGP SPF 
computations which is harmful for other computations which are typically 
heavier and manifolds (cf above)

-  Multiple IGP SPF computations also create multiple transient 
forwarding loops. There are some techniques to remove forwarding loops but this 
is still an advanced topic and some implementations do not handle consecutives 
IGP SPF (with ‘overlapping’ convergences and combined distributed forwarding 
loops)

-  For FRR, you mostly need to pre-decide/configure whether you want to 
protect link or node failures. Tradeoff are involved and given probability of 
events, link protection is usually enabled (hence not node protection)

-  …

Also, given the current “state of the art”, there is no stressing involved. 
Really. Using TCP, my 200€ mobile running on battery and over 
wifi+ADSL+Internet can achieve better communication throughput than a n*100k€ 
high end IS-IS router.
I think many persons agree that IS-IS could do better in term of flooding. 
(possibly not as good as a brand new approach, but incremental improvement also 
have some benefits). Eventually, we don’t need everyone to agree on this.



>  PS. Does anyone have a pointer to any real data showing that performance of 
> real life WAN ISIS deployments is bad ?

In some of our ASes, we do monitor IS-IS by listening to and recording flooded 
LSPs. I can’t share any data.
Next question could be what is “good enough”. I guess this may depend on the 
size of your network, its topology, and your requirements.

We also ran tests in labs. I may share some results during my presentation. (no 
names, possibly no KPI, but some high level outcomes).

Regards,
Bruno


From: Robert Raszuk [mailto:rob...@raszuk.net]
Sent: Friday, April 24, 2020 12:42 PM
To: DECRAENE Bruno TGI/OLN
Cc: Tony Przygienda; Les Ginsberg (ginsberg); lsr@ietf.org
Subject: Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

Hi Bruno  & all,

[Bruno] On my side, I’ll try once and I think the LSR WG should also try to 
improve IS-IS performance. May be if we want to move, we should first release 
the brakes.

Well from my observations releasing the breaks means increasing the risks.

T

Re: [Lsr] 答复: I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-01.txt

[Acee Lindem (acee)]

Hi Yali, 

On 4/26/20, 10:34 PM, "Lsr on behalf of wangyali"  wrote:

Dear authors,

It's valuable work. After reading I have a clarifying question.

As you defined a Container unknown-tlv and Grouping unknown-sub-tlv in each 
OSPFv3 Extended LSAs defined in [RFC8362], are these used for extension of new 
OSPF Extended LSAs and new attributes in each extended LSA, respectively?

Yes. 

For example, if other attributes associated with Link are extended to 
E-Router-LSA TLV for access via NETCONF, does it can be directly augmented leaf 
of the List sub-tlvs in this YANG module? 

If not, does it need to define a new YANG module used for other Link 
attributes can be accessed via NETCONF?

Yes. There are many features that utilize the OSPFv3 extended LSA format and 
these will correspond to new models. For example, OSPFv3 segment routing. 

Thanks,
Acee

Best regards,
Yali

-邮件原件-
发件人: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
发送时间: 2020年4月25日 3:36
收件人: i-d-annou...@ietf.org
抄送: lsr@ietf.org
主题: [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-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   : YANG Model for OSPFv3 Extended LSAs
Authors : Acee Lindem
  Sharmila Palani
  Yingzhen Qu
Filename: draft-ietf-lsr-ospfv3-extended-lsa-yang-01.txt
Pages   : 30
Date: 2020-04-24

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


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

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

https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospfv3-extended-lsa-yang-01

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


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] Genart last call review of draft-ietf-isis-mpls-elc-11

[Acee Lindem (acee)]

Hi Mohit,

Speaking as document shepherd. See inline. 

On 4/24/20, 3:39 AM, "Mohit Sethi via Datatracker"  wrote:

Reviewer: Mohit Sethi
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-isis-mpls-elc-11
Reviewer: Mohit Sethi
Review Date: 2020-04-24
IETF LC End Date: 2020-05-05
IESG Telechat date: Not scheduled for a telechat

Summary: This document specifies how Entropy Label Capability (ELC) and 
Entropy
Readable Label Depth (ERLD) are advertised using IS-IS. For advertising 
ELC, a
flag in the Prefix Attribute Flags is used. For advertising ERLD, a Node MSD
Advertisement is used.

Major issues:

Minor issues: The document is short and straightforward. For someone like me
who is not familiar with the routing area, would it make sense to explain 
why
signalling ELC information with MPLS is not sufficient (or what are the
benefits of advertising with IS-IS)?

I guess I'm wondering what you mean "signaling ELC information with MPLS"? With 
segment routing, the IGPs can be the only choice for signaling ELC capability. 
I don’t believe this comment requires any action. 

Thanks,
Acee


Nits/editorial comments:

In section 3, "used as the ECL  Flag" should perhaps be "used as the ELC 
Flag"?
In section 4, "IANA for EARLD-MSD" should perhaps be "IANA for ERLD-MSD"?
In section 6, "ECL Flag (E-flag)." should perhaps be "ELC Flag (E-flag)."?



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

Re: [Lsr] clarification of locator block and locator node in draft-ietf-spring-srv6-network-programming and draft-ietf-lsr-isis-srv6-extensions

[Acee Lindem (acee)]

Speaking as WG member:

In the past, we developed protocol encodings that afforded future 
extendibility. I don't see the problem with the including the SID structure 
sub-sub-TLV and would support progression.

Thanks,
Acee

On 4/10/20, 2:45 AM, "Lsr on behalf of Derek Yeung"  wrote:

Hi,

We at Arrcus have implemented support for this draft including the SID 
Structure sub-sub-TLV.
The proposed encodings for the SID Structure sub-sub-TLV is flexible and 
works fine.

Thanks,
Derek

Derek Yeung
de...@arrcus.com
Main: 408.884.1965



2077 Gateway Place, Suite 400
San Jose, CA.  95110

The contents of this message, together with any attachments, are intended 
only for the use of the individual or entity to which they are addressed and 
may contain information that is confidential and proprietary to Arrcus. If you 
are not the intended recipient, you are hereby notified that any dissemination, 
distribution, or copying of this message, or any attachment, is strictly 
prohibited. If you have received this message in error, please notify the 
original sender immediately by telephone or by return E-mail and delete this 
message, along with any attachments, from your computer. Thank you.


On 4/6/20, 4:03 AM, "Lsr on behalf of Peter Psenak"  wrote:

Chris,

On 01/04/2020 21:58, Chris Bowers wrote:
> Peter,
> 
> There seem to be two disconnects in this discussion.
> 
> 1) The response below implies that the encodings in 
> draft-ietf-lsr-isis-srv6-extensions are supposed represent the case 
> where the locators are allocated from several different IPv6 address 
> blocks (for example, blocks S1/s1 through Sn/sn). However, 
> draft-ietf-spring-srv6-network-programming and 
> draft-ietf-6man-segment-routing-header only discuss the case where 
the 
> locators are allocated from a single block (S/s).  If an 
implementation 
> is expected to properly encode the case where locators are allocated 
> from several different IPv6 address blocks, then I think that case 
> should be explicitly described in these documents.


There is no statement in draft-ietf-spring-srv6-network-programming 
that 
the block is unique. As an example, Iliad authorized me to indicate 
that 
their SRv6 deployment involves several blocks.


> 
> 2)   The response below says "To be able to find out where the func 
and 
> arg are located, you need to know the LOC length, e.g. Block and Node 
> length."  However, the SRv6 SID Structure Sub-Sub-TLV is carried 
within 
> the SRv6 End SID, SRv6 End.X SID, and the SRv6 LAN End.X SID 
Sub-TLVs, 
> which are carried within the SRv6 Locator TLV.  

not really. SRv6 End.X SID, and the SRv6 LAN End.X SID Sub-TLVs are 
advertised in the IS Reachability TLVs (22, 23, 222, 223, 141), not in 
SRv6 Locator TLV.

thanks,
Peter


> The  SRv6 Locator TLV 
> has a Loc-Size field.  Why would the value of the LOC length computed 
as 
> the sum of the Block and Node length ever be different from the value 
in 
> the Loc-Size field?
> 
> Chris
> 
> 
> On Wed, Mar 25, 2020 at 9:49 AM Peter Psenak  > wrote:
> 
> Chris,
> 
> please see inline:
> 
> 
> On 23/03/2020 17:39, Chris Bowers wrote:
>  > Peter,
>  >
>  > The proposed SRv6 SID Structure Sub-Sub-TLV has several 
problems.
>  >
>  > 1) As discussed in item#3 below, it is not clear that flooding 
LB
>  > Length, LN Length, Fun. Length, and Arg. Length to all ISIS
> speakers is
>  > really the right approach.  However, if the WG determines that 
it
> is the
>  > right approach, the current encodings of this information in 
the
>  > proposed SRv6 SID Structure Sub-Sub-TLV are problematic.  As
> discussed
>  > earlier in this thread, a network operator may choose to not
> allocate
>  > all locators from a single block, so LB Length and LN Length 
may
> not be
>  > well-defined.
> 
> I'm not sure what do you mean by not "well defined". For every 
SID you
> need to know the LOC (B+N) part. If you guarantee that it is the
> same on
> all nodes, you know it from the local config, otherwise, you 
advertise
> it with a SID.
> 
>  > The current encoding of the SRv6 SID Structure
>  > Sub-Sub-TLV makes it difficult to represent this situation.  
The
> simple
>  > thing to do for nodes that don't have a well-defi

Re: [Lsr] RFC 8770 on Host Router Support for OSPFv2

[Acee Lindem (acee)]

Padma, Keyur, Manish, and Serpil - Congrats on publications... 

We are completing much of the existing work prior to the merge of the OSPF and 
IS-IS WGs into LSR. 

Thanks,
Acee

On 4/9/20, 1:23 PM, "Lsr on behalf of rfc-edi...@rfc-editor.org" 
 wrote:

A new Request for Comments is now available in online RFC libraries.


RFC 8770

Title:  Host Router Support for OSPFv2 
Author: K. Patel, 
P. Pillay-Esnault,
M. Bhardwaj,
S. Bayraktar
Status: Standards Track
Stream: IETF
Date:   April 2020
Mailbox:ke...@arrcus.com, 
padma.i...@gmail.com, 
manbh...@cisco.com,
ser...@cisco.com
Pages:  8
Updates:RFC 6987

I-D Tag:draft-ietf-ospf-ospfv2-hbit-12.txt

URL:https://www.rfc-editor.org/info/rfc8770

DOI:10.17487/RFC8770

The Open Shortest Path First Version 2 (OSPFv2) protocol does not
have a mechanism for a node to repel transit traffic if it is on the
shortest path.  This document defines a bit called the Host-bit
(H-bit). This bit enables a router to advertise that it is a
non-transit router.  This document also describes the changes needed
to support the H-bit in the domain.  In addition, this document
updates RFC 6987 to advertise Type 2 External and Not-So-Stubby Area
(NSSA) Link State Advertisements (LSAs) (RFC 3101) with a high cost
in order to repel traffic effectively.

This document is a product of the Link State Routing Working Group of the 
IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet Standards Track
protocol for the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Official
Internet Protocol Standards (https://www.rfc-editor.org/standards) for the 
standardization state and status of this protocol.  Distribution of this 
memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


___
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] I,Scope of FIT Capability: a node or a link?

[Acee Lindem (acee)]

Tianran,

You keep missing my point. Even if the potential transit nodes advertise the 
capability, the management function doesn’t know which nodes will be transited 
in the path. Hence, you’re second use case is misguided.

Acee

From: Lsr  on behalf of Tianran Zhou 

Date: Wednesday, April 8, 2020 at 2:51 AM
To: Acee Lindem , Jeff Tantsura , "Les 
Ginsberg (ginsberg)" , Tony Li 

Cc: Greg Mirsky , "ops...@ietf.org" , 
"draft-song-opsawg-ifit-framew...@ietf.org" 
, 
"draft-wang-lsr-ifit-node-capability-advertisem...@ietf.org" 
, "lsr@ietf.org" 

Subject: Re: [Lsr] I,Scope of FIT Capability: a node or a link?

Hi Acee,

Tracing is of course useful.
Here we  also consider to combine the traffic engineering and monitoring. So 
the transit nodes are visible.
For the loose TE, the intermediate SR nodes construct the segment monitoring.

Tianran

From: Acee Lindem (acee) [mailto:a...@cisco.com]
Sent: Wednesday, April 8, 2020 4:29 AM
To: Tianran Zhou ; Jeff Tantsura 
; Les Ginsberg (ginsberg) 
; Tony Li 
Cc: Greg Mirsky ; 
draft-song-opsawg-ifit-framew...@ietf.org; lsr@ietf.org; ops...@ietf.org; 
draft-wang-lsr-ifit-node-capability-advertisem...@ietf.org
Subject: Re: [Lsr] I,Scope of FIT Capability: a node or a link?

Speaking as WG member:

With respect to your use case for transit router advertisement… What I was 
unsuccessfully trying to articulate to you during the interim was that the 
management system will typically not know the exact path between two endpoints 
so the use case is flawed. In fact, many times tracing is used by the 
management system to discover the path – as in traceroute…

Thanks,
Acee



From: Tianran Zhou mailto:zhoutian...@huawei.com>>
Date: Tuesday, April 7, 2020 at 3:22 AM
To: Acee Lindem mailto:a...@cisco.com>>, Jeff Tantsura 
mailto:jefftant.i...@gmail.com>>, "Les Ginsberg 
(ginsberg)" 
mailto:ginsberg=40cisco@dmarc.ietf.org>>,
 Tony Li mailto:tony1ath...@gmail.com>>
Cc: Greg Mirsky mailto:gregimir...@gmail.com>>, 
"draft-song-opsawg-ifit-framew...@ietf.org<mailto:draft-song-opsawg-ifit-framew...@ietf.org>"
 
mailto:draft-song-opsawg-ifit-framew...@ietf.org>>,
 "lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>, 
"ops...@ietf.org<mailto:ops...@ietf.org>" 
mailto:ops...@ietf.org>>, 
"draft-wang-lsr-ifit-node-capability-advertisem...@ietf.org<mailto:draft-wang-lsr-ifit-node-capability-advertisem...@ietf.org>"
 
mailto:draft-wang-lsr-ifit-node-capability-advertisem...@ietf.org>>
Subject: RE: [Lsr] I,Scope of FIT Capability: a node or a link?

Hi Acee,

About the “IFIT specific information channel”, as in 
https://datatracker.ietf.org/doc/draft-qin-idr-sr-policy-ifit/
we propose to use bgp enabled sr-policy for IFIT auto deployment.
It’s reasonable to incorporate both traffic engineering and monitoring.

Thanks,
Tianran

发件人: Acee Lindem (acee) [mailto:a...@cisco.com]
发送时间: 2020年4月7日 2:54
收件人: Jeff Tantsura mailto:jefftant.i...@gmail.com>>; 
Les Ginsberg (ginsberg) 
mailto:ginsberg=40cisco@dmarc.ietf.org>>;
 Tony Li mailto:tony1ath...@gmail.com>>
抄送: Greg Mirsky mailto:gregimir...@gmail.com>>; 
draft-song-opsawg-ifit-framew...@ietf.org<mailto:draft-song-opsawg-ifit-framew...@ietf.org>;
 lsr@ietf.org<mailto:lsr@ietf.org>; ops...@ietf.org<mailto:ops...@ietf.org>; 
Tianran Zhou mailto:zhoutian...@huawei.com>>; 
draft-wang-lsr-ifit-node-capability-advertisem...@ietf.org<mailto:draft-wang-lsr-ifit-node-capability-advertisem...@ietf.org>
主题: Re: [Lsr] I,Scope of FIT Capability: a node or a link?

Speaking as WG member – It seems that additional IFIT-specific information is 
required to make this useful and the IGPs are certainly not the case. 
Additionally, the point was made that an IFIT specific information channel 
would anyway be required to provision the telemetry generation.
Thanks,
Acee

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of Jeff 
Tantsura mailto:jefftant.i...@gmail.com>>
Date: Monday, April 6, 2020 at 2:33 PM
To: "Les Ginsberg (ginsberg)" 
mailto:ginsberg=40cisco@dmarc.ietf.org>>,
 Tony Li mailto:tony1ath...@gmail.com>>
Cc: Greg Mirsky mailto:gregimir...@gmail.com>>, 
"draft-song-opsawg-ifit-framew...@ietf.org<mailto:draft-song-opsawg-ifit-framew...@ietf.org>"
 
mailto:draft-song-opsawg-ifit-framew...@ietf.org>>,
 "lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>, 
"ops...@ietf.org<mailto:ops...@ietf.org>" 
mailto:ops...@ietf.org>>, Tianran Zhou 
mailto:zhoutian...@huawei.com>>, 
"draft-wang-lsr-ifit-node-capability-advertisem...@ietf.org<mailto:draft-wang-lsr-ifit-node-capability-advertisem...@ietf.org>"
 
mailto:draft-wang-lsr-ifit-node-capability-advertisem...@ietf.org>

Re: [Lsr] I,Scope of FIT Capability: a node or a link?

[Acee Lindem (acee)]

Speaking as WG member:

With respect to your use case for transit router advertisement… What I was 
unsuccessfully trying to articulate to you during the interim was that the 
management system will typically not know the exact path between two endpoints 
so the use case is flawed. In fact, many times tracing is used by the 
management system to discover the path – as in traceroute…

Thanks,
Acee



From: Tianran Zhou 
Date: Tuesday, April 7, 2020 at 3:22 AM
To: Acee Lindem , Jeff Tantsura , "Les 
Ginsberg (ginsberg)" , Tony Li 

Cc: Greg Mirsky , 
"draft-song-opsawg-ifit-framew...@ietf.org" 
, "lsr@ietf.org" , 
"ops...@ietf.org" , 
"draft-wang-lsr-ifit-node-capability-advertisem...@ietf.org" 

Subject: RE: [Lsr] I,Scope of FIT Capability: a node or a link?

Hi Acee,

About the “IFIT specific information channel”, as in 
https://datatracker.ietf.org/doc/draft-qin-idr-sr-policy-ifit/
we propose to use bgp enabled sr-policy for IFIT auto deployment.
It’s reasonable to incorporate both traffic engineering and monitoring.

Thanks,
Tianran

发件人: Acee Lindem (acee) [mailto:a...@cisco.com]
发送时间: 2020年4月7日 2:54
收件人: Jeff Tantsura ; Les Ginsberg (ginsberg) 
; Tony Li 
抄送: Greg Mirsky ; 
draft-song-opsawg-ifit-framew...@ietf.org; lsr@ietf.org; ops...@ietf.org; 
Tianran Zhou ; 
draft-wang-lsr-ifit-node-capability-advertisem...@ietf.org
主题: Re: [Lsr] I,Scope of FIT Capability: a node or a link?

Speaking as WG member – It seems that additional IFIT-specific information is 
required to make this useful and the IGPs are certainly not the case. 
Additionally, the point was made that an IFIT specific information channel 
would anyway be required to provision the telemetry generation.
Thanks,
Acee

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of Jeff 
Tantsura mailto:jefftant.i...@gmail.com>>
Date: Monday, April 6, 2020 at 2:33 PM
To: "Les Ginsberg (ginsberg)" 
mailto:ginsberg=40cisco@dmarc.ietf.org>>,
 Tony Li mailto:tony1ath...@gmail.com>>
Cc: Greg Mirsky mailto:gregimir...@gmail.com>>, 
"draft-song-opsawg-ifit-framew...@ietf.org<mailto:draft-song-opsawg-ifit-framew...@ietf.org>"
 
mailto:draft-song-opsawg-ifit-framew...@ietf.org>>,
 "lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>, 
"ops...@ietf.org<mailto:ops...@ietf.org>" 
mailto:ops...@ietf.org>>, Tianran Zhou 
mailto:zhoutian...@huawei.com>>, 
"draft-wang-lsr-ifit-node-capability-advertisem...@ietf.org<mailto:draft-wang-lsr-ifit-node-capability-advertisem...@ietf.org>"
 
mailto:draft-wang-lsr-ifit-node-capability-advertisem...@ietf.org>>
Subject: Re: [Lsr] I,Scope of FIT Capability: a node or a link?

+1
Please do not take my comments about link vs node capabilities, as support for 
the solution, they are semantical.

Cheers,
Jeff
On Apr 6, 2020, 8:58 AM -0700, Tony Li 
mailto:tony1ath...@gmail.com>>, wrote:


This discussion is interesting, but please do not ignore the considerable 
feedback from multiple folks indicating that this advertisement does not belong 
in the IGP at all (regardless of scope).
My opinion on that has not changed.


+1

IS-IS is not the correct place to implement Service Discovery mechanisms. The 
management plane already has ample mechanisms for service and capability 
discovery.

Tony


___
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] I,Scope of FIT Capability: a node or a link?

[Acee Lindem (acee)]

Speaking as WG member:

Hi Tianran,

The more I look, the less I like this. We have a YANG infra-structure for 
telemetry data using YANG pub/sub. It is being implement and deployed over both 
NETCONF and proprietary transports. Why would we want to take just this type of 
telemetry out and handle it differently??? See an inline below…

From: Tianran Zhou 
Date: Tuesday, April 7, 2020 at 3:22 AM
To: Acee Lindem , Jeff Tantsura , "Les 
Ginsberg (ginsberg)" , Tony Li 

Cc: Greg Mirsky , 
"draft-song-opsawg-ifit-framew...@ietf.org" 
, "lsr@ietf.org" , 
"ops...@ietf.org" , 
"draft-wang-lsr-ifit-node-capability-advertisem...@ietf.org" 

Subject: RE: [Lsr] I,Scope of FIT Capability: a node or a link?

Hi Acee,

About the “IFIT specific information channel”, as in 
https://datatracker.ietf.org/doc/draft-qin-idr-sr-policy-ifit/
we propose to use bgp enabled sr-policy for IFIT auto deployment.
It’s reasonable to incorporate both traffic engineering and monitoring.

I think this is a terrible idea. Why wouldn’t you just provision it via a YANG 
subscription? An SR Policy could be identified by a  tuple in 
the subscription? There can be many candidate SR policies but only the 
best-path is active. You’d need to update all the candidate policies in order 
to assure your iFIT tracing is enabled on the corresponding SR path. Why would 
you want to put this in BGP?

Acee


Thanks,
Tianran

发件人: Acee Lindem (acee) [mailto:a...@cisco.com]
发送时间: 2020年4月7日 2:54
收件人: Jeff Tantsura ; Les Ginsberg (ginsberg) 
; Tony Li 
抄送: Greg Mirsky ; 
draft-song-opsawg-ifit-framew...@ietf.org; lsr@ietf.org; ops...@ietf.org; 
Tianran Zhou ; 
draft-wang-lsr-ifit-node-capability-advertisem...@ietf.org
主题: Re: [Lsr] I,Scope of FIT Capability: a node or a link?

Speaking as WG member – It seems that additional IFIT-specific information is 
required to make this useful and the IGPs are certainly not the case. 
Additionally, the point was made that an IFIT specific information channel 
would anyway be required to provision the telemetry generation.
Thanks,
Acee

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of Jeff 
Tantsura mailto:jefftant.i...@gmail.com>>
Date: Monday, April 6, 2020 at 2:33 PM
To: "Les Ginsberg (ginsberg)" 
mailto:ginsberg=40cisco@dmarc.ietf.org>>,
 Tony Li mailto:tony1ath...@gmail.com>>
Cc: Greg Mirsky mailto:gregimir...@gmail.com>>, 
"draft-song-opsawg-ifit-framew...@ietf.org<mailto:draft-song-opsawg-ifit-framew...@ietf.org>"
 
mailto:draft-song-opsawg-ifit-framew...@ietf.org>>,
 "lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>, 
"ops...@ietf.org<mailto:ops...@ietf.org>" 
mailto:ops...@ietf.org>>, Tianran Zhou 
mailto:zhoutian...@huawei.com>>, 
"draft-wang-lsr-ifit-node-capability-advertisem...@ietf.org<mailto:draft-wang-lsr-ifit-node-capability-advertisem...@ietf.org>"
 
mailto:draft-wang-lsr-ifit-node-capability-advertisem...@ietf.org>>
Subject: Re: [Lsr] I,Scope of FIT Capability: a node or a link?

+1
Please do not take my comments about link vs node capabilities, as support for 
the solution, they are semantical.

Cheers,
Jeff
On Apr 6, 2020, 8:58 AM -0700, Tony Li 
mailto:tony1ath...@gmail.com>>, wrote:


This discussion is interesting, but please do not ignore the considerable 
feedback from multiple folks indicating that this advertisement does not belong 
in the IGP at all (regardless of scope).
My opinion on that has not changed.


+1

IS-IS is not the correct place to implement Service Discovery mechanisms. The 
management plane already has ample mechanisms for service and capability 
discovery.

Tony


___
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] LSR Virtual Interim Minutes

[Acee Lindem (acee)]

And, for those of you running of things to quarantine watch on your favorite 
streaming service, here is the recording:

https://ietf.webex.com/webappng/sites/ietf/recording/play/015369b6eda543b9a123ac3de1b45203

If I seem a bit flustered in the recording, it was because it took me until the 
fourth presentation to figure out how to use WebEx on multiple computers w/o 
feedback.

Thanks,
Acee

From: Acee Lindem 
Date: Tuesday, April 7, 2020 at 11:32 AM
To: "lsr@ietf.org" 
Subject: LSR Virtual Interim Minutes

I have uploaded the minutes from the virtual interim meeting. Thanks much to 
Yingzhen Qu for taking them.

https://datatracker.ietf.org/meeting/interim-2020-lsr-01/materials/minutes-interim-2020-lsr-01-202004020900

Also, some of you missed signing the blue-sheet. Please send me your name 
affiliation if you missed. I’ll update at the end of this week.

https://www.ietf.org/proceedings/interim-2020-lsr-01/bluesheets/bluesheets-interim-2020-lsr-01-202004020900-00.pdf

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

[Lsr] LSR Virtual Interim Minutes

[Acee Lindem (acee)]

I have uploaded the minutes from the virtual interim meeting. Thanks much to 
Yingzhen Qu for taking them.

https://datatracker.ietf.org/meeting/interim-2020-lsr-01/materials/minutes-interim-2020-lsr-01-202004020900

Also, some of you missed signing the blue-sheet. Please send me your name 
affiliation if you missed. I’ll update at the end of this week.

https://www.ietf.org/proceedings/interim-2020-lsr-01/bluesheets/bluesheets-interim-2020-lsr-01-202004020900-00.pdf

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

Re: [Lsr] I,Scope of FIT Capability: a node or a link?

[Acee Lindem (acee)]

Speaking as WG member – It seems that additional IFIT-specific information is 
required to make this useful and the IGPs are certainly not the case. 
Additionally, the point was made that an IFIT specific information channel 
would anyway be required to provision the telemetry generation.
Thanks,
Acee

From: Lsr  on behalf of Jeff Tantsura 

Date: Monday, April 6, 2020 at 2:33 PM
To: "Les Ginsberg (ginsberg)" , Tony Li 

Cc: Greg Mirsky , 
"draft-song-opsawg-ifit-framew...@ietf.org" 
, "lsr@ietf.org" , 
"ops...@ietf.org" , Tianran Zhou , 
"draft-wang-lsr-ifit-node-capability-advertisem...@ietf.org" 

Subject: Re: [Lsr] I,Scope of FIT Capability: a node or a link?

+1
Please do not take my comments about link vs node capabilities, as support for 
the solution, they are semantical.

Cheers,
Jeff
On Apr 6, 2020, 8:58 AM -0700, Tony Li , wrote:




This discussion is interesting, but please do not ignore the considerable 
feedback from multiple folks indicating that this advertisement does not belong 
in the IGP at all (regardless of scope).
My opinion on that has not changed.


+1

IS-IS is not the correct place to implement Service Discovery mechanisms. The 
management plane already has ample mechanisms for service and capability 
discovery.

Tony


___
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] problem joining interim [Re: A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02]

[Acee Lindem (acee)]

This also explains the mystery of why some Bruno, Robert, and possibly others 
were having problems joining. 
Thanks,
Acee

On 4/3/20, 6:26 AM, "Christian Hopps"  wrote:

Hi Bruno,

This is very useful feedback. It looks like that link the secretary posted 
simply tries to join a standing open room associated with the LSR webex 
account. This is frustrating b/c I sent an email to the secretary asking if I'd 
done things correctly. I'm not sure they are aware that the link they send is 
no good so I will contact them again.

Thanks,
Chris.

> On Apr 3, 2020, at 6:14 AM, bruno.decra...@orange.com wrote:
> 
> Chris, 
> 
> Please see inline.
> 
> 
>> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Christian Hopps
>> Sent: Friday, April 3, 2020 12:00 AM
>> To: Robert Raszuk
>> 
>> 
>> 
>>> On Apr 2, 2020, at 5:17 PM, Robert Raszuk  wrote:
>>> 
>>> Many thx,
>>> R.
>>> 
>>> PS. As we are talking LSR here it is strange that joining virtual LSR 
meeting is not for everyone. I was waiting and tried three times today for host 
approval to join which was not granted. 
>>> 
>> 
>> I am very sorry to hear this! We had 64 participants, at least at one 
point that I saw. I set the meeting up, and I don't believe there is any way to 
exclude anyone in particular, I certainly would never have chosen to do that.
>> 
>> However, Webex has a password requirement when setting up meetings (I 
guess, I tried to not have one, it wouldn't let me) which we included in all 
the details wherever the details were posted, it was "linkstate".
>> 
>> I did notice an email, from webex, during the meeting about a request 
from Bruno to join as guest, but he was in the participant list when I then 
checked.
>> 
> 
> So may be my experience may help for next time(s). See below.
> 
> An email from the IESG secretary was sent on 2020-03-19, saying 
"Information about remote participation: https://ietf.webex.com/meet/lsr "
> Hence I used that URL.
> On this webex, the meeting did not start on time so I've waited for some 
time. Then 10-15 minutes past the start, I decided to 'notify the host', but 
never got accepted on the webex.
> At that point I assumed a technical issue with webex and monitored the 
mailing list, but no one was complaining, which is not inline with typical IETF 
reaction ;-) .
> So I assumed the error was only on my side and I searched for more emails 
and found one from Chris (2020-03-31) saying that the URL was 
https://ietf.webex.com/ietf/j.php?MTID=mbef20efa9e66c7e97f9d6b18ea84eca8 
> And this one worked fine.
> My guess is that the 'interim' webex did not use the 'lsr' webex. Also 
the 'official' notification from the IESG secretary with the incorrect webex 
URL did not helped.
> 
> --Bruno
> 
>> I didn't receive any other emails like that (and FWIW I had 5 windows 
over 2 monitors going at once trying to manage all this, so noticing the 1 
email was lucky).
>> 
>> Did it let you skip entering a password (or did it not offer the option 
in the first place)?
>> 
>> It would be good to figure this out before the next interim.
>> 
>> Thanks,
>> Chris.
>> 
>> ___
>> Lsr mailing list
>> Lsr@ietf.org
>> https://www.ietf.org/mailman/listinfo/lsr
> 
> 
_
> 
> 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



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

Re: [Lsr] problem joining interim [Re: A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02]

[Acee Lindem (acee)]

As host of the meeting, I didn’t see any indication that you were waiting in 
the lobby.
Thanks,
Acee

From: Robert Raszuk 
Date: Thursday, April 2, 2020 at 6:10 PM
To: Christian Hopps 
Cc: "Les Ginsberg (ginsberg)" , "lsr@ietf.org" 
, Jeff Tantsura , Tianran Zhou 
, Acee Lindem , wangyali 

Subject: Re: [Lsr] problem joining interim [Re: A new version of I-D, 
draft-liu-lsr-isis-ifit-node-capability-02]

Hi Chris,

I never noticed the password ...

Just few days back I participated in IDR and no password was needed or perhaps 
webex invite link contained a token relaxing from needing one.

Cheers,
R.

On Fri, Apr 3, 2020 at 12:00 AM Christian Hopps 
mailto:cho...@chopps.org>> wrote:


> On Apr 2, 2020, at 5:17 PM, Robert Raszuk 
> mailto:rob...@raszuk.net>> wrote:
>
> Many thx,
> R.
>
> PS. As we are talking LSR here it is strange that joining virtual LSR meeting 
> is not for everyone. I was waiting and tried three times today for host 
> approval to join which was not granted.
>

I am very sorry to hear this! We had 64 participants, at least at one point 
that I saw. I set the meeting up, and I don't believe there is any way to 
exclude anyone in particular, I certainly would never have chosen to do that.

However, Webex has a password requirement when setting up meetings (I guess, I 
tried to not have one, it wouldn't let me) which we included in all the details 
wherever the details were posted, it was "linkstate".

I did notice an email, from webex, during the meeting about a request from 
Bruno to join as guest, but he was in the participant list when I then checked. 
I didn't receive any other emails like that (and FWIW I had 5 windows over 2 
monitors going at once trying to manage all this, so noticing the 1 email was 
lucky).

Did it let you skip entering a password (or did it not offer the option in the 
first place)?

It would be good to figure this out before the next interim.

Thanks,
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] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02

[Acee Lindem (acee)]

Speak as WG Member... 

On 4/1/20, 8:08 AM, "Acee Lindem (acee)"  wrote:

There is also a difference between some of the existing applications 
advertised in IGP capabilities. For example, MSD is used with the routing 
information to construct SR paths. The information for all these OAM mechanisms 
doesn't share this affinity. Also, it seems like a slippery slope in what is 
needed for each of the mechanism. 
Thanks,
Acee

On 4/1/20, 4:01 AM, "Lsr on behalf of Tianran Zhou"  wrote:

Hi Les,

Thanks very much for your suggestion. I have a quick look at rfc6823. 
Sounds like a good idea. I will think about it.

Cheers,
Tianran

-Original Message-
From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com] 
Sent: Wednesday, April 1, 2020 1:47 PM
To: Tianran Zhou ; Christian Hopps 

Cc: wangyali ; lsr@ietf.org
Subject: RE: [Lsr] A new version of I-D, 
draft-liu-lsr-isis-ifit-node-capability-02

Tianran -

I am very much in agreement with the points Chris has made.

IGPs do not exist to advertise capabilities/configure applications - 
which seems to me to be what you are proposing here.
The fact that you can easily define the encodings does not make it the 
right thing to do.

This issue was discussed at length in the context of 
https://tools.ietf.org/html/rfc6823 . If you were proposing to use GENAPP I 
would not object - though I do think Chris has correctly pointed out that 
NETCONF/YANG is likely a more appropriate solution for your use case.

   Les


> -Original Message-
> From: Tianran Zhou 
> Sent: Tuesday, March 31, 2020 7:53 PM
> To: Christian Hopps 
> Cc: wangyali ; Les Ginsberg (ginsberg) 
> ; lsr@ietf.org
> Subject: RE: [Lsr] A new version of I-D, 
> draft-liu-lsr-isis-ifit-node-capability-02
> 
> Hi Chris,
> Thanks for your quick reply, and please see inline.
> 
> Cheers,
> Tianran
> 
> -Original Message-
> From: Christian Hopps [mailto:cho...@chopps.org]
> Sent: Wednesday, April 1, 2020 10:00 AM
> To: Tianran Zhou 
> Cc: Christian Hopps ; wangyali 
> ; Les Ginsberg (ginsberg) 
; 
> lsr@ietf.org
> Subject: Re: [Lsr] A new version of I-D, 
> draft-liu-lsr-isis-ifit-node-capability-02
> 
> 
> 
> > On Mar 31, 2020, at 9:28 PM, Tianran Zhou 
> wrote:
> >
> > ZTR> Let's not boil the ocean to compare NETCONF/YANG or routing
> protocol, which is better. But I did not see the modification to 
> routing protocol with some TLVs is a heavy work, or more complex than 
> NETCONF/YANG.  I see both are available and useful.
> 
> I'm not sure what you mean by boiling the ocean. I'm saying that YANG 
> is built and intended for querying capabilities and configuring 
> routers. Why isn't that where you are looking first for configuring 
your monitoring application?
> 
> ZTR> I know NETCONF can do both query and configuration. And I know
> resent YANG-Push improvements to reduce the polling.  But routing 
> protocol solutions are also widely used for this. There are already 
> many RFCs and implementation practices. We considered both ways, and 
> aimed for different scenarios.
> 
> You don't see the major difference between writing a YANG model vs 
> modifying all of the standard IETF routing protocols?
> 
> ZTR> I know many differences between NETCONF and routing protocol.
> There are many details on both interfaces, implementations, scenarios 
> when comparing them. That's what I mean boil the ocean.
> Here I do not know what's the "major difference" you mean?
> 
> Thanks,
> 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] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02

[Acee Lindem (acee)]

There is also a difference between some of the existing applications advertised 
in IGP capabilities. For example, MSD is used with the routing information to 
construct SR paths. The information for all these OAM mechanisms doesn't share 
this affinity. Also, it seems like a slippery slope in what is needed for each 
of the mechanism. 
Thanks,
Acee

On 4/1/20, 4:01 AM, "Lsr on behalf of Tianran Zhou"  wrote:

Hi Les,

Thanks very much for your suggestion. I have a quick look at rfc6823. 
Sounds like a good idea. I will think about it.

Cheers,
Tianran

-Original Message-
From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com] 
Sent: Wednesday, April 1, 2020 1:47 PM
To: Tianran Zhou ; Christian Hopps 

Cc: wangyali ; lsr@ietf.org
Subject: RE: [Lsr] A new version of I-D, 
draft-liu-lsr-isis-ifit-node-capability-02

Tianran -

I am very much in agreement with the points Chris has made.

IGPs do not exist to advertise capabilities/configure applications - which 
seems to me to be what you are proposing here.
The fact that you can easily define the encodings does not make it the 
right thing to do.

This issue was discussed at length in the context of 
https://tools.ietf.org/html/rfc6823 . If you were proposing to use GENAPP I 
would not object - though I do think Chris has correctly pointed out that 
NETCONF/YANG is likely a more appropriate solution for your use case.

   Les


> -Original Message-
> From: Tianran Zhou 
> Sent: Tuesday, March 31, 2020 7:53 PM
> To: Christian Hopps 
> Cc: wangyali ; Les Ginsberg (ginsberg) 
> ; lsr@ietf.org
> Subject: RE: [Lsr] A new version of I-D, 
> draft-liu-lsr-isis-ifit-node-capability-02
> 
> Hi Chris,
> Thanks for your quick reply, and please see inline.
> 
> Cheers,
> Tianran
> 
> -Original Message-
> From: Christian Hopps [mailto:cho...@chopps.org]
> Sent: Wednesday, April 1, 2020 10:00 AM
> To: Tianran Zhou 
> Cc: Christian Hopps ; wangyali 
> ; Les Ginsberg (ginsberg) ; 
> lsr@ietf.org
> Subject: Re: [Lsr] A new version of I-D, 
> draft-liu-lsr-isis-ifit-node-capability-02
> 
> 
> 
> > On Mar 31, 2020, at 9:28 PM, Tianran Zhou 
> wrote:
> >
> > ZTR> Let's not boil the ocean to compare NETCONF/YANG or routing
> protocol, which is better. But I did not see the modification to 
> routing protocol with some TLVs is a heavy work, or more complex than 
> NETCONF/YANG.  I see both are available and useful.
> 
> I'm not sure what you mean by boiling the ocean. I'm saying that YANG 
> is built and intended for querying capabilities and configuring 
> routers. Why isn't that where you are looking first for configuring your 
monitoring application?
> 
> ZTR> I know NETCONF can do both query and configuration. And I know
> resent YANG-Push improvements to reduce the polling.  But routing 
> protocol solutions are also widely used for this. There are already 
> many RFCs and implementation practices. We considered both ways, and 
> aimed for different scenarios.
> 
> You don't see the major difference between writing a YANG model vs 
> modifying all of the standard IETF routing protocols?
> 
> ZTR> I know many differences between NETCONF and routing protocol.
> There are many details on both interfaces, implementations, scenarios 
> when comparing them. That's what I mean boil the ocean.
> Here I do not know what's the "major difference" you mean?
> 
> Thanks,
> 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] 答复: 答复: New Version Notification for draft-wang-lsr-ospf-ifit-node-capability-02

[Acee Lindem (acee)]

Hi Yali, 

Thanks for the quick turn around with the version incorporating my comments. 

https://datatracker.ietf.org/doc/draft-wang-lsr-ifit-node-capability-advertisement/

This is the organization of draft that I had in mind. It may need some more 
references to 
https://datatracker.ietf.org/doc/draft-song-opsawg-ifit-framework/ but that can 
come if the work progresses in OPSAWG.  Also, I was surprised not to see more 
discussion of the identifiers and name spaces in the base framework document. 

Thanks,
Acee 

On 3/16/20, 3:52 AM, "wangyali"  wrote:

Dear Acee,

Many thanks for your comments. Taking your suggestion I am writing a new 
LSR draft to combine the OSPF draft, ISIS draft and BGP-LS draft and will add 
more context on how to use the IFIT Capability information.

Best regards,
Yali

-邮件原件-
    发件人: Acee Lindem (acee) [mailto:a...@cisco.com] 
发送时间: 2020年3月15日 2:18
收件人: wangyali ; lsr@ietf.org
抄送: IDR List 
主题: Re: 答复: [Lsr] New Version Notification for 
draft-wang-lsr-ospf-ifit-node-capability-02

Hi Yali,
Please add some more context to the draft as to how the information will be 
used. I say draft rather than drafts since you can really combine the OSPF 
draft, IS-IS draft, and BGP-LS draft into a single LSR document. For RFC 8379, 
we included the BGP-LS specification in the OSPF draft and the IDR chairs have 
agreed to this for simple encodings such as this one.  
Thanks,
Acee

On 3/10/20, 4:46 AM, "wangyali"  wrote:

Dear Acee,

Thanks a lot for your comments. I have revised the title of drafts and 
will take your suggestion to add more text on how to use the IFIT Capability 
information, once the submission is opened. Here is my quick reply:

IFIT is deployed in a specific domain referred as the IFIT domain. One 
network domain may consists of multiple IFIT domain. Within the IFIT domain, 
one or more IFIT-options are added into packet at the IFIT-enabled head node 
that is referred to as the “IFIT encapsulating node”. Then IFIT data fields MAY 
be updated by IFIT transit nodes that the packet traverses. Finally, the data 
fields are removed at a device that is referred to as the “IFIT decapsulating 
node”. 

The IFIT data fields must not leak to other domains. So, the IFIT 
encapsulating node need to know if the decapsulating node is able to support 
the IFIT capability. So that it can decide whether to add the IFIT-option or 
not.

The solution is similar to RFC8491. We use IGP to advertise the 
capability, so that head node can use. By using BGP-LS, a centralized 
controller can also learn the IFIT Capability of nodes to determine whether a 
particular IFIT Option type can be supported in a given network.

Best regards,
Yali

-邮件原件-----
    发件人: Acee Lindem (acee) [mailto:a...@cisco.com] 
发送时间: 2020年3月9日 18:30
收件人: wangyali ; lsr@ietf.org
主题: Re: [Lsr] New Version Notification for 
draft-wang-lsr-ospf-ifit-node-capability-02

Hi Yali,

A couple of very basic comments on these drafts. They are definitely 
not ready for consideration. 

1. IFIT is never expanded as an acronym. Seems it should be as 
early as the title. 

  OSPF extensions for Advertising In-Situ Flow Information 
Telemetry (IFIT) Capability

   2. You probably could come up with a more succinct acronym for IFIT. 

   3. The has no specification of how the capabilities are used. Are 
they purely informational? 

Thanks,
Acee

 


On 3/9/20, 4:33 AM, "Lsr on behalf of wangyali"  wrote:

Dear all,

I'm Yali. Following is a new version of I-D, 
draft-wang-lsr-ospf-ifit-node-capability-02 I submitted recently.

Please let me know your questions and comments. Thank you.

>>>>>>>>>>>
Name:   draft-wang-lsr-ospf-ifit-node-capability
Revision:   02
Title:  Extensions to OSPF for Advertising IFIT Node 
Capability
Document date:  2020-03-09
Group:  Individual Submission
Pages:  7
URL:
https://www.ietf.org/internet-drafts/draft-wang-lsr-ospf-ifit-node-capability-02.txt
Status: 
https://datatracker.ietf.org/doc/draft-wang-lsr-ospf-ifit-node-capability/
Htmlized:   
https://tools.ietf.org/html/draft-wang-lsr-ospf-ifit-node-capability-02
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-wang-lsr-ospf-ifit-node-capability
Diff:   
https://w

Re: [Lsr] Agenda Posted Re: Link State Routing (lsr) WG Virtual Meeting: 2020-04-02

[Acee Lindem (acee)]

While I never concluded the discussion (until now), but there is very little 
support for the requirement from operators. The flooding reflector draft did 
have the most support with support from one operator who was not a co-author on 
the draft. We could move these presentations to the second session and the 
flood parameters to the first session. However, given the paucity of support, I 
think the direction on flooding parameters is much more pressing and deserves 
more time. At the same time, I don’t see a problem with updates on the drafts 
as long as the drafts themselves have been updated.

Thanks,
Acee

From: Tony Przygienda 
Date: Tuesday, March 24, 2020 at 8:58 PM
To: Alvaro Retana 
Cc: "lsr-cha...@ietf.org" , "lsr@ietf.org" , 
Martin Vigoureux , Yingzhen Qu 
, Chris Bowers 
Subject: Re: [Lsr] Agenda Posted Re: Link State Routing (lsr) WG Virtual 
Meeting: 2020-04-02
Resent-From: 
Resent-To: Acee Lindem , Yingzhen Qu , 
Christian Hopps 
Resent-Date: Tuesday, March 24, 2020 at 8:58 PM

any chance people can post invite.ics I cn import into my agenda? it's really 
tedious with the timezones & every group announcing the time in different way 
;-)

Having said that, if we present this topic we could plug in 
draft-przygienda-lsr-flood-reflection update preso in case Chris wants to do it 
(for me it's 6am in the morning so I pass). We had an update with readability 
comments and also some procedure/format clarifications. Yes, I  think on the 
list there were voices supporting work in this area & backing this draft. From 
our side we see that it 1. works & 2. seems to solve a problem for several 
customers within the parameters they set.

--- tony

On Tue, Mar 24, 2020 at 3:15 PM Alvaro Retana 
mailto:alvaro.ret...@futurewei.com>> wrote:
On March 24, 2020 at 1:42:29 PM, Yingzhen Qu wrote:


[Speaking as a WG participant.]


> Now we have two interim sessions scheduled, please find updated agenda here:
> https://datatracker.ietf.org/meeting/interim-2020-lsr-01/materials/agenda-interim-2020-lsr-01-lsr-01.html
>
> If there is any question, please let us know.


Dear Chairs:

Hi!


I have a question, perhaps an early agenda bash.

The agenda includes presentations of the Area Proxy/TTZ drafts [*].

Acee had sent a message to the WG "asking whether there is a really a strong 
requirement to advance one or more of these documents" [1]. I saw a couple of 
replies on the list supporting this type of work, but I didn't see a discussion 
related to what specific requirements/issues/"places in the network" should be 
addressed.

What was the conclusion of the thread?  Are we ready to start/continue 
discussing the drafts?


Thanks!

Alvaro.


[*] Disclaimer: I am an author on the TTZ draft -- cc'ing Martin just in case 
an AD is needed at this early stage.

[1] https://mailarchive.ietf.org/arch/msg/lsr/Dc1YZd6KgKrwx3ooqLcdW3C6qPY/

___
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] LSR Interim Invitations (.ics attached)

[Acee Lindem (acee)]

Thanks Much Yingzhen! I will text Tony P 15 minutes before the start of each 
meeting 😉

Given that the only routing WGs that are meeting next week are LSR and IDR, I 
hope that many of you will have time to read the drafts.

Thanks,
Acee

From: Yingzhen Qu 
Date: Tuesday, March 24, 2020 at 11:45 PM
To: "lsr@ietf.org" , "lsr-cha...@ietf.org" 
Subject: LSR Interim Invitations (.ics attached)
Resent-From: 
Resent-To: Acee Lindem , Yingzhen Qu , 
Christian Hopps 
Resent-Date: Tuesday, March 24, 2020 at 11:44 PM

Hi all,

Attached are the invite.ics files for LSR Interim sessions with Webex info. 
Please let me know if there is any questions.

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

Re: [Lsr] AD Review of draft-ietf-isis-mpls-elc-10

[Acee Lindem (acee)]

Hi Alvaro, 

On 3/23/20, 5:17 AM, "Peter Psenak"  wrote:

Hi Alavaro,

On 20/03/2020 19:23, Alvaro Retana wrote:
> On March 20, 2020 at 10:34:59 AM, Peter Psenak wrote:
> 
> 
> Peter:
> 
> 
> I don't really see why one would affect the other.

 I agree. BMI-MSD is an egress capability and ERLD-MSD is an ingress
 capability. While they may be related in the internal ASIC 
implementation,
 they are independent from a capability perspective.
>>>
>>> Please write that then.
>>
>> there are many MSDs defined already, are we going to write that the new
>> MSD type is not interacting with any other MSD each time we define a new
>> one?
> 
> Yes, when they could be related, we are.  More importantly, the reason
> why the will not interact, which is what Acee’s text points to.

honestly I do not see a reason to say that they do not interact. Because 
if I use your logic I would have to mention hundred other node 
capabilities that ERLD-MSD is not interacting with. My logic is that if 
something interacts it needs to be specified, if it does not, it does 
not need to be.

I agree. It seems like a slippery slope to specifically call out protocol 
elements which not related from a protocol standpoint. 

Thanks,
Acee

> 
> BTW, according to the registry there are only 2 MSDs defined:
> 
https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml#igp-msd-types

there are more defined for SRv6 - draft-ietf-lsr-isis-srv6-extensions-06.

thanks,
Peter


> 
> 
> Alvaro.
> 
> 



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

Re: [Lsr] AD Review of draft-ietf-isis-mpls-elc-10

[Acee Lindem (acee)]

Hi Peter Alvaro, 

On 3/20/20, 8:58 AM, "Peter Psenak"  wrote:

On 20/03/2020 11:59, Alvaro Retana wrote:
> On March 20, 2020 at 6:22:38 AM, Peter Psenak wrote:
> 
> 
> ...
>>> Besides the in-line comments, I want to point out here that this
>>> specification is incomplete. It needs to have (1) a formal description 
of
>>> the new MSD-Type (similar to §5/rfc8491), and (2) a discussion of the
>>> interaction with the BMI-MSD.
>>
>> sorry, I missed it.
>>
>> Entropy Readable Label Depth is defined in rfc8662.
>>
>> I have modified the text as foolows:
>>
>> "A new MSD-type [RFC8491], called ERLD-MSD is defined to
>> advertise the ERLD [RFC8662] of a given router. A MSD-Type code 2
>> has been assigned by IANA for EARLD-MSD."
>>
>> Would that be good enough?
> 
> Not quite.  According to rfc8662, when a new MSD is defined, the
> document MUST indicate the meaning of the absence of the MSD
> advertisement.  For example, it says this about the BMI-MSD: "The
> absence of BMI-MSD advertisements indicates only that the advertising
> node does not support advertisement of this capability."

ok, I  will add that.

> 
> 
> Also, I need you to talk about the interaction between ERLD-MSD and
> BMI-MSD.  If both are present, what should happen?  Should one take
> precedence, should both be ignored, can they coexist without issues???

how are BMI-MSD and EARLD-MSD related?

BMI-MSD signals the total number of MPLS labels that can be imposed.

EARLD-MSD - is defined as the number of labels a router can both:

a.  Read in an MPLS packet received on its incoming interface(s)
(starting from the top of the stack).

b.  Use in its load-balancing function.

I don't really see why one would affect the other.

I agree. BMI-MSD is an egress capability and ERLD-MSD is an ingress capability. 
While they may be related in the internal ASIC implementation, they are 
independent from a capability perspective. 

Thanks,
Acee


thanks,
Peter

> 
> 
> Thanks!
> 
> Alvaro.
> 
> 



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

Re: [Lsr] Link State Routing (lsr) WG Virtual Meeting: 2020-04-02

[Acee Lindem (acee)]

This will take the place of the LSRs meetings that were scheduled to take place 
in Vancouver. We will honor the existing agenda requests. However, we intend to 
provide the WG document status prior on the list as opposed to taking interim 
meeting time. 

Thanks,
Acee

On 3/19/20, 3:54 PM, "Lsr on behalf of IESG Secretary"  wrote:

The Link State Routing (lsr) Working Group will hold
a virtual interim meeting on 2020-04-02 from 09:00 to 12:00 
America/New_York.

Agenda:
TBD 

Information about remote participation:
https://ietf.webex.com/meet/lsr

___
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] AD Review of draft-ietf-isis-mpls-elc-10

[Acee Lindem (acee)]

Hi Alvaro - Thanks for the extensive review. 

Hi Peter - Thanks for the addressing all the comments. 

See one inline. 

On 3/16/20, 7:52 AM, "Peter Psenak"  wrote:

Hi Alvaro,

thanks for your comments.

Let's first close the ISIS ELC draft before starting to work on OSPF 
one, as many comments are common and will be applicable to both ISIS and 
OSPF variants.

Please see inline (##PP):

On 29/02/2020 06:00, Alvaro Retana wrote:
> Dear authors:
> 
> This is my review of draft-ietf-isis-mpls-elc-10.  I reviewed this
> document alongside draft-ietf-ospf-mpls-elc-12, so many comments are
> the same/similar.  Thank you for the work in both of them!
> 
> Besides the in-line comments, I want to point out here that this
> specification is incomplete.  It needs to have (1) a formal
> description of the new MSD-Type (similar to §5/rfc8491), and (2) a
> discussion of the interaction with the BMI-MSD.
> 
> I will progress both documents together, so I will wait for both of
> them to address my comments before starting their IETF LC.
> 
> Thanks!!
> 
> Alvaro.
> 
> 
> [Line numbers from idnits.]
> 
> ...
> 18Abstract
> 
> 20   Multiprotocol Label Switching (MPLS) has defined a mechanism 
to load-
> 21   balance traffic flows using Entropy Labels (EL).  An ingress 
Label
> 22   Switching Router (LSR) cannot insert ELs for packets going 
into a
> 23   given Label Switched Path (LSP) unless an egress LSR has 
indicated
> 24   via signaling that it has the capability to process ELs, 
referred to
> 25   as Entropy Label Capability (ELC), on that tunnel.  In 
addition, it
> 26   would be useful for ingress LSRs to know each LSR's 
capability for
> 27   reading the maximum label stack depth and performing 
EL-based load-
> 28   balancing, referred to as Entropy Readable Label Depth 
(ERLD).  This
> 29   document defines a mechanism to signal these two 
capabilities using
> 30   IS-IS.  These mechanisms are particularly useful, where label
> 31   advertisements are done via protocols like IS-IS.
> 
> [nit] s/  /as the Entropy Label Capability

##PP
done

> 
> [minor] "protocols like IS-IS"  That last sentence sounds as if there
> were other options; for example advertise labels with OSPF and then
> use the extensions here.  It's just a minor point, but I think that
> maybe that last sentence is not needed.

##PP
removed last sentence

> 
> 
> ...
> 811.  Introduction
> 
> 83   [RFC6790] describes a method to load-balance Multiprotocol 
Label
> 84   Switching (MPLS) traffic flows using Entropy Labels (EL).  
"The Use
> 85   of Entropy Labels in MPLS Forwarding" [RFC6790] introduces 
the
> 86   concept of Entropy Label Capability (ELC) and defines the 
signalings
> 87   of this capability via MPLS signaling protocols.  Recently,
> 88   mechanisms have been defined to signal labels via link-state 
Interior
> 89   Gateway Protocols (IGP) such as IS-IS
> 90   [I-D.ietf-isis-segment-routing-extensions].  In such 
scenarios, the
> 91   defined signaling mechanisms are inadequate.  This draft 
defines a
> 92   mechanism to signal the ELC using IS-IS.  This mechanism is 
useful
> 93   when the label advertisement is also done via IS-IS.
> 
> [nit] s/"The Use of Entropy Labels in MPLS Forwarding" [RFC6790]/It also

##PP
done
> 
> [nit] s/signalings/signaling

##PP
done

> 
> [nit] "In such scenarios, the defined signaling mechanisms are
> inadequate." Take this sentence out: the rest of the paragraph is
> enough.

##PP
done
> 
> 
> 95   In addition, in the cases where LSPs are used for whatever 
reasons
> 96   (e.g., SR-MPLS [I-D.ietf-spring-segment-routing-mpls]), it 
would be
> 97   useful for ingress LSRs to know each intermediate LSR's 
capability of
> 98   reading the maximum label stack depth and performing 
EL-based load-
> 99   balancing.  This capability, referred to as Entropy Readable 
Label
> 100  Depth (ERLD) as defined in 
[I-D.ietf-mpls-spring-entropy-label] may
> 101  be used by ingress LSRs to determine the position of the EL 
label in
> 102  the stack, and whether it's necessary to insert multiple ELs 
at
> 103  different positions in the label stack.
> 
> [nit] s/in the cases where LSPs are used for whatever reasons/in cases
> where LSPs are used

##PP
done
> 
> 
> 105   2.  Terminology

Re: [Lsr] 答复: New Version Notification for draft-wang-lsr-ospf-ifit-node-capability-02

[Acee Lindem (acee)]

Hi Yali,
Please add some more context to the draft as to how the information will be 
used. I say draft rather than drafts since you can really combine the OSPF 
draft, IS-IS draft, and BGP-LS draft into a single LSR document. For RFC 8379, 
we included the BGP-LS specification in the OSPF draft and the IDR chairs have 
agreed to this for simple encodings such as this one.  
Thanks,
Acee

On 3/10/20, 4:46 AM, "wangyali"  wrote:

Dear Acee,

Thanks a lot for your comments. I have revised the title of drafts and will 
take your suggestion to add more text on how to use the IFIT Capability 
information, once the submission is opened. Here is my quick reply:

IFIT is deployed in a specific domain referred as the IFIT domain. One 
network domain may consists of multiple IFIT domain. Within the IFIT domain, 
one or more IFIT-options are added into packet at the IFIT-enabled head node 
that is referred to as the “IFIT encapsulating node”. Then IFIT data fields MAY 
be updated by IFIT transit nodes that the packet traverses. Finally, the data 
fields are removed at a device that is referred to as the “IFIT decapsulating 
node”. 

The IFIT data fields must not leak to other domains. So, the IFIT 
encapsulating node need to know if the decapsulating node is able to support 
the IFIT capability. So that it can decide whether to add the IFIT-option or 
not.

The solution is similar to RFC8491. We use IGP to advertise the capability, 
so that head node can use. By using BGP-LS, a centralized controller can also 
learn the IFIT Capability of nodes to determine whether a particular IFIT 
Option type can be supported in a given network.

Best regards,
Yali

-邮件原件-
    发件人: Acee Lindem (acee) [mailto:a...@cisco.com] 
发送时间: 2020年3月9日 18:30
收件人: wangyali ; lsr@ietf.org
主题: Re: [Lsr] New Version Notification for 
draft-wang-lsr-ospf-ifit-node-capability-02

Hi Yali,

A couple of very basic comments on these drafts. They are definitely not 
ready for consideration. 

1. IFIT is never expanded as an acronym. Seems it should be as early as 
the title. 

  OSPF extensions for Advertising In-Situ Flow Information 
Telemetry (IFIT) Capability

   2. You probably could come up with a more succinct acronym for IFIT. 

   3. The has no specification of how the capabilities are used. Are they 
purely informational? 

Thanks,
Acee

 


On 3/9/20, 4:33 AM, "Lsr on behalf of wangyali"  wrote:

Dear all,

I'm Yali. Following is a new version of I-D, 
draft-wang-lsr-ospf-ifit-node-capability-02 I submitted recently.

Please let me know your questions and comments. Thank you.

>>>>>>>>>>>
Name:   draft-wang-lsr-ospf-ifit-node-capability
Revision:   02
Title:  Extensions to OSPF for Advertising IFIT Node Capability
Document date:  2020-03-09
Group:  Individual Submission
Pages:  7
URL:
https://www.ietf.org/internet-drafts/draft-wang-lsr-ospf-ifit-node-capability-02.txt
Status: 
https://datatracker.ietf.org/doc/draft-wang-lsr-ospf-ifit-node-capability/
Htmlized:   
https://tools.ietf.org/html/draft-wang-lsr-ospf-ifit-node-capability-02
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-wang-lsr-ospf-ifit-node-capability
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-wang-lsr-ospf-ifit-node-capability-02

Abstract:
   This document defines a way for an Open Shortest Path First (OSPF)
   router originating the RI LSA to announce IFIT node capabilities
   within the entire routing domain.  A new optional TLV is extended to
   the OSPF RI Opaque LSA [RFC7770] to carry the IFIT node capability
   information.  Such advertisements enable IFIT applications in an
   operational network domain.  Here, the term "OSPF" includes both
   OSPFv2 and OSPFv3.

Best regards,
Yali WANG
___
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] 答复: Question about OSPF (transit area routing loop)

[Acee Lindem (acee)]

Hi Aijun,
Yes – it seems ASBR-2 should be removed from the diagram.
Thanks,
Acee

From: Lsr  on behalf of Aijun Wang 

Date: Wednesday, March 11, 2020 at 6:48 AM
To: 'Sergey SHpenkov' , "lsr@ietf.org" 

Subject: [Lsr] 答复: Question about OSPF (transit area routing loop)

Hi, Sergey:

If so, ABR-3 should also receive this SumLSA-4 for the ASBR(with cost 300), and 
then prefer the path via ABR-2 to reach ASBR(with cost 20).
Then there will be no loop then?

Or, how many SumLAS-4 will be advertised by ABR-1? If it selects and advertises 
only one (3 or 300), then the loop will not be emerged.
Currently, it seems it advertises this SumLAS-4 with the cost 300 to RT_1 and 
with the cost 3 to ABR-3?


Best Regards.

Aijun Wang
China Telecom

发件人: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] 代表 Sergey SHpenkov
发送时间: 2020年2月26日 15:20
收件人: lsr@ietf.org
主题: Re: [Lsr] Question about OSPF (transit area routing loop)

Acee,

Because ABR_1 creates SumLSA-4 for the ASBR not from the backbone area. The 
cost of SumLSA-4 for ASBR is 300.

Thanks,
Sergey

вт, 25 февр. 2020 г. в 22:44, Acee Lindem (acee) 
mailto:a...@cisco.com>>:
Hi Sergey,
I don’t see why RT_1 wouldn’t go through ABR_1 to get to the ASBR.
Thanks,
Acee

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of 
Sergey SHpenkov 
mailto:sergey.v.shpen...@gmail.com>>
Date: Tuesday, February 25, 2020 at 2:38 PM
To: "l...@ietf..org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>
Subject: [Lsr] Question about OSPF (transit area routing loop)

Hi,
In section 16.3 of the OSPF RFC 2328 standard, it is stated that all ABR routers
connected to a transit area are required to check the sumLSA contained within
this area in order to possibly improve the intra-area and inter-area backbone 
routes
for themselves.

See the picture:
[cid:image001.png@01D5F7B9.DD7F1000]
The RT_1 and ABR_3 routers will use different paths to the ASBR router:

ABR_3 -> RT_1 -> ABR_1 -> ASBR = cost 3
RT_1 -> ABR_3 -> ABR_2 -> ASBR = cost 21

route loop between RT_1 and ABR_3

Please explain this situation

Thanks,
Sergey

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

Re: [Lsr] "Legal" endpoint behaviors [draft-ietf-lsr-isis-srv6-extensions-06.txt]

[Acee Lindem (acee)]

I looked at this again and the long Email thread and agree with Peter, Les, and 
Joel that we don't need a protocol specific registry for the Endpoint behaviors 
and associated SIDs. 
Thanks,
Acee

On 3/11/20, 1:42 PM, "Lsr on behalf of Joel M. Halpern"  wrote:

It does seem to me that using a registry to capture the relationship 
between the OSPF or IS-IS advertisement (TLV, sub-TLV, ...) and the SR 
behavior (as defined in the NP registry and subsequent additions) is 
useful.  I would not want to have to respin the base draft to add 
additional behaviors.  We use registries for a reason.

Now, if the advertisement registry has a note column, we could use that 
to record the information.  As far as I know the current registries are 
not well-structured for such auxiliary information.

Yours,
Joel

On 3/11/2020 11:52 AM, Christian Hopps wrote:
> 
> 
>> On Mar 11, 2020, at 10:38 AM, Les Ginsberg (ginsberg) 
 wrote:
>>
>> Chris -
>>
>>
>>>
>>> Do you think we should get rid of the "used in" columns in the IS-IS 
TLV and
>>> sub-TLV registries? The documents that define those TLVs and sub-TLVs
>>> already indicate which PDUs and TLVs they go in, so why do we need that
>>> info in the registry?
>>>
>> [Les:] The difference for me is that the definition of sub-TLVs 
associated with the related set of TLVs is scattered across multiple RFCs. The 
additional information in the registry allows us to find this information in 
one place.
>> Here, there is only one relevant IS-IS draft on this technology (SRv6). 
If the set of behaviors which can be advertised in IS-IS changes, then an 
additional IS-IS document (or a bis) will be written - and it likely would be 
required for other reasons.
>>
>> We still may not agree - but I hope we at least understand each other 
better.
> 
> Is the SR network programming document expected to respin a -bis for 
adding a behavior?
> 
> Anyway, unless someone else thinks this is important, I guess we can just 
revisit it when the next SR End behavior gets added and we're faced with 
re-spinning this document, the OSPF companion document, and whatever other 
protocols support documents for advertising the new behavior, in order to 
support it (rather than e.g., it just going directly in a base document or a 
combined protocols document and updating a couple registries).
> 
> Thanks,
> Chris.
> [as WG member]
> 
>>Les
>>
>> ___
>> 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 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] "Legal" endpoint behaviors [draft-ietf-lsr-isis-srv6-extensions-06.txt]

[Acee Lindem (acee)]

Hi Peter, Chris, 

I agree that a number of IS-IS IANA registries have this level of 
specification. For example:

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

Thanks,
Acee

On 3/9/20, 8:28 AM, "Lsr on behalf of Christian Hopps"  wrote:



> On Mar 9, 2020, at 6:36 AM, Peter Psenak 
 wrote:
> 
> Hi Chris,
> 
> On 07/03/2020 15:46, Christian Hopps wrote:
>> 1) I think we should have an IANA registry instead of just a table 
defined in section 10 of draft-ietf-lsr-isis-srv6-extensions-06.
>> The registry could be cross-referenced by and to "SRv6 Endpoint 
Behaviors" for each protocol carrying these behaviors (IS-IS, OSPFv3, ...). 
If/when new behaviors are added they could then update where they are supposed 
to be advertised in the underlying protocols.
> 
> why do we need a protocol specific registry to advertise values that are 
defined in another protocol independent registry? I have never seen such a 
duplication. Looks completely redundant to me.

You are creating some new sub TLVs (End, End.X, LAN End.X), and you are 
restricting and directing which externally defined behaviors (values) can be 
advertised in which of these TLVs. The registry would keep track of this (e.g., 
"Valid behaviors for sub-TLVs End, End.X, LAN End.X")

What happens when new behaviors are defined (externally), which TLVs are 
they supposed to be advertised in? Either the document that defines the new 
behavior or a related LSR document will have to indicate where this new 
behavior should be advertised too. That new document would update this registry 
to track that. Keeping track of this stuff is what registries are for. 

Your table literally looks like a template for the initial content of a 
registry. :)

Later in your IANA section you are updating other registries that bear a 
striking resemblance to this (e.g., what sub-TLV types are valid to advertise 
in what TLVs).

>> 2) It's odd that we are referring to the section as "Legal Behaviors" in 
the TLV definitions, and then in the actual section using "MAY" terms and no 
"MUST"/"MUST NOT", but then using "Yes" and "No" in the table.
> 
> a) Legal Behavior - refers to the set of values defined in the 
[I-D.ietf-spring-srv6-network-programming] which can be advertised in a 
particular TLV
> 
> b) We can not use MUST in section 10, as all these TLVs are optional

What's wrong with "If this behavior is advertised it MUST only be 
advertised in the TLV[s] as indicated by "Y" in the table below, and MUST NOT 
be advertised in the TLV[s] as indicated by "N" in the table below." or 
something like that.

Thanks,
Chris.
(as WG member)


> c) Yes/No means whether the particular behavior is allowed in the 
particular END-SID TLV.
> 
>> Are these suggestions or are they documenting the required behavior?
> 
> these are limitations as to which behavior is allowed to be advertised in 
which TLV.
> thanks,
> Peter
> 
>> Thanks,
>> 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


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

Re: [Lsr] New Version Notification for draft-wang-lsr-ospf-ifit-node-capability-02

[Acee Lindem (acee)]

Hi Yali,

A couple of very basic comments on these drafts. They are definitely not ready 
for consideration. 

1. IFIT is never expanded as an acronym. Seems it should be as early as the 
title. 

  OSPF extensions for Advertising In-Situ Flow Information Telemetry 
(IFIT) Capability

   2. You probably could come up with a more succinct acronym for IFIT. 

   3. The has no specification of how the capabilities are used. Are they 
purely informational? 

Thanks,
Acee

 


On 3/9/20, 4:33 AM, "Lsr on behalf of wangyali"  wrote:

Dear all,

I'm Yali. Following is a new version of I-D, 
draft-wang-lsr-ospf-ifit-node-capability-02 I submitted recently.

Please let me know your questions and comments. Thank you.

>>>
Name:   draft-wang-lsr-ospf-ifit-node-capability
Revision:   02
Title:  Extensions to OSPF for Advertising IFIT Node Capability
Document date:  2020-03-09
Group:  Individual Submission
Pages:  7
URL:
https://www.ietf.org/internet-drafts/draft-wang-lsr-ospf-ifit-node-capability-02.txt
Status: 
https://datatracker.ietf.org/doc/draft-wang-lsr-ospf-ifit-node-capability/
Htmlized:   
https://tools.ietf.org/html/draft-wang-lsr-ospf-ifit-node-capability-02
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-wang-lsr-ospf-ifit-node-capability
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-wang-lsr-ospf-ifit-node-capability-02

Abstract:
   This document defines a way for an Open Shortest Path First (OSPF)
   router originating the RI LSA to announce IFIT node capabilities
   within the entire routing domain.  A new optional TLV is extended to
   the OSPF RI Opaque LSA [RFC7770] to carry the IFIT node capability
   information.  Such advertisements enable IFIT applications in an
   operational network domain.  Here, the term "OSPF" includes both
   OSPFv2 and OSPFv3.

Best regards,
Yali WANG
___
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] Question about OSPF (transit area routing loop)

[Acee Lindem (acee)]

Hi Chris, 

On 3/8/20, 7:26 AM, "Lsr on behalf of Christian Hopps"  wrote:

Why does ABR_1 create a summary LSA to ASBR using the more expensive 
non-backbone path? This would seem to violate 12.4.3:

Else, if the destination of this route is an AS boundary
router, a summary-LSA should be originated if and only
if the routing table entry describes the preferred path
to the AS boundary router (see Step 3 of Section 16.4).
If so, a Type 4 summary-LSA is originated for the
destination, with Link State ID equal to the AS boundary
router's Router ID and metric equal to the routing table
entry's cost. Note: these LSAs should not be generated
if Area A has been configured as a stub area.

But even so, why is ABR_1 even looking at a cost 300 path to summarize, why 
would it not be looking at the cost 1 path it has through the backbone? That's 
the path that ABR_3 has chosen when it forwarded towards ABR_1 through RT_1, 
right?


Based on RFC 2328, section 16.4.1, intra-area paths through non-backbone areas 
are preferred over backbone paths. 
This counter intuitive preference was added way back in the late 90s to resolve 
a different routing loop with virtual links (refer to RFC 2328, Appendix G.2). 
Sigh - if we ever did OSPFv4, I'd remove virtual links. 

Thanks,
Acee

Thanks,
Chris.

> On Feb 26, 2020, at 2:19 AM, Sergey SHpenkov 
 wrote:
> 
> Acee,
> 
> Because ABR_1 creates SumLSA-4 for the ASBR not from the backbone area. 
The cost of SumLSA-4 for ASBR is 300.
> 
> Thanks,
> Sergey
    > 
> вт, 25 февр. 2020 г. в 22:44, Acee Lindem (acee) :
> Hi Sergey,
> 
> I don’t see why RT_1 wouldn’t go through ABR_1 to get to the ASBR.
> 
> Thanks,
> 
> Acee
> 
>  
> 
> From: Lsr  on behalf of Sergey SHpenkov 

> Date: Tuesday, February 25, 2020 at 2:38 PM
> To: "l...@ietf..org" 
> Subject: [Lsr] Question about OSPF (transit area routing loop)
> 
>  
> 
> Hi,
> 
> In section 16.3 of the OSPF RFC 2328 standard, it is stated that all ABR 
routers
> 
> connected to a transit area are required to check the sumLSA contained 
within
> 
> this area in order to possibly improve the intra-area and inter-area 
backbone routes
> 
> for themselves.
> 
> 
> See the picture:
> 
> The RT_1 and ABR_3 routers will use different paths to the ASBR router:
> 
> ABR_3 -> RT_1 -> ABR_1 -> ASBR = cost 3
> RT_1 -> ABR_3 -> ABR_2 -> ASBR = cost 21
> 
> route loop between RT_1 and ABR_3
> 
> Please explain this situation
> 
> Thanks,
> Sergey
> 
>  
> 
> ___
> 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 mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Question about OSPF (transit area routing loop)

[Acee Lindem (acee)]

Hi Sergey, OSPF adherents,
I think what you are proposing is that ASBR 3 prefers an inter-area path over a 
transit area over an intra-area backbone path (irrespective of cost). That was 
solve this problem – trying to think if it would create any. I’ve included the 
network topology again for reference.

Others, please chime in..
[A screenshot of a video game  Description automatically generated]
Thanks,
Acee

From: Sergey SHpenkov 
Date: Wednesday, March 4, 2020 at 6:05 AM
To: Acee Lindem , "lsr@ietf.org" 
Subject: Re: [Lsr] Question about OSPF (transit area routing loop)

Hi Acee,

Fixed errata in a previous my post.

To solve this problem, before starting 16.3, it is possible that all ABR
routers (virtual endpoints) should update the cost of routes for all ASBRs (if
these routes exist in the backbone area) from all virtual neighbors in the
transit area, regardless of whether these costs have been improved or
worsened.

For example, router ABR_3 first checks sumLSA-4 from virtual neighbor ABR_1
in the transit area 0.0.0.200 and updates the cost for ASBR to 300 in the
backbone area. After that, the calculation begins on the router ABR_3 16.3.

It is a bad idea?

Thanks,
Sergey

вт, 3 мар. 2020 г. в 21:58, Sergey SHpenkov 
mailto:sergey.v.shpen...@gmail.com>>:
Hi Acee,

To solve this problem, before starting 16.3, it is possible that all ABR 
routers (virtual endpoints) should update the cost of routes for ABRS (if these 
routes exist in the backbone area) from all virtual neighbors in the transit 
area, regardless of whether these costs have been improved or worsened.

For example, router ABR_3 first checks sumLSA-4 from virtual neighbor ABR_1 in 
the transit area 0.0.0.200 and updates the cost for ABRS to 300 in the backbone 
area. After that, the calculation begins on the router ABR_3 16.3.

It is a bad idea? :)

Thansk,
Sergey

пн, 2 мар. 2020 г. в 00:51, Acee Lindem (acee) 
mailto:a...@cisco.com>>:
Hi Sergey,
Seems it is a real problem that needs a solution. Let’s continue the discussion.
Thanks,
Acee

From: Sergey SHpenkov 
mailto:sergey.v.shpen...@gmail.com>>
Date: Sunday, March 1, 2020 at 4:41 PM
To: Acee Lindem mailto:a...@cisco.com>>
Subject: Re: [Lsr] Question about OSPF (transit area routing loop)

Hi Acee,

Please tell me the discussion on the topic of "Question about OSPF (transit 
area routing loop)" can be considered complete?

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

Re: [Lsr] IETF 107 LSR Presentation Slot Requests

[Acee Lindem (acee)]

Caught me just in time asking about this 😉
Acee

From: Linda Dunbar 
Date: Monday, March 2, 2020 at 1:57 PM
To: Yingzhen Qu 
Cc: "lsr@ietf.org" , "lsr-cha...@ietf.org" 
Subject: RE: [Lsr] IETF 107 LSR Presentation Slot Requests
Resent-From: 
Resent-To: Christian Hopps , Acee Lindem , 
Yingzhen Qu 
Resent-Date: Monday, March 2, 2020 at 1:57 PM

Opps, meant to send to RTGwg. Wrong reply.

I am very sorry.

Linda

From: Linda Dunbar
Sent: Monday, March 2, 2020 12:56 PM
To: Yingzhen Qu 
Cc: lsr@ietf.org; lsr-cha...@ietf.org
Subject: RE: [Lsr] IETF 107 LSR Presentation Slot Requests

Ying Zhen,

Can you please give me 15 minutes to update the
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-net2cloud-problem-statement/
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-net2cloud-gap-analysis/

we have made a lot of changes to address comments and suggestions from the  
IETF 106 and mailing list.

Thank you very much

Linda Dunbar

On 28/02/2020 20:56, Yingzhen Qu wrote:
> Hi all,
>
> We're now accepting agenda request for the LSR Working Grouping meeting
> IETF 107. Please send your requests to 
> lsr-cha...@ietf.org
> > indicating draft 
> name, speaker, and desired
> duration (covering presentation and discussion).
>
> If you plan to present remotely, please let us know so we can make the
> arrangements with the Meetecho team.
>
> Thanks,
> Yingzhen
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] AD Review of draft-ietf-isis-mpls-elc-10

[Acee Lindem (acee)]

Authors Dearest,

Please update all the out-of-date references and the copyright date to 2020. 
This will resolve the Nits. 

https://www6.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-isis-mpls-elc-10.txt

Thanks,
Acee (speaking as document shepherd) 

On 2/29/20, 12:00 AM, "Alvaro Retana"  wrote:

Dear authors:

This is my review of draft-ietf-isis-mpls-elc-10.  I reviewed this
document alongside draft-ietf-ospf-mpls-elc-12, so many comments are
the same/similar.  Thank you for the work in both of them!

Besides the in-line comments, I want to point out here that this
specification is incomplete.  It needs to have (1) a formal
description of the new MSD-Type (similar to §5/rfc8491), and (2) a
discussion of the interaction with the BMI-MSD.

I will progress both documents together, so I will wait for both of
them to address my comments before starting their IETF LC.

Thanks!!

Alvaro.


[Line numbers from idnits.]

...
18  Abstract

20 Multiprotocol Label Switching (MPLS) has defined a mechanism to load-
21 balance traffic flows using Entropy Labels (EL).  An ingress Label
22 Switching Router (LSR) cannot insert ELs for packets going into a
23 given Label Switched Path (LSP) unless an egress LSR has indicated
24 via signaling that it has the capability to process ELs, referred to
25 as Entropy Label Capability (ELC), on that tunnel.  In addition, it
26 would be useful for ingress LSRs to know each LSR's capability for
27 reading the maximum label stack depth and performing EL-based load-
28 balancing, referred to as Entropy Readable Label Depth (ERLD).  This
29 document defines a mechanism to signal these two capabilities using
30 IS-IS.  These mechanisms are particularly useful, where label
31 advertisements are done via protocols like IS-IS.

[nit] s/as Entropy Label Capability/as the Entropy Label Capability

[minor] "protocols like IS-IS"  That last sentence sounds as if there
were other options; for example advertise labels with OSPF and then
use the extensions here.  It's just a minor point, but I think that
maybe that last sentence is not needed.


...
81  1.  Introduction

83 [RFC6790] describes a method to load-balance Multiprotocol Label
84 Switching (MPLS) traffic flows using Entropy Labels (EL).  "The Use
85 of Entropy Labels in MPLS Forwarding" [RFC6790] introduces the
86 concept of Entropy Label Capability (ELC) and defines the signalings
87 of this capability via MPLS signaling protocols.  Recently,
88 mechanisms have been defined to signal labels via link-state Interior
89 Gateway Protocols (IGP) such as IS-IS
90 [I-D.ietf-isis-segment-routing-extensions].  In such scenarios, the
91 defined signaling mechanisms are inadequate.  This draft defines a
92 mechanism to signal the ELC using IS-IS.  This mechanism is useful
93 when the label advertisement is also done via IS-IS.

[nit] s/"The Use of Entropy Labels in MPLS Forwarding" [RFC6790]/It also

[nit] s/signalings/signaling

[nit] "In such scenarios, the defined signaling mechanisms are
inadequate." Take this sentence out: the rest of the paragraph is
enough.


95 In addition, in the cases where LSPs are used for whatever reasons
96 (e.g., SR-MPLS [I-D.ietf-spring-segment-routing-mpls]), it would be
97 useful for ingress LSRs to know each intermediate LSR's capability of
98 reading the maximum label stack depth and performing EL-based load-
99 balancing.  This capability, referred to as Entropy Readable Label
100Depth (ERLD) as defined in [I-D.ietf-mpls-spring-entropy-label] may
101be used by ingress LSRs to determine the position of the EL label in
102the stack, and whether it's necessary to insert multiple ELs at
103different positions in the label stack.

[nit] s/in the cases where LSPs are used for whatever reasons/in cases
where LSPs are used


105 2.  Terminology

107This memo makes use of the terms defined in [RFC6790], [RFC4971] and
108[I-D.ietf-mpls-spring-entropy-label].

[minor] I'm not sure why rfc4971 is referenced here; what terminology
is needed from it?


...
116 3.  Advertising ELC Using IS-IS

118Even though ELC is a property of the node, in some cases it is
119advantageous to associate and advertise the ELC with a prefix.  In a
120multi-area network, routers may not know the identity of the prefix
121originator in a remote area, or may not know the capabilities of such
122originator.  Similarly in a multi-domain network, the identity of the
123

Re: [Lsr] 答复: IETF 107 LSR Presentation Slot Requests

[Acee Lindem (acee)]

Yali – Can you give an overview on the list as well?
Thanks,
Acee

From: wangyali 
Date: Friday, February 28, 2020 at 10:03 PM
To: "lsr-cha...@ietf.org" , "lsr@ietf.org" 
Cc: Yingzhen Qu 
Subject: 答复: [Lsr] IETF 107 LSR Presentation Slot Requests
Resent-From: 
Resent-To: Acee Lindem , Yingzhen Qu , 
Christian Hopps 
Resent-Date: Friday, February 28, 2020 at 10:03 PM

Dear chairs, secretary and all,

This is Yali. It’s my honor to give a remote presentation for two new drafts 
(draft-liu-lsr-isis-ifit-node-capability-00 and 
draft-wang-lsr-ospf-ifit-node-capability-00) and request duration around 15 min 
for these two draft.

Everyone is welcome to give comments for these two drafts. Thank you.

Best regards,
Yali Wang

发件人: Yingzhen Qu [mailto:yingzhen.i...@gmail.com]
发送时间: 2020年2月29日 3:57
收件人: lsr@ietf.org; lsr-cha...@ietf.org
主题: [Lsr] IETF 107 LSR Presentation Slot Requests

Hi all,

We're now accepting agenda request for the LSR Working Grouping meeting IETF 
107. Please send your requests to 
lsr-cha...@ietf.org indicating draft name, speaker, 
and desired duration (covering presentation and discussion).

If you plan to present remotely, please let us know so we can make the 
arrangements with the Meetecho team.

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

Re: [Lsr] Question about OSPF (transit area routing loop)

[Acee Lindem (acee)]

Hi Sergey,

Have you reproduced the loop with routers? I definitely agree that ABR_1 will 
prefer the path to the ASBR through area 100. I think there is some ambiguity 
as to the cost it uses in its ASBR-Summary LSA injected into area 200.

Thanks,
Acee

From: Lsr  on behalf of Sergey SHpenkov 

Date: Wednesday, February 26, 2020 at 2:22 AM
To: "lsr@ietf.org" 
Subject: Re: [Lsr] Question about OSPF (transit area routing loop)

Acee,

Because ABR_1 creates SumLSA-4 for the ASBR not from the backbone area. The 
cost of SumLSA-4 for ASBR is 300.


Thanks,
Sergey

вт, 25 февр. 2020 г. в 22:44, Acee Lindem (acee) 
mailto:a...@cisco.com>>:
Hi Sergey,
I don’t see why RT_1 wouldn’t go through ABR_1 to get to the ASBR.
Thanks,
Acee

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of 
Sergey SHpenkov 
mailto:sergey.v.shpen...@gmail.com>>
Date: Tuesday, February 25, 2020 at 2:38 PM
To: "l...@ietf..org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>
Subject: [Lsr] Question about OSPF (transit area routing loop)

Hi,
In section 16.3 of the OSPF RFC 2328 standard, it is stated that all ABR routers
connected to a transit area are required to check the sumLSA contained within
this area in order to possibly improve the intra-area and inter-area backbone 
routes
for themselves.

See the picture:
[cid:image001.png@01D5ED64.AD66B6C0]
The RT_1 and ABR_3 routers will use different paths to the ASBR router:

ABR_3 -> RT_1 -> ABR_1 -> ASBR = cost 3
RT_1 -> ABR_3 -> ABR_2 -> ASBR = cost 21

route loop between RT_1 and ABR_3

Please explain this situation

Thanks,
Sergey

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

Re: [Lsr] Question about OSPF (transit area routing loop)

[Acee Lindem (acee)]

Hi Sergey,
I don’t see why RT_1 wouldn’t go through ABR_1 to get to the ASBR.
Thanks,
Acee

From: Lsr  on behalf of Sergey SHpenkov 

Date: Tuesday, February 25, 2020 at 2:38 PM
To: "lsr@ietf.org" 
Subject: [Lsr] Question about OSPF (transit area routing loop)

Hi,
In section 16.3 of the OSPF RFC 2328 standard, it is stated that all ABR routers
connected to a transit area are required to check the sumLSA contained within
this area in order to possibly improve the intra-area and inter-area backbone 
routes
for themselves.

See the picture:
[cid:image001.png@01D5EBEA.1BF45650]
The RT_1 and ABR_3 routers will use different paths to the ASBR router:

ABR_3 -> RT_1 -> ABR_1 -> ASBR = cost 3
RT_1 -> ABR_3 -> ABR_2 -> ASBR = cost 21

route loop between RT_1 and ABR_3

Please explain this situation

Thanks,
Sergey

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

Re: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions

[Acee Lindem (acee)]

Hey Ketan, 

Looks good - but can we simplify/shorten the last sentence?


On 1/31/20, 7:22 AM, "Ketan Talaulikar (ketant)"  wrote:

Hi Acee,

We'll update the text as follows in sec 8 to clarify this. Please let know 
if this works.


   All End.X SIDs MUST be subsumed by the subnet of a Locator with the
   matching algorithm which is advertised by the same node in an SRv6
   Locator TLV.  End.X SIDs which do not meet this requirement MUST be
   ignored.



   All End.X and LAN End.X SIDs MUST be subsumed by the subnet of a 
   Locator with the matching algorithm which is advertised by the same 
   node in an SRv6 Locator TLV.  End.X SIDs which do not meet this 
   requirement MUST be ignored. This ensures that the node
   advertising the End.X or LAN End.X SID is also advertising its
   corresponding Locator with matching algorithm that would be used
   for routing packets destined to that SID to its parent node 
   consistently over the specific algorithm topology. 


How about  "... with the algorithm that will be used for computing
paths destined to the SID."? 

Do we refer to "specific algorithm topologies" in the flex algorithm draft? I 
haven't read it for a while... 

Thanks,
Acee


Thanks,
Ketan

    -----Original Message-
From: Acee Lindem (acee)  
Sent: 30 January 2020 23:02
To: Peter Psenak (ppsenak) ; Ketan Talaulikar (ketant) 
; li_zhenqi...@hotmail.com; Christian Hopps 
; lsr 
Cc: draft-li-lsr-ospfv3-srv6-extensions 
; lsr-ads 
Subject: Re: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions

Hi Peter, 

On 1/30/20, 12:25 PM, "Peter Psenak"  wrote:

    Hi Acee,
    
On 30/01/2020 18:12, Acee Lindem (acee) wrote:
> Hi Peter,
> 
> On 1/30/20, 11:36 AM, "Peter Psenak"  wrote:
> 
>      Hi Acee,
>  
>  On 30/01/2020 17:11, Acee Lindem (acee) wrote:
>  > Hi Ketan,
>  >
>  > In that case, it doesn’t make sense to include it in the End.X
>  > advertisement since you need to look it up to check it anyway. 
I don’t
>  > see any benefit here.
>  The benefit is to make sure that the END.X SID that was 
configured for
>  the algo X is covered by the locator that has the same algo.
>  
>  If you do not advertise the algo with END.X SID, you have no way 
of
>  checking that on rcv side.
> 
> Ok - so it is to verify that algorithm for the adjacency matches that 
algorithm for the longest match locator - which may be advertised by a 
>different OSPFv3 router. Correct? 

yes.


>I guess I don't see why the algorithm for the END.X SID just isn't 
defined as the algorithm from the longest match locator. That way, everyone in 
>the area would use the same one and there would be less that could go wrong. 
What am I missing?

locators may change over time. During the reconfiguration a END.X SID 
may wrongly be associated with the incorrect locator from a different 
algo.

Also if for some reason the right locator is not advertised (due to a 
bug on the originator), END.X SID traffic may be sent using a wrong 
algo. We wanted to avoid it as that can be seen as a security issue.

Ok - makes sense. It would be good to capture these reasons in the along 
with the test for ignoring END.X SIDs that have conflicting algorithms with 
their longest matching locator. 

thanks,
Peter



> 
> Thanks,
> Acee
> 
>  
>  thanks,
>  Peter
>  
>  >
>  > Thanks,
>  >
>  > Acee
>  >
>  > *From: *"Ketan Talaulikar (ketant)" 
>  > *Date: *Thursday, January 30, 2020 at 11:06 AM
>  > *To: *Acee Lindem , "li_zhenqi...@hotmail.com"
>  > , Christian Hopps 
, lsr
>  > 
>  > *Cc: *draft-li-lsr-ospfv3-srv6-extensions
>  > , lsr-ads 

>  > *Subject: *RE: [Lsr] WG Adoption Call for
>  > draft-li-lsr-ospfv3-srv6-extensions
>  >
>  > Hi Acee/Zhen,
>  >
>  > The sec 8 of the draft has the following text which specifies 
the
>  > handling of this condition.
>  >
>  > All En

Re: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions

[Acee Lindem (acee)]

Hi Peter, 

On 1/30/20, 12:25 PM, "Peter Psenak"  wrote:

Hi Acee,

On 30/01/2020 18:12, Acee Lindem (acee) wrote:
> Hi Peter,
> 
> On 1/30/20, 11:36 AM, "Peter Psenak"  wrote:
> 
>  Hi Acee,
>  
>      On 30/01/2020 17:11, Acee Lindem (acee) wrote:
>  > Hi Ketan,
>  >
>  > In that case, it doesn’t make sense to include it in the End.X
>  > advertisement since you need to look it up to check it anyway. I 
don’t
>  > see any benefit here.
>  The benefit is to make sure that the END.X SID that was configured 
for
>  the algo X is covered by the locator that has the same algo.
>  
>  If you do not advertise the algo with END.X SID, you have no way of
>  checking that on rcv side.
> 
> Ok - so it is to verify that algorithm for the adjacency matches that 
algorithm for the longest match locator - which may be advertised by a 
>different OSPFv3 router. Correct? 

yes.


>I guess I don't see why the algorithm for the END.X SID just isn't defined 
as the algorithm from the longest match locator. That way, everyone in >the 
area would use the same one and there would be less that could go wrong. What 
am I missing?

locators may change over time. During the reconfiguration a END.X SID 
may wrongly be associated with the incorrect locator from a different algo.

Also if for some reason the right locator is not advertised (due to a 
bug on the originator), END.X SID traffic may be sent using a wrong 
algo. We wanted to avoid it as that can be seen as a security issue.

Ok - makes sense. It would be good to capture these reasons in the along with 
the test for ignoring END.X SIDs that have conflicting algorithms with their 
longest matching locator. 

thanks,
Peter



> 
> Thanks,
> Acee
> 
>  
>  thanks,
>  Peter
>  
>  >
>  > Thanks,
>  >
>  > Acee
>  >
>  > *From: *"Ketan Talaulikar (ketant)" 
>  > *Date: *Thursday, January 30, 2020 at 11:06 AM
>  > *To: *Acee Lindem , "li_zhenqi...@hotmail.com"
>  > , Christian Hopps , 
lsr
>  > 
>  > *Cc: *draft-li-lsr-ospfv3-srv6-extensions
>  > , lsr-ads 

>  > *Subject: *RE: [Lsr] WG Adoption Call for
>  > draft-li-lsr-ospfv3-srv6-extensions
>  >
>  > Hi Acee/Zhen,
>  >
>  > The sec 8 of the draft has the following text which specifies the
>  > handling of this condition.
>  >
>  > All End.X SIDs MUST be subsumed by the subnet of a Locator 
with the
>  >
>  > matching algorithm which is advertised by the same node in an 
SRv6
>  >
>  > Locator TLV.  End.X SIDs which do not meet this requirement 
MUST be
>  >
>  > ignored.
>  >
>  > Thanks,
>  >
>  > Ketan
>  >
>  > *From:* Acee Lindem (acee) 
>  > *Sent:* 30 January 2020 21:01
>  > *To:* li_zhenqi...@hotmail.com; Ketan Talaulikar (ketant)
>  > ; Christian Hopps ; lsr 

>  > *Cc:* draft-li-lsr-ospfv3-srv6-extensions
>  > ; lsr-ads 

>  > *Subject:* Re: [Lsr] WG Adoption Call for
>  > draft-li-lsr-ospfv3-srv6-extensions
>  >
>  > Hi Ketan, Zhen,
>  >
>  > What happens if there an algorithm conflict between the Adjacency 
END.X
>  > SID and the longest match Locator SID? Either one has to take 
precedence
>  > or this is an error condition. In either case, it needs to be 
documented.
>  >
>  > Thanks,
>  >
>  > Acee
>  >
>  > *From: *"li_zhenqi...@hotmail.com 
<mailto:li_zhenqi...@hotmail.com>"
>  > mailto:li_zhenqi...@hotmail.com>>
>  > *Date: *Thursday, January 30, 2020 at 10:20 AM
>  > *To: *"Ketan Talaulikar (ketant)"   > <mailto:ket...@cisco.com>>, Christian Hopps   > <mailto:cho...@chopps.org>>, lsr mailto:lsr@ietf.org>>
>  > *Cc: *draft-li-lsr-ospfv3-srv6-extensions
>  >   > <mailto:draft-li-lsr-ospfv3-srv6-extensi...@ietf.org>>, lsr-ads
>  > mailto:lsr-...@ietf.org>>, Christian Hopps
>  > mailto

Re: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions

[Acee Lindem (acee)]

Hi Peter, 

On 1/30/20, 11:36 AM, "Peter Psenak"  wrote:

Hi Acee,

On 30/01/2020 17:11, Acee Lindem (acee) wrote:
> Hi Ketan,
> 
> In that case, it doesn’t make sense to include it in the End.X 
> advertisement since you need to look it up to check it anyway. I don’t 
> see any benefit here.
The benefit is to make sure that the END.X SID that was configured for 
the algo X is covered by the locator that has the same algo.

If you do not advertise the algo with END.X SID, you have no way of 
checking that on rcv side.

Ok - so it is to verify that algorithm for the adjacency matches that algorithm 
for the longest match locator - which may be advertised by a different OSPFv3 
router. Correct? I guess I don't see why the algorithm for the END.X SID just 
isn't defined as the algorithm from the longest match locator. That way, 
everyone in the area would use the same one and there would be less that could 
go wrong. What am I missing? 

Thanks,
Acee


thanks,
Peter

> 
> Thanks,
> 
> Acee
> 
> *From: *"Ketan Talaulikar (ketant)" 
> *Date: *Thursday, January 30, 2020 at 11:06 AM
> *To: *Acee Lindem , "li_zhenqi...@hotmail.com" 
> , Christian Hopps , lsr 
> 
> *Cc: *draft-li-lsr-ospfv3-srv6-extensions 
> , lsr-ads 
> *Subject: *RE: [Lsr] WG Adoption Call for 
> draft-li-lsr-ospfv3-srv6-extensions
> 
> Hi Acee/Zhen,
> 
> The sec 8 of the draft has the following text which specifies the 
> handling of this condition.
> 
> All End.X SIDs MUST be subsumed by the subnet of a Locator with the
> 
> matching algorithm which is advertised by the same node in an SRv6
> 
> Locator TLV.  End.X SIDs which do not meet this requirement MUST be
> 
> ignored.
> 
> Thanks,
> 
> Ketan
> 
> *From:* Acee Lindem (acee) 
> *Sent:* 30 January 2020 21:01
> *To:* li_zhenqi...@hotmail.com; Ketan Talaulikar (ketant) 
> ; Christian Hopps ; lsr 

> *Cc:* draft-li-lsr-ospfv3-srv6-extensions 
> ; lsr-ads 
> *Subject:* Re: [Lsr] WG Adoption Call for 
> draft-li-lsr-ospfv3-srv6-extensions
> 
> Hi Ketan, Zhen,
> 
> What happens if there an algorithm conflict between the Adjacency END.X 
> SID and the longest match Locator SID? Either one has to take precedence 
> or this is an error condition. In either case, it needs to be documented.
> 
> Thanks,
> 
> Acee
> 
> *From: *"li_zhenqi...@hotmail.com <mailto:li_zhenqi...@hotmail.com>" 
> mailto:li_zhenqi...@hotmail.com>>
> *Date: *Thursday, January 30, 2020 at 10:20 AM
> *To: *"Ketan Talaulikar (ketant)"  <mailto:ket...@cisco.com>>, Christian Hopps  <mailto:cho...@chopps.org>>, lsr mailto:lsr@ietf.org>>
> *Cc: *draft-li-lsr-ospfv3-srv6-extensions 
>  <mailto:draft-li-lsr-ospfv3-srv6-extensi...@ietf.org>>, lsr-ads 
> mailto:lsr-...@ietf.org>>, Christian Hopps 
> mailto:cho...@chopps.org>>, Acee Lindem 
> mailto:a...@cisco.com>>
> *Subject: *Re: RE: [Lsr] WG Adoption Call for 
> draft-li-lsr-ospfv3-srv6-extensions
> 
> For the third concern, I think it is better to list the considerations 
> behind the format design of the TLVs to help readers understand them 
> better. For the specification behavior you mention, this doc SHOULD 
> specify it explicitly.
> 
> By the way, what a router should do when it receives END.X SID 
> containing algorithm that is different from the one carried in the 
> convering locator?
> 
> Best Regards,
> 
> Zhenqiang Li
> 
> 
> 
> li_zhenqi...@hotmail.com <mailto:li_zhenqi...@hotmail.com>
> 
> *From:*Ketan Talaulikar (ketant) <mailto:ket...@cisco.com>
> 
> *Date:* 2020-01-30 16:44
    > 
> *To:*li_zhenqi...@hotmail.com <mailto:li_zhenqi...@hotmail.com>;
> Christian Hopps <mailto:cho...@chopps.org>; lsr <mailto:lsr@ietf.org>
> 
> *CC:*draft-li-lsr-ospfv3-srv6-extensions
> <mailto:draft-li-lsr-ospfv3-srv6-extensi...@ietf.org>; lsr-ads
> <mailto:lsr-...@ietf.org>; Christian Hopps
> <mailto:cho...@chopps.org>; Acee Lindem (acee) <mailto:a...@cisco.com>
> 
> *Subject:* RE: RE: [Lsr] WG Adoption Call for
> draft-li-lsr-ospfv3-srv6-extensions
>

Re: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions

[Acee Lindem (acee)]

Hi Ketan,
In that case, it doesn’t make sense to include it in the End.X advertisement 
since you need to look it up to check it anyway. I don’t see any benefit here.
Thanks,
Acee

From: "Ketan Talaulikar (ketant)" 
Date: Thursday, January 30, 2020 at 11:06 AM
To: Acee Lindem , "li_zhenqi...@hotmail.com" 
, Christian Hopps , lsr 

Cc: draft-li-lsr-ospfv3-srv6-extensions 
, lsr-ads 
Subject: RE: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions

Hi Acee/Zhen,

The sec 8 of the draft has the following text which specifies the handling of 
this condition.

   All End.X SIDs MUST be subsumed by the subnet of a Locator with the
   matching algorithm which is advertised by the same node in an SRv6
   Locator TLV.  End.X SIDs which do not meet this requirement MUST be
   ignored.

Thanks,
Ketan

From: Acee Lindem (acee) 
Sent: 30 January 2020 21:01
To: li_zhenqi...@hotmail.com; Ketan Talaulikar (ketant) ; 
Christian Hopps ; lsr 
Cc: draft-li-lsr-ospfv3-srv6-extensions 
; lsr-ads 
Subject: Re: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions

Hi Ketan, Zhen,

What happens if there an algorithm conflict between the Adjacency END.X SID and 
the longest match Locator SID? Either one has to take precedence or this is an 
error condition. In either case, it needs to be documented.
Thanks,
Acee

From: "li_zhenqi...@hotmail.com<mailto:li_zhenqi...@hotmail.com>" 
mailto:li_zhenqi...@hotmail.com>>
Date: Thursday, January 30, 2020 at 10:20 AM
To: "Ketan Talaulikar (ketant)" mailto:ket...@cisco.com>>, 
Christian Hopps mailto:cho...@chopps.org>>, lsr 
mailto:lsr@ietf.org>>
Cc: draft-li-lsr-ospfv3-srv6-extensions 
mailto:draft-li-lsr-ospfv3-srv6-extensi...@ietf.org>>,
 lsr-ads mailto:lsr-...@ietf.org>>, Christian Hopps 
mailto:cho...@chopps.org>>, Acee Lindem 
mailto:a...@cisco.com>>
Subject: Re: RE: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions

For the third concern, I think it is better to list the considerations behind 
the format design of the TLVs to help readers understand them better. For the 
specification behavior you mention, this doc SHOULD specify it explicitly.
By the way, what a router should do when it receives END.X SID containing 
algorithm that is different from the one carried in the convering locator?

Best Regards,
Zhenqiang Li

li_zhenqi...@hotmail.com<mailto:li_zhenqi...@hotmail.com>

From: Ketan Talaulikar (ketant)<mailto:ket...@cisco.com>
Date: 2020-01-30 16:44
To: li_zhenqi...@hotmail.com<mailto:li_zhenqi...@hotmail.com>; Christian 
Hopps<mailto:cho...@chopps.org>; lsr<mailto:lsr@ietf.org>
CC: 
draft-li-lsr-ospfv3-srv6-extensions<mailto:draft-li-lsr-ospfv3-srv6-extensi...@ietf.org>;
 lsr-ads<mailto:lsr-...@ietf.org>; Christian Hopps<mailto:cho...@chopps.org>; 
Acee Lindem (acee)<mailto:a...@cisco.com>
Subject: RE: RE: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions
Please check inline again.

From: li_zhenqi...@hotmail.com<mailto:li_zhenqi...@hotmail.com> 
mailto:li_zhenqi...@hotmail.com>>
Sent: 30 January 2020 13:46
To: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>; 
Christian Hopps mailto:cho...@chopps.org>>; lsr 
mailto:lsr@ietf.org>>
Cc: draft-li-lsr-ospfv3-srv6-extensions 
mailto:draft-li-lsr-ospfv3-srv6-extensi...@ietf.org>>;
 lsr-ads mailto:lsr-...@ietf.org>>; Christian Hopps 
mailto:cho...@chopps.org>>; Acee Lindem (acee) 
mailto:a...@cisco.com>>
Subject: Re: RE: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions

Thank you KT for your quick response. Please see my reply begins with [ZQ].

Best Regards,
Zhenqiang Li

li_zhenqi...@hotmail.com<mailto:li_zhenqi...@hotmail.com>

From: Ketan Talaulikar (ketant)<mailto:ket...@cisco.com>
Date: 2020-01-30 13:42
To: li_zhenqi...@hotmail.com<mailto:li_zhenqi...@hotmail.com>; Christian 
Hopps<mailto:cho...@chopps.org>; lsr<mailto:lsr@ietf.org>
CC: 
draft-li-lsr-ospfv3-srv6-extensions<mailto:draft-li-lsr-ospfv3-srv6-extensi...@ietf.org>;
 lsr-ads<mailto:lsr-...@ietf.org>; Christian Hopps<mailto:cho...@chopps.org>; 
Acee Lindem (acee)<mailto:a...@cisco.com>
Subject: RE: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions
Hello Zhenqiang Li,

Thanks for your review and comments. Please check inline below.

From: li_zhenqi...@hotmail.com<mailto:li_zhenqi...@hotmail.com> 
mailto:li_zhenqi...@hotmail.com>>
Sent: 30 January 2020 08:46
To: Christian Hopps mailto:cho...@chopps.org>>; lsr 
mailto:lsr@ietf.org>>
Cc: draft-li-lsr-ospfv3-srv6-extensions 
mailto:draft-li-lsr-ospfv3-srv6-extensi...@ietf.org>>;
 lsr-ads mailto:lsr-...@ietf.org>>; Christian Hopps 
mailto:cho...@chopps.org>>; Acee Lindem (acee) 
mailto:a...@cisc

Re: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions

[Acee Lindem (acee)]

Hi Ketan, Zhen,

What happens if there an algorithm conflict between the Adjacency END.X SID and 
the longest match Locator SID? Either one has to take precedence or this is an 
error condition. In either case, it needs to be documented.

Thanks,
Acee

From: "li_zhenqi...@hotmail.com" 
Date: Thursday, January 30, 2020 at 10:20 AM
To: "Ketan Talaulikar (ketant)" , Christian Hopps 
, lsr 
Cc: draft-li-lsr-ospfv3-srv6-extensions 
, lsr-ads , 
Christian Hopps , Acee Lindem 
Subject: Re: RE: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions

For the third concern, I think it is better to list the considerations behind 
the format design of the TLVs to help readers understand them better. For the 
specification behavior you mention, this doc SHOULD specify it explicitly.
By the way, what a router should do when it receives END.X SID containing 
algorithm that is different from the one carried in the convering locator?

Best Regards,
Zhenqiang Li

li_zhenqi...@hotmail.com

From: Ketan Talaulikar (ketant)<mailto:ket...@cisco.com>
Date: 2020-01-30 16:44
To: li_zhenqi...@hotmail.com<mailto:li_zhenqi...@hotmail.com>; Christian 
Hopps<mailto:cho...@chopps.org>; lsr<mailto:lsr@ietf.org>
CC: 
draft-li-lsr-ospfv3-srv6-extensions<mailto:draft-li-lsr-ospfv3-srv6-extensi...@ietf.org>;
 lsr-ads<mailto:lsr-...@ietf.org>; Christian Hopps<mailto:cho...@chopps.org>; 
Acee Lindem (acee)<mailto:a...@cisco.com>
Subject: RE: RE: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions
Please check inline again.

From: li_zhenqi...@hotmail.com 
Sent: 30 January 2020 13:46
To: Ketan Talaulikar (ketant) ; Christian Hopps 
; lsr 
Cc: draft-li-lsr-ospfv3-srv6-extensions 
; lsr-ads ; 
Christian Hopps ; Acee Lindem (acee) 
Subject: Re: RE: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions

Thank you KT for your quick response. Please see my reply begins with [ZQ].

Best Regards,
Zhenqiang Li

li_zhenqi...@hotmail.com<mailto:li_zhenqi...@hotmail.com>

From: Ketan Talaulikar (ketant)<mailto:ket...@cisco.com>
Date: 2020-01-30 13:42
To: li_zhenqi...@hotmail.com<mailto:li_zhenqi...@hotmail.com>; Christian 
Hopps<mailto:cho...@chopps.org>; lsr<mailto:lsr@ietf.org>
CC: 
draft-li-lsr-ospfv3-srv6-extensions<mailto:draft-li-lsr-ospfv3-srv6-extensi...@ietf.org>;
 lsr-ads<mailto:lsr-...@ietf.org>; Christian Hopps<mailto:cho...@chopps.org>; 
Acee Lindem (acee)<mailto:a...@cisco.com>
Subject: RE: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions
Hello Zhenqiang Li,

Thanks for your review and comments. Please check inline below.

From: li_zhenqi...@hotmail.com<mailto:li_zhenqi...@hotmail.com> 
mailto:li_zhenqi...@hotmail.com>>
Sent: 30 January 2020 08:46
To: Christian Hopps mailto:cho...@chopps.org>>; lsr 
mailto:lsr@ietf.org>>
Cc: draft-li-lsr-ospfv3-srv6-extensions 
mailto:draft-li-lsr-ospfv3-srv6-extensi...@ietf.org>>;
 lsr-ads mailto:lsr-...@ietf.org>>; Christian Hopps 
mailto:cho...@chopps.org>>; Acee Lindem (acee) 
mailto:a...@cisco.com>>
Subject: Re: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions

support the adoption with the following comments.

1. What does SRH stack mean in section 4.2? AS specified in RFC8200 and 
draft-ietf-6man-segment-routing-header, only one SRH can be presented in one 
IPv6 header.

[KT] Thanks for catching this error and will fix as below:


OLD: The Maximum End Pop MSD Type specifies the maximum number of SIDs in
   the top SRH in an SRH stack to which the router can apply Penultimate
   Segment Pop (PSP) or Ultimate Segment Pop (USP)


NEW: The Maximum End Pop MSD Type specifies the maximum number of SIDs in

   the SRH for which the router can apply Penultimate

   Segment Pop (PSP) or Ultimate Segment Pop (USP)



[ZQ] Fine.

2. The abbreviations used in this draft should be listed in a seperated section 
or point out where they are defined.
[KT] We’ve followed the convention of expanding on first use as also providing 
reference where necessary. Please do let know if we’ve missed doing so anywhere.

[ZQ] Some examples: SPF computation in secction 5,  TBD in section 2.
[KT] Will expand SPF and some other such on first use :-). The TBD (to be 
decided) is for use until the code point are allocated by IANA.

3. Algorithm field is defined for End.x SID to carry the algorithm the end.x 
sid associates. But no algorithm field is defined for End SID in section 7. May 
I know the reason?
[KT] The SRv6 Locator TLV that is the parent of the SRv6 End SID Sub-TLV 
carries the algorithm and hence there is no need to repeat in the Sub-TLV. This 
is not the case for SRv6 End.X SID Sub-TLV and hence it has the algorithm field.



[ZQ] Make sense but still a little bit weird. Since any SID belongs to a 
locator, or it is not routable, the

[Lsr] IS-IS Requirements for Area Abstraction (Corrected Alias for ADs)

[Acee Lindem (acee)]

Speaking as WG Co-chair:

At IETF 107, we had a protracted discussion of several drafts having  goal of 
reducing the amount of link-state information that must be flooded into the 
level-2 area. We have two drafts that do this essentially via abstraction of 
the level-1 areas. These are:

https://www.ietf.org/id/draft-li-lsr-isis-area-proxy-01.txt
https://www.ietf.org/id/draft-chen-isis-ttz-07.txt

There are various reasons why these drafts can’t consolidated involving both 
IPR and government restrictions. Refer to 
https://datatracker.ietf.org/meeting/106/materials/minutes-106-lsr-00 for the 
complete discussion.

We have another draft that also reduces the amount of link-state information 
each IS-IS router must maintain but using IS-IS reflectors. This is slightly 
different but also avoids leaking all the level-1 area link-state to the 
level-2 area.

https://www.ietf.org/id/draft-przygienda-lsr-flood-reflection-01.txt

Given the amount of overlap and the conflicts amongst these drafts, the 
chairs/Ads are now asking whether there is a really a strong requirement to 
advance one or more of these documents. Especially given that we are already 
moving forward with both IS-IS/OSPF flooding reductions and the Hierarchal 
IS-IS work. Additionally,  we anticipate we’ll reach an impasse in 
consolidating these drafts. We’d really like to hear from the operators that 
would deploy these mechanisms.

Thanks,
Acee and Chris


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

[Lsr] IS-IS Requirements for Area Abstraction

[Acee Lindem (acee)]

Speaking as WG Co-chair:

At IETF 107, we had a protracted discussion of several drafts having  goal of 
reducing the amount of link-state information that must be flooded into the 
level-2 area. We have two drafts that do this essentially via abstraction of 
the level-1 areas. These are:

https://www.ietf.org/id/draft-li-lsr-isis-area-proxy-01.txt
https://www.ietf.org/id/draft-chen-isis-ttz-07.txt

There are various reasons why these drafts can’t consolidated involving both 
IPR and government restrictions. Refer to 
https://datatracker.ietf.org/meeting/106/materials/minutes-106-lsr-00 for the 
complete discussion.

We have another draft that also reduces the amount of link-state information 
each IS-IS router must maintain but using IS-IS reflectors. This is slightly 
different but also avoids leaking all the level-1 area link-state to the 
level-2 area.

https://www.ietf.org/id/draft-przygienda-lsr-flood-reflection-01.txt

Given the amount of overlap and the conflicts amongst these drafts, the 
chairs/Ads are now asking whether there is a really a strong requirement to 
advance one or more of these documents. Especially given that we are already 
moving forward with both IS-IS/OSPF flooding reductions and the Hierarchal 
IS-IS work. Additionally,  we anticipate we’ll reach an impasse in 
consolidating these drafts. We’d really like to hear from the operators that 
would deploy these mechanisms.

Thanks,
Acee and Chris


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

Re: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions

[Acee Lindem (acee)]

Speaking as WG member:

I have reviewed the document and my comments have been incorporated. I support 
WG adoption.

Thanks,
Acee

On 1/23/20, 3:25 PM, "Lsr on behalf of Christian Hopps"  wrote:

Hi LSR WG and Draft Authors,

The authors originally requested adoption back @ 105; however, some 
comments were received and new version was produced. Moving forward...

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

  https://datatracker.ietf.org/doc/draft-li-lsr-ospfv3-srv6-extensions/
 
Please indicate your support or objection by Feb 6, 2020.

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

Thanks,
Chris & Acee.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


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

Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

[Acee Lindem (acee)]

Speaking as WG member, 

I have reviewed revisions of this draft and support publication.

Thanks,
Acee

On 1/21/20, 7:15 PM, "Christian Hopps"  wrote:

This begins a 2 week WG Last Call, ending after Feb 4, 2020, for 
draft-ietf-lsr-isis-srv6-extensions

  https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/

Authors please indicate if you aware of any other IPR beyond what is posted:

  https://datatracker.ietf.org/ipr/3796/

Thanks,
Chris & Acee.

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

Re: [Lsr] Methods to label the passive interfaces within ISIS

[Acee Lindem (acee)]

Hi Aijun,

From: Aijun Wang 
Date: Monday, January 13, 2020 at 5:48 PM
To: Acee Lindem 
Cc: Jeff Tantsura , "Les Ginsberg (ginsberg)" 
, Tony Li , Robert Raszuk 
, "lsr@ietf.org" 
Subject: Re: [Lsr] Methods to label the passive interfaces within ISIS

Hi, Acee:
As Tony suggested also before, we can change the description for “passive” to 
“stub” later.
Is that more acceptable then?

Yes – but I’d still like to know why this is needed.

Thanks,
Acee

Aijun Wang
China Telecom


On Jan 14, 2020, at 06:40, Acee Lindem (acee)  wrote:
Hi Aijun,

From: Aijun Wang 
Date: Monday, January 13, 2020 at 5:37 PM
To: Jeff Tantsura 
Cc: Acee Lindem , Tony Li , "Les Ginsberg 
(ginsberg)" , "lsr@ietf.org" , Robert Raszuk 

Subject: Re: [Lsr] Methods to label the passive interfaces within ISIS

Hi, Acee, Les and Jeff:
IGP is used to transfer the topology information within the domain, and the 
stub/passive interface is the important part of one network, especially for the 
inter-AS topology.
Currently, we have not figured out other use cases to distinguish other 
interfaces type. But for stub/passive interfaces, it will be useful to flooding 
such information to other internal routers.

A stub interface is not necessarily a passive interace.

OSPF has already the corresponding consideration and specifications, isn’t it 
reasonable for ISIS to have such capabilities also?

OSPF doesn’t advertise that an interface is a passive interface. Others routing 
can’t distinguish a passive interface from any other stub link.

Thanks,
Acee

Aijun Wang
China Telecom



On Jan 14, 2020, at 02:41, Jeff Tantsura  wrote:
Agree with Acee and Les

Cheers,
Jeff
On Jan 13, 2020, 9:29 AM -0800, Les Ginsberg (ginsberg) , 
wrote:


I agree with Acee that there is no requirement to identify an interface as 
passive – or (as suggested in this thread) as loopback or tunnel or stub…

Before debating the best encoding for information, it would be sensible to 
define the use case/requirements.
Simply having an advertisement that identifies an interface type isn’t 
sufficient to do anything useful IMO.

   Les

From: Acee Lindem (acee) 
Sent: Monday, January 13, 2020 8:03 AM
To: tony...@tony.li; Aijun Wang 
Cc: Les Ginsberg (ginsberg) ; Robert Raszuk 
; lsr@ietf.org
Subject: Re: [Lsr] Methods to label the passive interfaces within ISIS

Hi Aijun,
I guess the external use case for this is advertisement in BGP-LS for Network 
Management purposes?? There really isn’t IS-IS requirement to know whether or 
not an interface is a passive interface.
Thanks,
Acee

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of Tony 
Li mailto:tony...@tony.li>>
Date: Monday, January 13, 2020 at 11:00 AM
To: Aijun Wang mailto:wangai...@tsinghua.org.cn>>
Cc: "Les Ginsberg (ginsberg)" mailto:ginsb...@cisco.com>>, 
Robert Raszuk mailto:rob...@raszuk.net>>, 
"lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>
Subject: Re: [Lsr] Methods to label the passive interfaces within ISIS


Hi Anjun,


Is it reasonable to put the link attribute information into the “IP 
Reachability TLV”?
IMHO, such stub link is not the normal links within IGP domain.  Label the 
related prefix is coming from the passive/stub link seems also acceptable?


Well, a passive interface is really configured so that you advertise the 
interface’s prefix.  Attaching the data that you want to the associated data 
seems reasonable to me.

There’s no good IS Neighbor advertisement to attach the sub-TLV to because 
there is no neighbor.

Tony


___
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 mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Methods to label the passive interfaces within ISIS

[Acee Lindem (acee)]

Hi Aijun,

From: Aijun Wang 
Date: Monday, January 13, 2020 at 5:37 PM
To: Jeff Tantsura 
Cc: Acee Lindem , Tony Li , "Les Ginsberg 
(ginsberg)" , "lsr@ietf.org" , Robert Raszuk 

Subject: Re: [Lsr] Methods to label the passive interfaces within ISIS

Hi, Acee, Les and Jeff:
IGP is used to transfer the topology information within the domain, and the 
stub/passive interface is the important part of one network, especially for the 
inter-AS topology.
Currently, we have not figured out other use cases to distinguish other 
interfaces type. But for stub/passive interfaces, it will be useful to flooding 
such information to other internal routers.

A stub interface is not necessarily a passive interace.

OSPF has already the corresponding consideration and specifications, isn’t it 
reasonable for ISIS to have such capabilities also?

OSPF doesn’t advertise that an interface is a passive interface. Others routing 
can’t distinguish a passive interface from any other stub link.

Thanks,
Acee

Aijun Wang
China Telecom


On Jan 14, 2020, at 02:41, Jeff Tantsura  wrote:
Agree with Acee and Les

Cheers,
Jeff
On Jan 13, 2020, 9:29 AM -0800, Les Ginsberg (ginsberg) , 
wrote:

I agree with Acee that there is no requirement to identify an interface as 
passive – or (as suggested in this thread) as loopback or tunnel or stub…

Before debating the best encoding for information, it would be sensible to 
define the use case/requirements.
Simply having an advertisement that identifies an interface type isn’t 
sufficient to do anything useful IMO.

   Les

From: Acee Lindem (acee) 
Sent: Monday, January 13, 2020 8:03 AM
To: tony...@tony.li; Aijun Wang 
Cc: Les Ginsberg (ginsberg) ; Robert Raszuk 
; lsr@ietf.org
Subject: Re: [Lsr] Methods to label the passive interfaces within ISIS

Hi Aijun,
I guess the external use case for this is advertisement in BGP-LS for Network 
Management purposes?? There really isn’t IS-IS requirement to know whether or 
not an interface is a passive interface.
Thanks,
Acee

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of Tony 
Li mailto:tony...@tony.li>>
Date: Monday, January 13, 2020 at 11:00 AM
To: Aijun Wang mailto:wangai...@tsinghua.org.cn>>
Cc: "Les Ginsberg (ginsberg)" mailto:ginsb...@cisco.com>>, 
Robert Raszuk mailto:rob...@raszuk.net>>, 
"lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>
Subject: Re: [Lsr] Methods to label the passive interfaces within ISIS


Hi Anjun,


Is it reasonable to put the link attribute information into the “IP 
Reachability TLV”?
IMHO, such stub link is not the normal links within IGP domain.  Label the 
related prefix is coming from the passive/stub link seems also acceptable?


Well, a passive interface is really configured so that you advertise the 
interface’s prefix.  Attaching the data that you want to the associated data 
seems reasonable to me.

There’s no good IS Neighbor advertisement to attach the sub-TLV to because 
there is no neighbor.

Tony


___
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] Methods to label the passive interfaces within ISIS

[Acee Lindem (acee)]

Hi Aijun,
I guess the external use case for this is advertisement in BGP-LS for Network 
Management purposes?? There really isn’t IS-IS requirement to know whether or 
not an interface is a passive interface.
Thanks,
Acee

From: Lsr  on behalf of Tony Li 
Date: Monday, January 13, 2020 at 11:00 AM
To: Aijun Wang 
Cc: "Les Ginsberg (ginsberg)" , Robert Raszuk 
, "lsr@ietf.org" 
Subject: Re: [Lsr] Methods to label the passive interfaces within ISIS


Hi Anjun,



Is it reasonable to put the link attribute information into the “IP 
Reachability TLV”?
IMHO, such stub link is not the normal links within IGP domain.  Label the 
related prefix is coming from the passive/stub link seems also acceptable?


Well, a passive interface is really configured so that you advertise the 
interface’s prefix.  Attaching the data that you want to the associated data 
seems reasonable to me.

There’s no good IS Neighbor advertisement to attach the sub-TLV to because 
there is no neighbor.

Tony



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

Re: [Lsr] [Technical Errata Reported] RFC2328 (5956)

[Acee Lindem (acee)]

All, 
I don't agree this change is required. The non-normative appendix C text 
clearly states that this is the "cost of sending a packet on the interface". 
The examples cited are cases where reachability to a local address is provided. 
Now, there are cases where it is useful to specify a non-zero cost for a 
loopback address (e.g., Anycast addresses) but these scenarios are out of scope.
Thanks,
Acee

On 1/8/20, 4:58 PM, "RFC Errata System"  wrote:

The following errata report has been submitted for RFC2328,
"OSPF Version 2".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid5956

--
Type: Technical
Reported by: Marcelo Bustani 

Section: 12.4.1

Original Text
-
Router-LSAs

If the state of the interface is Loopback, add a Type 3
link (stub network) as long as this is not an interface
to an unnumbered point-to-point network.  The Link ID
should be set to the IP interface address, the Link Data
set to the mask 0x (indicating a host route),
and the cost set to 0.

===
12.4.1.4.  Describing Point-to-MultiPoint interfaces

For operational Point-to-MultiPoint interfaces, one or
more link descriptions are added to the router-LSA as
follows:

o   A single Type 3 link (stub network) is added with
Link ID set to the router's own IP interface
address, Link Data set to the mask 0x
(indicating a host route), and cost set to 0.

=
C.3 Router interface parameters
 
 Interface output cost
The cost of sending a packet on the interface, expressed in
the link state metric.  This is advertised as the link cost
for this interface in the router's router-LSA. The interface
output cost must always be greater than 0.


Corrected Text
--
"cost set to 0" to at least "greater than 0"

Notes
-
The section 12.4.1 and 12.4.1.4 are inconsistent with the appendix c.3.

These both section we find the cost to stub networks have to be set to 0, 
but in appendix c.3 we see that the interfaces must have greater than 0.

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--
RFC2328 (no draft string recorded)
--
Title   : OSPF Version 2
Publication Date: April 1998
Author(s)   : J. Moy
Category: INTERNET STANDARD
Source  : Open Shortest Path First IGP
Area: Routing
Stream  : IETF
Verifying Party : IESG


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

Re: [Lsr] WG Last Call draft-ietf-lsr-isis-invalid-tlv

[Acee Lindem (acee)]

Speaking as WG Member:

I support publication. This is document fills a long-standing gap in the IS-IS 
specification. 

Thanks,
Acee

On 1/2/20, 2:09 PM, "Lsr on behalf of Christian Hopps"  wrote:

This begins a 2 week WG Last Call, ending after Jan 16th, 2020, for 
draft-ietf-lsr-isis-invalid-tlv.

  https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-invalid-tlv/

Tony P (other authors already responded during the adoption poll), please 
indicate your knowledge of any IPR related to this work to the list as well.

Thanks,
Chris & Acee.

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


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

Re: [Lsr] WG Adoption Call for draft-ketant-lsr-ospf-bfd-strict-mode

[Acee Lindem (acee)]

Speaking as a WG member, I support WG adoption.
Thanks,
Acee

On 12/13/19, 6:55 AM, "Lsr on behalf of Christian Hopps"  wrote:

Hi LSR WG and Draft Authors,

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

  https://datatracker.ietf.org/doc/draft-ketant-lsr-ospf-bfd-strict-mode/

Please indicate your support or objection by Dec 27th.

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

Thanks,
Chris & Acee.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


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

Re: [Lsr] WG Adoption Call for draft-ketant-lsr-ospf-reverse-metric

[Acee Lindem (acee)]

Speaking as a WG member, I support WG adoption. 
Thanks,
Acee

On 12/13/19, 6:29 AM, "Lsr on behalf of Christian Hopps"  wrote:

Hi LSR WG and Draft Authors,

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

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

Please indicate your support or objection by Dec 27th.

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

Thanks,
Chris & Acee.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


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

Re: [Lsr] "YANG Module for IS-IS Reverse Metric" - draft-hopps-lsr-yang-isis-reverse-metric-02

[Acee Lindem (acee)]

The WG adoption poll has ended and the draft has been accepted.

Chris – please republish as draft-ietf-lsr-yang-isis-reverse-metric-00.txt.

Thanks,
Acee

From: Lsr  on behalf of Acee Lindem 
Date: Monday, November 25, 2019 at 7:27 AM
To: "lsr@ietf.org" 
Cc: Christian Hopps 
Subject: [Lsr] "YANG Module for IS-IS Reverse Metric" - 
draft-hopps-lsr-yang-isis-reverse-metric-02

This begins a two week LSR Working Group adoption call for the subject document.

https://datatracker.ietf.org/doc/draft-hopps-lsr-yang-isis-reverse-metric/

Please indicate your support or objection to adoption to the LSR list 
(lsr@ietf.org) prior to 12:00 AM UTC on December 10th, 
2019.

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

Re: [Lsr] 答复: some doubts about RFC3101

[Acee Lindem (acee)]

Hi Meicong,

From: Lsr  on behalf of meicong 
Date: Monday, December 9, 2019 at 9:12 AM
To: Acee Lindem , "lsr@ietf.org" 
Subject: [Lsr] 答复: some doubts about RFC3101

Hi Acee,

The subnet 128.185.1.0/255.255.255.0 is an intra-area of the NSSA area,
and subnet 128.185.0.0/255.255.0.0 is a directly attached subnet on the ASBR 
that originate the type-5 LSA.
The fowarding address of the type-5 LSA is 128.185.1.1.

This is broken. Nobody within the NSSA will be able to reach hosts within the 
128.155.1/24 subnet that are on the ASBR’s directly attached network.


There are two subnet seemly same but different netmask in the network
128.185.1.0/255.255.255.0 intra-area route of nssa area,
128.185.0.0/255.255.0.0 intra-area route of normal area.

Maybe we could say it is a config error,

There is no “Maybe” about it.

but what should be the result?
It is working as designed.
Hope this helps,
Acee

Regards

发件人: Acee Lindem (acee) [mailto:a...@cisco.com]
发送时间: 2019年12月6日 20:23
收件人: meicong ; lsr@ietf.org
主题: Re: [Lsr] some doubts about RFC3101

Hi Meicong,
The problem is that the subnet 128.185.1.0/255.255.255.0 is seemly in two 
places in the network. It is both an intra-area subnet withins the NSSA and a 
directly attached subnet on one of the ASBR’s OSPF interfaces. The ASBR should 
not advertise it as a forwarding address if it is not a directly attached 
subnet on an OSPF interface. Refer to section 2.3 in RFC 2328.
Thanks,
Acee

From: meicong mailto:meic...@huawei.com>>
Date: Thursday, December 5, 2019 at 8:40 PM
To: Acee Lindem mailto:a...@cisco.com>>, 
"lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>
Subject: Re: [Lsr] some doubts about RFC3101

Hi Acee,
Thanks for your answer.
In the example,
If the type-5 lsa is originated by the ASBR that in the normal area,
the other router in the normal area will use the type-5 lsa,
for the ASBR is reachable in the normal area,
and there is (128.185.1.0, 0xff00) inter-area route that be orignated by 
the abr in routing table of  other router,
and the calculated result for the type-5 lsa is path to the abr,
but there is no path on the abr, because the route (128.185.1.0, 0xff00) is 
intra-route of Nssa area on the abr.
In the scenario, the fowarding address is advertised by differnet router in 
different capable area with different netmask.
It maybe fall under a configed error, but the result of the calculate result 
seems wrong.
What is your opinion for it?
Regards

发件人: Acee Lindem (acee) [mailto:a...@cisco.com]
发送时间: 2019年12月5日 20:40
收件人: meicong mailto:meic...@huawei.com>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
主题: Re: [Lsr] some doubts about RFC3101

Hi Meicong,

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of 
meicong mailto:meic...@huawei.com>>
Date: Thursday, December 5, 2019 at 4:48 AM
To: "lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>
Cc: 
"draft-ietf-ospf-nssa-upd...@ietf.org<mailto:draft-ietf-ospf-nssa-upd...@ietf.org>"
 
mailto:draft-ietf-ospf-nssa-upd...@ietf.org>>
Subject: [Lsr] some doubts about RFC3101


Hi All,
Could you please provide clarification for following section 2.5.(3) in rfc3101.

  If the forwarding address is non-zero look up the forwarding
  address in the routing table.  For a Type-5 LSA the matching
  routing table entry must specify an intra-area or inter-area
  path through a Type-5 capable area.  For a Type-7 LSA the
  matching routing table entry must specify an intra-area path
  through the LSA's originating NSSA.  If no such path exists
  then do nothing with this LSA and consider the next in the
  list.
  [NSSA]

In the section, the matching routing table entry of the forwarding address is 
limited("an intra-area or inter-area path through a Type-5 capable area" or "an 
intra-area path through the LSA's originating NSSA").
If the best matching routing table entry for the forwarding address does not 
match the limited, the secondory best matching routing table entry should be 
find or not?

e.g., the forwarding address of a Type-5 LSA is 128.185.1.1,
and there are two routing table entry int the routing table on the abr,
(128.185.1.0, 0xff00) intra-area route of the NSSA area,
(128.185.0.0, 0x) intra-area route of the normal area(Type-5 capable 
area),
The path of the forwarding address should be consider as exist or not?

The short answer is no. The OSPF AS-External LSA should not be used since the 
forwarding address is not reachable through a normal area. As one would expect, 
the route lookup is always a longest prefix lookup. Note that having NSSA 
routes implies that the computing OSPF router is an ABR with both normal and 
NSSA area(s). One would expect that prefix being computed would also have a 
corresponding OSPF NSSA LSA that would satisfy the reachability check. 

[Lsr] OSPF/IS-IS Segment Routing RFCs - MPLS Dataplane

[Acee Lindem (acee)]

The OSPF/IS-IS Segment Routing drafts have been published as RFCs. There’s been 
a lot of iterations and work done here and I’d like to recognize the occasion 
as well as congratulate the authors.


 OSPF Segment Rouing - https://www.rfc-editor.org/info/rfc8665
OSPFv3 Segment Routing – https://www.rfc-editor.org/info/rfc8666
IS-IS Segment Routing – https://www.rfc-editor.org/info/rfc8667


Thanks,
Acee

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

Re: [Lsr] some doubts about RFC3101

[Acee Lindem (acee)]

Hi Meicong,
The problem is that the subnet 128.185.1.0/255.255.255.0 is seemly in two 
places in the network. It is both an intra-area subnet withins the NSSA and a 
directly attached subnet on one of the ASBR’s OSPF interfaces. The ASBR should 
not advertise it as a forwarding address if it is not a directly attached 
subnet on an OSPF interface. Refer to section 2.3 in RFC 2328.
Thanks,
Acee

From: meicong 
Date: Thursday, December 5, 2019 at 8:40 PM
To: Acee Lindem , "lsr@ietf.org" 
Subject: Re: [Lsr] some doubts about RFC3101

Hi Acee,
Thanks for your answer.
In the example,
If the type-5 lsa is originated by the ASBR that in the normal area,
the other router in the normal area will use the type-5 lsa,
for the ASBR is reachable in the normal area,
and there is (128.185.1.0, 0xff00) inter-area route that be orignated by 
the abr in routing table of  other router,
and the calculated result for the type-5 lsa is path to the abr,
but there is no path on the abr, because the route (128.185.1.0, 0xff00) is 
intra-route of Nssa area on the abr.
In the scenario, the fowarding address is advertised by differnet router in 
different capable area with different netmask.
It maybe fall under a configed error, but the result of the calculate result 
seems wrong.
What is your opinion for it?
Regards

发件人: Acee Lindem (acee) [mailto:a...@cisco.com]
发送时间: 2019年12月5日 20:40
收件人: meicong ; lsr@ietf.org
主题: Re: [Lsr] some doubts about RFC3101

Hi Meicong,

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of 
meicong mailto:meic...@huawei.com>>
Date: Thursday, December 5, 2019 at 4:48 AM
To: "lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>
Cc: 
"draft-ietf-ospf-nssa-upd...@ietf.org<mailto:draft-ietf-ospf-nssa-upd...@ietf.org>"
 
mailto:draft-ietf-ospf-nssa-upd...@ietf.org>>
Subject: [Lsr] some doubts about RFC3101


Hi All,
Could you please provide clarification for following section 2.5.(3) in rfc3101.

  If the forwarding address is non-zero look up the forwarding
  address in the routing table.  For a Type-5 LSA the matching
  routing table entry must specify an intra-area or inter-area
  path through a Type-5 capable area.  For a Type-7 LSA the
  matching routing table entry must specify an intra-area path
  through the LSA's originating NSSA.  If no such path exists
  then do nothing with this LSA and consider the next in the
  list.
  [NSSA]

In the section, the matching routing table entry of the forwarding address is 
limited("an intra-area or inter-area path through a Type-5 capable area" or "an 
intra-area path through the LSA's originating NSSA").
If the best matching routing table entry for the forwarding address does not 
match the limited, the secondory best matching routing table entry should be 
find or not?

e.g., the forwarding address of a Type-5 LSA is 128.185.1.1,
and there are two routing table entry int the routing table on the abr,
(128.185.1.0, 0xff00) intra-area route of the NSSA area,
(128.185.0.0, 0x) intra-area route of the normal area(Type-5 capable 
area),
The path of the forwarding address should be consider as exist or not?

The short answer is no. The OSPF AS-External LSA should not be used since the 
forwarding address is not reachable through a normal area. As one would expect, 
the route lookup is always a longest prefix lookup. Note that having NSSA 
routes implies that the computing OSPF router is an ABR with both normal and 
NSSA area(s). One would expect that prefix being computed would also have a 
corresponding OSPF NSSA LSA that would satisfy the reachability check. If not, 
something in the OSPF routing design is broken.

Hope this helps,
Acee



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

[Lsr] IETF 106 LSR Working Group Meeting Minutes

[Acee Lindem (acee)]

I’ve uploaded the IETF 106 LSR minutes at 
https://datatracker.ietf.org/meeting/106/materials/minutes-106-lsr-00

Please send me any additions or corrections. Thanks much to Yingzhen Qu for 
compiling the minutes. As you can see, we had quite a lot of lively discussion 
during the sessions – especially with respect to IS-IS flooding flow-control 
mechanisms.

As I stated at the end of the second WG session – let’s keep this energy going 
between IETFs.

Thanks,
Acee

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

Re: [Lsr] some doubts about RFC3101

[Acee Lindem (acee)]

Hi Meicong,

From: Lsr  on behalf of meicong 
Date: Thursday, December 5, 2019 at 4:48 AM
To: "lsr@ietf.org" 
Cc: "draft-ietf-ospf-nssa-upd...@ietf.org" 

Subject: [Lsr] some doubts about RFC3101


Hi All,
Could you please provide clarification for following section 2.5.(3) in rfc3101.

  If the forwarding address is non-zero look up the forwarding
  address in the routing table.  For a Type-5 LSA the matching
  routing table entry must specify an intra-area or inter-area
  path through a Type-5 capable area.  For a Type-7 LSA the
  matching routing table entry must specify an intra-area path
  through the LSA's originating NSSA.  If no such path exists
  then do nothing with this LSA and consider the next in the
  list.
  [NSSA]

In the section, the matching routing table entry of the forwarding address is 
limited("an intra-area or inter-area path through a Type-5 capable area" or "an 
intra-area path through the LSA's originating NSSA").
If the best matching routing table entry for the forwarding address does not 
match the limited, the secondory best matching routing table entry should be 
find or not?

e.g., the forwarding address of a Type-5 LSA is 128.185.1.1,
and there are two routing table entry int the routing table on the abr,
(128.185.1.0, 0xff00) intra-area route of the NSSA area,
(128.185.0.0, 0x) intra-area route of the normal area(Type-5 capable 
area),
The path of the forwarding address should be consider as exist or not?

The short answer is no. The OSPF AS-External LSA should not be used since the 
forwarding address is not reachable through a normal area. As one would expect, 
the route lookup is always a longest prefix lookup. Note that having NSSA 
routes implies that the computing OSPF router is an ABR with both normal and 
NSSA area(s). One would expect that prefix being computed would also have a 
corresponding OSPF NSSA LSA that would satisfy the reachability check. If not, 
something in the OSPF routing design is broken.

Hope this helps,
Acee



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

Re: [Lsr] Éric Vyncke's Discuss on draft-ietf-ospf-ospfv2-hbit-11: (with DISCUSS and COMMENT)

[Acee Lindem (acee)]

Hi Eric,

See inline.

From: "Eric Vyncke (evyncke)" 
Date: Tuesday, December 3, 2019 at 3:39 AM
To: Padma Pillay-Esnault 
Cc: Éric Vyncke via Datatracker , 
"draft-ietf-ospf-ospfv2-h...@ietf.org" , 
Alvaro Retana , "lsr-cha...@ietf.org" 
, Yingzhen Qu , The IESG 
, "lsr@ietf.org" 
Subject: Re: Éric Vyncke's Discuss on draft-ietf-ospf-ospfv2-hbit-11: (with 
DISCUSS and COMMENT)
Resent-From: 
Resent-To: Yingzhen Qu , Christian Hopps 
, Acee Lindem 
Resent-Date: Tuesday, December 3, 2019 at 3:39 AM

Padma,

This is indeed what I understood by reading the section 5, OTOH, the ‘MUST’ is 
also a wishful thinking (bugs happen). I would feel more comfortable (and clear 
my DISCUSS), if the H-bit deployment has been tested in simulation or even in 
real network with a scenario where there is no H-bit aware routers first, then 
adding a couple of H-bit aware routers, then only H-bit aware routers and 
finally adding again a single non H-bit aware router. A failure could be quite 
catastrophic.

It is common to in OSPF to use OSPF capabilities to be used to determine if 
optional features are in use within an OSPF routing domain. This dates back to 
RFC 1793 when the DC-bit in the Router-LSA options was used to indicate whether 
or not an OSPF router supports Demand Circuits including DoNotAge LSAs. So, 
irrespective of your concerns with implementation bugs, this is a tried and 
true OSPF protocol mechanism.

Also, my OSPF knowledge is a little rusty, but, can LSA be lost? So, having a 
wrong representation of the H-bit awareness.

OSPF has reliable flooding so LSAs cannot get “lost”. And, if an LSA were 
indeed lost, it would be missing from the SPF topology and whether or not H-bit 
were being used would be a secondary concern.

Thanks,
Acee

You can call me paranoid :-) but I would like to get your point of view on the 
above.

-éric

From: iesg  on behalf of Padma Pillay-Esnault 

Date: Monday, 2 December 2019 at 21:44
To: Eric Vyncke 
Cc: Éric Vyncke via Datatracker , 
"draft-ietf-ospf-ospfv2-h...@ietf.org" , 
Alvaro Retana , "lsr-cha...@ietf.org" 
, Yingzhen Qu , The IESG 
, "lsr@ietf.org" 
Subject: Re: Éric Vyncke's Discuss on draft-ietf-ospf-ospfv2-hbit-11: (with 
DISCUSS and COMMENT)

Hello Eric

On Mon, Dec 2, 2019 at 12:31 PM Eric Vyncke (evyncke) 
mailto:evyn...@cisco.com>> wrote:
Alvaro

I do not mind too much the transient inconsistencies but more about longer term 
inconsistencies (1) hence my question about simulations / tests in the absence 
of mathematical proof.
The R-bit has always been in OSPFv3 (AFAIK), so, OSPFv3 does not have the same 
issue.

-éric

(1) having some routers being H-bit aware and other routers not processing the 
H-bit could probably introduce long term inconsistencies and loops.

As described in section 5
"All routers supporting H-Bit MUST check all the RI LSAs of nodes in the area 
before actively running the modified SPF to account for the H-bit in order to 
verify that all routers are in routing capability. If any router does not 
advertise the Host Router Support capability then the SPF Modifications 
(Section 4) MUST NOT be used in the area."

The H-bit aware routers will revert to normal operation if they detect routers 
not processing the H-bit. Therefore, if ever there is a discrepancy it not 
cause long term inconsistencies nor loops. In effect, H-bit processing is 
either done by all or no one in the area.

Let me know if this answers your question.
Padma


On 02/12/2019, 17:59, "iesg on behalf of Alvaro Retana" 
mailto:iesg-boun...@ietf.org> on behalf of 
aretana.i...@gmail.com> wrote:

On November 30, 2019 at 11:21:01 AM, Éric Vyncke wrote:

Eric:

Hi!

> == DISCUSS ==
>
> -- Section 5 --
> The risk of having inconsistent view of the topology with H-bit aware and
> unaware routers seems possible to me (albeit perhaps only transient). Has
> this feature been tested / simulated in large scale networks?

Yes, as with other operations in a network (reconvergence, for
example), there is a risk of transient inconsistency.  §5 already
makes recommendations to mitigate transient states.  What explicitly
are you looking for to address your DISCUSS?

I'll let the authors reply about tests/simulations.

Thanks!

Alvaro.



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

Re: [Lsr] "YANG Module for IS-IS Reverse Metric" - draft-hopps-lsr-yang-isis-reverse-metric-02

[Acee Lindem (acee)]

Speaking as a WG member, I support adoption.
Thanks,
Acee

From: Lsr  on behalf of Acee Lindem 
Date: Monday, November 25, 2019 at 7:27 AM
To: "lsr@ietf.org" 
Cc: Christian Hopps 
Subject: [Lsr] "YANG Module for IS-IS Reverse Metric" - 
draft-hopps-lsr-yang-isis-reverse-metric-02

This begins a two week LSR Working Group adoption call for the subject document.

https://datatracker.ietf.org/doc/draft-hopps-lsr-yang-isis-reverse-metric/

Please indicate your support or objection to adoption to the LSR list 
(lsr@ietf.org) prior to 12:00 AM UTC on December 10th, 
2019.

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

[Lsr] IPR Poll on "YANG Module for IS-IS Reverse Metric" - draft-hopps-lsr-yang-isis-reverse-metric-02

[Acee Lindem (acee)]

Authors,

Are you aware of any IPR that applies to 
draft-hopps-lsr-yang-isis-reverse-metric-02?

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

[Lsr] "YANG Module for IS-IS Reverse Metric" - draft-hopps-lsr-yang-isis-reverse-metric-02

[Acee Lindem (acee)]

This begins a two week LSR Working Group adoption call for the subject document.

https://datatracker.ietf.org/doc/draft-hopps-lsr-yang-isis-reverse-metric/

Please indicate your support or objection to adoption to the LSR list 
(lsr@ietf.org) prior to 12:00 AM UTC on December 10th, 
2019.

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

Re: [Lsr] draft-hopps-lsr-yang-isis-reverse-metric-02

[Acee Lindem (acee)]

Hi Tom, 

I agree with your comments. I'm going to start a WG adoption poll on this 
document as it is pretty straight-forward. See one inline.  

On 11/24/19, 2:44 AM, "Lsr on behalf of tom petch"  wrote:

Christian

Some stray thoughts

/intermediate system routeing/intermediate system routing/
since we have to use the American style:-(

We sometimes violate this rule if it is a direct reference to an ISO document 
of a text lifted directly from ISO specification. However, the two instances 
are not so I'd recommend, "Intermediate System to Intermediate System (IS-IS) 
routing" for both references. 

Thanks,
Acee


 import ietf-routing { prefix "rt"; }
lacks a reference clause and the reference should be in the Normative
References


 import ietf-isis { prefix "isis"; }
lacks a reference clause

IS-IS reverse metric functionality [RFC8500].
YANG module must be plain text and this looks like it is not.


Tom Petch

___
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] "OSPFv3 Extensions for SRv6" - draft-li-ospf-ospfv3-srv6-extensions-07 Questions/Comments

[Acee Lindem (acee)]

Hi Ketan,

From: "Ketan Talaulikar (ketant)" 
Date: Monday, November 18, 2019 at 7:24 AM
To: Acee Lindem , 
"draft-li-ospf-ospfv3-srv6-extensi...@ietf.org" 

Cc: "lsr@ietf.org" 
Subject: RE: "OSPFv3 Extensions for SRv6" - 
draft-li-ospf-ospfv3-srv6-extensions-07 Questions/Comments

Hi Acee,

Thanks for your review and comments. Please check inline below.

From: Acee Lindem (acee) 
Sent: 18 November 2019 06:18
To: draft-li-ospf-ospfv3-srv6-extensi...@ietf.org
Cc: lsr@ietf.org
Subject: "OSPFv3 Extensions for SRv6" - draft-li-ospf-ospfv3-srv6-extensions-07 
Questions/Comments

Hi Authors,
I know you have asked for adoption and I have some comments on the draft. I 
think these need to be addressed or at least answered prior to any LSR adoption 
call. In my opinion, this document is not ready.


1.  Why do you define a separate SRv6 Locator LSA to advertise SRv6 
reachability? One of the primary benefits of RFC8362 is to advertise all the 
information associated with a prefix in one LSA. Now you have negated that 
benefit by putting this information in a separate LSA.
[KT] We need to define a new LSA since this is not an extension for the normal 
prefix reachability. For doing FlexAlgo with SRv6, the locators are used for 
reachability computation within the FlexAlgo. If these were advertised as 
normal prefix reachability then routers which are not part of the FlexAlgo or 
even routers not supporting SRv6 would program them. We’ve tried to explain 
this in 
https://tools.ietf.org/html/draft-li-ospf-ospfv3-srv6-extensions-07#section-5.

Note that in ISIS, the SRv6 Locators are introduced as a new top-level TLV 
along side the Prefix Reachability TLV. So what we propose in OSPFv3 is 
consistent with that model.

Ok – I thought one advantage of SRv6 is that you simply route through routers 
that don’t support SRv6? If you don’t program the locator in these, how does 
this work?


2.  Why do always advertise 128 bit values even when you don’t need it? You 
should only advertise the part of the Locator or SID required dependent on the 
LOC:FUNCTION split (padded to a 4 octet boundary). I would expect the SIDs the 
are Sub-TLVs of the Locator TLV would have that locator in the high-order bit…
[KT] I believe the Locator being a prefix can be advertised only up to the LOC 
part – similar to how it’s done for IS-IS. The SID is being advertised as a 
128-bit value (IPv6 address and not subnet/prefix) and hence we’ve tried to be 
consistent with the same in OSPFv3 as well.

I guess an advantage of this 128-bit format is that it makes the value easier 
to consume? However, with this full expansion, you also need to check that the 
Locator is consistent with the top-level TLV.

Thanks,
Acee



3.  Similarly, what is the purpose of the SRv6 SID Structure Sub-TLV? 
ietf-spring-srv6-network-programming defines the locator to the first N bits 
and the function to the remaining 128-N bits so I don’t see the need for this 
TLV. At the very least, there should be text defining how it is used.
[KT] This is consistent with 
https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05#section-3.1

Also, some editorial comments to make the text consistent with other OSPF 
documents.


1.  There is a mixture of US English and UK English of preferred spellings. 
Please use the US English as the is the style of IETF documents. For example, 
lose the extra “u” in “behavior”.

2.  OSPF doesn’t define sub-sub-TLVs, sub-sub-sub-TLVs, or any other 
alliterative TLVs.  This is an IS-IS artifact. Any TLV that is not a top-level 
TLV is a Sub-TLV and can be defined at any level of nesting. The GMPLS optical 
encodings in OSPF are very heavily nested.

3.  Sub-TLV is capitalized, not “sub-TLVs”.
[KT] Mea culpa … we’ll fix all of these in the next update.

Thanks,
Ketan

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

[Lsr] "OSPFv3 Extensions for SRv6" - draft-li-ospf-ospfv3-srv6-extensions-07 Questions/Comments

[Acee Lindem (acee)]

Hi Authors,
I know you have asked for adoption and I have some comments on the draft. I 
think these need to be addressed or at least answered prior to any LSR adoption 
call. In my opinion, this document is not ready.


  1.  Why do you define a separate SRv6 Locator LSA to advertise SRv6 
reachability? One of the primary benefits of RFC8362 is to advertise all the 
information associated with a prefix in one LSA. Now you have negated that 
benefit by putting this information in a separate LSA.
  2.  Why do always advertise 128 bit values even when you don’t need it? You 
should only advertise the part of the Locator or SID required dependent on the 
LOC:FUNCTION split (padded to a 4 octet boundary). I would expect the SIDs the 
are Sub-TLVs of the Locator TLV would have that locator in the high-order bit…
  3.  Similarly, what is the purpose of the SRv6 SID Structure Sub-TLV? 
ietf-spring-srv6-network-programming defines the locator to the first N bits 
and the function to the remaining 128-N bits so I don’t see the need for this 
TLV. At the very least, there should be text defining how it is used.

Also, some editorial comments to make the text consistent with other OSPF 
documents.


  1.  There is a mixture of US English and UK English of preferred spellings. 
Please use the US English as the is the style of IETF documents. For example, 
lose the extra “u” in “behavior”.
  2.  OSPF doesn’t define sub-sub-TLVs, sub-sub-sub-TLVs, or any other 
alliterative TLSs.  This is an IS-IS artifact. Any TLV that is not a top-level 
TLV is a Sub-TLV and can be defined at any level of nesting. The GMPLS optical 
encodings in OSPF are very heavily nested.
  3.  Sub-TLV is capitalized, not “sub-TLVs”.

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

Re: [Lsr] [Last-Call] Tsvart last call review of draft-ietf-ospf-ospfv2-hbit-10

[Acee Lindem (acee)]

Hi Alvaro, 

On 11/7/19, 11:58 AM, "Alvaro Retana"  wrote:

On November 3, 2019 at 2:28:29 PM, Padma Pillay-Esnault wrote:

Padma:

Hi!

See below...

> On Sat, Nov 2, 2019 at 7:03 PM Benjamin Kaduk wrote:
> > On Thu, Oct 31, 2019 at 03:50:45PM -0700, Padma Pillay-Esnault wrote:
> > > On Thu, Oct 31, 2019 at 2:47 PM Kyle Rose via Datatracker
> > > wrote:
> > >
> > > > * I'm curious what happens if a router sets the H-bit when it is on 
the
> > > > only feasible transit path.
> > >
> > > PPE - The router with the H-bit set will not be "on the only feasible
> > > transit path" to other destinations. The H-bit functionality will 
exclude
> > > the host router from the path calculation in the SPF.
> >
> > I think you are talking about normal operation ("will not be on the only
> > feasible transit path") and Kyle is asking about misconfiguration or
> > similar edge cases.
>
> Thanks for this clarification.
> >
> > Having only read this email thread and not the document itself, I assume
> > that traffic will fail to flow if such a misconfiguration occurred, but 
it
> > would be good to confirm/refute that.
>
> Yes you are right ... for some cases.
>
> Assuming the router with the H-bit clear is on the only transit path. 
There
> are several cases see below.
>
> Normal case:
> The router has H-bit set
> (a) All routers in the area support the H-bit then the router is excluded 
in
> the SPF calculations and traffic will not flow.
> (b) At least one router in the area does not support H-bit then H-bit is 
not
> active in area. The traffic will flow as per normal OSPF operation.
>
> Misconfiguration case:
> The router has H-bit erroneously set (misconfig)
> (a) All routers in the areas support H-bit then the router is excluded in 
the
> SPF calculations and traffic will not flow.
> (b) At least one router in the area does not support H-bit then H-bit is 
not
> active in area. The traffic will flow as per normal OSPF operation.
>
> The Section 8 of the document has a discussion on this.

Yes, there is a discussion in §8, but I think we left out the case
where a rogue router, who is on the only transit path, may set the
H-bit (for no good/valid reason) and effectively partition the
network.  This case is indistinguishable from the normal case where
the operator (still on the only transit path) may consciously decide
to set the H-bit to perform maintenance, for example.

Please add a new bullet to cover this case.

If an OSPFv2 router is a trusted participant in the OSPFv2 routing domain (with 
or without cryptographic authentication), there are at least 3 or 4 other ways 
in which it could partition the routing domain. This is just one more. However, 
I'm not opposed to adding the bullet as this is "what we do" during the 
security reviews. 

Thanks,
Acee


Thanks!

Alvaro.


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

Re: [Lsr] Genart last call review of draft-ietf-ospf-ospfv2-hbit-10

[Acee Lindem (acee)]

See one inline.

From: Acee Lindem 
Date: Thursday, October 31, 2019 at 2:39 PM
To: Padma Pillay-Esnault , Mohit Sethi 

Cc: "gen-...@ietf.org" , "last-c...@ietf.org" 
, "draft-ietf-ospf-ospfv2-hbit@ietf.org" 
, "lsr@ietf.org" 
Subject: Re: Genart last call review of draft-ietf-ospf-ospfv2-hbit-10
Resent-From: 
Resent-To: Keyur Patel , , 
, , Yingzhen Qu 
, Christian Hopps , Acee Lindem 
, Martin Vigoureux , Deborah 
Brungard , Alvaro Retana , Yingzhen Qu 

Resent-Date: Thursday, October 31, 2019 at 2:39 PM

HI Padma, Mohit,

From: Padma Pillay-Esnault 
Date: Thursday, October 31, 2019 at 2:17 PM
To: Mohit Sethi 
Cc: "gen-...@ietf.org" , "last-c...@ietf.org" 
, "draft-ietf-ospf-ospfv2-hbit@ietf.org" 
, "lsr@ietf.org" , 
Padma Pillay-Esnault 
Subject: Re: Genart last call review of draft-ietf-ospf-ospfv2-hbit-10
Resent-From: 
Resent-To: Keyur Patel , , 
, , Yingzhen Qu 
, Christian Hopps , Acee Lindem 
, Martin Vigoureux , Deborah 
Brungard , Alvaro Retana , Yingzhen Qu 

Resent-Date: Thursday, October 31, 2019 at 2:17 PM

Dear Mohit

Thank you for your review.

Please see below PPE for responses and suggestion.

Padma

On Thu, Oct 31, 2019 at 1:08 AM Mohit Sethi via Datatracker 
mailto:nore...@ietf.org>> wrote:
Reviewer: Mohit Sethi
Review result: Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-ospf-ospfv2-hbit-10
Reviewer: Mohit Sethi
Review Date: 2019-10-31
IETF LC End Date: 2019-11-07
IESG Telechat date: Not scheduled for a telechat

Summary:
This document uses a bit in the link state advertisement (LSA) sent from
routers to indicate that they are hosts which will not forward transit traffic.
The document is READY for publication.

Major issues:

Minor issues:
I think the document would benefit from some more discussion on what happens if
a router that is repelling traffic is on the only path to some destinations?
PPE:
The router with the H-bit set will not be "on the only path" to other 
destinations, rather it would look that there is no path for transit traffic to 
other routers.

CURRENT:
This document describes the Host-bit (H-bit) functionality that prevents other 
OSPFv2 routers from using the host router for transit traffic in OSPFv2 routing 
domains.

SUGGESTED NEW:
This document describes the Host-bit (H-bit) functionality that prevents other 
OSPFv2 routers from using the host router by excluding it in path calculations 
for transit traffic in OSPFv2 routing domains.

This sounds fine to me. However, I was surprised that this was apparent from 
the original abstract and first paragraph of the introduction.

I meant “not apparent”…

Acee

Does this address your comment?
How is this handled?

PPE:
The changes in the SPF calculation in Section 4 ensure that the router with the 
H-bit set is excluded for the
path calculations for transit traffic.

Is it fair to say that H-bit is only a best effort way of
repelling traffic and does not guarantee that the transit traffic is actually
interrupted?

PPE:
No that would not be correct.
The above describes the best effort that exists today with use of metrics and 
this is the gap that H-bit is addressing.
With the H-bit functionality, the host router will not attract the transit 
traffic as it is excluded from route calculations other than its host 
destination(s).
Indeed, other OSPFv2 routers in the domain should not forward any transit 
traffic to it as the host router will not appear on the path at all.


Any reason that this is only done for OSPFv2 and not v3? Are there ways of
achieving this functionality (of repelling transit traffic) already in v3?

PPE:
No needed in OSPFv3 as it has a similar mechanism in the standard already.

A little more background for Mohit… OSPFv3 followed OSPFv2 by about 5+ years 
and preventing transit traffic was recognized as a requirement. In OSPFv3 (RFC 
5340), the corollary function is provided by the R-bit which must be set in 
order for a Router’s Router-LSA to be used in path computations for transit 
traffic. We would have liked to have used the same R-bit in OSPFv2 but it would 
not have been backward compatible since you can’t mandate that a bit be set for 
an existing LSA to be used. Hence, the OSPFv2 H-bit is the corollary of the 
OSPFv3 R-bit.

Thanks,
Acee


Nits/editorial comments:
- Please expand acronyms like NSSA and LSAs on first usage.
PPE: Fixed

OLD:
In addition, this document updates RFC 6987 to advertise type-2 External
   and NSSA LSAs with a high cost in order to repel traffic effectively.

NEW:

In addition, this document updates RFC 6987 to advertise type-2 External
   and Not-So-Stubby-Area (NSSA) Link State Advertisements (LSAs) with a
   high cost in order to repel traffic effec

Re: [Lsr] Genart last call review of draft-ietf-ospf-ospfv2-hbit-10

[Acee Lindem (acee)]

HI Padma, Mohit,

From: Padma Pillay-Esnault 
Date: Thursday, October 31, 2019 at 2:17 PM
To: Mohit Sethi 
Cc: "gen-...@ietf.org" , "last-c...@ietf.org" 
, "draft-ietf-ospf-ospfv2-hbit@ietf.org" 
, "lsr@ietf.org" , 
Padma Pillay-Esnault 
Subject: Re: Genart last call review of draft-ietf-ospf-ospfv2-hbit-10
Resent-From: 
Resent-To: Keyur Patel , , 
, , Yingzhen Qu 
, Christian Hopps , Acee Lindem 
, Martin Vigoureux , Deborah 
Brungard , Alvaro Retana , Yingzhen Qu 

Resent-Date: Thursday, October 31, 2019 at 2:17 PM

Dear Mohit

Thank you for your review.

Please see below PPE for responses and suggestion.

Padma

On Thu, Oct 31, 2019 at 1:08 AM Mohit Sethi via Datatracker 
mailto:nore...@ietf.org>> wrote:
Reviewer: Mohit Sethi
Review result: Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-ospf-ospfv2-hbit-10
Reviewer: Mohit Sethi
Review Date: 2019-10-31
IETF LC End Date: 2019-11-07
IESG Telechat date: Not scheduled for a telechat

Summary:
This document uses a bit in the link state advertisement (LSA) sent from
routers to indicate that they are hosts which will not forward transit traffic.
The document is READY for publication.

Major issues:

Minor issues:
I think the document would benefit from some more discussion on what happens if
a router that is repelling traffic is on the only path to some destinations?
PPE:
The router with the H-bit set will not be "on the only path" to other 
destinations, rather it would look that there is no path for transit traffic to 
other routers.

CURRENT:
This document describes the Host-bit (H-bit) functionality that prevents other 
OSPFv2 routers from using the host router for transit traffic in OSPFv2 routing 
domains.

SUGGESTED NEW:
This document describes the Host-bit (H-bit) functionality that prevents other 
OSPFv2 routers from using the host router by excluding it in path calculations 
for transit traffic in OSPFv2 routing domains.

This sounds fine to me. However, I was surprised that this was apparent from 
the original abstract and first paragraph of the introduction.

Does this address your comment?
How is this handled?

PPE:
The changes in the SPF calculation in Section 4 ensure that the router with the 
H-bit set is excluded for the
path calculations for transit traffic.

Is it fair to say that H-bit is only a best effort way of
repelling traffic and does not guarantee that the transit traffic is actually
interrupted?

PPE:
No that would not be correct.
The above describes the best effort that exists today with use of metrics and 
this is the gap that H-bit is addressing.
With the H-bit functionality, the host router will not attract the transit 
traffic as it is excluded from route calculations other than its host 
destination(s).
Indeed, other OSPFv2 routers in the domain should not forward any transit 
traffic to it as the host router will not appear on the path at all.


Any reason that this is only done for OSPFv2 and not v3? Are there ways of
achieving this functionality (of repelling transit traffic) already in v3?

PPE:
No needed in OSPFv3 as it has a similar mechanism in the standard already.

A little more background for Mohit… OSPFv3 followed OSPFv2 by about 5+ years 
and preventing transit traffic was recognized as a requirement. In OSPFv3 (RFC 
5340), the corollary function is provided by the R-bit which must be set in 
order for a Router’s Router-LSA to be used in path computations for transit 
traffic. We would have liked to have used the same R-bit in OSPFv2 but it would 
not have been backward compatible since you can’t mandate that a bit be set for 
an existing LSA to be used. Hence, the OSPFv2 H-bit is the corollary of the 
OSPFv3 R-bit.

Thanks,
Acee


Nits/editorial comments:
- Please expand acronyms like NSSA and LSAs on first usage.
PPE: Fixed

OLD:
In addition, this document updates RFC 6987 to advertise type-2 External
   and NSSA LSAs with a high cost in order to repel traffic effectively.

NEW:

In addition, this document updates RFC 6987 to advertise type-2 External
   and Not-So-Stubby-Area (NSSA) Link State Advertisements (LSAs) with a
   high cost in order to repel traffic effectively.

- Abstract has stray " symbol.
PPE:  Fixed

OLD:
This document defines a bit (Host-bit) that enables a router to advertise that 
it is a non-transit router."

NEW:
This document defines a bit (Host-bit) that enables a router to advertise that 
it is a non-transit router.


-  The list in the acknowledgements section could benefit from an Oxford comma:
Abhay Roy, David Ward, Burjiz Pithawala, and Michael Barnes for their comments.
PPE: Fixed

OLD:
Abhay Roy, David Ward, Burjiz Pithawala and Michael Barnes for their comments.

NEW:
Abha

[Lsr] Early Allocation request for "OSPF Prefix Originator Extension" - draft-ietf-lsr-ospf-prefix-originator-04

[Acee Lindem (acee)]

Hi Amanda, et al,

We have some implementation momentum and wish to request early IANA allocation 
for OSPFv2 and OSPFv3 code points in the subject draft.

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

[Lsr] "Signaling Entropy Label Capability and Entropy Readable Label-stack Depth Using OSPF" IPR

[Acee Lindem (acee)]

All,

I you were paying attention, you noticed that publication was requested for 
both the OSPF and IS-IS Entropy Label signaling drafts.

During the review, we found the IPR statement was missing from the OSPF draft 
in the data tracker. This was an oversite on my part as the “Replaces” 
meta-data for the draft didn’t get updated when the draft was adopted as a WG 
document. Normally, this happen automatically when the draft file name only 
changes from the “author(s)” to “ietf”, but in this case it didn’t. This has 
been rectified but I wanted to make clear that this is not a new IPR 
declaration.

https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-ospf-mpls-elc


Thanks,
Acee



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

Re: [Lsr] IPR Call for New Co-authors of draft-ietf-ospf-mpls-elc-11.txt - "Signaling Entropy Label Capability and Entropy Readable Label-stack Depth Using OSPF" (And this one)

[Acee Lindem (acee)]

We’ve now received replies from all the new authors and contributors. We’ll 
proceed with publication.
Thanks,
Acee

From: Keyur Patel 
Date: Monday, October 21, 2019 at 12:49 PM
To: Wim Henderickx , Gunter Van de Velde 
, Acee Lindem 
Cc: "lsr@ietf.org" , Alvaro Retana , 
"Bocci, Matthew (Nokia - GB)" 
Subject: Re: IPR Call for New Co-authors of draft-ietf-ospf-mpls-elc-11.txt - 
"Signaling Entropy Label Capability and Entropy Readable Label-stack Depth 
Using OSPF" (And this one)

Not aware of IPR related to this draft.

From: "Henderickx, Wim (Nokia - BE/Antwerp)" 
Date: Monday, October 21, 2019 at 9:04 AM
To: "Van De Velde, Gunter (Nokia - BE/Antwerp)" 
, "Acee Lindem (acee)" 
Cc: "lsr@ietf.org" , Alvaro Retana , 
"Bocci, Matthew (Nokia - GB)" , Keyur Patel 

Subject: Re: IPR Call for New Co-authors of draft-ietf-ospf-mpls-elc-11.txt - 
"Signaling Entropy Label Capability and Entropy Readable Label-stack Depth 
Using OSPF" (And this one)

Not aware of IPR related to this draft

From: Gunter VAN DE VELDE 
Date: Monday, 21 October 2019 at 16:39
To: "Acee Lindem (acee)" 
Cc: "lsr@ietf.org" , Alvaro Retana , 
"Bocci, Matthew (Nokia - GB)" , Keyur Patel 
, "Henderickx, Wim (Nokia - BE/Antwerp)" 

Subject: RE: IPR Call for New Co-authors of draft-ietf-ospf-mpls-elc-11.txt - 
"Signaling Entropy Label Capability and Entropy Readable Label-stack Depth 
Using OSPF" (And this one)

Hi Acee,

I am not aware of any IPR that has not been disclosed already.

Kind Regards,
G/


From: Acee Lindem (acee) 
Sent: Monday, October 21, 2019 16:43
To: Bocci, Matthew (Nokia - GB) ; Keyur Patel 
; Henderickx, Wim (Nokia - BE/Antwerp) 
; Van De Velde, Gunter (Nokia - BE/Antwerp) 

Cc: lsr@ietf.org; Alvaro Retana 
Subject: IPR Call for New Co-authors of draft-ietf-ospf-mpls-elc-11.txt - 
"Signaling Entropy Label Capability and Entropy Readable Label-stack Depth 
Using OSPF" (And this one)

New Author and Contributors,

Are you aware of any IPR that applies to draft-ietf-ospf-mpls-elc-11?

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] IPR Call for New Co-authors of draft-ietf-isis-mpls-elc-10.txt - "Signaling Entropy Label Capability and Entropy Readable Label-stack Depth Using OSPF" (Corrected)

[Acee Lindem (acee)]

We’ve now received replies from all the new authors and contributors – we’ll 
proceed with publication.
Thanks,
Acee

From: Keyur Patel 
Date: Monday, October 21, 2019 at 12:50 PM
To: Wim Henderickx , Gunter Van de Velde 
, Acee Lindem , "Bocci, Matthew 
(Nokia - GB)" 
Cc: "lsr@ietf.org" , Alvaro Retana 
Subject: Re: IPR Call for New Co-authors of draft-ietf-isis-mpls-elc-10.txt - 
"Signaling Entropy Label Capability and Entropy Readable Label-stack Depth 
Using OSPF" (Corrected)

Not aware of IPR related to this draft.

From: "Henderickx, Wim (Nokia - BE/Antwerp)" 
Date: Monday, October 21, 2019 at 9:03 AM
To: "Van De Velde, Gunter (Nokia - BE/Antwerp)" 
, "Acee Lindem (acee)" , "Bocci, 
Matthew (Nokia - GB)" , Keyur Patel 
Cc: "lsr@ietf.org" , Alvaro Retana 
Subject: Re: IPR Call for New Co-authors of draft-ietf-isis-mpls-elc-10.txt - 
"Signaling Entropy Label Capability and Entropy Readable Label-stack Depth 
Using OSPF" (Corrected)

Not aware of IPR related to this draft

From: Gunter VAN DE VELDE 
Date: Monday, 21 October 2019 at 16:38
To: "Acee Lindem (acee)" , "Bocci, Matthew (Nokia - GB)" 
, Keyur Patel , "Henderickx, Wim 
(Nokia - BE/Antwerp)" 
Cc: "lsr@ietf.org" , Alvaro Retana 
Subject: RE: IPR Call for New Co-authors of draft-ietf-isis-mpls-elc-10.txt - 
"Signaling Entropy Label Capability and Entropy Readable Label-stack Depth 
Using OSPF" (Corrected)

Hi Acee,

I am not aware of any IPR that has not been disclosed already.

Kind Regards,
G/

From: Acee Lindem (acee) 
Sent: Monday, October 21, 2019 16:40
To: Bocci, Matthew (Nokia - GB) ; Keyur Patel 
; Henderickx, Wim (Nokia - BE/Antwerp) 
; Van De Velde, Gunter (Nokia - BE/Antwerp) 

Cc: lsr@ietf.org; Alvaro Retana 
Subject: IPR Call for New Co-authors of draft-ietf-isis-mpls-elc-10.txt - 
"Signaling Entropy Label Capability and Entropy Readable Label-stack Depth 
Using OSPF" (Corrected)

New Author and Contributors,

Are you aware of any IPR that applies to draft-ietf-ospf-mpls-elc-11?

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

[Lsr] IPR Call for New Co-authors of draft-ietf-ospf-mpls-elc-11.txt - "Signaling Entropy Label Capability and Entropy Readable Label-stack Depth Using OSPF" (And this one)

[Acee Lindem (acee)]

New Author and Contributors,

Are you aware of any IPR that applies to draft-ietf-ospf-mpls-elc-11?

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

[Lsr] IPR Call for New Co-authors of draft-ietf-isis-mpls-elc-10.txt - "Signaling Entropy Label Capability and Entropy Readable Label-stack Depth Using IS-IS" (Reply to this one)

[Acee Lindem (acee)]

New Author and Contributors,

Are you aware of any IPR that applies to draft-ietf-isis-mpls-elc-10?

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

[Lsr] IPR Call for New Co-authors of draft-ietf-isis-mpls-elc-10.txt - "Signaling Entropy Label Capability and Entropy Readable Label-stack Depth Using OSPF" (Corrected)

[Acee Lindem (acee)]

New Author and Contributors,

Are you aware of any IPR that applies to draft-ietf-ospf-mpls-elc-11?

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

[Lsr] IPR Call for New Co-authors of draft-ietf-isis-mpls-elc-10.txt - "Signaling Entropy Label Capability and Entropy Readable Label-stack Depth Using OSPF"

[Acee Lindem (acee)]

New Author and Contributors,

Are you aware of any IPR that applies to draft-ietf-isis-mpls-elc-07?

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] Benjamin Kaduk's No Objection on draft-ietf-isis-yang-isis-cfg-41: (with COMMENT)

[Acee Lindem (acee)]

Hi Ben,
Thanks again for the detailed review. I've made the editorial changes below in 
the -42 version.
Thanks,
Acee

On 10/15/19, 1:38 AM, "Benjamin Kaduk via Datatracker"  
wrote:

Benjamin Kaduk has entered the following ballot position for
draft-ietf-isis-yang-isis-cfg-41: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-isis-yang-isis-cfg/



--
COMMENT:
--

Thanks for the updates in the -41!
I think that "i-e" in the following got missed, but that can probably be 
done with an
RFC Editor note, so I'm clearing my Discuss:

 grouping neighbor {
   description  "IS-IS standard neighbor grouping.";
   leaf neighbor-id {
 type extended-system-id;
 description "IS-IS neighbor system-id";
   }
  container instances {
 description "List of all adjacencies between the local
  system and the neighbor system-id.";
 list instance {
   key id;

   leaf id {
 type uint32;
 description "Unique identifier of an instance of a
  particular neighbor.";
   }
   leaf i-e {
 type boolean;
 description
   "Internal or External (I/E) Metric bit value";
   }

Also, I think that a spurious 'd' got added into "Routing Information 
Based".




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

Re: [Lsr] Adam Roach's No Objection on draft-ietf-isis-yang-isis-cfg-40: (with COMMENT)

[Acee Lindem (acee)]

Hi Chris,
We made this change in -41.
Thanks,
Acee

On 10/8/19, 6:14 AM, "Christian Hopps"  wrote:

should have read "or it supports more than 32"

> On Oct 8, 2019, at 5:53 AM, Christian Hopps  wrote:
> 
> This strikes me as one of these artificial limits that gains us almost 
nothing (what if the platform supports less than 32 or it supports 32?), and 
creates these backward incompatible YANG issues (ranges that have to change) 
that are part of what is driving the complexity in the YANG versioning stuff. 
Why don't we just have a no range u16 or a 1..max range?
> Thanks,
> Chris.
    > 
>> On Oct 7, 2019, at 12:44 PM, Acee Lindem (acee)  wrote:
>> 
>>>  grouping spf-parameters {
>>>container spf-control {
>>>leaf paths {
>>>  if-feature max-ecmp;
>>>  type uint16 {
>>>range "1..32";
>>>  }
>> 
>>   Why is this a uint16 rather than a uint8?
>> 
>> It definitely could be uint8.
> 



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

Re: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-isis-yang-isis-cfg-40: (with DISCUSS and COMMENT)

[Acee Lindem (acee)]

Hi Ben, 
Thanks for the excellent review - see one inline. 

On 10/8/19, 6:13 AM, "Benjamin Kaduk"  wrote:

Hi Stephane,

Thanks for pulling in the fixes; just a few notes inline (and trimming)...

On Tue, Oct 08, 2019 at 10:33:49AM +0200, slitkows.i...@gmail.com wrote:
> Hi Benjamin,
> 
> Thanks for your comment.
> Please find some inline answers.
> I'm doing the changes as part of the -41.
> 
> 
> Stephane
> 
> -Original Message-
> From: Benjamin Kaduk via Datatracker  
> Sent: mercredi 2 octobre 2019 03:17
> To: The IESG 
> Cc: draft-ietf-isis-yang-isis-...@ietf.org; Yingzhen Qu 
; aretana.i...@gmail.com; lsr-cha...@ietf.org; 
yingzhen.i...@gmail.com; lsr@ietf.org
> Subject: Benjamin Kaduk's Discuss on draft-ietf-isis-yang-isis-cfg-40: 
(with DISCUSS and COMMENT)
> 
[...]
> 
> 
> In the "protection-available" container, is there some sort of constraint 
that two of the alternate-metrics add up to the third?
> [SLI] It is not really a constraint from a YANG point of view, these are 
operational counters.

Sorry, I shouldn't have used the word "constraint", since that's a YANG
verb.  I was just asking if the description should reiterate to the reader
that in normal circumstances the two will add up to the third (and "no" is
a fine answer).

[...]
>container delay-metric {
>  leaf metric {
>type std-metric;
>description "IS-IS delay metric for IPv4 prefix";
>  }
>  leaf supported {
>type boolean;
> 
> Should the "metric" leaf be conditional on "supported" being true?
> (Same for the other flavors of metric, as well as when they appear later 
on in the "neighbor" grouping.)
> 
> 
> [SLI] This is not a configuration leaf, so I don't think that there is a 
need for enforcement at YANG level.

Oh, I had missed that it was config false; sorry about that.

[...]
> 
>container unidirectional-link-delay-variation {
>  description
>"Container for the average delay variation
>from the local neighbor to the remote one.";
>  leaf value {
>type uint32;
>units usec;
>description
>  "Delay variation value expressed in microseconds.";
> 
> Is this a standard deviation (variance), mean absolute error, ...?
> [SLI] We just mimic what is defined in RFC8570. As the reference is 
defined in the model. People should refer to it for more details.
> Moreover this is a pure operational state.

https://tools.ietf.org/html/rfc8570#section-4.3 still leaves me a little
unclear about what exactly is being reported (it sounds like it's just an
average link delay so the word "variation" confuses me), but I agree that
we should not say any more in this document.

>container unidirectional-link-loss {
>  [...]
>  leaf value {
>type uint32;
>units percent;
>description
>  "Link packet loss expressed as a percentage
>  of the total traffic sent over a configurable interval.";
> 
> This document is all about specifying configuration.  How do I configure 
the interval in question?
> [SLI] This is an operational state.

The leaf value is operational state, yes, but it reports a valid computed
"over a configurable interval".  How do I configure that interval?

I don't disagree that there is more configuration and state associated with 
these traffic metrics. However, these are not really under the purview of this 
model since IS-IS (and OSPF for that matter) are only serving as a mechanism to 
advertise these traffic metrics. 

Thanks,
Acee

Thanks!

-Ben


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

Re: [Lsr] Adam Roach's No Objection on draft-ietf-isis-yang-isis-cfg-40: (with COMMENT)

[Acee Lindem (acee)]

Hi Adam, 

Thanks for review. 

On 10/2/19, 6:31 PM, "Adam Roach via Datatracker"  wrote:

Adam Roach has entered the following ballot position for
draft-ietf-isis-yang-isis-cfg-40: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-isis-yang-isis-cfg/



--
COMMENT:
--


Thanks for the work that went into this model. I have only a handful
of minor issues I found when reading through the module.

---

>grouping spf-parameters {
>  container spf-control {
>  leaf paths {
>if-feature max-ecmp;
>type uint16 {
>  range "1..32";
>}

Why is this a uint16 rather than a uint8?

It definitely could be uint8. 

---

>  leaf-list tag {
>type uint32;
>description
>  "List of 32-bit tags associated with the IPv4 prefix.";
>  }
>  leaf-list tag64 {
>type uint64;
>description
>  "List of 32-bit tags associated with the IPv4 prefix.";
>  }

I think this second description is meant to say "64-bit" rather than 
"32-bit".

Fixed and will be in the -41 version. 

---

>  leaf reason {
>type string {
>  length "1..255";
>}
>description
>  "The system may provide a reason to reject the
>   adjacency. If the reason is not available,
>   an empty string will be returned.
>   The expected format is a single line text.";
>  }

This description is inconsistent with the definition: it calls for an empty
string, while the definition requires that at lest one character be 
present. If
you want to keep the description as-is, you need to adjust the length to be
"0..255". Alternately, you might indicate that the field is simply to be
omitted rather than empty, which appears to be the intention for other
"reason" fields in this model.

Actually, I think the intension was to return a string consisting solely of the 
EOL character ('\0'). However, I think not returning a string is a better 
alternative. 

Thanks
Acee




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

Re: [Lsr] WG Adoption poll for draft-acee-lsr-ospf-yang-augmentation-v1-01

[Acee Lindem (acee)]

Speaking as a co-author, I support this draft. When we froze the features in 
the base OSPF YANG model so it could be published, we committed to supporting 
new RFCs and drafts in separate model in a new draft.

I don't know of any IPR.
 
Thanks,
Acee

On 10/2/19, 5:29 PM, "Lsr on behalf of Christian Hopps"  wrote:

Hi Folks,

This begins a 2 week WG adoption poll for the following:

  https://datatracker.ietf.org/doc/draft-acee-lsr-ospf-yang-augmentation-v1/

Please send any comments to the list by Wednesday Oct 16th, 2019.

Thanks,
Chris.


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

Re: [Lsr] WG Adoption Poll for draft-acee-lsr-ospfv3-extended-lsa-yang-06

[Acee Lindem (acee)]

Speaking as co-author, I support this draft. It is required for all OSPFv3 
extensions utilizing RFC8362 extended LSA encodings.
Additionally, I'm not aware of any IPR. 

Thanks,
Acee

On 10/2/19, 5:27 PM, "Lsr on behalf of Christian Hopps"  wrote:

Hi Folks,

This begins a 2 week WG adoption poll for the following:

  https://datatracker.ietf.org/doc/draft-acee-lsr-ospfv3-extended-lsa-yang/

Please send any comments to the list by Wednesday Oct 16th, 2019.

Thanks,
Chris.


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

Re: [Lsr] Roman Danyliw's Discuss on draft-ietf-isis-yang-isis-cfg-40: (with DISCUSS)

[Acee Lindem (acee)]

Hi Roman, 

On 10/1/19, 4:28 PM, "Roman Danyliw via Datatracker"  wrote:

Roman Danyliw has entered the following ballot position for
draft-ietf-isis-yang-isis-cfg-40: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-isis-yang-isis-cfg/



--
DISCUSS:
--

Section 7.  A DISCUSS for discussion.  Thanks for this enumeration of 
writeable
and readable nodes which could be considered sensitive.  Per the list of 
nodes
that could expose the topology of the network, wouldn’t the following also 
have
sensitive topology information:

-- /isis/local-rib

Although not as detailed as the Link State Database, a case could also be made 
for the local RIB. I'll add it to the sensitive operational data. 

-- /isis/hostnames

These is basically a mapping of hostnames to ISO System IDs. The ISO System ID 
is really only used by IS-IS (native CLNS is a thing of the past). I really 
don't see this as being all that useful to an attacker. 

Furthermore, shouldn’t the log files also be protected as the errors or 
status
posted there could also leak topology information: -- /isis/spf-log -- 
/isis/lsp-log

This doesn't include the contents of the LSP - only the LSP ID that caused the 
SPF. I don't see how this would that sensitive - other than that someone 
accessing the SPF and LSP logs could determine that the IS-IS Routing domain is 
volatile. 

Thanks,
Acee







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

Re: [Lsr] Barry Leiba's No Objection on draft-ietf-isis-yang-isis-cfg-37: (with COMMENT)

[Acee Lindem (acee)]

Hi Alvaro, Co-authors, et al,
I went ahead and changed to “should” for the YANG deviations as well as fixing 
a couple typos and changing the draft short name from “isis-cfg” to 
“isis-yang”. The -40 version is posted.
Thanks,
Acee

From: Acee Lindem 
Date: Friday, September 27, 2019 at 8:30 AM
To: Alvaro Retana , Barry Leiba 

Cc: "draft-ietf-isis-yang-isis-...@ietf.org" 
, "lsr-cha...@ietf.org" 
, "lsr@ietf.org" , Yingzhen Qu 
, The IESG 
Subject: Re: Barry Leiba's No Objection on draft-ietf-isis-yang-isis-cfg-37: 
(with COMMENT)
Resent-From: 
Resent-To: , Derek Yeung , Acee 
Lindem , Jeffrey Zhang , Ladislav Lhotka 

Resent-Date: Friday, September 27, 2019 at 8:30 AM

Hi Alvaro,

From: Alvaro Retana 
Date: Thursday, September 26, 2019 at 7:18 PM
To: Barry Leiba , Acee Lindem 
Cc: "draft-ietf-isis-yang-isis-...@ietf.org" 
, "lsr-cha...@ietf.org" 
, "lsr@ietf.org" , Yingzhen Qu 
, The IESG 
Subject: Re: Barry Leiba's No Objection on draft-ietf-isis-yang-isis-cfg-37: 
(with COMMENT)
Resent-From: 
Resent-To: , Derek Yeung , Acee 
Lindem , Jeffrey Zhang , Ladislav Lhotka 

Resent-Date: Thursday, September 26, 2019 at 7:18 PM

On September 26, 2019 at 1:37:47 AM, Barry Leiba via Datatracker 
(nore...@ietf.org) wrote:

Acee:

Hi!

— Section 2.3 —
In the last two paragraphs of the section, one uses “should” advertise and the
other uses “SHOULD” advertise. They should either both be BCP 14 key words, or
both not.

In this case, instead of the change to “SHOULD” (which you made in -38), we 
need to go the other way: s/SHOULD/should

This is from my AD review:

- - - -
...
506   If an implementation does not support per level configuration for a
507   parameter modeled with per level configuration, the implementation
508   SHOULD advertise a deviation to announce the non-support of the
509   level-1 and level-2 containers.

511   Finally, if an implementation supports per level configuration but
512   does not support the level-1-2 configuration, it SHOULD also
513   advertise a deviation.

[major] "SHOULD advertise a deviation"  According to rfc7950: "Deviations MUST 
never be part of a published standard"; I realize that this document doesn't 
include one, but it Normatively recommends their use.  s/SHOULD/should
- - - -

I missed in -36 the fact that only the first SHOULD was changed.

You’d think I would have remembered that. I will make both “should” I the -40 
revision. -39 simply updated Stephane’s contact info to avoid bounces during 
IESG review.

Thanks,
Acee




Thanks!

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

Re: [Lsr] LSR Working Group Adoption Call for "Hierarchical IS-IS" - draft-li-lsr-isis-hierarchical-isis-01

[Acee Lindem (acee)]

Authors,
The LSR Working Group Adoption Call has ended and there is sufficient support 
and interest in working on this draft here in LSR.
Please republish the draft as draft-ietf-lsr-isis-extended-hierarchy-00.txt as 
we agreed during the discussion initiated by Robert Raszuk during the adoption 
call. I will update the draft meta-data to assure there is traceability to the 
current draft.
Thanks,
Acee

From: Lsr  on behalf of Acee Lindem 
Date: Monday, August 12, 2019 at 5:58 PM
To: "lsr@ietf.org" 
Subject: [Lsr] LSR Working Group Adoption Call for "Hierarchical IS-IS" - 
draft-li-lsr-isis-hierarchical-isis-01

This begins a two week LSR Working Group Adoption Poll for the "Hierarchical 
IS-IS" - draft-li-lsr-isis-hierarchical-isis-01. The poll will end at 12:00 AM 
UTC on August 27th, 2019. 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] Working Group Last Call for "Signaling Entropy Label Capability and Entropy Readable Label-stack Depth Using OSPF" - draft-ietf-ospf-mpls-elc-08

[Acee Lindem (acee)]

The Working Group last call has completed and we have received IPR responses 
from all the authors. We have some comments from the Routing Directorate review 
on the corresponding IS-IS draft. I will hold off requesting publication in 
case the comments are also applicable to this version. Thanks,
Acee



From: Acee Lindem 
Date: Friday, August 30, 2019 at 3:42 PM
To: "lsr@ietf.org" 
Cc: "lsr-...@ietf.org" , "draft-ietf-ospf-mpls-...@ietf.org" 
, "m...@ietf.org" 
Subject: Working Group Last Call for "Signaling Entropy Label Capability and 
Entropy Readable Label-stack Depth Using OSPF" - draft-ietf-ospf-mpls-elc-08

We’ve gone through a number of iterations with these ELC drafts and I believe 
they are ready and meets all the use case requirements. Note that “Entropy 
Label for Spring tunnels” – draft-ietf-mpls-spring-entropy-label-12 is on the 
RFC editor’s queue.
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 Sept 14th, 2014.
Thanks,
Acee
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] [mpls] Working Group Last Call for "Signaling Entropy Label Capability and Entropy Readable Label-stack Depth Using ISIS" - draft-ietf-isis-mpls-elc-07

[Acee Lindem (acee)]

The Working Group last call has completed and we have received IPR responses 
from all the authors. We have some comments from the Routing Directorate 
review. I will request publication of the version addressing these comments.
Thanks,
Acee

From: mpls  on behalf of Acee Lindem 
Date: Friday, August 30, 2019 at 3:45 PM
To: "lsr@ietf.org" 
Cc: "m...@ietf.org" , "lsr-...@ietf.org" , 
"draft-ietf-isis-mpls-...@ietf.org" 
Subject: [mpls] Working Group Last Call for "Signaling Entropy Label Capability 
and Entropy Readable Label-stack Depth Using ISIS" - draft-ietf-isis-mpls-elc-07

We’ve gone through a number of iterations with these ELC drafts and I believe 
they are ready and meets all the use case requirements. Note that “Entropy 
Label for Spring tunnels” – draft-ietf-mpls-spring-entropy-label-12 is on the 
RFC editor’s queue.
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 Sept 14th, 2014. 
Also, review comments are certainly welcome.
Thanks,
Acee
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] IPR Poll for "Signaling Entropy Label Capability and Entropy Readable Label Depth Using IS-IS" - draft-ietf-isis-mpls-elc-07

[Acee Lindem (acee)]

Thanks – we should be all set to request publication of the next version of 
these drafts (which will include the Routing Directorate review comments)
Acee.

From: "Clarence Filsfils (cfilsfil)" 
Date: Friday, September 27, 2019 at 11:43 AM
To: Acee Lindem , "Xiaohu (Tiger) Xu" 

Cc: "lsr@ietf.org" , "draft-ietf-isis-mpls-...@ietf.org" 

Subject: RE: [Lsr] IPR Poll for "Signaling Entropy Label Capability and Entropy 
Readable Label Depth Using IS-IS" - draft-ietf-isis-mpls-elc-07

Acee,

I am not aware of any IPR that applies to this draft.

Cheers,
Clarence

From: Acee Lindem (acee)
Sent: Monday, September 23, 2019 5:39 PM
To: Xiaohu (Tiger) Xu ; Clarence Filsfils 
(cfilsfil) 
Cc: lsr@ietf.org; draft-ietf-isis-mpls-...@ietf.org
Subject: Re: [Lsr] IPR Poll for "Signaling Entropy Label Capability and Entropy 
Readable Label Depth Using IS-IS" - draft-ietf-isis-mpls-elc-07

Clarence and Xiaohu (Tiger)  – I still need responses to the IPR poll…

Tiger – you replied to the poll for the OSPF ELC draft but not the IS-IS ELC 
draft.

Thanks,
Acee


From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of Acee 
Lindem mailto:a...@cisco.com>>
Date: Friday, August 30, 2019 at 3:11 PM
To: 
"draft-ietf-isis-mpls-...@ietf.org<mailto:draft-ietf-isis-mpls-...@ietf.org>" 
mailto:draft-ietf-isis-mpls-...@ietf.org>>
Cc: "lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>
Subject: [Lsr] IPR Poll for "Signaling Entropy Label Capability and Entropy 
Readable Label Depth Using IS-IS" - draft-ietf-isis-mpls-elc-07

Authors,

Are you aware of any IPR that applies to draft-ietf-isis-mpls-elc-07?

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] Barry Leiba's No Objection on draft-ietf-isis-yang-isis-cfg-37: (with COMMENT)

[Acee Lindem (acee)]

Hi Alvaro,

From: Alvaro Retana 
Date: Thursday, September 26, 2019 at 7:18 PM
To: Barry Leiba , Acee Lindem 
Cc: "draft-ietf-isis-yang-isis-...@ietf.org" 
, "lsr-cha...@ietf.org" 
, "lsr@ietf.org" , Yingzhen Qu 
, The IESG 
Subject: Re: Barry Leiba's No Objection on draft-ietf-isis-yang-isis-cfg-37: 
(with COMMENT)
Resent-From: 
Resent-To: , Derek Yeung , Acee 
Lindem , Jeffrey Zhang , Ladislav Lhotka 

Resent-Date: Thursday, September 26, 2019 at 7:18 PM

On September 26, 2019 at 1:37:47 AM, Barry Leiba via Datatracker 
(nore...@ietf.org) wrote:

Acee:

Hi!

— Section 2.3 —
In the last two paragraphs of the section, one uses “should” advertise and the
other uses “SHOULD” advertise. They should either both be BCP 14 key words, or
both not.

In this case, instead of the change to “SHOULD” (which you made in -38), we 
need to go the other way: s/SHOULD/should

This is from my AD review:

- - - -
...
506   If an implementation does not support per level configuration for a
507   parameter modeled with per level configuration, the implementation
508   SHOULD advertise a deviation to announce the non-support of the
509   level-1 and level-2 containers.

511   Finally, if an implementation supports per level configuration but
512   does not support the level-1-2 configuration, it SHOULD also
513   advertise a deviation.

[major] "SHOULD advertise a deviation"  According to rfc7950: "Deviations MUST 
never be part of a published standard"; I realize that this document doesn't 
include one, but it Normatively recommends their use.  s/SHOULD/should
- - - -

I missed in -36 the fact that only the first SHOULD was changed.

You’d think I would have remembered that. I will make both “should” I the -40 
revision. -39 simply updated Stephane’s contact info to avoid bounces during 
IESG review.

Thanks,
Acee




Thanks!

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

Re: [Lsr] Barry Leiba's No Objection on draft-ietf-isis-yang-isis-cfg-37: (with COMMENT)

[Acee Lindem (acee)]

Hi Barry, 
Thanks for your review - I've published the -38 version incorporating all your 
comments and Stewart Bryant's comments in order to avoid duplicates from other 
reviewers. I did take a pass over the document and added some additional 
articles. 
Thanks,
Acee

On 9/26/19, 1:37 AM, "Barry Leiba via Datatracker"  wrote:

Barry Leiba has entered the following ballot position for
draft-ietf-isis-yang-isis-cfg-37: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-isis-yang-isis-cfg/



--
COMMENT:
--

Thanks for the work on this YANG module.  My comments are all editorial, and
there’s no need for a response... please just consider these, as they will 
help
make the document clearer.

Throughout the document, please hyphenate the following as shown here:
per-topology basis
per-interface basis
per-level configuration
per-level value
level-specific parameter
interface-specific parameter
vendor-specific

When you use “like” to mean “such as”, it’s ambiguous: “like” can also
introduce a comparison, so does “fruit, like an apple” mean any fruit (and 
an
apple is an example), or are you talking specifically about fruit that is in
some way similar to an apple?  It’s better to say “such as”, to avoid the
ambiguity.  All instances of “like” in the document should be changed, 
*except*
for “encoded as a MAC address like” on page 35 and “would like to thank” in 
the
Contributors section.

Other, specific comments:

— Section 2.1 —

   The model implements features, thus some of the configuration
   statement becomes optional.

This is an odd sentence that I’m having a hard time understanding.  Do you 
mean
this?:

NEW
   This model includes optional features, for which the corresponding
   configuration statements are optional.
END

   By advertising the feature "admin-control", a device communicates to
   the client that it supports the ability to shutdown a particular IS-
   IS instance.

The verb “shut down” is two words.

— Section 2.2 —

   Some specific parameters can be defined on a per topology basis both
   at global level and at interface level

Apart from adding a hyphen in “per-topology basis”, you need “the” before 
both
“global” and “interface”.  There are many places throughout the document 
where
articles (usually “the”, but sometimes “a” or “an”) are missing.  Someone
familiar with the correct use of articles should take a pass through the
document.

— Section 2.3 —
In the last two paragraphs of the section, one uses “should” advertise and 
the
other uses “SHOULD” advertise.  They should either both be BCP 14 key 
words, or
both not.

— Section 2.6 —

   The goal of this empty
   container is to allow easy augmentation with additional parameters
   like timers for example.

As I noted above, you should use “such as”, rather than “like”, and you 
don’t
*also* need “for example”, because “such as” already has that covered.  So,
“...additional parameters, such as timers.”

— Section 2.8 —

   The "candidate-enable" allows to mark an interface to be used as a
   backup.

You need a subject for the verb after “allows” or “requires”.  It has to 
allow
 to mark an interface, and you can’t omit the .  So 
what
is it?

If there really is no sensible entity to put there, you can use passive 
voice,
‘The "candidate-enable" option allows an interface to be marked for use as a
backup.’

— Section 2.9 —
Throughout the section, “information” is a collective noun; we don’t say
“informations”.

— Section 4 —
The first four notification descriptions start with “raised when”, and the 
rest
start with “This notification is sent when”.  Please make them consistent, 
one
way or the other.

— Section 5 —

   Some IS-IS specific routes attributes are added to route objects

I think this is supposed to say, “Some IS-IS-specific route attributes are
added...” (add another hyphen and take the “s” off “routes”).




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

Re: [Lsr] "Signaling Entropy Label Capability and Entropy Readable Label-stack Depth Using OSPF" - draft-ietf-ospf-mpls-elc-08

[Acee Lindem (acee)]

Clarence – I still need a response to the IPR poll.
Thanks,
Acee

From: Lsr  on behalf of Acee Lindem 
Date: Friday, August 30, 2019 at 3:07 PM
To: "draft-ietf-ospf-mpls-...@ietf.org" 
Cc: "lsr@ietf.org" 
Subject: [Lsr] "Signaling Entropy Label Capability and Entropy Readable 
Label-stack Depth Using OSPF" - draft-ietf-ospf-mpls-elc-08

Authors,

Are you aware of any IPR that applies to draft-ietf-ospf-mpls-elc-08?

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] IPR Poll for "Signaling Entropy Label Capability and Entropy Readable Label Depth Using IS-IS" - draft-ietf-isis-mpls-elc-07

[Acee Lindem (acee)]

Clarence and Xiaohu (Tiger)  – I still need responses to the IPR poll…

Tiger – you replied to the poll for the OSPF ELC draft but not the IS-IS ELC 
draft.

Thanks,
Acee


From: Lsr  on behalf of Acee Lindem 
Date: Friday, August 30, 2019 at 3:11 PM
To: "draft-ietf-isis-mpls-...@ietf.org" 
Cc: "lsr@ietf.org" 
Subject: [Lsr] IPR Poll for "Signaling Entropy Label Capability and Entropy 
Readable Label Depth Using IS-IS" - draft-ietf-isis-mpls-elc-07

Authors,

Are you aware of any IPR that applies to draft-ietf-isis-mpls-elc-07?

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] Rtgdir early review of draft-ietf-isis-mpls-elc-08

[Acee Lindem (acee)]

Dhruv - thanks much for the review. 

Authors - can you address Dhruv's comments? 

Thanks,
Acee

On 9/12/19, 6:06 AM, "Dhruv Dhody via Datatracker"  wrote:

Reviewer: Dhruv Dhody
Review result: Has Issues

Subject: RtgDir Early review: draft-ietf-isis-mpls-elc-08

Hello

I have been selected to do a routing directorate “early” review of this 
draft.
​https://datatracker.ietf.org/doc/draft-ietf-isis-mpls-elc/

The routing directorate will, on request from the working group chair, 
perform
an “early” review of a draft before it is submitted for publication to the
IESG. The early review can be performed at any time during the draft’s 
lifetime
as a working group document. The purpose of the early review depends on the
stage that the document has reached.

As this document is in working group last call, my focus for the review was 
to
determine whether the document is ready to be published. Please consider my
comments along with the other working group last call comments.

For more information about the Routing Directorate, please see
​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Document: draft-ietf-isis-mpls-elc-08
Reviewer: Dhruv Dhody
Review Date: 12-09-2019
Intended Status: Standards Track

Summary: I have some minor concerns about this document that I think should 
be
resolved before it is submitted to the IESG.

The draft is focused and straightforward, the reader needs to be aware of
RFC6790 and draft-ietf-mpls-spring-entropy-label beforehand. I have reviewed
this and the OSPF I-D together and you will find similar comments for both 
I-Ds.

Minor
*
(1) Could you mark that the codepoints mentioned in the draft are early
allocated by IANA? Currently it says the value are desired. I also suggest
following change in Section 7 (IANA Considerations) -

OLD:
   IANA is requested to allocate the E-bit (bit position 3 is desired)
   from the "Bit Values for Prefix Attribute Flags Sub-TLV" registry.

   IANA is requested to allocate a MSD type (the type code of 2 is
   desired) from the "IGP MSD Types" registry for ERLD.
NEW:
   IANA is requested to confirm the early allocation of the E-bit (Bit
   position 3) in the "Bit Values for Prefix Attribute Flags Sub-TLV"
   registry.

   IANA is requested to confirm the early allocation of the ERLD (type
   code of 2) in the "IGP MSD Types" registry.
END

(2) Section 3 talks about ERLD in Node MSD sub-TLV. But what happens if one
receives ERLD in the Link MSD sub-TLV? As per my understanding this is not
allowed, better to add normative text for the case then.

Also we have this text in draft-ietf-mpls-spring-entropy-label -

   In a distributed switching architecture, each linecard may have a
   different capability in terms of ERLD.  For simplicity, an
   implementation MAY use the minimum ERLD of all linecards as the ERLD
   value for the system.

   There may also be a case where a router has a fast switching path
   (handled by an ASIC or network processor) and a slow switching path
   (handled by a CPU) with a different ERLD for each switching path.
   Again, for simplicity's sake, an implementation MAY use the minimum
   ERLD as the ERLD value for the system.

   The drawback of using a single ERLD for a system lower than the
   capability of one or more specific component is that it may increase
   the number of ELI/ELs inserted.  This leads to an increase of the
   label stack size and may have an impact on the capability of the
   ingress node to push this label stack.

If we are deviating from this and opting for the node (marked 'MAY' above) 
as
the only possibility, we need to handle this properly. Maybe check with
chairs/AD on this!

(3) Section 4, can we add some more description on what the 'E' flags 
means, in
the similar style of other flags
[https://tools.ietf.org/html/rfc7794#section-2.1]

(4) Section 8, suggest to also add one sentence for the impact of 
advertising
incorrect ERLD. If there isn't any, that can also be stated.

Nits

(1) Suggested ordering of sections - ..ELC/ERLD/BGP-LS/ACK..  [matching 
between
OSPF/ISIS] (2) Section 2, add [I-D.ietf-mpls-spring-entropy-label] for
terminology reference (3) Section 3, Add reference to
draft-ietf-mpls-spring-entropy-label for the definition and usage of ERLD 
(4)
Section 6,

   The ERLD MSD-type introduced for IS-IS in Section 3 is advertised
   using the Node MSD TLV (TLV 266) of the BGP-LS Node NLRI Attribute as
   defined in section 3 of [I-D.ietf-idr-bgp-ls-segment-routing-ext].

I think you mean draft-ietf-idr-bgp-ls-segment-routing-msd here!

Also, maybe change th

Re: [Lsr] Genart last call review of draft-ietf-isis-yang-isis-cfg-37

[Acee Lindem (acee)]

Thanks Stewart - we will fix this nit in the -38 version. 
Acee

On 9/18/19, 10:14 AM, "Stewart Bryant via Datatracker"  
wrote:

Reviewer: Stewart Bryant
Review result: Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-isis-yang-isis-cfg-??
Reviewer: Stewart Bryant
Review Date: 2019-09-18
IETF LC End Date: 2019-09-23
IESG Telechat date: Not scheduled for a telechat

Summary: A true magnum opus. Well written and from a GENART point of view 
ready
to be published. I have not checked the YANG syntax, and have only checked 
that
the configuration symantics look plausible. I assume that specalist YANG and
Routing reviewers will look at that detail.

Major issues: None

Minor issues: None

Nits/editorial comments:
   This document defines a YANG data model that can be used to configure
   and manage IS-IS protocol on network elements.

SB> s/manage/manage the/



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

[Lsr] FW: I-D Action: draft-ietf-lsr-flex-algo-04.txt

[Acee Lindem (acee)]

Amanda et al,
The IGP Flex Algorithm early allocations were made prior to the addition of 
Prefix Metric as defined in sections 16.3.2. 16.4.2. and 16.4.3 repectively for 
IS-IS, OSPFv2, and OSPFv3. Can these code points for prefix metric be added to 
the early allocations?
Thanks,
Acee

On 9/18/19, 6:16 AM, "Lsr on behalf of internet-dra...@ietf.org" 
 wrote:


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   : IGP Flexible Algorithm
Authors : Peter Psenak
  Shraddha Hegde
  Clarence Filsfils
  Ketan Talaulikar
  Arkadiy Gulko
Filename: draft-ietf-lsr-flex-algo-04.txt
Pages   : 31
Date: 2019-09-18

Abstract:
   IGP protocols traditionally compute best paths over the network based
   on the IGP metric assigned to the links.  Many network deployments
   use RSVP-TE based or Segment Routing based Traffic Engineering to
   enforce traffic over a path that is computed using different metrics
   or constraints than the shortest IGP path.  This document proposes a
   solution that allows IGPs themselves to compute constraint based
   paths over the network.  This document also specifies a way of using
   Segment Routing (SR) Prefix-SIDs and SRv6 locators to steer packets
   along the constraint-based paths.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-lsr-flex-algo-04
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-flex-algo-04


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] Rtgdir early review of draft-ietf-isis-mpls-elc-08

[Acee Lindem (acee)]

Thanks Dhruv for the review... 

Peter and other authors, 
Please include Dhruv's comments or respond as to why they are being omitted. 

Thanks,
Acee


On 9/12/19, 6:06 AM, "Dhruv Dhody via Datatracker"  wrote:

Reviewer: Dhruv Dhody
Review result: Has Issues

Subject: RtgDir Early review: draft-ietf-isis-mpls-elc-08

Hello

I have been selected to do a routing directorate “early” review of this 
draft.
​https://datatracker.ietf.org/doc/draft-ietf-isis-mpls-elc/

The routing directorate will, on request from the working group chair, 
perform
an “early” review of a draft before it is submitted for publication to the
IESG. The early review can be performed at any time during the draft’s 
lifetime
as a working group document. The purpose of the early review depends on the
stage that the document has reached.

As this document is in working group last call, my focus for the review was 
to
determine whether the document is ready to be published. Please consider my
comments along with the other working group last call comments.

For more information about the Routing Directorate, please see
​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Document: draft-ietf-isis-mpls-elc-08
Reviewer: Dhruv Dhody
Review Date: 12-09-2019
Intended Status: Standards Track

Summary: I have some minor concerns about this document that I think should 
be
resolved before it is submitted to the IESG.

The draft is focused and straightforward, the reader needs to be aware of
RFC6790 and draft-ietf-mpls-spring-entropy-label beforehand. I have reviewed
this and the OSPF I-D together and you will find similar comments for both 
I-Ds.

Minor
*
(1) Could you mark that the codepoints mentioned in the draft are early
allocated by IANA? Currently it says the value are desired. I also suggest
following change in Section 7 (IANA Considerations) -

OLD:
   IANA is requested to allocate the E-bit (bit position 3 is desired)
   from the "Bit Values for Prefix Attribute Flags Sub-TLV" registry.

   IANA is requested to allocate a MSD type (the type code of 2 is
   desired) from the "IGP MSD Types" registry for ERLD.
NEW:
   IANA is requested to confirm the early allocation of the E-bit (Bit
   position 3) in the "Bit Values for Prefix Attribute Flags Sub-TLV"
   registry.

   IANA is requested to confirm the early allocation of the ERLD (type
   code of 2) in the "IGP MSD Types" registry.
END

(2) Section 3 talks about ERLD in Node MSD sub-TLV. But what happens if one
receives ERLD in the Link MSD sub-TLV? As per my understanding this is not
allowed, better to add normative text for the case then.

Also we have this text in draft-ietf-mpls-spring-entropy-label -

   In a distributed switching architecture, each linecard may have a
   different capability in terms of ERLD.  For simplicity, an
   implementation MAY use the minimum ERLD of all linecards as the ERLD
   value for the system.

   There may also be a case where a router has a fast switching path
   (handled by an ASIC or network processor) and a slow switching path
   (handled by a CPU) with a different ERLD for each switching path.
   Again, for simplicity's sake, an implementation MAY use the minimum
   ERLD as the ERLD value for the system.

   The drawback of using a single ERLD for a system lower than the
   capability of one or more specific component is that it may increase
   the number of ELI/ELs inserted.  This leads to an increase of the
   label stack size and may have an impact on the capability of the
   ingress node to push this label stack.

If we are deviating from this and opting for the node (marked 'MAY' above) 
as
the only possibility, we need to handle this properly. Maybe check with
chairs/AD on this!

(3) Section 4, can we add some more description on what the 'E' flags 
means, in
the similar style of other flags
[https://tools.ietf.org/html/rfc7794#section-2.1]

(4) Section 8, suggest to also add one sentence for the impact of 
advertising
incorrect ERLD. If there isn't any, that can also be stated.

Nits

(1) Suggested ordering of sections - ..ELC/ERLD/BGP-LS/ACK..  [matching 
between
OSPF/ISIS] (2) Section 2, add [I-D.ietf-mpls-spring-entropy-label] for
terminology reference (3) Section 3, Add reference to
draft-ietf-mpls-spring-entropy-label for the definition and usage of ERLD 
(4)
Section 6,

   The ERLD MSD-type introduced for IS-IS in Section 3 is advertised
   using the Node MSD TLV (TLV 266) of the BGP-LS Node NLRI Attribute as
   defined in section 3 of [I-D.ietf-idr-bgp-ls-segment-routing-ext].

I think you mean draft-ietf-idr-bgp-ls-s

Re: [Lsr] Rtgdir early review of draft-ietf-ospf-mpls-elc-09

[Acee Lindem (acee)]

Thanks Dhruv for the review... 

Peter and other authors, 
Please include Dhruv's comments or respond as to why they are being omitted. 

Thanks,
Acee

On 9/12/19, 6:12 AM, "Dhruv Dhody via Datatracker"  wrote:

Reviewer: Dhruv Dhody
Review result: Has Issues

Subject: RtgDir Early review: draft-ietf-ospf-mpls-elc-09

Hello

I have been selected to do a routing directorate “early” review of this 
draft.
​https://datatracker.ietf.org/doc/draft-ietf-ospf-mpls-elc/

The routing directorate will, on request from the working group chair, 
perform
an “early” review of a draft before it is submitted for publication to the
IESG. The early review can be performed at any time during the draft’s 
lifetime
as a working group document. The purpose of the early review depends on the
stage that the document has reached.

As this document is in working group last call, my focus for the review was 
to
determine whether the document is ready to be published. Please consider my
comments along with the other working group last call comments.

For more information about the Routing Directorate, please see
​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Document: draft-ietf-ospf-mpls-elc-09
Reviewer: Dhruv Dhody
Review Date: 12-09-2019
Intended Status: Standards Track

Summary: I have some minor concerns about this document that I think should 
be
resolved before it is submitted to the IESG.

The draft is focused and straightforward, the reader needs to be aware of
RFC6790 and draft-ietf-mpls-spring-entropy-label beforehand. I have reviewed
this and the IS-IS I-D together and you will find similar comments for both
I-Ds.

Minor
*

(1) Please use updated requirement language text as per RFC 8174, as you do
have a mix of upper-case and lower-case terms in your I-D.

  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
  NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
  "MAY", and "OPTIONAL" in this document are to be interpreted as
  described in BCP 14 [RFC2119] [RFC8174] when, and only when, they
  appear in all capitals, as shown here.

(2) Could you mark that the codepoints mentioned in the draft are early
allocated by IANA? This would make it clear that you are not squatting on 
them.
I also suggest following change in Section 7 (IANA Considerations) -

OLD:
   This document requests IANA to allocate one flag from the OSPFv2
   Extended Prefix TLV Flags registry:

  0x20 - E-Flag (ELC Flag)

   This document requests IANA to allocate one flag from the OSPFv3
   Prefix Options registry:

  0x04 - E-Flag (ELC Flag)
NEW:
   IANA is requested to confirm the early allocation of the following
   code point in the OSPFv2 Extended Prefix TLV Flags registry:

  0x20 - E-Flag (ELC Flag)

   IANA is requested to confirm the early allocation of the following
   code point in the  the OSPFv3 Prefix Options registry:

  0x04 - E-Flag (ELC Flag)
END

(3) Section 4, I think a reference to RFC 8476 is needed as well to state 
the
ERLD is advertised as part of Node MSD advertisement as defined in 
[RFC8476].
As mentioned in my review of the IS-IS I-D, what happens if one receives 
ERLD
in the Link MSD advertisement? As per my understanding this is not allowed,
better to add normative text for the case then.

(4) Section 8, suggest to also add one sentence for the impact of 
advertising
incorrect ERLD. If there isn't any, that can also be stated.

Nits

(1) Suggested ordering of sections - ..ELC/ERLD/BGP-LS/ACK..  [matching 
between
OSPF/ISIS]

(2) Section 2, add [I-D.ietf-mpls-spring-entropy-label] for terminology
reference

(3) Section 3, Add reference to draft-ietf-mpls-spring-entropy-label for the
definition and usage of ERLD

(4) Section 6,

   The ERLD MSD-type introduced for OSPF in Section 4 is advertised
   using the Node MSD TLV (TLV 266) of the BGP-LS Node NLRI Attribute as
   defined in section 3 of [I-D.ietf-idr-bgp-ls-segment-routing-ext].

I think you mean draft-ietf-idr-bgp-ls-segment-routing-msd here!

Also, maybe change the title "BGP-LS Extension" as there is no 'extension'
required, ELC/ERLD is BGP-LS would be automatically supported.

(5) Expand MSD on first use.

Thanks!
Dhruv



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

Re: [Lsr] Working Group Last Call for "Signaling Entropy Label Capability and Entropy Readable Label-stack Depth Using OSPF" - draft-ietf-ospf-mpls-elc-08

[Acee Lindem (acee)]

Hi Uma,

From: Uma Chunduri 
Date: Tuesday, September 10, 2019 at 2:43 PM
To: Acee Lindem , "lsr@ietf.org" 
Cc: "m...@ietf.org" , "lsr-...@ietf.org" , 
"draft-ietf-ospf-mpls-...@ietf.org" 
Subject: RE: Working Group Last Call for "Signaling Entropy Label Capability 
and Entropy Readable Label-stack Depth Using OSPF" - draft-ietf-ospf-mpls-elc-08

Support.


One question to authors:

On E bit in section 4:  The motivation seems to extend this in Prefix 
attributes is for inter-area consideration and advertised per every local host 
prefix (link) .
   Is there any specific reason why link 
MSD is not considered instead ? ( https://tools.ietf.org/html/rfc8491)

Because the intra-area link topology is not exposed across areas or to other 
protocols.

Thanks,
Acee


--
Uma C.


From: mpls  On Behalf Of Acee Lindem (acee)
Sent: Friday, August 30, 2019 12:42 PM
To: lsr@ietf.org
Cc: m...@ietf.org; lsr-...@ietf.org; draft-ietf-ospf-mpls-...@ietf.org
Subject: [mpls] Working Group Last Call for "Signaling Entropy Label Capability 
and Entropy Readable Label-stack Depth Using OSPF" - draft-ietf-ospf-mpls-elc-08

We’ve gone through a number of iterations with these ELC drafts and I believe 
they are ready and meets all the use case requirements. Note that “Entropy 
Label for Spring tunnels” – draft-ietf-mpls-spring-entropy-label-12 is on the 
RFC editor’s queue.
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 Sept 14th, 2014.
Thanks,
Acee
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] AD Review of draft-ietf-isis-yang-isis-cfg-35

[Acee Lindem (acee)]

Hi Alvaro,
I see you started the WG last call. I’ll update this tonight - although I 
believe this isn’t the only down-ref.
Thanks,
Acee

From: Alvaro Retana 
Date: Monday, September 9, 2019 at 4:45 PM
To: Acee Lindem , "draft-ietf-isis-yang-isis-...@ietf.org" 
, Stephane Litkowski 

Cc: Yingzhen Qu , "lsr@ietf.org" , 
"lsr-cha...@ietf.org" 
Subject: Re: AD Review of draft-ietf-isis-yang-isis-cfg-35
Resent-From: 
Resent-To: Stephane Litkowski , Derek Yeung 
, Acee Lindem , Jeffrey Zhang 
, Ladislav Lhotka 
Resent-Date: Monday, September 9, 2019 at 4:45 PM

Hi!

I just found that rfc2966 is in the DownRef registry already, so I’m starting 
the IETF LC now.

We will still need to update the reference, but that can be done with any other 
LC comments.

Thanks!

Alvaro.


On September 9, 2019 at 4:43:30 PM, Alvaro Retana 
(aretana.i...@gmail.com<mailto:aretana.i...@gmail.com>) wrote:
On September 5, 2019 at 3:09:44 PM, Acee Lindem (acee) 
(a...@cisco.com<mailto:a...@cisco.com>) wrote:

Hi!

Stephane and I have some more updates in -36 version.

I’m ready to start the IETF LC, but there’s one small thing I need you to fix 
before:  rfc2966 was Obsoleted by rfc5302; please update the reference.

It’s important that we make this update before the LC because rfc2966 was 
Informational, so it would require a DownRef, but rfc5302 is in the Standards 
Track.

Thanks!

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