Re: [Lsr] 答复: 答复: 答复: Regarding OSPF extension for inter-area topology retrieval

[Dongjie (Jimmy)]

Hi Acee, Ketan and Aijun, 

I also agree that the introduction of source router ID could be a generic 
useful extension to OSPF, we already have this in IS-IS [RFC 7794]. 

As for the inter-area topology retrieval use case, I tend to agree that there 
can be multiple ways to achieve this, thus it would make sense to decouple this 
specific use case with the generic extension. 

Best regards,
Jie

> -Original Message-
> From: Acee Lindem (acee) [mailto:a...@cisco.com]
> Sent: Tuesday, July 24, 2018 10:37 PM
> To: Ketan Talaulikar (ketant) ; Peter Psenak (ppsenak)
> ; Aijun Wang ; 'Rob Shakir'
> 
> Cc: Dongjie (Jimmy) ; cho...@chopps.org; lsr@ietf.org
> Subject: Re: 答复: [Lsr] 答复: 答复: Regarding OSPF extension for inter-area
> topology retrieval
> 
> Hi Ketan,
> 
> On 7/24/18, 7:44 AM, "Ketan Talaulikar (ketant)"  wrote:
> 
> Hi Aijun,
> 
> Your draft introduces the Source Router ID which is, by itself, an useful
> protocol extension.
> 
> I agree. What is the use case for advertisement in IS-IS? Perhaps this could 
> be
> used as the primary motivation.
> 
> 
>However, the use-case on inter-as topology retrieval has issues which has
> been shared by many of us at the mike, offline and on the list.
> 
> And this could be moved to an appendix or even completely.
> 
> Thanks,
> Acee
> 
> Could you consider de-coupling the two?
> 
> Also, if the proposal for learning inter-AS as described by you works for 
> your
> own specific network design (and you don't think any of the points made affect
> that decision), then please go ahead. However, I do not see the point of 
> trying to
> get that as an IETF document?
> 
> Thanks,
> Ketan
> 
> -Original Message-
> From: Peter Psenak (ppsenak)
> Sent: 24 July 2018 04:22
> To: Aijun Wang ; 'Rob Shakir' 
> Cc: 'Dongjie (Jimmy)' ; cho...@chopps.org; Ketan
> Talaulikar (ketant) ; lsr@ietf.org; Acee Lindem (acee)
> 
> Subject: Re: 答复: [Lsr] 答复: 答复: Regarding OSPF extension for
> inter-area topology retrieval
> 
> Hi Aijun,
> 
> On 24/07/18 05:37 , Aijun Wang wrote:
> > _Hi, Peter:_
> >
> > For point-to-point interface, as described in  OSPFv2(RFC2328 12.4.1.1.
> Describing point-to-point interfaces)
> , the router LSA will include 
> two
> links description for each interface, within which the “type 3 link”(stub 
> network)
> will describe the subnet mask of the point-to-point interface.
> >
> > For broadcast/NBMA interface, the DR will be elected and it will
> > generate the network LSA which will include also the subnet mask of
> > the connected interface.
> >
> > For unnumbered and virtual link, if you consider we should include
> > them also for all possible scenarios even if we seldom use them in
> > large network, we can consider expand the summary LSA to cover it, as
> > done by this draft.
> 
> there is no way to address unnumbered p2p case your way, because there is
> no Summary LSA generated to other area in such case.
> 
> Anyway, reconstructing a topology of a remote area based on the prefix
> announcements that come from it is a broken concept. I have given you several
> examples where your proposal does not work.
> 
> thanks,
> Peter
> 
> >
> > For Anycast prefixes situation that you described(although we seldom
> > plan our network in such way), the PCE controller will not deduce the
> > wrong information from the reported information--Different router
> > advertise the same prefix, why can’t they be connected in logically?
> >
> > On summary, the ABR can know and report the originator of the
> > connected interface’s prefixes, and also the connected information for
> > the unnumbered/virtual link from the traditional router LSA/network
> > LSA message, thus can transfer them to the router that run BGP-LS,
> > then to the PCE controller to retrieval the topology.
> >
> > _To Rob: _
> >
> > BGP-LS is one prominent method to get the underlay network topology
> > and has more flexibility to control the topology export as described
> > in RFC
> > 7752 .
> >
> > Solution 1) that you proposed is possible, but we will not run two
> > different methods to get the topology.
> >
> > Solution 2) is also one possible deployment, but it eliminates the
> > advantage of the BGP-LS, in which it needs several interaction points
> > with the underlay network. and such deployment is not belong to
> > redundancy category as information got from different areaes are
> different.
> >
> > Solution 3)--Streaming telemetry technology should be used mainly for
> > the monitor of network devices, it requires the PCE controller to
> > contact with every router in the network, is also not the optimal
> > solution when compared with BGP

Re: [Lsr] 答复: 答复: Regarding OSPF extension for inter-area topology retrieval

[Tony Przygienda]

pretty obvious +1 here

--- tony

On Tue, Jul 24, 2018 at 3:41 AM Rob Shakir  wrote:

> +1 to Peter. We should not define fragile solutions within the IETF.
>
> There are also a multitude of other solutions here already:
>
> 1) IGP adjacency with one router in each area (at a minimum - probably two
> for a robust system) over a tunnel. Deployed in many networks for years.
> 2) BGP-LS to one router (ditto robustness comment) in each area.
> 3) streaming telemetry of the LSDB contents via gNMI.
>
> All these solutions exist in shipping implementations - please let’s not
> add to the system complexity of the IGP here.
>
> r.
> On Mon, Jul 23, 2018 at 12:30 Peter Psenak  40cisco@dmarc.ietf.org> wrote:
>
>> Hi Aijun,
>>
>> On 23/07/18 13:07 , Aijun Wang wrote:
>> > Hi, Peter:
>> >
>> > For routers that connected by LAN, the router will establish adjacent
>> > neighbor with DR, but not only DR advertises the connected prefixes.
>>
>> only the Network LSA includes the network mask, other routers would
>> include the interface address only.
>>
>>
>> > DR and
>> > DRother will all advertise type 1 and type 2 LSA with each other, then
>> the
>> > process and proposal described in this draft will still work.
>> > We seldom use the ip unnumbered features in our network, can we ignore
>> it
>> > then? Or other persons has some idea on such situation?
>>
>> the fact that you do not use unnumbered is not really relevant. IETF
>> defines solutions that MUST work for all possible scenarios, not only
>> for a specific one.
>>
>> > Anycast prefixes are often /32 long, this can be easily filtered by SDN
>> > controller because the link prefixes between two routers will be no
>> larger
>> > than /32 for IPv4 network.
>>
>> protocol allows to advertise the same prefix with an arbitrary mask from
>> multiple routers without these routers being directly connected. Your
>> proposal is based on the assumptions that are incorrect.
>>
>> thanks,
>> Peter
>>
>> >
>> > Best Regards.
>> >
>> > Aijun Wang
>> > Network R&D and Operation Support Department
>> > China Telecom Corporation Limited Beijing Research Institute,Beijing,
>> China.
>> >
>> > -邮件原件-
>> > 发件人: Peter Psenak [mailto:ppsenak=40cisco@dmarc.ietf.org]
>> > 发送时间: 2018年7月23日 18:20
>> > 收件人: Aijun Wang; 'Peter Psenak'; cho...@chopps..org
>> > 抄送: lsr@ietf.org; 'Ketan Talaulikar (ketant)'; 'Acee Lindem (acee)';
>> > 'Dongjie (Jimmy)'
>> > 主题: Re: [Lsr] 答复: Regarding OSPF extension for inter-area topology
>> > retrieval
>> >
>> > Hi Aijun,
>> >
>> > On 23/07/18 11:16 , Aijun Wang wrote:
>> >> Hi, Peter:
>> >>
>> >> Actually, I consider mainly the point-to-point connection and the
>> >> numbered interface, which are normal in our network.
>> >> For the two situations that you mentioned, I will investigation the
>> >> possible solutions and feedback you later.
>> >>
>> >> For the point-to-point and numbered interface, do you have other
>> >> questions then?
>> >
>> > the fact that two routers announce the same subnet, does not mean they
>> are
>> > connected together by p2p link. Anycast prefix is an example.
>> >
>> > The idea you are proposing simply does not work.
>> >
>> > thanks,
>> > Peter
>> >
>> >
>> >>
>> >> Best Regards.
>> >>
>> >> Aijun Wang
>> >> Network R&D and Operation Support Department China Telecom Corporation
>> >> Limited Beijing Research Institute,Beijing, China.
>> >>
>> >> -邮件原件-
>> >> 发件人: Peter Psenak [mailto:ppsenak=40cisco@dmarc.ietf.org]
>> >> 发送时间: 2018年7月23日 16:15
>> >> 收件人: Aijun Wang; cho...@chopps.org
>> >> 抄送: lsr@ietf.org; 'Ketan Talaulikar (ketant)'; 'Acee Lindem (acee)';
>> >> 'Dongjie (Jimmy)'
>> >> 主题: Re: [Lsr] Regarding OSPF extension for inter-area topology
>> >> retrieval
>> >>
>> >> Hi Aijun,
>> >>
>> >> you are trying to reconstruct the topology of the remote area based on
>> >> the fact that two routers are connected to the same subnet. It does
>> >> not work
>> >> because:
>> >>
>> >> 1. connections between routers can be unnumbered 2. routers can be
>> >> connected via LAN, in which case only DR announces the prefix.
>> >>
>> >> In summary, what you propose does not work.
>> >>
>> >> thanks,
>> >> Peter
>> >>
>> >>
>> >>
>> >> On 23/07/18 09:49 , Aijun Wang wrote:
>> >>> (Sorry for my previous mail sent wrongly to the IDR mail list, please
>> >>> reply on this thread within the LSR wg)
>> >>>
>> >>> Hi, Peter:
>> >>>
>> >>> I am Aijun Wang from China Telecom, the author of draft about “OSPF
>> >>> extension for inter-area topology retrieval”
>> >>> > >>> l ogy-ext/>, which is presented by Mr.Jie Dong during the IETF102
>> >>> meeting.
>> >>>
>> >>> Thanks for your comments on the presentation material
>> >>>
>> >> > >> f-inte
>> >> r-area-topology-retrieval-00>.
>> >>>
>> >>> Below are my explanation that regarding to the question about “how it
>> >>> retrievals t

Re: [Lsr] I-D Action: draft-ietf-ospf-lls-interface-id-05.txt

[Yingzhen Qu]

Hi authors,

I just run idnits against version 05, and there is still a warning:

  Miscellaneous warnings:
  

  == The document seems to lack the recommended RFC 2119 boilerplate, even if
 it appears to use RFC 2119 keywords -- however, there's a paragraph with
 a matching beginning. Boilerplate error?

 RFC 8174, paragraph 11:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as
described in BCP 14 [RFC2119] [RFC8174] when, and only when, they
appear in all capitals, as shown here. 

 ... text found in draft:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as
described in BCP14 [RFC2119] [RFC8174] when, and only when, they
.^
appear in all capitals, as shown here.


This is really minor. I suppose you can fix it later with other comments if 
there is any.

Thanks,
Yingzhen


On 7/18/18, 4:33 AM, "Lsr on behalf of internet-dra...@ietf.org" 
 wrote:


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

Title   : OSPF LLS Extensions for Local Interface ID 
Advertisement
Authors : Peter Psenak
  Ketan Jivan Talaulikar
  Wim Henderickx
  Padma Pillay-Esnault
Filename: draft-ietf-ospf-lls-interface-id-05.txt
Pages   : 7
Date: 2018-07-18

Abstract:
   Every OSPF interface is assigned an identifier, Interface ID, which
   uniquely identifies the interface on the router.  In some cases it is
   useful to know the Interface ID assigned by the adjacent router on
   its side of the adjacency (Remote Interface ID).

   This draft describes the extensions to OSPF link-local signalling to
   advertise the Local Interface Identifier.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ospf-lls-interface-id/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ospf-lls-interface-id-05
https://datatracker.ietf.org/doc/html/draft-ietf-ospf-lls-interface-id-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-lls-interface-id-05


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

[Lsr] 答复: 答复: 答复: 答复: Regarding OSPF extension for inter-area topology retrieval

[Aijun Wang]

Hi, Rob:

 

If we use BGP-LS to get the underlay topology, we will not consider deployment 
other methods such as IGP adjacency or LSDB telemetry, although all of them are 
applicable.

If we deploy BGP-LS adjacency with routers in multi-area to get the full 
multi-area topology, it will be no different with the traditional IGP 
adjacency, increase the complexity that BGP-LS solution itself can reduce.

 

On the other hand, if we do not solve such scenario, isn’t BGP-LS one complete 
solution for underlay IGP topology gathering?

 

Best Regards.

 

Aijun Wang

Network R&D and Operation Support Department

China Telecom Corporation Limited Beijing Research Institute,Beijing, China.

发件人: Rob Shakir [mailto:r...@rob.sh] 
发送时间: 2018年7月25日 0:22
收件人: Aijun Wang
抄送: Dongjie (Jimmy); cho...@chopps.org; Peter Psenak; Ketan Talaulikar 
(ketant); lsr@ietf.org; Acee Lindem (acee)
主题: Re: [Lsr] 答复: 答复: 答复: Regarding OSPF extension for inter-area topology 
retrieval

 

 

 

On 23 July 2018 at 23:37, Aijun Wang  wrote:

 

To Rob: 

 

BGP-LS is one prominent method to get the underlay network topology and has 
more flexibility to control the topology export as described in RFC 7752 
 . 

 

Solution 1) that you proposed is possible, but we will not run two different 
methods to get the topology.

 

What is the other method that you're running alongside an IGP adjacency? This 
is a single method that just uses the IGP protocol that you have today.

 

Solution 2) is also one possible deployment, but it eliminates the advantage of 
the BGP-LS, in which it needs several interaction points with the underlay 
network. and such deployment is not belong to redundancy category as 
information got from different areaes are different.

 

Yes, the information is different but this is why you have areas within the 
IGP. Are you implying that your controller cannot merge topologies from 
different areas? I'd suggest that this is something that is relatively trivial 
to add into that code, rather than changing the code running on your routers.

 

Solution 3)--Streaming telemetry technology should be used mainly for the 
monitor of network devices, it requires the PCE controller to contact with 
every router in the network, is also not the optimal solution when compared 
with BGP-LS.

 

This is not true. LSDB export via streaming telemetry (for the entire LSDB) is 
possible in today's running code with IS-IS, and models are written for OSPF's 
LSDB. The controller just needs to interact with one device per area per the 
existing discussion. 

 

Assertion that this is not the optimal solution seems more like opinion to me. 
Some justification would be useful for us to understand why the existing 
solutions that are shipping aren't suitable. Why should we further complicate 
protocols that ship for everyone if there is no technical reason to do so?

 

 We can update the current draft to include all possible scenarios that we are 
not aiming at beginning for integrity consideration. The proposed extension 
does not add to complexity of IGP. What we discussed here is the complexity of 
IGP protocol itself.

 

 You're asking for information that is explicitly partitioned (based on the 
fact that your network is partitioned into areas) to be exported into an area 
simply to reduce the number of adjacencies between a controller and the network 
to N (where N is the redundancy of the controller) rather than N*areas -- why 
is this the right trade-off?

 

r.

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

[Lsr] 答复: 答复: 答复: 答复: Regarding OSPF extension for inter-area topology retrieval

[Aijun Wang]

Hi, Peter:

Actually, only the unnumbered scenario that you insisted has no straightforward 
solution for the topology reconstruction. As I had explained previously, 
unnumbered interface deployment is very seldom within our network, because it 
is unavailable for remote testing and management.
If we still need to cover it, one viable way is to let "summary LSA" also 
announced it, with "Link State ID" is identical to the neighboring router, and 
the proposed "source router ID" is the original router itself. PCE/SDN 
controller can then recognize and reconstruct the topology correctly under such 
scenario.

>From the view of other point, let the "summary LSA" carry the "source router 
>ID" can aid us reconstruct the underlay multi-area topology in most of common 
>scenario, will do no harm to the traditional IGP flooding and SPF calculation. 
>I am also investigating other use case of this extension as suggested by Acee 
>and Ketan.

Very thanks for your comments to this draft again, and wish you can work 
together with us for the suitable solution.


Best Regards.

Aijun Wang
Network R&D and Operation Support Department
China Telecom Corporation Limited Beijing Research Institute,Beijing, China.

-邮件原件-
发件人: Peter Psenak [mailto:ppsenak=40cisco@dmarc.ietf.org] 
发送时间: 2018年7月24日 16:22
收件人: Aijun Wang; 'Rob Shakir'
抄送: 'Dongjie (Jimmy)'; 'Ketan Talaulikar (ketant)'; cho...@chopps.org; 'Acee 
Lindem (acee)'; lsr@ietf.org
主题: Re: [Lsr] 答复: 答复: 答复: Regarding OSPF extension for inter-area topology 
retrieval

Hi Aijun,

On 24/07/18 05:37 , Aijun Wang wrote:
> _Hi, Peter:_
>
> For point-to-point interface, as described in  OSPFv2(RFC2328 12.4.1.1.  
> Describing point-to-point interfaces)  
> , the router LSA will include 
> two links description for each interface, within which the “type 3 link”(stub 
> network) will describe the subnet mask of the point-to-point interface.
>
> For broadcast/NBMA interface, the DR will be elected and it will 
> generate the network LSA which will include also the subnet mask of 
> the connected interface.
>
> For unnumbered and virtual link, if you consider we should include 
> them also for all possible scenarios even if we seldom use them in 
> large network, we can consider expand the summary LSA to cover it, as 
> done by this draft.

there is no way to address unnumbered p2p case your way, because there is no 
Summary LSA generated to other area in such case.

Anyway, reconstructing a topology of a remote area based on the prefix 
announcements that come from it is a broken concept. I have given you several 
examples where your proposal does not work.

thanks,
Peter

>
> For Anycast prefixes situation that you described(although we seldom 
> plan our network in such way), the PCE controller will not deduce the 
> wrong information from the reported information--Different router 
> advertise the same prefix, why can’t they be connected in logically?
>
> On summary, the ABR can know and report the originator of the 
> connected interface’s prefixes, and also the connected information for 
> the unnumbered/virtual link from the traditional router LSA/network 
> LSA message, thus can transfer them to the router that run BGP-LS, 
> then to the PCE controller to retrieval the topology.
>
> _To Rob: _
>
> BGP-LS is one prominent method to get the underlay network topology 
> and has more flexibility to control the topology export as described 
> in RFC
> 7752 .
>
> Solution 1) that you proposed is possible, but we will not run two 
> different methods to get the topology.
>
> Solution 2) is also one possible deployment, but it eliminates the 
> advantage of the BGP-LS, in which it needs several interaction points 
> with the underlay network. and such deployment is not belong to 
> redundancy category as information got from different areaes are different.
>
> Solution 3)--Streaming telemetry technology should be used mainly for 
> the monitor of network devices, it requires the PCE controller to 
> contact with every router in the network, is also not the optimal 
> solution when compared with BGP-LS.
>
> We can update the current draft to include all possible scenarios that 
> we are not aiming at beginning for integrity consideration. The 
> proposed extension does not add to complexity of IGP. What we 
> discussed here is the complexity of IGP protocol itself.
>
> Best Regards.
>
> Aijun Wang
>
> Network R&D and Operation Support Department
>
> China Telecom Corporation Limited Beijing Research Institute,Beijing, China.
>
> *发件人:*Rob Shakir [mailto:r...@rob.sh]
> *发送时间:*2018年7月24日7:04
> *收件人:*Peter Psenak
> *抄送:*Dongjie (Jimmy); cho...@chopps.org; Ketan Talaulikar (ketant); 
> Aijun Wang; lsr@ietf.org; Acee Lindem (acee)
> *主题:*Re: [Lsr] 答复: 答复: Regarding OSPF extension for inter-area 
> topology retrieval
>
> +1 to Peter. We should not define fragile solutions within 

[Lsr] I-D Action: draft-ietf-isis-mpls-elc-04.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 Entropy Label Capability and Entropy 
Readable Label Depth Using IS-IS
Authors : Xiaohu Xu
  Sriganesh Kini
  Siva Sivabalan
  Clarence Filsfils
  Stephane Litkowski
Filename: draft-ietf-isis-mpls-elc-04.txt
Pages   : 6
Date: 2018-07-24

Abstract:
   Multiprotocol Label Switching (MPLS) has defined a mechanism to load
   balance traffic flows using Entropy Labels (EL).  An ingress Label
   Switching Router (LSR) cannot insert ELs for packets going into a
   given tunnel unless an egress LSR has indicated via signaling that it
   has the capability of processing ELs, referred to as Entropy Label
   Capability (ELC), on that tunnel.  In addition, it would be useful
   for ingress LSRs to know each LSR's capability of reading the maximum
   label stack depth and performing EL-based load-balancing, referred to
   as Entropy Readable Label Depth (ERLD), in the cases where stacked
   LSPs are used for whatever reasons.  This document defines mechanisms
   to signal these two capabilities using IS-IS.  These mechanisms are
   useful when the label advertisement is also done via IS-IS.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-isis-mpls-elc/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-isis-mpls-elc-04
https://datatracker.ietf.org/doc/html/draft-ietf-isis-mpls-elc-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-isis-mpls-elc-04


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

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

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

[Lsr] 答复: 答复: 答复: 答复: Regarding OSPF extension for inter-area topology retrieval

[Aijun Wang]

Hi, Ketan and Acee:

I am working on the other use cases of "Source Router ID" extension, which may 
corresponding to that in RFC7794. Once finished, I will update the draft.
RFC5392 and RFC5316 are for inter-AS TE extension, not inter-area scenario and 
solution that proposed in this draft.

-邮件原件-
发件人: Ketan Talaulikar (ketant) [mailto:ket...@cisco.com] 
发送时间: 2018年7月24日 23:56
收件人: Acee Lindem (acee); Peter Psenak (ppsenak); Aijun Wang; 'Rob Shakir'
抄送: 'Dongjie (Jimmy)'; cho...@chopps.org; lsr@ietf.org
主题: RE: 答复: [Lsr] 答复: 答复: Regarding OSPF extension for inter-area topology 
retrieval

Ack and IMHO the reference to this inter-AS use-case should be removed as it is 
very specific and works in very limited cases as opposed to rfc5392 which 
presented a proper OSPF solution for this specific problem (rfc5316 does same 
for IS-IS).

Thanks,
Ketan

-Original Message-
From: Acee Lindem (acee) 
Sent: 24 July 2018 10:37
To: Ketan Talaulikar (ketant) ; Peter Psenak (ppsenak) 
; Aijun Wang ; 'Rob Shakir' 

Cc: 'Dongjie (Jimmy)' ; cho...@chopps.org; lsr@ietf.org
Subject: Re: 答复: [Lsr] 答复: 答复: Regarding OSPF extension for inter-area topology 
retrieval

Hi Ketan, 

On 7/24/18, 7:44 AM, "Ketan Talaulikar (ketant)"  wrote:

Hi Aijun,

Your draft introduces the Source Router ID which is, by itself, an useful 
protocol extension.

I agree. What is the use case for advertisement in IS-IS? Perhaps this could be 
used as the primary motivation. 


   However, the use-case on inter-as topology retrieval has issues which has 
been shared by many of us at the mike, offline and on the list.

And this could be moved to an appendix or even completely. 

Thanks,
Acee 

Could you consider de-coupling the two?

Also, if the proposal for learning inter-AS as described by you works for 
your own specific network design (and you don't think any of the points made 
affect that decision), then please go ahead. However, I do not see the point of 
trying to get that as an IETF document?

Thanks,
Ketan

-Original Message-
From: Peter Psenak (ppsenak) 
Sent: 24 July 2018 04:22
To: Aijun Wang ; 'Rob Shakir' 
Cc: 'Dongjie (Jimmy)' ; cho...@chopps.org; Ketan 
Talaulikar (ketant) ; lsr@ietf.org; Acee Lindem (acee) 

Subject: Re: 答复: [Lsr] 答复: 答复: Regarding OSPF extension for inter-area 
topology retrieval

Hi Aijun,

On 24/07/18 05:37 , Aijun Wang wrote:
> _Hi, Peter:_
>
> For point-to-point interface, as described in  OSPFv2(RFC2328 12.4.1.1.  
Describing point-to-point interfaces)  
, the router LSA will include two 
links description for each interface, within which the “type 3 link”(stub 
network) will describe the subnet mask of the point-to-point interface.
>
> For broadcast/NBMA interface, the DR will be elected and it will 
> generate the network LSA which will include also the subnet mask of 
> the connected interface.
>
> For unnumbered and virtual link, if you consider we should include 
> them also for all possible scenarios even if we seldom use them in 
> large network, we can consider expand the summary LSA to cover it, as 
> done by this draft.

there is no way to address unnumbered p2p case your way, because there is 
no Summary LSA generated to other area in such case.

Anyway, reconstructing a topology of a remote area based on the prefix 
announcements that come from it is a broken concept. I have given you several 
examples where your proposal does not work.

thanks,
Peter

>
> For Anycast prefixes situation that you described(although we seldom 
> plan our network in such way), the PCE controller will not deduce the 
> wrong information from the reported information--Different router 
> advertise the same prefix, why can’t they be connected in logically?
>
> On summary, the ABR can know and report the originator of the 
> connected interface’s prefixes, and also the connected information for 
> the unnumbered/virtual link from the traditional router LSA/network 
> LSA message, thus can transfer them to the router that run BGP-LS, 
> then to the PCE controller to retrieval the topology.
>
> _To Rob: _
>
> BGP-LS is one prominent method to get the underlay network topology 
> and has more flexibility to control the topology export as described 
> in RFC
> 7752 .
>
> Solution 1) that you proposed is possible, but we will not run two 
> different methods to get the topology.
>
> Solution 2) is also one possible deployment, but it eliminates the 
> advantage of the BGP-LS, in which it needs several interaction points 
> with the underlay network. and such deployment is not belong to 
> redundancy category as information got from different are

[Lsr] I-D Action: draft-ietf-ospf-segment-routing-msd-15.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-15.txt
Pages   : 10
Date: 2018-07-24

Abstract:
   This document defines a way for an 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-15
https://datatracker.ietf.org/doc/html/draft-ietf-ospf-segment-routing-msd-15

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-segment-routing-msd-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

Re: [Lsr] I-D Action: draft-ietf-isis-segment-routing-msd-13.txt

[Jeff Tantsura]

Folks,

The only update is the correct name for the registry - from "MSD Types" to "IGP 
MSD Types"

Cheers,
Jeff

On 7/24/18, 15:51, "lsr-boun...@ietf.org on behalf of 
internet-dra...@ietf.org"  wrote:


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

Title   : Signaling MSD (Maximum SID Depth) using IS-IS
Authors : Jeff Tantsura
  Uma Chunduri
  Sam Aldrin
  Les Ginsberg
Filename: draft-ietf-isis-segment-routing-msd-13.txt
Pages   : 9
Date: 2018-07-24

Abstract:
   This document defines a way for an IS-IS 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 only defines one type of
   MSD maximum label imposition, but defines an encoding that can
   support other MSD types.


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

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

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


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

[Lsr] I-D Action: draft-ietf-isis-segment-routing-msd-13.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 IS-IS
Authors : Jeff Tantsura
  Uma Chunduri
  Sam Aldrin
  Les Ginsberg
Filename: draft-ietf-isis-segment-routing-msd-13.txt
Pages   : 9
Date: 2018-07-24

Abstract:
   This document defines a way for an IS-IS 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 only defines one type of
   MSD maximum label imposition, but defines an encoding that can
   support other MSD types.


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

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

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


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] [IANA #1117133] Early Allocation Request for "Signaling MSD (Maximum SID Depth) using IS-IS"

[Amanda Baber via RT]

Hi Acee,

According to our logs, although we made individual registrations through the 
early allocation process, it looks like all of the RFC 7684 registries at 
https://www.iana.org/assignments/ospfv2-parameters were created in September 
2015, after the document was approved by the IESG. 

Amanda

On Tue Jul 24 20:54:52 2018, a...@cisco.com wrote:
> Hi Amanda,
> 
> It seems to me that we created the RFC 7684 TLV registry via early
> allocation so that we could allocate code points from other drafts.
> 
> If this is, in fact, the case, we'll need to manage the IGP MSD Type
> in the WG.
> 
> Thanks,
>  Acee
> 
> On 7/24/18, 4:25 PM, "Amanda Baber via RT" 
> wrote:
> 
> Hi Acee,
> 
> We actually aren't able to create registries through the RFC 7120
> early allocation process. We'll have to hold off until the IESG
> notifies us that they've approved the document for publication.
> 
> Best regards,
> Amanda
> 
> On Tue Jul 24 14:50:47 2018, a...@cisco.com wrote:
> > Hi Amanda, et al,
> >
> > Can we get the registry for “IGP MSD Types” created as well? We now
> > have another draft allocating a code point. The IS-IS TLVs have
> > already been allocated through the early allocation process.
> >
> > Hi Authors,
> >
> > Please change “MSD Types” to “IGP MSD Types” in the IANA section
> > consistent with other registries in the “Interior Gateway Protocol
> > (IGP) Parameters” registry grouping.
> >
> > https://www.iana.org/assignments/igp-parameters/igp-
> > parameters.xhtml#igp-algorithm-types
> >
> > Thanks,
> > Acee
> 
> 
> 
> 
> 



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

Re: [Lsr] [IANA #1117133] Early Allocation Request for "Signaling MSD (Maximum SID Depth) using IS-IS"

[Acee Lindem (acee)]

Hi Amanda, 

It seems to me that we created the RFC 7684 TLV registry via early allocation 
so that we could allocate code points from other drafts. 

If this is, in fact, the case, we'll need to manage the IGP MSD Type in the WG.

Thanks,
Acee 

On 7/24/18, 4:25 PM, "Amanda Baber via RT"  wrote:

Hi Acee,

We actually aren't able to create registries through the RFC 7120 early 
allocation process. We'll have to hold off until the IESG notifies us that 
they've approved the document for publication.

Best regards,
Amanda

On Tue Jul 24 14:50:47 2018, a...@cisco.com wrote:
> Hi Amanda, et al,
> 
> Can we get the registry for “IGP MSD Types” created as well? We now
> have another draft allocating a code point. The IS-IS TLVs have
> already been allocated through the early allocation process.
> 
> Hi Authors,
> 
> Please change “MSD Types” to “IGP MSD Types” in the IANA section
> consistent with other registries in the “Interior Gateway Protocol
> (IGP) Parameters” registry grouping.
> 
> https://www.iana.org/assignments/igp-parameters/igp-
> parameters.xhtml#igp-algorithm-types
> 
> Thanks,
> Acee





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

Re: [Lsr] [IANA #1117133] Early Allocation Request for "Signaling MSD (Maximum SID Depth) using IS-IS"

[Acee Lindem via RT]

Hi Amanda, 

It seems to me that we created the RFC 7684 TLV registry via early allocation 
so that we could allocate code points from other drafts. 

If this is, in fact, the case, we'll need to manage the IGP MSD Type in the WG.

Thanks,
Acee 

On 7/24/18, 4:25 PM, "Amanda Baber via RT"  wrote:

Hi Acee,

We actually aren't able to create registries through the RFC 7120 early 
allocation process. We'll have to hold off until the IESG notifies us that 
they've approved the document for publication.

Best regards,
Amanda

On Tue Jul 24 14:50:47 2018, a...@cisco.com wrote:
> Hi Amanda, et al,
> 
> Can we get the registry for “IGP MSD Types” created as well? We now
> have another draft allocating a code point. The IS-IS TLVs have
> already been allocated through the early allocation process.
> 
> Hi Authors,
> 
> Please change “MSD Types” to “IGP MSD Types” in the IANA section
> consistent with other registries in the “Interior Gateway Protocol
> (IGP) Parameters” registry grouping.
> 
> https://www.iana.org/assignments/igp-parameters/igp-
> parameters.xhtml#igp-algorithm-types
> 
> Thanks,
> Acee






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

[Lsr] [IANA #1117133] Early Allocation Request for "Signaling MSD (Maximum SID Depth) using IS-IS"

[Amanda Baber via RT]

Hi Acee,

We actually aren't able to create registries through the RFC 7120 early 
allocation process. We'll have to hold off until the IESG notifies us that 
they've approved the document for publication.

Best regards,
Amanda

On Tue Jul 24 14:50:47 2018, a...@cisco.com wrote:
> Hi Amanda, et al,
> 
> Can we get the registry for “IGP MSD Types” created as well? We now
> have another draft allocating a code point. The IS-IS TLVs have
> already been allocated through the early allocation process.
> 
> Hi Authors,
> 
> Please change “MSD Types” to “IGP MSD Types” in the IANA section
> consistent with other registries in the “Interior Gateway Protocol
> (IGP) Parameters” registry grouping.
> 
> https://www.iana.org/assignments/igp-parameters/igp-
> parameters.xhtml#igp-algorithm-types
> 
> Thanks,
> Acee



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

[Lsr] IETF 102 LSR Meeting Minutes

[Acee Lindem (acee)]

All,

I have uploaded the meeting minutes - 
https://datatracker.ietf.org/doc/minutes-102-lsr/

Thanks so much to Yingzhen for taking them. As you can see, we had quite a 
lively discussion with respect to the flooding optimizations. I intend to start 
a separate thread as to how we move forward.

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

Re: [Lsr] 答复: 答复: 答复: Regarding OSPF extension for inter-area topology retrieval

[Rob Shakir]

On 23 July 2018 at 23:37, Aijun Wang  wrote:

>
>
> *To Rob: *
>
>
>
> BGP-LS is one prominent method to get the underlay network topology and
> has more flexibility to control the topology export as described in RFC
> 7752 .
>
>
>
> Solution 1) that you proposed is possible, but we will not run two
> different methods to get the topology.
>

What is the other method that you're running alongside an IGP adjacency?
This is a single method that just uses the IGP protocol that you have today.


> Solution 2) is also one possible deployment, but it eliminates the
> advantage of the BGP-LS, in which it needs several interaction points with
> the underlay network. and such deployment is not belong to redundancy
> category as information got from different areaes are different.
>

Yes, the information is different but this is why you have areas within the
IGP. Are you implying that your controller cannot merge topologies from
different areas? I'd suggest that this is something that is relatively
trivial to add into that code, rather than changing the code running on
your routers.


> Solution 3)--Streaming telemetry technology should be used mainly for the
> monitor of network devices, it requires the PCE controller to contact with
> every router in the network, is also not the optimal solution when compared
> with BGP-LS.
>

This is not true. LSDB export via streaming telemetry (for the entire LSDB)
is possible in today's running code with IS-IS, and models are written for
OSPF's LSDB. The controller just needs to interact with one device per area
per the existing discussion.

Assertion that this is not the optimal solution seems more like opinion to
me. Some justification would be useful for us to understand why the
existing solutions that are shipping aren't suitable. Why should we further
complicate protocols that ship for everyone if there is no technical reason
to do so?


>  We can update the current draft to include all possible scenarios that
> we are not aiming at beginning for integrity consideration. The proposed
> extension does not add to complexity of IGP. What we discussed here is the
> complexity of IGP protocol itself.
>

 You're asking for information that is explicitly partitioned (based on the
fact that your network is partitioned into areas) to be exported into an
area simply to reduce the number of adjacencies between a controller and
the network to N (where N is the redundancy of the controller) rather than
N*areas -- why is this the right trade-off?

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

Re: [Lsr] 答复: 答复: 答复: Regarding OSPF extension for inter-area topology retrieval

[Ketan Talaulikar (ketant)]

Ack and IMHO the reference to this inter-AS use-case should be removed as it is 
very specific and works in very limited cases as opposed to rfc5392 which 
presented a proper OSPF solution for this specific problem (rfc5316 does same 
for IS-IS).

Thanks,
Ketan

-Original Message-
From: Acee Lindem (acee) 
Sent: 24 July 2018 10:37
To: Ketan Talaulikar (ketant) ; Peter Psenak (ppsenak) 
; Aijun Wang ; 'Rob Shakir' 

Cc: 'Dongjie (Jimmy)' ; cho...@chopps.org; lsr@ietf.org
Subject: Re: 答复: [Lsr] 答复: 答复: Regarding OSPF extension for inter-area topology 
retrieval

Hi Ketan, 

On 7/24/18, 7:44 AM, "Ketan Talaulikar (ketant)"  wrote:

Hi Aijun,

Your draft introduces the Source Router ID which is, by itself, an useful 
protocol extension.

I agree. What is the use case for advertisement in IS-IS? Perhaps this could be 
used as the primary motivation. 


   However, the use-case on inter-as topology retrieval has issues which has 
been shared by many of us at the mike, offline and on the list.

And this could be moved to an appendix or even completely. 

Thanks,
Acee 

Could you consider de-coupling the two?

Also, if the proposal for learning inter-AS as described by you works for 
your own specific network design (and you don't think any of the points made 
affect that decision), then please go ahead. However, I do not see the point of 
trying to get that as an IETF document?

Thanks,
Ketan

-Original Message-
From: Peter Psenak (ppsenak) 
Sent: 24 July 2018 04:22
To: Aijun Wang ; 'Rob Shakir' 
Cc: 'Dongjie (Jimmy)' ; cho...@chopps.org; Ketan 
Talaulikar (ketant) ; lsr@ietf.org; Acee Lindem (acee) 

Subject: Re: 答复: [Lsr] 答复: 答复: Regarding OSPF extension for inter-area 
topology retrieval

Hi Aijun,

On 24/07/18 05:37 , Aijun Wang wrote:
> _Hi, Peter:_
>
> For point-to-point interface, as described in  OSPFv2(RFC2328 12.4.1.1.  
Describing point-to-point interfaces)  
, the router LSA will include two 
links description for each interface, within which the “type 3 link”(stub 
network) will describe the subnet mask of the point-to-point interface.
>
> For broadcast/NBMA interface, the DR will be elected and it will 
> generate the network LSA which will include also the subnet mask of 
> the connected interface.
>
> For unnumbered and virtual link, if you consider we should include 
> them also for all possible scenarios even if we seldom use them in 
> large network, we can consider expand the summary LSA to cover it, as 
> done by this draft.

there is no way to address unnumbered p2p case your way, because there is 
no Summary LSA generated to other area in such case.

Anyway, reconstructing a topology of a remote area based on the prefix 
announcements that come from it is a broken concept. I have given you several 
examples where your proposal does not work.

thanks,
Peter

>
> For Anycast prefixes situation that you described(although we seldom 
> plan our network in such way), the PCE controller will not deduce the 
> wrong information from the reported information--Different router 
> advertise the same prefix, why can’t they be connected in logically?
>
> On summary, the ABR can know and report the originator of the 
> connected interface’s prefixes, and also the connected information for 
> the unnumbered/virtual link from the traditional router LSA/network 
> LSA message, thus can transfer them to the router that run BGP-LS, 
> then to the PCE controller to retrieval the topology.
>
> _To Rob: _
>
> BGP-LS is one prominent method to get the underlay network topology 
> and has more flexibility to control the topology export as described 
> in RFC
> 7752 .
>
> Solution 1) that you proposed is possible, but we will not run two 
> different methods to get the topology.
>
> Solution 2) is also one possible deployment, but it eliminates the 
> advantage of the BGP-LS, in which it needs several interaction points 
> with the underlay network. and such deployment is not belong to 
> redundancy category as information got from different areaes are 
different.
>
> Solution 3)--Streaming telemetry technology should be used mainly for 
> the monitor of network devices, it requires the PCE controller to 
> contact with every router in the network, is also not the optimal 
> solution when compared with BGP-LS.
>
> We can update the current draft to include all possible scenarios that 
> we are not aiming at beginning for integrity consideration. The 
> proposed extension does not add to complexity of IGP. What we 
> discussed here is the complexity of IGP protocol itself.
>
> Best Regards.
  

Re: [Lsr] WG Last Call for draft-ietf-lsr-isis-rfc7810bis-00

[Ketan Talaulikar (ketant)]

Hi Les,

It does and thanks for the update.

Thanks,
Ketan

-Original Message-
From: Les Ginsberg (ginsberg) 
Sent: 17 July 2018 17:32
To: Les Ginsberg (ginsberg) ; Ketan 
Talaulikar (ketant) ; Acee Lindem (acee) ; 
Christian Hopps ; lsr@ietf.org
Cc: lsr-cha...@ietf.org; lsr-...@ietf.org
Subject: RE: [Lsr] WG Last Call for draft-ietf-lsr-isis-rfc7810bis-00

V1 has been posted with the additional text.

Hope this clears any issues with the shepherd's report.

Les


> -Original Message-
> From: Lsr  On Behalf Of Les Ginsberg (ginsberg)
> Sent: Tuesday, July 17, 2018 2:07 PM
> To: Ketan Talaulikar (ketant) ; Acee Lindem (acee) 
> ; Christian Hopps ; lsr@ietf.org
> Cc: lsr-cha...@ietf.org; lsr-...@ietf.org
> Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-isis-rfc7810bis-00
> 
> Ketan -
> 
> I don't want to be overly prescriptive here.
> The need for supporting backwards compatibility is limited by the 
> amount of existing deployment by implementations that chose the 
> "length 5" solution - and hopefully any such issues will be 
> short-lived as the problematic implementations get upgraded.
> 
> But If there is a need for backwards compatibility it is possible that 
> both transmit/receive are required. This is a judgment call for 
> implementers and the new text in the draft is not meant to tell 
> implementers what they SHOULD do - only to remind them that this may 
> be an issue which they will have to consider. If they think receive 
> only is sufficient that's fine, but it is beyond what I think the draft needs 
> to say.
> 
>Les
> 
> 
> > -Original Message-
> > From: Ketan Talaulikar (ketant)
> > Sent: Tuesday, July 17, 2018 11:29 AM
> > To: Les Ginsberg (ginsberg) ; Acee Lindem (acee) 
> > ; Christian Hopps ; lsr@ietf.org
> > Cc: lsr-cha...@ietf.org; lsr-...@ietf.org
> > Subject: RE: [Lsr] WG Last Call for 
> > draft-ietf-lsr-isis-rfc7810bis-00
> >
> > Hi Les,
> >
> > This sounds good. I would suggest being liberal in receive (i.e.
> > accept and interpret the incorrect encoding) and there is no need to 
> > send that erroneous encoding.
> >
> > Thanks,
> > Ketan
> >
> > -Original Message-
> > From: Les Ginsberg (ginsberg)
> > Sent: 17 July 2018 13:30
> > To: Ketan Talaulikar (ketant) ; Acee Lindem (acee) 
> > ; Christian Hopps ; lsr@ietf.org
> > Cc: lsr-cha...@ietf.org; lsr-...@ietf.org
> > Subject: RE: [Lsr] WG Last Call for 
> > draft-ietf-lsr-isis-rfc7810bis-00
> >
> > Ketan -
> >
> > Thanx for taking on the role of shepherd.
> >
> > I am attaching some proposed diffs which I think addresses your concern.
> > Let me know if this suffices and we can publish an update.
> >
> >Les
> >
> >
> > > -Original Message-
> > > From: Ketan Talaulikar (ketant)
> > > Sent: Tuesday, July 17, 2018 6:55 AM
> > > To: Acee Lindem (acee) ; Les Ginsberg (ginsberg) 
> > > ; Christian Hopps ; 
> > > lsr@ietf.org
> > > Cc: lsr-cha...@ietf.org; lsr-...@ietf.org
> > > Subject: RE: [Lsr] WG Last Call for
> > > draft-ietf-lsr-isis-rfc7810bis-00
> > >
> > > Hi All,
> > >
> > > I was reviewing this draft as the Shepherd. It is a fairly simple 
> > > and straightforward bis update to RFC7810 to fix an encoding error.
> > >
> > > There is one point that I would like the authors and WG to consider.
> > >
> > > The draft in the appendix talks about two interpretations of the 
> > > erroneous sub- TLVs and from the conversation on the list I get 
> > > the impression that there are at least two implementations out 
> > > there which did different interpretations. Do we want to consider 
> > > putting in a suggestion (i.e. not normative perhaps) that 
> > > implementations updated to this specifications accept the sub-TLV 
> > > with the Reserved field included and size 5? So they don't 
> > > consider such an encoding as error or
> > malformed on reception?
> > >
> > > Thanks,
> > > Ketan
> > >
> > > -Original Message-
> > > From: Lsr  On Behalf Of Acee Lindem (acee)
> > > Sent: 18 June 2018 17:38
> > > To: Les Ginsberg (ginsberg) ; Christian Hopps 
> > > ; lsr@ietf.org
> > > Cc: lsr-cha...@ietf.org; lsr-...@ietf.org
> > > Subject: Re: [Lsr] WG Last Call for
> > > draft-ietf-lsr-isis-rfc7810bis-00
> > >
> > > Hi Les,
> > > Yes - the Working Group Last call has completed. We'll find a 
> > > shepherd and request publication.
> > > Thanks,
> > > Acee
> > >
> > > On 6/15/18, 10:49 AM, "Les Ginsberg (ginsberg)"
> > > 
> > wrote:
> > >
> > > WG chairs -
> > >
> > > Can we consider WG last call completed? (It has been more than 
> > > 3
> > > weeks...)
> > >
> > > Would really like to get this small but important correction 
> > > published ASAP
> > >
> > > ___
> > > 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] Early Allocation Request for "Signaling MSD (Maximum SID Depth) using IS-IS"

[Acee Lindem (acee)]

Hi Amanda, et al,

Can we get the registry for “IGP MSD Types” created as well? We now have 
another draft allocating a code point. The IS-IS TLVs have already been 
allocated through the early allocation process.

Hi Authors,

Please change “MSD Types” to “IGP MSD Types” in the IANA section consistent 
with other registries in the “Interior Gateway Protocol (IGP) Parameters” 
registry grouping.

https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml#igp-algorithm-types

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

Re: [Lsr] 答复: 答复: 答复: Regarding OSPF extension for inter-area topology retrieval

[Acee Lindem (acee)]

Hi Ketan, 

On 7/24/18, 7:44 AM, "Ketan Talaulikar (ketant)"  wrote:

Hi Aijun,

Your draft introduces the Source Router ID which is, by itself, an useful 
protocol extension.

I agree. What is the use case for advertisement in IS-IS? Perhaps this could be 
used as the primary motivation. 


   However, the use-case on inter-as topology retrieval has issues which has 
been shared by many of us at the mike, offline and on the list.

And this could be moved to an appendix or even completely. 

Thanks,
Acee 

Could you consider de-coupling the two?

Also, if the proposal for learning inter-AS as described by you works for 
your own specific network design (and you don't think any of the points made 
affect that decision), then please go ahead. However, I do not see the point of 
trying to get that as an IETF document?

Thanks,
Ketan

-Original Message-
From: Peter Psenak (ppsenak) 
Sent: 24 July 2018 04:22
To: Aijun Wang ; 'Rob Shakir' 
Cc: 'Dongjie (Jimmy)' ; cho...@chopps.org; Ketan 
Talaulikar (ketant) ; lsr@ietf.org; Acee Lindem (acee) 

Subject: Re: 答复: [Lsr] 答复: 答复: Regarding OSPF extension for inter-area 
topology retrieval

Hi Aijun,

On 24/07/18 05:37 , Aijun Wang wrote:
> _Hi, Peter:_
>
> For point-to-point interface, as described in  OSPFv2(RFC2328 12.4.1.1.  
Describing point-to-point interfaces)  
, the router LSA will include two 
links description for each interface, within which the “type 3 link”(stub 
network) will describe the subnet mask of the point-to-point interface.
>
> For broadcast/NBMA interface, the DR will be elected and it will 
> generate the network LSA which will include also the subnet mask of 
> the connected interface.
>
> For unnumbered and virtual link, if you consider we should include 
> them also for all possible scenarios even if we seldom use them in 
> large network, we can consider expand the summary LSA to cover it, as 
> done by this draft.

there is no way to address unnumbered p2p case your way, because there is 
no Summary LSA generated to other area in such case.

Anyway, reconstructing a topology of a remote area based on the prefix 
announcements that come from it is a broken concept. I have given you several 
examples where your proposal does not work.

thanks,
Peter

>
> For Anycast prefixes situation that you described(although we seldom 
> plan our network in such way), the PCE controller will not deduce the 
> wrong information from the reported information--Different router 
> advertise the same prefix, why can’t they be connected in logically?
>
> On summary, the ABR can know and report the originator of the 
> connected interface’s prefixes, and also the connected information for 
> the unnumbered/virtual link from the traditional router LSA/network 
> LSA message, thus can transfer them to the router that run BGP-LS, 
> then to the PCE controller to retrieval the topology.
>
> _To Rob: _
>
> BGP-LS is one prominent method to get the underlay network topology 
> and has more flexibility to control the topology export as described 
> in RFC
> 7752 .
>
> Solution 1) that you proposed is possible, but we will not run two 
> different methods to get the topology.
>
> Solution 2) is also one possible deployment, but it eliminates the 
> advantage of the BGP-LS, in which it needs several interaction points 
> with the underlay network. and such deployment is not belong to 
> redundancy category as information got from different areaes are 
different.
>
> Solution 3)--Streaming telemetry technology should be used mainly for 
> the monitor of network devices, it requires the PCE controller to 
> contact with every router in the network, is also not the optimal 
> solution when compared with BGP-LS.
>
> We can update the current draft to include all possible scenarios that 
> we are not aiming at beginning for integrity consideration. The 
> proposed extension does not add to complexity of IGP. What we 
> discussed here is the complexity of IGP protocol itself.
>
> Best Regards.
>
> Aijun Wang
>
> Network R&D and Operation Support Department
>
> China Telecom Corporation Limited Beijing Research Institute,Beijing, 
China.
>
> *发件人:*Rob Shakir [mailto:r...@rob.sh]
> *发送时间:*2018年7月24日7:04
> *收件人:*Peter Psenak
> *抄送:*Dongjie (Jimmy); cho...@chopps.org; Ketan Talaulikar (ketant); 
> Aijun Wang; lsr@ietf.org; Acee Lindem (acee)
> *主题:*Re: [Lsr] 答复: 答复: Regarding OSPF extension for inter-area 
> topology retrieval
>
> +1 to Peter. We should not define fragile solutions within the IETF.
  

Re: [Lsr] 答复: 答复: 答复: Regarding OSPF extension for inter-area topology retrieval

[Ketan Talaulikar (ketant)]

Hi Aijun,

Your draft introduces the Source Router ID which is, by itself, an useful 
protocol extension. However, the use-case on inter-as topology retrieval has 
issues which has been shared by many of us at the mike, offline and on the list.

Could you consider de-coupling the two?

Also, if the proposal for learning inter-AS as described by you works for your 
own specific network design (and you don't think any of the points made affect 
that decision), then please go ahead. However, I do not see the point of trying 
to get that as an IETF document?

Thanks,
Ketan

-Original Message-
From: Peter Psenak (ppsenak) 
Sent: 24 July 2018 04:22
To: Aijun Wang ; 'Rob Shakir' 
Cc: 'Dongjie (Jimmy)' ; cho...@chopps.org; Ketan 
Talaulikar (ketant) ; lsr@ietf.org; Acee Lindem (acee) 

Subject: Re: 答复: [Lsr] 答复: 答复: Regarding OSPF extension for inter-area topology 
retrieval

Hi Aijun,

On 24/07/18 05:37 , Aijun Wang wrote:
> _Hi, Peter:_
>
> For point-to-point interface, as described in  OSPFv2(RFC2328 12.4.1.1.  
> Describing point-to-point interfaces)  
> , the router LSA will include 
> two links description for each interface, within which the “type 3 link”(stub 
> network) will describe the subnet mask of the point-to-point interface.
>
> For broadcast/NBMA interface, the DR will be elected and it will 
> generate the network LSA which will include also the subnet mask of 
> the connected interface.
>
> For unnumbered and virtual link, if you consider we should include 
> them also for all possible scenarios even if we seldom use them in 
> large network, we can consider expand the summary LSA to cover it, as 
> done by this draft.

there is no way to address unnumbered p2p case your way, because there is no 
Summary LSA generated to other area in such case.

Anyway, reconstructing a topology of a remote area based on the prefix 
announcements that come from it is a broken concept. I have given you several 
examples where your proposal does not work.

thanks,
Peter

>
> For Anycast prefixes situation that you described(although we seldom 
> plan our network in such way), the PCE controller will not deduce the 
> wrong information from the reported information--Different router 
> advertise the same prefix, why can’t they be connected in logically?
>
> On summary, the ABR can know and report the originator of the 
> connected interface’s prefixes, and also the connected information for 
> the unnumbered/virtual link from the traditional router LSA/network 
> LSA message, thus can transfer them to the router that run BGP-LS, 
> then to the PCE controller to retrieval the topology.
>
> _To Rob: _
>
> BGP-LS is one prominent method to get the underlay network topology 
> and has more flexibility to control the topology export as described 
> in RFC
> 7752 .
>
> Solution 1) that you proposed is possible, but we will not run two 
> different methods to get the topology.
>
> Solution 2) is also one possible deployment, but it eliminates the 
> advantage of the BGP-LS, in which it needs several interaction points 
> with the underlay network. and such deployment is not belong to 
> redundancy category as information got from different areaes are different.
>
> Solution 3)--Streaming telemetry technology should be used mainly for 
> the monitor of network devices, it requires the PCE controller to 
> contact with every router in the network, is also not the optimal 
> solution when compared with BGP-LS.
>
> We can update the current draft to include all possible scenarios that 
> we are not aiming at beginning for integrity consideration. The 
> proposed extension does not add to complexity of IGP. What we 
> discussed here is the complexity of IGP protocol itself.
>
> Best Regards.
>
> Aijun Wang
>
> Network R&D and Operation Support Department
>
> China Telecom Corporation Limited Beijing Research Institute,Beijing, China.
>
> *发件人:*Rob Shakir [mailto:r...@rob.sh]
> *发送时间:*2018年7月24日7:04
> *收件人:*Peter Psenak
> *抄送:*Dongjie (Jimmy); cho...@chopps.org; Ketan Talaulikar (ketant); 
> Aijun Wang; lsr@ietf.org; Acee Lindem (acee)
> *主题:*Re: [Lsr] 答复: 答复: Regarding OSPF extension for inter-area 
> topology retrieval
>
> +1 to Peter. We should not define fragile solutions within the IETF.
>
> There are also a multitude of other solutions here already:
>
> 1) IGP adjacency with one router in each area (at a minimum - probably 
> two for a robust system) over a tunnel. Deployed in many networks for 
> years.
> 2) BGP-LS to one router (ditto robustness comment) in each area.
> 3) streaming telemetry of the LSDB contents via gNMI.
>
> All these solutions exist in shipping implementations - please let’s 
> not add to the system complexity of the IGP here.
>
> r.
>
> On Mon, Jul 23, 2018 at 12:30 Peter Psenak 
>  >
> wrote:
>
> Hi Aijun,
>
> On 23/07/18 13:07 , Aijun Wang wrote:
>   

Re: [Lsr] OSPF/IS-IS Entropy Label Signaling Drafts

[Van De Velde, Gunter (Nokia - BE/Antwerp)]

Thanks. We have the BGP-LS work stuck until this is resolved and OSPF/ISIS IANA 
code points are correctly updated.
Would appreciate a fast update to align the language so the 
draft-ietf-idr-bgp-ls-segment-routing-rld can be progressed in parallel.

G/

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of ???(??)
Sent: Wednesday, July 18, 2018 02:45
To: Lsr ; draft-ietf-ospf-mpls-...@ietf.org; 
draft-ietf-isis-mpls-...@ietf.org
Cc: lsr@ietf.org
Subject: Re: [Lsr] OSPF/IS-IS Entropy Label Signaling Drafts

Hi Acee,

We will update these two drafts so as to keep the terminologies be aligned with 
the https://www.ietf.org/id/draft-ietf-mpls-spring-entropy-label-12.txt

Best regards,
Xiaohu

--
From:Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>
Send Time:2018年7月18日(星期三) 05:13
To:draft-ietf-ospf-mpls-...@ietf.org 
mailto:draft-ietf-ospf-mpls-...@ietf.org>>; 
draft-ietf-isis-mpls-...@ietf.org 
mailto:draft-ietf-isis-mpls-...@ietf.org>>
Cc:lsr@ietf.org mailto:lsr@ietf.org>>
Subject:[Lsr] OSPF/IS-IS Entropy Label Signaling Drafts

Authors of LSR MPLS ELC Signaling Drafts,

Now that we have 
https://www.ietf.org/id/draft-ietf-mpls-spring-entropy-label-12.txt on the RFC 
queue waiting on a MISREF for Segment Routing MPLS, it seems we should move 
forward with these drafts.

However, it seems that we should advertise an Entropy RLD rather than a generic 
RLD to be aligned with the terminology in the MPLS draft (soon to be RFC).

Thanks,
Acee


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

Re: [Lsr] 答复: 答复: 答复: Regarding OSPF extension for inter-area topology retrieval

[Peter Psenak]

Hi Aijun,

On 24/07/18 05:37 , Aijun Wang wrote:

_Hi, Peter:_

For point-to-point interface, as described in  OSPFv2(RFC2328 12.4.1.1.  Describing 
point-to-point interfaces)  , the 
router LSA will include two links description for each interface, within which the 
“type 3 link”(stub network) will describe the subnet mask of the point-to-point 
interface.

For broadcast/NBMA interface, the DR will be elected and it will
generate the network LSA which will include also the subnet mask of the
connected interface.

For unnumbered and virtual link, if you consider we should include them
also for all possible scenarios even if we seldom use them in large
network, we can consider expand the summary LSA to cover it, as done by
this draft.


there is no way to address unnumbered p2p case your way, because there 
is no Summary LSA generated to other area in such case.


Anyway, reconstructing a topology of a remote area based on the prefix 
announcements that come from it is a broken concept. I have given you 
several examples where your proposal does not work.


thanks,
Peter



For Anycast prefixes situation that you described(although we seldom
plan our network in such way), the PCE controller will not deduce the
wrong information from the reported information--Different router
advertise the same prefix, why can’t they be connected in logically?

On summary, the ABR can know and report the originator of the connected
interface’s prefixes, and also the connected information for the
unnumbered/virtual link from the traditional router LSA/network LSA
message, thus can transfer them to the router that run BGP-LS, then to
the PCE controller to retrieval the topology.

_To Rob: _

BGP-LS is one prominent method to get the underlay network topology and
has more flexibility to control the topology export as described in RFC
7752 .

Solution 1) that you proposed is possible, but we will not run two
different methods to get the topology.

Solution 2) is also one possible deployment, but it eliminates the
advantage of the BGP-LS, in which it needs several interaction points
with the underlay network. and such deployment is not belong to
redundancy category as information got from different areaes are different.

Solution 3)--Streaming telemetry technology should be used mainly for
the monitor of network devices, it requires the PCE controller to
contact with every router in the network, is also not the optimal
solution when compared with BGP-LS.

We can update the current draft to include all possible scenarios that
we are not aiming at beginning for integrity consideration. The proposed
extension does not add to complexity of IGP. What we discussed here is
the complexity of IGP protocol itself.

Best Regards.

Aijun Wang

Network R&D and Operation Support Department

China Telecom Corporation Limited Beijing Research Institute,Beijing, China.

*发件人:*Rob Shakir [mailto:r...@rob.sh]
*发送时间:*2018年7月24日7:04
*收件人:*Peter Psenak
*抄送:*Dongjie (Jimmy); cho...@chopps.org; Ketan Talaulikar (ketant);
Aijun Wang; lsr@ietf.org; Acee Lindem (acee)
*主题:*Re: [Lsr] 答复: 答复: Regarding OSPF extension for inter-area
topology retrieval

+1 to Peter. We should not define fragile solutions within the IETF.

There are also a multitude of other solutions here already:

1) IGP adjacency with one router in each area (at a minimum - probably
two for a robust system) over a tunnel. Deployed in many networks for
years.
2) BGP-LS to one router (ditto robustness comment) in each area.
3) streaming telemetry of the LSDB contents via gNMI.

All these solutions exist in shipping implementations - please let’s not
add to the system complexity of the IGP here.

r.

On Mon, Jul 23, 2018 at 12:30 Peter Psenak
mailto:40cisco@dmarc.ietf.org>>
wrote:

Hi Aijun,

On 23/07/18 13:07 , Aijun Wang wrote:
> Hi, Peter:
>
> For routers that connected by LAN, the router will establish adjacent
> neighbor with DR, but not only DR advertises the connected prefixes.

only the Network LSA includes the network mask, other routers would
include the interface address only.


> DR and
> DRother will all advertise type 1 and type 2 LSA with each other, then the
> process and proposal described in this draft will still work.
> We seldom use the ip unnumbered features in our network, can we ignore it
> then? Or other persons has some idea on such situation?

the fact that you do not use unnumbered is not really relevant. IETF
defines solutions that MUST work for all possible scenarios, not only
for a specific one.

> Anycast prefixes are often /32 long, this can be easily filtered by SDN
> controller because the link prefixes between two routers will be no larger
> than /32 for IPv4 network.

protocol allows to advertise the same prefix with an arbitrary mask from
multiple routers without these router