Re: [Lsr] New Version Notification for draft-wu-lsr-pce-discovery-security-support-00.txt

[Qin Wu]

Hi, Folks:
draft-wu-pce-discovery-pceps-support-07 has been resubmitted to LSR as 
draft-wu-lsr-pce-discovery-security-support-00 based on Chairs' suggestion.
https://tools.ietf.org/html/draft-wu-lsr-pce-discovery-security-support-00
This draft define IGP extension for PCEP security support, 
1.TCP AO which has been published as RFC5295.
2.PCEP over TLS which has been published as RFC8253 recently.

One issue raised by chair is shared key support for TCP-AO, how do you get 
shared key?
we believe to support TCP-AO, RFC5296 should also be implemented, which provide 
PSK and associated ciphersuit.
Let us know if you have any other opinion?

-Qin
-邮件原件-
发件人: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
发送时间: 2018年8月24日 10:57
收件人: Daniel King; wangzitao; Dhruv Dhody; wangzitao; Diego R. Lopez; Diego 
Lopez; Qin Wu
主题: New Version Notification for 
draft-wu-lsr-pce-discovery-security-support-00.txt


A new version of I-D, draft-wu-lsr-pce-discovery-security-support-00.txt
has been successfully submitted by Qin Wu and posted to the IETF repository.

Name:   draft-wu-lsr-pce-discovery-security-support
Revision:   00
Title:  IGP extension for PCEP security capability support in the PCE 
discovery
Document date:  2018-08-23
Group:  Individual Submission
Pages:  6
URL:
https://www.ietf.org/internet-drafts/draft-wu-lsr-pce-discovery-security-support-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-wu-lsr-pce-discovery-security-support/
Htmlized:   
https://tools.ietf.org/html/draft-wu-lsr-pce-discovery-security-support-00
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-wu-lsr-pce-discovery-security-support


Abstract:
   When a Path Computation Element (PCE) is a Label Switching Router
   (LSR) participating in the Interior Gateway Protocol (IGP), or even a
   server participating in IGP, its presence and path computation
   capabilities can be advertised using IGP flooding.  The IGP
   extensions for PCE discovery (RFC 5088 and RFC 5089) define a method
   to advertise path computation capabilities using IGP flooding for
   OSPF and IS-IS respectively.  However these specifications lack a
   method to advertise PCEP security (e.g., Transport Layer
   Security(TLS),TCP Authentication Option (TCP-AO)) support capability.

   This document proposes new capability flag bits for PCE-CAP-FLAGS
   sub-TLV that can be announced as attribute in the IGP advertisement
   to distribute PCEP security support information.


  


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] LSR Flooding Reduction Drafts - Moving Forward

[Jeff Tantsura]

Peter,

As previously stated - I'm against gating, it should be developed in parallel 
and with cooperation with the ongoing/existing work.
Note - there's a document (albeit expired, it played its role) that talks about 
generic DC Routing requirements, work in LSR would be scooped to LSR only.
So no going into religious discussions - new vs old/ls vs pv, etc, but focusing 
on ospf/isis and what is needed for DC specifically.
I think it would be good to do some gain/complexity mental exercise...  

Cheers,
Jeff

On 8/23/18, 02:05, "Peter Psenak"  wrote:

Jeff, All,

we have added many extensions to IGP protocols over the years. Many 
times multiple solutions were proposed for the same or similar problem 
and WG picked from the set, many times multiple solutions were merged or 
combined together. We never asked for a requirement document. Even for 
more significant changes then we are talking about here.

I understand that the area of DC routing using IGPs is a broader area, 
but it does not fundamentally change IGPs to warrant the need for 
requirement document as a prerequisite to move forward with any work 
that is related to any optimization that may be applicable to DC 
environment.

So while I'm not against the existence of the document that would cover 
the requirements for IGPs in DC environments , I don't believe we should 
gate all proposed work in this space by such a document. And to be 
completely honest, the requirements are pretty straightforward for 
anyone that is familiar with the protocols' operation.

my 2c,
Peter

On 22/08/18 18:42 , Jeff Tantsura wrote:
> +1 Tony
>
> We could start with a document, similar to dc-routing requirements one
> we did in RTGWG before chartering RIFT and LSVR.
> Would help to disambiguate requirements from claims and have apple to
> apple comparison.
> Doing it on github was a good experience.
>
>
> Regards,
> Jeff
>
> On Aug 22, 2018, at 09:27, Tony Li  > wrote:
>
>>
>>
>>> At IETF 102, there was no dearth of flooding reduction proposals.  In
>>> fact, we have so many proposals that there wasn’t agree as how to
>>> move forward and we agreed to discuss on the list. This Email is to
>>> initiate that discussion (which I intend to participate in but as a
>>> WG member).
>>
>>
>> Hi Acee,
>>
>> Perhaps a useful starting point of the discussion is to talk about
>> requirements.  There seem to many different perceptions.
>>
>> Regards,
>> Tony
>>
>>
>> ___
>> Lsr mailing list
>> Lsr@ietf.org 
>> https://www..ietf.org/mailman/listinfo/lsr
>> 
>
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>




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

[Lsr] I-D Action: draft-ietf-ospf-segment-routing-msd-17.txt

[internet-drafts]

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

Title   : Signaling MSD (Maximum SID Depth) using OSPF
Authors : Jeff Tantsura
  Uma Chunduri
  Sam Aldrin
  Peter Psenak
Filename: draft-ietf-ospf-segment-routing-msd-17.txt
Pages   : 9
Date: 2018-08-23

Abstract:
   This document defines a way for an Open Shortest Path First (OSPF)
   Router to advertise multiple types of supported Maximum SID Depths
   (MSDs) at node and/or link granularity.  Such advertisements allow
   entities (e.g., centralized controllers) to determine whether a
   particular SID stack can be supported in a given network.  This
   document defines only one type of MSD, but defines an encoding that
   can support other MSD types.  Here the term OSPF means both OSPFv2
   and OSPFv3.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ospf-segment-routing-msd/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ospf-segment-routing-msd-17
https://datatracker.ietf.org/doc/html/draft-ietf-ospf-segment-routing-msd-17

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-segment-routing-msd-17


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

Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

[Huaimo Chen]

Hi Tony,

Regarding to the issues/problems you mentioned for flooding reduction 
(using distributed algorithm), can you give some more details?

Best Regards,
Huaimo
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Tony Przygienda
Sent: Wednesday, August 22, 2018 2:59 PM
To: ginsberg=40cisco@dmarc.ietf.org
Cc: lsr@ietf.org; Jeff Tantsura ; Tony Li 
; acee=40cisco@dmarc.ietf.org
Subject: Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

I do think it is a good idea in a sense to somehow outline WHAT problem is 
being solved via some write-down or mind-melt

a) I hope it's captured in the meeting notes but otherwise running the danger 
of repeating myself, the problem splits along the line of "directed graphs" 
(basically lattices) which DC topologies are today and generic graphs. In first 
case problem can be solved quite well (Pascal's idea based loosely on MANET in 
RIFT that could be stretched to flat flooding as well), in 2nd it's much harder.
b) Beside pure reduction, aspects like redundancy of the resulting mesh(es), 
minimal-cut properties and load balancing aspects emerge from practical pursuit 
of the problem (let's not even mention the dynamic re-convergence problems no 
matter whether some centralized instance floods or async distributed algorithm 
is run). Hence the scope or scopes of what needs being done seems prudent.
c) ultimately, other things like link properties and resulting meshes play a 
big role (MANET). In sparse networks we lived quite well without reduction but 
MANET/DSR had to deal with it already AFAIR & IP fabric seem to cause a 
different variation of the limitation to rear its head

2c

--- tony

On Wed, Aug 22, 2018 at 11:04 AM Les Ginsberg (ginsberg) 
mailto:40cisco@dmarc.ietf.org>> wrote:
In the discussions which led to the creation of LSVR and RIFT WGs, considerable 
interest was expressed in working on enhancements to existing Link State 
protocols. You can peruse the dcrouting mailing list archives.

https://mailarchive.ietf.org/arch/browse/dcrouting/

It is rather befuddling to me that the IETF seems to have decided to move 
forward on two new protocols (no objection from me) but seems to feel there is 
insufficient reason to move forward on proposals to extend existing IGPs.
I think the suggestion that we need to write (yet another)  requirements 
document before doing so is a recipe for delay – not for progress.

Multiple drafts have been presented over the course of the past two years and 
discussed on the list as well.
In the case of two of the drafts:

draft-shen-isis-spine-leaf-ext
draft-li-dynamic-flooding

WG adoption was requested in Montreal..

Please explain why we cannot proceed with “business as usual” as regards these 
drafts.


   Les


From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Jeff 
Tantsura
Sent: Wednesday, August 22, 2018 9:43 AM
To: Tony Li mailto:tony1ath...@gmail.com>>
Cc: lsr@ietf.org; Acee Lindem (acee) 
mailto:40cisco@dmarc.ietf.org>>
Subject: Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

+1 Tony

We could start with a document, similar to dc-routing requirements one we did 
in RTGWG before chartering RIFT and LSVR.
Would help to disambiguate requirements from claims and have apple to apple 
comparison.
Doing it on github was a good experience.

Regards,
Jeff

On Aug 22, 2018, at 09:27, Tony Li 
mailto:tony1ath...@gmail.com>> wrote:


At IETF 102, there was no dearth of flooding reduction proposals.  In fact, we 
have so many proposals that there wasn’t agree as how to move forward and we 
agreed to discuss on the list. This Email is to initiate that discussion (which 
I intend to participate in but as a WG member).


Hi Acee,

Perhaps a useful starting point of the discussion is to talk about 
requirements.  There seem to many different perceptions..

Regards,
Tony


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

Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

[Tony Przygienda]

On Thu, Aug 23, 2018 at 2:05 AM Peter Psenak  wrote:

> ...
>   And to be
> completely honest, the requirements are pretty straightforward for
> anyone that is familiar with the protocols' operation.
>
>
The signalling is quite simple as often the case, good quality algorithms,
especially distributed versions, anything but IME ...

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

Re: [Lsr] LSR Working Last Call for draft-ietf-ospf-yang - YANG is too complicated

[tom petch]

Acee

Tweaking the subject line slightly since this is a more generic point.

My point about
refine "version/ospfv2/ospfv2" {
 must "derived-from-or-self( "
 + "../../../../../../../../../../"
 + "rt:type, 'ospf:ospfv2')" {
 description "OSPFv2 LSA.";
was more about the difficulty of validating these conditionals in YANG.
It could be worse e.g.
  augment "/nw:networks/nw:network/nt:link/tet:te/"
+ "tet:te-link-attributes/"
+ "tet:max-resv-link-bandwidth/"
+ "tet:te-bandwidth/tet:technology" {
when "../../../../../../nw:network-types/tet:te-topology/"
   + "otntopo:otn-topology" {

occurring 100 or so times in an I-D.  Tools can check the syntax, they
can (almost) never check the semantics. It takes something more
intelligent, more knowledgeable than a tool to spot that e.g.
RFC 5178 - OSPFv3 Graceful Restart";
is wrong and I think the same of complicated YANG expressions.

If complicated expressions occur once, I could check them; 100 times, no
way.  Every other language (almost) I have used allows me to say
 must "derived-from-or-self( "
 + "../../../../../../../../../../"
 + "rt:type, 'ospf:ospfv2')" {
is equivalent to
 ospfv2 {type boolean}
so I need check the complicated expression once, subsequent uses being
just
 ospfv2
which is then obviously right or wrong.

You only have any one 'complicated' expression occurring half a dozen
times or so, but then there are a number of them, conditional on OSPF
version, LSA type and so on. If one instance of one expression was
syntactically valid but not quite right, perhaps missing 'or-self' or
/.. or some such, would anyone ever notice?

I see this as the biggest single defect in YANG that has only become
apparent with the use it is put to in the Routing Area; and it is YANG
that needs to change (IMHO).

Tom Petch

- Original Message -
From: "Acee Lindem (acee)" 
To: "tom petch" ; "Jeff Tantsura"
; 
Sent: Thursday, August 23, 2018 12:23 AM
Subject: Re: [Lsr] LSR Working Last Call for draft-ietf-ospf-yang


> Hi Tom,
>
> Thanks much Tom - I agree with your comments. See one inline.
>
> I will likely work on these prior to the end of the WG last call
period.
>
> On 8/22/18, 11:41 AM, "tom petch"  wrote:
>
>  Original Message -
> From: "Jeff Tantsura" 
> Sent: Friday, August 17, 2018 9:14 PM
>
> Acee,
>
> The draft is in good shape, support.
>
> 
>
> Mmm that sounds like a good challenge.  I had a quick look and
noticed:
>
> - NMDA gets discussed in s.2.1; I like to see support for it
mentioned
> earlier, in Abstract and Introduction, something I have seen the
IESG
> request recently
>
> - there is no explanation of the legend used in the tree diagrams;
if
> appropriate, this can be fixed with an Informative Reference to
RFC8340
>
> - s.2.4 NSR needs expanding IMHO
>
> - s.2.4 I would like a list of features, all 20 of them, not just
> "such as NSR, max-LSA, etc"
> so I don't have to reverse engineer the YANG module to find them;
as and
> when new features come along, I expect there will be a delay
before they
> make it into YANG so a clear list for those supported by this
module
> would be useful
>
> - sometimes it is 'link state database ', sometimes 'Link State
> Database', sometimes 'Link State database'; I would like
consistency
> (and prefer the capitalised version)
>
> I agree.
>
> - the YANG module as
> version 1.1
> but RFC7950 is not mentioned or referenced; odd
>
> - the YANG module has
> RFC 5178 - OSPFv3 Graceful Restart";
> which I think should be RFC 5187
>
> Yup.
>
> - the YANG module has
> "RFC  - YANG Data Model for Bidirectional Forwarding Detection
> (BFD)";
> "RFC : A YANG Data Model for OSPF.";
> "RFC  - SPF Back-off algorithm for link state IGPs";  RFC8405
>  reference "draft-ietf-bfd-yang-xx.txt:
>
> I suggest using a larger namespace than ''; perhaps '' and
> '' (since  "RFC  - SPF Back-off algorithm for link state
IGPs"
> is in fact RFC8405 and is already in the Normative References)
along
> with a note to the RFC Editor telling them what '' and ''
should
> be replaced with.
>
>  reviewing the technical bits is going to be a challenge; I
struggle to
> interpret such as
>  when "derived-from("
> +
"../../../../../areas/area[area-id=current()/../area-id]/"
> + "area-type, 'stub-nssa-area')" {
> or
>  refine "version/ospfv2/ospfv2" {
>must "derived-from-or-self( "
>   + "../../../../../../../../../../"
>   + "rt:type, 'ospf:ospfv2')" {
>  description "OSPFv2 LSA.";
>
> I note the use of "derived-from-or-self " as opposed to
"derived-from "
> but it will take me longer to work out if 

Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

[Peter Psenak]

Jeff, All,

we have added many extensions to IGP protocols over the years. Many 
times multiple solutions were proposed for the same or similar problem 
and WG picked from the set, many times multiple solutions were merged or 
combined together. We never asked for a requirement document. Even for 
more significant changes then we are talking about here.


I understand that the area of DC routing using IGPs is a broader area, 
but it does not fundamentally change IGPs to warrant the need for 
requirement document as a prerequisite to move forward with any work 
that is related to any optimization that may be applicable to DC 
environment.


So while I'm not against the existence of the document that would cover 
the requirements for IGPs in DC environments , I don't believe we should 
gate all proposed work in this space by such a document. And to be 
completely honest, the requirements are pretty straightforward for 
anyone that is familiar with the protocols' operation.


my 2c,
Peter

On 22/08/18 18:42 , Jeff Tantsura wrote:

+1 Tony

We could start with a document, similar to dc-routing requirements one
we did in RTGWG before chartering RIFT and LSVR.
Would help to disambiguate requirements from claims and have apple to
apple comparison.
Doing it on github was a good experience.


Regards,
Jeff

On Aug 22, 2018, at 09:27, Tony Li mailto:tony1ath...@gmail.com>> wrote:





At IETF 102, there was no dearth of flooding reduction proposals.  In
fact, we have so many proposals that there wasn’t agree as how to
move forward and we agreed to discuss on the list. This Email is to
initiate that discussion (which I intend to participate in but as a
WG member).



Hi Acee,

Perhaps a useful starting point of the discussion is to talk about
requirements.  There seem to many different perceptions.

Regards,
Tony


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




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



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