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

[Ketan Talaulikar (ketant)]

Hi Chris,

I agree with Peter and I would suggest to drop LSR since this is not a protocol 
specific thing.

I believe the text in draft-ietf-spring-srv6-network-programming clears says 
what locator block and locator node are. What more details do you think are 
required?

Thanks,
Ketan

From: Lsr  On Behalf Of Chris Bowers
Sent: 27 February 2020 22:46
To: lsr@ietf.org; SPRING WG List 
Cc: Peter Psenak (ppsenak) 
Subject: [Lsr] clarification of locator block and locator node in 
draft-ietf-spring-srv6-network-programming and 
draft-ietf-lsr-isis-srv6-extensions

SPRING and LSR WGs,

I think that we need a much more detailed description of the locator block and 
locator node in either draft-ietf-spring-srv6-network-programming or 
draft-ietf-lsr-isis-srv6-extensions.  See original email below.

Thanks,
Chris

On Thu, Feb 27, 2020 at 11:08 AM Peter Psenak 
mailto:ppse...@cisco.com>> wrote:
Hi Chris,

On 27/02/2020 17:54, Chris Bowers wrote:
> LSR WG,
>
> Section 9 of draft-ietf-lsr-isis-srv6-extensions-05 defines the  SRv6
> SID Structure Sub-Sub-TLV. In particular, it defines encoding for the
> locator block length and the locator node length.  The text refers to
> [I-D.ietf-spring-srv6-network-programming] for the definition of these
> concepts.
>
> As far as I can tell, the only reference to locator block and locator
> node in draft-ietf-spring-srv6-network-programming-10 is section 3.1
> which has the following text:
>
> A locator may be represented as B:N where B is the SRv6 SID block
> (IPv6 subnet allocated for SRv6 SIDs by the operator) and N is the
> identifier of the parent node instantiating the SID..
>
> I think that we need a much more detailed description of the locator
> block and locator node.

sure, but that would be in the
draft-ietf-spring-srv6-network-programming-10, not in
draft-ietf-lsr-isis-srv6-extensions, as these are not a protocol
specific constructs.

thanks,
Peter

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

Re: [Lsr] AD Review of draft-ietf-isis-te-app-09

[Les Ginsberg (ginsberg)]

Alvaro -

Thanx for the continued review.
V11 of the draft has been posted to address your additional comments.

More inline.

> -Original Message-
> From: Alvaro Retana 
> Sent: Tuesday, February 25, 2020 4:42 AM
> To: Les Ginsberg (ginsberg) ; draft-ietf-isis-te-
> a...@ietf.org
> Cc: Acee Lindem (acee) ; lsr@ietf.org; lsr-cha...@ietf.org
> Subject: RE: AD Review of draft-ietf-isis-te-app-09
> 
> On February 7, 2020 at 1:50:58 AM, Les Ginsberg wrote:
> 
> Les:
> 
> Hi!
> 
> > We have published V10 of the draft addressing your comments.
> 
> It looks like your copy of my review was truncated (not sure why).
> The archive has the complete version, and I pasted the remaining
> comments at the end of this message.
> 
> https://mailarchive.ietf.org/arch/msg/lsr/Q39ilCqsDo0WIhayZ57RTqHEHCQ/
> 
> 
> > Note that the authors of the IS-IS and OSPF drafts are "synchronizing" as
> > there is a lot of similarity in your comments regarding the two drafts. We
> > have decided to close all issues with you for the IS-IS draft first - then
> > hopefully the equivalent changes can be made for the OSPF draft can be
> made
> > and resolved more quickly.
> 
> Makes sense!
> 
> 
> > Detailed responses inline.
> 
> I have some responses myself; most of them not-major.  I've indicated
> the ones that I consider major -- it would be ideal if others in the
> WG chimed in with any opinions.
> 
> 
> Thanks!
> 
> Alvaro.
> 
> 
> ...
> > > (B) I was able to identify one significant functional difference which
> > > warrants a discussion of the reason for it and maybe the pros/cons:
> > >
> > > §4.1 talks about the behavior when "both SABM Length and UDABM
> Length
> > > are zero". This document makes the use of the attributes optional while
> the
> > > OSPF draft mandates their use (§3).
> > >
> > [Les:] Both drafts use the word "MAY" in the respective sections entitled
> > "Use of Zero Length Application Identifier Bit Masks".
> >
> > "MAY" - or perhaps "may" - makes sense to me because in the absence of
> SABM
> > bits there is no way to know if a given application will have any reason to
> > use the attributes advertised. The text is intended to say use by any
> > application is "permitted". I have changed the text in this way.
> 
> I'm fine with the changes you made.
> 
> This is the text from the OSPF draft that I was referring to:
> 
>    When neither the Standard Application Bits nor the User Defined
>    Application bits are set (i.e., both SABM Length and UDABM Length are
>    0) in the ASLA sub-TLV, then the link attributes included in it MUST
>    be considered as being applicable to all applications.
> 
> From your explanation, I see the intent, but the use of "MUST" gives
> the impression that there's no choice.
> 
[Les:] The OSPF text will be changed to be consistent with what is in the IS-IS 
draft.

> 
> 
> ...
> > > 177 3. Legacy Advertisements
> ...
> > > [minor] Please add references to where all the values in this section
> > > are defined...if the same as the references above.
> > >
> > [Les:] Done.
> 
> Sorry, I meant the RFCs where the sub-TLVs are defined, not the registries.

[Les:] Well, the IANA registry identifies the Reference RFCs - and has the 
advantage that it gets updated should that ever change. So I would suggest 
providing a link to the registry is actually better than identifying the RFC 
for each code point. :-)
?? 

> 
> 
> 
> ...
> > > 231 4.1. Application Identifier Bit Mask
> > >
> > > 233 Identification of the set of applications associated with link
> > > 234 attribute advertisements utilizes two bit masks. One bit mask is for
> > > 235 standard applications where the definition of each bit is defined in
> > > 236 a new IANA controlled registry. A second bit mask is for non-
> > > 237 standard User Defined Applications(UDAs).
> ...
> > > [minor] "second bit mask is for non-standard User Defined
> > > Applications" The explicit point is made here that the UDAs are used
> > > for *non-standard* applications. Given that these bits are for *user
> > > defined* applications, the user can make the bits mean anything they
> > > want (including SRTE, LFA, etc.), right? If so, then highlighting
> > > *non-standard* seems not to be needed. s/for non-standard User
> > > Defined Applications/for User Defined Applications
> > >
> > [Les:] In theory it is possible for a User Defined Application to perform 
> > the
> > same functions as a standard application (such as SRTE). However, if it did
> > so it would not be "Standard SRTE" and the bit could NOT be considered as
> the
> > same as "standard SRTE".
> 
> I didn't mean just the same function, but the same application.  Let
> me try again.
> 
> Can an operator do the following:  define a bit (call it X) in the
> UDABM to mean SRTE (*the* SRTE)?  IOW, for the routers operating in
> the network (which all would be aware of the X-bit), when the X-bit is
> set it indicates that SRTE will use the information.  This operation
> would result in 

[Lsr] I-D Action: draft-ietf-isis-te-app-11.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   : IS-IS TE Attributes per application
Authors : Les Ginsberg
  Peter Psenak
  Stefano Previdi
  Wim Henderickx
  John Drake
Filename: draft-ietf-isis-te-app-11.txt
Pages   : 20
Date: 2020-02-27

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 Traffic Engineering, Loop Free Alternate) have been
   defined which also make use of the link attribute advertisements.  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
   which 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-11
https://datatracker.ietf.org/doc/html/draft-ietf-isis-te-app-11

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-isis-te-app-11


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] Question about OSPF (transit area routing loop)

[Sergey SHpenkov]

Hi Acee,

Yes, I was able to reproduce the loop

Thanks,
Sergey

чт, 27 февр. 2020 г. в 19:54, Acee Lindem (acee) :

> Hi Sergey,
>
>
>
> Have you reproduced the loop with routers? I definitely agree that ABR_1
> will prefer the path to the ASBR through area 100. I think there is some
> ambiguity as to the cost it uses in its ASBR-Summary LSA injected into area
> 200.
>
>
>
> Thanks,
>
> Acee
>
>
>
> *From: *Lsr  on behalf of Sergey SHpenkov <
> sergey.v.shpen...@gmail.com>
> *Date: *Wednesday, February 26, 2020 at 2:22 AM
> *To: *"lsr@ietf.org" 
> *Subject: *Re: [Lsr] Question about OSPF (transit area routing loop)
>
>
>
> Acee,
>
>
>
> Because ABR_1 creates SumLSA-4 for the ASBR not from the backbone
> area. The cost of SumLSA-4 for ASBR is 300.
>
>
>
> Thanks,
>
> Sergey
>
>
>
> вт, 25 февр. 2020 г. в 22:44, Acee Lindem (acee) :
>
> Hi Sergey,
>
> I don’t see why RT_1 wouldn’t go through ABR_1 to get to the ASBR.
>
> Thanks,
>
> Acee
>
>
>
> *From: *Lsr  on behalf of Sergey SHpenkov <
> sergey.v.shpen...@gmail.com>
> *Date: *Tuesday, February 25, 2020 at 2:38 PM
> *To: *"l...@ietf..org " 
> *Subject: *[Lsr] Question about OSPF (transit area routing loop)
>
>
>
> Hi,
>
> In section 16.3 of the OSPF RFC 2328 standard, it is stated that all ABR
> routers
>
> connected to a transit area are required to check the sumLSA contained
> within
>
> this area in order to possibly improve the intra-area and inter-area
> backbone routes
>
> for themselves.
>
>
> See the picture:
>
> The RT_1 and ABR_3 routers will use different paths to the ASBR router:
>
> ABR_3 -> RT_1 -> ABR_1 -> ASBR = cost 3
> RT_1 -> ABR_3 -> ABR_2 -> ASBR = cost 21
>
> route loop between RT_1 and ABR_3
>
> Please explain this situation
>
> Thanks,
> Sergey
>
>
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Peter Psenak]

Hi Chris,

On 27/02/2020 17:54, Chris Bowers wrote:

LSR WG,

Section 9 of draft-ietf-lsr-isis-srv6-extensions-05 defines the  SRv6 
SID Structure Sub-Sub-TLV. In particular, it defines encoding for the 
locator block length and the locator node length.  The text refers to 
[I-D.ietf-spring-srv6-network-programming] for the definition of these 
concepts.


As far as I can tell, the only reference to locator block and locator 
node in draft-ietf-spring-srv6-network-programming-10 is section 3.1 
which has the following text:


A locator may be represented as B:N where B is the SRv6 SID block
(IPv6 subnet allocated for SRv6 SIDs by the operator) and N is the
identifier of the parent node instantiating the SID.

I think that we need a much more detailed description of the locator 
block and locator node.


sure, but that would be in the 
draft-ietf-spring-srv6-network-programming-10, not in 
draft-ietf-lsr-isis-srv6-extensions, as these are not a protocol 
specific constructs.


thanks,
Peter



Thanks,

Chris



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

[Lsr] clarification of locator block and locator node in draft-ietf-lsr-isis-srv6-extensions

[Chris Bowers]

LSR WG,

Section 9 of draft-ietf-lsr-isis-srv6-extensions-05 defines the  SRv6 SID
Structure Sub-Sub-TLV. In particular, it defines encoding for the locator
block length and the locator node length.  The text refers to
[I-D.ietf-spring-srv6-network-programming] for the definition of these
concepts.

As far as I can tell, the only reference to locator block and locator node
in draft-ietf-spring-srv6-network-programming-10 is section 3.1 which has
the following text:

   A locator may be represented as B:N where B is the SRv6 SID block
   (IPv6 subnet allocated for SRv6 SIDs by the operator) and N is the
   identifier of the parent node instantiating the SID.

I think that we need a much more detailed description of the locator
block and locator node.

Thanks,

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

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

[Acee Lindem (acee)]

Hi Sergey,

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

Thanks,
Acee

From: Lsr  on behalf of Sergey SHpenkov 

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

Acee,

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


Thanks,
Sergey

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

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

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

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

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

route loop between RT_1 and ABR_3

Please explain this situation

Thanks,
Sergey

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