Re: [Lsr] Early Allocation for IS-IS TTZ

2020-11-20 Thread Les Ginsberg (ginsberg)
FYI –

This has been approved by the DEs and IANA has updated the registry.

   Les



From: Lsr  On Behalf Of Les Ginsberg (ginsberg)
Sent: Wednesday, November 18, 2020 1:45 PM
To: Acee Lindem (acee) ; Huaimo Chen 
; Christian Hopps ; Hannes 
Gredler 
Cc: lsr@ietf.org; Alvaro Retana 
Subject: Re: [Lsr] Early Allocation for IS-IS TTZ

Request noted.

Chris/Hannes/myself will discuss and get back to you.

   Les

From: Acee Lindem (acee) mailto:a...@cisco.com>>
Sent: Wednesday, November 18, 2020 12:21 PM
To: Huaimo Chen mailto:huaimo.c...@futurewei.com>>; 
Christian Hopps mailto:cho...@chopps.org>>; Hannes Gredler 
mailto:han...@gredler.at>>; Les Ginsberg (ginsberg) 
mailto:ginsb...@cisco.com>>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>; Alvaro Retana 
mailto:aretana.i...@gmail.com>>
Subject: Re: Early Allocation for IS-IS TTZ

+LSR list and Alvaro for information.

I have no problems with this allocation. This needs to go to IS-IS designated 
experts (Chris, Les, Hannes).

Thanks,
Acee

From: Huaimo Chen mailto:huaimo.c...@futurewei.com>>
Date: Wednesday, November 18, 2020 at 2:34 PM
To: Acee Lindem mailto:a...@cisco.com>>, Christian Hopps 
mailto:cho...@chopps.org>>
Subject: Early Allocation for IS-IS TTZ

Hi Acee and Chris,

We would like to request an early allocation of "IS-IS TLV Codepoints" for 
IS-IS TTZ  https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-ttz/

 28 (suggested) - IS-IS Zone ID TLV

Thank you very much for your consideration.

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


Re: [Lsr] Early Allocation for IS-IS TTZ

2020-11-18 Thread Les Ginsberg (ginsberg)
Request noted.

Chris/Hannes/myself will discuss and get back to you.

   Les

From: Acee Lindem (acee) 
Sent: Wednesday, November 18, 2020 12:21 PM
To: Huaimo Chen ; Christian Hopps 
; Hannes Gredler ; Les Ginsberg 
(ginsberg) 
Cc: lsr@ietf.org; Alvaro Retana 
Subject: Re: Early Allocation for IS-IS TTZ

+LSR list and Alvaro for information.

I have no problems with this allocation. This needs to go to IS-IS designated 
experts (Chris, Les, Hannes).

Thanks,
Acee

From: Huaimo Chen mailto:huaimo.c...@futurewei.com>>
Date: Wednesday, November 18, 2020 at 2:34 PM
To: Acee Lindem mailto:a...@cisco.com>>, Christian Hopps 
mailto:cho...@chopps.org>>
Subject: Early Allocation for IS-IS TTZ

Hi Acee and Chris,

We would like to request an early allocation of "IS-IS TLV Codepoints" for 
IS-IS TTZ  https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-ttz/

 28 (suggested) - IS-IS Zone ID TLV

Thank you very much for your consideration.

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


Re: [Lsr] [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 11/16/2020)

2020-11-14 Thread Les Ginsberg (ginsberg)
Zhibo –

It is good of you to “keep me honest” as regards my past comments.

In reviewing the relevant material, the best I can say as regards my comments 
from 2 years ago is that they were made with insufficient diligence. Apologies 
for any resulting confusion.

https://www.rfc-editor.org/rfc/rfc7176.html#section-2.4 clearly indicates that 
the advertised value is dependent on the results of MTU-probe testing as 
specified in https://www.rfc-editor.org/rfc/rfc6325#section-4.3.2 .

Particularly relevant is the statement:

“o  MTU: This field is set to the largest successfully tested MTU size
  for this link or zero if it has not been tested, as specified in
  Section 4.3.2 of [RFC6325].”

So, as currently defined, IS-IS is not allowed to advertise a non-zero MTU 
value unless MTU-probes/acks have been exchanged.

https://www.rfc-editor.org/rfc/rfc7177#section-5 further clarifies that:

“The purpose of MTU testing is to ensure that the links used in the
   campus topology can pass TRILL IS-IS packets, particularly LSP PDUs,
   at the TRILL campus MTU.”

So the stated purpose of the TRILL definitions is NOT to provide assurances of 
data packet MTU, but more specifically to ensure that the IS-IS protocol can 
function correctly.

Could the MTU sub-TLV be repurposed to meet the requirements being discussed in 
the context of draft-zhu-idr-bgp-ls-path-mtu? Yes – I think that is possible - 
but it requires further  work.

draft-hu-lsr-isis-path-mtu was published over two years ago to define IS-IS 
extensions to advertise MTU. As you have noted, you received feedback from both 
Acee and myself which suggested that the TRILL defined MTU sub-TLV might be a 
better choice than the node property you had proposed. It seems based on that 
feedback you abandoned draft-hu-lsr-isis-path-mtu and focused only on 
draft-zhu-idr-bgp-ls-path-mtu. But as others have also noted, there is a gap 
regarding IGP support. OSPF has no ability to support MTU advertisement 
currently and – as this thread explains – even in IS-IS there is work to be 
done.

I would like to restate that I am – like others – supportive of this work – but 
I think WG adoption at this stage (in ANY WG) is premature.

   Les


From: Huzhibo 
Sent: Friday, November 13, 2020 7:20 PM
To: Les Ginsberg (ginsberg) ; Ketan Talaulikar (ketant) 
; Susan Hares ; 'Jeff Tantsura' 
; Stephane Litkowski (slitkows) ; 
i...@ietf.org; Acee Lindem (acee) 
Cc: lsr@ietf.org
Subject: 答复: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 
11/16/2020)

Hi Les, Acee:

Actually we have already discussed about this and reached agreements about two 
years ago. You may have forgotten. Please find the archives below.

https://mailarchive.ietf.org/arch/msg/lsr/C2bhd2ff2UJf4e_Gr-7j2W0g-SU/

I have followed your advice: "there already is a per link MTU sub-TLV defined 
by RFC 7176 ... in which case the existing sub-TLV is a perfect fit ...  IS-IS 
already has what is needed and therefore does not need any additional protocol 
extension". So we let our draft on ISIS extensions for MTU expired, i.e. 
draft-hu-lsr-isis-path-mtu. To be honest, I am a bit surprised when I saw your 
comments.

In this draft we focused on the extensions of BGP_LS for MTU only, which does 
not have to be feed by IGP LSDB. This draft has been discussed and revised a 
few rounds, based on the feedbacks both on ietf meetings and mail list, this 
document has good maturity to move forward.

Thanks
Zhibo


发件人: Idr [mailto:idr-boun...@ietf.org] 代表 Les Ginsberg (ginsberg)
发送时间: 2020年11月14日 7:58
收件人: Ketan Talaulikar (ketant) 
mailto:ketant=40cisco@dmarc.ietf.org>>; 
Susan Hares mailto:sha...@ndzh.com>>; 'Jeff Tantsura' 
mailto:jefftant.i...@gmail.com>>; 'Stephane Litkowski 
(slitkows)' 
mailto:slitkows=40cisco@dmarc.ietf.org>>;
 i...@ietf.org<mailto:i...@ietf.org>; 'Acee Lindem (acee)' 
mailto:acee=40cisco@dmarc.ietf.org>>
抄送: lsr@ietf.org<mailto:lsr@ietf.org>
主题: Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 
11/16/2020)

The points which Ketan has made regarding the use of MTU advertisements defined 
in RFC 7176 are very valid. Indeed, the contents of the sub-TLV defined in 
https://www.rfc-editor.org/rfc/rfc7176.html#section-2.4 depend upon the TRILL 
specific MTU-probe/MTU-ack procedures defined in 
https://www.rfc-editor.org/rfc/rfc6325#section-4.4.3. These procedures are not 
currently applicable to non-TRILL environments.

So, there are no existing IGP advertisements defined which can support the 
goals of this draft.

As Ketan has also indicated, there is no discussion in the draft of how a BGP 
only network (for example) could provide the information of interest.

From my perspective, WG adoption of this draft in ANY WG is premature.
This might be a useful functionality to have – but at the moment we simply have 
an idea with no definition of how to implement/deploy it.

So I therefore 

Re: [Lsr] [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 11/16/2020)

2020-11-13 Thread Les Ginsberg (ginsberg)
The points which Ketan has made regarding the use of MTU advertisements defined 
in RFC 7176 are very valid. Indeed, the contents of the sub-TLV defined in 
https://www.rfc-editor.org/rfc/rfc7176.html#section-2.4 depend upon the TRILL 
specific MTU-probe/MTU-ack procedures defined in 
https://www.rfc-editor.org/rfc/rfc6325#section-4.4.3. These procedures are not 
currently applicable to non-TRILL environments.

So, there are no existing IGP advertisements defined which can support the 
goals of this draft.

As Ketan has also indicated, there is no discussion in the draft of how a BGP 
only network (for example) could provide the information of interest.

From my perspective, WG adoption of this draft in ANY WG is premature.
This might be a useful functionality to have – but at the moment we simply have 
an idea with no definition of how to implement/deploy it.

So I therefore oppose WG adoption of this draft by IDR.

Continuing the discussion is certainly useful – and I would encourage the 
current authors to investigate and propose relevant mechanisms in all the 
protocols of interest in some future version of the draft.
At that point we could then have a far more meaningful WG adoption call.

   Les


From: Idr  On Behalf Of Ketan Talaulikar (ketant)
Sent: Friday, November 13, 2020 1:35 AM
To: Susan Hares ; 'Jeff Tantsura' ; 
'Stephane Litkowski (slitkows)' ; 
i...@ietf.org; 'Acee Lindem (acee)' 
Cc: lsr@ietf.org
Subject: Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 
11/16/2020)

Hi Authors,

I believe this work is useful and should be taken up. It has value in providing 
the link MTU as part of the topology information via BGP-LS. However, as 
pointed out by others on this thread, the draft should remain scoped to just 
that – i.e. providing link MTU information. The discussion related to Path MTU 
and applicability to SR networks are best left outside the scope of this 
standards track draft.

Hi Sue,

I would support the points made by Acee for not taking up this draft in IDR WG 
and instead doing this in LSR.

Besides the missing coverage for OSPFv2/v3, there are also issues with how this 
would work with ISIS. The reference to the ISIS Trill specification points to 
this TLV https://tools.ietf.org/html/rfc7176#section-2.4 – if you see, there is 
more here than just the MTU value. What is more critical is the ISIS procedures 
(in non-Trill deployments) on how this value is determined. Please do not mix 
the following :

The MTU sub-TLV is used to optionally announce the MTU of a link as
   specified in [RFC6325], Section 
4.2.4.4.

Are the authors trying to specify that these Trill procedures for testing MTU 
need to be adopted for regular ISIS deployments.

My take is that while the ISIS TLV defined for Trill may be re-used in normal 
ISIS deployments, its usage and procedures need to be specified. Copying the 
LSR WG so that I may be corrected if I am wrong here.

Coming to the point of BGP-only networks, the draft has zero text related to 
that scenario. Moreover, the procedures for BGP-LS advertisements in BGP only 
fabric need to be specified as a base. The 
https://datatracker.ietf.org/doc/draft-ketant-idr-bgp-ls-bgp-only-fabric/ was 
my attempt to specify those procedures and it would be great if the IDR WG 
could review and provide feedback to this document and consider for adoption so 
we can cover the BGP-only networks.

I would also like to offer support/help to the authors in adding the necessary 
OSPFv2/v3 support for the same in an LSR draft where we could tackle both the 
IGPs and BGP-LS encoding and procedures together.

Thanks,
Ketan

From: Idr mailto:idr-boun...@ietf.org>> On Behalf Of 
Susan Hares
Sent: 13 November 2020 00:20
To: 'Jeff Tantsura' mailto:jefftant.i...@gmail.com>>; 
'Stephane Litkowski (slitkows)' 
mailto:slitkows=40cisco@dmarc.ietf.org>>;
 i...@ietf.org; 'Acee Lindem (acee)' 
mailto:acee=40cisco@dmarc.ietf.org>>
Subject: Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 
11/16/2020)

Jeff and Authors of draft-zhu-idr-bgp-ls-path-mtu:

I do believe the authors agreed to renaming the draft.

Does the name:   draft-xxx-idr-bgp-ls-link-mtu work for
the authors and interested IDR participants.

As the end of 12 days of the 14 day WG LC, this draft appears
to have general consensus from the WG as a useful draft.

I plan to allow 2 more days of comment, but at this point
it appears the WG wishes to adopt this draft.

Here’s my understanding of the best way forward:

If LSR adopts a version of the draft, IDR will allow the
LSR WG to be the main source as long as cross-working
review occurs so the BGP-only function can be reviewed.

Please continue to comment on the draft and
the planned progression.

Cheers,  Sue

From: Jeff Tantsura [mailto:jefftant.i...@gmail.com]
Sent: Thursday, November 12, 2020 12:53 PM
To: Susan Hares; Stephane Litkowski 

Re: [Lsr] WG Adoption Call for "ISIS Extensions in Support of Inter-AS MPLS and GMPLS TE" - draft-chen-lsr-isis-rfc5316bis-02

2020-10-23 Thread Les Ginsberg (ginsberg)
This simple extension to RFC 5316 is analogous to the extension to RFC 4971 
defined in RFC 7981. As Acee indicated, this is needed to support operation in 
IPv6 only networks.

I support WG adoption as a co-author.
I would appreciate WG support so we can complete this necessary extension.

   Les


From: Lsr  On Behalf Of Acee Lindem (acee)
Sent: Friday, October 23, 2020 7:43 AM
To: lsr@ietf.org
Subject: [Lsr] WG Adoption Call for "ISIS Extensions in Support of Inter-AS 
MPLS and GMPLS TE" - draft-chen-lsr-isis-rfc5316bis-02

This is simple BIS update to RFC 5316 is required to support IS-IS Inter-AS TE 
in IPv6 only networks. The authors have asked for WG adoption.

This begins a two week LSR Working Group Adoption Poll for “ISIS Extensions in 
Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering” - 
draft-chen-lsr-isis-rfc5316bis-02. The poll will end at 12:00 AM UTC on 
November 7th, 2020. Please indicate your support of objection on this list 
prior to the end of the adoption poll.

Thanks,
Acee

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


Re: [Lsr] IPR Call for "ISIS Extensions in Support of Inter-AS MPLS and GMPLS TE" - draft-chen-lsr-isis-rfc5316bis-02

2020-10-23 Thread Les Ginsberg (ginsberg)
I am not aware of any relevant undisclosed IPR associated with the bis draft.

   Les


From: Acee Lindem (acee) 
Sent: Friday, October 23, 2020 7:50 AM
To: draft-chen-lsr-isis-rfc5316...@ietf.org
Cc: lsr@ietf.org
Subject: IPR Call for "ISIS Extensions in Support of Inter-AS MPLS and GMPLS 
TE" - draft-chen-lsr-isis-rfc5316bis-02

Hi Mach, Les, Stefano, Xiaodong,

Are you aware of any IPR associated with the subject draft.

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as a document author or contributor please respond
to this email regardless of whether or not you are aware of any
relevant IPR. The response needs to be sent to the LSR WG mailing
list. The document will not advance to the next stage until a
response has been received from each author and contributor.

If you are on the LSR WG email list but are not listed as an author or
contributor, then please explicitly respond only if you are aware of
any IPR that has not yet been disclosed in conformance with IETF rules.

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


Re: [Lsr] Rtg-Dir Last Call review of draft-ietf-lsr-flex-algo

2020-10-20 Thread Les Ginsberg (ginsberg)
Eric –

Always appreciate the time reviewers put in – so apologies if my response came 
off as an overreaction.

As you understood that OSPF addresses backwards compatibility by ignoring 
unknown TLVs I wanted to emphasize that IS-IS has the same policy.

As regards the section on backwards compatibility, Peter has already suggested 
some text that seems to do what you have suggested. I am sure you will let him 
know if it is adequate.

I do understand that the compatibility concerns have to do with networks where 
some nodes support the new functionality and some don’t. But I think the real 
deployment issue is not “compatibility” but that in order for algo specific 
forwarding to work you must have a connected sub-topology of routers that 
support the desired algo. I would not use the term “compatibility” to describe 
that – but if we understand each other then we can leave it at that.

   Les


From: Eric Gray 
Sent: Tuesday, October 20, 2020 6:39 PM
To: Les Ginsberg (ginsberg) ; rtg-...@ietf.org; 
lsr-cha...@ietf.org
Cc: rtg-...@ietf.org; lsr@ietf.org
Subject: RE: Rtg-Dir Last Call review of draft-ietf-lsr-flex-algo

Les,

  Thanks for your helpful feedback on my minor comments.

  I think you may have misunderstood my comments.

  I do not have concerns about backward compatibility with respect 
to the flex-algo ID.

  What I was making a minor comment on was the dismissive approach 
the draft takes with respect to concerns about backward compatibility.

  It simply says that this draft does not introduce any new 
backward compatibility issues – which, going back to when IDs used to say 
pretty much the same thing about Security, is often not quite good enough.

  I feel the draft would make a better RFC if it said just a bit 
more about why the new TLV(s) and Sub-TLVs do not introduce backward 
compatibility issues.  It could even summarize how the extensions in this draft 
are (or are not) impacted by deployment in an environment where not all routers 
are able to participate in any specific flex-algorithm.

  For example, your own statement about why it is not an issue with 
IS-IS would be a useful addition to the section on backward compatibility.

  Maybe you and others disagree that this is useful, and that’s 
fine with me.

  I am happy to take your word for it about configuration, though I 
suspect that you also missed the point I was making about that specific aspect 
of compatibility of newer nodes (that can participate in a flex-algorithm) with 
others (that cannot – likely including existing and deployed routers).

  This point is not very important, so the authors can address it 
any way they want (including doing nothing at all).

  I see these reviews as an opportunity to improve our work, and 
have no other personal investment in my comments.

--
Eric


From: Les Ginsberg (ginsberg) 
mailto:ginsberg=40cisco@dmarc.ietf.org>>
Sent: Friday, October 16, 2020 3:59 PM
To: Eric Gray mailto:eric.g...@ericsson.com>>; 
rtg-...@ietf.org<mailto:rtg-...@ietf.org>; 
lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>
Cc: rtg-...@ietf.org<mailto:rtg-...@ietf.org>; lsr@ietf.org<mailto:lsr@ietf.org>
Subject: RE: Rtg-Dir Last Call review of draft-ietf-lsr-flex-algo
Importance: High

Eric –

I will let the draft authors respond to the bulk of your comments. But in 
regards to your question/comment:

“I assume (but do not actually know) that a similar situation exists for the 
new ISIS FAD Sub-TLV of the existing TLV Type 242 - i.e. - ISIS presumably has 
well defined handling for sub-TLVs (of at least type 242) that are not 
recognized.  If so, than the new Sub-TLV types defined are also not an issue.”

Indeed, base behavior for the IS-IS protocol as defined in ISO 10589 is to 
ignore unrecognized TLVs - and this extends to unrecognized sub-TLVs as well. 
This is key to the ability to introduce the many extensions that have been 
defined by the plethora of IS-IS RFCs over the last 20+ years.
This point is further discussed in the recently published:

https://www.rfc-editor.org/rfc/rfc8918.html#name-handling-of-disallowed-tlvs<https://protect2.fireeye.com/v1/url?k=560d142b-08bccf4b-560d54b0-86e2237f51fb-24dfc414d340a7cc=1=7cda84da-f086-4e37-8611-0a5c60f9a87b=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc8918.html%23name-handling-of-disallowed-tlvs>

So I think your concerns about backwards compatibility are unwarranted. In 
particular the statement:

“[backwards compatibility] apparently relies on configuration of those routers 
that _do_ support the extensions to address this”

Is not correct.

   Les

From: rtg-dir mailto:rtg-dir-boun...@ietf.org>> On 
Behalf Of Eric Gray
Sent: Friday, October 16, 2020 11:49 AM
To: rtg-...@ietf.org<mailto:rtg-...@ietf.org>; 
lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>
Cc: rtg-..

Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

2020-10-19 Thread Les Ginsberg (ginsberg)
Aijun -

I am not going to continue these side discussions with you.

The primary purpose of the protocol extensions are as stated in the draft 
Introduction. This is analogous to the use cases for the equivalent extensions 
for IS-IS already approved in RFC 7794. We need the equivalent in OSPF.

You can show that you are listening to the concerns of WG members by removing 
the Appendices - in which case you have (I believe) broad support for moving 
the draft forward.
You can then write a separate draft to discuss other use cases and allow the WG 
to discuss those other use cases w/o preventing the extensions from being 
approved and deployed for the use cases which have already been demonstrated as 
useful by IS-IS.

If you remove the Appendices I can support the draft.
If you do not remove the Appendices I cannot support the draft.

Please discuss this with your co-authors and come to consensus on your next 
step.

   Les


> -Original Message-
> From: Aijun Wang 
> Sent: Monday, October 19, 2020 12:06 AM
> To: Les Ginsberg (ginsberg) ; 'Christian Hopps'
> 
> Cc: 'John E Drake' ; lsr-cha...@ietf.org; lsr@ietf.org;
> 'Jeff Tantsura' ; draft-ietf-lsr-ospf-prefix-
> origina...@ietf.org; lsr-...@ietf.org
> Subject: RE: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06
> 
> Hi, Les:
> 
> As I stated clearly before, the appendix described in the draft is not the new
> use case. It is the start point of this draft.
> Have you noticed that the introduction part is not the final usage of such
> protocol extension information?
> Certainly, we will not expand all the possible use cases in very detail, but
> putting some of them(some interesting, prominent use cases) in the
> appendix will not hamper the protocol extension itself.
> 
> If the statements/descriptions in the appendix are not correct, we can fix it,
> or remove it finally.  If not, why not let it be for reference to the user of 
> such
> protocol extension?
> For the body part of this draft, we are also welcome comments.
> 
> More replies inline below[WAJ]
> 
> Best Regards
> 
> Aijun Wang
> China Telecom
> 
> -----Original Message-
> From: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] On Behalf Of Les
> Ginsberg (ginsberg)
> Sent: Monday, October 19, 2020 2:15 PM
> To: Aijun Wang ; 'Christian Hopps'
> 
> Cc: 'John E Drake' ; lsr-cha...@ietf.org; 'Les Ginsberg
> (ginsberg)' ; lsr@ietf.org; 'Jeff
> Tantsura' ; draft-ietf-lsr-ospf-prefix-
> origina...@ietf.org; lsr-...@ietf.org
> Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06
> 
> Aijun -
> 
> The "use case" for the protocol extensions is clearly stated in the
> Introduction:
> 
> "The primary use case for the extensions proposed in this document is
>to be able to identify the originator of the prefix in the network.
>In cases where multiple prefixes are advertised by a given router, it
>is also useful to be able to associate all these prefixes with a
>single router even when prefixes are advertised outside of the area
>in which they originated.  It also helps to determine when the same
>prefix is being originated by multiple routers across areas."
> 
> This is equivalent to language in RFC 7794 which defines the analogous
> extensions for IS-IS.
> 
> Everything you have in the Appendix is not related to the primary use case -
> and is fact a use case which many of us have objected to.
> [WAJ] Very glad to know the false statements in the appendix.
> 
> You are entitled to write another draft advocating for your new use case if
> you wish, but requiring that the protocol extensions in support of the
> primary use case not go forward without your new use case is - as Chris has
> stated very clearly - holding approval of the protocol extensions hostage to
> your new use case.
> [WAJ] It is not new use case. As I sated before, I am open to this part, but
> should on the conditions that the statements in this part are incorrect.
> 
> I am asking you (yet again) not to do this.
> 
> I cannot support the document moving forward with the content in the
> Appendices included.
> [WAJ] Would like to hear more technical analysis.
> 
>Les
> 
> 
> > -Original Message-
> > From: Lsr  On Behalf Of Aijun Wang
> > Sent: Sunday, October 18, 2020 7:08 PM
> > To: 'Christian Hopps' 
> > Cc: 'John E Drake' ; lsr-cha...@ietf.org; 'Les
> > Ginsberg (ginsberg)' ;
> > lsr@ietf.org; 'Jeff Tantsura' ;
> > draft-ietf-lsr-ospf-prefix- origina...@ietf.org; lsr-...@ietf.org
> > Subject: Re: [Lsr] WG Last Call
> > draft-ietf-lsr-ospf-prefix-originator-06
> >
> > Hi, Chris:
> >
> > I think we have "p

Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

2020-10-19 Thread Les Ginsberg (ginsberg)
Aijun -

The "use case" for the protocol extensions is clearly stated in the 
Introduction:

"The primary use case for the extensions proposed in this document is
   to be able to identify the originator of the prefix in the network.
   In cases where multiple prefixes are advertised by a given router, it
   is also useful to be able to associate all these prefixes with a
   single router even when prefixes are advertised outside of the area
   in which they originated.  It also helps to determine when the same
   prefix is being originated by multiple routers across areas."

This is equivalent to language in RFC 7794 which defines the analogous 
extensions for IS-IS.

Everything you have in the Appendix is not related to the primary use case - 
and is fact a use case which many of us have objected to.

You are entitled to write another draft advocating for your new use case if you 
wish, but requiring that the protocol extensions in support of the primary use 
case not go forward without your new use case is - as Chris has stated very 
clearly - holding approval of the protocol extensions hostage to your new use 
case.

I am asking you (yet again) not to do this.

I cannot support the document moving forward with the content in the Appendices 
included.

   Les


> -Original Message-
> From: Lsr  On Behalf Of Aijun Wang
> Sent: Sunday, October 18, 2020 7:08 PM
> To: 'Christian Hopps' 
> Cc: 'John E Drake' ; lsr-cha...@ietf.org; 'Les Ginsberg
> (ginsberg)' ; lsr@ietf.org; 'Jeff
> Tantsura' ; draft-ietf-lsr-ospf-prefix-
> origina...@ietf.org; lsr-...@ietf.org
> Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06
> 
> Hi, Chris:
> 
> I think we have "put the cart before the horse". For protocol extension draft,
> the origin is the use case.
> And I think we will not expand OSPF protocol, just because it lack something
> as compared with ISIS, right?
> 
> As I stated before, the use case in current appendix is the main motivation of
> this draft, you can see this in main body of the earlier version of this
> draft(from version 0 to version 5).
> The reason that we move this part to the appendix, as that you said, is to let
> person focus on the protocol extension itself.
> 
> Moving this part to appendix is acceptable, but removing it from the draft 
> will
> erase the origin of this document.
> Is it reasonable that one document discusses the "origin"(of the prefix), 
> can't
> keep its origin?
> 
> More replies inline below[WAJ].
> 
> Best Regards
> 
> Aijun Wang
> China Telecom
> 
> 
> -Original Message-
> From: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] On Behalf Of
> Christian Hopps
> Sent: Friday, October 16, 2020 10:47 PM
> To: 王爱俊 
> Cc: John E Drake ; Christian Hopps
> ; lsr-cha...@ietf.org; Les Ginsberg (ginsberg)
> ; lsr@ietf.org; Jeff Tantsura
> ; draft-ietf-lsr-ospf-prefix-origina...@ietf.org; 
> lsr-
> a...@ietf.org
> Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06
> 
> Isn't this just adding an analogous extension that already exists in RFC7794?
> [WAJ] No. RFC7794 is just one example that to illustrate, as the companion
> IGP protocol, OSPF can also accomplish this. And, actually, there are
> differences consideration in this draft for the protocol extension.
> 
> I don't think we need to do a lot of convincing at this point. I agree with 
> Les, if
> you want to talk about use cases (especially ones that are controversial!)
> then the correct place for that is in a new informative draft.
> [WAJ] we have discussed the use case before and state the discussion
> results at the appendix part. We will not emphasis and expand the use case
> more. If one does not agree the statement of this appendix, we can discuss
> online or offline. We just need to make the statement in appendix is correct.
> 
> Otherwise, especially if the cases are controversial, this can be seen as 
> doing
> an "end-run" to avoid the debate b/c people want the extension, but maybe
> don't agree with your use case.
> [WAJ] One should point out which statement in the appendix is
> controversial, we can correct it. This use case is the origin of this draft, 
> not
> the results.
> 
> Legislators do this sometimes adding things they want personally to popular
> bills, that other people may not want, but since people want the main bill
> they vote for it anyway, in the US it's called "adding pork" or "pork barrel
> politics". :)
> [WAJ] The appendix is not added later, but exist at the first beginning. This 
> is
> the origin of the bills.
> 
> Thanks,
> Chris.
> 
> > On Oct 16, 2020, at 10:37 AM, 王爱俊 
> wrote:
> >
> >

Re: [Lsr] Rtg-Dir Last Call review of draft-ietf-lsr-flex-algo

2020-10-16 Thread Les Ginsberg (ginsberg)
Eric –

I will let the draft authors respond to the bulk of your comments. But in 
regards to your question/comment:

“I assume (but do not actually know) that a similar situation exists for the 
new ISIS FAD Sub-TLV of the existing TLV Type 242 - i.e. - ISIS presumably has 
well defined handling for sub-TLVs (of at least type 242) that are not 
recognized.  If so, than the new Sub-TLV types defined are also not an issue.”

Indeed, base behavior for the IS-IS protocol as defined in ISO 10589 is to 
ignore unrecognized TLVs - and this extends to unrecognized sub-TLVs as well. 
This is key to the ability to introduce the many extensions that have been 
defined by the plethora of IS-IS RFCs over the last 20+ years.
This point is further discussed in the recently published:

https://www.rfc-editor.org/rfc/rfc8918.html#name-handling-of-disallowed-tlvs

So I think your concerns about backwards compatibility are unwarranted. In 
particular the statement:

“[backwards compatibility] apparently relies on configuration of those routers 
that _do_ support the extensions to address this”

Is not correct.

   Les

From: rtg-dir  On Behalf Of Eric Gray
Sent: Friday, October 16, 2020 11:49 AM
To: rtg-...@ietf.org; lsr-cha...@ietf.org
Cc: rtg-...@ietf.org; lsr@ietf.org
Subject: [RTG-DIR] Rtg-Dir Last Call review of draft-ietf-lsr-flex-algo


Hello,

I have been selected as the Routing Directorate reviewer for this draft. The 
Routing Directorate seeks to review all routing or routing-related drafts as 
they pass through IETF last call and IESG review, and sometimes on special 
request. The purpose of the review is to provide assistance to the Routing ADs. 
For more information about the Routing Directorate, please see 
https://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir.



Although these comments are primarily for the use of the Routing ADs, it would 
be helpful if you could consider them along with any other IETF Last Call 
comments that you receive, and strive to resolve them through discussion or by 
updating the draft.



Document: draft-ietf-lsr-flex-algo-12.txt



Reviewer: Eric Gray

Review Date: 16 October, 2020

IETF LC End Date: Unknown

Intended Status: Standards Track



Summary:

This document is well organized, relatively easy to read, and probably ready 
for publication, but has one potential minor issue and a very small number of 
NITs that might be considered prior to publication.



Major Issues:

None



Minor Issues:

The statement in section 15 (Backward Compatibility) - "This extension brings 
no new backward compatibility issues" - seems somewhat flip.



I suspect that a tiny bit of analysis would not hurt.



The extensions in this draft are clearly intended to work in an environment 
where routers that _do_not_ support these extensions are also deployed, but 
apparently relies on configuration of those routers that _do_ support the 
extensions to address this.



That seems correct.



From my reading of the draft (which I have not closely followed for its entire 
development), while it introduces at least one new TLV, the OSPF routing 
protocol has well defined handling for TLVs that are not understood - hence the 
introduction of one or more new TLVs should not present a problem in OSPF.



Obviously Sub-TLVs of the new OSPF TLV type will not introduce compatibility 
issues.



I assume (but do not actually know) that a similar situation exists for the new 
ISIS FAD Sub-TLV of the existing TLV Type 242 - i.e. - ISIS presumably has well 
defined handling for sub-TLVs (of at least type 242) that are not recognized.  
If so, than the new Sub-TLV types defined are also not an issue.



Shouldn't this section say something along these lines?  I suspect that it 
would be more helpful if verifying the content of the "considerations" sections 
were not left as an exercise for the reader.  



NITs:

In the Introduction, the phrase "must often be replaced" seems very slightly 
problematic (especially given this is a standards track RFC wanna-be).  Would 
it be better to say "is often replaced" instead?



In section 17.1.2 and 17.2 - '... a "Interior Gateway ...' should probably be 
'... an "Interior Gateway ..." in both cases.



--

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


Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

2020-10-16 Thread Les Ginsberg (ginsberg)


> -Original Message-
> From: Lsr  On Behalf Of Aijun Wang
> Sent: Friday, October 16, 2020 1:48 AM
> To: Les Ginsberg (ginsberg) 
> Cc: John E Drake ; Christian Hopps
> ; lsr-cha...@ietf.org; lsr@ietf.org; Jeff Tantsura
> ; draft-ietf-lsr-ospf-prefix-origina...@ietf.org; 
> lsr-
> a...@ietf.org
> Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06
> 
> Hi, Les and experts in LSR:
> 
> I am open to the removal of the this appendix to forward this draft.

[Les:] Great!! Please do so.

   Les


> But as stated in previous mail, providing this can assist the user/reader of 
> the
> draft. We often encounter the questions in the mail list that what the usage
> of protocol/bit definition in some drafts.
> 
> Actually, we did not expand the discussion of this part in this draft. The
> description of this part is very concise.
> 
> If you insist this, I can update the draft in recent days, together with other
> comments on this draft.
> 
> Other comments are welcome also!
> 
> Aijun Wang
> China Telecom
> 
> > On Oct 16, 2020, at 13:51, Les Ginsberg (ginsberg) 
> wrote:
> >
> > Aijun -
> >
> > The point I am making is very focused.
> >
> > This draft is defining a protocol extension. As such it is necessary that 
> > this
> be Standards track as adhering to the normative statements in the draft are
> necessary for interoperability.
> >
> > What is discussed in the Appendix is a use case. It is not normative and
> there are strong opinions on both sides as to whether this is an appropriate
> use case or not.
> > In the context of this draft, I have no interest in trying to resolve our
> difference of opinion on this use case. I simply want the protocol extension
> to move forward so that we have another tool available.
> >
> > If you want to write a draft on the use case discussed in the Appendix
> please feel free to do so. That draft may very well not be normative -
> Informational or BCP may be more appropriate - because it will be discussing
> a deployment scenario and a proposal to use defined protocol extensions as
> one way to solve problems in that deployment scenario. Such a draft might
> also be more appropriate in another WG (e.g., TEAS). The merits of using
> prefix advertisements to build a topology could then be discussed on its own.
> >
> > Please do not try to avoid having a full discussion of the merits of using
> prefix advertisements to derive topology by adding it to a draft that is (and
> should be) focused on simple protocol extensions.
> >
> > Thanx.
> >
> >   Les
> >
> >
> >> -Original Message-
> >> From: Aijun Wang 
> >> Sent: Thursday, October 15, 2020 6:51 PM
> >> To: 'Jeff Tantsura' ; 'John E Drake'
> >> 
> >> Cc: 'Christian Hopps' ; lsr-cha...@ietf.org; Les
> Ginsberg
> >> (ginsberg) ; lsr@ietf.org; lsr-...@ietf.org; draft-
> ietf-
> >> lsr-ospf-prefix-origina...@ietf.org
> >> Subject: RE: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06
> >>
> >> Hi, Les, John and Jeff:
> >>
> >> Let's reply you all together.
> >> In my POV, The standard document should not define solely the protocol
> >> extension, but their usages in the network deployment. As I known,
> almost
> >> all the IETF documents following this style.
> >> And, before adopting one work, we have often intense discussion for
> what's
> >> their usages.
> >> Such discussion in the mail list and statements in the doc
> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

2020-10-15 Thread Les Ginsberg (ginsberg)
Aijun -

The point I am making is very focused.

This draft is defining a protocol extension. As such it is necessary that this 
be Standards track as adhering to the normative statements in the draft are 
necessary for interoperability.

What is discussed in the Appendix is a use case. It is not normative and there 
are strong opinions on both sides as to whether this is an appropriate use case 
or not.
In the context of this draft, I have no interest in trying to resolve our 
difference of opinion on this use case. I simply want the protocol extension to 
move forward so that we have another tool available.

If you want to write a draft on the use case discussed in the Appendix please 
feel free to do so. That draft may very well not be normative - Informational 
or BCP may be more appropriate - because it will be discussing a deployment 
scenario and a proposal to use defined protocol extensions as one way to solve 
problems in that deployment scenario. Such a draft might also be more 
appropriate in another WG (e.g., TEAS). The merits of using prefix 
advertisements to build a topology could then be discussed on its own. 

Please do not try to avoid having a full discussion of the merits of using 
prefix advertisements to derive topology by adding it to a draft that is (and 
should be) focused on simple protocol extensions.

Thanx.

   Les


> -Original Message-
> From: Aijun Wang 
> Sent: Thursday, October 15, 2020 6:51 PM
> To: 'Jeff Tantsura' ; 'John E Drake'
> 
> Cc: 'Christian Hopps' ; lsr-cha...@ietf.org; Les Ginsberg
> (ginsberg) ; lsr@ietf.org; lsr-...@ietf.org; draft-ietf-
> lsr-ospf-prefix-origina...@ietf.org
> Subject: RE: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06
> 
> Hi, Les, John and Jeff:
> 
> Let's reply you all together.
> In my POV, The standard document should not define solely the protocol
> extension, but their usages in the network deployment. As I known, almost
> all the IETF documents following this style.
> And, before adopting one work, we have often intense discussion for what's
> their usages.
> Such discussion in the mail list and statements in the document can certainly
> assist the reader/user of the document get the essence of the standard, and
> follow them unambiguously.
> 
> Regarding the contents of appendices, as stated in the section, "The
> Appendix A heuristic to rebuild the topology can normally be used if all links
> are numbered." I think this can apply almost most of the operator's network,
> and facilitate the inter-area TE path calculation for central controller, or 
> even
> for the head-end router that located in one area that different from the tail-
> end router.
> 
> Keeping the contents of appendices does not have the negative impact of
> the protocol extension, it is just one reference for the usage of this
> extension.
> One can select not refer to it, if their networks are deployed with large
> amount of unnumbered links. But for others, the heuristic applies.
> 
> Best Regards
> 
> Aijun Wang
> China Telecom
> 
> 
> 
> -Original Message-
> From: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] On Behalf Of Jeff
> Tantsura
> Sent: Friday, October 16, 2020 5:28 AM
> To: John E Drake 
> Cc: Christian Hopps ; lsr-cha...@ietf.org; Les Ginsberg
> (ginsberg) ; lsr@ietf.org; lsr-
> a...@ietf.org; draft-ietf-lsr-ospf-prefix-origina...@ietf.org
> Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06
> 
> +1
> 
> Regards,
> Jeff
> 
> > On Oct 15, 2020, at 11:33, John E Drake
>  wrote:
> >
> > Hi,
> >
> > I agree with Les.  This is a simple protocol extension for a specific 
> > purpose
> and there is no reason to include speculation about its use for other
> purposes, particularly when it is inherently not suited for them.
> >
> > Yours Irrespectively,
> >
> > John
> >
> >
> > Juniper Business Use Only
> >
> >> -Original Message-
> >> From: Lsr  On Behalf Of Les Ginsberg (ginsberg)
> >> Sent: Thursday, October 15, 2020 12:33 PM
> >> To: Christian Hopps ; lsr@ietf.org
> >> Cc: lsr-cha...@ietf.org; lsr-...@ietf.org;
> >> draft-ietf-lsr-ospf-prefix- origina...@ietf.org
> >> Subject: Re: [Lsr] WG Last Call
> >> draft-ietf-lsr-ospf-prefix-originator-06
> >>
> >> [External Email. Be cautious of content]
> >>
> >>
> >> I support moving this document forward.
> >> Similar functionality in IS-IS has proved useful.
> >>
> >> I would however like to repeat comments I made earlier in the review
> >> of this document.
> >> The content of the Appendices should be removed.
>

Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

2020-10-15 Thread Les Ginsberg (ginsberg)
I support moving this document forward.
Similar functionality in IS-IS has proved useful.

I would however like to repeat comments I made earlier in the review of this 
document.
The content of the Appendices should be removed.
The Appendices define and discuss deriving topology information from prefix 
advertisements - which is flawed and should not be done.
Perhaps more relevant, the purpose of the document is to define  protocol 
extensions supporting advertisement of the originators of a prefix 
advertisement. There is no need to discuss how this mechanism might be used to 
build topology information.
This document should confine itself to defining the protocol extensions - 
similar the RFC 7794.

If the authors do not agree to do this, I would encourage this point to be 
discussed during IESG review.

   Les

> -Original Message-
> From: Lsr  On Behalf Of Christian Hopps
> Sent: Wednesday, October 14, 2020 11:15 PM
> To: lsr@ietf.org
> Cc: draft-ietf-lsr-ospf-prefix-origina...@ietf.org; lsr-cha...@ietf.org; lsr-
> a...@ietf.org; Christian Hopps 
> Subject: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06
> 
> This begins a 2 week WG Last Call, ending after Oct 29th, 2020, for:
> 
>   https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-prefix-originator/
> 
> The following IPR has been filed https://datatracker.ietf.org/ipr/3448/
> 
> Authors,
> 
>   Please indicate to the list, your knowledge of any other IPR related to this
> work.
> 
> Thanks,
> Chris.

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


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

2020-10-02 Thread Les Ginsberg (ginsberg)
I support WG adoption of this draft.
OSPF needs functionality equivalent to that defined for IS-IS in RFC 8668.

   Les


> -Original Message-
> From: Lsr  On Behalf Of Christian Hopps
> Sent: Friday, October 02, 2020 5:03 AM
> To: lsr@ietf.org
> Cc: lsr-cha...@ietf.org; Christian Hopps ; draft-ketant-
> lsr-ospf-l2bundles@ietf.org
> Subject: [Lsr] WG adoption call for draft-ketant-lsr-ospf-l2bundles-01
> 
> This begins a 2 week WG adoption call for the following draft:
> 
>   https://datatracker.ietf.org/doc/draft-ketant-lsr-ospf-l2bundles/
> 
> Please indicate your support or objection by October 16, 2020.
> 
> Authors, please respond to the list indicating whether you are aware of any
> IPR that applies to this draft.
> 
> Thanks,
> Chris and Acee.

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


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

2020-09-30 Thread Les Ginsberg (ginsberg)
Ron -

Interesting proposal.

A few mundane - but I think still important - comments.

New IS-IS TLVs


There is no need to have two TLVs for each address-family - one for MTID #0 and 
one for all non-zero MTIDs. One TLV/AF will suffice.
The reason we have separate TLVs today is because MT (RFC 5120)  came along 
after TLV 135/236 had been defined/deployed.
Since you have a greenfield here you can simply have one TLV/AF and allow all 
MTIDs (including 0).

MTID is a 16 bit field with 4 reserved bits and 12 bits used for MTID value.  
(I believe someone else pointed this out as well.)
See RFC 5120.

You should specify that the new TLVs inherit the sub-TLV space defined in 
https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-135-235-236-237
 

The U-bit
-

I appreciate that there is precedence for calling this the U-bit based on RFC 
5308 - but I would prefer that you call it the D-bit.
Regardless of name, it MUST be consistent with existing usage - meaning it is 
set when the prefix is leaked downwards. Currently your text says:

"U (1 bit): Set indicates up.  Clear indicates down."

This needs to be reversed.

Constraints
---

I think you need to speak to various constraints including (but not limited to):

1)Algorithm is limited to flex-algo values (128-255)

I don't understand why Section 6 (main part - not the sub-sections) is there. 
What relevance do non-flex-algos have to this draft??

I also think the new sub-TLV would be better named "Native Flex-Algo Algorithm 
Sub-TLV".
Unless you are proposing to use this sub-TLV in ways not related to flex-algo - 
in which case I think you need to provide some explanation of the use case for 
this.

2)How to handle advertisement of same algo both in the new Algorithm sub-TLV 
and the existing SR Algorithm sub-TLV (prefer SR??)
Note that legacy routers may understand SR Algorithm Sub-TLV but not the new 
one.

   Les



> -Original Message-
> From: Lsr  On Behalf Of Ron Bonica
> Sent: Tuesday, September 29, 2020 6:38 AM
> To: lsr@ietf.org
> Subject: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-
> 00.txt
> 
> 
> Please review and comment
> 
>Ron
> 
> 
> 
> Juniper Business Use Only
> 
> > -Original Message-
> > From: internet-dra...@ietf.org 
> > Sent: Tuesday, September 29, 2020 9:36 AM
> > To: Parag Kaneriya ; Shraddha Hegde
> > ; Ron Bonica ; Rajesh M
> > ; William Britto A J 
> > Subject: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt
> >
> > [External Email. Be cautious of content]
> >
> >
> > A new version of I-D, draft-bonica-lsr-ip-flexalgo-00.txt
> > has been successfully submitted by Ron Bonica and posted to the IETF
> > repository.
> >
> > Name:   draft-bonica-lsr-ip-flexalgo
> > Revision:   00
> > Title:  IGP Flexible Algorithms (Flexalgo) In IP Networks
> > Document date:  2020-09-29
> > Group:  Individual Submission
> > Pages:  14
> > URL:https://urldefense.com/v3/__https://www.ietf.org/id/draft-
> bonica-
> > lsr-ip-flexalgo-00.txt__;!!NEt6yMaO-gk!X7PVDP-
> > FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck80Zbjoij$
> > Status:
> > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-
> bonica-lsr-
> > ip-flexalgo/__;!!NEt6yMaO-gk!X7PVDP-
> > FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck8x7e5ZqI$
> > Htmlized:
> > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-
> > bonica-lsr-ip-flexalgo__;!!NEt6yMaO-gk!X7PVDP-
> > FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck82w_6CyU$
> > Htmlized:
> https://urldefense.com/v3/__https://tools.ietf.org/html/draft-
> > bonica-lsr-ip-flexalgo-00__;!!NEt6yMaO-gk!X7PVDP-
> > FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck81_QrJ_p$
> >
> >
> > Abstract:
> >An IGP Flexible Algorithm computes a constraint-based path and maps
> >that path to an identifier.  As currently defined, Flexalgo can only
> >map the paths that it computes to Segment Routing (SR) identifiers.
> >Therefore, Flexalgo cannot be deployed in the absence of SR.
> >
> >This document extends Flexalgo, so that it can map the paths that it
> >computes to IP addresses.  This allows Flexalgo to be deployed in any
> >IP network, even in the absence of SR.
> >
> >
> >
> >
> > Please note that it may take a couple of minutes from the time of
> submission
> > until the htmlized version and diff are available at tools.ietf.org.
> >
> > The IETF Secretariat
> >
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

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


Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

2020-09-04 Thread Les Ginsberg (ginsberg)
In support of what Tony has said, I think any comparison between what RIFT is 
doing and what is proposed in this draft is inappropriate.

RIFT is able to determine what destinations exist in the network but are not 
reachable via a certain subset of the topology – and then generate negative 
advertisements appropriately. There is also full determinism in knowing when 
the negative advertisement should be removed.

draft-wang-lsr-prefix-unreachable-announcement by contrast tries to provide an 
advertisement for a destination that no longer exists. This leads to the lack 
of determinism which necessitates arbitrary timers and creates problems for 
nodes who connect to the network after the disappearance of the destination.

Not comparable at all IMO…

   Les

From: Lsr  On Behalf Of Tony Przygienda
Sent: Friday, September 04, 2020 11:12 AM
To: Aijun Wang 
Cc: Gyan Mishra ; Robert Raszuk ; 
Huzhibo ; Aijun Wang ; Peter 
Psenak ; lsr ; Acee Lindem 
(acee) ; Xiaoyaqun 
Subject: Re: [Lsr] New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt

I read the draft since the longish thread triggered my interest. As Peter said 
very thin ice walking with magic soft-state-timers for (to me) entirely unclear 
benefit and lots of interesting questions completely omitted like e.g. what 
will happen if a mix of old and new routers are in the network.

RIFT works completely differently BTW (and I don't think we _also_ noticed the 
problem, AFAIK RIFT is the first protocol that defined the concept of at least 
negative disaggregation to deal with black-hole avoidance in presence of 
summaries). RIFT defines precisely how negative disaggregation state is 
transitively propagated (if necessary) and next-hop resolved via recursive 
inheritance to provide black-hole and loop free routing in case of links 
failures on IP fabrics. No soft-timers or undescribed magic there. However, to 
do what RIFT is doing a sense of direction on the graph is needed (this is 
relatively easy on semi-lattice RIFT supports but would precondition uniform 
topological sorting on generic graphs, probably ending up in RPL type of 
solutions [which still need a direction indicator on arc to work and would take 
out a lot of links out of the topology possibly {but Pascal is better to judge 
that}]).

-- tony

On Mon, Aug 24, 2020 at 11:11 AM Aijun Wang 
mailto:wangai...@tsinghua.org.cn>> wrote:
Hi, Gyan:

Sorry for replying you so late.
You are right about the summary address behavior, but the summary address is 
configured by manually, and if one of the specific prefix within this summary 
range is down, the black hole(route to this specific prefix) will be formed.  
PUA mechanism just want to amend this.
Glad to know Rift has also noticed such issues.  In OSPF/ISIS, such problem 
needs also be solved.

If you are interested this topic, welcome to join us to the solution.


Best Regards

Aijun Wang
China Telecom

From: lsr-boun...@ietf.org 
[mailto:lsr-boun...@ietf.org] On Behalf Of Gyan 
Mishra
Sent: Thursday, August 6, 2020 4:44 PM
To: Aijun Wang mailto:wangai...@tsinghua.org.cn>>
Cc: Peter Psenak 
mailto:40cisco@dmarc.ietf.org>>; Robert 
Raszuk mailto:rob...@raszuk.net>>; Huzhibo 
mailto:huzh...@huawei.com>>; Aijun Wang 
mailto:wang...@chinatelecom.cn>>; lsr 
mailto:lsr@ietf.org>>; Acee Lindem (acee) 
mailto:a...@cisco.com>>; Xiaoyaqun 
mailto:xiaoya...@huawei.com>>
Subject: Re: [Lsr] New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt

Hi Aijun and authors

I am catching up with this thread after reading through this draft.

I understand the concept that we are trying to send a PUA advertisement which 
sounds similar to Rift Negative Disaggregation prefix now with a  null setting 
when a longer match component prefix that is part of a summary range is down to 
detect prefix down conditions with longer match component prefixes that are 
part of a summary.

Basically how summarization works with both OSPF and ISIS is that at minimum a 
single longer match within the defined IA summary range must exist for the IA 
summary to be sent.  So the summary is sent conditionally similar to a BGP 
conditional advertisement or even a ospf default originate which requires a 
default in the RIB to exist before the advertisement is sent.  A good example 
of non conditional analogy with BGP if you have a null0 static for a summary 
for an exact match BGP advertisement the prefix is always advertised no matter 
what even if no component prefixes exist.  This can result in black hole 
routing. BGP has conditional feature to conditionally advertisement based on 
existence of a route advertisement of downstream neighbor in the BGP RIB.  So 
with ospf and Isis the summary is in fact conditional similar to a BGP 
conditional advertisement and in the example given in the draft in section 3.1 
when node T2 is down and pt2 becomes unreachable and let’s 

Re: [Lsr] I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt

2020-08-27 Thread Les Ginsberg (ginsberg)
Tony –

The statement “the … Prefix SID does NOT have the semantics that we want and 
causes deleterious side-effects” is FALSE.

Other than  that,  we understand each other and we disagree.
You have my input.

There is an alternative here:

Given that there isn’t any defined use case for the Area Prefix/SID, you could 
choose to defer its definition until such time as a use case arises.
I agree that the concept is appealing and is potentially useful – which is why 
I thought it worthwhile to invest time in defining it. But a conservative 
approach might be to wait until we actually need it before defining it. It is 
always possible that when the use case arises we will find that there are some 
other issues which have been overlooked which might alter how this would be 
advertised.

   Les


From: Tony Li  On Behalf Of tony...@tony.li
Sent: Thursday, August 27, 2020 8:19 AM
To: Les Ginsberg (ginsberg) 
Cc: lsr@ietf.org
Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt


Les,


[Les:] Thanx for clarifying this. A careful reading of the draft supports what 
you say, but as this point could be easily overlooked it might be worth 
emphasizing this in the draft.


Noted and enhanced.

We do NOT require that the Area Leader candidates have identical 
configurations.  In fact, if there is a configuration change, it may be 
beneficial to configure one candidate differently and then raise its priority.  
It’s a simple way of effecting an area-wide configuration change.

[Les:] Section 4.2 states:

“For consistency, all Area Leader candidates SHOULD be configured with
   the same Proxy System Id, Proxy Hostname, and any other information
   that may be inserted into the Proxy LSP.”

I would agree that the flexibility to easily propagate a config change to be 
reflected in the Proxy LSP content requires relaxation of this rule.


This is exactly why it says SHOULD and not MUST.



We want outside nodes to install forwarding entries on the Prefix SID.  This is 
entirely backward compatible.  How is that inappropriate?

[Les:] Installation of forwarding entries today is based on Prefix Reachability 
advertisements. You are proposing to extend that by requiring a forwarding 
entry to be installed based on the context of the Area Proxy TLV.
I would prefer that you not introduce this.


I am well aware of that.

Perhaps it would help if I tell you that I am 100% impervious to Persuasion by 
Repetition.  I understand what you want. I disagree with you on the tradeoffs.



In addition, since there will also be a Prefix Reachability Advertisement for 
the Area Prefix in the Proxy LSP, the IERs will have two sources of information 
for the SID associated with the Area prefix (Area SID sub-TLV from Area leader 
L2 LSP and Prefix Reachability advertisement in the Proxy LSP). Which 
introduces the possibility of inconsistency.


No, since the IERs are supposed to ignore the Proxy LSP for any purpose other 
than flooding. I’m adding an explicit statement to this effect. The only source 
of truth is the Area Proxy TLV generated by the Area Leader.


The existing ones do not have the required semantics.

[Les:] That’s wasn’t the point.



That is the entire point.  You insist that we advertise the Area SID as a 
Prefix SID in addition to the a prefix in the Area Proxy TLV.  The additional 
Prefix SID does NOT have the semantics that we want and causes deleterious 
side-effects.




The point was that when a SID is advertised in prefix reachability it is used 
in preference to advertisements in other TLVs.


Except when it is part of the Proxy LSP, in which case we want the Inside 
Routers to ignore it.  We do NOT want Inside Routers creating forwarding state 
or SPF state for every prefix and SID in the Proxy LSP.



[Les:] The semantics you require are functionally equivalent to anycast 
behavior – which is supported already.


Please point me to anycast semantics that will ONLY be selected by IERs.
[Les:] You have specified that only IERs and Outside Routers process Proxy LSP 
content.  So why do you ask this question?


You’re asking me to use another mechanism.  I don’t see how it applies.  I’m 
open to you educating me.

IERs do NOT process Proxy LSP content other than to flood it.

Tony


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


Re: [Lsr] I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt

2020-08-27 Thread Les Ginsberg (ginsberg)
Tony –

Inline.

From: Tony Li  On Behalf Of tony...@tony.li
Sent: Wednesday, August 26, 2020 8:56 PM
To: Les Ginsberg (ginsberg) 
Cc: lsr@ietf.org
Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt


Hi Les,

[Les:] Any one of the IERs can be elected Area Leader, therefore all of them 
have to be configured with the Area Prefix and associated SID.


The Area Leader may not be an IER.  In fact, in an important use case for us, 
the area is a leaf-spine topology.  The Area Leader is one of the spines.  The 
leaves are the edge routers.  For resource reasons, we do NOT want the Area 
Leader to be a leaf.

[Les:] Thanx for clarifying this. A careful reading of the draft supports what 
you say, but as this point could be easily overlooked it might be worth 
emphasizing this in the draft.
In any case this isn’t significant for the points we are debating here.

We do NOT require that the Area Leader candidates have identical 
configurations.  In fact, if there is a configuration change, it may be 
beneficial to configure one candidate differently and then raise its priority.  
It’s a simple way of effecting an area-wide configuration change.

[Les:] Section 4.2 states:

“For consistency, all Area Leader candidates SHOULD be configured with
   the same Proxy System Id, Proxy Hostname, and any other information
   that may be inserted into the Proxy LSP.”

I would agree that the flexibility to easily propagate a config change to be 
reflected in the Proxy LSP content requires relaxation of this rule.
But again, not significant for the points we are debating here.


Perhaps you are allowing that each IER could choose a different Area 
Prefix/SID. Not sure why you would want to do that – but even if you did, the 
behavior of the winning prefix/SID is analogous to an anycast address.
The difference here is that the advertisement of the Prefix Reachability 
associated with the area prefix is within the Proxy LSP – which appears to OERs 
as if it was originated by all of the IERs i.e., the set of IERs appears as a 
single node to the OERs. Still, all IERs are aware of the winning prefix 
reachability advertisement and will do what is required in forwarding based on 
that content.


They will not be aware of it unless we tell them via the Area Proxy TLV.  For 
obvious reasons, the Inside Nodes do NOT do anything with the Proxy LSP other 
than flood it.


Which is why we’re using the Prefix SID.

[Les:] You are using the prefix-SID, but the advertisement is not associated 
with a prefix reachability  advertisement, yet you want nodes to install 
forwarding entries based on this advertisement. This is what seems 
inappropriate.


We want outside nodes to install forwarding entries on the Prefix SID.  This is 
entirely backward compatible.  How is that inappropriate?

[Les:] Installation of forwarding entries today is based on Prefix Reachability 
advertisements. You are proposing to extend that by requiring a forwarding 
entry to be installed based on the context of the Area Proxy TLV.
I would prefer that you not introduce this.
In addition, since there will also be a Prefix Reachability Advertisement for 
the Area Prefix in the Proxy LSP, the IERs will have two sources of information 
for the SID associated with the Area prefix (Area SID sub-TLV from Area leader 
L2 LSP and Prefix Reachability advertisement in the Proxy LSP). Which 
introduces the possibility of inconsistency.
If you do NOT advertise the SID in the Area Proxy TLV then you both eliminate 
the introduction of installing forwarding entries based on non-reachability 
advertisements and you eliminate the possibility of inconsistency.
That is what I am asking you to do.


The only current case where a prefix-SID is advertised and is NOT associated 
with prefix reachability is in the Binding TLVs. This has two use cases:

  *   Advertising SIDs for prefixes associated with nodes which are NOT SR 
capable
  *   As an alternative to per prefix advertisement if the operator prefers to 
use a centralized SID assignment service

In both of these cases if a SID were to be advertised in prefix reachability 
TLV for the same prefix the SID in the prefix reachability advertisement would 
be preferred.
You don’t discuss this at all in the draft i.e., what happens if the SID in the 
prefix reachability advertisement for the Area Prefix differs from that 
advertised in the Area Proxy TLV. What I am pushing for is eliminating the need 
to do so by relying on the existing prefix SID advertisements and not 
introducing a new one in the Area Proxy TLV.


The existing ones do not have the required semantics.

[Les:] That’s wasn’t the point. The point was that when a SID is advertised in 
prefix reachability it is used in preference to advertisements in other TLVs.


[Les:] The semantics you require are functionally equivalent to anycast 
behavior – which is supported already.


Please point me to anycast semantics that will ONLY be selected by IERs.
[Les

Re: [Lsr] I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt

2020-08-26 Thread Les Ginsberg (ginsberg)
Tony –

Inline.

From: Tony Li  On Behalf Of tony...@tony.li
Sent: Wednesday, August 26, 2020 5:40 PM
To: Les Ginsberg (ginsberg) 
Cc: lsr@ietf.org
Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt


Les,

As per the draft:

Area Proxy TLV is advertised by IERs in their L2 LSP.
Area Proxy TLV is NOT advertised in the Proxy LSP.
So how do the OERs become aware of the

“prefix and  SID that represents the entirety of the Inside Area to the Outside 
 Area”

???

I assume that they learn this because the Proxy LSP (at least) contains a 
Prefix Reachability TLV with the same prefix/SID that was advertised in the 
Area Proxy TLV.
Is this correct? If not, please correct me.


That’s correct.  If this isn’t crystal clear from the draft, please work with 
me to get it clarified to your satisfaction.



Also explain why it is necessary for something other than a prefix reachability 
advertisement to cause an entry to be created in forwarding for a prefix – and 
ONLY when received in an L2 LSP?
This is unprecedented.



It is unprecedented because there we are proposing something unprecedented.  I 
repeat: "There is no other mechanism whereby system A can advertise a prefix 
SID to a number of other systems and have them install receive/POP forwarding 
entries.”

It is NOT creating forwarding TO a prefix.  It’s reception.


[Les:] Any one of the IERs can be elected Area Leader, therefore all of them 
have to be configured with the Area Prefix and associated SID.
Perhaps you are allowing that each IER could choose a different Area 
Prefix/SID. Not sure why you would want to do that – but even if you did, the 
behavior of the winning prefix/SID is analogous to an anycast address.
The difference here is that the advertisement of the Prefix Reachability 
associated with the area prefix is within the Proxy LSP – which appears to OERs 
as if it was originated by all of the IERs i.e., the set of IERs appears as a 
single node to the OERs. Still, all IERs are aware of the winning prefix 
reachability advertisement and will do what is required in forwarding based on 
that content.


If I am right, you then have  multiple TLVs which advertise duplicate 
advertisements – even if not in the same LSP - which exposes you to the 
problems I mentioned.
My goal is to have one – and only one – advertisement which creates forwarding 
state.


Well, I’m sorry, but your goal is unachievable.  The Proxy LSP is only relevant 
outside of the area.  The Inner Node LSPs aren’t circulated outside of the area.

[Les:] Agreed. Nothing I have asserted suggests otherwise.


My second goal is not to invent a new SID type/advertisement when the object 
associated with it (a prefix) already has a defined SID type.


Which is why we’re using the Prefix SID.

[Les:] You are using the prefix-SID, but the advertisement is not associated 
with a prefix reachability  advertisement, yet you want nodes to install 
forwarding entries based on this advertisement. This is what seems 
inappropriate.
The only current case where a prefix-SID is advertised and is NOT associated 
with prefix reachability is in the Binding TLVs. This has two use cases:

  *   Advertising SIDs for prefixes associated with nodes which are NOT SR 
capable
  *   As an alternative to per prefix advertisement if the operator prefers to 
use a centralized SID assignment service

In both of these cases if a SID were to be advertised in prefix reachability 
TLV for the same prefix the SID in the prefix reachability advertisement would 
be preferred.
You don’t discuss this at all in the draft i.e., what happens if the SID in the 
prefix reachability advertisement for the Area Prefix differs from that 
advertised in the Area Proxy TLV. What I am pushing for is eliminating the need 
to do so by relying on the existing prefix SID advertisements and not 
introducing a new one in the Area Proxy TLV.

What I object to – and am concerned about – is that you seem to invent your 
version of SR for Area Proxy even when you use the same object (a prefix) that 
SR already supports.


Again, SR does not support the semantics that we require.


[Les:] The semantics you require are functionally equivalent to anycast 
behavior – which is supported already.

   Les


As you know, I was prepared to support a new type of SID when you actually were 
defining a new object type. The fact that you decided NOT to invent a new 
object type is fine with me – but please do not claim that you need a new SID 
type when you don’t.


I’m sorry that you still don’t understand.  We do need something different.

Tony


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


Re: [Lsr] I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt

2020-08-26 Thread Les Ginsberg (ginsberg)
Tony –

Sigh…

I introduced the term “Area Destination” only as a means of demonstrating that 
this could have been something other than a prefix – as had been proposed in 
earlier versions of the draft. I am not asking you to introduce the term in the 
draft and as it seemed to confuse you I won’t use it any more in this thread.

As per the draft:

Area Proxy TLV is advertised by IERs in their L2 LSP.
Area Proxy TLV is NOT advertised in the Proxy LSP.
So how do the OERs become aware of the

“prefix and  SID that represents the entirety of the Inside Area to the Outside 
 Area”

???

I assume that they learn this because the Proxy LSP (at least) contains a 
Prefix Reachability TLV with the same prefix/SID that was advertised in the 
Area Proxy TLV.
Is this correct? If not, please correct me.  Also explain why it is necessary 
for something other than a prefix reachability advertisement to cause an entry 
to be created in forwarding for a prefix – and ONLY when received in an L2 LSP?
This is unprecedented.

If I am right, you then have  multiple TLVs which advertise duplicate 
advertisements – even if not in the same LSP - which exposes you to the 
problems I mentioned.
My goal is to have one – and only one – advertisement which creates forwarding 
state.
My second goal is not to invent a new SID type/advertisement when the object 
associated with it (a prefix) already has a defined SID type.

What I object to – and am concerned about – is that you seem to invent your 
version of SR for Area Proxy even when you use the same object (a prefix) that 
SR already supports.

As you know, I was prepared to support a new type of SID when you actually were 
defining a new object type. The fact that you decided NOT to invent a new 
object type is fine with me – but please do not claim that you need a new SID 
type when you don’t.

   Les

From: Tony Li  On Behalf Of tony...@tony.li
Sent: Wednesday, August 26, 2020 4:02 PM
To: Les Ginsberg (ginsberg) 
Cc: lsr@ietf.org
Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt



Hi Les,


You have chosen to assign a prefix as the “Area Destination”.


Are you sure you have the right document?  The word “Destination” does not 
appear anywhere within 
https://tools.ietf.org/html/draft-ietf-lsr-isis-area-proxy-03



This is fine with me. But having done that, forwarding should be based on the 
existing mechanisms for advertising a prefix and the associated prefix SID.


Which is exactly what we’re doing: we’re advertising a prefix SID in the Proxy 
LSP.


If you’re referring to the Area SID advertisement, then there is no existing 
mechanism for advertising that today, that’s why we’re having to create an 
additional subTLV.
There is no other mechanism whereby system A can advertise a prefix SID to a 
number of other systems and have them install receive/POP forwarding entries.



By doing that you avoid a number of problems:


  *   Duplicate SID advertisements for the same prefix and the possibility of 
inconsistency
  *   Differing forwarding behavior for routers (IERs) who understand the Area 
Proxy TLV and those routers which don’t (everyone else)

You can still include a sub-TLV in the Area Proxy TLV to identify the Area 
Prefix, but there is no need to also advertise the SID there. This makes the 
“Area Prefix” advertisement functionally equivalent to the “Router-ID” 
advertisement. It’s a convenient way to identify the prefix associated with the 
area, but it does not eliminate the need to also advertise prefix reachability 
information for that prefix in order to enable forwarding.


You seem to be asking that the Area Leader also advertise a Prefix SID in its 
own LSP, as well as a prefix in the Area Proxy TLV.  This is not just 
duplication of advertisement, it’s duplication plus a prefix.  By your own 
criteria, this suggestion is worse than what we’ve proposed.

All Inside Nodes need to understand the Area Proxy TLV and respond accordingly. 
 Only the Inside Edge Nodes need to install forwarding state for the Area SID.  
Advertising a separate Prefix SID to the Inside Nodes forces them to create 
additional forwarding state that may not be desired by the network 
administrator.



I have also suggested that an additional bit could be assigned in the 
Prefix-Attributes sub-TLV (RFC 7794) to mark a prefix as an Area Prefix if you 
wish.


Thank you, but no thanks. As you’ve seen, a large driver for doing it this way 
is backward compatibility. Adding a bit would not be helpful in that regard.



But advertising a prefix-SID in two different places is a bad idea.


Advertising it in 2.5 places is worse.



In an unrelated matter, 
https://tools.ietf.org/html/draft-ietf-lsr-isis-area-proxy-03#section-2 states:

“An Inside Edge Router may be elected the DIS for a Boundary
   LAN.  In this case using the Area Proxy System Id as the basis for
   the LAN pseudonode identifier could create a collision, so the
   Insider Edge Router SHOULD compose

Re: [Lsr] Fwd: I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt

2020-08-26 Thread Les Ginsberg (ginsberg)
Tony -

You have chosen to assign a prefix as the "Area Destination". This is fine with 
me. But having done that, forwarding should be based on the existing mechanisms 
for advertising a prefix and the associated prefix SID.
By doing that you avoid a number of problems:


  *   Duplicate SID advertisements for the same prefix and the possibility of 
inconsistency
  *   Differing forwarding behavior for routers (IERs) who understand the Area 
Proxy TLV and those routers which don't (everyone else)


You can still include a sub-TLV in the Area Proxy TLV to identify the Area 
Prefix, but there is no need to also advertise the SID there. This makes the 
"Area Prefix" advertisement functionally equivalent to the "Router-ID" 
advertisement. It's a convenient way to identify the prefix associated with the 
area, but it does not eliminate the need to also advertise prefix reachability 
information for that prefix in order to enable forwarding.

I have also suggested that an additional bit could be assigned in the 
Prefix-Attributes sub-TLV (RFC 7794) to mark a prefix as an Area Prefix if you 
wish.

But advertising a prefix-SID in two different places is a bad idea.

.

In an unrelated matter, 
https://tools.ietf.org/html/draft-ietf-lsr-isis-area-proxy-03#section-2 states:

"An Inside Edge Router may be elected the DIS for a Boundary
   LAN.  In this case using the Area Proxy System Id as the basis for
   the LAN pseudonode identifier could create a collision, so the
   Insider Edge Router SHOULD compose the pseudonode identifier using
   its native system identifier."

I understand the potential collision that could arise if the Area Proxy 
System-Id were to be used in the pseudonode-id. However, what you propose is 
incompatible with a strict interpretation of ISO 10589 Section 8.4.5:

"If this system, as a result of the Designated Intermediate System election 
process, considers itself to be designated Intermediate System, the LAN ID 
field shall be set to the concatenation of this system's own system ID and the 
locally assigned one octet Local Circuit ID."

This raises the possibility that some of the non-DIS neighbors might not honor 
the pseudo-node ID since it does not match the system-id associated with their 
adjacency to the pseudo-node.
At a minimum this possibility should be mentioned in the text.

One way to mitigate this is to have the IERs advertise a LAN Priority of 0 in 
their IIHs so as to avoid this case.

   Les

From: Lsr  On Behalf Of tony...@tony.li
Sent: Monday, August 24, 2020 10:02 AM
To: lsr@ietf.org
Subject: [Lsr] Fwd: I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt


Hi folks,

This updated draft has been published for a few weeks now.  We would like to 
solicit your opinion on this.  In particular, we have changed the encoding of 
the Area SID.  Do you find this encoding adequate and appropriate?

Thanks,
Tony



Begin forwarded message:

From: internet-dra...@ietf.org
Subject: I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt
Date: August 5, 2020 at 1:17:39 PM PDT
To: mailto:i-d-annou...@ietf.org>>
Cc: lsr@ietf.org
Reply-To: internet-dra...@ietf.org, 
lsr@ietf.org


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

   Title   : Area Proxy for IS-IS
   Authors : Tony Li
 Sarah Chen
 Vivek Ilangovan
 Gyan S. Mishra
 Filename: draft-ietf-lsr-isis-area-proxy-03.txt
 Pages   : 19
 Date: 2020-08-05

Abstract:
  Link state routing protocols have hierarchical abstraction already
  built into them.  However, when lower levels are used for transit,
  they must expose their internal topologies to each other, leading to
  scale issues.

  To avoid this, this document discusses extensions to the IS-IS
  routing protocol that would allow level 1 areas to provide transit,
  yet only inject an abstraction of the level 1 topology into level 2.
  Each level 1 area is represented as a single level 2 node, thereby
  enabling greater scale.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-area-proxy/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-lsr-isis-area-proxy-03
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-area-proxy-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-isis-area-proxy-03


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

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



Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

2020-08-18 Thread Les Ginsberg (ginsberg)
Huaimo -

The question I and others have asked is "what can we do with zones that cannot 
be done with areas?".

>From the day several years ago when IS-IS TTZ was first presented,  your 
>answer has been "with zones you can hitlessly alter the topological 
>boundaries".
My response has consistently been "we can already do that with areas".

If you want to justify zones, you then need to provide some other use case that 
either cannot be done using areas or cannot be done hitlessly.
Continuing to focus on something that can already be done with areas isn't 
helping you.

   Les


From: Huaimo Chen 
Sent: Tuesday, August 18, 2020 3:18 PM
To: Les Ginsberg (ginsberg) ; Les Ginsberg (ginsberg) 
; Acee Lindem (acee) 
; lsr@ietf.org
Subject: Re: LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - 
draft-chen-isis-ttz-11.txt

Hi Les,

> It is possible to merge/split areas without adjacency flaps.
[HC]: While an existing area or zone is being abstracted as a single node 
or vice versa, there are the adjacency ups and downs. The areas 
merging/splitting without adjacency flaps has been done before this abstraction 
and will not reduce the service interruption during the abstraction.

Best Regards,
Huaimo
____
From: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Sent: Tuesday, August 18, 2020 5:59 PM
To: Huaimo Chen mailto:huaimo.c...@futurewei.com>>; 
Les Ginsberg (ginsberg) 
mailto:ginsberg=40cisco@dmarc.ietf.org>>;
 Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org> mailto:lsr@ietf.org>>
Subject: RE: LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - 
draft-chen-isis-ttz-11.txt


Huaimo -



It is possible to merge/split areas without adjacency flaps.

The technique has been known for many years.

It requires careful planning - but it is quite feasible and has been done.



You cannot justify the need for zones on this basis.



   Les





From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
Huaimo Chen
Sent: Tuesday, August 18, 2020 2:33 PM
To: Les Ginsberg (ginsberg) 
mailto:ginsberg=40cisco@dmarc.ietf.org>>;
 Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Subject: Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - 
draft-chen-isis-ttz-11.txt



Hi Les,



> I see no need for "abstraction at arbitrary boundaries". Areas work just fine.

> IS-IS already has smooth transition capability for merging/splitting areas..



[HC]: The smooth transition capability for merging/splitting areas in IS-IS 
will not reduce the service interruption while an existing area or zone is 
being abstracted as a single node because the adjacency ups and downs.



> Given both of the points above, I see no value in "smooth transition to/from 
> zone abstraction".



[HC]:  The "smooth transition to/from zone abstraction" will reduce the service 
interruption while an existing area or zone is being abstracted as a single 
node and vice versa.



Best Regards,

Huaimo



From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of Les 
Ginsberg (ginsberg) 
mailto:ginsberg=40cisco@dmarc.ietf.org>>
Sent: Tuesday, August 18, 2020 5:06 PM
To: Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org> mailto:lsr@ietf.org>>
Subject: Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - 
draft-chen-isis-ttz-11.txt



I see no need for "abstraction at arbitrary boundaries". Areas work just fine.



IS-IS already has smooth transition capability for merging/splitting areas.



Given both of the points above, I see no value in "smooth transition to/from 
zone abstraction".



If these are the principal distinguishing characteristics of TTZ as compared to 
area proxy (and I would agree they are), then I see no reason why this solution 
should be pursued as well.



I am therefore opposed to WG adoption of TTZ.



   Les







From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Acee 
Lindem (acee)
Sent: Tuesday, August 18, 2020 7:17 AM
To: lsr@ietf.org<mailto:lsr@ietf.org>
Subject: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - 
draft-chen-isis-ttz-11.txt





Based on the discussions in the last meeting and on the mailing list regarding 
draft-chen-isis-ttz-11, the chairs feel that there are enough differences with 
draft-ietf-lsr-isis-area-proxy-03 and in the community to consider advancing it 
independently on the experimental track.



These differences include abstraction at arbitrary boundaries and IS-IS 
extensions for smooth transition to/from zone abstraction.



We are now starting an LSR 

Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

2020-08-18 Thread Les Ginsberg (ginsberg)
Huaimo -

It is possible to merge/split areas without adjacency flaps.
The technique has been known for many years.
It requires careful planning - but it is quite feasible and has been done.

You cannot justify the need for zones on this basis.

   Les


From: Lsr  On Behalf Of Huaimo Chen
Sent: Tuesday, August 18, 2020 2:33 PM
To: Les Ginsberg (ginsberg) ; Acee Lindem 
(acee) ; lsr@ietf.org
Subject: Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - 
draft-chen-isis-ttz-11.txt

Hi Les,

> I see no need for "abstraction at arbitrary boundaries". Areas work just fine.
> IS-IS already has smooth transition capability for merging/splitting areas..

[HC]: The smooth transition capability for merging/splitting areas in IS-IS 
will not reduce the service interruption while an existing area or zone is 
being abstracted as a single node because the adjacency ups and downs.

> Given both of the points above, I see no value in "smooth transition to/from 
> zone abstraction".

[HC]:  The "smooth transition to/from zone abstraction" will reduce the service 
interruption while an existing area or zone is being abstracted as a single 
node and vice versa.

Best Regards,
Huaimo

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of Les 
Ginsberg (ginsberg) 
mailto:ginsberg=40cisco@dmarc.ietf.org>>
Sent: Tuesday, August 18, 2020 5:06 PM
To: Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org> mailto:lsr@ietf.org>>
Subject: Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - 
draft-chen-isis-ttz-11.txt


I see no need for "abstraction at arbitrary boundaries". Areas work just fine.



IS-IS already has smooth transition capability for merging/splitting areas.



Given both of the points above, I see no value in "smooth transition to/from 
zone abstraction".



If these are the principal distinguishing characteristics of TTZ as compared to 
area proxy (and I would agree they are), then I see no reason why this solution 
should be pursued as well.



I am therefore opposed to WG adoption of TTZ.



   Les







From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Acee 
Lindem (acee)
Sent: Tuesday, August 18, 2020 7:17 AM
To: lsr@ietf.org<mailto:lsr@ietf.org>
Subject: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - 
draft-chen-isis-ttz-11.txt





Based on the discussions in the last meeting and on the mailing list regarding 
draft-chen-isis-ttz-11, the chairs feel that there are enough differences with 
draft-ietf-lsr-isis-area-proxy-03 and in the community to consider advancing it 
independently on the experimental track.



These differences include abstraction at arbitrary boundaries and IS-IS 
extensions for smooth transition to/from zone abstraction.



We are now starting an LSR WG adoption call for draft-chen-isis-ttz-11.txt. 
Please indicate your support or objection to adoption prior to Tuesday, 
September 2nd, 2020.



Thanks,

Acee and Chris


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


Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

2020-08-18 Thread Les Ginsberg (ginsberg)
I see no need for “abstraction at arbitrary boundaries”. Areas work just fine.

IS-IS already has smooth transition capability for merging/splitting areas.

Given both of the points above, I see no value in “smooth transition to/from 
zone abstraction”.

If these are the principal distinguishing characteristics of TTZ as compared to 
area proxy (and I would agree they are), then I see no reason why this solution 
should be pursued as well.

I am therefore opposed to WG adoption of TTZ.

   Les



From: Lsr  On Behalf Of Acee Lindem (acee)
Sent: Tuesday, August 18, 2020 7:17 AM
To: lsr@ietf.org
Subject: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - 
draft-chen-isis-ttz-11.txt


Based on the discussions in the last meeting and on the mailing list regarding 
draft-chen-isis-ttz-11, the chairs feel that there are enough differences with 
draft-ietf-lsr-isis-area-proxy-03 and in the community to consider advancing it 
independently on the experimental track.

These differences include abstraction at arbitrary boundaries and IS-IS 
extensions for smooth transition to/from zone abstraction.

We are now starting an LSR WG adoption call for draft-chen-isis-ttz-11.txt. 
Please indicate your support or objection to adoption prior to Tuesday, 
September 2nd, 2020.

Thanks,
Acee and Chris

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


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

2020-08-18 Thread Les Ginsberg (ginsberg)
Tony –

I am not “fighting”.
I just found your interpretation very hard to follow.

Moving on…

   Les


From: Tony Li  On Behalf Of tony...@tony.li
Sent: Tuesday, August 18, 2020 12:33 PM
To: Les Ginsberg (ginsberg) 
Cc: Robert Raszuk ; Christian Hopps ; 
draft-ietf-lsr-flex-algo@ietf.org; Les Ginsberg (ginsberg) 
; lsr@ietf.org; lsr-...@ietf.org; Acee 
Lindem (acee) ; Peter Psenak (ppsenak) 
Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo


Les,

There is no TLV called the Min Unidirectional Link Delay.

If the document had said “The min delay of the Min/Max Unidirectional Link 
Delay” then there would be no confusion.

Instead, it is the sloppy writing of ignoring the full name of the TLV that has 
created ambiguity.

Now, Peter has agreed to make a clarification, so:

  Why are we still fighting?

Tony



On Aug 18, 2020, at 12:18 PM, Les Ginsberg (ginsberg) 
mailto:ginsb...@cisco.com>> wrote:

Tony/Robert –

Whatever clarification Peter may choose to make would be fine – but I do 
question your casual ignoring of adjectives. 

There are three values being advertised:

33 - Unidirectional Link Delay
34 – Min/Max Unidirectional Link Delay
 Meaning two values are advertised in this codepoint:
 Min Unidirectional Link Delay
 Max Unidirectional Link Delay

Now, the flex algo draft states: Min Unidirectional Link Delay

If you want to argue that “Min Unidirectional Link Delay” != “Min/Max 
Unidirectional Link Delay” – I think you are pedantically correct.

But how that leads you to simply truncate “Min” and conclude that this is 
really “Unidirectional Link Delay” is a leap that I cannot follow.

Perhaps you don’t really like the fact that RFC 8570 encoding combined Min/Max 
in a single codepoint – but that ship sailed years ago.

Given that RFC 8570 is very clear in showing that the encoding includes:


   0   1   2   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Type| Length|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A| RESERVED|   Min Delay   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   RESERVED|   Max Delay   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


my ability to see your POV is somewhat limited.

Perhaps you could own that a more careful reading is possible?

   Les


From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
tony...@tony.li<mailto:tony...@tony.li>
Sent: Tuesday, August 18, 2020 10:03 AM
To: Robert Raszuk mailto:rob...@raszuk.net>>
Cc: Christian Hopps mailto:cho...@chopps.org>>; 
draft-ietf-lsr-flex-algo@ietf.org<mailto:draft-ietf-lsr-flex-algo@ietf.org>;
 Les Ginsberg (ginsberg) 
mailto:ginsberg=40cisco@dmarc.ietf.org>>;
 lsr@ietf.org<mailto:lsr@ietf.org>; lsr-...@ietf.org<mailto:lsr-...@ietf.org>; 
Acee Lindem (acee) mailto:a...@cisco.com>>; Peter Psenak 
(ppsenak) mailto:ppse...@cisco.com>>
Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo


Robert,

Thank you, exactly.

We just need a clarification of the document.  I don’t understand why this is 
such a big deal.

Tony




On Aug 18, 2020, at 9:22 AM, Robert Raszuk 
mailto:rob...@raszuk.net>> wrote:

Les,

I think this is not very obvious as Tony is pointing out.

See RFC 8570 says:


  TypeDescription

  

   33 Unidirectional Link Delay



   34 Min/Max Unidirectional Link Delay

That means that is someone implementing it reads text in this draft literally 
(meaning Minimum value of Unidirectional Link Delay) it may pick minimum value 
from ULD type 33 :)

If you want to be precise this draft may say minimum value of Min/Max 
Unidirectional Link Delay (34) and be done.

That's all.

Cheers,
R.



On Tue, Aug 18, 2020 at 6:04 PM Les Ginsberg (ginsberg) 
mailto:40cisco@dmarc.ietf.org>> wrote:
Tony –

As an author of both RFC 8570 and I-D.ietf-isis-te-app, I am not sure why you 
are confused – nor why you got misdirected to code point 33.

RFC 8570 (and its predecessor RFC 7810) define:

34   Min/Max Unidirectional Link Delay

This sub-TLV contains two values:

“Min Delay:  This 24-bit field carries the minimum measured link delay
  value (in microseconds) over a configurable interval, encoded as
  an integer value.

   Max Delay:  This 24-bit field carries the maximum measured link delay
  value (in microseconds) over a configurable interval, encoded as
  an integer value.”

It seems clear to me that the flex-draft is referring to Min Unidirectional 
Link Delay in codepoint 34.

I agree it is important to be unambiguous in specifications, but I think Peter 
has been v

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

2020-08-18 Thread Les Ginsberg (ginsberg)
Tony/Robert –

Whatever clarification Peter may choose to make would be fine – but I do 
question your casual ignoring of adjectives. 

There are three values being advertised:

33 - Unidirectional Link Delay
34 – Min/Max Unidirectional Link Delay
 Meaning two values are advertised in this codepoint:
 Min Unidirectional Link Delay
 Max Unidirectional Link Delay

Now, the flex algo draft states: Min Unidirectional Link Delay

If you want to argue that “Min Unidirectional Link Delay” != “Min/Max 
Unidirectional Link Delay” – I think you are pedantically correct.

But how that leads you to simply truncate “Min” and conclude that this is 
really “Unidirectional Link Delay” is a leap that I cannot follow.

Perhaps you don’t really like the fact that RFC 8570 encoding combined Min/Max 
in a single codepoint – but that ship sailed years ago.

Given that RFC 8570 is very clear in showing that the encoding includes:


   0   1   2   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Type| Length|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A| RESERVED|   Min Delay   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   RESERVED|   Max Delay   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


my ability to see your POV is somewhat limited.

Perhaps you could own that a more careful reading is possible?

   Les


From: Lsr  On Behalf Of tony...@tony.li
Sent: Tuesday, August 18, 2020 10:03 AM
To: Robert Raszuk 
Cc: Christian Hopps ; draft-ietf-lsr-flex-algo@ietf.org; 
Les Ginsberg (ginsberg) ; lsr@ietf.org; 
lsr-...@ietf.org; Acee Lindem (acee) ; Peter Psenak (ppsenak) 

Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo


Robert,

Thank you, exactly.

We just need a clarification of the document.  I don’t understand why this is 
such a big deal.

Tony



On Aug 18, 2020, at 9:22 AM, Robert Raszuk 
mailto:rob...@raszuk.net>> wrote:

Les,

I think this is not very obvious as Tony is pointing out.

See RFC 8570 says:


  TypeDescription

  

   33 Unidirectional Link Delay



   34 Min/Max Unidirectional Link Delay

That means that is someone implementing it reads text in this draft literally 
(meaning Minimum value of Unidirectional Link Delay) it may pick minimum value 
from ULD type 33 :)

If you want to be precise this draft may say minimum value of Min/Max 
Unidirectional Link Delay (34) and be done.

That's all.

Cheers,
R.



On Tue, Aug 18, 2020 at 6:04 PM Les Ginsberg (ginsberg) 
mailto:40cisco@dmarc.ietf.org>> wrote:
Tony –

As an author of both RFC 8570 and I-D.ietf-isis-te-app, I am not sure why you 
are confused – nor why you got misdirected to code point 33.

RFC 8570 (and its predecessor RFC 7810) define:

34   Min/Max Unidirectional Link Delay

This sub-TLV contains two values:

“Min Delay:  This 24-bit field carries the minimum measured link delay
  value (in microseconds) over a configurable interval, encoded as
  an integer value.

   Max Delay:  This 24-bit field carries the maximum measured link delay
  value (in microseconds) over a configurable interval, encoded as
  an integer value.”

It seems clear to me that the flex-draft is referring to Min Unidirectional 
Link Delay in codepoint 34.

I agree it is important to be unambiguous in specifications, but I think Peter 
has been very clear.
Please explain how you managed to end up at code point 33??

   Les



From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
tony...@tony.li<mailto:tony...@tony.li>
Sent: Tuesday, August 18, 2020 7:44 AM
To: Peter Psenak (ppsenak) mailto:ppse...@cisco.com>>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>; 
lsr-...@ietf.org<mailto:lsr-...@ietf.org>; Christian Hopps 
mailto:cho...@chopps.org>>; Acee Lindem (acee) 
mailto:a...@cisco.com>>; 
draft-ietf-lsr-flex-algo@ietf.org<mailto:draft-ietf-lsr-flex-algo@ietf.org>
Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo


Hi Peter,


section 5.1 of the draft-ietf-lsr-flex-algo says:

Min Unidirectional Link Delay as defined in [I-D.ietf-isis-te-app].

We explicitly say "Min Unidirectional Link Delay", so this cannot be mixed with 
other delay values (max, average).


The problem is that that does not exactly match “Unidirectional Link Delay” or 
“Min/Max Unidirectional Link Delay”, leading to the ambiguity. Without a clear 
match, you leave things open to people guessing. Now, it’s a metriic, so of 
course, you always want to take the min.  So type 33 seems like a better match.



section 7.3. of ietf-isis-te-app says:

Type   Description 

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

2020-08-18 Thread Les Ginsberg (ginsberg)
Tony –

As an author of both RFC 8570 and I-D.ietf-isis-te-app, I am not sure why you 
are confused – nor why you got misdirected to code point 33.

RFC 8570 (and its predecessor RFC 7810) define:

34   Min/Max Unidirectional Link Delay

This sub-TLV contains two values:

“Min Delay:  This 24-bit field carries the minimum measured link delay
  value (in microseconds) over a configurable interval, encoded as
  an integer value.

   Max Delay:  This 24-bit field carries the maximum measured link delay
  value (in microseconds) over a configurable interval, encoded as
  an integer value.”

It seems clear to me that the flex-draft is referring to Min Unidirectional 
Link Delay in codepoint 34.

I agree it is important to be unambiguous in specifications, but I think Peter 
has been very clear.
Please explain how you managed to end up at code point 33??

   Les



From: Lsr  On Behalf Of tony...@tony.li
Sent: Tuesday, August 18, 2020 7:44 AM
To: Peter Psenak (ppsenak) 
Cc: lsr@ietf.org; lsr-...@ietf.org; Christian Hopps ; Acee 
Lindem (acee) ; draft-ietf-lsr-flex-algo@ietf.org
Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo


Hi Peter,



section 5.1 of the draft-ietf-lsr-flex-algo says:

Min Unidirectional Link Delay as defined in [I-D.ietf-isis-te-app].

We explicitly say "Min Unidirectional Link Delay", so this cannot be mixed with 
other delay values (max, average).


The problem is that that does not exactly match “Unidirectional Link Delay” or 
“Min/Max Unidirectional Link Delay”, leading to the ambiguity. Without a clear 
match, you leave things open to people guessing. Now, it’s a metriic, so of 
course, you always want to take the min.  So type 33 seems like a better match.




section 7.3. of ietf-isis-te-app says:

Type   Description  Encoding
   Reference
-
34  Min/Max Unidirectional Link DelayRFC8570


And it also says:


33  Unidirectional Link Delay
RFC8570


This does not help.



So, IMHO what we have now is correct and sufficient, but I have no issue adding 
the text you proposed below.


What you have now is ambiguous. We have a responsibility, as writers of 
specifications, to be precise and clear.  We are not there yet.



BTW, before I posted 09 version of flex-algo draft, I asked if you were fine 
with just referencing ietf-isis-te-app in 5.1. I thought you were, as you did 
not indicate otherwise.


My bad, I should have pressed the issue.



Anyway, I consider this as a pure editorial issue and hopefully not something 
that would cause you to object the WG LC of the flex-algo draft.


I’m sorry, I think that this is trivially resolved, but important clarification.

You also have an author’s email that is bouncing, so at least one more spin is 
required.

Sorry,
Tony

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


Re: [Lsr] draft-ietf-lsr-isis-area-proxy-02

2020-08-07 Thread Les Ginsberg (ginsberg)
Tony –

If the choice is to use a prefix, I do not know why you even raise the 
possibility of advertising the SID other than how Prefix SIDs are done today.
Is the current Reachability advertisement inadequate in some way? I don’t think 
so.

   Les


From: Tony Li 
Sent: Thursday, August 06, 2020 11:46 PM
To: Les Ginsberg (ginsberg) 
Cc: Acee Lindem (acee) ; Bruno Decraene 
; lsr@ietf.org
Subject: Re: [Lsr] draft-ietf-lsr-isis-area-proxy-02


Hi Les,

1)Invent a new type of SID which is associated with an area.
In this case some variation of encodings defined in V2 of the draft are 
appropriate.


But these aren’t backward compatible, which operators clearly want.


2)Use a reachable address to get to the area. That address could be the node 
address of the current Area Leader or an anycast address shared by all IERs.


Either of these is fine by me.  Do others care?



IN which case existing prefix SID advertisement is appropriate coupled with a 
means of identifying the address. There are two proposed encodings for that.


And here we haven’t come to agreement.  Do others have a preference?

Tony


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


Re: [Lsr] draft-ietf-lsr-isis-area-proxy-02

2020-08-06 Thread Les Ginsberg (ginsberg)
Tony –

There are two options that have been proposed:

1)Invent a new type of SID which is associated with an area.
In this case some variation of encodings defined in V2 of the draft are 
appropriate.

2)Use a reachable address to get to the area. That address could be the node 
address of the current Area Leader or an anycast address shared by all IERs.
IN which case existing prefix SID advertisement is appropriate coupled with a 
means of identifying the address. There are two proposed encodings for that.

Pick either of the two options above and I would find it acceptable.

   Les

From: Tony Li 
Sent: Thursday, August 06, 2020 2:42 PM
To: Les Ginsberg (ginsberg) 
Cc: Acee Lindem (acee) ; Bruno Decraene 
; lsr@ietf.org
Subject: Re: [Lsr] draft-ietf-lsr-isis-area-proxy-02


Les,

Not sure why this needs to be explained.


Because we are not communicating well. We are each making unstated assumptions 
that do not mesh.

When we do not communicate, it’s time to double check the basics.



Whether you are doing label forwarding or IP forwarding, the path of the packet 
still depends upon reaching the destination.
If I have a unicast destination then the packet needs to reach the unique 
advertiser of that destination.
If I have an anycast destination then the packet needs to reach only one of the 
possibly many advertisers of that destination.


You’re assuming that there’s actually traffic that is destined to the specified 
prefix.  I don’t share that assumption.  [Communication just improved!]

At the end of the day, we’re talking about TE here and path computation is not 
only about destinations.  It’s also about the path itself. The purpose of the 
Area SID is to provide a waypoint for path computation, not to provide a 
destination.


Are you proposing for “Area SID” that we tie the SID to a prefix but alter the 
logic such that nodes which do not advertise the prefix can be considered as 
the final destination?
I would not like to go down that path…


From my perspective, the entire purpose of the Area SID is to provide the SID 
value so that some controller somewhere, in its infinite wisdom, can stick a 
label somewhere in some lable stack and route packets via the Proxy Area.  The 
sole purpose of the prefix is to make SR syntax happy.  [See previous rant 
about encodings in IS-IS.] For my intent, we could use 0.0.0.0/32 and 0::0/128.

Let me turn it around: what’s the simplest thing that we could do that would 
satisfy you?

Tony

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


Re: [Lsr] draft-ietf-lsr-isis-area-proxy-02

2020-08-06 Thread Les Ginsberg (ginsberg)
Tony –

Not sure why this needs to be explained.
Whether you are doing label forwarding or IP forwarding, the path of the packet 
still depends upon reaching the destination.
If I have a unicast destination then the packet needs to reach the unique 
advertiser of that destination.
If I have an anycast destination then the packet needs to reach only one of the 
possibly many advertisers of that destination.

Are you proposing for “Area SID” that we tie the SID to a prefix but alter the 
logic such that nodes which do not advertise the prefix can be considered as 
the final destination?
I would not like to go down that path…

   Les


From: Tony Li 
Sent: Thursday, August 06, 2020 9:32 AM
To: Les Ginsberg (ginsberg) 
Cc: Acee Lindem (acee) ; Bruno Decraene 
; lsr@ietf.org
Subject: Re: [Lsr] draft-ietf-lsr-isis-area-proxy-02



Les,

 There then remains the question as to whether the “Area Prefix” is anycast or 
unicast i.e., is it common to all IERs or is it unique to whomever gets elected 
Area Leader?

Does it matter? We have no clear semantics for this prefix. A difference that 
makes no difference is no difference.

[Les:] This question needs to be directed at those who prefer the Area Prefix 
approach. It matters as it impacts configuration and advertisement semantics. 
An anycast prefix is NOT a Node Prefix.
And it impacts how traffic is forwarded into the area.



How so?  Traffic will be directed to the SID value (modulo PHP).
[Les3:] If the prefix is private to a single router then traffic has to pass 
through that router. If it is anycast the traffic could arrive at any one of 
the routers supporting the anycast address.



I must be missing something. My understanding of SR is that you forward based 
on the label.  Please educate me.

Tony

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


Re: [Lsr] draft-ietf-lsr-isis-area-proxy-02

2020-08-05 Thread Les Ginsberg (ginsberg)
Tony -

From: Tony Li 
Sent: Wednesday, August 05, 2020 4:26 PM
To: Les Ginsberg (ginsberg) 
Cc: Acee Lindem (acee) ; Bruno Decraene 
; lsr@ietf.org
Subject: Re: [Lsr] draft-ietf-lsr-isis-area-proxy-02


Les,

This would make the Area Prefix mandatory for Area Proxy, which is not desired. 
 We would prefer it to remain optional and thus part of the Area SID sub-TLV.

[Les2:] You can advertise the Area Prefix in an optional sub-TLV – just as you 
did with the Area SID. That is what I expected you would do.


Good.  I’ve just submitted -03, which does exactly that.  Please review.  Note 
that tools.ietf.org<http://tools.ietf.org> appears to be down at this instant. 
(??!?!?!)

[Les3:] Yes – I saw that after my reply. My comments still stand.

b)The remaining info (reachability and SID) can then be provided using existing 
Prefix Reachability advertisements – no need for new sub-TLV for “Area SID”. 
This eliminates any potential issues if the SID advertised by “Area SID 
sub-TLV” were to differ from the SID advertised in Prefix Reachability for the 
same prefix.


As we discussed privately, we view this as a non-issue.  The Area Leader is the 
one advertising both the Area SID sub-TLV and the Proxy LSP. If there’s a 
coding error, there’s a coding error. There is a single source of truth (the 
Area Leader’s config) and we cannot protect against every possible coding 
error.  Reconciling the prefix with a separate advertisement has a non-trivial 
chance of being broken too, and IMHO, much larger.

[Les2:] You can define the advertisements in a way which reduces the 
possibility of ambiguity – which seems like a good thing to me.
And rest assured that you will be asked by someone to define the expected 
behavior when there is an inconsistency. 


Same question: same answer. :-)



Since prefix SID and Prefix reachability are directly related in forwarding, it 
makes far more sense to me to have those two together.
If you find correlating information in two different TLVs too challenging, you 
could opt for a new bit in the prefix attributes sub-TLV to identify a prefix 
as an “Area Prefix”. Then you would not need any additional info advertised in 
the Area Proxy TLV at all.


We prefer to keep it in the Area Proxy TLV so that its semantics are crystal 
clear.

[Les3:] This will make it more awkward (at best) to reuse the concept outside 
of the  Area Proxy use case. The prefix attributes option would make it very 
easy for any use case to be supported.


 There then remains the question as to whether the “Area Prefix” is anycast or 
unicast i.e., is it common to all IERs or is it unique to whomever gets elected 
Area Leader?

Does it matter? We have no clear semantics for this prefix. A difference that 
makes no difference is no difference.

[Les:] This question needs to be directed at those who prefer the Area Prefix 
approach. It matters as it impacts configuration and advertisement semantics. 
An anycast prefix is NOT a Node Prefix.
And it impacts how traffic is forwarded into the area.



How so?  Traffic will be directed to the SID value (modulo PHP).
[Les3:] If the prefix is private to a single router then traffic has to pass 
through that router. If it is anycast the traffic could arrive at any one of 
the routers supporting the anycast address.

   Les

Tony

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


Re: [Lsr] draft-ietf-lsr-isis-area-proxy-02

2020-08-05 Thread Les Ginsberg (ginsberg)
Tony -

From: Tony Li 
Sent: Wednesday, August 05, 2020 1:08 PM
To: Les Ginsberg (ginsberg) 
Cc: Acee Lindem (acee) ; Bruno Decraene 
; lsr@ietf.org
Subject: Re: [Lsr] draft-ietf-lsr-isis-area-proxy-02


Les,



a)Advertise the “Area Prefix” in the Area Proxy TLV – much as we do a router-id 
today in the Router-ID TLV.


This would make the Area Prefix mandatory for Area Proxy, which is not desired. 
 We would prefer it to remain optional and thus part of the Area SID sub-TLV.

[Les2:] You can advertise the Area Prefix in an optional sub-TLV – just as you 
did with the Area SID. That is what I expected you would do.


b)The remaining info (reachability and SID) can then be provided using existing 
Prefix Reachability advertisements – no need for new sub-TLV for “Area SID”. 
This eliminates any potential issues if the SID advertised by “Area SID 
sub-TLV” were to differ from the SID advertised in Prefix Reachability for the 
same prefix.


As we discussed privately, we view this as a non-issue.  The Area Leader is the 
one advertising both the Area SID sub-TLV and the Proxy LSP. If there’s a 
coding error, there’s a coding error. There is a single source of truth (the 
Area Leader’s config) and we cannot protect against every possible coding 
error.  Reconciling the prefix with a separate advertisement has a non-trivial 
chance of being broken too, and IMHO, much larger.

[Les2:] You can define the advertisements in a way which reduces the 
possibility of ambiguity – which seems like a good thing to me.
And rest assured that you will be asked by someone to define the expected 
behavior when there is an inconsistency. 
Since prefix SID and Prefix reachability are directly related in forwarding, it 
makes far more sense to me to have those two together.
If you find correlating information in two different TLVs too challenging, you 
could opt for a new bit in the prefix attributes sub-TLV to identify a prefix 
as an “Area Prefix”. Then you would not need any additional info advertised in 
the Area Proxy TLV at all.


 There then remains the question as to whether the “Area Prefix” is anycast or 
unicast i.e., is it common to all IERs or is it unique to whomever gets elected 
Area Leader?


Does it matter? We have no clear semantics for this prefix. A difference that 
makes no difference is no difference.

[Les:] This question needs to be directed at those who prefer the Area Prefix 
approach. It matters as it impacts configuration and advertisement semantics. 
An anycast prefix is NOT a Node Prefix.
And it impacts how traffic is forwarded into the area.

   Les

Tony

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


Re: [Lsr] draft-ietf-lsr-isis-area-proxy-02

2020-08-05 Thread Les Ginsberg (ginsberg)
Acee -

From: Acee Lindem (acee) 
Sent: Wednesday, August 05, 2020 12:31 PM
To: Tony Li ; Bruno Decraene 
Cc: Les Ginsberg (ginsberg) ; lsr@ietf.org
Subject: Re: [Lsr] draft-ietf-lsr-isis-area-proxy-02

Hi Tony, Bruno, Les,

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of Tony 
Li mailto:tony1ath...@gmail.com>>
Date: Tuesday, August 4, 2020 at 11:26 AM
To: Bruno Decraene mailto:bruno.decra...@orange.com>>
Cc: "Les Ginsberg (ginsberg)" mailto:ginsb...@cisco.com>>, 
"lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>
Subject: Re: [Lsr] draft-ietf-lsr-isis-area-proxy-02


Hi Bruno,



[Bruno] Agreed so far.
Do we agree that draft-ietf-lsr-isis-area-proxy uses the SID/Label sub-TLV? We 
both agree that this sub-TLV has no mention of the global flag nor the routing 
algoto be used.


So far, we do NOT have agreement on that.  Your argument yesterday (backed by 
Robert) is pretty compelling: go ahead and assign a prefix and now the Area SID 
may be advertised as a Node SID in the Proxy LSP. If we take that direction, 
this discussion is moot.

Why wouldn’t we take this approach? Since the border routers are abstracting 
the area as a node, why wouldn’t we do the same for the Node-SID?

[Les:] The original idea proposed by the draft authors was to have a SID which 
could be used to forward traffic to the inside area. Conceptually this does not 
require a prefix – and the encodings currently defined in the draft reflect 
this.

Bruno has since commented that he prefers a prefix to be associated with the 
Area SID.
I agree this is a viable approach, but if we go that way then I think what is 
needed is:

a)Advertise the “Area Prefix” in the Area Proxy TLV – much as we do a router-id 
today in the Router-ID TLV.
b)The remaining info (reachability and SID) can then be provided using existing 
Prefix Reachability advertisements – no need for new sub-TLV for “Area SID”. 
This eliminates any potential issues if the SID advertised by “Area SID 
sub-TLV” were to differ from the SID advertised in Prefix Reachability for the 
same prefix.

There then remains the question as to whether the “Area Prefix” is anycast or 
unicast i.e., is it common to all IERs or is it unique to whomever gets elected 
Area Leader?

   Les

Thanks,
Acee

Tony

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


Re: [Lsr] draft-ietf-lsr-isis-area-proxy-02

2020-08-04 Thread Les Ginsberg (ginsberg)
Bruno -

Please see inline.

From: Lsr  On Behalf Of bruno.decra...@orange.com
Sent: Tuesday, August 04, 2020 5:45 AM
To: lsr@ietf.org
Subject: [Lsr] draft-ietf-lsr-isis-area-proxy-02

Hi,

I may be missing something but the SR Binding SID TLV extension  is not clear 
to me.


  1.  It does not seem compliant with RFC 8667

Draft says that the advertisement has: T-flag set, M & A flags cleared, 
SID/Label sub-TLV present, Prefix-SID sub-TLV NOT present


The following extensions to the Binding TLV are defined in order to

   support Area SID:



  A new flag is defined:



 T-flag: The SID directs traffic to an area.  (Bit 5)



 When T-flag is set:



M and A flag MUST be clear



Range and Prefix are ignored



  Section 2.4.4 of RFC 
8667 is altered to say:



 "The Prefix-SID sub-TLV MUST be present in the SID/Label

 Binding TLV when the M-Flag and T-flag are both clear.  The

 Prefix-SID sub-TLV MUST NOT be present when either the M-Flag

 or T-flag are set."



  Regarding the SID/Label sub-TLV Section 2.4.5 of RFC 
8667 is

  altered to say:



 "It MUST be present in the SID/Label Binding TLV when either

 the M-Flag or T-flag is set in the Flags field of the parent

 TLV."

https://tools.ietf.org/html/draft-ietf-lsr-isis-area-proxy-02#page-14



By definition, legacy L2 external  node will support vanilla RFC 8667, which 
says:
"The Prefix-SID sub-TLV MUST be present in the SID/Label Binding TLV when the 
M-Flag is clear."
https://www.rfc-editor.org/rfc/rfc8667.html#name-sid-label-binding-tlv

So it seems that the extension violates the above MUST in RFC8667, as regarding 
the Prefix-SID sub-TLV

  *   Area proxy says "MUST NOT be present" (as T-flag is set)
  *   RFC 8667 says "MUST be present" (as M-flag is cleared)


In addition to the above, legacy node _will_ interpret the 'Range' and 'Prefix' 
fields. So there is probably a need to specify which values need to be 
advertised for those legacy nodes. A priori range would be one as a single SID 
is advertised. Prefix seems more problematic as you need to find an IP prefix 
to advertise. And please let's avoid SID conflict and Prefix conflict...
[Les:] Format of the Binding TLV when the new T-bit is set is similar to the 
format when the M-bit is set in that Prefix-SID sub-TLV is NOT present.
A legacy node parsing the Binding TLV would be looking for the Prefix-SID 
sub-TLV (M-bit NOT set) and would not find it. The contents of the Binding TLV 
would therefore be unusable to a legacy node.
The correct behaviour for a legacy node would be to (optionally) report an 
"invalid TLV" and to ignore the TLV.



  1.  It's not clear to me whether the segment/SID is global or local.
As per my understanding of the draft-ietf-lsr-isis-area-proxy use case, the 
area-proxy SID would be global (in the external L2): "Area SID which will 
direct traffic to any of the Inside Edge Routers."

But the SID/Label Sub-TLV used by area-proxy has no flag (L-flag) indicating 
whether the SID is global or local. One could argue that if it carries a label 
it's a local SID and if it carries and index it's a global SID. But this has 
not been specified.
It has also no "algorithm" indicating how it needs to be routed global, so at 
minimum would not work with different routing algo/flex algo.
I'm not seeing in RFC 8402 or 8667 any text saying that such SID would be 
global hence globally routed in the L2 domain. (To me, this IS-IS SID was 
local, but arguably also can't find text stating this).

[Les:] There is a subtle difference between the Prefix-SID sub-TLV as defined 
in https://www.rfc-editor.org/rfc/rfc8667.html#section-2.1 and the SID/Label 
sub-TLV defined in https://www.rfc-editor.org/rfc/rfc8667.html#SIDLABELSUBTLV

The Prefix-SID sub-TLV has a flags field which includes V-bit/L-bit to indicate 
whether the variable length field which follows is a 3 byte label (both bits 
set to 1) or a 4 byte index (both bits set to 0).

The SID/Label sub-TLV has no flags field. The length of the sub-TLV indicates 
whether the advertised value has is a label (length = 3)  or an index (length = 
4).

I see no issue here.

I would also point out that the new Area Proxy SID sub-TLV ( 
https://tools.ietf.org/html/draft-ietf-lsr-isis-area-proxy-02#section-4.3.2 ) 
does include V/L bits - similar to the Prefix-SID sub-TLV.


At minimum, area-proxy would need to specify whether the SID is global and 
local. And if global, with which hard coded algorithm it is routed. (I would 
assume "0")

[Les:]Just as the Mirror SID has no algorithm associated, neither does the Area 
SID.
If you feel that is an issue, please expand on how you intend to use an 
algorithm specific Area SID.
Thus far you seem more inclined to use an anycast  Prefix-SID, so I am not 
clear on what you think is 

Re: [Lsr] New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt

2020-08-03 Thread Les Ginsberg (ginsberg)
Robert –

You need to allow that not everything in the world is identified by an IP/IPv6 
address.

If you want an IP address shared by all nodes in an area there is already a 
mean of doing that: assign a common anycast address on all nodes.

The value add (if there is any) of an Area SID is that I don’t have to assign 
an anycast address to all nodes. I can associate the SID with an identifier 
that is already shared and known by all nodes in the area.
If you don’t see that as worthwhile, fine, let’s abandon the Area SID idea.

   Les



From: Robert Raszuk 
Sent: Monday, August 03, 2020 10:47 AM
To: Les Ginsberg (ginsberg) 
Cc: bruno.decra...@orange.com; tony...@tony.li; lsr@ietf.org
Subject: Re: [Lsr] New Version Notification for 
draft-ietf-lsr-isis-area-proxy-02.txt

Hi Les,

Well I am talking about IP routable identifier which I can place on the front 
of the packet and which can assure that the packet will arrive at given area.

Then Area SID becomes analogy of Node SID :)

Thx

On Mon, Aug 3, 2020 at 7:40 PM Les Ginsberg (ginsberg) 
mailto:ginsb...@cisco.com>> wrote:
Robert –

Both OSPF and IS-IS have area identifiers which are advertised.
Why would we need to invent another identifier for an area?

   Les


From: Robert Raszuk mailto:rob...@raszuk.net>>
Sent: Monday, August 03, 2020 10:31 AM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Cc: bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>; 
tony...@tony.li<mailto:tony...@tony.li>; lsr@ietf.org<mailto:lsr@ietf.org>
Subject: Re: [Lsr] New Version Notification for 
draft-ietf-lsr-isis-area-proxy-02.txt

Les,

> But currently the draft is defining a SID which is NOT associated with a 
> prefix.
+
> But if the proposal is to use a SID associated with a prefix then I see no 
> need to invent a new SID advertisement.

How about we first define an "Area Prefix" (IP address being a property of an 
area) then assign SID to it ?

- - -

How odd it may sound I would like to still be able to direct traffic (read ip 
tunnel) traffic to an area without any SID.

Thx,
R.

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


Re: [Lsr] New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt

2020-08-03 Thread Les Ginsberg (ginsberg)
Robert –

Both OSPF and IS-IS have area identifiers which are advertised.
Why would we need to invent another identifier for an area?

   Les


From: Robert Raszuk 
Sent: Monday, August 03, 2020 10:31 AM
To: Les Ginsberg (ginsberg) 
Cc: bruno.decra...@orange.com; tony...@tony.li; lsr@ietf.org
Subject: Re: [Lsr] New Version Notification for 
draft-ietf-lsr-isis-area-proxy-02.txt

Les,

> But currently the draft is defining a SID which is NOT associated with a 
> prefix.
+
> But if the proposal is to use a SID associated with a prefix then I see no 
> need to invent a new SID advertisement.

How about we first define an "Area Prefix" (IP address being a property of an 
area) then assign SID to it ?

- - -

How odd it may sound I would like to still be able to direct traffic (read ip 
tunnel) traffic to an area without any SID.

Thx,
R.

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


Re: [Lsr] New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt

2020-08-03 Thread Les Ginsberg (ginsberg)
Bruno –

Inline.

From: bruno.decra...@orange.com 
Sent: Monday, August 03, 2020 8:52 AM
To: Les Ginsberg (ginsberg) ; tony...@tony.li
Cc: lsr@ietf.org
Subject: RE: [Lsr] New Version Notification for 
draft-ietf-lsr-isis-area-proxy-02.txt

Les,


From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Monday, August 3, 2020 5:22 PM
To: DECRAENE Bruno TGI/OLN 
mailto:bruno.decra...@orange.com>>; 
tony...@tony.li<mailto:tony...@tony.li>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>
Subject: RE: [Lsr] New Version Notification for 
draft-ietf-lsr-isis-area-proxy-02.txt

Bruno –

The concept of “Area SID” – at least to me – is “please forward to any node in 
the Area advertising the Area SID”.
[Bruno] How is that different from “anycast”? i.e. your option b?

[Les:] It would differ because it would not be associated with a prefix but 
with an area. Any node in the area could make use of the SID.

You, however, seem to be asking for either:

a)The node originating the Proxy LSP to advertise a Node SID for a loopback 
address on that node

OR

b)The node originating the Proxy LSP to advertise an anycast SID which is 
shared by the IERs in the Proxy Area

To do so, it seems to me we need not invent a new type of SID, we can simply 
advertise using the existing Prefix Reachability/Prefix SID sub-TLVs.

So it seems you are not interested in an “Area SID”.

Can you please clarify?

[Bruno] I’m interested in the forwarding behavior defined in the draft: “all of 
the Inside Edge Nodes […] should consume this SID at forwarding time.” How we 
call this, I don’t really care. Could be area SID, or proxy SID or anycast SID… 
but for the external L2 nodes, there is no anycast behavior: just one single 
node/LSP/SID, so calling it anycast could be strange.

[Les:] Agreed – which is why a new type of SID was chosen.

For me, the reason to invent a new type of SID and new forms of SID 
advertisements is because we were defining a SID with new functionality i.e., 
send this to another area – which entry point into the area is used should not 
matter.
[Bruno] From the external L2 nodes, the “area” is seen as a single node. “which 
entry point into the area is used ” equals “which interface of the (proxy) node 
is used. I’m not sure that we need a new concept.
From within area internal nodes, we do see the detail of the topology and need 
to advertise & agree on the area SID.
[Les:] You are correct in terms of usage within Area Proxy.
But I was allowing that other use cases for Area SID might be defined in the 
future and the abstraction that is present in Area Proxy would not be relevant.
But if the proposal is to use a SID associated with a prefix then I see no need 
to invent a new SID advertisement.

This seems like a property which might be useful – and might be useful outside 
of Area Proxy use cases as well. If however, we (the WG) see no need for this 
type of SID then we should remove these definitions and simply use the existing 
Prefix-SID advertisements.
[Bruno] The property is useful. I’m fine with the name & encoding in current 
and past draft.
I’m simply raising the point that this new advertisement will not be understood 
by vanilla external L2 nodes. Hence unless you upgrade all those external 
nodes, you have regression in the network, at least in the following use case: 
replacing a big chassis with a set of smaller nodes grouped in one area.

[Les:] A fair point. But currently the draft is defining a SID which is NOT 
associated with a prefix. And you are correctly pointing out that this has an 
impact on both the IER nodes (which MUST support the Area Proxy extensions) and 
the external L2 nodes – which theoretically need not be upgraded at all.
If the impact on external nodes is unacceptable, then a prefix-SID 
advertisement MUST be used. Any new advertisement – whether associated with a 
prefix or not – would raise the same interoperability issue you mention.


One other comment regarding your reference to 
https://tools.ietf.org/html/draft-ietf-spring-mpls-anycast-segments-03 .

https://tools.ietf.org/html/draft-ietf-lsr-isis-area-proxy-02#section-2.1 
already specifies that all inside nodes MUST have the “same SRGB”. So I do not 
see that your reference is relevant – unless you are proposing to change that.
[Bruno] You can safely forget about this reference.
I was trying to say that anycast SID is not new. And no, I’m not proposing to 
change that all node must use the same SRGB. (that been said, sometimes you 
need to use the implementation that are on the market. The concept of index + 
SRGB has only been designed because some nodes could not support a common SRGB.)
[Les:] Understood. But there is a reason why the anycast draft has not been 
progressing. 

  Les

--Bruno

   Les

From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>
Sent: Monday, August 03, 2020 1:10 AM
To: tony...@tony.li<mailto:ton

Re: [Lsr] New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt

2020-08-03 Thread Les Ginsberg (ginsberg)
Bruno –

The concept of “Area SID” – at least to me – is “please forward to any node in 
the Area advertising the Area SID”.

You, however, seem to be asking for either:

a)The node originating the Proxy LSP to advertise a Node SID for a loopback 
address on that node

OR

b)The node originating the Proxy LSP to advertise an anycast SID which is 
shared by the IERs in the Proxy Area

To do so, it seems to me we need not invent a new type of SID, we can simply 
advertise using the existing Prefix Reachability/Prefix SID sub-TLVs.

So it seems you are not interested in an “Area SID”.

Can you please clarify?

For me, the reason to invent a new type of SID and new forms of SID 
advertisements is because we were defining a SID with new functionality i.e., 
send this to another area – which entry point into the area is used should not 
matter. This seems like a property which might be useful – and might be useful 
outside of Area Proxy use cases as well. If however, we (the WG) see no need 
for this type of SID then we should remove these definitions and simply use the 
existing Prefix-SID advertisements.

One other comment regarding your reference to 
https://tools.ietf.org/html/draft-ietf-spring-mpls-anycast-segments-03 .

https://tools.ietf.org/html/draft-ietf-lsr-isis-area-proxy-02#section-2.1 
already specifies that all inside nodes MUST have the “same SRGB”. So I do not 
see that your reference is relevant – unless you are proposing to change that.

   Les

From: Lsr  On Behalf Of bruno.decra...@orange.com
Sent: Monday, August 03, 2020 1:10 AM
To: tony...@tony.li
Cc: lsr@ietf.org
Subject: Re: [Lsr] New Version Notification for 
draft-ietf-lsr-isis-area-proxy-02.txt

Hi Tony,

From: Tony Li [mailto:tony1ath...@gmail.com] On Behalf Of 
tony...@tony.li
Subject: Re: [Lsr] New Version Notification for 
draft-ietf-lsr-isis-area-proxy-02.txt


Hi Bruno,

Thank you for the clarification.
[Bruno] You are very welcome. Thank you for listening.

 I understand completely what you’re trying to do and I agree that it’s 
valuable.

The downside of your approach is that the Area Leader will now need 
configuration of a new prefix to advertise as the Node SID.
[Bruno] Agreed.
I believe that the Area SID equally needs to be configured, so configuration is 
required in all cases. Given this, the extra effort seems marginal to me.
Not unthinkable.

What do the Inside Nodes do with this prefix, if anything?
[Bruno] good question. 2 options:

  *   Drop traffic to control plane (i.e. IP is not supposed to be used)
  *   Nothing really new: it’s an anycast IP/SID. There is even a draft for the 
more complex case where the SRGB is different on the anycast nodes . 
https://tools.ietf.org/html/draft-ietf-spring-mpls-anycast-segments-03

Regards,
--Bruno

I am open to this approach, either in addition to, or instead of the approach 
currently in the draft.  I await feedback from the WG.

Regards,
Tony



p.s. The fact that the node SID requires a prefix is just a side effect of the 
IP address space excluding hosts from addressing. The one, true
way within IS-IS is the system ID, a separate, independent namespace for nodes 
that simply avoids ALL of these problems.  If RFC 8667
encoded node SIDs as their own TLV without the unnecessary prefix that OSPF’s 
style mandates, this would be trivial.




On Jul 31, 2020, at 2:24 AM, 
bruno.decra...@orange.com wrote:

Hi Tony,

Thank you for your reply.
Top posting the description of the use case that I have in mind.

>  First off, the Area SID is 100% optional. If you choose not to use it, then 
> the Proxy LSP should be 100% compatible with a standard L2 node.
Good. But I think that the idea of the Area SID is a good one, and I choose to 
use it. Then I’d like to get it for free ;-)


Please fine below a network topology:



My understanding is that the L2 topology seen by node S is the following


P been the Proxy LSP.

S wants to protect from the failure of link S-C by using TI-LFA. For the 
destination C, it would push 2 (*) node SIDs: P, C
So S needs a Node SID for P:
a)  If P does not redistribute the Node SIDs from its area members, P does 
not seem to advertise any node SID currently. There is a chance that C’s TI-LFA 
implementation would not like it and hence would not install protection for 
this (link, destination)
b)  If P redistributes the Node SIDs from its area members, P advertises 3 
node SIDs (1,2, 3). S could pick any one at random. If it picks 3, the 
forwarding path would be S, A,B, 1, 2, 3, 2 , 1, C,  which is suboptimal.

Two solutions I could think of:
- when redistributing the node SID, P changes the SIDs values and replace them 
with the value of the Area SID. This works for this use case, but it is 
borderline. (e.g. if some a L2 node learn both the original and ‘NATed’ SID, we 
have some SID conflict. Let’s try to avoid this subject).
- P could advertise its own Node-SID with the Area SID 

Re: [Lsr] draft-ietf-lsr-isis-area-proxy-02

2020-07-30 Thread Les Ginsberg (ginsberg)
Bruno -

Regarding the A-flag...
It may not matter much whichever way we decide - but the A-flag was invented 
because at the time (prior to RFC 7794) there was no way to determine from 
looking at a prefix reachability advertisement whether it was originated by the 
advertising node or had been leaked from another area.
If RFC 7794 had existed when the SR-MPLS draft was first being developed there 
would have been no need for the A-flag.

As regards Area-SID, there is no prefix to be leaked - so I do not see that the 
A-flag serves any useful purpose.
If you want it to be set just to be consistent with its use in PSP logic - OK - 
but I think this is unnecessary.

   Les


From: Lsr  On Behalf Of bruno.decra...@orange.com
Sent: Thursday, July 30, 2020 9:46 AM
To: lsr@ietf.org
Subject: [Lsr] draft-ietf-lsr-isis-area-proxy-02

Hi authors,

Please find below some feedback for information. Feel free to ignore.

4.4.13.  The Area SID  
https://tools.ietf.org/html/draft-ietf-lsr-isis-area-proxy-02#section-4.4.13

   "The following extensions to the Binding TLV are defined in order to
   support Area SID:

  A new flag is defined:

 T-flag: The SID directs traffic to an area.  (Bit 5)

 When T-flag is set:

M and A flag MUST be clear"

My understanding is that the Area SID is installed in the FIB of all inside 
edge routers. Based on this, I would argue that the  A flag could and SHOULD be 
set

https://www.rfc-editor.org/rfc/rfc8667.html#name-flags-2
"A-Flag: Attached Flag. The originator of the SID/Label Binding TLV MAY set the 
A bit in order to signal that the prefixes and SIDs advertised in the SID/Label 
Binding TLV are directly connected to their originators."
---
4.4.7.  Reachability TLVs   
https://tools.ietf.org/html/draft-ietf-lsr-isis-area-proxy-02#section-4.4.7


   If the Inside Area supports Segment Routing and the selected TLV

   includes a Prefix Segment Identifier sub-TLV (3) 
[RFC8667], then the

   sub-TLV SHOULD be copied as well. The P-Flag SHOULD be set in the

   copy of the sub-TLV to indicate that penultimate hop popping SHOULD

   NOT be performed for this prefix.  The E-Flag SHOULD be reset in the

   copy of the sub-TLV to indicate that an explicit NULL is not

   required. The R-Flag SHOULD simply be copied.




May be it would be more generic to say that those prefix are handled as 
redistributed prefix.
https://www.rfc-editor.org/rfc/rfc8667.html#section-2.1.2 and 
https://www.rfc-editor.org/rfc/rfc8667.html#EANDPFLAGS already defines the 
behaviour for respectively Prefix-SID propagation and P and E flags handling, 
so probably no need to re-specify:
When propagating (from either Level-1 to Level-2 or Level-2 to Level-1) a 
reachability advertisement originated by another IS-IS speaker, the router MUST 
set the P-Flag and MUST clear the E-Flag of the related Prefix-SIDs.
That would also cover for the handling of Prefix Attribute Flags sub-TLV 
RFC7794.

I would argue that the R-Flag MUST be set (rather than simply copied). As per 
https://www.rfc-editor.org/rfc/rfc8667.html#name-r-flag-and-n-flag

Best regards,
--Bruno



_



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

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

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

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



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

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

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

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

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


Re: [Lsr] Fwd: New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt

2020-07-30 Thread Les Ginsberg (ginsberg)
Bruno –

One of the reasons to use the Binding TLV to advertise the Area SID was that it 
has been suggested that other use cases for Area SID – unrelated to Area Proxy 
– may come along.
Therefore tying the advertisement to an Area Proxy TLV seems not the best 
option if we want to allow for these other use cases (admittedly currently 
unknown).

Thoughts??

   Les


From: Lsr  On Behalf Of bruno.decra...@orange.com
Sent: Thursday, July 30, 2020 9:22 AM
To: tony...@tony.li; lsr@ietf.org
Subject: Re: [Lsr] Fwd: New Version Notification for 
draft-ietf-lsr-isis-area-proxy-02.txt

Hi Tony,

Thanks for the updated draft.

“ The Area SID Sub-TLV allows the Area Leader to advertise a SID that
   represents the entirety of the Inside Area to the Outside Area.  This
   sub-TLV is learned by all of the Inside Edge Nodes who should consume
   this SID at forwarding time.”

Excellent, from my perspective.


  *   - The Area Segment SID TLV has been replaced by extending the Binding SID 
TLV.


“When SR is enabled, it may be useful to advertise an Area SID which

   will direct traffic to any of the Inside Edge Routers.  The Binding/

   MT Binding TLVs described in RFC 8667 Section 
2.4 are used to

   advertise such a SID.



   The following extensions to the Binding TLV are defined in order to

   support Area SID:



  A new flag is defined:



 T-flag: The SID directs traffic to an area.  (Bit 5) »




This works.
However I may have a different deployment environment than the one you have in 
mind. Even if those issues may be mine, allow me to share them with you.
In many WAN networks than I’m used to, there are routers from different 
vendors, platforms, software, generations. Requiring all those routers to 
support the new Binding SID TLV T-Flag will take time. Some platform may even 
be end of engineering (evolutions) so would never support such new features.
In my environment, ideally, I would prefer a solution which do not require any 
new feature on external L2 nodes, while all existing L2 features keep working, 
in particular SR, SR-TE, TI-LFA, SR uloop avoidance… This would require the 
Proxy LSP to be not (significantly) different than the LSP of a vanilla L2 
node. For SR, I think that this would require this Proxy LSP to advertise a 
Prefix/Node SID with the Area SID attached. One drawback is that a Node-SID is 
advertised with an IP address that would need to be provisioned.

Both approaches are not mutually exclusives. I’d be happy enough with an option 
for the Proxy LSP to advertise an Area Node SID with the Area SID attached.

Finally, there is no requirement to make me happy ;-) . The above could also be 
a local implementation knob not mentioned in the draft.

Thanks,
--Bruno

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of 
tony...@tony.li
Sent: Sunday, July 26, 2020 3:49 AM
To: lsr@ietf.org
Subject: [Lsr] Fwd: New Version Notification for 
draft-ietf-lsr-isis-area-proxy-02.txt


Hi folks,

This version of the draft reflects major changes in line with the discussions 
that we’ve had so far.

To wit:
- The Area Proxy TLV is now moved to be in L2 LSPs and indicates that the 
advertising node is an Inside Node and Area Proxy is active.
- The Area Proxy Router Capability has been removed.
- The Inside Node TLV has been removed.
- The Area Segment SID TLV has been replaced by extending the Binding SID TLV.

We know that some folks disagree with this last point, so we welcome discussion 
on this. We would like to reach consensus as quickly as possible.

Thanks,
Tony



Begin forwarded message:

From: internet-dra...@ietf.org
Subject: New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt
Date: July 25, 2020 at 6:46:05 PM PDT
To: "Vivek Ilangovan" mailto:ilango...@arista.com>>, 
"Sarah Chen" mailto:sarahc...@arista.com>>, "Gyan S. 
Mishra" mailto:gyan.s.mis...@verizon.com>>, "Gyan 
Mishra" mailto:gyan.s.mis...@verizon.com>>, "Yunxia 
Chen" mailto:sarahc...@arista.com>>, "Tony Li" 
mailto:tony...@tony.li>>


A new version of I-D, draft-ietf-lsr-isis-area-proxy-02.txt
has been successfully submitted by Tony Li and posted to the
IETF repository.

Name: draft-ietf-lsr-isis-area-proxy
Revision: 02
Title:Area Proxy for IS-IS
Document date:  2020-07-25
Group: lsr
Pages:  20
URL:
https://www.ietf.org/internet-drafts/draft-ietf-lsr-isis-area-proxy-02.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-area-proxy/
Htmlized:   https://tools.ietf.org/html/draft-ietf-lsr-isis-area-proxy-02
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-area-proxy
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-isis-area-proxy-02

Abstract:
  Link state routing protocols have hierarchical abstraction 

Re: [Lsr] I-D Action: draft-ietf-lsr-isis-invalid-tlv-03.txt

2020-07-26 Thread Les Ginsberg (ginsberg)
This update addresses review comments from:

Murray Kucherawy
Roman Danyliw
Benjamin Kaduk
Rob Wilton

   Les


> -Original Message-
> From: Lsr  On Behalf Of internet-dra...@ietf.org
> Sent: Sunday, July 26, 2020 6:04 PM
> To: i-d-annou...@ietf.org
> Cc: lsr@ietf.org
> Subject: [Lsr] I-D Action: draft-ietf-lsr-isis-invalid-tlv-03.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   : Invalid TLV Handling in IS-IS
> Authors : Les Ginsberg
>   Paul Wells
>   Tony Li
>   Tony Przygienda
>   Shraddha Hegde
>   Filename: draft-ietf-lsr-isis-invalid-tlv-03.txt
>   Pages   : 9
>   Date: 2020-07-26
> 
> Abstract:
>Key to the extensibility of the Intermediate System to Intermediate
>System (IS-IS) protocol has been the handling of unsupported and/or
>invalid Type/Length/Value (TLV) tuples.  Although there are explicit
>statements in existing specifications, deployment experience has
>shown that there are inconsistencies in the behavior when a TLV which
>is disallowed in a particular Protocol Data Unit (PDU) is received.
> 
>This document discusses such cases and makes the correct behavior
>explicit in order to ensure that interoperability is maximized.
> 
>This document updates RFC5305 and RFC6232.
> 
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-invalid-tlv/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-lsr-isis-invalid-tlv-03
> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-invalid-tlv-03
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-isis-invalid-tlv-03
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> 
> ___
> 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-igp-extensions-ifit-00.txt

2020-07-17 Thread Les Ginsberg (ginsberg)
Robin/Yali –

The argument here is circular.
You are saying “if the IGPs advertised ifit information/capability then it 
would be used”.

Sure.

But the question that was discussed three months back was whether IGPs were the 
right vehicle to advertise this information or whether it should be done in 
other ways.

Please reread the thread:  
https://mailarchive.ietf.org/arch/browse/lsr/?gbt=1=5GdFCy7zg8eCIGvQZpmAbOtrTjQ

   Les


From: Lizhenbin 
Sent: Friday, July 17, 2020 6:12 AM
To: Les Ginsberg (ginsberg) ; lsr@ietf.org
Cc: wangyali 
Subject: 答复: New Version Notification for 
draft-wang-lsr-igp-extensions-ifit-00.txt


Hi Les,

I add one more case for your reference. There are several SR-Policy/SR-Tunnel 
implementations which depend on the configuration on the devices other than the 
controller. If the IFIT capability is enabled for these SR-Policy/Tunnels, IGP 
will be helpful for the ingress node to learn the capabilities of other nodes 
along the SR-Policy/Tunnel.





Best Regards,

Robin










发件人: Lsr [lsr-boun...@ietf.org] 代表 wangyali [wangyal...@huawei.com]
发送时间: 2020年7月17日 20:19
收件人: Les Ginsberg (ginsberg); lsr@ietf.org<mailto:lsr@ietf.org>
主题: Re: [Lsr] New Version Notification for 
draft-wang-lsr-igp-extensions-ifit-00.txt
Dear Les,

Many thanks for your quick feedback. We are very appreciate all of your 
insightful comments and advices. ☺

Please let me clarify the one of requirements is that the ingress node cannot 
insert IFIT instruction for packets going into a path unless the egress node 
signals its capability of processing IFIT data fields.

Actually, taking your suggestions and those of others into account, we tried to 
use NETCONF for query node capability.  However, in the scenario of SR-BE, the 
ingress node controls a path along which packets are transmitted, which is not 
included in a centralized controller. Therefore, extensions to IGP for node’s 
capability advertisement is considered as an efficient way but NETCONF doesn't 
work.

Best regards,
Yali

From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Friday, July 17, 2020 5:25 AM
To: wangyali mailto:wangyal...@huawei.com>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Subject: RE: New Version Notification for 
draft-wang-lsr-igp-extensions-ifit-00.txt


Yali -



While it is kind of you to acknowledge many of us for our comments, in many 
cases (myself included) what we told you is that this does not belong in the 
IGPs.

Putting out a new draft which continues to push for advertising ifit in IGPs 
(even if in different TLVs) does not indicate that you are heeding our message. 






   Les





> -Original Message-

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

> Sent: Thursday, July 16, 2020 8:20 AM

> To: lsr@ietf.org<mailto:lsr@ietf.org>

> Subject: [Lsr] FW: New Version Notification for draft-wang-lsr-igp-

> extensions-ifit-00.txt

>

> Dear LSR WG,

>

> We've uploaded a new revision of draft-wang-lsr-igp-extensions-ifit-00 to

> replace draft-wang-lsr-ifit-node-capability-advertisement. In this new

> revision, Node and Link Attribute TLVs are extended to IGP for signaling the

> supported IFIT capability of egress and/or intermediate nodes to the ingress

> nodes.

>

> The changes in this revision are:

>

> 1. added Link Attribute TLVs extension to IGP to signal IFIT Capability at 
> link

> granularity.

> 2. updated Application section, which illustrates such advertisements would

> helpful for avoiding the leak of IFIT-specific header and metadata, as well 
> as,

> for ingress routers to gather each router's IFIT capability for achieving the

> computation of TE paths or loose TE paths that be able to fulfill the 
> visibility of

> on-path OAM data.

> 3. updated Acknowledgements sections, in which, the authors would like to

> thank Acee Lindem, Christian Hopps, Robert Raszuk, Les Ginsberg, Jeff

> Tantsura, Rakesh Gandhi, Tony Li and Greg Mirsky for the comments.

> 4. adding China Telecom into the author list.

>

> We are looking forward to hearing your feedback and comments, and try to

> achieve consensus.

>

> Thanks,

> Yali

>

>

> -Original Message-

> From: internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> 
> [mailto:internet-dra...@ietf.org]

> Sent: Monday, July 13, 2020 9:15 PM

> To: Tianran Zhou mailto:zhoutian...@huawei.com>>; 
> wangyali

> mailto:wangyal...@huawei.com>>; Huanan Chen 
> mailto:chenhu...@chinatelecom.cn>>;

> Liumin (Lucy) mailto:lucy.liu...@huawei.com>>; Ran 
> Pang

> mailto:pang...@chinaunicom.cn>>; Liumin (Lucy) 
> mailto:lucy.liu...@huawei.com>>

> Subject: New Version Notification for draft-wang-lsr-igp-extensions-ifit-

> 00.txt

>

>


Re: [Lsr] Request WG adoption of TTZ

2020-07-16 Thread Les Ginsberg (ginsberg)
Huaimo -

I am not going to comment on the history issues - though I understand why that 
is of significance to you.

Otherwise, I don't think you are appreciating the key point many of us are 
making - which is that we do not need to introduce a new concept "zone" (subset 
of an area).
It is sufficient to operate on an area.

  "reducing the service interruption, making operations to be simple, and 
so on"

does not require introduction of zones.  We can already do so using areas - 
including merging/splitting of an area.

The argument then against moving forward with both Area Proxy and TTZ is that 
they are redundant.

Until you demonstrate something compelling which cannot be done with an area 
but can be done with a zone, I simply do not see why we need to introduce zones 
to the protocol.

Les



From: Lsr  On Behalf Of Huaimo Chen
Sent: Thursday, July 16, 2020 12:16 PM
To: Acee Lindem (acee) 
Cc: lsr@ietf.org
Subject: Re: [Lsr] Request WG adoption of TTZ

Hi Acee,

> Conversely, now that the IS-IS TTZ has adopted the Area Proxy mechanisms of 
> having an Area/Zone leader generate a single LSP representing the Area/Zone, 
> the two proposals are very similar.

[HC]:  It looks like the other way around. In 2013, IS-IS TTZ .00 draft 
describes the mechanism of having a Zone DR (called TTZ-DR) to generate a 
single LSP for representing the single node abstracted from the Zone. DR and 
Leader are just two different names of the same node. In 2018, Area Proxy .00 
draft presents the mechanism of having an Area leader to generate a single LSP 
representing the node abstracted from the Area. There are some big differences 
between IS-IS TTZ and Area Proxy even though they are similar.

>I think that the two proposals that have already been adopted as experimental 
>are VERY different in the way they solve the problem of better LSDB 
>scalability across an IS-IS routing domain.

[HC]: The three proposals (the two adopted as experimental recently and IS-IS 
TTZ) are all very different even though they solve the same problem for better 
LSDB scalability. It is would be reasonable and beneficial to allow IS-IS TTZ 
to move forward also as experimental.

>I agree with Henk, Les, and John that the purported advantages of TTZ are not 
>required. These advantages being arbitrary abstraction boundaries and a 
>description of the transition mechanisms.

[HC]: It seems that reducing the service interruption, making operations to be 
simple, and so on are expected by users in general.

Best Regards,
Huaimo

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of Uma 
Chunduri mailto:umac.i...@gmail.com>>
Sent: Wednesday, July 15, 2020 1:38 PM
To: Acee Lindem (acee) mailto:a...@cisco.com>>
Cc: lsr@ietf.org mailto:lsr@ietf.org>>
Subject: Re: [Lsr] Request WG adoption of TTZ

Acee,

In-line ..

On Wed, Jul 15, 2020 at 10:14 AM Acee Lindem (acee) 
mailto:a...@cisco.com>> wrote:

Speaking as WG member...



See inline.



From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of Uma 
Chunduri mailto:umac.i...@gmail.com>>
Date: Wednesday, July 15, 2020 at 12:52 PM
To: Henk Smit mailto:henk.i...@xs4all.nl>>
Cc: "l...@ietf...org" mailto:lsr@ietf.org>>, 
Huaimo Chen mailto:huaimo.c...@futurewei.com>>
Subject: Re: [Lsr] Request WG adoption of TTZ







On Wed, Jul 15, 2020 at 5:22 AM Henk Smit 
mailto:henk.i...@xs4all.nl>> wrote:

Huaimo Chen wrote on 2020-07-14 06:09:

>  2). IS-IS TTZ abstracts a zone to a single node. A zone is any target
> block or piece of an IS-IS area, which is to be abstracted. This seems
> more flexible and convenient to users.

I don't agree that this convenience is really beneficial.

I actually think this convenience is a downside.



I actually think not  having more configuration across the network to enable a 
new feature is more useful even if

you don't do this operation every single day (especially if you want to roll 
back).





Link-state protocols are not easy to understand. And we already
have the misfortune that IS-IS and OSPF use different names for things.
Adding the new concept of a "zone", while we already have the
concept of an area makes things only more complex.



Agree in general.



I would say this is no more complex than what has been adopted already or the 
slew of proposals we have been seeing here.



I too think as some other said we should have ideally adopted only one proposal 
by merging whatever possible.

As  that is not the case and 2 parallel proposals have already been accepted as 
WG experimental track, and given the interest/support on this particular topic

I would think it's reasonable to continue this experiment in IS-IS too as is 
done in OSPF.



I think that the two proposals that have already been adopted as experimental 
are VERY different in the way they solve the problem of better LSDB scalability 
across an IS-IS routing domain.

You are right, of course. IS-IS TTZ draft 

Re: [Lsr] New Version Notification for draft-wang-lsr-igp-extensions-ifit-00.txt

2020-07-16 Thread Les Ginsberg (ginsberg)
Yali -



While it is kind of you to acknowledge many of us for our comments, in many 
cases (myself included) what we told you is that this does not belong in the 
IGPs.

Putting out a new draft which continues to push for advertising ifit in IGPs 
(even if in different TLVs) does not indicate that you are heeding our message. 






   Les





> -Original Message-

> From: Lsr  On Behalf Of wangyali

> Sent: Thursday, July 16, 2020 8:20 AM

> To: lsr@ietf.org

> Subject: [Lsr] FW: New Version Notification for draft-wang-lsr-igp-

> extensions-ifit-00.txt

>

> Dear LSR WG,

>

> We've uploaded a new revision of draft-wang-lsr-igp-extensions-ifit-00 to

> replace draft-wang-lsr-ifit-node-capability-advertisement. In this new

> revision, Node and Link Attribute TLVs are extended to IGP for signaling the

> supported IFIT capability of egress and/or intermediate nodes to the ingress

> nodes.

>

> The changes in this revision are:

>

> 1. added Link Attribute TLVs extension to IGP to signal IFIT Capability at 
> link

> granularity.

> 2. updated Application section, which illustrates such advertisements would

> helpful for avoiding the leak of IFIT-specific header and metadata, as well 
> as,

> for ingress routers to gather each router's IFIT capability for achieving the

> computation of TE paths or loose TE paths that be able to fulfill the 
> visibility of

> on-path OAM data.

> 3. updated Acknowledgements sections, in which, the authors would like to

> thank Acee Lindem, Christian Hopps, Robert Raszuk, Les Ginsberg, Jeff

> Tantsura, Rakesh Gandhi, Tony Li and Greg Mirsky for the comments.

> 4. adding China Telecom into the author list.

>

> We are looking forward to hearing your feedback and comments, and try to

> achieve consensus.

>

> Thanks,

> Yali

>

>

> -Original Message-

> From: internet-dra...@ietf.org 
> [mailto:internet-dra...@ietf.org]

> Sent: Monday, July 13, 2020 9:15 PM

> To: Tianran Zhou mailto:zhoutian...@huawei.com>>; 
> wangyali

> mailto:wangyal...@huawei.com>>; Huanan Chen 
> mailto:chenhu...@chinatelecom.cn>>;

> Liumin (Lucy) mailto:lucy.liu...@huawei.com>>; Ran 
> Pang

> mailto:pang...@chinaunicom.cn>>; Liumin (Lucy) 
> mailto:lucy.liu...@huawei.com>>

> Subject: New Version Notification for draft-wang-lsr-igp-extensions-ifit-

> 00.txt

>

>

> A new version of I-D, draft-wang-lsr-igp-extensions-ifit-00.txt

> has been successfully submitted by Yali Wang and posted to the IETF

> repository.

>

> Name:   draft-wang-lsr-igp-extensions-ifit

> Revision:  00

> Title:  IGP Extensions for In-situ Flow Information Telemetry 
> (IFIT)

> Capability Advertisement

> Document date:2020-07-12

> Group:  Individual Submission

> Pages:   12

> URL:
> https://www.ietf.org/internet-drafts/draft-wang-lsr-igp-

> extensions-ifit-00.txt

> Status: 
> https://datatracker.ietf.org/doc/draft-wang-lsr-igp-extensions-

> ifit/

> Htmlized:   
> https://tools.ietf.org/html/draft-wang-lsr-igp-extensions-ifit-00

> Htmlized:   
> https://datatracker.ietf.org/doc/html/draft-wang-lsr-igp-

> extensions-ifit

>

>

> Abstract:

>This document extends Node and Link Attribute TLVs to Interior

>Gateway Protocols (IGP) to advertise supported In-situ Flow

>Information Telemetry (IFIT) capabilities at node and/or link

>granularity.  An ingress router cannot insert IFIT-Data-Fields for

>packets going into a path unless an egress router has indicated via

>signaling that it has the capability to process IFIT-Data-Fields.  In

>addition, such advertisements would be useful for ingress routers to

>gather each router's IFIT capability for achieving the computation of

>Traffic Engineering (TE) paths or loose TE paths that be able to

>fulfill the visibility of on-path OAM data.

>

>

>

>

>

> Please note that it may take a couple of minutes from the time of submission

> until the htmlized version and diff are available at tools.ietf.org.

>

> The IETF Secretariat

>

>

> ___

> Lsr mailing list

> Lsr@ietf.org

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


Re: [Lsr] Request WG adoption of TTZ

2020-07-15 Thread Les Ginsberg (ginsberg)
+1

I think Henk has spoken eloquently here - as have others before him.

Abstracting an area may be useful - the WG has yet to fully decide on that.
But nothing so far has demonstrated that we need to go even further and 
abstract a subset of an area.

   Les


> -Original Message-
> From: Lsr  On Behalf Of John E Drake
> Sent: Wednesday, July 15, 2020 7:19 AM
> To: Henk Smit ; Huaimo Chen
> 
> Cc: lsr@ietf.org
> Subject: Re: [Lsr] Request WG adoption of TTZ
> 
> I agree w/ Henk.  The TTZ seems to be a gratuitous addition.
> 
> Yours Irrespectively,
> 
> John
> 
> 
> Juniper Business Use Only
> 
> > -Original Message-
> > From: Lsr  On Behalf Of Henk Smit
> > Sent: Wednesday, July 15, 2020 8:22 AM
> > To: Huaimo Chen 
> > Cc: lsr@ietf.org
> > Subject: Re: [Lsr] Request WG adoption of TTZ
> >
> > [External Email. Be cautious of content]
> >
> >
> > Huaimo Chen wrote on 2020-07-14 06:09:
> >
> > >  2). IS-IS TTZ abstracts a zone to a single node. A zone is any target
> > > block or piece of an IS-IS area, which is to be abstracted. This seems
> > > more flexible and convenient to users.
> >
> > I don't agree that this convenience is really beneficial.
> > I actually think this convenience is a downside.
> >
> >
> > Link-state protocols are not easy to understand. And we already have the
> > misfortune that IS-IS and OSPF use different names for things.
> > Adding the new concept of a "zone", while we already have the concept of
> an
> > area makes things only more complex.
> >
> > How often will this new flexibility be used in the real world ?
> > I still haven't seen an answer to Christian Hopp's simple question:
> > "Has RFC8099 been deployed by anyone ?"
> > Anyone who has an answer ?
> >
> > My favorite rule of RFC1925 is rule 12:
> > In protocol design, perfection has been reached not when there is
> > nothing left to add, but when there is nothing left to take away.
> >
> > Adding a new concept, with very little benefit, hurts the protocol in the
> long run.
> > The ability to abstract an area, and not also a zone, is strong enough to be
> > worthwhile, imho.
> >
> > henk.
> >
> > ___
> > Lsr mailing list
> > Lsr@ietf.org
> >
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!
> !NEt
> > 6yMaO-
> >
> gk!Qd22Qan7jubM_Vup5P5G6gsGg_horPl4PSDx8qS_v03ZIb8sNalgwEsGJ7Q6
> 1cc
> > $
> 
> ___
> 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] Robert Wilton's No Objection on draft-ietf-lsr-isis-invalid-tlv-02: (with COMMENT)

2020-07-14 Thread Les Ginsberg (ginsberg)
Rob -

Thanx for the review.
Responses inline.

> -Original Message-
> From: Robert Wilton via Datatracker 
> Sent: Tuesday, July 14, 2020 2:25 AM
> To: The IESG 
> Cc: draft-ietf-lsr-isis-invalid-...@ietf.org; lsr-cha...@ietf.org; 
> lsr@ietf.org;
> Christian Hopps ; aretana.i...@gmail.com;
> cho...@chopps.org
> Subject: Robert Wilton's No Objection on draft-ietf-lsr-isis-invalid-tlv-02:
> (with COMMENT)
> 
> Robert Wilton has entered the following ballot position for
> draft-ietf-lsr-isis-invalid-tlv-02: 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-lsr-isis-invalid-tlv/
> 
> 
> 
> --
> COMMENT:
> --
> 
> The document is short and easy to read, thanks!  However, I was sure
> whether I
> should put a DISCUSS on this document for section 3.4.
> 
> I find that the quoted paragraph from RFC6232 to be badly worded:
> 
>   "The POI TLV SHOULD be found in all purges and
>MUST NOT be found in LSPs with a non-zero
>Remaining Lifetime."
> 
> Taking a strict reading of this, my interpretation is that an implementation 
> is
> not compliant to RFC 6232 if it happens to receive a POI TLV in an LSP with
> non-zero remaining lifetime!  Further, this text then arguably conflicts with
> earlier parts of this document regarding how unrecognized or bad TLVs
> should be
> handled.
> 
> Hence, given that RFC6232 is being updated, I would prefer it if this
> document
> also updated RFC6232 to clarify the above paragraph to something like:
> 
>   "The POI TLV SHOULD be sent in all purges and
>MUST NOT be sent in LSPs with a non-zero
>Remaining Lifetime."
> 
[Les:] I have no objection to the wording change.  

But, I do find your interpretation that "an implementation which receives...is 
non-compliant" a bit pedantic (no offense intended).
Clearly an implementation cannot control what it receives. 
But I agree your proposed wording change is more "traditional".


> One other minor comment:
> 
> It is RECOMMENDED that implementations provide controls for the
> enablement
> of behaviors that are not backward compatible.
> 
> Is this covered by the existing ISIS YANG model, or included in the latest
> update to that YANG model?

[Les:] Note that the wording of this has been revised based on recent comments 
and now speaks to future instances as well as existing ones. But to answer your 
question, this isn’t just "one thing".  For each non-backwards compatible 
behavior I would expect that an implementation would need to provide a separate 
control. So coverage in a YANG model is going to be on a feature-by-feature 
basis. There is no one generic "backwards-compatible-knob" that will suffice.

More details I leave to the team that will be working on extensions to the base 
protocol YANG model.

   Les


> 
> Regards,
> Rob
> 
> 

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


Re: [Lsr] Roman Danyliw's No Objection on draft-ietf-lsr-isis-invalid-tlv-02: (with COMMENT)

2020-07-13 Thread Les Ginsberg (ginsberg)
Roman (and Acee) -

After a suggestion from Ben, I have reworded the sentence to read:

" When new protocol behaviors are specified that are not backwards
   compatible, it is RECOMMENDED that implementations provide controls
   for their enablement.  This serves to prevent interoperability issues
   and allow for non-disruptive introduction of the new functionality
   into an existing network."

Let me know if this resolves the concerns.

   Les


> -Original Message-
> From: Acee Lindem (acee) 
> Sent: Monday, July 13, 2020 9:38 AM
> To: Les Ginsberg (ginsberg) ; Roman Danyliw
> ; The IESG 
> Cc: lsr-cha...@ietf.org; aretana.i...@gmail.com; cho...@chopps.org; draft-
> ietf-lsr-isis-invalid-...@ietf.org; lsr@ietf.org
> Subject: Re: [Lsr] Roman Danyliw's No Objection on 
> draft-ietf-lsr-isis-invalid-
> tlv-02: (with COMMENT)
> 
> 
> 
> On 7/13/20, 12:23 PM, "Les Ginsberg (ginsberg)" 
> wrote:
> 
> Acee -
> 
> Inline.
> 
> > -Original Message-
>     > From: Acee Lindem (acee) 
> > Sent: Monday, July 13, 2020 9:04 AM
> > To: Les Ginsberg (ginsberg) ; Roman Danyliw
> > ; The IESG 
> > Cc: lsr-cha...@ietf.org; aretana.i...@gmail.com; cho...@chopps.org;
> draft-
> > ietf-lsr-isis-invalid-...@ietf.org; lsr@ietf.org
> > Subject: Re: [Lsr] Roman Danyliw's No Objection on draft-ietf-lsr-isis-
> invalid-
> > tlv-02: (with COMMENT)
> >
> > Hi Les,
> >
> > On 7/13/20, 11:53 AM, "Les Ginsberg (ginsberg)" 
> > wrote:
> >
> > Roman -
> >
> > Thanx for the review.
> > Inline.
> >
> > > -Original Message-
> > > From: Lsr  On Behalf Of Roman Danyliw via
> > > Datatracker
> > > Sent: Monday, July 13, 2020 7:40 AM
> > > To: The IESG 
> > > Cc: lsr-cha...@ietf.org; aretana.i...@gmail.com; 
> cho...@chopps.org;
> > draft-
> > > ietf-lsr-isis-invalid-...@ietf.org; lsr@ietf.org
> > > Subject: [Lsr] Roman Danyliw's No Objection on 
> draft-ietf-lsr-isis-
> invalid-
> > tlv-
> > > 02: (with COMMENT)
> > >
> > > Roman Danyliw has entered the following ballot position for
> > > draft-ietf-lsr-isis-invalid-tlv-02: 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-lsr-isis-invalid-tlv/
> > >
> > >
> > >
> > > 
> --
> > > COMMENT:
> > > 
> --
> > >
> > > I'm glad to see language clarifying error handling.  Thanks for 
> the work
> on
> > it.
> > >
> > > Section 3.2.  Per “It is RECOMMENDED that implementations provide
> > controls
> > > for
> > > the enablement of behaviors that are not backward compatible”, I
> want
> > to
> > > double
> > > check that I’m understanding this  sentence correctly. RFC5304
> provides
> > > normative guidance that isn’t backward compatible with ISO10589.
> > RFC6233
> > > provide guidance that isn’t backward compatible with either 
> RFC5304
> or
> > > ISO10589.  Is the initial sentence effectively saying that
> implementations
> > > should support deployments in configurations that are not backward
> > > compatible
> > > (i.e., those using the newer TLVs)?  As these changes are covering
> > security
> > > matters, I read “controls” in the cyber mitigation sense -- they
> prevent an
> > > action, not enable one.
> >
> > [Les:] T

Re: [Lsr] Benjamin Kaduk's Yes on draft-ietf-lsr-isis-invalid-tlv-02: (with COMMENT)

2020-07-13 Thread Les Ginsberg (ginsberg)
Ben -

I have prepared V3 of the draft to address your comments.
As the window for draft submissions is temporarily closed, I have attached the 
diffs for your review.

I will post the updated version once the window for submissions reopens.

A few more remarks inline.

> -Original Message-
> From: Benjamin Kaduk 
> Sent: Monday, July 13, 2020 4:24 PM
> To: Les Ginsberg (ginsberg) 
> Cc: The IESG ; draft-ietf-lsr-isis-invalid-...@ietf.org; lsr-
> cha...@ietf.org; lsr@ietf.org; Christian Hopps ;
> aretana.i...@gmail.com
> Subject: Re: Benjamin Kaduk's Yes on draft-ietf-lsr-isis-invalid-tlv-02: (with
> COMMENT)
> 
> Hi Les,
> 
> On Mon, Jul 13, 2020 at 11:05:35PM +, Les Ginsberg (ginsberg) wrote:
> > Ben -
> >
> >
> >
> > Thanx for your review.
> 
> My pleasure; this is a nice document.  (A shame it's needed, of course, but
> that's neither here nor there.)
> 
> > Responses inline.
> >
> >
> >
> > > -Original Message-
> >
> > > From: Benjamin Kaduk via Datatracker 
> >
> > > Sent: Monday, July 13, 2020 2:11 PM
> >
> > > To: The IESG 
> >
> > > Cc: draft-ietf-lsr-isis-invalid-...@ietf.org; lsr-cha...@ietf.org; 
> > > lsr@ietf.org;
> >
> > > Christian Hopps ; aretana.i...@gmail.com;
> >
> > > cho...@chopps.org
> >
> > > Subject: Benjamin Kaduk's Yes on draft-ietf-lsr-isis-invalid-tlv-02: (with
> >
> > > COMMENT)
> >
> > >
> >
> > > Benjamin Kaduk has entered the following ballot position for
> >
> > > draft-ietf-lsr-isis-invalid-tlv-02: Yes
> >
> > >
> >
> > > 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-lsr-isis-invalid-tlv/
> >
> > >
> >
> > >
> >
> > >
> >
> > > --
> >
> > > COMMENT:
> >
> > > --
> >
> > >
> >
> > > The shepherd writeup is a bit unclear as to why Proposed Standard is the
> >
> > > right document status (vs., e.g., Informational).  I guess it's desired
> >
> > > to have the Updates: relationship to the indicated documents, which
> >
> > > essentially forces it to be standards-track.  On the other hand, perhaps
> >
> > > the sense that ignoring a TLV that is specifically disallowed (as
> >
> > > opposed to "merely" unrecognized) is itself a newly specified
> >
> > > requirement, in which case the status as Proposed Standard makes sense
> >
> > > for that reason.  It might be worth a little more clarity on which (if
> >
> > > either) of these scenarios are intended.
> >
> > >
> >
> > [Les:] What prompted the writing of this document was a real world
> interoperability scenario wherein one implementation generated a
> malformed TLV and a receiving implementation rejected the entire PDU
> because of it. This resulted in persistent LSPDB inconsistency in the network
> for a prolonged period with a significant impact on the proper functioning of
> the network. This failure was considered significant enough that Standards
> Track seemed appropriate.
> >
> >
> >
> > As the document developed, the authors were encouraged to address
> some other issues, one of which was clarifying disallowed TLV handling as
> well.
> >
> >
> >
> > I can understand why Informational track may seem appropriate to you. In
> early discussions with Alvaro I had suggested that there was no need to write
> the document - that existing specifications were sufficiently clear. But the
> fact that - despite existing standards - such an interoperability issue did 
> occur
> was compelling. The WG also embraced this as useful.
> 
> Thanks for the extra explanation.  I think PS makes sense, and the only
> text change I might (emphasis: *might*) consider is to emphasize that th

Re: [Lsr] Benjamin Kaduk's Yes on draft-ietf-lsr-isis-invalid-tlv-02: (with COMMENT)

2020-07-13 Thread Les Ginsberg (ginsberg)
Ben -



Thanx for your review.

Responses inline.



> -Original Message-

> From: Benjamin Kaduk via Datatracker 

> Sent: Monday, July 13, 2020 2:11 PM

> To: The IESG 

> Cc: draft-ietf-lsr-isis-invalid-...@ietf.org; lsr-cha...@ietf.org; 
> lsr@ietf.org;

> Christian Hopps ; aretana.i...@gmail.com;

> cho...@chopps.org

> Subject: Benjamin Kaduk's Yes on draft-ietf-lsr-isis-invalid-tlv-02: (with

> COMMENT)

>

> Benjamin Kaduk has entered the following ballot position for

> draft-ietf-lsr-isis-invalid-tlv-02: Yes

>

> 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-lsr-isis-invalid-tlv/

>

>

>

> --

> COMMENT:

> --

>

> The shepherd writeup is a bit unclear as to why Proposed Standard is the

> right document status (vs., e.g., Informational).  I guess it's desired

> to have the Updates: relationship to the indicated documents, which

> essentially forces it to be standards-track.  On the other hand, perhaps

> the sense that ignoring a TLV that is specifically disallowed (as

> opposed to "merely" unrecognized) is itself a newly specified

> requirement, in which case the status as Proposed Standard makes sense

> for that reason.  It might be worth a little more clarity on which (if

> either) of these scenarios are intended.

>

[Les:] What prompted the writing of this document was a real world 
interoperability scenario wherein one implementation generated a malformed TLV 
and a receiving implementation rejected the entire PDU because of it. This 
resulted in persistent LSPDB inconsistency in the network for a prolonged 
period with a significant impact on the proper functioning of the network. This 
failure was considered significant enough that Standards Track seemed 
appropriate.



As the document developed, the authors were encouraged to address some other 
issues, one of which was clarifying disallowed TLV handling as well.



I can understand why Informational track may seem appropriate to you. In early 
discussions with Alvaro I had suggested that there was no need to write the 
document - that existing specifications were sufficiently clear. But the fact 
that - despite existing standards - such an interoperability issue did occur 
was compelling. The WG also embraced this as useful.



> Section 1

>

>A corollary to ignoring unknown TLVs is having the validation of PDUs

>be independent from the validation of the TLVs contained in the PDU.

>

> nit: this doesn't exactly seem like a "corollary" specifically, but

> rather a choice that [ISO10589] made (and which keeps some overall sense

> of consistency between PDU and TLV handling).

>

[Les:] Rejecting a PDU because of some issue with a single TLV would mean that 
the full set of updates contained in that LSP would not be propagated. This has 
a significant impact on the correct operation of the protocol. So I think this 
really isn’t an option.





> Section 3.1

>

>[ISO10589] defines the behavior required when a PDU is received

>containing a TLV which is "not recognised".  It states (see Sections

>9.3 - 9.13):

>

> This is Sections 9.5 (not 9.3) to 9.13 in the copy I have.

>

[Les:] Well spotted. I see you have put your newly acquired  copy of ISO 10589 
to good use. Bravo!! 



> Section 3.2

>

>Similarly, the extensions defined by [RFC6233] are not compatible

>with the behavior defined in [RFC5304], therefore can only be safely

>enabled when all nodes support the extensions.

>

> nit: I'd argue that technically the extensions are *defined* by 6232, even

> though 6233 is what makes their nature (as "allowed in purge") easily

> discoverable.

>

[Les:] Fair enough. I will change this to RFC6232 - which is one of documents 
updated by this draft.



>It is RECOMMENDED that implementations provide controls for the

>enablement of behaviors that are not backward compatible.

>

> We also specifically want the ability to generate but not

> process/require at least some of them, right?  Is that worth calling out

> in addition to just "controls for the enablement"?



[Les:] This sentence is serving as a guideline for new behaviors that have 
backwards compatibility issues. New information which could be safely sent in 
the presence of legacy routers does not fall into this category.



>

> Section 3.3

>

>a given sub-TLV is allowed.  Section 2 of [RFC5305] is updated by the

>following sentence:

>

>   "As with TLVs, 

Re: [Lsr] Secdir last call review of draft-ietf-lsr-isis-invalid-tlv-02

2020-07-13 Thread Les Ginsberg (ginsberg)
Leif -

Thanx for your review.

   Les

> -Original Message-
> From: Leif Johansson via Datatracker 
> Sent: Monday, July 13, 2020 1:55 PM
> To: sec...@ietf.org
> Cc: last-c...@ietf.org; lsr@ietf.org; 
> draft-ietf-lsr-isis-invalid-tlv@ietf.org
> Subject: Secdir last call review of draft-ietf-lsr-isis-invalid-tlv-02
> 
> Reviewer: Leif Johansson
> Review result: Ready
> 
> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the
> IESG.  These comments were written primarily for the benefit of the
> security area directors.  Document editors and WG chairs should treat
> these comments just like any other last call comments.
> 
> The subject matter is outside my area of expertise but addressing the
> obvious attack vector related to authenticated purge messages seems
> like a good catch.
> 
> The document is well written and clearly describes what registries
> and documents are updated.
> 

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


Re: [Lsr] Roman Danyliw's No Objection on draft-ietf-lsr-isis-invalid-tlv-02: (with COMMENT)

2020-07-13 Thread Les Ginsberg (ginsberg)
Acee -

Inline.

> -Original Message-
> From: Acee Lindem (acee) 
> Sent: Monday, July 13, 2020 9:04 AM
> To: Les Ginsberg (ginsberg) ; Roman Danyliw
> ; The IESG 
> Cc: lsr-cha...@ietf.org; aretana.i...@gmail.com; cho...@chopps.org; draft-
> ietf-lsr-isis-invalid-...@ietf.org; lsr@ietf.org
> Subject: Re: [Lsr] Roman Danyliw's No Objection on 
> draft-ietf-lsr-isis-invalid-
> tlv-02: (with COMMENT)
> 
> Hi Les,
> 
> On 7/13/20, 11:53 AM, "Les Ginsberg (ginsberg)" 
> wrote:
> 
> Roman -
> 
> Thanx for the review.
> Inline.
> 
> > -Original Message-
> > From: Lsr  On Behalf Of Roman Danyliw via
> > Datatracker
> > Sent: Monday, July 13, 2020 7:40 AM
> > To: The IESG 
> > Cc: lsr-cha...@ietf.org; aretana.i...@gmail.com; cho...@chopps.org;
> draft-
> > ietf-lsr-isis-invalid-...@ietf.org; lsr@ietf.org
> > Subject: [Lsr] Roman Danyliw's No Objection on 
> draft-ietf-lsr-isis-invalid-
> tlv-
> > 02: (with COMMENT)
> >
> > Roman Danyliw has entered the following ballot position for
> > draft-ietf-lsr-isis-invalid-tlv-02: 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-lsr-isis-invalid-tlv/
> >
> >
> >
> > --
> > COMMENT:
> > --
> >
> > I'm glad to see language clarifying error handling.  Thanks for the 
> work on
> it.
> >
> > Section 3.2.  Per “It is RECOMMENDED that implementations provide
> controls
> > for
> > the enablement of behaviors that are not backward compatible”, I want
> to
> > double
> > check that I’m understanding this  sentence correctly. RFC5304 provides
> > normative guidance that isn’t backward compatible with ISO10589.
> RFC6233
> > provide guidance that isn’t backward compatible with either RFC5304 or
> > ISO10589.  Is the initial sentence effectively saying that 
> implementations
> > should support deployments in configurations that are not backward
> > compatible
> > (i.e., those using the newer TLVs)?  As these changes are covering
> security
> > matters, I read “controls” in the cyber mitigation sense -- they 
> prevent an
> > action, not enable one.
> 
> [Les:] The recommendation is for implementations to provide control as to
> when the new (non-backwards compatible) behavior is used.
> Without that, an implementation which adds support for (to use one
> example) sending the Purge Originator TLV in the presence of MD5
> authentication would simply start sending it and risk the PDU not being
> accepted by implementations which had not yet added the support.
> 
> One way of reading this is that "including the POI TLV in purges w MD5
> authentication" is "enablement" of a new feature. Another way of reading it
> might be "disablement" of the use of a new feature.
> This seems to me to be a semantical distinction.
> 
> The recommendation to use "controls" also does not specify what the
> default behavior should be - that is up to the implementation.
> 
> Since there was some confusion, maybe "configurable specification" would
> be clearer than "controls".
> 
[Les:] I will certainly wait for Roman's input, but to me the term "controls" 
means there is a way to control whether a particular behavior is used/not used. 
(An "on/off" switch comes to mind.)
Frankly, I don’t know what the term "configuration specification" means. Maybe 
if I worked with YANG more I would know. 

I am open to an alternate term if there really is confusion - but for me you 
haven't added clarity with your suggestion.

  Les

> Thanks,
> Acee
> 
>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


Re: [Lsr] Roman Danyliw's No Objection on draft-ietf-lsr-isis-invalid-tlv-02: (with COMMENT)

2020-07-13 Thread Les Ginsberg (ginsberg)
Roman -

Thanx for the review.
Inline.

> -Original Message-
> From: Lsr  On Behalf Of Roman Danyliw via
> Datatracker
> Sent: Monday, July 13, 2020 7:40 AM
> To: The IESG 
> Cc: lsr-cha...@ietf.org; aretana.i...@gmail.com; cho...@chopps.org; draft-
> ietf-lsr-isis-invalid-...@ietf.org; lsr@ietf.org
> Subject: [Lsr] Roman Danyliw's No Objection on 
> draft-ietf-lsr-isis-invalid-tlv-
> 02: (with COMMENT)
> 
> Roman Danyliw has entered the following ballot position for
> draft-ietf-lsr-isis-invalid-tlv-02: 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-lsr-isis-invalid-tlv/
> 
> 
> 
> --
> COMMENT:
> --
> 
> I'm glad to see language clarifying error handling.  Thanks for the work on 
> it.
> 
> Section 3.2.  Per “It is RECOMMENDED that implementations provide controls
> for
> the enablement of behaviors that are not backward compatible”, I want to
> double
> check that I’m understanding this  sentence correctly. RFC5304 provides
> normative guidance that isn’t backward compatible with ISO10589. RFC6233
> provide guidance that isn’t backward compatible with either RFC5304 or
> ISO10589.  Is the initial sentence effectively saying that implementations
> should support deployments in configurations that are not backward
> compatible
> (i.e., those using the newer TLVs)?  As these changes are covering security
> matters, I read “controls” in the cyber mitigation sense -- they prevent an
> action, not enable one.

[Les:] The recommendation is for implementations to provide control as to when 
the new (non-backwards compatible) behavior is used.
Without that, an implementation which adds support for (to use one example) 
sending the Purge Originator TLV in the presence of MD5 authentication would 
simply start sending it and risk the PDU not being accepted by implementations 
which had not yet added the support.

One way of reading this is that "including the POI TLV in purges w MD5 
authentication" is "enablement" of a new feature. Another way of reading it 
might be "disablement" of the use of a new feature.
This seems to me to be a semantical distinction.

The recommendation to use "controls" also does not specify what the default 
behavior should be - that is up to the implementation.

   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


Re: [Lsr] Murray Kucherawy's No Objection on draft-ietf-lsr-isis-invalid-tlv-02: (with COMMENT)

2020-07-13 Thread Les Ginsberg (ginsberg)
Murray -

Thanx for your review - and for catching the editorial issue.
We will address that in the next revision.

   Les


> -Original Message-
> From: Murray Kucherawy via Datatracker 
> Sent: Monday, July 13, 2020 12:21 AM
> To: The IESG 
> Cc: draft-ietf-lsr-isis-invalid-...@ietf.org; lsr-cha...@ietf.org; 
> lsr@ietf.org;
> Christian Hopps ; aretana.i...@gmail.com
> Subject: Murray Kucherawy's No Objection on 
> draft-ietf-lsr-isis-invalid-tlv-02:
> (with COMMENT)
> 
> Murray Kucherawy has entered the following ballot position for
> draft-ietf-lsr-isis-invalid-tlv-02: 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-lsr-isis-invalid-tlv/
> 
> 
> 
> --
> COMMENT:
> --
> 
> In the Abstract:
> 
> * "... in order to insure that interoperability is maximized." --  That 
> should be
> "ensure".
> 
> 

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


Re: [Lsr] New Version Notification for draft-ietf-lsr-isis-area-proxy-01.txt

2020-07-12 Thread Les Ginsberg (ginsberg)
Resuming this thread…the authors were kind enough to meet with me and educate 
me on how Area Proxy works. The resulting conclusions are:

1)Area Proxy TLV is meant to  be sent ONLY in L1L2 LSPs (NOT Proxy LSPs).

2)Advertisement of Area SID in the Area Proxy TLV is needed so that Inside 
Nodes can install a receive entry for that SID

3)Advertisement of Area SID in Binding TLV is needed in Proxy LSPs so that 
outside nodes can install a forwarding entry towards the Inside Node(s).
This SID MUST be identical to the SID advertised in the Area Proxy TLV in L2 
LSPs.
Use of the Binding TLVs to do this is the current choice.

4)Other uses of an Area SID not related to Area Proxy are outside the scope of 
the Area Proxy draft. However, as the concept seems potentially useful in other 
scenarios, being able to advertise an Area SID in the Binding TLV allows for 
these other uses.
But, any advertisement of Area SID in Binding TLV which appears in L1L2 LSPs is 
unrelated to Area Proxy. Whether that SID is the same value as that used for 
Area Proxy is something future use cases for Area SID will have to decide.

I therefore think it makes sense to allow advertisement of the Area SID in both 
the Area Proxy TLV and the Binding TLV, subject to the constraints above. This 
will NOT result in “duplicate advertisements”.

Further details regarding the encoding will need to be provided in future 
revisions of the draft.

   Les (both as WG member and Designated Expert for IS-IS TLV Codepoints 
Registry)


From: Lsr  On Behalf Of Les Ginsberg (ginsberg)
Sent: Wednesday, July 08, 2020 11:19 AM
To: tony...@tony.li
Cc: lsr@ietf.org
Subject: Re: [Lsr] New Version Notification for 
draft-ietf-lsr-isis-area-proxy-01.txt

Tony –

Inline.

From: Tony Li mailto:tony1ath...@gmail.com>> On Behalf 
Of tony...@tony.li<mailto:tony...@tony.li>
Sent: Wednesday, July 08, 2020 11:12 AM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>
Subject: Re: [Lsr] New Version Notification for 
draft-ietf-lsr-isis-area-proxy-01.txt


Hi Les,


Again, the subTLVs of the area proxy TLV are for the coordination of the Inside 
Area. The Area Proxy TLV appears in the Inside Node’s normal LSP.

The Proxy LSP is for informing the Outside Area.

[Les:] Understood – but I do not see why this requires you to advertise the SID 
in two different TLVs. As you allow the Binding SID TLVs to be advertised in 
both standard LSPs and Proxy LSPs, there seems to be no need for two different 
TLVs to include the advertisement.
??


The semantics are completely different. Advertising it in the Binding TLV is 
permission to use the SID for packet forwarding.

The advertisement in the Area Proxy LSP is to instruct the Inside Nodes to use 
that SID to establish the forwarding state.
[Les:] Sorry, I do not see why this requires you to advertise the SID in two 
different places.
The SID gets advertised in one place (which TLV is TBD for the moment). The 
instruction to enable use of it for Area Proxy comes in the Area Proxy TLV. 
That only requires (at most) a bit – and perhaps nothing other than the 
presence of the Area Proxy TLV. It certainly does not require the SID itself to 
be readvertised.

Let’s see if we can agree that the SID only needs to be advertised in one place 
before proceeding further.

Les



[Les:] Yes – of course – this is pathological. (Probably not hilarious to the 
customer.  )


No doubt, but I’ve found that if one doesn’t regard bugs with some humor, our 
profession would be morose, in the extreme.


I am just saying by having two sources for the advertisement you introduce the 
possibility of inconsistency – and the spec would have to speak to this – even 
if it should not happen.


Ummm…. Not sure what I can say other than “don’t write bugs”.  But ok, I’ll 
happily do so.


We are abusing the definition of the Binding TLV.  2.4 says: "The SID/Label 
Binding TLV may be used to advertise prefixes to SID/Label mappings.”  That’s 
not what we’re doing, so it’s not too surprising that there’s some conflicts.

[Les:] Yes – the Binding TLV has some issues being generalized. There is 
history here as to why the format is the way it is and why it isn’t more easily 
extensible – and that is open for discussion AFAIAC, but we cannot break 
backwards compatibility for SR.


Agreed, trying not to. :-)


But I am also responding (in part) to your desire to make the Area Segment SID 
a more general tool – usable outside of Area Proxy – which seems like a good 
goal.


And you’ve requested that we put the Area Segment SID in the Binding TLV.  I’ve 
tried to do so and you don’t like how I’ve done it.  Please tell me what I can 
do that will satisfy you.  From what you’ve said so far, there is no legal way 
to use the Binding TLV.

Catch-22.  Yossarian!

Regards,
Tony

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


Re: [Lsr] Martin Duke's No Objection on draft-ietf-lsr-isis-invalid-tlv-02: (with COMMENT)

2020-07-11 Thread Les Ginsberg (ginsberg)
Martin -

Thanx for your review.
Responses inline.

> -Original Message-
> From: Martin Duke via Datatracker 
> Sent: Saturday, July 11, 2020 9:08 AM
> To: The IESG 
> Cc: draft-ietf-lsr-isis-invalid-...@ietf.org; lsr-cha...@ietf.org; 
> lsr@ietf.org;
> Christian Hopps ; aretana.i...@gmail.com;
> cho...@chopps.org
> Subject: Martin Duke's No Objection on draft-ietf-lsr-isis-invalid-tlv-02: 
> (with
> COMMENT)
> 
> Martin Duke has entered the following ballot position for
> draft-ietf-lsr-isis-invalid-tlv-02: 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-lsr-isis-invalid-tlv/
> 
> 
> 
> --
> COMMENT:
> --
> 
> It might be helpful to define “ignore” as “skip the number of octets indicated
> by the length field.” An alternate interpretation might skip the number of
> bytes implied by the type code, if the type is known.
> 
[Les:] The definition of TLV as:

Type
Length (# of octets of data)
Data

comes from the base specification (ISO 10589).

There is no encoding which omits the Length - nor one which allows for the 
value in the length field to be ignored and a fixed length to be associated 
based on the Type.
Doing that would compromise the ability to extend the protocol as nodes which 
do not recognize a new TLV type would have no idea how many octets to skip 
unless the length field were valid.

> Similarly, I take it that a length value beyond the end of the message ends
> processing of the PDU, but the PDU as a whole MUST NOT be discarded.

[Les:] You are correct.
Note that the scope of this draft is to make explicit how to handle invalid 
TLVs independent of validation of the PDU in which the TLVs appear.
Discussion of this case is therefore out of scope of the draft.

   Les

> 
> 

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


Re: [Lsr] New Version Notification for draft-ietf-lsr-isis-area-proxy-01.txt

2020-07-08 Thread Les Ginsberg (ginsberg)
Tony –

Inline.

From: Tony Li  On Behalf Of tony...@tony.li
Sent: Wednesday, July 08, 2020 11:12 AM
To: Les Ginsberg (ginsberg) 
Cc: lsr@ietf.org
Subject: Re: [Lsr] New Version Notification for 
draft-ietf-lsr-isis-area-proxy-01.txt


Hi Les,


Again, the subTLVs of the area proxy TLV are for the coordination of the Inside 
Area. The Area Proxy TLV appears in the Inside Node’s normal LSP.

The Proxy LSP is for informing the Outside Area.

[Les:] Understood – but I do not see why this requires you to advertise the SID 
in two different TLVs. As you allow the Binding SID TLVs to be advertised in 
both standard LSPs and Proxy LSPs, there seems to be no need for two different 
TLVs to include the advertisement.
??


The semantics are completely different. Advertising it in the Binding TLV is 
permission to use the SID for packet forwarding.

The advertisement in the Area Proxy LSP is to instruct the Inside Nodes to use 
that SID to establish the forwarding state.
[Les:] Sorry, I do not see why this requires you to advertise the SID in two 
different places.
The SID gets advertised in one place (which TLV is TBD for the moment). The 
instruction to enable use of it for Area Proxy comes in the Area Proxy TLV. 
That only requires (at most) a bit – and perhaps nothing other than the 
presence of the Area Proxy TLV. It certainly does not require the SID itself to 
be readvertised.

Let’s see if we can agree that the SID only needs to be advertised in one place 
before proceeding further.

Les




[Les:] Yes – of course – this is pathological. (Probably not hilarious to the 
customer.  )


No doubt, but I’ve found that if one doesn’t regard bugs with some humor, our 
profession would be morose, in the extreme.



I am just saying by having two sources for the advertisement you introduce the 
possibility of inconsistency – and the spec would have to speak to this – even 
if it should not happen.


Ummm…. Not sure what I can say other than “don’t write bugs”.  But ok, I’ll 
happily do so.


We are abusing the definition of the Binding TLV.  2.4 says: "The SID/Label 
Binding TLV may be used to advertise prefixes to SID/Label mappings.”  That’s 
not what we’re doing, so it’s not too surprising that there’s some conflicts.

[Les:] Yes – the Binding TLV has some issues being generalized. There is 
history here as to why the format is the way it is and why it isn’t more easily 
extensible – and that is open for discussion AFAIAC, but we cannot break 
backwards compatibility for SR.


Agreed, trying not to. :-)



But I am also responding (in part) to your desire to make the Area Segment SID 
a more general tool – usable outside of Area Proxy – which seems like a good 
goal.


And you’ve requested that we put the Area Segment SID in the Binding TLV.  I’ve 
tried to do so and you don’t like how I’ve done it.  Please tell me what I can 
do that will satisfy you.  From what you’ve said so far, there is no legal way 
to use the Binding TLV.

Catch-22.  Yossarian!

Regards,
Tony

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


Re: [Lsr] New Version Notification for draft-ietf-lsr-isis-area-proxy-01.txt

2020-07-08 Thread Les Ginsberg (ginsberg)
Tony –

Inline.

From: Tony Li  On Behalf Of tony...@tony.li
Sent: Wednesday, July 08, 2020 8:29 AM
To: Les Ginsberg (ginsberg) 
Cc: lsr@ietf.org
Subject: Re: [Lsr] New Version Notification for 
draft-ietf-lsr-isis-area-proxy-01.txt


Hi Les,



The new definitions in the latest version in the draft are very close to what 
we discussed in the earlier thread – so this looks pretty good to me.


Excellent, thanks.



I still have some concerns regarding the Area Segment SID.
You propose to advertise this in two places:

1)As a sub-TLV of the new Area Proxy TLV
2)As a new sub-TLV of the existing Binding TLVs (149, 150)

I am not sure why you need this in the Area Proxy TLV as you allow Binding TLVs 
to be advertised in the Proxy LSPs (Section 4.4.10).
???


Again, the subTLVs of the area proxy TLV are for the coordination of the Inside 
Area. The Area Proxy TLV appears in the Inside Node’s normal LSP.

The Proxy LSP is for informing the Outside Area.

It’s fairly important that we install the forwarding state for the Area Segment 
SID and distribute the Proxy System ID before we advertise the Proxy LSP.

[Les:] Understood – but I do not see why this requires you to advertise the SID 
in two different TLVs. As you allow the Binding SID TLVs to be advertised in 
both standard LSPs and Proxy LSPs, there seems to be no need for two different 
TLVs to include the advertisement.
??


If this is what is intended, it raises a number of concerns:

If both are present and inconsistent how are they used?


If both are present and inconsistent, then we have a major malfunction of the 
Area Leader, since it is the single system that is intentionally advertising 
both.

The Inside Nodes would follow the contents of the Area Proxy TLV and employ one 
SID value.

The Outsiide Nodes would follow the contents of the Proxy LSP and employ a 
different SID value.

Hilarity ensues.

Note that this is somewhat analogous to a system that wished to advertise a 
loopback interface and advertised one prefix into L1 and another prefix into L2.

[Les:] Yes – of course – this is pathological. (Probably not hilarious to the 
customer.  )
I am just saying by having two sources for the advertisement you introduce the 
possibility of inconsistency – and the spec would have to speak to this – even 
if it should not happen.


As Area Proxy TLV does not support MT (not suggesting that it should) it isn’t 
clear how this relates to MT context – which exists for TLVs 149/150.

Encoding wise, if we are to support Area Segment SID in the Binding TLVs, I 
think more detail needs to be provided as to flag settings when the new sub-TLV 
is present.
The following flags are currently defined for the Binding TLVs:

0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|F|M|S|D|A| |
+-+-+-+-+-+-+-+-+

F,S,D flags seem applicable w/o change.
However, M flag would need to be clear when Area Segment SID is present.
The A flag seems not applicable to Area Segment SID
And your encoding violates the current definition of Binding TLVs.
Specifically, https://www.rfc-editor.org/rfc/rfc8667.html#section-2.4.4 states:

“The Prefix-SID sub-TLV is defined in Section 
2.1<https://www.rfc-editor.org/rfc/rfc8667.html#PREFIXSIDSUBTLV> and contains 
the SID/Index/Label value associated with the prefix and range.
 The Prefix-SID sub-TLV MUST be present in the SID/Label Binding TLV when the 
M-Flag is clear.
 The Prefix-SID sub-TLV MUST NOT be present when the M-Flag is set.”

While some changes to this definition are likely required to support Area 
Segment SID no matter what, it is hard for me to see a good way to do this w/o 
adding a new flag.


I’m open to suggestions here.

We are abusing the definition of the Binding TLV.  2.4 says: "The SID/Label 
Binding TLV may be used to advertise prefixes to SID/Label mappings.”  That’s 
not what we’re doing, so it’s not too surprising that there’s some conflicts.

[Les:] Yes – the Binding TLV has some issues being generalized. There is 
history here as to why the format is the way it is and why it isn’t more easily 
extensible – and that is open for discussion AFAIAC, but we cannot break 
backwards compatibility for SR.
But I am also responding (in part) to your desire to make the Area Segment SID 
a more general tool – usable outside of Area Proxy – which seems like a good 
goal.

   Les

Tony


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


Re: [Lsr] Fwd: New Version Notification for draft-ietf-lsr-isis-area-proxy-01.txt

2020-07-08 Thread Les Ginsberg (ginsberg)
Tony –

The new definitions in the latest version in the draft are very close to what 
we discussed in the earlier thread – so this looks pretty good to me.

I still have some concerns regarding the Area Segment SID.
You propose to advertise this in two places:

1)As a sub-TLV of the new Area Proxy TLV
2)As a new sub-TLV of the existing Binding TLVs (149, 150)

I am not sure why you need this in the Area Proxy TLV as you allow Binding TLVs 
to be advertised in the Proxy LSPs (Section 4.4.10).
???

If this is what is intended, it raises a number of concerns:

If both are present and inconsistent how are they used?
As Area Proxy TLV does not support MT (not suggesting that it should) it isn’t 
clear how this relates to MT context – which exists for TLVs 149/150.

Encoding wise, if we are to support Area Segment SID in the Binding TLVs, I 
think more detail needs to be provided as to flag settings when the new sub-TLV 
is present.
The following flags are currently defined for the Binding TLVs:

0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|F|M|S|D|A| |
+-+-+-+-+-+-+-+-+

F,S,D flags seem applicable w/o change.
However, M flag would need to be clear when Area Segment SID is present.
The A flag seems not applicable to Area Segment SID
And your encoding violates the current definition of Binding TLVs.
Specifically, https://www.rfc-editor.org/rfc/rfc8667.html#section-2.4.4 states:

“The Prefix-SID sub-TLV is defined in Section 
2.1 and contains 
the SID/Index/Label value associated with the prefix and range.
 The Prefix-SID sub-TLV MUST be present in the SID/Label Binding TLV when the 
M-Flag is clear.
 The Prefix-SID sub-TLV MUST NOT be present when the M-Flag is set.”

While some changes to this definition are likely required to support Area 
Segment SID no matter what, it is hard for me to see a good way to do this w/o 
adding a new flag.

   Les


From: Lsr  On Behalf Of tony...@tony.li
Sent: Tuesday, July 07, 2020 8:20 AM
To: lsr@ietf.org
Subject: [Lsr] Fwd: New Version Notification for 
draft-ietf-lsr-isis-area-proxy-01.txt


Hi all,

We’ve updated our draft to revise the TLV encodings along the lines of the 
discussions we’ve been having.

1) The Area Proxy Router Capability is removed.
2) The Inside Node TLV is removed. Instead, the Area Proxy TLV is used instead.
3) The Area Segment SID is advertised inside of a SID/Label Binding TLV. While 
we discussed using
a flag within this TLV to denote that this was an Area Segment SID, after 
looking at it, it seemed simpler
and more consistent to use a sub-TLV.

Please review and comment.

Thanks,
Sarah, Vivek, Gyan, and Tony



Begin forwarded message:

From: internet-dra...@ietf.org
Subject: New Version Notification for draft-ietf-lsr-isis-area-proxy-01.txt
Date: July 7, 2020 at 8:14:58 AM PDT
To: "Gyan Mishra" 
mailto:gyan.s.mis...@verizon.com>>, "Vivek 
Ilangovan" mailto:ilango...@arista.com>>, "Sarah Chen" 
mailto:sarahc...@arista.com>>, "Tony Li" 
mailto:tony...@tony.li>>, "Gyan S. Mishra" 
mailto:gyan.s.mis...@verizon.com>>, "Yunxia Chen" 
mailto:sarahc...@arista.com>>


A new version of I-D, draft-ietf-lsr-isis-area-proxy-01.txt
has been successfully submitted by Tony Li and posted to the
IETF repository.

Name:draft-ietf-lsr-isis-area-proxy
Revision:   01
Title:Area Proxy for IS-IS
Document date: 2020-07-07
Group:   lsr
Pages:19
URL:
https://www.ietf.org/internet-drafts/draft-ietf-lsr-isis-area-proxy-01.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-area-proxy/
Htmlized:   https://tools.ietf.org/html/draft-ietf-lsr-isis-area-proxy-01
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-area-proxy
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-isis-area-proxy-01

Abstract:
  Link state routing protocols have hierarchical abstraction already
  built into them.  However, when lower levels are used for transit,
  they must expose their internal topologies to each other, leading to
  scale issues.

  To avoid this, this document discusses extensions to the IS-IS
  routing protocol that would allow level 1 areas to provide transit,
  yet only inject an abstraction of the level 1 topology into level 2.
  Each level 1 area is represented as a single level 2 node, thereby
  enabling greater scale.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at 
tools.ietf.org.

The IETF Secretariat


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


Re: [Lsr] Request WG adoption of TTZ

2020-07-07 Thread Les Ginsberg (ginsberg)
Huaimo -

Sorry for ascribing area merging properties to zones. As the base protocol 
mechanism in IS-IS can be used both to split and merge areas I was thinking 
zones could be used the same way, but I see on closer reading that you have 
restricted a zone to be a subset of an area (which could also be the area 
itself).

I think this does not detract from the main point I am trying to make - which 
is that unless there is reason to believe that operators would prefer to use 
zones rather than split an area (when necessary), this does not serve as a 
significant differentiator between TTZ and area-proxy.
I think you need a more compelling differentiator to justify proceeding with 
both drafts.

In this regard I am agreeing with the points made by other folks (notably Chris 
and Tony), that the introduction of zones may well be adding unneeded 
complexity.

Just my opinion of course...

   Les


From: Huaimo Chen 
Sent: Tuesday, July 07, 2020 12:42 PM
To: Les Ginsberg (ginsberg) ; Christian Hopps 

Cc: lsr@ietf.org; lsr-cha...@ietf.org
Subject: Re: [Lsr] Request WG adoption of TTZ

Hi Les,

> I think what you are highlighting is that w TTZ an operator could apply the 
> solution to a subset of an area (which you call a zone) - or to a set of 
> areas (which you also call a zone). This presumes that it is expected that a 
> customer would want to operate in a mode where the interconnections do not 
> follow area boundaries. It isn't clear to me that this is a compelling 
> requirement. If there are operators who feel otherwise I would appreciate 
> them speaking up and educating us on the requirements.

How do you get that TTZ could be used to a set of areas (which you also call a 
zone)?
A zone is a piece or block of an area.  In an area, we can define one or more 
zones. All these zones are within this area. For a set of areas, we can define 
one or more zones in each of these areas. But we can not define a zone crossing 
multiple areas.

Best Regards,
Huaimo
________
From: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Sent: Tuesday, July 7, 2020 3:29 PM
To: Huaimo Chen mailto:huaimo.c...@futurewei.com>>; 
Christian Hopps mailto:cho...@chopps.org>>
Cc: lsr@ietf.org<mailto:lsr@ietf.org> mailto:lsr@ietf.org>>; 
lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org> 
mailto:lsr-cha...@ietf.org>>
Subject: RE: [Lsr] Request WG adoption of TTZ


Huaimo -



I think what you are highlighting is that w TTZ an operator could apply the 
solution to a subset of an area (which you call a zone) - or to a set of areas 
(which you also call a zone). This presumes that it is expected that a customer 
would want to operate in a mode where the interconnections do not follow area 
boundaries. It isn't clear to me that this is a compelling requirement. If 
there are operators who feel otherwise I would appreciate them speaking up and 
educating us on the requirements.



Absent that, it seems if you want to differentiate TTZ from Area-Proxy you 
should be focusing on things other than the flexibility of zones over areas..



   Les





From: Huaimo Chen mailto:huaimo.c...@futurewei.com>>
Sent: Tuesday, July 07, 2020 11:13 AM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; 
Christian Hopps mailto:cho...@chopps.org>>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>; 
lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>
Subject: Re: [Lsr] Request WG adoption of TTZ



Hi Les,



Thank you very much for your comments.



There are still some differences between Area Proxy and TTZ regarding to 
IS-IS with smooth area splitting and merging.



At first, the operations/configurations are different.

Using Area Proxy, two steps are needed. One step is to split an IS-IS area 
to multiple areas through some configurations. The other step is to abstract an 
existing IS-IS area to a single pseudo node through another set of 
configurations.

Using TTZ, only one step is needed, which is to abstract a zone to a single 
pseudo node.

From operations' point of view, TTZ seems simpler.



Secondly, TTZ provides smooth transferring between a zone and its single 
pseudo node. That is that a zone can be smoothly transferred to a single pseudo 
node, and the pseudo node can be smoothly rolled back to the zone.

Smooth IS-IS area splitting and merging can not be used for abstracting an 
existing IS-IS area to a single pseudo node in Area Proxy.



Best Regards,

Huaimo



From: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Sent: Tuesday, July 7, 2020 12:52 PM
To: Huaimo Chen mailto:huaimo.c...@futurewei.com>>; 
Christian Hopps mailto:cho...@chopps.org>>
Cc: lsr@ietf.org<mailto:lsr@ietf.org> mailto:lsr@ietf.org>>; 
lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org> 
mailto:lsr-cha...@ietf.org>>
Subject: RE: [Lsr] Request WG adoption of

Re: [Lsr] Request WG adoption of TTZ

2020-07-07 Thread Les Ginsberg (ginsberg)
Huaimo -

I think what you are highlighting is that w TTZ an operator could apply the 
solution to a subset of an area (which you call a zone) - or to a set of areas 
(which you also call a zone). This presumes that it is expected that a customer 
would want to operate in a mode where the interconnections do not follow area 
boundaries. It isn't clear to me that this is a compelling requirement. If 
there are operators who feel otherwise I would appreciate them speaking up and 
educating us on the requirements.

Absent that, it seems if you want to differentiate TTZ from Area-Proxy you 
should be focusing on things other than the flexibility of zones over areas..

   Les


From: Huaimo Chen 
Sent: Tuesday, July 07, 2020 11:13 AM
To: Les Ginsberg (ginsberg) ; Christian Hopps 

Cc: lsr@ietf.org; lsr-cha...@ietf.org
Subject: Re: [Lsr] Request WG adoption of TTZ

Hi Les,

Thank you very much for your comments.

There are still some differences between Area Proxy and TTZ regarding to 
IS-IS with smooth area splitting and merging.

At first, the operations/configurations are different.
Using Area Proxy, two steps are needed. One step is to split an IS-IS area 
to multiple areas through some configurations. The other step is to abstract an 
existing IS-IS area to a single pseudo node through another set of 
configurations.
Using TTZ, only one step is needed, which is to abstract a zone to a single 
pseudo node.
From operations' point of view, TTZ seems simpler.

Secondly, TTZ provides smooth transferring between a zone and its single 
pseudo node. That is that a zone can be smoothly transferred to a single pseudo 
node, and the pseudo node can be smoothly rolled back to the zone.
Smooth IS-IS area splitting and merging can not be used for abstracting an 
existing IS-IS area to a single pseudo node in Area Proxy.

Best Regards,
Huaimo

From: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Sent: Tuesday, July 7, 2020 12:52 PM
To: Huaimo Chen mailto:huaimo.c...@futurewei.com>>; 
Christian Hopps mailto:cho...@chopps.org>>
Cc: lsr@ietf.org<mailto:lsr@ietf.org> mailto:lsr@ietf.org>>; 
lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org> 
mailto:lsr-cha...@ietf.org>>
Subject: RE: [Lsr] Request WG adoption of TTZ


Huaimo -



In regards to merging/splitting areas, IS-IS base protocol provides a way to do 
this hitlessly (this was discussed some years ago when IS-IS TTZ draft was 
first introduced).

So if the major difference/advantage between area-proxy and ttz is the ability 
to use zones to handle area merging/splitting this does not add much value in 
IS-IS.



Please consider this in your responses.



Thanx.



Les





From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
Huaimo Chen
Sent: Tuesday, July 07, 2020 9:00 AM
To: Christian Hopps mailto:cho...@chopps.org>>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>; 
lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>
Subject: Re: [Lsr] Request WG adoption of TTZ



Hi Chris,



Thank you very much for your questions.

My answers/explanations are inline below with prefix [HC].



Best Regards,

Huaimo



From: Christian Hopps
Sent: Tuesday, July 7, 2020 8:08 AM
To: Huaimo Chen
Cc: Christian Hopps; lsr@ietf.org<mailto:lsr@ietf.org>; 
lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>
Subject: Re: [Lsr] Request WG adoption of TTZ



Hi Huaimo,

Can you speak to the differences of this with Area Proxy? They are similar 
solutions, right?



[HC]: There are some differences even though they looks similar.

At first, the target to be abstracted in Area Proxy is different from that in 
TTZ.

Area Proxy abstracts an existing area to a single pseudo node.

TTZ abstracts a zone to a single pseudo node. A zone is a piece or block of an 
area.

An area is different from a zone in general.



Secondly, the ways in which they are applied to an area for scalability are 
different.

When an area becomes bigger and bigger, we may have scalability issues. Using 
TTZ, we can abstract one or a few zones in the area to one or few pseudo nodes 
smoothly without any interface down. Using Area Proxy, we need split the 
existing area into multiple areas, and then abstract one or a few areas to one 
or few pseudo nodes.

These differences will produce different user experiences.

For splitting an existing area into multiple areas, users may need put more 
efforts since it causes service interruptions in general. While splitting an 
area such as an OSPF area into multiple areas, the area numbers configured on 
some interfaces will be changed and each of these interfaces will be down with 
its old area number and then up with its new area number. These interface downs 
and ups will cause service interruptions in general.

For defining zones in an area, users may need less efforts since abstracting a 
zone to a single pseu

Re: [Lsr] Request WG adoption of TTZ

2020-07-07 Thread Les Ginsberg (ginsberg)
Huaimo -

In regards to merging/splitting areas, IS-IS base protocol provides a way to do 
this hitlessly (this was discussed some years ago when IS-IS TTZ draft was 
first introduced).
So if the major difference/advantage between area-proxy and ttz is the ability 
to use zones to handle area merging/splitting this does not add much value in 
IS-IS.

Please consider this in your responses.

Thanx.

Les


From: Lsr  On Behalf Of Huaimo Chen
Sent: Tuesday, July 07, 2020 9:00 AM
To: Christian Hopps 
Cc: lsr@ietf.org; lsr-cha...@ietf.org
Subject: Re: [Lsr] Request WG adoption of TTZ

Hi Chris,

Thank you very much for your questions.
My answers/explanations are inline below with prefix [HC].

Best Regards,
Huaimo

From: Christian Hopps
Sent: Tuesday, July 7, 2020 8:08 AM
To: Huaimo Chen
Cc: Christian Hopps; lsr@ietf.org; 
lsr-cha...@ietf.org
Subject: Re: [Lsr] Request WG adoption of TTZ

Hi Huaimo,

Can you speak to the differences of this with Area Proxy? They are similar 
solutions, right?

[HC]: There are some differences even though they looks similar.
At first, the target to be abstracted in Area Proxy is different from that in 
TTZ.
Area Proxy abstracts an existing area to a single pseudo node.
TTZ abstracts a zone to a single pseudo node. A zone is a piece or block of an 
area.
An area is different from a zone in general.

Secondly, the ways in which they are applied to an area for scalability are 
different.
When an area becomes bigger and bigger, we may have scalability issues. Using 
TTZ, we can abstract one or a few zones in the area to one or few pseudo nodes 
smoothly without any interface down. Using Area Proxy, we need split the 
existing area into multiple areas, and then abstract one or a few areas to one 
or few pseudo nodes.
These differences will produce different user experiences.
For splitting an existing area into multiple areas, users may need put more 
efforts since it causes service interruptions in general. While splitting an 
area such as an OSPF area into multiple areas, the area numbers configured on 
some interfaces will be changed and each of these interfaces will be down with 
its old area number and then up with its new area number. These interface downs 
and ups will cause service interruptions in general.
For defining zones in an area, users may need less efforts since abstracting a 
zone to a single pseudo node is smooth without any interface down.

Moreover, TTZ provides smooth transferring between a zone and its single pseudo 
node. That is that a zone can be smoothly transferred to a single pseudo node, 
and the pseudo node can be smoothly rolled back to the zone.

BTW, In the Area Proxy draft, Area Proxy abstracts an existing IS-IS area to a 
single pseudo node.
In the TTZ draft, TTZ abstracts a zone in an OSPF area to a single pseudo node, 
and a zone in an IS-IS area to a single pseudo node.


There's an existing experimental track OSPF RFC (RFC8099) already for TTZ so i 
found it confusing to have this document also talking about TTZ for OSPF; is it 
redefining it, updating it, just referring to it?

[HC]: Regarding to TTZ for OSPF, OSPF RFC (RFC8099) describes a solution for 
abstracting a zone to the zone edges full mess. This document proposes a new 
solution for abstracting a zone to a single pseudo node. The new solution 
re-uses some of RFC 8099, to which are referred. The new extensions to OSPF for 
the new solution are defined in the document.

Thanks,
Chris.
[chair hat]


> On Jun 18, 2020, at 11:38 PM, Huaimo Chen 
> mailto:huaimo.c...@futurewei.com>> wrote:
>
> Hi Chris and Acee, and everyone,
>
>
>
> I would like to request working group adoption of "Topology-Transparent 
> Zone"
>
> (TTZ for short) https://datatracker.ietf.org/doc/draft-chen-isis-ttz/ .
>
>
>
> This draft comprises the following solutions for helping to improve 
> scalability:
>
> 1) abstracting a zone to a single pseudo node in IS-IS,
>
> 2) abstracting a zone to a single pseudo node in OSPF,
>
> 3) abstracting a zone to zone edges' full mess in IS-IS, and
>
> 4) transferring smoothly between a zone and a single pseudo node.
>
> A zone is a block of an area (IS-IS L2 or L1 area, OSPF backbone or
>
> non-backbone area).
>
>
>
> When a network area becomes (too) big, we can reduce its size in the sense
>
> of its LSDB size through abstracting a zone to a single pseudo node or
>
> abstracting a few zones to a few pseudo nodes.
>
>
>
> While a zone is being abstracted (or transferred) to a single pseudo node,
>
> the network is stable. There is no or minimum service interruption.
>
>
>
> After abstracting a few zones to a few pseudo nodes, if we want to 
> reconstruct
>
> them, we can transfer (or roll) any of the pseudo nodes back to its zone 
> smoothly
>
> with no or minimum service interruption.
>
>
>
> We had a prototype 

Re: [Lsr] Comments on Requested Codepoints for draft-li-lsr-isis-area-proxy

2020-06-29 Thread Les Ginsberg (ginsberg)
Tony –

Inline.

From: Tony Li  On Behalf Of tony...@tony.li
Sent: Monday, June 29, 2020 2:37 PM
To: Les Ginsberg (ginsberg) 
Cc: Hannes Gredler ; 
draft-li-lsr-isis-area-proxy.auth...@ietf.org; lsr@ietf.org
Subject: Re: [Lsr] Comments on Requested Codepoints for 
draft-li-lsr-isis-area-proxy



Hi Les,



On Jun 29, 2020, at 2:13 PM, Les Ginsberg (ginsberg) 
mailto:ginsb...@cisco.com>> wrote:

Tony –

OLD:
1)Area Proxy Router Capability - sub-TLV of Router Capability TLV

2)Inside Node TLV - Top level TLV

3)Area Proxy TLV - Top Level TLV with optional sub-TLVs:
   Sub-TLV Area Proxy System ID
   Sub-TLV Area Segment SID

4)Area Segment SID - Top Level TLV

NEW: (Please check my interpretation)

1)Area Proxy Router Capability - sub-TLV of Router Capability TLV

2)Area Proxy TLV - Top Level TLV with optional sub-TLVs:
   Sub-TLV Area Proxy System ID
   Sub-TLV Area Segment SID
   Sub-TLV Inside Node ???

3)Area Segment SID - Top Level TLV

Am I correct so far??


Yes, exactly.  Inside node would be a sub-TLV or a flag, TBD.


If so, a couple more comments/suggestions:

a)Could the Area Proxy TLV become a bit more generic and allow advertisement of 
the capability (implied by presence of the TLV)?
If  so, the Router Capability sub-TLV could go away.


Speaking just for myself, ok, that seems reasonable and doable.



b)If the Area Segment SID is (as you suggest) a generic thing not specific to 
Area Proxy, then I would point you to 
https://www.rfc-editor.org/rfc/rfc8667.html#section-2.4.1


?  Your pointer is to the flags field of the SID/Label Binding TLV.

[Les:] Yes – as the suggestion would be to add another flag definition.


This allows SIDs to be advertised in the SID Binding TLV for a special purpose 
(see the Mirror SID). One could imagine another flag bit to indicate this is an 
Area SID.


You’re suggesting a bit in the flags, the range would be unused, and a prefix 
length of 0? Then the actual SID would be in the SID/Label sub-TLV?

[Les:]Range could be specified as ignored in this case. Prefix length would be 
0.
The SID would be – as you say – advertised in the SID/Label sub-TLV – as with 
all other SIDs.


I think this would need to be vetted with SR  folks


That will happen, regardless of how we proceed.



– but I would like to avoid advertising a SID in a way different from all other 
SIDs i.e., SIDs currently are always a sub-TLV of some top level TLV – whether 
it be Prefix Reachability (Prefix-SID), IS Neighbor (Adjacency SID), or Binding 
SID (Mirror SID).


We were trying to extend the current design consistently with existing SIDs.  
As the Prefix SID and Adjacency SID were top level, it made sense to continue 
that approach.  The approach of the Binding SID TLV would seem to mix all 
semantics into one encoding and seems inconsistent and complicated with respect 
to the other SIDs.  If this was the intent, shouldn’t prefix and adjacency SIDs 
be encoded in this TLV as well?
[Les:] Prefix/adjacency SIDs are sub-TLVs of TLVs 135 and 22 respectively.

There’s only three available bits (plus one octet) here.  Aren’t we concerned 
about running out of bits if we go this direction?
[Les:] I am not. It is a question of whether SR sees this as a useful type of 
SID. If so, it merits a bit.

   Les

Tony

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


Re: [Lsr] Comments on Requested Codepoints for draft-li-lsr-isis-area-proxy

2020-06-29 Thread Les Ginsberg (ginsberg)
Tony –

OLD:
1)Area Proxy Router Capability - sub-TLV of Router Capability TLV

2)Inside Node TLV - Top level TLV

3)Area Proxy TLV - Top Level TLV with optional sub-TLVs:
   Sub-TLV Area Proxy System ID
   Sub-TLV Area Segment SID

4)Area Segment SID - Top Level TLV

NEW: (Please check my interpretation)

1)Area Proxy Router Capability - sub-TLV of Router Capability TLV

2)Area Proxy TLV - Top Level TLV with optional sub-TLVs:
   Sub-TLV Area Proxy System ID
   Sub-TLV Area Segment SID
   Sub-TLV Inside Node ???

3)Area Segment SID - Top Level TLV

Am I correct so far??

If so, a couple more comments/suggestions:

a)Could the Area Proxy TLV become a bit more generic and allow advertisement of 
the capability (implied by presence of the TLV)?
If  so, the Router Capability sub-TLV could go away.

b)If the Area Segment SID is (as you suggest) a generic thing not specific to 
Area Proxy, then I would point you to 
https://www.rfc-editor.org/rfc/rfc8667.html#section-2.4.1
This allows SIDs to be advertised in the SID Binding TLV for a special purpose 
(see the Mirror SID). One could imagine another flag bit to indicate this is an 
Area SID.
I think this would need to be vetted with SR  folks – but I would like to avoid 
advertising a SID in a way different from all other SIDs i.e., SIDs currently 
are always a sub-TLV of some top level TLV – whether it be Prefix Reachability 
(Prefix-SID), IS Neighbor (Adjacency SID), or Binding SID (Mirror SID).

   Les


From: Tony Li  On Behalf Of tony...@tony.li
Sent: Monday, June 29, 2020 12:52 PM
To: Hannes Gredler 
Cc: Les Ginsberg (ginsberg) ; 
draft-li-lsr-isis-area-proxy.auth...@ietf.org; lsr@ietf.org
Subject: Re: [Lsr] Comments on Requested Codepoints for 
draft-li-lsr-isis-area-proxy



Hi,

The authors have conferred and we would like to propose the following changes:

- The semantics of the Inside Node TLV will be folded into the Area Proxy TLV.

- The Area Proxy TLV will have its scope expanded to include pseudonodes.

- No change to the Area Segment SID TLV encoding.

Comments?   Especially from our Designated Experts?

Regards,
Sarah, Vivek, Gyan, and Tony



On Jun 25, 2020, at 12:04 PM, tony...@tony.li<mailto:tony...@tony.li> wrote:


Hi Hannes,

Thanks for your comments.  We will propose an alternate encoding.

Tony



On Jun 25, 2020, at 10:47 AM, Hannes Gredler 
mailto:han...@gredler.at>> wrote:

Hi Tony,

I do share Les’ concerns on burning top-level 8-bit code point space at this 
point.

At this point it is not me to judge wether CAP TLV or GENAPP TLV or something 
else should be a more appropriate place.
Please let's have a WG discussion on this.

Thanks,

/hannes


On 21.06.2020, at 18:50, tony...@tony.li<mailto:tony...@tony.li> wrote:


Les,

We don’t have to resolve this now.
One of my motivations for sending this was related to Early Allocation of code 
points. Since you have already asked once, I am assuming that if WG adoption is 
achieved it will be swiftly followed by an early allocation request – and as 
one of the Designated Experts I wanted to share my concerns sooner rather than 
later.


I appreciate that.  Do others share Les’ perspective on the relative tradeoffs? 
 Especially our other Desginated Experts?


Would this argue for advertising “this is a boundary circuit” in pseudo-node 
LSPs for boundary circuits rather than advertising “inside” on all inside 
pseudo-nodes?

You could do it that way.  It inverts the semantics and inverts the deployment. 
 Logically, it should have the same effect.  However, it then is seen by 
outside nodes.  Since they need not support Area Proxy, this seemed like a 
riskier approach, thus we opted for marking inside pseudonodes.

[Les:] My point was largely motivated by the statement in the draft:

“Area Proxy Boundary multi-access circuits (i.e.  Ethernets in LAN
   mode) with multiple Inside Edge Routers on them are not supported.”

So it seems advantageous to be able to prevent this from happening – which 
requires some signaling on the circuit in question.



I think that the case that you’re concerned about is already easily detected.  
Recall that an Inside Edge router will generate IIH’s onto a boundary circuit 
using the Proxy system ID.  Thus, if an Inside Edge router receives an IIH with 
a source address of it’s own proxy system id, then it has encountered this 
issue.

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] AD Review of draft-ietf-lsr-isis-invalid-tlv-01

2020-06-22 Thread Les Ginsberg (ginsberg)
Alvaro -

Thanx.
V2 of the draft has been posted. I believe it addresses all of your comments.

   Les


> -Original Message-
> From: Alvaro Retana 
> Sent: Monday, June 22, 2020 3:05 PM
> To: Les Ginsberg (ginsberg) ; draft-ietf-lsr-isis-invalid-
> t...@ietf.org
> Cc: lsr-cha...@ietf.org; lsr@ietf.org; Christian Hopps 
> Subject: RE: AD Review of draft-ietf-lsr-isis-invalid-tlv-01
> 
> On June 19, 2020 at 11:49:51 AM, Les Ginsberg wrote:
> 
> 
> Les:
> 
> Hi!
> 
> Just a couple of in-line answers.
> 
> We should be ready to move forward once you submit the update.
> 
> Thanks!!
> 
> Alvaro.
> 
> 
> ...
> > > I'm writing all this here to have a record of this decision and to
> > > give anyone in the WG the opportunity to raise concerns, if any.
> >
> > [Les:] Just to be sure I understand, you are documenting that we need do
> > nothing in this regard?
> 
> Correct.
> 
> 
> 
> ...
> > > [major] s/5304/5305 Is §3.2 intended to update rfc5304?
> >
> > [Les:] 3.2 updates RFC 5304 to the extent that it recommends controls for
> > behaviors that might not be backwards compatible. (Similar for RFC 6233)
> >
> > Section 3.3 clearly updates RFC 5305, so I have added that here.
> >
> > But it is a fair question to ask if RFC 5304 should be added to the list of
> > documents updated? It currently is NOT listed - which makes me wonder
> why
> > we include RFC 6233 in the list of updated documents.
> >
> > I am inclined to not include either in the list of updated documents.
> >
> > Please comment.
> 
> I agree that it is not necessary to formally Update either.
> 
> 
> 
> 
> ...
> > > [major] An important clarification, which I don't think is explicitly
> > > made, is that the behavior for unknown is being applied to disallowed.
> > > Not knowing and not expecting (= disallowed) are different things, but
> > > this document is saying that the document treats them the same:
> > > ignore. I think adding a sentence about that relationship would help
> > > a lot, and it may help us cover any cases that may have been missed (I
> > > don't think there are any, but just in case)...maybe something like
> > > this (I'm sure you can come up with much better words):
> > >
> > > This document extends the concept of unknown to disallowed.
> > >
> > >
> > > [major] Related to the last comment... The title of the document
> > > mentions "Invalid" TLVs. (1) there is no other mention of an invalid
> > > TLV in the text, and (2) there is no connection made between "invalid"
> > > (in the title) and "disallowed" (in the text).
> >
> >
> > [Les:] It seems to me that Section 3.1 is very clear on this point. I
> > prefer not to change/add text as you have suggested.
> >
> > I did add some examples of "invalid".
> 
> As long as it is clear to other reviewers that invalid, disallowed and
> unknown have the same behavior...we can go ahead with no changes.
> 
> 
> ...
> > [Les:] It isn’t clear to me that we have updated RFC3563 - unless you
> > presume that anything that alters the registries in any way is considered
> > an update to RFC 3563.
> >
> > RFC3563 created the registry based on RFC 3359 - which had the columns in
> > there.
> >
> > The description of the columns is present in this document to provide
> > context for the rest of the document. I don’t believe this description
> > represents any change to the registry.
> >
> > Specifically, we are not proposing that the registry be altered to include
> > the description.
> >
> > If you agree, should we then remove RFC 3563 from the list of RFCs
> updated
> > by this document??
> 
> 
> Yes, I agree.
> 
> BTW, this request..
> 
>    "IANA is requested to update the TLV Codepoints Registry to reference
>    this document."
> 
> ...is to add a reference to this document, and not to remove the others,
> right?
> 
> If so, then maybe "IANA is requested to add this document as a
> reference for the TLV Codepoints Registry." might be better.
> 
> 
> 
> ...
> > > 215 "The additional values for this TLV should be IIH:n, LSP:y, SNP:n,
> > > 216 and Purge:y. "
> > >
> > > [nit] s/y. "/y."
> >
> > [Les:] This is a direct quote from RFC6232.
> >
> > Sorry, you don’t get to edit it. 
> 
> Not editing the quote...just the extra space after the period. ;-)
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


Re: [Lsr] WG adoption call for draft-przygienda-lsr-flood-reflection-01

2020-06-21 Thread Les Ginsberg (ginsberg)
I support WG adoption of 
https://datatracker.ietf.org/doc/draft-przygienda-lsr-flood-reflection .



(I also support the WG adoption of  
https://datatracker.ietf.org/doc/draft-li-lsr-isis-area-proxy/ )



I believe the problem space addressed by these two drafts warrants attention.



I am not yet overly enthused about approaches which promote non-hierarchical 
network architectures. But it seems clear that there is interest in deploying 
non-hierarchical solutions and both drafts present solutions

which merit further evaluation.



The easy road for the WG to take would be to simply allow both drafts to 
proceed to Experimental RFCs, but I hope we are able to do more than this. 
Multiple solutions place undesirable burdens on vendors and providers alike.



To the extent they feel comfortable, I encourage folks who wish to deploy such 
solutions to share their requirements and discuss how each of the solutions

address their requirements/fall short of addressing their requirements. I think 
this would help the WG discover better ways forward.



   Les





> -Original Message-

> From: Lsr  On Behalf Of Christian Hopps

> Sent: Wednesday, June 10, 2020 12:29 PM

> To: lsr@ietf.org

> Cc: lsr-cha...@ietf.org; lsr-...@ietf.org; Christian Hopps

> 

> Subject: [Lsr] WG adoption call for draft-przygienda-lsr-flood-reflection-01

>

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

>

>   https://datatracker.ietf.org/doc/draft-przygienda-lsr-flood-reflection

>

> The draft would be adopted on the Experimental track.

>

> Please indicate your support or objection by June 24, 2020.

>

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

> IPR that applies to this draft.

>

> Thanks,

> Chris and Acee.

> ___

> Lsr mailing list

> Lsr@ietf.org

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


Re: [Lsr] WG adoption call for draft-li-lsr-isis-area-proxy-06

2020-06-21 Thread Les Ginsberg (ginsberg)
I support the WG adoption of  
https://datatracker.ietf.org/doc/draft-li-lsr-isis-area-proxy/ .

(I also support WG adoption of 
https://datatracker.ietf.org/doc/draft-przygienda-lsr-flood-reflection )

I believe the problem space addressed by these two drafts warrants attention.

I am not yet overly enthused about approaches which promote non-hierarchical 
network architectures. But it seems clear that there is interest in deploying 
non-hierarchical solutions and both drafts present solutions
which merit further evaluation.

The easy road for the WG to take would be to simply allow both drafts to 
proceed to Experimental RFCs, but I hope we are able to do more than this. 
Multiple solutions place undesirable burdens on vendors and providers alike.

To the extent they feel comfortable, I encourage folks who wish to deploy such 
solutions to share their requirements and discuss how each of the solutions
address their requirements/fall short of addressing their requirements. I think 
this would help the WG discover better ways forward.

   Les

> -Original Message-
> From: Lsr  On Behalf Of Christian Hopps
> Sent: Wednesday, June 10, 2020 12:28 PM
> To: lsr@ietf.org
> Cc: lsr-cha...@ietf.org; lsr-...@ietf.org; Christian Hopps
> 
> Subject: [Lsr] WG adoption call for draft-li-lsr-isis-area-proxy-06
> 
> This begins a 2 week WG adoption call for the following draft:
> 
>   https://datatracker.ietf.org/doc/draft-li-lsr-isis-area-proxy/
> 
> The draft would be adopted on the Experimental track.
> 
> Please indicate your support or objection by June 24, 2020.
> 
> Authors, please respond to the list indicating whether you are aware of any
> IPR that applies to this draft.
> 
> Thanks,
> Chris and Acee.
> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

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


Re: [Lsr] Comments on Requested Codepoints for draft-li-lsr-isis-area-proxy

2020-06-21 Thread Les Ginsberg (ginsberg)
Tony –

We don’t have to resolve this now.
One of my motivations for sending this was related to Early Allocation of code 
points. Since you have already asked once, I am assuming that if WG adoption is 
achieved it will be swiftly followed by an early allocation request – and as 
one of the Designated Experts I wanted to share my concerns sooner rather than 
later.

A few more responses inline.

From: Tony Li  On Behalf Of tony...@tony.li
Sent: Saturday, June 20, 2020 5:13 PM
To: Les Ginsberg (ginsberg) 
Cc: draft-li-lsr-isis-area-proxy.auth...@ietf.org; lsr@ietf.org
Subject: Re: Comments on Requested Codepoints for draft-li-lsr-isis-area-proxy


Hi Les,

Putting the Inside Node TLV aside for the moment, it would seem to me to be 
advantageous (in a modest way) to have all information relating to Area Proxy 
contained in one advertisement. Using Router Capabilities TLV would accomplish 
that.


I agree that the information should be contained, this is why we opted to put 
it all into one top level TLV.  Recall that only the Area Leader is advertising 
the Area Proxy TLV, while all inside nodes need the capability.

[Les:] My proposal does not alter what information is sent by Area 
leaders/non-Area leaders – just the container in which the information appears.


Your concern about “burdening” the Router Capabilities TLV seems unwarranted.


Given that we have 64k top level code points, I’m equally confused about your 
concern.

[Les:] Today, we only have 255 top level codepoints.
64K codepoints will only become available when the industry moves to RFC 7356 
based implementations and includes the 16 bit TLV Type/Length option.
While I would obviously like to see this happen, as it isn’t backwards 
compatible I expect we are still some years away from a “tectonic shift”.
And your draft does not propose moving to RFC 7356 as part of the feature (and 
I am not suggesting that it should).

At least part of the reason we still have sufficient available top level code 
points is that we do our collective best to use them judiciously.


Multiple Router Capability TLVs are allowed (indeed even required to support 
different flooding scopes) – so TLV space is not limited.


I expect that we will have numerous bug reports when we start to cross the TLV 
boundary.  I’m not in favor of pushing this.

 [Les:] We already enough info to advertise that one Router Capability TLV is 
not enough. Implementations that cannot handle multiple Router Capability TLVs 
are already busted.
Area Proxy by itself won’t force this to be exposed.

Returning to Inside Node TLV, I share your concern about advertising Router 
Capabilities TLV in pseudo-node LSP. But what does it mean to advertise the 
Inside Node TLV in a pseudo-node LSP?


It’s a clear indication that the pseudonode is intended to be inside.



Presumably you need some capability indicator because even on boundary circuits 
the DIS will use the native systemid rather than the proxy systemid and 
therefore you cannot tell based on pseudonode-id alone what type of circuit 
this is.


Correct. The DIS would have a very difficult time using the proxy systemid and 
assigning a unique circuit id for the pseduonode.  Some other system on the 
other side of the area could be making exactly the same choice, leading to a 
collision.  Thus, it seems simpler to use the native system id and explicitly 
signal that the pseudonode is inside.  I’ve become a pretty big fan of explicit 
signaling, as it’s more robust.

[Les:] Yes, I understand  and agree with your choice. There is no good way to 
manage the pseudo-node ID space in a distributed manner.


Would this argue for advertising “this is a boundary circuit” in pseudo-node 
LSPs for boundary circuits rather than advertising “inside” on all inside 
pseudo-nodes?


You could do it that way.  It inverts the semantics and inverts the deployment. 
 Logically, it should have the same effect.  However, it then is seen by 
outside nodes.  Since they need not support Area Proxy, this seemed like a 
riskier approach, thus we opted for marking inside pseudonodes.

[Les:] My point was largely motivated by the statement in the draft:

“Area Proxy Boundary multi-access circuits (i.e.  Ethernets in LAN
   mode) with multiple Inside Edge Routers on them are not supported.”

So it seems advantageous to be able to prevent this from happening – which 
requires some signaling on the circuit in question.


And do you need the “boundary circuit” indication in L2 IIHs (and perhaps P2P 
IIH as well??) as protection against improperly forming adjacencies on boundary 
circuits?


Not required if there is consistent configuration.  All inside nodes will be 
using the proxy system ID in their IIH.  If a node is inconsistently 
configured, then it is difficult to prevent at least one side from trying to 
form the adjacency.

[Les:] Yes – the key point here is “consistent configuration”. It seems useful 
to be able to detect/report mismatched configurations

Re: [Lsr] Comments on Requested Codepoints for draft-li-lsr-isis-area-proxy

2020-06-20 Thread Les Ginsberg (ginsberg)
Tony –

Thanx for the quick response.

Putting the Inside Node TLV aside for the moment, it would seem to me to be 
advantageous (in a modest way) to have all information relating to Area Proxy 
contained in one advertisement. Using Router Capabilities TLV would accomplish 
that.
Your concern about “burdening” the Router Capabilities TLV seems unwarranted.
Every capability currently defined comes with additional information.
Multiple Router Capability TLVs are allowed (indeed even required to support 
different flooding scopes) – so TLV space is not limited.

Returning to Inside Node TLV, I share your concern about advertising Router 
Capabilities TLV in pseudo-node LSP. But what does it mean to advertise the 
Inside Node TLV in a pseudo-node LSP?
Presumably you need some capability indicator because even on boundary circuits 
the DIS will use the native systemid rather than the proxy systemid and 
therefore you cannot tell based on pseudonode-id alone what type of circuit 
this is.

Would this argue for advertising “this is a boundary circuit” in pseudo-node 
LSPs for boundary circuits rather than advertising “inside” on all inside 
pseudo-nodes?

And do you need the “boundary circuit” indication in L2 IIHs (and perhaps P2P 
IIH as well??) as protection against improperly forming adjacencies on boundary 
circuits?

Regarding the Area SID advertisement, I take the point that this concept might 
be useful more generically, but as it is key to have the correct scope for the 
SID, it is hard to see how the advertisement could be used apart from the 
context (Area Proxy in this case). So advertising it separately doesn’t seem 
useful.

Regarding consistent SRGBs, you might find 
https://datatracker.ietf.org/doc/draft-ietf-spring-mpls-anycast-segments/ worth 
reading as something attempting to address a similar problem. It isn’t easy.

   Les


From: Tony Li  On Behalf Of tony...@tony.li
Sent: Saturday, June 20, 2020 1:41 PM
To: Les Ginsberg (ginsberg) 
Cc: draft-li-lsr-isis-area-proxy.auth...@ietf.org; lsr@ietf.org
Subject: Re: Comments on Requested Codepoints for draft-li-lsr-isis-area-proxy


Hi Les,

Thank you for your comments.  Please see my comments inline.


draft-li-lsr-isis-area-proxy-06  currently proposes the use of one new sub-TLV 
of Router Capabilities TLV and three new top level TLVs


It should probably be noted that the Area Segment SID is somewhat orthogonal to 
the rest of Area Proxy.   It could be conceivably be used without
Area Proxy, or with another solution.

It would not be unreasonable to consider the Area Segment SID to be a proposal 
logically independent of Area Proxy.  Thus, Area Proxy really is requesting two 
new top level TLVs.


1)Area Proxy Router Capability - sub-TLV of Router Capability TLV

2)Inside Node TLV - Top level TLV

3)Area Proxy TLV - Top Level TLV with optional sub-TLVs:
   Sub-TLV Area Proxy System ID
   Sub-TLV Area Segment SID

4)Area Segment SID - Top Level TLV


Comments:
This seems unnecessarily profligate in its consumption of top level TLV code 
points – something to which, as a Designated Expert for the IS-IS registries,  
I pay close attention.
I can imagine an alternative encoding which utilizes a single sub-TLV within 
the Router Capabilities TLV:

Area Proxy Router Capability sub-TLV

  Type: TBD
  Length: Variable
  Value: Flags + Optional sub-TLVs

1 octet of Flags:

  0 1 2 3 4 5 6 7
  +-+-+-+-+-+-+-+
  |I|L|P| RSVD  |
  +-+-+-+-+-+-+-+

I If set indicates Inside Node
L If set indicates capable of performing Area Leader functions
P If set indicates Proxy LSP advertisement
RSVD - for future allocation

Followed by optional sub-sub-TLVs

Sub-sub-TLV Area Proxy System ID
Sub-sub-TLV Area SID (Used only when P bit is set)

Please comment on this alternative.


One of the issues that drove us to introduce the Inside Node TLV was confusion 
about pseudonodes.  How does a node determine whether a pseudonode is Inside or 
Outside?  This is an important at flooding time because if it is Inside, it 
should be flooded externally.  We did not consider putting a router capability 
TLV into a pseudonode and opted for another top level TLV instead.

We chose to make the Area Proxy TLV a top level TLV because we felt that it was 
inappropriate to burden the Router Capabilities TLV with arbitrary amounts of 
additional data. In our humble opinion, the router capabilities TLV should be 
reserved for capabilities.  Yes, it’s true, we could put that data inside of 
the router capabilities TLV, but as we learned a long time ago with GUP, we can 
pretty much put anything anywhere. Just because we can doesn’t mean that we 
should.


Additional Questions:
It is not clear to me why Area SID requires two different advertisements :
1)As a sub-TLV of Area Proxy TLV and
2)As a top Level TLV in the Proxy LSP
Is it because you wanted a unique codepoint for the Proxy LSP advertisements?


We wanted the sub-TLV so that the Area Leader can distribute the value

[Lsr] Comments on Requested Codepoints for draft-li-lsr-isis-area-proxy

2020-06-20 Thread Les Ginsberg (ginsberg)
(NOTE: Comments below are mine alone - wearing both my WG member hat and my 
Designated Expert for IS-IS Registries Hat. They do not represent support for 
or against the draft itself.)



draft-li-lsr-isis-area-proxy-06  currently proposes the use of one new sub-TLV 
of Router Capabilities TLV and three new top level TLVs



1)Area Proxy Router Capability - sub-TLV of Router Capability TLV



2)Inside Node TLV - Top level TLV



3)Area Proxy TLV - Top Level TLV with optional sub-TLVs:

   Sub-TLV Area Proxy System ID

   Sub-TLV Area Segment SID



4)Area Segment SID - Top Level TLV





Comments:

This seems unnecessarily profligate in its consumption of top level TLV code 
points - something to which, as a Designated Expert for the IS-IS registries,  
I pay close attention.

I can imagine an alternative encoding which utilizes a single sub-TLV within 
the Router Capabilities TLV:



Area Proxy Router Capability sub-TLV



  Type: TBD

  Length: Variable

  Value: Flags + Optional sub-TLVs



1 octet of Flags:



  0 1 2 3 4 5 6 7

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

  |I|L|P| RSVD  |

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



I If set indicates Inside Node

L If set indicates capable of performing Area Leader functions

P If set indicates Proxy LSP advertisement

RSVD - for future allocation



Followed by optional sub-sub-TLVs



Sub-sub-TLV Area Proxy System ID

Sub-sub-TLV Area SID (Used only when P bit is set)



Please comment on this alternative.



Additional Questions:

It is not clear to me why Area SID requires two different advertisements :

1)As a sub-TLV of Area Proxy TLV and

2)As a top Level TLV in the Proxy LSP

Is it because you wanted a unique codepoint for the Proxy LSP advertisements?



With what I have proposed above, there is only one form of the Area SID 
advertisement but the indication of Proxy LSP is provided.







There is a statement regarding the SR Capabilities sub-TLV advertised by the 
Area Leader as having:



   "an SRGB identical to that advertised by all Inside Routers"



SR does not require all nodes to advertise identical SRGBs. Are you imposing

a new requirement in order to support SR and Area Proxy together? If so, what 
happens if all Inside Nodes do NOT advertise identical SRGBs?



   Les


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


Re: [Lsr] AD Review of draft-ietf-lsr-isis-invalid-tlv-01

2020-06-19 Thread Les Ginsberg (ginsberg)
Alvaro -



I will publish an update once we have converged on all your comments.

Responses inline.



> -Original Message-

> From: Alvaro Retana 

> Sent: Thursday, June 18, 2020 1:05 PM

> To: draft-ietf-lsr-isis-invalid-...@ietf.org

> Cc: Christian Hopps ; lsr-cha...@ietf.org; lsr@ietf.org

> Subject: AD Review of draft-ietf-lsr-isis-invalid-tlv-01

>

> Dear authors:

>

> First of all, thank you for taking on this work!



[Les:] And thank you for insisting that the draft be written. 



>

> I have some comments which I home will be easy to address -- please

> see in-line below.  I will wait for a revised ID before starting the

> IETF Last Call.

>

> Before getting into the specifics, idnits came up with this warning:

>

> =

>  (Using the creation date from RFC3563, updated by this document, for

>  RFC5378 checks: 2002-10-15)

>

>   -- The document seems to lack a disclaimer for pre-RFC5378 work, but may

>  have content which was first submitted before 10 November 2008.  If you

>  have contacted all the original authors and they are all willing to grant

>  the BCP78 rights to the IETF Trust, then this is fine, and you can ignore

>  this comment.  If not, you may need to add the pre-RFC5378 disclaimer.

>  (See the Legal Provisions document at

>  https://trustee.ietf.org/license-info for more information.)

> =

>

> This documents Updates several existing RFCs.  In general, the warning

> means that we need to ask the authors of those RFCs, if published

> before rfc5378, to grant BCP78 rights to the IETF Trust.  In this case

> only rfc3563 is affected.  rfc5305 is not included because Tony Li was

> one of the authors.

>

> rfc6233 already Updated rfc3563, and it didn't include the disclaimer

> for pre-RFC5378 work, which leads me to conclude that the BCP78 rights

> were already granted at that time.  IOW, we don't need the disclaimer

> for pre-RFC5378 work.

>

> I'm writing all this here to have a record of this decision and to

> give anyone in the WG the opportunity to raise concerns, if any.

>



[Les:] Just to be sure I understand, you are documenting that we need do 
nothing in this regard?



>

> Thanks!!

>

> Alvaro.

>

>

> [Line numbers from idnits.]

>

>

> ...

> 15Abstract

> ...

> 27  This document when approved updates RFC3563, RFC5305,

> RFC6232, and

> 28  RFC6233.

>

> [minor] s/This document when approved updates/This document updates



[Les:] Done



>

>

> ...

> 901.  Introduction

>

> 92  The Intermediate System to Intermediate System (IS-IS) protocol

> 93  utilizes Type/Length/Value (TLV) encoding for all content in the

> body

> 94  of Protocol Data Units (PDUs).  New extensions to the protocol are

> 95  supported by defining new TLVs.  In order to allow protocol

> 96  extensions to be deployed in a backwards compatible way an

> 97  implementation is required to ignore TLVs that it does not

> 98  understand.  This behavior is also applied to sub-TLVs, which are

> 99  contained within TLVs.

>

> [minor] Add references to ISO10589 and rfc5305 in this first

> paragraph: ...(IS-IS) protocol [ISO10589]...applied to sub-TLVs

> [RFC5305]...



[Les:] Done



>

>

> 101   A corollary to ignoring unknown TLVs is having the validation of

> PDUs

> 102   be independent from the validation of the TLVs contained in the

> PDU.

> 103   PDUs which are valid MUST be accepted even if an individual TLV

> 104   contained within that PDU is invalid in some way.

>

> [major] "MUST be accepted"   This is the behavior already specified in

> ISO10589, right?   If so, then we shouldn't make it Normative here;

> instead, s/MUST/must and add a reference to ISO10589.



[Les:] Done



>

> Including that reference makes the first sentence in the next

> paragraph unnecessary.



[Les:] Removed.



>

>

> 106   These behaviors are specified in existing protocol documents -

> 107   principally [ISO10589] and [RFC5305].  In addition, the set of TLVs

> 108   (and sub-TLVs) which are allowed in each PDU type is documented

> in

> 109   the TLV Codepoints Registry (

> https://www.iana.org/assignments/isis-

> 110   tlv-codepoints/isis-tlv-codepoints.xhtml ) established by [RFC3563]

> 111   and updated by [RFC6233] and [RFC7356].

>

> [minor] s/( 
> https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-

> codepoints.xhtml

> )/[TLV_CODEPOINTS]



[Les:] Done



>

>

> 113   This document is intended to clarify some aspects of existing

> 114   specifications and thereby reduce the occurrence of non-

> conformant

> 115   behavior seen in real world deployments.  Although behaviors

> 116  

Re: [Lsr] Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: (with DISCUSS and COMMENT)

2020-06-18 Thread Les Ginsberg (ginsberg)
John -

Yes - I like "Application-Specific" better. This matches the term we use 
throughout the documents.

Thanx.

Les

From: John E Drake 
Sent: Thursday, June 18, 2020 1:37 PM
To: Yingzhen Qu ; Les Ginsberg (ginsberg) 
; Les Ginsberg (ginsberg) 
; BRUNGARD, DEBORAH A ; 
The IESG 
Cc: lsr-cha...@ietf.org; aretana.i...@gmail.com; Acee Lindem (acee) 
; draft-ietf-isis-te-...@ietf.org; lsr@ietf.org
Subject: RE: [Lsr] Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: 
(with DISCUSS and COMMENT)

I had mentioned "Application Specific"

Yours Irrespectively,

John



Juniper Business Use Only
From: Yingzhen Qu mailto:yingzhen...@futurewei.com>>
Sent: Thursday, June 18, 2020 4:30 PM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; 
Les Ginsberg (ginsberg) 
mailto:ginsberg=40cisco@dmarc.ietf.org>>;
 BRUNGARD, DEBORAH A mailto:db3...@att.com>>; The IESG 
mailto:i...@ietf.org>>
Cc: lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>; 
aretana.i...@gmail.com<mailto:aretana.i...@gmail.com>; Acee Lindem (acee) 
mailto:a...@cisco.com>>; 
draft-ietf-isis-te-...@ietf.org<mailto:draft-ietf-isis-te-...@ietf.org>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Subject: Re: [Lsr] Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: 
(with DISCUSS and COMMENT)

[External Email. Be cautious of content]

Hi Les,

The proposed new titles are much better than the old ones. I'm debating between 
"application-scoped" and "application-based", but no strong opinion. It's up to 
you and Peter to decide a good name.

Thanks,
Yingzhen

From: "Les Ginsberg (ginsberg)" mailto:ginsb...@cisco.com>>
Date: Thursday, June 18, 2020 at 11:04 AM
To: Yingzhen Qu mailto:yingzhen...@futurewei.com>>, 
"Les Ginsberg (ginsberg)" 
mailto:ginsberg=40cisco@dmarc.ietf.org>>,
 "BRUNGARD, DEBORAH A" mailto:db3...@att.com>>, The IESG 
mailto:i...@ietf.org>>
Cc: "lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>" 
mailto:lsr-cha...@ietf.org>>, 
"aretana.i...@gmail.com<mailto:aretana.i...@gmail.com>" 
mailto:aretana.i...@gmail.com>>, "Acee Lindem (acee)" 
mailto:a...@cisco.com>>, 
"draft-ietf-isis-te-...@ietf.org<mailto:draft-ietf-isis-te-...@ietf.org>" 
mailto:draft-ietf-isis-te-...@ietf.org>>, 
"lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>
Subject: RE: [Lsr] Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: 
(with DISCUSS and COMMENT)

Yingzhen -

Thanx for providing the YANG example - and for taking on the additions to the 
IGP YANG models.

Regarding changing the titles of the documents, I see your point. The work 
started because of issues related to different TE applications (RSVP-TE and SR 
Policy) - but you are correct that the solution provided can be used by 
applications that are NOT TE related.

Peter and I are still mulling this over, but how about these for new titles?

IS-IS Application-Scoped Link Attributes
OSPF Application-Scoped Link Attributes

   Les




From: Yingzhen Qu mailto:yingzhen...@futurewei.com>>
Sent: Wednesday, June 17, 2020 11:29 PM
To: Les Ginsberg (ginsberg) 
mailto:ginsberg=40cisco@dmarc.ietf.org>>;
 BRUNGARD, DEBORAH A mailto:db3...@att.com>>; The IESG 
mailto:i...@ietf.org>>
Cc: lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>; 
aretana.i...@gmail.com<mailto:aretana.i...@gmail.com>; Acee Lindem (acee) 
mailto:a...@cisco.com>>; 
draft-ietf-isis-te-...@ietf.org<mailto:draft-ietf-isis-te-...@ietf.org>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Subject: Re: [Lsr] Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: 
(with DISCUSS and COMMENT)

Hi Deborah and Les,

>From YANG model's perspective, whether there is a default value is based on 
>the protocol definition and it is optional. For this case, if there is no 
>default value the following could be an example YANG definition:

  choice te-app-op-mode {
mandatory "true";
leaf legacy {
  type empty;
}
leaf transition {
  type empty;
}
leaf app-specific{
  type empty;
}
description
  "Link attributes mode.";
  }

"mandatory true" is used here to make this configuration mandatory, which means 
implementations supporting this draft need to explicitly config the operation 
mode. I'll add the YANG support of this feature for both OSPF and ISIS into the 
next version of the augmentation drafts.
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-yang-augmentation-v1/<https://urldefense.com/v3/__https:/nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fdraft-ietf-lsr-ospf-yang-augmentation-v1*2F=02*7C01*7Cyingzhen.qu*40futurewei.com*7Cebfff0c

Re: [Lsr] Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: (with DISCUSS and COMMENT)

2020-06-18 Thread Les Ginsberg (ginsberg)
Yingzhen –

Thanx for providing the YANG example – and for taking on the additions to the 
IGP YANG models.

Regarding changing the titles of the documents, I see your point. The work 
started because of issues related to different TE applications (RSVP-TE and SR 
Policy) – but you are correct that the solution provided can be used by 
applications that are NOT TE related.

Peter and I are still mulling this over, but how about these for new titles?

IS-IS Application-Scoped Link Attributes
OSPF Application-Scoped Link Attributes

   Les




From: Yingzhen Qu 
Sent: Wednesday, June 17, 2020 11:29 PM
To: Les Ginsberg (ginsberg) ; BRUNGARD, 
DEBORAH A ; The IESG 
Cc: lsr-cha...@ietf.org; aretana.i...@gmail.com; Acee Lindem (acee) 
; draft-ietf-isis-te-...@ietf.org; lsr@ietf.org
Subject: Re: [Lsr] Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: 
(with DISCUSS and COMMENT)

Hi Deborah and Les,

From YANG model’s perspective, whether there is a default value is based on the 
protocol definition and it is optional. For this case, if there is no default 
value the following could be an example YANG definition:

  choice te-app-op-mode {
mandatory "true";
leaf legacy {
  type empty;
}
leaf transition {
  type empty;
}
leaf app-specific{
  type empty;
}
description
  "Link attributes mode.";
  }

“mandatory true” is used here to make this configuration mandatory, which means 
implementations supporting this draft need to explicitly config the operation 
mode. I’ll add the YANG support of this feature for both OSPF and ISIS into the 
next version of the augmentation drafts.
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-yang-augmentation-v1/
https://datatracker.ietf.org/doc/draft-acee-lsr-isis-yang-augmentation-v1/

BTW, I’m now wondering whether the title of the draft is precise? Instead of 
“IS-IS TE Attributes per application”, maybe something like “IS-IS per 
application link attributes”? considering more applications will be using the 
sub-TLV and they may not be TE. Same for OSPF.

Thanks,
Yingzhen

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of "Les 
Ginsberg (ginsberg)" 
mailto:ginsberg=40cisco@dmarc.ietf.org>>
Date: Wednesday, June 17, 2020 at 4:19 PM
To: "BRUNGARD, DEBORAH A" mailto:db3...@att.com>>, The IESG 
mailto:i...@ietf.org>>
Cc: "lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>" 
mailto:lsr-cha...@ietf.org>>, 
"aretana.i...@gmail.com<mailto:aretana.i...@gmail.com>" 
mailto:aretana.i...@gmail.com>>, "Acee Lindem (acee)" 
mailto:a...@cisco.com>>, 
"draft-ietf-isis-te-...@ietf.org<mailto:draft-ietf-isis-te-...@ietf.org>" 
mailto:draft-ietf-isis-te-...@ietf.org>>, 
"lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>
Subject: Re: [Lsr] Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: 
(with DISCUSS and COMMENT)
Resent-From: mailto:yingzhen...@huawei.com>>

Deborah –

We have a protocol extension that provides alternative ways of supporting 
legacy applications.

Under the conditions noted in Section 6.1, implementations have a choice as to 
which advertisements they use.
There is nothing in the document to specify which choice is the default – nor 
should there be.
To do so  implies that you believe that an implementation which is otherwise 
compliant (i.e., it sends/receives TLVs in accordance with the specification) 
could or should be considered in violation of the specification because it 
chose to use new advertisements as the default with an option to select legacy 
advertisements rather than use legacy advertisements as the default with an 
option to use new advertisements.

Further, what makes sense to be the default – from a user convenience POV - is 
likely to change over time. Initially the existence of legacy routers will be 
large and the upgraded routers few. This argues for legacy being the default. 
But a few years down the road and the numbers will be reversed – in which case 
the “better” default will be “new”. Declaring conformant implementations in 
violation simply because they decide to align their defaults with their most 
common deployment scenarios seems like unreasonable punishment.

There are certainly past examples – not least of which is the introduction of 
the “extended” TLVs in RFC 5305 - which have followed a similar path. Initially 
it made sense to default to old style advertisements – but over time it made 
more sense to default to new advertisements.
Note that RFC 5305 was silent on this – which in my opinion is correct and what 
we should do here.

I also take issue with your assumption that a default MUST be specified in the 
corresponding YANG model. I am far from a YANG expert – and will happily defer 
to those with more experience – but I see no reaso

Re: [Lsr] Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: (with DISCUSS and COMMENT)

2020-06-17 Thread Les Ginsberg (ginsberg)
Deborah –

We have a protocol extension that provides alternative ways of supporting 
legacy applications.

Under the conditions noted in Section 6.1, implementations have a choice as to 
which advertisements they use.
There is nothing in the document to specify which choice is the default – nor 
should there be.
To do so  implies that you believe that an implementation which is otherwise 
compliant (i.e., it sends/receives TLVs in accordance with the specification) 
could or should be considered in violation of the specification because it 
chose to use new advertisements as the default with an option to select legacy 
advertisements rather than use legacy advertisements as the default with an 
option to use new advertisements.

Further, what makes sense to be the default – from a user convenience POV - is 
likely to change over time. Initially the existence of legacy routers will be 
large and the upgraded routers few. This argues for legacy being the default. 
But a few years down the road and the numbers will be reversed – in which case 
the “better” default will be “new”. Declaring conformant implementations in 
violation simply because they decide to align their defaults with their most 
common deployment scenarios seems like unreasonable punishment.

There are certainly past examples – not least of which is the introduction of 
the “extended” TLVs in RFC 5305 - which have followed a similar path. Initially 
it made sense to default to old style advertisements – but over time it made 
more sense to default to new advertisements.
Note that RFC 5305 was silent on this – which in my opinion is correct and what 
we should do here.

I also take issue with your assumption that a default MUST be specified in the 
corresponding YANG model. I am far from a YANG expert – and will happily defer 
to those with more experience – but I see no reason why this cannot be modeled 
as a leaf which can take on one enumerated value – but there need not be a 
default. It is simply required to have a value.

A few more comments inline.


From: BRUNGARD, DEBORAH A 
Sent: Wednesday, June 17, 2020 1:07 PM
To: Les Ginsberg (ginsberg) ; The IESG 
Cc: draft-ietf-isis-te-...@ietf.org; lsr-cha...@ietf.org; lsr@ietf.org; Acee 
Lindem (acee) ; aretana.i...@gmail.com
Subject: RE: Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: (with 
DISCUSS and COMMENT)

Les-

To shortcut the discussion on the need for adding a default for “control”, 
these two sections are inconsistent as currently worded:

Section 6.1.1
Specifies for SR Policy and/or LFA applications: “This will require 
implementations to provide controls specifying which type of advertisements are 
to be sent/processed on receive for these applications.”

Section 6.3.3.

“2)Enable the use of the application specific advertisements on all Routers”



[Les:] What is being described here is a “hitless transition strategy”. It is 
wrong to assume that the use of “enable” here means that the default is 
“disable”.

This is the action taken in Step 2 after you started (Step 1) by using legacy 
only.

None of this says or implies anything about what defaults are nor what config 
commands (if any) were needed to place the box in the state specified at Step 1.



This document is not a vendor configuration guide – and I do not want to make 
it one.



Les





If one is “enabling” then the default is “OFF”? So this document already 
assumes it. I don’t understand the reluctance to add also to section 6.1.1. 
When the YANG model is defined, this will be the config default. So either you 
specify now or later – later, may result in every vendor/platform having a 
different default if they don’t read section 6.3.3. That will be a major 
interoperability problem – even potentially among the same vendor for different 
platforms.



This same comment is for the OSPF document – it needs to specify a default.



More notes below.

Thanks,
Deborah

[Les:] “Legacy” refers to routers which do not support the extensions defined 
in this document.
“Legacy advertisements” are explicitly listed in Section 3.
“Legacy advertisements” have been used (prior to this draft) in support of all 
of the applications discussed in this draft (RSVP-TE, SRTE (renamed to SR 
Policy as per your comment), and LFA) because there was nothing else available.
There is no intent to “upgrade RSVP-TE”. The new encodings can be used by 
RSVP-TE (as discussed in Sections 6.3.4) – but this is not a main motivation 
for the draft and if it never happens (i.e., RSVP-TE implementations continue 
to use legacy advertisements) that is fine.
[Deborah:]
Ok, but I still agree with Bruno – this is very confusing on what is being 
referenced, especially what needs to be done for RSVP-TE deployments. The 
addition of the default=off will clarify RSVP-TE deployments remain the same.

[Les:]
It is not an update to RFC 5305.
As an analogy, are you suggesting that RFC 5120 should be considered  an update 
to RFC 5305 because

Re: [Lsr] [Last-Call] Opsdir telechat review of draft-ietf-ospf-te-link-attr-reuse-14

2020-06-17 Thread Les Ginsberg (ginsberg)
draft-ietf-isis-te-app-17 has been posted with this change.

   Les


> -Original Message-
> From: Scott O. Bradner 
> Sent: Wednesday, June 17, 2020 8:53 AM
> To: Les Ginsberg (ginsberg) 
> Cc: Rob Wilton (rwilton) ; Peter Psenak
> ; Benjamin Kaduk
> ; lsr@ietf.org; ops-...@ietf.org; last-c...@ietf.org; draft-
> ietf-ospf-te-link-attr-reuse@ietf.org
> Subject: Re: [Last-Call] Opsdir telechat review of 
> draft-ietf-ospf-te-link-attr-
> reuse-14
> 
> I'm fine if both documents have the text
> 
> thanks
> 
> 
> Scott
> 
> > On Jun 17, 2020, at 10:56 AM, Les Ginsberg (ginsberg)
>  wrote:
> >
> > Rob -
> >
> > IS-IS draft currently states:
> >
> > "User Defined Application Identifier Bits have no relationship to
> >   Standard Application Identifier Bits and are not managed by IANA or
> >   any other standards body."
> >
> > (OSPF has this text also.)
> >
> > I am happy enough to include an additional statement similar to the OSPF
> text below in Section 4.
> >
> > Scott can speak for himself of course - but not clear to me that this really
> satisfies him since his comment was on the OSPF draft that already had this
> text.
> >
> > And not clear that this would make Ben (copied) any more comfortable
> since his concern (clarified in his most recent post) is about discussing
> allocation of the UDA bit space.
> >
> > But I will add the text - it makes the two drafts closer in content - which 
> > has
> been an ongoing goal during the review process.
> >
> > Thanx.
> >
> >   Les
> >
> >
> >> -Original Message-
> >> From: Rob Wilton (rwilton) 
> >> Sent: Wednesday, June 17, 2020 5:09 AM
> >> To: Peter Psenak ; Les Ginsberg
> >> (ginsberg) 
> >> Cc: lsr@ietf.org; draft-ietf-ospf-te-link-attr-reuse@ietf.org; ops-
> >> d...@ietf.org; last-c...@ietf.org; Scott O. Bradner 
> >> Subject: RE: [Last-Call] Opsdir telechat review of draft-ietf-ospf-te-link-
> attr-
> >> reuse-14
> >>
> >> Hi Les,
> >>
> >> Would you be opposed to adding text similar to the OSPF paragraph
> below to
> >> the ISIS draft?
> >>
> >> I think that the OSPF draft does a better job of first introducing UDAs.
> Having
> >> just looked at the ISIS draft, it does seem to somewhat assume that the
> >> reader will just know what they are ...
> >>
> >> I understand that this should resolve Scott's concerns.
> >>
> >> Regards,
> >> Rob
> >>
> >>
> >>> -Original Message-
> >>> From: last-call  On Behalf Of Scott O.
> Bradner
> >>> Sent: 15 June 2020 11:17
> >>> To: Peter Psenak 
> >>> Cc: lsr@ietf.org; draft-ietf-ospf-te-link-attr-reuse@ietf.org; ops-
> >>> d...@ietf.org; last-c...@ietf.org
> >>> Subject: Re: [Last-Call] Opsdir telechat review of draft-ietf-ospf-te-
> >>> link-attr-reuse-14
> >>>
> >>> that looks just fine to me - thanks
> >>>
> >>> Scott
> >>>
> >>>> On Jun 15, 2020, at 5:14 AM, Peter Psenak
> >>>  wrote:
> >>>>
> >>>> Hi Scott.
> >>>>
> >>>> there is a following text in the OSPF draft:
> >>>>
> >>>> "On top of advertising the link attributes for standardized
> >>>>  applications, link attributes can be advertised for the purpose of
> >>>>  applications that are not standardized.  We call such an
> >>>>  application a "User Defined Application" or "UDA".  These
> >>>>  applications are not subject to standardization and are outside of
> >>>>  the scope of this specification."
> >>>>
> >>>> Feel free to propose an additional text if you feel above is not
> >>> sufficient.
> >>>>
> >>>> thanks,
> >>>> Peter
> >>>>
> >>>>
> >>>>
> >>>> On 14/06/2020 21:22, Scott Bradner via Datatracker wrote:
> >>>>> Reviewer: Scott Bradner
> >>>>> Review result: Ready
> >>>>> I have reviewed the latest version of this document and my earlier
> >>> issues have
> >>>>> been resolved at least well enough for teh document to be
> considered
> >>> ready for
> >>>>> publication.
> >>>>> that said I still do not see where "User Defined Application
> >>> Identifier" is
> >>>>> actually cleanly defined - one can read carefully and determine but it
> >>> would be
> >>>>> easier on the reader to just say that it is a field that can be used to
> >>>>> indicate the use of one or more non-standard applications within
> some
> >>> scope
> >>>>> (network, subnet, link, organization, ... not sure what scopes are
> >>> meaningful
> >>>>> here but it does not seem that a User Defined Application Identifier
> >>> would be a
> >>>>> global (between network operators) value
> >>>>> Scott
> >>>>
> >>>> --
> >>>> last-call mailing list
> >>>> last-c...@ietf.org
> >>>> https://www.ietf.org/mailman/listinfo/last-call
> >>>
> >>> --
> >>> last-call mailing list
> >>> last-c...@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/last-call
> >
> > --
> > last-call mailing list
> > last-c...@ietf.org
> > https://www.ietf.org/mailman/listinfo/last-call

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


Re: [Lsr] [Last-Call] Opsdir telechat review of draft-ietf-ospf-te-link-attr-reuse-14

2020-06-17 Thread Les Ginsberg (ginsberg)
Rob -

IS-IS draft currently states:

"User Defined Application Identifier Bits have no relationship to
   Standard Application Identifier Bits and are not managed by IANA or
   any other standards body."

(OSPF has this text also.)

I am happy enough to include an additional statement similar to the OSPF text 
below in Section 4.

Scott can speak for himself of course - but not clear to me that this really 
satisfies him since his comment was on the OSPF draft that already had this 
text.

And not clear that this would make Ben (copied) any more comfortable since his 
concern (clarified in his most recent post) is about discussing allocation of 
the UDA bit space.

But I will add the text - it makes the two drafts closer in content - which has 
been an ongoing goal during the review process.

Thanx.

   Les


> -Original Message-
> From: Rob Wilton (rwilton) 
> Sent: Wednesday, June 17, 2020 5:09 AM
> To: Peter Psenak ; Les Ginsberg
> (ginsberg) 
> Cc: lsr@ietf.org; draft-ietf-ospf-te-link-attr-reuse@ietf.org; ops-
> d...@ietf.org; last-c...@ietf.org; Scott O. Bradner 
> Subject: RE: [Last-Call] Opsdir telechat review of 
> draft-ietf-ospf-te-link-attr-
> reuse-14
> 
> Hi Les,
> 
> Would you be opposed to adding text similar to the OSPF paragraph below to
> the ISIS draft?
> 
> I think that the OSPF draft does a better job of first introducing UDAs.  
> Having
> just looked at the ISIS draft, it does seem to somewhat assume that the
> reader will just know what they are ...
> 
> I understand that this should resolve Scott's concerns.
> 
> Regards,
> Rob
> 
> 
> > -Original Message-
> > From: last-call  On Behalf Of Scott O. Bradner
> > Sent: 15 June 2020 11:17
> > To: Peter Psenak 
> > Cc: lsr@ietf.org; draft-ietf-ospf-te-link-attr-reuse@ietf.org; ops-
> > d...@ietf.org; last-c...@ietf.org
> > Subject: Re: [Last-Call] Opsdir telechat review of draft-ietf-ospf-te-
> > link-attr-reuse-14
> >
> > that looks just fine to me - thanks
> >
> > Scott
> >
> > > On Jun 15, 2020, at 5:14 AM, Peter Psenak
> >  wrote:
> > >
> > > Hi Scott.
> > >
> > > there is a following text in the OSPF draft:
> > >
> > >  "On top of advertising the link attributes for standardized
> > >   applications, link attributes can be advertised for the purpose of
> > >   applications that are not standardized.  We call such an
> > >   application a "User Defined Application" or "UDA".  These
> > >   applications are not subject to standardization and are outside of
> > >   the scope of this specification."
> > >
> > > Feel free to propose an additional text if you feel above is not
> > sufficient.
> > >
> > > thanks,
> > > Peter
> > >
> > >
> > >
> > > On 14/06/2020 21:22, Scott Bradner via Datatracker wrote:
> > >> Reviewer: Scott Bradner
> > >> Review result: Ready
> > >> I have reviewed the latest version of this document and my earlier
> > issues have
> > >> been resolved at least well enough for teh document to be considered
> > ready for
> > >> publication.
> > >> that said I still do not see where "User Defined Application
> > Identifier" is
> > >> actually cleanly defined - one can read carefully and determine but it
> > would be
> > >> easier on the reader to just say that it is a field that can be used to
> > >> indicate the use of one or more non-standard applications within some
> > scope
> > >> (network, subnet, link, organization, ... not sure what scopes are
> > meaningful
> > >> here but it does not seem that a User Defined Application Identifier
> > would be a
> > >> global (between network operators) value
> > >> Scott
> > >
> > > --
> > > last-call mailing list
> > > last-c...@ietf.org
> > > https://www.ietf.org/mailman/listinfo/last-call
> >
> > --
> > last-call mailing list
> > last-c...@ietf.org
> > https://www.ietf.org/mailman/listinfo/last-call

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


Re: [Lsr] Opsdir telechat review of draft-ietf-ospf-te-link-attr-reuse-14

2020-06-17 Thread Les Ginsberg (ginsberg)
Ben -

Inline.

> -Original Message-
> From: Benjamin Kaduk 
> Sent: Tuesday, June 16, 2020 7:22 PM
> To: Les Ginsberg (ginsberg) 
> Cc: Scott Bradner ; ops-...@ietf.org; draft-ietf-ospf-te-
> link-attr-reuse@ietf.org; lsr@ietf.org; last-c...@ietf.org
> Subject: Re: Opsdir telechat review of draft-ietf-ospf-te-link-attr-reuse-14
> 
> Hi Les, Scott, Peter,
> 
> I appreciate the text about "not subject to standardization and are outside
> of the scope of this specification".  That said (inline),
> 
> On Sun, Jun 14, 2020 at 09:14:49PM +, Les Ginsberg (ginsberg) wrote:
> > Scott -
> >
> > Allow me to inject myself here. As editor of the companion IS-IS document
> (draft-ietf-isis-te-app) I have received similar comments - for example from
> Ben (copied on this thread).
> >
> > I continue to be at a loss as to why you believe we have to say something
> about User Defined Applications beyond what we have already said:
> >
> > "User Defined Application Identifier Bits have no relationship to
> >Standard Application Identifier Bits and are not managed by IANA or
> >any other standards body."
> >
> > If you do a search through both documents using "standard app" and "user
> defined app" I think you will find equivalent statements about both. Which
> means you are asking for some text regarding UDAs that doesn’t exist for
> SAs.
> > Why?
> 
> We give instructions to IANA for how to managed the Standard Application
> Identifier Bits.  Is it fair to give guidance to the entity assigning User
> Defined Application Identifier Bits (whomever that may be) about things
> they might want to consider while doing so?  A "several ways to not shoot
> yourself in the foot" guide, as it were, even though such a guide is
> inherently incomplete.  If there is nothing useful to say and the key
> factors are pretty inherent in how IS-IS/OSPF work, that's fine.  But the
> "warnings about potential 'gotcha's" directed at the party assigning UAI
> bits is the main topic I was trying to get at in my remarks on the
> analogous part of the IS-IS document.
> 

[Les:] There is no standards body assigning UDA bits. As we say above:

" not managed by IANA or  any other standards body."

As the applications are "User Defined" I would assume the "user" will have to 
decide what bits they want to use and how to insure they don’t conflict with 
other applications the same user defines.

The point of "User Defined" (as we keep saying) is that the user has complete 
control. There is no requirement that two different users have any 
compatibility at all.
If multiple users want interoperability, then they should use a standardized 
application.
Of course, there is nothing to stop two users from cooperating, but now we are 
in the "wild-wild-west" where people create ad-hoc definitions w/o any 
standardization.
For whatever reason, they rejected IETF/IANA and decided to manage their own ID 
space. This is beyond our control.

There is no intent, for example, to have IANA manage UDA space on behalf of 
"Experimental Applications".
We have simply provided an encoding syntax for UDAs to be advertised in the 
same link attribute sub-TLVs that include SA. What users put into UDABM and 
what applications are supported by UDABM is out of scope.

I really don’t think there is anything meaningful to say.

   Les




> Sorry for having made my point so circuitously.
> 
> -Ben
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


Re: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-isis-te-app-14: (with DISCUSS and COMMENT)

2020-06-15 Thread Les Ginsberg (ginsberg)
Ben -

V16 has been published addressing your comments on the new registry.

At this point I am not planning any additional changes to the document.

If you still want to discuss UDA related issues (or anything else), please let 
me know.

Thanx.

Les


> -Original Message-
> From: Benjamin Kaduk 
> Sent: Saturday, June 13, 2020 12:03 PM
> To: Les Ginsberg (ginsberg) 
> Cc: The IESG ; draft-ietf-isis-te-...@ietf.org; lsr-
> cha...@ietf.org; lsr@ietf.org; Acee Lindem (acee) ;
> aretana.i...@gmail.com
> Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-isis-te-app-14: (with
> DISCUSS and COMMENT)
> 
> Also inline.
> 
> On Sat, Jun 13, 2020 at 05:01:41PM +, Les Ginsberg (ginsberg) wrote:
> > Ben -
> >
> > Inline.
> >
> > > -Original Message-
> > > From: Benjamin Kaduk 
> > > Sent: Friday, June 12, 2020 9:15 PM
> > > To: Les Ginsberg (ginsberg) 
> > > Cc: The IESG ; draft-ietf-isis-te-...@ietf.org; lsr-
> > > cha...@ietf.org; lsr@ietf.org; Acee Lindem (acee) ;
> > > aretana.i...@gmail.com
> > > Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-isis-te-app-14: (with
> > > DISCUSS and COMMENT)
> > >
> > > On Fri, Jun 12, 2020 at 07:45:00PM +, Les Ginsberg (ginsberg) wrote:
> > > > Ben -
> > > >
> > > > Top posting the open issues - as I think there are only two.
> > > >
> > > > Issue #1
> > > >
> > > > > > What is the scope over which the user-defined application bits are
> > > > > > defined/allocated?
> > > > >
> > > >
> > > > LES: User defined applications are - by definition - outside the scope 
> > > > of
> this
> > > document/standardization.
> > >
> > > Yes.
> > >
> > > > We have simply defined the syntax of how to advertise associated bit
> > > mask.
> > >
> > > But if my implementation is built around (say) the meanings of the bits in
> > > the bit mask being local to a single area, and your implementation is 
> > > built
> > > around them having meaning local to a full domain, when you try to send
> me
> > > something from out of area it's not going to work so well.  Even without
> > > saying what any given bit means, we can still say that "all systems in the
> > > same  need to interpret each bit in the same way.  What is the
> smallest
> > >  such that deployment is safe?
> > >
> > > > How, for example, interoperability is achieved is up to implementors.
> > > > Whether they want an application to be area scoped or domain-wide is
> also
> > > up to them.
> > >
> > > I think leaving the question of area vs. domain up to the application is a
> > > recipe for interop failures.
> > >
> > > (A similar question presumably applies to the OSPF document, though I
> > > didn't get a chance to actually review that one.)
> > >
> >
> > [Les:] If interoperability between implementations is a concern, then the
> obvious choice is to use a standardized application.
> >
> > Placing limits on the scope of a user defined application is both 
> > unnecessary
> and unenforceable. I say "unenforceable" because, if you have a mixed
> vendor network, there is no guarantee that User Bit X means the same thing
> to both implementations. And since I cannot tell the identity of the
> implementation originating an advertisement, I cannot tell if the User Bit
> advertised in Area Scoped LSPs (Level-1 in IS-IS speak) has the same meaning
> as the same bit advertised in Domain-wide LSPs. So I cannot detect when a
> violation occurs.
> 
> I see your point about being able to "detect a violation".  That you are
> focusing on this aspect makes me suspect that my point did not come across
> quite as intended, though.  I don't feel a need to make a normative
> statement like "User Bits MUST be agreed upon at Domain-wide scope",
> since
> if anything that's trying to place a requirement on the operator, and our
> role is mostly just to inform the operator so they can make their own
> decisions.  As such, I'd be thinking more along the lines of "when
> user-defined bits are used, all routers that receive such information have
> to agree on their meaning, or breakage can occur.  Minimally, this implies
> that all machines in a given area need to use the same mapping of user-bit
> to application, and it's safest to ensure agreement across the entire
> domain."  (But with more wordsmithing, of course.)

Re: [Lsr] [Last-Call] Opsdir telechat review of draft-ietf-ospf-te-link-attr-reuse-14

2020-06-14 Thread Les Ginsberg (ginsberg)
Scott -

I hear and respect your choice to end this thread.

One point of clarification - no response is required or expected.

The definition I mentioned ("to provide the opportunity for 
proprietary/experimental applications") is simply my POV. This was never 
discussed in the WG. While this might be easy for you and I to agree on, I 
don’t feel comfortable introducing a definition that was never discussed.

The difference between you and I seems to be that you feel the document is 
incomplete without such a statement - while I feel it is unnecessary to the 
document. Everyone should free to consider use cases for UDA in whatever manner 
they feel is best.

Despite our lack of agreement, I do appreciate the time and thoughtfulness you 
put into the review. Thanx for that.

   Les


> -Original Message-
> From: Scott O. Bradner 
> Sent: Sunday, June 14, 2020 4:15 PM
> To: Les Ginsberg (ginsberg) 
> Cc: lsr@ietf.org; draft-ietf-ospf-te-link-attr-reuse@ietf.org; ops-
> d...@ietf.org; Benjamin Kaduk ; last-c...@ietf.org; ops-
> a...@ietf.org
> Subject: Re: [Last-Call] Opsdir telechat review of 
> draft-ietf-ospf-te-link-attr-
> reuse-14
> 
> inline
> 
> > On Jun 14, 2020, at 6:50 PM, Les Ginsberg (ginsberg)
>  wrote:
> >
> > Scott -
> >
> >
> >
> > Inline.
> >
> >
> >
> > > -----Original Message-
> >
> > > From: Scott O. Bradner 
> >
> > > Sent: Sunday, June 14, 2020 3:16 PM
> >
> > > To: Les Ginsberg (ginsberg) 
> >
> > > Cc: ops-...@ietf.org; Benjamin Kaduk ; draft-ietf-ospf-
> te-
> >
> > > link-attr-reuse@ietf.org; last-c...@ietf.org; lsr@ietf.org
> >
> > > Subject: Re: [Last-Call] Opsdir telechat review of 
> > > draft-ietf-ospf-te-link-
> attr-
> >
> > > reuse-14
> >
> > >
> >
> > > but why not spend the few bits to make it clear what its intended for -
> the
> >
> > > pushback on that simple request puzzles me
> >
> > > I do not understand the reluctance
> >
> >
> >
> > [Les:] With respect, answering my question with a counter question does
> not answer my question. 
> >
> > I have explained why I am reluctant -
> 
> 
> sorry but that did not explain your reluctance too me
> 
> > please explain what purpose your request serves. And why additional text
> is required for UDA when it is not needed for SA.
> 
> to mak eten document complete - the IDs introduce a field that they do not
> explain - that, to me, is a clear lack
> >
> >
> >
> > The "purpose" of UDA - to me - is to provide the opportunity for
> proprietary/experimental applications. But as UDAs are by definition outside
> the scope of standardization, it is not within the purview of the IETF or this
> document to place limitations on them. What I might judge to be an
> appropriate use case and what you might judge to be an appropriate use
> case might be different - and that should be OK. Which is why I don’t want to
> discuss "intent".
> >
> 
> I do not think I asked for "intent" but you just gave it to me "The "purpose"
> of UDA - to me - is to provide the opportunity for proprietary/experimental
> applications"
> 
> I do not see why it is so hard to say just that
> 
> in any case this does not seem like a productive discussion - you-all reject
> what seems like a logical and easy to implement request from me
> so I guess we will just hav etc agree to disagree
> 
> I'm done
> 
> Scott
> 
> >
> >
> > >
> >
> > > if it is so far outside of the area covered by the document why not simply
> >
> > > remove it?
> >
> > >
> >
> > [Les:] UDA was put in based on comments received from the WG. You
> would need to convince the WG that UDAs are not needed - not just me.
> >
> > That said, removing it now could introduce backwards compatibility issues
> with the existing deployments unless the syntax changes were limited - so
> this idea should be considered carefully before proceeding.
> >
> >
> >
> >   Les
> >
> >
> >
> > > Scott
> >
> > >
> >
> > > > On Jun 14, 2020, at 5:14 PM, Les Ginsberg (ginsberg)
> >
> > >  wrote:
> >
> > > >
> >
> > > > Scott -
> >
> > > >
> >
> > > > Allow me to inject myself here. As editor of the companion IS-IS
> document
> >
> > > (draft-ietf-isis-te-app) I have received similar comments - for example
>

Re: [Lsr] [Last-Call] Opsdir telechat review of draft-ietf-ospf-te-link-attr-reuse-14

2020-06-14 Thread Les Ginsberg (ginsberg)
Scott -



Inline.



> -Original Message-

> From: Scott O. Bradner 

> Sent: Sunday, June 14, 2020 3:16 PM

> To: Les Ginsberg (ginsberg) 

> Cc: ops-...@ietf.org; Benjamin Kaduk ; draft-ietf-ospf-te-

> link-attr-reuse@ietf.org; last-c...@ietf.org; lsr@ietf.org

> Subject: Re: [Last-Call] Opsdir telechat review of 
> draft-ietf-ospf-te-link-attr-

> reuse-14

>

> but why not spend the few bits to make it clear what its intended for - the

> pushback on that simple request puzzles me

> I do not understand the reluctance



[Les:] With respect, answering my question with a counter question does not 
answer my question. 

I have explained why I am reluctant - please explain what purpose your request 
serves. And why additional text is required for UDA when it is not needed for 
SA.



The "purpose" of UDA - to me - is to provide the opportunity for 
proprietary/experimental applications. But as UDAs are by definition outside 
the scope of standardization, it is not within the purview of the IETF or this 
document to place limitations on them. What I might judge to be an appropriate 
use case and what you might judge to be an appropriate use case might be 
different - and that should be OK. Which is why I don’t want to discuss 
"intent".



>

> if it is so far outside of the area covered by the document why not simply

> remove it?

>

[Les:] UDA was put in based on comments received from the WG. You would need to 
convince the WG that UDAs are not needed - not just me.

That said, removing it now could introduce backwards compatibility issues with 
the existing deployments unless the syntax changes were limited - so this idea 
should be considered carefully before proceeding.



  Les



> Scott

>

> > On Jun 14, 2020, at 5:14 PM, Les Ginsberg (ginsberg)

> mailto:ginsberg=40cisco@dmarc.ietf.org>>
>  wrote:

> >

> > Scott -

> >

> > Allow me to inject myself here. As editor of the companion IS-IS document

> (draft-ietf-isis-te-app) I have received similar comments - for example from

> Ben (copied on this thread).

> >

> > I continue to be at a loss as to why you believe we have to say something

> about User Defined Applications beyond what we have already said:

> >

> > "User Defined Application Identifier Bits have no relationship to

> >   Standard Application Identifier Bits and are not managed by IANA or

> >   any other standards body."

> >

> > If you do a search through both documents using "standard app" and "user

> defined app" I think you will find equivalent statements about both. Which

> means you are asking for some text regarding UDAs that doesn’t exist for

> SAs.

> > Why?

> >

> > The question of "UDA scope" - raised by both you and Ben - I think is an

> example of something that isn’t needed.

> >

> > Link attributes have been advertised for years - and the ability to define

> the appropriate scope (area or domain) has been supported by

> implementations for many years. While we are changing the format of how

> link attributes are advertised, we aren't altering the scopes supported.

> >

> > Standard applications can be (and have been) supported area wide and/or

> domain wide - and no restriction/specification of what scopes

> SHOULD/MUST be supported is present in either document other than to

> specify the type of LSAs in which the advertisements may appear. And since

> the new TLV introduced to carry application specific advertisements carries

> both SA and UDA bit masks in the same TLV, clearly the available scopes are

> the same for both types of applications.

> >

> > For me, the fact that UDA is outside the scope of standardization means

> the less said about how UDAs might be used the better.

> >

> > Do we have common ground here?

> >

> >   Les

> >

> >

> >> -Original Message-

> >> From: Scott Bradner via Datatracker 
> >> mailto:nore...@ietf.org>>

> >> Sent: Sunday, June 14, 2020 12:23 PM

> >> To: ops-...@ietf.org<mailto:ops-...@ietf.org>

> >> Cc: 
> >> draft-ietf-ospf-te-link-attr-reuse@ietf.org<mailto:draft-ietf-ospf-te-link-attr-reuse@ietf.org>;
> >>  lsr@ietf.org<mailto:lsr@ietf.org>; last-

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

> >> Subject: Opsdir telechat review of draft-ietf-ospf-te-link-attr-reuse-14

> >>

> >> Reviewer: Scott Bradner

> >> Review result: Ready

> >>

> >> I have reviewed the latest version of this document and my earlier issues

> >> have

> >> been res

Re: [Lsr] Opsdir telechat review of draft-ietf-ospf-te-link-attr-reuse-14

2020-06-14 Thread Les Ginsberg (ginsberg)
Scott -

Allow me to inject myself here. As editor of the companion IS-IS document 
(draft-ietf-isis-te-app) I have received similar comments - for example from 
Ben (copied on this thread).

I continue to be at a loss as to why you believe we have to say something about 
User Defined Applications beyond what we have already said:

"User Defined Application Identifier Bits have no relationship to
   Standard Application Identifier Bits and are not managed by IANA or
   any other standards body."

If you do a search through both documents using "standard app" and "user 
defined app" I think you will find equivalent statements about both. Which 
means you are asking for some text regarding UDAs that doesn’t exist for SAs.
Why? 

The question of "UDA scope" - raised by both you and Ben - I think is an 
example of something that isn’t needed.

Link attributes have been advertised for years - and the ability to define the 
appropriate scope (area or domain) has been supported by implementations for 
many years. While we are changing the format of how link attributes are 
advertised, we aren't altering the scopes supported.

Standard applications can be (and have been) supported area wide and/or domain 
wide - and no restriction/specification of what scopes SHOULD/MUST be supported 
is present in either document other than to specify the type of LSAs in which 
the advertisements may appear. And since the new TLV introduced to carry 
application specific advertisements carries both SA and UDA bit masks in the 
same TLV, clearly the available scopes are the same for both types of 
applications.

For me, the fact that UDA is outside the scope of standardization means the 
less said about how UDAs might be used the better.

Do we have common ground here?

   Les


> -Original Message-
> From: Scott Bradner via Datatracker 
> Sent: Sunday, June 14, 2020 12:23 PM
> To: ops-...@ietf.org
> Cc: draft-ietf-ospf-te-link-attr-reuse@ietf.org; lsr@ietf.org; last-
> c...@ietf.org
> Subject: Opsdir telechat review of draft-ietf-ospf-te-link-attr-reuse-14
> 
> Reviewer: Scott Bradner
> Review result: Ready
> 
> I have reviewed the latest version of this document and my earlier issues
> have
> been resolved at least well enough for teh document to be considered ready
> for
> publication.
> 
> that said I still do not see where "User Defined Application Identifier" is
> actually cleanly defined - one can read carefully and determine but it would
> be
> easier on the reader to just say that it is a field that can be used to
> indicate the use of one or more non-standard applications within some scope
> (network, subnet, link, organization, ... not sure what scopes are meaningful
> here but it does not seem that a User Defined Application Identifier would
> be a
> global (between network operators) value
> 
> Scott
> 

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


Re: [Lsr] Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: (with DISCUSS and COMMENT)

2020-06-13 Thread Les Ginsberg (ginsberg)
Deborah –

Inline.

From: BRUNGARD, DEBORAH A 
Sent: Friday, June 12, 2020 4:16 PM
To: Les Ginsberg (ginsberg) ; The IESG 
Cc: draft-ietf-isis-te-...@ietf.org; lsr-cha...@ietf.org; lsr@ietf.org; Acee 
Lindem (acee) ; aretana.i...@gmail.com
Subject: RE: Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: (with 
DISCUSS and COMMENT)

Hi Les,

On my Discuss, that’s good.

On my comments, I’m still confused then on the scope of the draft. If it was 
(2) below only, it would seem that this is an extension of current capabilities 
(my first reading). Considering (1), “unambiguously”, and the use of the terms 
“legacy” and “all routers are upgraded” in the document, I wonder why this is 
not considered an update to RFC5305 – is this updating RSVP-TE routers too? If 
not, and it is only referring to (legacy) SR routers which are doing “legacy 
advertisements” then I would agree this would not be an update as there is no 
RFC saying how an SR router should advertise.

Depending on the intention, it would really help to clarify “legacy”, e.g., it 
is not an RSVP-TE router but a router with SR capabilities still doing “legacy” 
advertisements. I think Bruno was trying to say this in his rtgdir review. It 
is really confusing, e.g., here in Section 3, suggest:
Section 3. Legacy Advertisements/s/Legacy SR Advertisements, and “in support of 
RSVP-TE”/s/”in support of SR” (as it’s an SR “legacy” router)

But if the intention is to upgrade ALL RSVP-TE routers too, and this is an 
UPDATE to 5305, here can say “in support of RSVP-TE and SR”. Though if this is 
the intention, it clashes with 6.1 where it says there is no need to do 
anything for RSVP-TE.

[Les:] “Legacy” refers to routers which do not support the extensions defined 
in this document.
“Legacy advertisements” are explicitly listed in Section 3.
“Legacy advertisements” have been used (prior to this draft) in support of all 
of the applications discussed in this draft (RSVP-TE, SRTE (renamed to SR 
Policy as per your comment), and LFA) because there was nothing else available.
There is no intent to “upgrade RSVP-TE”. The new encodings can be used by 
RSVP-TE (as discussed in Sections 6.3.4) – but this is not a main motivation 
for the draft and if it never happens (i.e., RSVP-TE implementations continue 
to use legacy advertisements) that is fine.

This is introducing new advertisements for link attributes which support per 
application semantics and provide unambiguous association between link 
attribute advertisements and applications. This is necessary to address 
deployments where the constraints defined in Section 6.1 cannot be met.
It is not an update to RFC 5305.
As an analogy, are you suggesting that RFC 5120 should be considered  an update 
to RFC 5305 because it introduces new forms of IS-Neighbor and Prefix 
Reachability advertisements?

What the draft mandates is that new applications (i.e., other than RSVP-TE, SR 
Policy, LFA) MUST use the new advertisements (Section 6.1) . This avoids the 
introduction of the issues associated with a mixture of legacy/non-legacy 
routers that can occur with the pre-existing applications.
For existing applications, while we might like to see SR Policy/LFA use the new 
advertisements, we recognize that this may or may not happen based on the 
marketplace.
For RSVP-TE, the main motivation to move to new advertisements would be to be 
able to deprecate the use of legacy advertisements and thereby simplify 
implementations. But we recognize this isn’t a very compelling motivation and 
likely won’t happen – or will take many years to happen.


For 6.1, the 2nd bullet, you should add: RSVP-TE is not deployed/s/RSVP-TE is 
not deployed or planned to be deployed. Here, I agree with Bruno, you really 
need to provide guidance on “control”, otherwise you will most likely not have 
interoperability. Suggest: The default SHALL be use of legacy advertisements. 
Otherwise this is an UPDATE to 5305 as different vendors will choose different 
defaults.



[Les:] Section 6.1 makes explicit the conditions under which legacy 
advertisements may be used. This is reflecting the operational realities e.g., 
since legacy advertisements do not provide per application semantics using them 
when multiple applications are enabled requires congruence for all of the 
applications enabled.

It also provides guidance to implementors that controls for the types of 
advertisements which are sent/received will likely be needed.



I see no reason to go beyond what the draft specifies. An implementation which 
is working and conforms to the published standards in terms of the form of 
advertisements sent/received is not going to change simply because an RFC says 
you SHOULD.



If this is updating RSVP-TE routers, this should have been shared with TEAS (I 
don’t recall anything).

[Les:] I leave it to the WG chairs to address this request – to which I have no 
objection.

   Les

Thanks,
Deborah

From: Les Ginsberg (ginsberg) mailto:ginsb

Re: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-isis-te-app-14: (with DISCUSS and COMMENT)

2020-06-13 Thread Les Ginsberg (ginsberg)
Ben -

Inline.

> -Original Message-
> From: Benjamin Kaduk 
> Sent: Friday, June 12, 2020 9:15 PM
> To: Les Ginsberg (ginsberg) 
> Cc: The IESG ; draft-ietf-isis-te-...@ietf.org; lsr-
> cha...@ietf.org; lsr@ietf.org; Acee Lindem (acee) ;
> aretana.i...@gmail.com
> Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-isis-te-app-14: (with
> DISCUSS and COMMENT)
> 
> On Fri, Jun 12, 2020 at 07:45:00PM +, Les Ginsberg (ginsberg) wrote:
> > Ben -
> >
> > Top posting the open issues - as I think there are only two.
> >
> > Issue #1
> >
> > > > What is the scope over which the user-defined application bits are
> > > > defined/allocated?
> > >
> >
> > LES: User defined applications are - by definition - outside the scope of 
> > this
> document/standardization.
> 
> Yes.
> 
> > We have simply defined the syntax of how to advertise associated bit
> mask.
> 
> But if my implementation is built around (say) the meanings of the bits in
> the bit mask being local to a single area, and your implementation is built
> around them having meaning local to a full domain, when you try to send me
> something from out of area it's not going to work so well.  Even without
> saying what any given bit means, we can still say that "all systems in the
> same  need to interpret each bit in the same way.  What is the smallest
>  such that deployment is safe?
> 
> > How, for example, interoperability is achieved is up to implementors.
> > Whether they want an application to be area scoped or domain-wide is also
> up to them.
> 
> I think leaving the question of area vs. domain up to the application is a
> recipe for interop failures.
> 
> (A similar question presumably applies to the OSPF document, though I
> didn't get a chance to actually review that one.)
> 

[Les:] If interoperability between implementations is a concern, then the 
obvious choice is to use a standardized application.

Placing limits on the scope of a user defined application is both unnecessary 
and unenforceable. I say "unenforceable" because, if you have a mixed vendor 
network, there is no guarantee that User Bit X means the same thing to both 
implementations. And since I cannot tell the identity of the implementation 
originating an advertisement, I cannot tell if the User Bit advertised in Area 
Scoped LSPs (Level-1 in IS-IS speak) has the same meaning as the same bit 
advertised in Domain-wide LSPs. So I cannot detect when a violation occurs.

To me, User Defined Application is a space for implementations to do whatever 
they choose - subject to the syntax rules defined in the draft. Maybe they use 
it as an experimental space for something they will eventually standardize. 
Maybe they use it to implement a proprietary application that they have no 
intention of standardizing. As it does not impact operation of the standard 
applications, I see no reason or benefit for the draft to impose restrictions.

As context, User Defined was added based on comments received from some WG 
members. It isn't needed to support the goals of the draft. It is an option 
that at least some members felt was desirable to have.


> > Issue #2
> >
> > > > Section 7.4
> > >
> > > >
> > >
> > > >policy for this registry is "Standards Action" [RFC8126].  Bit
> > >
> > > >definitions SHOULD be assigned in ascending bit order beginning with
> > >
> > > >Bit 0 so as to minimize the number of octets that will need to be
> > >
> > > >transmitted.  The following assignments are made by this document:
> > >
> > > >
> > >
> > > > I worry a little bit that this will encourage codepoint squatting,
> > >
> > > > though in theory the user-defined bitmask should avoid the need for
> > >
> > > > squatting.
> > >
> > > >
> >
> > You replied:
> >
> > " If everyone expects a sequential allocation policy, then when
> > developing/testing, it's natural to look at "what's in the registry now"
> > and write code that uses the next value.  If three people do that at the
> > same time, we can end up with deployed software that has conflicting
> > interpretation of that value.  (This has happened for TLS, yes, with three
> > different extensions using the same value.)  My suggestion would be to
> not
> > say "SHOULD be assigned in ascending bit order", and perhaps just note
> > (without normative language) that it is advisable to allocate from the
> > lowest byte that has bits remaining, to allow for compact encodi

Re: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-isis-te-app-14: (with DISCUSS and COMMENT)

2020-06-12 Thread Les Ginsberg (ginsberg)
Ben -

Top posting the open issues - as I think there are only two.

Issue #1

> > What is the scope over which the user-defined application bits are
> > defined/allocated?
> 

LES: User defined applications are - by definition - outside the scope of this 
document/standardization.
We have simply defined the syntax of how to advertise associated bit mask.

How, for example, interoperability is achieved is up to implementors.
Whether they want an application to be area scoped or domain-wide is also up to 
them.

Issue #2

> > Section 7.4
> 
> >
> 
> >policy for this registry is "Standards Action" [RFC8126].  Bit
> 
> >definitions SHOULD be assigned in ascending bit order beginning with
> 
> >Bit 0 so as to minimize the number of octets that will need to be
> 
> >transmitted.  The following assignments are made by this document:
> 
> >
> 
> > I worry a little bit that this will encourage codepoint squatting,
> 
> > though in theory the user-defined bitmask should avoid the need for
> 
> > squatting.
> 
> >

You replied:

" If everyone expects a sequential allocation policy, then when
developing/testing, it's natural to look at "what's in the registry now"
and write code that uses the next value.  If three people do that at the
same time, we can end up with deployed software that has conflicting
interpretation of that value.  (This has happened for TLS, yes, with three
different extensions using the same value.)  My suggestion would be to not
say "SHOULD be assigned in ascending bit order", and perhaps just note
(without normative language) that it is advisable to allocate from the
lowest byte that has bits remaining, to allow for compact encoding.  It's
not actually necessary to be strictly sequential in order to minimize the
number of octets transmitted."

LES: I understand this concern. How about if we change policy to "Expert 
Review"?

   Les


> -Original Message-
> From: Benjamin Kaduk 
> Sent: Friday, June 12, 2020 11:57 AM
> To: Les Ginsberg (ginsberg) 
> Cc: The IESG ; draft-ietf-isis-te-...@ietf.org; lsr-
> cha...@ietf.org; lsr@ietf.org; Acee Lindem (acee) ;
> aretana.i...@gmail.com
> Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-isis-te-app-14: (with
> DISCUSS and COMMENT)
> 
> Getting back to the comment section (inline)...
> 
> On Thu, Jun 11, 2020 at 04:48:00PM +, Les Ginsberg (ginsberg) wrote:
> > Benjamin -
> >
> >
> >
> > Thanx for your review.
> >
> > Responses inline.
> >
> >
> >
> > > -Original Message-
> >
> > > From: Benjamin Kaduk via Datatracker 
> >
> > > Sent: Thursday, June 11, 2020 12:42 AM
> >
> > > To: The IESG 
> >
> > > Cc: draft-ietf-isis-te-...@ietf.org; lsr-cha...@ietf.org; lsr@ietf.org; 
> > > Acee
> >
> > > Lindem (acee) ; aretana.i...@gmail.com; Acee Lindem
> >
> > > (acee) 
> >
> > > Subject: Benjamin Kaduk's Discuss on draft-ietf-isis-te-app-14: (with
> DISCUSS
> >
> > > and COMMENT)
> >
> > >
> >
> > > Benjamin Kaduk has entered the following ballot position for
> >
> > > draft-ietf-isis-te-app-14: 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-te-app/
> >
> > >
> >
> > >
> >
> > >
> >
> > > --
> >
> > > DISCUSS:
> >
> > > --
> >
> > >
> >
> > > My apologies if this is super-obvious and I'm just missing it ... but
> >
> > > Section 4.3 dictates that part of the value for the application-specific
> >
> > > SRLG TLV is a "Neighbor System-ID + pseudo-node ID (7 octets)".  Where
> >
> > > are these defined?  (We don't exactly say that we're reusing the
> structure
> >
> > > from, e

Re: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-isis-te-app-14: (with DISCUSS and COMMENT)

2020-06-11 Thread Les Ginsberg (ginsberg)
Ben -

Sorry - there was a typo - correct specification number is ISO 10589.
It is freely available here: 
https://standards.iso.org/ittf/PubliclyAvailableStandards/index.html 

   Les

> -Original Message-
> From: Benjamin Kaduk 
> Sent: Thursday, June 11, 2020 1:01 PM
> To: Les Ginsberg (ginsberg) 
> Cc: The IESG ; draft-ietf-isis-te-...@ietf.org; lsr-
> cha...@ietf.org; lsr@ietf.org; Acee Lindem (acee) ;
> aretana.i...@gmail.com
> Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-isis-te-app-14: (with
> DISCUSS and COMMENT)
> 
> Hi Les,
> 
> On Thu, Jun 11, 2020 at 04:48:00PM +, Les Ginsberg (ginsberg) wrote:
> > Benjamin -
> >
> >
> >
> > Thanx for your review.
> >
> > Responses inline.
> >
> >
> >
> > > -Original Message-
> >
> > > From: Benjamin Kaduk via Datatracker 
> >
> > > Sent: Thursday, June 11, 2020 12:42 AM
> >
> > > To: The IESG 
> >
> > > Cc: draft-ietf-isis-te-...@ietf.org; lsr-cha...@ietf.org; lsr@ietf.org; 
> > > Acee
> >
> > > Lindem (acee) ; aretana.i...@gmail.com; Acee Lindem
> >
> > > (acee) 
> >
> > > Subject: Benjamin Kaduk's Discuss on draft-ietf-isis-te-app-14: (with
> DISCUSS
> >
> > > and COMMENT)
> >
> > >
> >
> > > Benjamin Kaduk has entered the following ballot position for
> >
> > > draft-ietf-isis-te-app-14: 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-te-app/
> >
> > >
> >
> > >
> >
> > >
> >
> > > --
> >
> > > DISCUSS:
> >
> > > --
> >
> > >
> >
> > > My apologies if this is super-obvious and I'm just missing it ... but
> >
> > > Section 4.3 dictates that part of the value for the application-specific
> >
> > > SRLG TLV is a "Neighbor System-ID + pseudo-node ID (7 octets)".  Where
> >
> > > are these defined?  (We don't exactly say that we're reusing the
> structure
> >
> > > from, e.g., TLV 138, which I note refers to the seventh octet as
> >
> > > "pseudonode number", not "pseudo-node ID".  Similarly for the
> >
> > > interpretation of the SRLG value(s).  Do we just need to reference that
> >
> > > we're reusing the encoding from RFC 5307 (or similar) or are some
> >
> > > changes needed?
> >
> > >
> >
> > [Les:] “system ID” and “pseudo-node ID” derive from the IS-IS base
> specification [ISO 19589]
> 
> Ah, so definitely "super-obvious", and just a consequence of my never
> actually getting my hands on a copy of ISO 19589 (obvious paths seem to ask
> for 200 CHF).
> 
> Sorry for the noise; I will go clear now (and will respond to the comment
> section later).
> 
> -Ben
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


Re: [Lsr] I-D Action: draft-ietf-isis-te-app-15.txt

2020-06-11 Thread Les Ginsberg (ginsberg)
Murray -

You never replied to my response to your comments - otherwise we could have 
continued the discussion in that thread.

What I replied there on this point was:

[Les:] IS-IS registries are guided by RFC 7370 (referenced in Section 7 and in 
https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml  
) - which does provide guidance to the experts.
There is some additional guidance in Section 7.3 because we want codepoints in 
the existing "sub-TLV of TLVs 22, 23, 25, 141, 222, and 223" registry to be in 
sync with the new registry whenever possible.
For Section 7.5 there really isn’t anything else to say beyond what RFC 7370 
says.

   Les


> -Original Message-
> From: Murray S. Kucherawy 
> Sent: Thursday, June 11, 2020 11:05 AM
> To: Les Ginsberg (ginsberg) 
> Cc: lsr@ietf.org; Martin Duke ; Rob Wilton
> (rwilton) ; Roman Danyliw ; Deborah
> Brungard ; Benjamin Kaduk 
> Subject: Re: [Lsr] I-D Action: draft-ietf-isis-te-app-15.txt
> 
> Hi Les,
> 
> I'm afraid I don't see how this revision resolves my DISCUSS point,
> which is that Section 7.5 creates a registry under "Expert Review"
> terms; BCP 26 pushes the point that such a registry definition should
> include guidance to the Designated Expert about how to handle new
> applications, but Section 7.5 doesn't.
> 
> On the other hand, Section 7.3 gets this right; note its last paragraph.
> 
> For that matter, BCP 26 recommends including a "Change Controller"
> column, but neither registry created here does so.  Is that
> intentional?
> 
> https://tools.ietf.org/html/bcp26#section-4.5
> 
> -MSK
> 
> On Thu, Jun 11, 2020 at 10:16 AM Les Ginsberg (ginsberg)
>  wrote:
> >
> > Folks -
> >
> > This update to the draft addresses comments from the following IESG
> reviewers:
> >
> > Murray Kucherawy
> > Martin Duke
> > Rob Wilton
> > Roman Danyliw
> > Deborah Brungard
> > Benjamin Kaduk
> >
> > It also includes grammatical corrections related to the use of "which/that".
> >
> > A special thank you to Acee Lindem for his tireless efforts to improve my
> grammar.
> >
> >   Les
> >
> > > -Original Message-
> > > From: Lsr  On Behalf Of internet-dra...@ietf.org
> > > Sent: Thursday, June 11, 2020 10:06 AM
> > > To: i-d-annou...@ietf.org
> > > Cc: lsr@ietf.org
> > > Subject: [Lsr] I-D Action: draft-ietf-isis-te-app-15.txt
> > >
> > >
> > > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> > > This draft is a work item of the Link State Routing WG of the IETF.
> > >
> > > Title   : IS-IS TE Attributes per application
> > > Authors : Les Ginsberg
> > >   Peter Psenak
> > >   Stefano Previdi
> > >   Wim Henderickx
> > >   John Drake
> > >   Filename: draft-ietf-isis-te-app-15.txt
> > >   Pages   : 21
> > >   Date: 2020-06-11
> > >
> > > Abstract:
> > >Existing traffic engineering related link attribute advertisements
> > >have been defined and are used in RSVP-TE deployments.  Since the
> > >original RSVP-TE use case was defined, additional applications (e.g.,
> > >Segment Routing Policy, Loop Free Alternate) that also make use of
> > >the link attribute advertisements have been defined . In cases where
> > >multiple applications wish to make use of these link attributes, the
> > >current advertisements do not support application specific values for
> > >a given attribute, nor do they support indication of which
> > >applications are using the advertised value for a given link.  This
> > >document introduces new link attribute advertisements that address
> > >both of these shortcomings.
> > >
> > >
> > >
> > > The IETF datatracker status page for this draft is:
> > > https://datatracker.ietf.org/doc/draft-ietf-isis-te-app/
> > >
> > > There are also htmlized versions available at:
> > > https://tools.ietf.org/html/draft-ietf-isis-te-app-15
> > > https://datatracker.ietf.org/doc/html/draft-ietf-isis-te-app-15
> > >
> > > A diff from the previous version is available at:
> > > https://www.ietf.org/rfcdiff?url2=draft-ietf-isis-te-app-15
> > >
> > >
> > > 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] I-D Action: draft-ietf-isis-te-app-15.txt

2020-06-11 Thread Les Ginsberg (ginsberg)
Folks -

This update to the draft addresses comments from the following IESG reviewers:

Murray Kucherawy
Martin Duke
Rob Wilton
Roman Danyliw
Deborah Brungard
Benjamin Kaduk

It also includes grammatical corrections related to the use of "which/that".

A special thank you to Acee Lindem for his tireless efforts to improve my 
grammar.

  Les

> -Original Message-
> From: Lsr  On Behalf Of internet-dra...@ietf.org
> Sent: Thursday, June 11, 2020 10:06 AM
> To: i-d-annou...@ietf.org
> Cc: lsr@ietf.org
> Subject: [Lsr] I-D Action: draft-ietf-isis-te-app-15.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Link State Routing WG of the IETF.
> 
> Title   : IS-IS TE Attributes per application
> Authors : Les Ginsberg
>   Peter Psenak
>   Stefano Previdi
>   Wim Henderickx
>   John Drake
>   Filename: draft-ietf-isis-te-app-15.txt
>   Pages   : 21
>   Date: 2020-06-11
> 
> Abstract:
>Existing traffic engineering related link attribute advertisements
>have been defined and are used in RSVP-TE deployments.  Since the
>original RSVP-TE use case was defined, additional applications (e.g.,
>Segment Routing Policy, Loop Free Alternate) that also make use of
>the link attribute advertisements have been defined . In cases where
>multiple applications wish to make use of these link attributes, the
>current advertisements do not support application specific values for
>a given attribute, nor do they support indication of which
>applications are using the advertised value for a given link.  This
>document introduces new link attribute advertisements that address
>both of these shortcomings.
> 
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-isis-te-app/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-isis-te-app-15
> https://datatracker.ietf.org/doc/html/draft-ietf-isis-te-app-15
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-isis-te-app-15
> 
> 
> 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] Benjamin Kaduk's Discuss on draft-ietf-isis-te-app-14: (with DISCUSS and COMMENT)

2020-06-11 Thread Les Ginsberg (ginsberg)
Benjamin -



Thanx for your review.

Responses inline.



> -Original Message-

> From: Benjamin Kaduk via Datatracker 

> Sent: Thursday, June 11, 2020 12:42 AM

> To: The IESG 

> Cc: draft-ietf-isis-te-...@ietf.org; lsr-cha...@ietf.org; lsr@ietf.org; Acee

> Lindem (acee) ; aretana.i...@gmail.com; Acee Lindem

> (acee) 

> Subject: Benjamin Kaduk's Discuss on draft-ietf-isis-te-app-14: (with DISCUSS

> and COMMENT)

>

> Benjamin Kaduk has entered the following ballot position for

> draft-ietf-isis-te-app-14: 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-te-app/

>

>

>

> --

> DISCUSS:

> --

>

> My apologies if this is super-obvious and I'm just missing it ... but

> Section 4.3 dictates that part of the value for the application-specific

> SRLG TLV is a "Neighbor System-ID + pseudo-node ID (7 octets)".  Where

> are these defined?  (We don't exactly say that we're reusing the structure

> from, e.g., TLV 138, which I note refers to the seventh octet as

> "pseudonode number", not "pseudo-node ID".  Similarly for the

> interpretation of the SRLG value(s).  Do we just need to reference that

> we're reusing the encoding from RFC 5307 (or similar) or are some

> changes needed?

>

[Les:] “system ID” and “pseudo-node ID” derive from the IS-IS base 
specification [ISO 19589]



>

> --

> COMMENT:

> --

>

> What is the scope over which the user-defined application bits are

> defined/allocated?



[Les:] Sorry – I do not understand this question.



>

> And, a general question, just to check my understanding: if I do need to

> specify different values of a given attribute for different

> applications, I do that by putting multiple copies of the new sub-TLV in

> TLV 22/23/etc., with the flags set according to which application the

> contained attributes apply to?  (Mostly I ask because I forget what the

> rules are for having multiple instances of a given TLV/sub-TLV as

> siblings in the same container.)

>

[Les:] You are correct.

Whether multiple occurrences of the same sub-TLV is allowed is codepoint 
specific.

Section 4.2 states:



“Multiple Application Specific Link Attribute sub-TLVs for the same

   link MAY be advertised.”



> Section 3.1

>

> Maybe mention (again, I know) that this is only the subset of sub-TLVs

> that are used for RSVP-TE?



[Les:] The point of Section 3.1 is to list the legacy sub-TLVs which are 
relevant to this draft. There are other sub-TLVs defined in 
https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-22-23-25-141-222-223

which are not relevant – but categorizing them as “not used by RSVP-TE” 
wouldn’t be completely accurate. For example, endpoint addresses (codepoints 
6,8,12,13) are quite relevant to RSVP-TE as they are required to uniquely 
identify the link – but they aren’t in the set of sub-sub-TLVs being defined.



>

> Section 4.2

>

>When the L-flag is set in the Application Identifier Bit Mask, all of

>the applications specified in the bit mask MUST use the legacy

>advertisements for the corresponding link found in TLVs 22, 23, 25,

>141, 222, and 223 or TLV 138 or TLV 139 as appropriate.  Link

>

> nit(?): is this "found in sub-TLVs of TLVs 22, [...]"?

[Les:] The top level TLVs are the containers in which link advertisements are 
present. A given link advertisement consists of the fixed portion of the TLV 
and a set of sub-TLVs.

I think the existing text is correct.



>

>attribute sub-sub-TLVs for the corresponding link attributes MUST NOT

>be advertised for the set of applications specified in the Standard/

>User Application Identifier Bit Masks and all such advertisements

>MUST be ignored on receipt.

>

> Does this apply to just the (sub-)TLV with the L-flag set, or to other

> instances of that (sub-)TLV as well?

>

[Les:] The scope is the set of sub-TLVs associated with the same link and the 
same application(s).



>For a given application, the setting of the L-flag MUST be the same

>in all sub-TLVs for a given link.  In cases where this constraint is

>violated, the L-flag MUST be considered set for this application.

>

> editorial: I suggest "the L-flag MUST be considered set for this

> application for all sub-TLVs on the link in 

Re: [Lsr] Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: (with DISCUSS and COMMENT)

2020-06-11 Thread Les Ginsberg (ginsberg)
Deborah -



Thanx for your review.

Responses inline.



> -Original Message-

> From: Deborah Brungard via Datatracker 

> Sent: Wednesday, June 10, 2020 3:17 PM

> To: The IESG 

> Cc: draft-ietf-isis-te-...@ietf.org; lsr-cha...@ietf.org; lsr@ietf.org; Acee

> Lindem (acee) ; aretana.i...@gmail.com; Acee Lindem

> (acee) 

> Subject: Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: (with

> DISCUSS and COMMENT)

>

> Deborah Brungard has entered the following ballot position for

> draft-ietf-isis-te-app-14: 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-te-app/

>

>

>

> --

> DISCUSS:

> --

>

> This should be simple to resolve - the use of the SR-TE term is

> out-of-alignment with other drafts, spring and idr. Suggest: Segment Routing

> Traffic Engineering/s/Segment Routing Policy and SRTE/s/SR Policy.

>

[Les:] Peter and I have discussed this suggestion. We have agreed to change 
“SRTE” to “SR Policy” in both drafts.



>

> --

> COMMENT:

> --

>

> I found this document a bit easier to read than the OSPF one. Though it also

> seems (implementation) confused on 1:1 association of signaling over a link

> with data use of the link and so the confusion on what application to support

> on the link. As I noted on the OSPF one, it would be much clearer to simply

> discuss the main problem (to me) - the ability to support advertisement of

> application specific values?

>

[Les:] There are two issues which this draft is addressing – as detailed in the 
Introduction:



1)Unambiguously indicate which  advertisements are to be used by a given 
application



2)Support advertisement of application specific values



Both are important.



> I don't see any discussion on the dark bandwidth problem or the security

> problems identified in RFC8426? It would be helpful if the draft pointed to

> the

> RFC8426 solution.

>

[Les:] I see RFC8426 and this document as complementary. RFC8426 discusses the 
operational challenges when multiple applications (specifically RSVP-TE and SR 
Policy) are deployed in the same network.

This document is defining new encodings in support of application specific 
advertisements, which eliminate ambiguity as to how to pair link attribute 
advertisements with applications.

Discussing dark bandwidth issues seems out of scope for this document.



   Les



>


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


Re: [Lsr] Roman Danyliw's No Objection on draft-ietf-isis-te-app-14: (with COMMENT)

2020-06-11 Thread Les Ginsberg (ginsberg)
Roman -



Thanx for the review.

Responses inline.



> -Original Message-

> From: Roman Danyliw via Datatracker 

> Sent: Wednesday, June 10, 2020 3:05 PM

> To: The IESG 

> Cc: draft-ietf-isis-te-...@ietf.org; lsr-cha...@ietf.org; lsr@ietf.org; Acee

> Lindem (acee) ; aretana.i...@gmail.com; Acee Lindem

> (acee) 

> Subject: Roman Danyliw's No Objection on draft-ietf-isis-te-app-14: (with

> COMMENT)

>

> Roman Danyliw has entered the following ballot position for

> draft-ietf-isis-te-app-14: 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-te-app/

>

>

>

> --

> COMMENT:

> --

>

> (revised)

> ** Section 4.1.  As I understand it, the SABM can be of 0 – 8 octets in 
> length.

> The SABM Length field represents that length and has 7 bits to do that.

> However, the maximum number of bits needed to represent 8 is only 4 bits.

> What’s the thinking on those three extra bits?  Should they be marked as

> reserved?  I would have the same question for the UDABM mask.

>

[Les:] The limitation for the xABM length to be no more than 8 bytes was 
introduced only recently based on a review comment.

The concern was that without a limit, it would be theoretically possible for 
the ABM itself to consume the full sub-TLV space, leaving no room for the 
actual link attribute advertisements.

There are existing implementations of this draft which have been deployed. 
Changing the interpretation of (some of) the  bits would not be backwards 
compatible.

I do not think the small space savings would be worth the trouble.



You are the third reviewer to ask about this.

(Tongue-in-cheek)  I am impressed with the (oxymoron alert…) “abundance of 
frugality”. 



> ** Section 6.2.  I didn’t follow what it means to send the sub-TLV in Section

> 4.2 with a zero length SABM Length and UDABM Length – that is two empty

> bitmasks?  Is that permitted?  What would it convey?

>

[Les:] Clearly 0 length masks are permitted since we specify a length of 0 as 
valid.

And usage is described in Sections 4.2 and 6.2 – any application can use such 
advertisements.

What specifically is your question?





> ** Section 8.  Per “Tampering with the information defined in this document

> may

> have an effect on applications using it, including impacting Traffic

> Engineering.”, I have no disagreement with this statement.  However, I

> would

> recommend adding a brief statement what is the security impact of

> “impacting

> Traffic Engineering”.

>

> ** Section 8.  Per “This is similar in nature to the impacts associated  with

> (for example) [RFC5305]”, what specific text in RFC5305 was envisioned?  The

> SecCon section (Section 6) of RFC5305 contains only one sentence that points

> to

> RFC5304?

>

[Les:] I have added a reference to RFC8570 – whose Security section has a good 
discussion of impacts to TE.

I have removed the reference to RFC5305. It seemed unnecessary after 
referencing RFC8570 and – as you point out – it does not discuss security 
issues in any detail.



> ** Section 8.  Consider using the editorial framing of the first paragraph of

> Section 13 in draft-ietf-ospf-te-link-attr-reuse to introduce how the RFC5304

> applies here.

>

[Les:] Done



> ** Editorial

> -- Section 3.  Editorial.  Consider providing a reference for the registries

> instead of an inline URL.

>

[Les:] Yes – this has been done. Another reviewer also requested this.



> -- Section 4.1.  The rendering of the sub-TLV diagram was split between Page

> 6

> and 7 when this draft is read in TXT format.  IMO, it would be more readable

> if

> it was on one page.

>

[Les:] I prefer to leave this to the RFC Editor.

> -- Per Section 4.1.  Editorial.  Per “See the following section for a

> description …”, please explicitly name the section.

>

[Les:] Done



> -- Section 4.2.  Typo. s/Identifer/Identifier/



[Les:] Done



   Les



>

>


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


Re: [Lsr] Robert Wilton's No Objection on draft-ietf-isis-te-app-14: (with COMMENT)

2020-06-10 Thread Les Ginsberg (ginsberg)
Rob -

Thanx for your review.
Inline.

> -Original Message-
> From: Robert Wilton via Datatracker 
> Sent: Wednesday, June 10, 2020 8:38 AM
> To: The IESG 
> Cc: draft-ietf-isis-te-...@ietf.org; lsr-cha...@ietf.org; lsr@ietf.org; Acee
> Lindem (acee) ; aretana.i...@gmail.com; Acee Lindem
> (acee) 
> Subject: Robert Wilton's No Objection on draft-ietf-isis-te-app-14: (with
> COMMENT)
> 
> Robert Wilton has entered the following ballot position for
> draft-ietf-isis-te-app-14: 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-te-app/
> 
> 
> 
> --
> COMMENT:
> --
> 
> I'm not sure whether this should really be a discuss ... I raised a similar
> concern on the OSPF document as part of a discuss, and presume
> consistency is
> helpful.
> 
> 4.1.  Application Identifier Bit Mask
> 
>   UDABM Length: Indicates the length in octets (0-8) of the
>User Defined Application Identifier Bit Mask. The length SHOULD
>be the minimum required to send all bits which are set.
> 
>User Defined Application Identifier Bits have no relationship to
>Standard Application Identifier Bits and are not managed by IANA or
>any other standards body.  It is recommended that bits are used
>starting with Bit 0 so as to minimize the number of octets required
>to advertise all UDAs.
> 
> In section 4.1, I think that the document should also add the sentence (taken
> from the previous paragraph) "Bits that are not transmitted MUST be treated
> as
> if they are set to 0 on receipt."  Note, that I also think that this behaviour
> is implicitly required from the description of UDABM Length.
> 
[Les:] I agree - but I think I will move/rewrite the sentence so that one 
instance indicates this applies to both SABM/UDABM.

   Les

> Regards,
> Rob
> 
> 

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


Re: [Lsr] Martin Duke's No Objection on draft-ietf-isis-te-app-14: (with COMMENT)

2020-06-09 Thread Les Ginsberg (ginsberg)
Martin -

From: Martin Duke 
Sent: Tuesday, June 09, 2020 2:35 PM
To: Les Ginsberg (ginsberg) 
Cc: The IESG ; lsr-cha...@ietf.org; aretana.i...@gmail.com; Acee 
Lindem (acee) ; draft-ietf-isis-te-...@ietf.org; lsr@ietf.org
Subject: Re: [Lsr] Martin Duke's No Objection on draft-ietf-isis-te-app-14: 
(with COMMENT)

On Tue, Jun 9, 2020 at 12:25 PM Les Ginsberg (ginsberg) 
mailto:ginsb...@cisco.com>> wrote:

[Les:] The use of "any application" is only possible if the same link attribute 
values can be used by all applications which are in use in that deployment. 
This is a decision that can only be made based on the deployment.
The discussion of "enablement" is pointing out a possible side effect even if 
the first set of conditions are met.

To my mind, the use of "any application" is likely NOT the default mode of 
operation even when the preconditions are met - but this is an implementation 
choice not subject to standardization.

I suspect we are talking past each other, probably due to my ignorance of this 
area, and possibly beyond what a non-blocking comment is worth.

Anyway, I can live with not having normative language here, but I would like to 
have a little more discussion of the considerations for this decision -- at 
least what the consequences are if nodes don't know if the links support 
RSVP-TE or not.

[Les:] When the application bit mask is populated (non-zero length), the set of 
applications to which the associated link attributes apply is explicit.
When the application bit mask is NOT populated (zero-length), the set of 
applications to which the associated link attributes apply is implicit. 
Specifically, any application that is enabled on a node (by application 
specific configuration which likely is NOT link specific) is allowed to use the 
attributes. For an application (such as RSVP-TE) where “use” includes the 
enablement of the application on that link there is a possibility that this is 
not what was intended. Simply by configuring/advertising a link attribute can 
then result in unintended use of that link by such an application.
Applications which do NOT depend on link attribute advertisements for 
enablement do not face this issue. They will use the link (or not) based on 
other criteria which remain application specific.

This is what we try to capture (more succinctly) in the sentence:

“In the presence of
   an application where the advertisement of link attribute
   advertisements is used to infer the enablement of an application on
   that link (e.g., RSVP-TE), the absence of the application identifier
   leaves ambiguous whether that application is enabled on such a link.”

I don’t know if this helps, but I am trying… 

   Les


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


Re: [Lsr] Martin Duke's No Objection on draft-ietf-isis-te-app-14: (with COMMENT)

2020-06-09 Thread Les Ginsberg (ginsberg)
Martin -

> -Original Message-
> From: Martin Duke 
> Sent: Tuesday, June 09, 2020 9:02 AM
> To: Les Ginsberg (ginsberg) 
> Cc: The IESG ; lsr-cha...@ietf.org; aretana.i...@gmail.com;
> Acee Lindem (acee) ; draft-ietf-isis-te-...@ietf.org;
> lsr@ietf.org
> Subject: Re: [Lsr] Martin Duke's No Objection on draft-ietf-isis-te-app-14:
> (with COMMENT)
> 
> Lee,
> 
> Responses inline.
> 
> On Mon, Jun 8, 2020 at 9:57 PM Les Ginsberg (ginsberg)
> 
> wrote:
> 
> >
> > > --
> > > COMMENT:
> > > --
> > >
> > > I know very little about this, but just checking:
> > > - I trust that a network that mixes routers that use application
> > attributes,
> > > and not, will not lead to long-term routing loops in spite of them not
> > having a
> > > common picture of the network?
> > >
> > [Les:] Traffic engineering policies are calculated by the headend/ingress
> > node. Based on the calculation a set of forwarding instructions are imposed
> > on a packet (e.g., MPLS labels) which direct forwarding of the packet
> > towards the destination. Intermediate nodes are unaware of the policy -
> > they simply forward the packet based on the forwarding instruction.  So
> the
> > fact that intermediate nodes may not themselves process link attribute
> > advertisements does not introduce loops.
> >
> 
> I see, thanks, that makes sense.
> 
> 
> >
> > > - It is odd that a link that advertises a zero-length flags field means
> > support
> > > for RSVP-TE is “ambiguous” (sec 5). What are the implications of this?
> > When
> > > is
> > > it OK to use a zero-length flags field given this ambiguity? In a
> > standard, can
> > > we not decide on a meaning to eliminate the uncertainty? I would
> > appreciate
> > > some language here to answer at least the first two questions.
> > >
> > [Les:] The use of zero length application bit mask is discussed in Section
> > 4.2 and Section 6.2. This can be convenient in that one set of link
> > attribute advertisements can be used for all applications and as
> > applications are enabled/disabled the advertisement of link attributes does
> > not have to be modified in any way. But it can also lead to unintended use
> > of link attribute advertisements by an application. This latter point is
> > discussed in Section 6.2.
> >
> > Section 5 is discussing whether the presence of link attribute
> > advertisements serve to indicate enablement of a given application on the
> > associated link for the three applications defined in this draft (RSVP-TE:
> > yes, SRTE and LFA: no).
> > The text in Section 5 that you ask about indicates that in the special
> > case where zero length Application Bit Mask is associated with link
> > attribute advertisements, for an application (RSVP-TE) which utilizes link
> > attributes to indicate application enablement, the lack of an explicit
> > application bit introduces ambiguity as to whether the application should
> > be considered enabled on the link or not. This is why we include the
> > cautionary statement:
> >
> > " This needs to be considered when making use of the "any application"
> >encoding."
> >
> > So I believe the draft does address your concerns.
> >
> 
> Thank you for clarifying. Your explanation conforms with my understanding
> from reading the document. Maybe this obvious to people in the field, but
> under what circumstances would I decline to use "any application" encoding?
> I think the draft indicates the first level implications (we don't have
> confirmed enablement) but under what circumstances is that OK? If there is
> out of band information that it's globally enabled? Or can RSVP-TE function
> if it turns out some aren't enabled?
> 
> 
[Les:] The use of "any application" is only possible if the same link attribute 
values can be used by all applications which are in use in that deployment. 
This is a decision that can only be made based on the deployment.
The discussion of "enablement" is pointing out a possible side effect even if 
the first set of conditions are met.

To my mind, the use of "any application" is likely NOT the default mode of 
operation even when the preconditions are met - but this is an implementation 
choice not subject to standardization.

Les


> >
> > > - as the TSVart review points out, the length field wastes 3 bits of 7
> > because
> > > the maximum length is 8. You could reserve them or even use them to
> > > encode
> > > these three legacy applications.
> > >
> > [Les:] As indicated in my previous response to this comment, the
> > limitation to 8 bytes maximum was put in late based upon a review
> comment
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


Re: [Lsr] Martin Duke's No Objection on draft-ietf-isis-te-app-14: (with COMMENT)

2020-06-08 Thread Les Ginsberg (ginsberg)
Martin -

Thanx for your review.
A new version will be published soon - pending resolution of comments from 
another review - that addresses issues you have raised - subject to my 
responses inline.

> -Original Message-
> From: Lsr  On Behalf Of Martin Duke via Datatracker
> Sent: Monday, June 08, 2020 5:34 PM
> To: The IESG 
> Cc: lsr-cha...@ietf.org; aretana.i...@gmail.com; Acee Lindem (acee)
> ; draft-ietf-isis-te-...@ietf.org; lsr@ietf.org
> Subject: [Lsr] Martin Duke's No Objection on draft-ietf-isis-te-app-14: (with
> COMMENT)
> 
> Martin Duke has entered the following ballot position for
> draft-ietf-isis-te-app-14: 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-te-app/
> 
> 
> 
> --
> COMMENT:
> --
> 
> I know very little about this, but just checking:
> - I trust that a network that mixes routers that use application attributes,
> and not, will not lead to long-term routing loops in spite of them not having 
> a
> common picture of the network?
> 
[Les:] Traffic engineering policies are calculated by the headend/ingress node. 
Based on the calculation a set of forwarding instructions are imposed on a 
packet (e.g., MPLS labels) which direct forwarding of the packet towards the 
destination. Intermediate nodes are unaware of the policy - they simply forward 
the packet based on the forwarding instruction.  So the fact that intermediate 
nodes may not themselves process link attribute advertisements does not 
introduce loops.

> - It is odd that a link that advertises a zero-length flags field means 
> support
> for RSVP-TE is “ambiguous” (sec 5). What are the implications of this? When
> is
> it OK to use a zero-length flags field given this ambiguity? In a standard, 
> can
> we not decide on a meaning to eliminate the uncertainty? I would appreciate
> some language here to answer at least the first two questions.
> 
[Les:] The use of zero length application bit mask is discussed in Section 4.2 
and Section 6.2. This can be convenient in that one set of link attribute 
advertisements can be used for all applications and as applications are 
enabled/disabled the advertisement of link attributes does not have to be 
modified in any way. But it can also lead to unintended use of link attribute 
advertisements by an application. This latter point is discussed in Section 6.2.

Section 5 is discussing whether the presence of link attribute advertisements 
serve to indicate enablement of a given application on the associated link for 
the three applications defined in this draft (RSVP-TE: yes, SRTE and LFA: no).
The text in Section 5 that you ask about indicates that in the special case 
where zero length Application Bit Mask is associated with link attribute 
advertisements, for an application (RSVP-TE) which utilizes link attributes to 
indicate application enablement, the lack of an explicit application bit 
introduces ambiguity as to whether the application should be considered enabled 
on the link or not. This is why we include the cautionary statement:

" This needs to be considered when making use of the "any application"
   encoding."

So I believe the draft does address your concerns.

> - as the TSVart review points out, the length field wastes 3 bits of 7 because
> the maximum length is 8. You could reserve them or even use them to
> encode
> these three legacy applications.
> 
[Les:] As indicated in my previous response to this comment, the limitation to 
8 bytes maximum was put in late based upon a review comment. There are already 
implementations of the draft deployed. Changing the format of the fields would 
result in backwards compatibility issues with these early implementations. The 
very minor savings in encoding (1 byte maximum) is not significant enough to 
warrant introducing backwards compatibility issues.

I do appreciate that you (and Kyle) have frugality in mind.

> Nits:
> 
> Abstract:
> In “these link attributes for a given attribute” add a comma after both
> instances of attribute(s)

[Les:] Done.

> 
> Sec 4 2)Application. Add a space

[Les:] Apologies - but I cannot find an instance in which a space is needed and 
not already present. Perhaps you could provide more context so I could locate 
the specific sentence involved. I did search for all occurrences of 
"Application".

> 
> Sec 5. Missing a period at the end of “existence of link attribute
> advertisements”

[Les:] Done.

   Les

> 
> 
> 
> 

Re: [Lsr] Murray Kucherawy's Discuss on draft-ietf-isis-te-app-14: (with DISCUSS and COMMENT)

2020-06-08 Thread Les Ginsberg (ginsberg)
Murray -



Thanx for the review.

Responses inline.

I'll post a new version once we have closed on all your comments.



> -Original Message-

> From: Murray Kucherawy via Datatracker 

> Sent: Monday, June 08, 2020 12:30 PM

> To: The IESG 

> Cc: draft-ietf-isis-te-...@ietf.org; lsr-cha...@ietf.org; lsr@ietf.org; Acee

> Lindem (acee) ; aretana.i...@gmail.com

> Subject: Murray Kucherawy's Discuss on draft-ietf-isis-te-app-14: (with

> DISCUSS and COMMENT)

>

> Murray Kucherawy has entered the following ballot position for

> draft-ietf-isis-te-app-14: 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-te-app/

>

>

>

> --

> DISCUSS:

> --

>

> An easy one:

>

> Sections 7.3 and 7.5 create new IANA registries with "Expert Review" rules,

> but

> Section 7.5 provides no particular guidance to the Designated Expert about

> how

> to review applications, as required by Section 4.5 of BCP 26.



[Les:] IS-IS registries are guided by RFC 7370 (referenced in Section 7 and in 
https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml 
) - which does provide guidance to the experts.

There is some additional guidance in Section 7.3 because we want codepoints in 
the existing "sub-TLV of TLVs 22, 23, 25, 141, 222, and 223" registry to be in 
sync with the new registry whenever possible.

For Section 7.5 there really isn’t anything else to say beyond what RFC 7370 
says.



??



>

>

> --

> COMMENT:

> --

>

> Since this document is in many parts a copy of

> draft-ietf-ospf-te-link-attr-reuse, I'm only reviewing this delta between

> them

> here:

> https://www.ietf.org/rfcdiff?url1=draft-ietf-ospf-te-link-attr-reuse-

> 14=draft-ietf-isis-te-app-14

>

> Section 2:

> * "... expected to continue - so any discussion ..." -- change to "... 
> expected

> to continue.  Therefore, any discussion ..." * "... key points identified in

> the introduction - which are:" -- change hyphen to a comma

>



[Les:] Done.



> Section 3:

> * "... advertisements include sub-TLVs for TLVs ..." -- Please define or 
> expand

> "TLV" on first use. * Please just name the registries, rather than giving

> multi-line URLs to them.

>



[Les:] "TLV" is marked as "well known" in 
https://www.rfc-editor.org/materials/abbrev.expansion.txt .

If you insist I will expand on first use, but not convinced it is necessary.



> Section 3.1:

> * As with the matching OSPF document, I don't see the benefit of citing

> current

> registry contents rather than just referencing the registry.

>

[Les:] The reason we list the existing code points is because we are using the 
same numeric values for the equivalent sub-sub-TLVs in the new ""sub-sub-TLV 
code points for application specific link attributes".

And we aren't listing all of the sub-TLVs currently defined - just the ones 
which historically have been used by RSVP-TE and which will also be used by the 
new Application Specific sub-TLV.

So I think there is value in listing the current code points of interest.



> Section 4.3:

> * Interestingly, the entries for IPv4 are not capitalized (e.g., "interface

> address"), but they are for IPv6 (e.g., "Interface Address").

>

[Les:] You and Eric Vyncke must have the same eye doctor. 

Here is my response to Eric:





You are correct in identifying this inconsistency - but note that the draft 
follows what is in 
https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-22-23-25-141-222-223
 .



It seems this discrepancy involves RFCs 5305 and 6119 as well.





> Section 6.3.2:

> * These two paragraphs read like they're in the wrong order.

>

[Les:] No - the second paragraph is clarifying the usage of the first. I have 
modified the first sentence of the second paragraph to be:



" These guidelines apply to cases where ..."



Does that help?





> Sections 7.1 and 7.2:

> * These should refer back to Sections 4.2 and 4.3, respectively, where the

> new

> values are fully described.

[Les:] Done.



   Les



>

>


___
Lsr 

Re: [Lsr] Éric Vyncke's No Objection on draft-ietf-isis-te-app-14: (with COMMENT)

2020-06-08 Thread Les Ginsberg (ginsberg)
Eric -



Thanx for your review.

Please see inline.



> -Original Message-

> From: Éric Vyncke via Datatracker 

> Sent: Monday, June 08, 2020 6:06 AM

> To: The IESG 

> Cc: draft-ietf-isis-te-...@ietf.org; lsr-cha...@ietf.org; lsr@ietf.org; Acee

> Lindem (acee) ; aretana.i...@gmail.com; Acee Lindem

> (acee) 

> Subject: Éric Vyncke's No Objection on draft-ietf-isis-te-app-14: (with

> COMMENT)

>

> Éric Vyncke has entered the following ballot position for

> draft-ietf-isis-te-app-14: 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-te-app/

>

>

>

> --

> COMMENT:

> --

>

> Thank you for the work put into this document. I have only one nits in section

> 4.3: while I appreciate IPv6, there is no need to capitalize 'IPv6 Interface

> Address' as "IPv4 interface address" is not capitalized ;-)



[Les:] You are correct in identifying this inconsistency - but note that the 
draft follows what is in 
https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-22-23-25-141-222-223
 .





It seems this discrepancy involves RFCs 5305 and 6119 as well.



   Les



>

> Special thanks to Acee, as the document shepherd he managed to represent

> the

> conflicts within the WG.

>

> I hope that this helps to improve the document,

>

> Regards,

>

> -éric

>

>


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


Re: [Lsr] Rtgdir last call review of draft-ietf-isis-te-app-13

2020-06-05 Thread Les Ginsberg (ginsberg)
Bruno -



Inline.



> -Original Message-

> From: bruno.decra...@orange.com 

> Sent: Friday, June 05, 2020 5:55 AM

> To: Les Ginsberg (ginsberg) 

> Cc: last-c...@ietf.org; draft-ietf-isis-te-app@ietf.org; lsr@ietf.org; 
> rtg-

> d...@ietf.org

> Subject: RE: Rtgdir last call review of draft-ietf-isis-te-app-13

>

> Les,

>

> Thanks for the updated draft.

> Looks ok to me except the point on interoperability.

>

> Indeed, I was asking to reinforce the requirement for interoperability with

> existing attributes, as this interop issue is created by this

> specification/extension. But you chose the opposite direction by calling

> existing routers "legacy routers" and by removing the "must" in the below

> sentence from -13 "must be able to co-exist with use  of the legacy

> advertisements by routers which do not support the extensions defined in

> this document.".

> IMHO this document was primarily motivated by interoperability issues with

> implementations. This was correctly pointed out in [1], more specifically "

> Existing IS-IS standards do not provide a mechanism to explicitly indicate

> whether or not RSVP has been enabled on a link.  Instead, different RSVP-TE

> implementations have used the presence of certain traffic engineering sub-

> TLVs in IS-IS to infer that RSVP signalling is enabled on a given link."

>



[Les:] This is not correct.

The motivations for the draft are stated in the Introduction.

The issue discussed in 
https://datatracker.ietf.org/doc/html/draft-hegde-isis-advertising-te-protocols-03#section-1
 has nothing to do with this draft.



> In such condition, IMHO draft-ietf-isis-te-app should not have the potential

> to create new interop issues in the future, otherwise its net gain with 
> regards

> to existing ("legacy") attributes seems debatable to me.

>

> Moving the requirement for interoperability on the deployment side (i.e.,

> network operator) as per -14, may prove difficult or impossible if

> implementers are not willing to accommodate. Given that, as you state it,

> there motivation is what's good for _their_ business, it seems a possibility

> that such vendor would argue that the network operator should just replace

> all their "older" routers with new ones, and as a matter of luck, they do have

> a very good deal to propose. I have seen this movie before (e.g. with LDP &

> TDP).

>

> I also understand your point as a vendor.

> After thinking about it for a while, I'd propose a resolution around 
> indicating

> that interoperability is required but only for implementations supporting

> both new and current attributes. This cover my point for interop and a priori

> cover your point to allow implementation to only support the new attributes.

>

> e.g. with the below text in §6.1

> OLD:

> Under the conditions defined above, implementations which support the

>extensions defined in this document have the choice of using legacy

>advertisements or application specific advertisements in support of

>SRTE and/or LFA.  This will require implementations to provide

>controls specifying which type of advertisements are to be sent/

>processed on receive for these applications.

>

> NEW:

> Under the conditions defined above, implementations which support

> both the legacy advertisements and the extensions defined in this document

> MUST provide controls  specifying which type of

> advertisements are to be sent and which type of advertisements are to be

> processed on receive for these applications.

>

> Or possibly much closer to your original text

> NEW2

> Under the conditions defined above, implementations which support

>  both the legacy advertisements and the extensions defined in this

> document

> have the choice of using legacy

>advertisements or application specific advertisements in support of

>SRTE and/or LFA.  Implementations are REQUIRED to provide

>controls specifying which type of advertisements are to be sent/

>processed on receive for these applications.

>



[Les:] It is not within the purview of the IETF to mandate what features 
vendors support.

What is normative in this draft - as with all protocol enhancements - is the 
definition of how "bits on the wire" are sent/received.



The introduction of any protocol extension in brownfield deployments creates 
the possibility that some routers support the extension and some do not.

How vendors handle this is an implementation issue.

We have provided guidance in this draft as to what issues may arise and what 
strategies can be used to address the interoperability issues - as well as how 
to migrate from a mix

Re: [Lsr] Genart last call review of draft-ietf-isis-te-app-13

2020-06-04 Thread Les Ginsberg (ginsberg)
Jouni -

Just to let you know that V14 of the draft was posted today and it includes all 
of the corrections you requested.
Thanx again for your review.

   Les


> -Original Message-
> From: Les Ginsberg (ginsberg) 
> Sent: Friday, May 29, 2020 8:02 AM
> To: Jouni Korhonen ; gen-...@ietf.org
> Cc: last-c...@ietf.org; draft-ietf-isis-te-app@ietf.org; lsr@ietf.org
> Subject: RE: Genart last call review of draft-ietf-isis-te-app-13
> 
> Jouni -
> 
> Thanx for the review.
> 
> I have addressed the editorial issues you raised - though I will wait for
> additional comments from other reviewers before publishing a new version.
> 
>Les
> 
> 
> > -Original Message-
> > From: Jouni Korhonen via Datatracker 
> > Sent: Friday, May 29, 2020 6:11 AM
> > To: gen-...@ietf.org
> > Cc: last-c...@ietf.org; draft-ietf-isis-te-app@ietf.org; lsr@ietf.org
> > Subject: Genart last call review of draft-ietf-isis-te-app-13
> >
> > Reviewer: Jouni Korhonen
> > 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>.
> >
> > Document: draft-ietf-isis-te-app-??
> > Reviewer: Jouni Korhonen
> > Review Date: 2020-05-29
> > IETF LC End Date: 2020-05-29
> > IESG Telechat date: Not scheduled for a telechat
> >
> > Summary:
> >
> > Not really my area of expertise, however, I did not spot any issues during
> the
> > review. The document is ready for publication.
> >
> > Major issues:
> >
> > None.
> >
> > Minor issues:
> >
> > None.
> >
> > Nits/editorial comments:
> >
> > * There are spacing issues mostly with parenthesis in the text that the RFC
> > editor likely takes care of. * On line 165 SR is used without expanding it. 
> > The
> > expansion is obvious but the RFC has both "Segment Routing" and "Shared
> > Risk"
> > used with SRxx.. * At least Section 5 has "is NOT" and "does NOT" emphasis
> > used. I would use just "is not" and "does not", since those with "NOT" are
> > not
> > in listed in normal "Requirements Language".
> >

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


Re: [Lsr] Rtgdir last call review of draft-ietf-isis-te-app-13

2020-06-04 Thread Les Ginsberg (ginsberg)
Bruno -

Thanx again for your review.
V14 of the draft has been posted to address your comments.

Please let me know if you believe there are still outstanding issues.

A few more remarks inline.

> -Original Message-
> From: bruno.decra...@orange.com 
> Sent: Tuesday, June 02, 2020 9:33 AM
> To: Les Ginsberg (ginsberg) 
> Cc: last-c...@ietf.org; draft-ietf-isis-te-app@ietf.org; lsr@ietf.org; 
> rtg-
> d...@ietf.org
> Subject: RE: Rtgdir last call review of draft-ietf-isis-te-app-13
> 
> Les,
> 
> Thanks for your answers.
> Comments inline
> 
> > From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
> > Sent: Saturday, May 30, 2020 12:09 AM
> >
> > Bruno -
> >
> > Thanx for your (as always) meticulous review.
> > Responses inline.
> > Once we have reached agreement I will send out an updated version.
> >
> > > -Original Message-
> > > From: Bruno Decraene via Datatracker 
> > > Sent: Friday, May 29, 2020 10:18 AM
> > > To: rtg-...@ietf.org
> > > Cc: last-c...@ietf.org; draft-ietf-isis-te-app@ietf.org; lsr@ietf.org
> > > Subject: Rtgdir last call review of draft-ietf-isis-te-app-13
> > >
> > > Reviewer: Bruno Decraene
> > > Review result: Has Issues
> > >
> > >  Hello,
> > >
> > > I have been selected as the Routing Directorate reviewer for this draft.
> The
> > > Routing Directorate seeks to review all routing or routing-related drafts 
> > > as
> > > they pass through IETF last call and IESG review, and sometimes on
> special
> > > request. The purpose of the review is to provide assistance to the
> Routing
> > > ADs.
> > > For more information about the Routing Directorate, please see
> > > http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
> > >
> > > Although these comments are primarily for the use of the Routing ADs, it
> > > would
> > > be helpful if you could consider them along with any other IETF Last Call
> > > comments that you receive, and strive to resolve them through
> discussion or
> > > by
> > > updating the draft.
> > >
> > > Document: draft-ietf-isis-te-app-13
> > > Reviewer: Bruno Decraene
> > > Review Date: 2020-05-29
> > > IETF LC End Date: 2020-05-29
> > > Intended Status: Standards Track
> > >
> > > Summary:
> > > I have some minor concerns about this document that I think should be
> > > resolved before publication.
> > >
> > > Comments:
> > >   Draft is clear.
> > >
> > > Minor Issues:
> > >
> > > §4.1
> > > *2 (for SABM & UDABM fields)
> > > OLD: The length SHOULD be the minimum required to send all bits which
> are
> > > set.
> > > I'd propose
> > > NEW: The length SHOULD be the minimum required to send all the
> > > meaningful bits
> > > which are set.
> > >
> > > Motivation; the 'bits which are sent' are the bits in the SABM field. 
> > > (they
> do
> > > include non-meaningful and padding bits)
> > >
> >
> > [Les:] The definition of what is "meaningful" and what is "padding"  to me 
> > is
> ambiguous.
> > Meaningful could be only those bits which are currently defined in the
> registry (speaking of SABM here). But if there are 10 bits defined in the
> registry and I only intend to set Bit 5, I do not need to send all 10 bits - 
> I only
> need to send one octet - because we state:
> >
> > "Bits that are NOT transmitted MUST be treated as if they
>> are set to 0 on receipt.  "
> >
> > Also, an implementation written when there were only 4 bits defined in
> the registry might think that "meaningful" is different than an
> implementation written when more than 8 bits were defined in the registry.
> Yet they can still interoperate.
> >
> > I believe the current language is best.
> 
> [Bruno]
> I withdraw my comment. Sorry for the noise.
> I had read "bits which are sent", while the text is "bits which are set".
> 
> 
> > > 
> > >
> > > OLD: Undefined bits MUST be transmitted as 0
> > > NEW: Undefined transmitted bits MUST be cleared (0)
> > >
> > > Motivation: currently the number of undefined bits is 8*8-3. They
> SHOULD
> > > not be
> > > transmitted (beyond the first ones fitting in the first N required octet).
> The
> > > sentence "Undefined bits MUST be transmi

Re: [Lsr] [IANA #1171772] Early Allocations request for "Area Proxy for IS-IS" - draft-li-lsr-isis-area-proxy-04

2020-06-04 Thread Les Ginsberg (ginsberg)
Folks -

Replying to the WG list on this as we believe this is of interest to the entire 
WG.

The designated experts (Chris, Hannes, and myself) have discussed the request 
for early codepoint allocations for draft-li-lsr-isis-area-proxy-04.

Ordinarily such requests are routine. Our task is only to perform due diligence 
to insure that the codepoints are assigned appropriately.

In this case however, we are - for the first time - being asked to provide 
early allocations for a document which has yet to be adopted by the WG.
Guidance for us is provided in RFC7370. 
Specifically

Section 4 which states

"2.  The Designated Experts SHOULD only consider requests that arise
   from I-Ds that have already been accepted as Working Group
   documents or that are planned for progression as AD Sponsored
   documents in the absence of a suitably chartered Working Group."

This recommendation is sound since early allocations for documents which do not 
achieve RFC status ultimately expire and are deallocated under the
procedures defined in rfc7120 . While WG 
adoption is not a guarantee of successful progression to RFC, it does commit 
the WG to working on such documents and greatly enhances the chances of
an RFC being published.

While the language above allows for exceptions, we are reluctant to make an 
exception in this case.

We note that the problem space being addressed by draft-li-lsr-isis-area-proxy 
has stimulated multiple solutions/drafts. The likelihood that some of the 
proposed solutions would be abandoned and/or not achieve market acceptance 
seems high.
Early allocation of code points without a WG commitment then seems to have a 
higher than normal probability that the codepoint allocations would ultimately 
be deallocated.

We believe that the WG needs to invest time in deciding which solutions should 
go forward. We therefore encourage the WG to make expeditious decisions 
regarding WG adoption of one (or perhaps multiple) of the drafts addressing 
this problem space.

We will be happy to quickly review early allocation requests for any documents 
as soon as they achieve WG status.

   Les and Chris and Hannes






> -Original Message-

> From: Lsr  On Behalf Of Amanda Baber via RT

> Sent: Monday, June 01, 2020 6:13 PM

> To: Acee Lindem (acee) 

> Cc: lsr@ietf.org; martin.vigour...@nokia.com

> Subject: [Lsr] [IANA #1171772] Early Allocations request for "Area Proxy for

> IS-IS" - draft-li-lsr-isis-area-proxy-04

>

> Hi Acee, Martin,

>

> We've sent this request to the IS-IS experts for review in accordance with

> the RFC 7370 early allocation procedure for IS-IS Expert Review registries.

>

> We understand that if the experts approve, we would make three

> early/temporary registrations in the TLV Codepoints registry and add one

> entry to the Sub-TLVs for TLV 242 (IS-IS Router CAPABILITY TLV) registry. The

> creation of the sub-registry will have to wait for the document to be

> approved for publication.

>

> However, the IANA Considerations section is missing some information. How

> would we fill in the IIH, LSP, SNP, and Purge fields for the TLV Codepoint

> registrations?

>

> Best regards,

>

> Amanda Baber

> Lead IANA Services Specialist

>

> On Mon Jun 01 19:46:54 2020, a...@cisco.com wrote:

> > Hi IANA, Martin,

> >

> > We’ve discussed this draft and are going forward with the early

> > allocation request. While there is some overlap with other LSR WG

> > proposals, there is no reason to block all the drafts given that it

> > very unlikely that we will have a combined draft any time soon.

> >

> > Thanks,

> > Acee and Chris

>

> ___

> Lsr mailing list

> Lsr@ietf.org

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


[Lsr] Request WG Adoption of draft-chen-lsr-isis-rfc5316bis-02.txt

2020-06-03 Thread Les Ginsberg (ginsberg)
WG Chairs -

This draft has been around for a few years now.
It makes a minor change to RFC 5316 to allow support in an IPv6 only network 
(no IPv4 support).
It is the Inter AS equivalent to the work already completed for Router 
Capabilities (RFC 7981).

Could you please start a WG adoption call for this draft.

Thanx.

Les


> -Original Message-
> From: Lsr  On Behalf Of Les Ginsberg (ginsberg)
> Sent: Wednesday, June 03, 2020 8:51 AM
> To: lsr@ietf.org
> Subject: [Lsr] FW: New Version Notification for 
> draft-chen-lsr-isis-rfc5316bis-
> 02.txt
> 
> Folks -
> 
> This is a refresh on this draft.
> 
>Les
> 
> -Original Message-
> From: internet-dra...@ietf.org 
> Sent: Wednesday, June 03, 2020 6:56 AM
> To: Les Ginsberg (ginsberg) ; Stefano Previdi
> ; Mach Chen (Guoyi) ;
> Mach Chen ; Xiaodong Duan
> 
> Subject: New Version Notification for draft-chen-lsr-isis-rfc5316bis-02.txt
> 
> 
> A new version of I-D, draft-chen-lsr-isis-rfc5316bis-02.txt
> has been successfully submitted by Les Ginsberg and posted to the
> IETF repository.
> 
> Name: draft-chen-lsr-isis-rfc5316bis
> Revision: 02
> Title:ISIS Extensions in Support of Inter-Autonomous System 
> (AS)
> MPLS and GMPLS Traffic Engineering
> Document date:2020-06-03
> Group:Individual Submission
> Pages:20
> URL:https://www.ietf.org/internet-drafts/draft-chen-lsr-isis-
> rfc5316bis-02.txt
> Status: 
> https://datatracker.ietf.org/doc/draft-chen-lsr-isis-rfc5316bis/
> Htmlized:   https://tools.ietf.org/html/draft-chen-lsr-isis-rfc5316bis-02
> Htmlized:   https://datatracker.ietf.org/doc/html/draft-chen-lsr-isis-
> rfc5316bis
> Diff:   
> https://www.ietf.org/rfcdiff?url2=draft-chen-lsr-isis-rfc5316bis-02
> 
> Abstract:
>This document describes extensions to the Intermediate System to
>Intermediate System (IS-IS) protocol to support Multiprotocol Label
>Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering
>(TE) for multiple Autonomous Systems (ASs).  It defines IS-IS
>extensions for the flooding of TE information about inter-AS links,
>which can be used to perform inter-AS TE path computation.
> 
>No support for flooding information from within one AS to another AS
>is proposed or defined in this document.
> 
>This document obsoletes RFC 5316.
> 
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 
> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

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


  1   2   3   4   >