Re: [Lsr] draft-ietf-isis-segment-routing-extensions-16 - Shepherd review comments

[Uma Chunduri]

Les,

Thanks for your quick response and changes in the document. Please find my
further response below* [Uma]:*

--
Uma C.

On Mon, Jun 11, 2018 at 10:00 PM, Les Ginsberg (ginsberg) <
ginsb...@cisco.com> wrote:

> Uma –
>
>
>
> Thanx for the prompt review.
>
>
>
>  2. Section 2.1
>
>
>
> a. "The 'Prefix SID' MUST   be unique within a given IGP domain (when the
> L-flag is not set)."
>
>
>
>I see this is conflicting with what's been defined in
> https://tools.ietf.org/html/draft-ietf-spring-segment-routing-14,
>
> section 3.3 -
>
>"Within an anycast group, all routers in an SR domain MUST
> advertise  the same prefix with the same SID value."
>
>
>
>If you see otherwise please explain why?
>
>
>
> *[Les:] This is a misunderstanding on your part.*
>
> *An anycast prefix may be advertised by multiple nodes, but the Prefix SID
> associated with the prefix is the same regardless of which node advertises
> it. So there is no contradiction/conflict here.*
>
>
>

*[Uma]:  I understood the intention.*

*This doc says - "The 'Prefix SID' MUST   be unique within a given IGP
domain (when the L-flag is not set)." *
*And it won't give any exception for "anycast group" either in the text or
through reference to  draft-ietf-spring-segment-routing-14
.*



>
>
> b. "A 4 octet index defining.."
>
> What happens  to the computed label value if the index is of 4 octets
> value? I am asking this as index can have 4 octets but the eventual label
> (SRGB offset + index) would be only 20 bits.
>
> Can you point (if any)  references to https://tools.ietf.org/html/
> draft-ietf-spring-segment-routing-mpls appropriate sections -  is this is
> addressed there?
>
>
>
> *[Les:] See
> https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls-14#section-2.4
> 
> (emphasis added):*
>
>
>
> *“ 0 =< I < size. If the index "I" does not satisfy the previous*
>
> *  inequality, **then the label cannot be calculated**.”*
>

*[Uma]: Thanks for the pointer. I am fine with keeping this at a common
place but this document  needs a generic reference specifically for some of
the conflict/error conditions to that.*


>
>
> 3. Section 2.2.1
>
>
>
> a. "F-Flag: Address-Family flag..."
>
>
>
>  Not sure why this has to do with encapsulation? What happens if
> native IPv4/IPv6 data packet is using this SID with out any encapsulation?
> Could you please clarify.
>
>
>
> *[Les:] When the packet is forwarded over the specified outgoing interface
> it will either have an IPv4 encapsulation or an IPv6 encapsulation i.e.,
> the payload is encapsulated in the afi specific L3 protocol. *
>
> *This does not mean that a new AFI specific header is imposed.*
>
>
>

*[Uma]: Thanks.  I didn't expect payload encapsulation with L3 in IS-IS
document. I see this is derived from the base TLV where this sub-TLV
belongs to (22/222/223 etc.). This sounded like additional encap and hence
my comment.*

*But one of my larger point here is why a sub-TLV has to specify/define AF.
This is the property of the associated TLV/MT-aware TLV.*
*I understand this could be too late to change here but this additional
information should not conflict with base while usage. *
*One incorrect usage *example* of this sub-TLV with AF unset (IPv4) in TLV
222 with MT-ID=2 (IPv6).*

*As it stands this combinations valid/allowed. Perhaps some text around
this would be helpful.*



> 4. Section 2.2.2
>
>
>
> a. Nit: V and L flags: Content is duplicated and perhaps it can instead
> refer to section 2.2.1
>
>
>
>
>
> *[Les:] The text says:*
>
> *“ where F, B, V, L, S and P flags are defined in Section 2.2.1.”*
>
>
>
> *???*
>

*[Uma]: Sorry - I should have been more specific. Was referring to
duplicated text in Section 2.2.1 and 2.2.2*

 "

  *  A 3 octet local label where the 20 rightmost bits are used for
 encoding the label value.  In this case the V and L flags MUST
 be set.

  *  A 4 octet index defining the offset in the SID/Label space
 advertised by this router using the encodings defined in
 Section 3.1
.
In this case V and L flags MUST be unset."



>
>
>
> 5. Section 3.2 and Section 2.1
>
>
>
> Could you please clarify what is preferred if multiple prefix-sids
> with different algorithm values are advertised for the same SID value?
>
>
>
> *[Les:] There is no “preference” here. In order to have algorithm specific
> forwarding entries we MUST have different SIDs for each algorithm. A router
> will use the SID which matches the algorithm associated with the forwarding
> entry.*
>

*[Uma]: ..and IMO, this should be specified. *
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] IPR Poll draft-ietf-isis-segment-routing-msd.

[Uma Chunduri]

I am not aware of any other IPRs on this draft other than what's been
already disclosed.

BR,

--
Uma C.

On Wed, Jun 13, 2018 at 6:37 AM, Christian Hopps  wrote:

> [Sigh, I quoted the wrong email and mixed things up -- thanks Bruno!]
>
> Authors,
>
> The original WGLC requested the authors indicate if they were aware of any
> additional IPR. This seems to have gotten lost in a bunch of comments that
> followed.
>
> Can each author reply to this email (and the list) indicating if they are
> aware of any *new* IPR on this document. Currently declared related IPR:
>
> https://datatracker.ietf.org/ipr/search/?submit=draft=dra
> ft-ietf-isis-segment-routing-msd
>
> Thanks,
> Chris.
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] IPR Poll on draft-ietf-isis-segment-routing-extensions-16 (Shepherd write-up)

[Uma Chunduri]

Dear All,

Are you aware of any IPR that applies to
https://tools.ietf.org/html/draft-ietf-isis-segment-routing-extensions-16 ?

Sending this email as suggested by LSR chairs - as this was not noticed
during/around WGLC.

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

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

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

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

Re: [Lsr] Flex Algorithms Drafts

[Uma Chunduri]

>
>
> these are being renamed in the next update to:
>
> Flex-Algorithm - Single octet value between 128 and 255 inclusive
>
>
> IGP Alg. Type - Single octet. Value between 0 and 127 inclusive, that
> identifies IGP algorithm type used to compute paths for the Flex-Algoritm.
> Values are defined in "IGP Algorithm Types" registry defined under
> "Interior Gateway Protocol (IGP) Parameters" IANA registries


Hi Peter,

The above change would conflict
https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml (where
it is defined till 255) and

cause changes to

https://tools.ietf.org/html/draft-ietf-ospf-segment-routing-extensions-25
(Which is  in RFC Editor queue)

https://datatracker.ietf.org/doc/draft-ietf-isis-segment-routing-extensions/
(In WG LC)


Are we going in that direction?

I still see "Flex-Algorithm" is light-weight sub-topology with constrains
and still computed using one of the Algorithms as specified in
https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml.

Kindly avoid confusion around the terminology here, plz -

Thx!

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

Re: [Lsr] Flex Algorithms Drafts

[Uma Chunduri]

Hi Peter,

Thanks for your response. See my questions below -

On Tue, Apr 17, 2018 at 2:31 AM, Peter Psenak <ppse...@cisco.com> wrote:

> Hi Uma,
>
> please see inline:
>
>
> On 17/04/18 00:14 , Uma Chunduri wrote:
>
>> Dear All,
>> I am neutral to combining the content of OSPF and IS-IS into a single
>> draft.
>> However, I have 2 questions on this draft.
>> 1.
>>0   1   2   3
>>  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> |  Type |Length |   Algorithm   |  Metric Type  |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> |   Alg. Type   |Priority   |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> |  Sub-TLVs |
>> +   +
>> |...|
>> |   |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> */   Algorithm: Flex-Algorithm number.  Value between 128 and 255/*
>> */  inclusive./*
>> */  Algorithm Type: Single octet identifying the algorithm type used/*
>> */  to compute paths for the Flex-Algoritm.  Values are defined in/*
>> */  "IGP Algorithm Types" registry defined under "Interior Gateway/*
>> */  Protocol (IGP) Parameters" IANA registries./*
>> Why there are two fields "Algorithm" and "Algorithm Type" ?
>>
>
> these are being renamed in the next update to:
>
> Flex-Algorithm - Single octet value between 128 and 255 inclusive
>

1.
"Algorithm "  as defined in the draft -  I see is nothing but a light
weight sub topology (with out MT ADJs)  computed using an "Alg. Type".

As of now -

"Algorithm" type X is using "Alg.Type" Y to compute  routes?

After the change you mentioned, this would become


"Algorithm" type X is using "Alg.Type" Y to compute  routes?

IMO, Overloading of the terms cause lot of  confusion (and
mis-understanding) down the line. This happened already in a different
context for IS-IS; ask me how I will give clear example.

I followed the other thread and agree with some of the points raised by Jie
w.r.t what is being defined and what is being done.



>
> IGP Alg. Type - Single octet. Value between 0 and 127 inclusive, that
> identifies IGP algorithm type used to compute paths for the Flex-Algoritm.
> Values are defined in "IGP Algorithm Types" registry defined under
> "Interior Gateway Protocol (IGP) Parameters" IANA registries


> What are we saving here by overloading the terminology?
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Concerns with draft-chunduri-lsr-isis-preferred-path-routing

[Uma Chunduri]

Hi Peter,


-Original Message-
From: Peter Psenak [mailto:ppse...@cisco.com] 
Sent: Tuesday, July 17, 2018 9:34 AM
To: Uma Chunduri ; Ketan Talaulikar (ketant) 
; lsr@ietf.org
Cc: spr...@ietf.org
Subject: Re: [Lsr] Concerns with draft-chunduri-lsr-isis-preferred-path-routing


> flex-algo is NOT a per path state. It's a regular prefix-SID, which 
is bound to a prefix only.

Not quite. I will come back to this bit later.

>The problem with your proposal is that you flood all paths to all 
routers in the area and ask every router to evaluate all of them and see which 
of them may apply. This scale poorly.

Please see Section 6, in 01 version.

--
Uma C.

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

Re: [Lsr] Concerns with draft-chunduri-lsr-isis-preferred-path-routing

[Uma Chunduri]

Hi Ketan,


In-line [Uma]:
--
Uma C.

-Original Message-
From: Ketan Talaulikar (ketant) [mailto:ket...@cisco.com] 
Sent: Tuesday, July 17, 2018 7:13 AM
To: Uma Chunduri ; lsr@ietf.org
Cc: spr...@ietf.org
Subject: Concerns with draft-chunduri-lsr-isis-preferred-path-routing

Hi Uma,

I would like share more context on the concerns that I raised on this proposal 
in LSR WG yesterday where we could not complete our discussion on the mike due 
to time constraints.

IGPs were originally invented for topology computation and then route 
programming based on the SPT computed. We've extended IGPs to carry/flood 
information and this includes information that were meant for various 
applications. IGPs always do distribute topology computation - that is the core 
principle.

The PPR proposal takes IGPs into the area of flooding p2p paths and then 
setting up forwarding state along the path - essentially introducing path 
provisioning capabilities into it. Essentially adding a new functionality that 
is NOT distributed topology computation.

For clarity, I could summarize the PPR as follows (please correct if wrong):
- Someone (head-end or controller) computes a SR Path which is expressed as a 
SID List (it's a list of EROs just like in RSVP-TE - loose or strict)
- The head-end floods this SR Path (and its EROs) into the IGP domain so all 
routers in the area get the P2P paths computed by all head-ends
- Each router then must look at every such SR Path flooded by every router and 
examine if it is part of the ERO list; if so then it needs to program the 
forwarding state for that PPR id (aka label)
- The headend can then just look at this like a "tunnel" and do something like 
IGP shortcut to the destination behind it

This is picking EROs from RSVP-TE and putting them into IGPs for flooding p2p 
path state pervasively. Consider the kind of flooding scale and challenges when 
all these SR Paths go to every router irrespective of whether they need/use it. 
Then on top of that, we are proposing IGPs to program a local cross-connect if 
they are on that SR Path. My question is, why not just use RSVP-TE in this 
case? RSVP-TE does signalling but it does it only on the nodes that matter for 
a specific LSP. 

[Uma]:  This helps in deployments, who is seeking source routing paradigm, but 
SID stack on the packet is unsustainable. This statement is applicable for both 
MPLS and IPv6 case. 
 Coming to the EROs in IGP - it was there in SR drafts, 
including as working group draft for 3 years.  But what completely lacked was 
how to use those. There are significant differences in the format and 
importantly usage to solve various issues including hardware 
Compatibilities of various line cards (and hence available 
paths), MTU and line rate issues. I don't think you can use RSVP-TE to solve 
these SR issues.

This is called SR but it introduces a forwarding state on each of the hops 
(i.e. the PPR label cross-connect) - something different from SR architecture. 

[Uma]:  You already introduced per path state in various cases (binding sids to 
local policy, flex-algo).  This has been discussed lately as part of 
re-chartering discussion. 
 This thread discusses that in detail and I fully concur what 
Dave said here 
https://www.ietf.org/mail-archive/web/spring/current/msg03794.html 


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

[Lsr] Fwd: IPR Poll follow up on draft-ietf-isis-segment-routing-extensions-16

[Uma Chunduri]

-- Forwarded message --
From: Saku Ytti 
Date: Fri, Jun 22, 2018 at 5:17 PM
Subject: Re: IPR Poll follow up on
draft-ietf-isis-segment-routing-extensions-16
To: umac.i...@gmail.com
Cc: draft-ietf-isis-segment-routing-extensi...@ietf.org, "Horneffer,
Martin" , Edward Crabbe <
edward.cra...@gmail.com>, ro...@google.com, milojevici...@gmail.com,
slu...@cisco.com, lsr-cha...@ietf.org


Not aware of any IPR.

On Sat, 23 Jun 2018 at 00:16, Uma Chunduri  wrote:
>
> Dear All,
>
> All authors have responded to the IPR Poll.
>
> Still couple of contributors (as listed) need to respond to the IPR Poll
>  - Martin H.
>  - Edward C.
>  - Rob S.
>  - Igor M.
> - Saku Y.
>
> Please respond to the LSR list thread.
>
> --
> Uma C.
>
> On Fri, Jun 15, 2018 at 9:16 AM, Uma Chunduri  wrote:
>>
>> Still need one author's and couple of contributors response for the
above subject.
>>
>> Please respond to  the LSR list thread.
>>
>> --
>> Uma C.
>
>


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

Re: [Lsr] Flex Algorithms Drafts

[Uma Chunduri]

Dear All,


I am neutral to combining the content of OSPF and IS-IS into a single draft.
However, I have 2 questions on this draft.


1.

  0   1   2   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Type |Length |   Algorithm   |  Metric Type  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Alg. Type   |Priority   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Sub-TLVs |
   +   +
   |...|

   |   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Algorithm: Flex-Algorithm number.  Value between 128 and 255
  inclusive.

  Algorithm Type: Single octet identifying the algorithm type used
  to compute paths for the Flex-Algoritm.  Values are defined in
  "IGP Algorithm Types" registry defined under "Interior Gateway
  Protocol (IGP) Parameters" IANA registries.

Why there are two fields "Algorithm" and "Algorithm Type" ?

While algorithm-type defines currently only 2 algorithms (0-SPF and 1-Strict 
SPF), that space can be carved out for user defined computation algorithms (I 
presume).  If yes, then "Algorithm Type" becomes user defined flexible 
algorithm.


2.  Also some of the sub-tlvs defined in the draft doesn't seem to belong to 
Router capabilities; where algorithm description is being advertised.

Flexible Algorithm Exclude Admin Group Sub-TLV

   "   The Flexible-Algorithm definition can specify 'colors' that are used
   by the operator to exclude links during the Flex-Algorithm path
   computation.




--
Uma C.


-Original Message-
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Thursday, April 12, 2018 2:53 AM
To: Peter Psenak (ppsenak) ; lsr@ietf.org
Cc: draft-hegdeppsenak-isis-sr-flex-a...@ietf.org
Subject: Re: [Lsr] Flex Algorithms Drafts

Hi Peter,

Ok - we'll decide during whether to merge during the WG adoption call. It would 
be a good LSR experiment for a combined draft if there are no significant 
differences between the protocols that would make a combined draft unwieldy.

Thanks,
Acee



On 4/12/18, 3:35 AM, "Peter Psenak (ppsenak)" 
> wrote:

Hi Acee,

On 11/04/18 22:36 , Acee Lindem (acee) wrote:
> In preparation for WG adoption and IANA early code point allocation, I 
suggest that we rename the “Flexible Algorithm Definition TLV Metric Registry” 
to the “Flexible Algorithm Definition TLV Metric Type Registry” to avoid 
confusion as to whether we are defining the actual metrics here. I know that in 
the contexts of the drafts, it is clear but the registries are going to be on 
their own. Additionally, while protocol TLV types should not be shared between 
protocols, it seems this registry could be common and placed in our "Interior 
Gateway Protocol (IGP) Parameters" registry.

sure I can make that change.

>
> Finally, the OSPF version has a typo in section 8.2. The last two types 
should be 2 and 3.

right, will fix it.
>
> o  0 - Reserved
>
> o  1 - Flexible Algorithm Exclude Admin Group Sub-TLV
>
> o  1 - Flexible Algorithm Include-Any Admin Group Sub-TLV
>
> o  1 - Flexible Algorithm Exclude-All Group Sub-TLV
>
> Also, how so the authors feel about combining the drafts? I know the 
IS-IS version has had more discussion and wouldn't want to hold it up if there 
is a possibility. I don't feel strongly one way or another.

I'm fine both ways.

thanks,
Peter

>
> Thanks,
> Acee
>



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

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

Re: [Lsr] Fwd: New Version Notification for draft-li-dynamic-flooding-04.txt

[Uma Chunduri]

Hi Peter,

> I have the feeling that the dependency of the "flooding topology" on the 
> flooded data is going to bring more complexity, than the selection of the 
> distributed algorithm to be used, if we ever need to support more then one.


I see

https://datatracker.ietf.org/doc/draft-hegdeppsenak-isis-sr-flex-algo/?include_text=1
 proposes flexible algorithms for route computation. 

Here, you are saying similar to flexible algorithms for route computation - 
flexible algorithms can be used for computing "flooding topology" in a 
distributed fashion ; is that correct?

Else I don't see any connection to different algorithms in the flooding 
topology context; please clarify?
--
Uma C.


-Original Message-
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak
Sent: Friday, April 06, 2018 8:50 AM
To: tony...@tony.li
Cc: lsr@ietf.org
Subject: Re: [Lsr] Fwd: New Version Notification for 
draft-li-dynamic-flooding-04.txt

Hi Tony,

if we start with a single standardized algorithm, that is easy to implement and 
deploy. We can leave the door open for additional algorithms to be defined 
later together with the selection mechanism.

I have the feeling that the dependency of the "flooding topology" on the 
flooded data is going to bring more complexity, than the selection of the 
distributed algorithm to be used, if we ever need to support more then one.

thanks,
Peter


On 06/04/18 17:19 , tony...@tony.li wrote:
>
> Hi Peter,
>
> Thank you for your comments.
>
>> while I appreciate the flexibility associated with the centralized 
>> computation of the flooding topology, it has some drawbacks as well:
>>
>> 1. "flooding topology" must be flooded. This makes the flooding 
>> dependent on the flooded data itself.
>
>
> Absolutely true. If the computation of the topology is incorrect, that 
> would certainly be a bug.
>
>
>> 2. The extra flooding of "flooding topology" adds some delay in the 
>> convergence towards the new "flooding topology”.
>
>
> Since we distribute the flooding topology before there are topology 
> failures, it would seem like the latency is not a significant concern.
>
>
>> Have you considered the distributed computation of "flooding topology"
>> using some standardized algorithm?
>
>
> Yes, Kireeti raised this in London as well. There are some practical 
> issues with this. How do we ever converge on an algorithm?
>
> There are many perspectives on what an adequate flooding topology 
> might be. Different administrations have different considerations and 
> risk tolerances.
>
> Debugging is going to be more challenging, as inconsistencies between 
> two nodes with different ideas of the topology will be difficult to 
> detect until there is a catastrophic failure.
>
> I’m trying to do something practical, and it seems like doing this in 
> a centralized fashion is the quickest, easiest, and most robust way forward.
>
>
>> Eventually we can support multiple standardized algorithms. A node 
>> can advertise support for several algorithms and the "active" 
>> algorithm is selected based on some criteria that would guarantee 
>> that all nodes in the flooding domain select the same one.
>
>
> Seems like that would also require some administrative input.
>
> So, I agree that that’s a technical possibility, but I think that 
> there’s significant problems in making that work. I prefer to focus on 
> something that we can implement more quickly.
>
> Tony
>
>

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

Re: [Lsr] LSR WG Adoption call for "IS-IS Traffic Engineering (TE) Metric Extensions" - draft-ginsberg-lsr-isis-rfc7810bis-00

[Uma Chunduri]

Thanks for clearly documenting the changes being made in a separate section.

Support.


--
Uma C.




On Apr 9, 2018, at 21:20, Acee Lindem (acee) 
> wrote:
This draft simply fixes a problem in RFC 7810 that resulted in an 
incompatibility issue with implementations. Given the simplicity of this 
document, I’d like to have an abbreviated WG adoption call of one week. Please 
indicate your support or objections to this document by April 17th, 2018.

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

Re: [Lsr] IS-IS over TCP

[Uma Chunduri]

>BTW, there is another reason for our proposal. With the incoming 
drafts about flooding-topology-reduction, there is a new problem.
>All these proposals have situations where non-flooding adjacencies 
suddenly change to flooding adjacencies. When that happens, the LSDBs need to 
be synchronized again. To do that, all of them propose "just send a CSNP and be 
done with it". Well, the more LSPs, the more CNSPs that need to be>sent. 
With 10k LSPs that's
>110 CSNPs. CSNPs are not reliable. This re-synchronization happens 
when there is churn in the IGP. Are we sure CSNPs aren't dropped somewhere ? 

These do get dropped and with default configurations of lot of commercial 
products, where no periodic CSNP advertisements on P2P links, caused lot of 
grief in even in regular SP networks (especially in some HA scenarios).
It's obvious and one has to enable recommend periodic CSNPs for any proposal 
relevant here (despite 110 CSNPs, yes inefficient but saves you big time in 
corner cases). This is kind of most needed insurance...

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

Re: [Lsr] Comments on draft-chunduri-lsr-isis-mt-deployment-cons-01

[Uma Chunduri]

Les,

Thanks for your comments.

  > If we were to proceed with this draft at all, I therefore think we
should limit the scope to merely explaining what the requirements for
correct operation are using the various modes.

Agree and this aspect is baked-in along with some common pitfalls. It also
clears the terminology and nuances here w.r.t "Topology" and "Address
Family".

 > I am not fully convinced we need an additional draft on this topic.
But I am convinced that IETF should NOT be writing deployments guides.

I would like to listen to other opinions too. But at least when operator
commented otherwise in the LSR meeting on the mike and I got 2 emails with
few suggestions and interest.

Let me clarify a bit here. This is precisely laying out various options
w.r.t IPv6 only and why this topic has been confusing for lot of  folks
(other than few experts, like you!).
Would be glad to get your comments on the text where it is sounding
objectionable to you or in general if you are seeking any improvements. Thx
in advance for that.

--
Uma C.




On Tue, Nov 6, 2018 at 3:35 PM Les Ginsberg (ginsberg) 
wrote:

> Having now read the draft in its entirety...
>
> As per the discussion in the WG meeting today...
>
> I agree that MT and its relationship to address-families can be confusing.
> I also agree that when deploying multiple address-family support the
> decision to use/not-use MT can be confusing.
> I also agree that now that IPv6 only deployments are becoming a reality
> whether to use MTID #0 or MTID #2 can be confusing.
>
> Etc.
>
> The discussion in the WG seemed to focus on the benefits of writing a
> deployment guide to both recommend desirable deployments configurations and
> alert folks to the problems they are likely to see if they are not careful
> in ensuring their topology usage matches their actual address-family
> support.
>
> It is often the case that vendors write configuration/deployment guides to
> provide guidance to their customers as to how to configure a feature. In
> doing so, a vendor is free to express their biases as to what they consider
> a preferred strategy.
> If the IETF were to do the same thing, there is a higher bar - since any
> IETF document represents a consensus of the WG in which it was written.
> There is more than one way to configure address-family support and each of
> us may have our biases as to which of the multiple strategies is preferred.
> Consensus on this is not required nor is it necessarily easy to achieve.
>
> I am therefore NOT eager to have the IETF become the home of "feature
> deployment guides".
>
> If we were to proceed with this draft at all, I therefore think we should
> limit the scope to merely explaining what the requirements for correct
> operation are using the various modes.
> I emphasize again that RFC 1195 speaks quite directly to the limitations
> of using a single topology to support multiple "address-families". (The
> discussion there is CLNS/IP oriented - but the issues are the same as
> IPv4/IPv6.)
> I am not fully convinced we need an additional draft on this topic. But I
> am convinced that IETF should NOT be writing deployments guides.
>
>Les
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] AD Review of draft-ietf-isis-reverse-metric-11

[Uma Chunduri]

Hi Naiming & Co-authors


Thanks for excellent work. Though, I reviewed the early versions of this draft 
could not follow all latest discussions/updates.

But just want to chime-in on part of the text posted here and the subsequent 
AD’s comment.

In-line [Uma]:
--
Uma C.

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Alvaro Retana
Sent: Friday, September 28, 2018 2:45 PM
To: Naiming Shen (naiming) 
Cc: lsr@ietf.org; Les Ginsberg (ginsberg) ; 
draft-ietf-isis-reverse-met...@ietf.org; Christian Hopps ; 
lsr-cha...@ietf.org
Subject: Re: [Lsr] AD Review of draft-ietf-isis-reverse-metric-11

On September 27, 2018 at 6:36:29 PM, Naiming Shen (naiming) 
(naim...@cisco.com) wrote:

Naiming:

Hi!

Some answers below.  Please take a look and publish an update.

Thanks!

Alvaro.

...
Note that I read -11, but -12 was published in the interim -- so I'm
putting this comment up here.  The only change in -12 is the addition (in
the IANA Considerations section) of "a new registry for sub-TLVs of the
Reverse Metric TLV".  Why do we need this new registry?  The description
(in §2) of the use of this sub-TLV already references rfc5305 (where a TE
Default Metric sub-TLV is already defined), so it seemed somewhat natural
to me to simply reuse that sub-TLV here.  From the discussion on the list,
I understand the intent to "future proof", even if no other applications
come to mind.  If that is the path we want to go, then we'll need a
complete description of the new sub-TLV as well. [Some of my comments
bellow assume the existing sub-TLV from rfc5305.]

 With the email exchange from you and Les, I assume I keep the same
as in the version 12 on this sub-TLV registry.
Yes.
However, I need you to add a description of the sub-TLV in this document.  
Right now there is a reference to rfc5305, but as Les explained, even though 
these sub-TLVs look the same, they are really different.  When doing so, the 
references to rfc5305 (for the sub-TLV) would not be needed.

 ok, modified. see diff.

The first MUST (below) sounds as if there must always be one of these sub-TLVs. 
 However, if other sub-TLVs are defined in the future, and this one is not 
needed, the MUST would make it mandatory.

OLD>

"This sub-TLV is optional, and MUST appear once at most in the Reverse Metric 
TLV, otherwise the entire Reverse Metric TLV MUST be ignore on the receive."

NEW>

This sub-TLV is optional, if it appears more than once then the entire Reverse 
Metric TLV MUST be ignored.



...


178   The Reverse Metric TLV is optional.  The Reverse Metric TLV may be
179   present in any IS-IS Hello PDU.  A sender MUST only transmit a single
180   Reverse Metric TLV in a IS-IS Hello PDU.  If a received IS-IS Hello
181   PDU contains more than one Reverse Metric TLV, an implementation
182   SHOULD ignore all the Reverse Metric TLVs and treat it as an error
183   condition..

[nit] The first two sentences sound redundant to me.

 OK.



[major] The text above is not specific about which PDUs can include the
Reverse Metric TLV.  The text does say that it is optional and that it may
be in an IIH once...but it doesn't say anything about other PDUs.  The IANA
Considerations section contains the attributes to be included in the
registry, but those are not Normative.

 Added other PDU MUST ignore it.
I saw the new text.  Thanks for being explicit about the TLV being used in an 
IIH.
Les also pointed to the following in ISO 10589: “TLVs received in a 
non-permitted PDU MUST be ignored.”  That means that the last sentence in the 
new text ("If an IS-IS node received of IS-IS Reverse Metric TLV in the PDU 
other than the IS-IS Hello PDU, this TLV MUST be ignored.”) is redundant.

 ok, removed:-) but it used to be “.. may be optional present in …”,
changed to ".. MAY be optional present in …”, the formally define into
Hello PDU.

The text now reads:

   The Reverse Metric TLV MAY be optionally present in any IS-IS Hello

   PDU. A sender MUST only transmit a single Reverse Metric TLV in a

   IS-IS Hello PDU. If a received IS-IS Hello PDU contains more than

   one Reverse Metric TLV, an implementation MUST ignore all the Reverse

   Metric TLVs.



MAY and optional are the same thing, so the first sentence is redundant.

s/MAY be optionally/MAY





...


...
 418 4.  Security Considerations

420   The enhancement in this document makes it possible for one IS-IS
421   router to manipulate the IS-IS default metric and, optionally,
422   Traffic Engineering parameters of adjacent IS-IS neighbors.  Although
423   IS-IS routers within a single Autonomous System nearly always are
424   under the control of a single administrative authority, it is highly
425   RECOMMENDED that operators configure authentication of IS-IS PDUs to
426   mitigate use of the Reverse Metric TLV as a potential attack vector,
427   particularly on multi-access LANs.

[Uma]:  1. It’s good to refer IS-IS auth drafts 5304 and 5310 and 

Re: [Lsr] LSR: Using DSCP for path/topology selection Q

[Uma Chunduri]

A quick comment below –

Cheers & have a great weekend!

--
Uma C.


From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Jeff Tantsura
Sent: Friday, November 16, 2018 12:15 AM
To: Robert Raszuk 
Cc: t...@cs.fau.de; Les Ginsberg (ginsberg) ; r...@rob.sh; 
tony1ath...@gmail.com; lsr@ietf.org
Subject: Re: [Lsr] LSR: Using DSCP for path/topology selection Q

Robert,

match DSCP X
set context Y or plane Z doesn’t make it any different.
It has been used and abused in any possible way. If you want to write a BCP 
saying - use it for X/Y/Z but not for A/B/C because of - your business.

As to using it someplace else - I’d expect respective documents to cover the 
use, flex-algo drafts as to your example.

More fundamentally, (flex-algo is the best example) we have got context aware 
metadata in a form of: MPLS labels (SR SID), v6 EHs, plethora of overlay 
encaps, etc, with accompanying CP extensions that can be used to achieve 
exactly that.

Now tell me - why again DSCP?

P.S. in my previous life, working on 5G transport slicing (yes, i know :)) - i 
needed per slice identity over the common transport, we ended up looking at UDP 
port ranges, rather than DSCP - too few bits


[Uma]: +1 and was part of that previous life. May be it should be called as “4G 
slicing” and it’s deployed in few places.  Any ways it’s all about how to map 
the incoming traffic at PE (in the above case at CSR/P-GW) to a particular LSP. 
I didn’t see any requirement which needs an MTR/flex-algo aka 
light-weight-sub-topology which needs to be built based on DSCP.

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

Re: [Lsr] draft-ietf-lsr-isis-rfc5306bis-01

[Uma Chunduri]

Les,

Few more comments for  your updated version.
in-line [Uma2]:



On Wed, May 29, 2019 at 10:09 PM Les Ginsberg (ginsberg) 
wrote:

Uma –
>

>
Hopefully we are making progress this time.
>
[Uma2]: Indeed! Thx!


>
Replies inline. Look for *[Les2:]  *
>

>
*From:* Uma Chunduri 
> *Sent:* Wednesday, May 29, 2019 6:56 PM
> *To:* Les Ginsberg (ginsberg) 
>
> ...
>
> *I think there are a few things that could be clarified in the text:*
>
>
>
> *1)State what I have written above*
>
> [Uma2]: Yes, that would help.

*2)Add Receive PA into the state machine diagram (as you suggested)*
>
> [Uma2]: For completeness you might want to add "RX PR" too in section 3.1
table (yup, same as currently documented receiving RR - being restarting
router). Also what happens in sec 3.1 for running router (aka neighbor of
the restarting router) when only RX PR Clr but RX RR set.



*3)We failed to mention that when sending the PR the restarting router
> should set the Remaining Holdtime to a value large enough to allow for the
> router reload to occur. This will serve as the value the helper router
> should use to maintain the adjacency in the absence of hellos while the
> restarting router is reloading*
>
> [Uma2]: "large enough to allow for the router reload"  - is there any
condition reload has to be initiated immediately after sending the PR by
restarting router?


>
> *I will spin a new version with those changes.*
>
> [Uma2]:
"   This document additionally describes a mechansim for a router
to
 signal its neighbors that it is preparing to initiate a restart while
 maintaining forwarding plane state.  This allows the neighbors to
 maintain their adjacencies until the router has restarted, but also
 allows the neighbors to bring the adjacencies down in the event of
 other topology changes."

 Nit: Newly added text - "additionally" has been repeated in the original
text after this paragraph.


--
Uma C.

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

Re: [Lsr] draft-ietf-lsr-isis-rfc5306bis-01

[Uma Chunduri]

Les,

Replies in-line [Uma1]:


On Tue, May 28, 2019 at 6:01 PM Les Ginsberg (ginsberg) 
wrote:

Uma -
>

>
>

>
Newly added Section 2.2.3 a says this:
>

>
*   The "remaining time" transmitted according to (b)*
>
*below MUST reflect the actual time after which the adjacency will*
>
*now expire. *
>

>
The above is same for section 2.2.1 a, which talks about RR and RA.
>
This is the reason, I asked, what is the implication of same timer value
> here for PR/PA.
>
For example, what are the implications of this new timer times out before
> the value specified in RA (as PR is obviously initiated before) ? Also see
> my original question.
>

>

>
*[Les:] Tx timers do NOT apply to the neighbors of the restarting router –
> and they are the only routers whose control plane is alive while the
> restarting router is reloading.*
>

>
[Uma1]: Yes. Who said it's otherwise?

  You are simply not answering what I was asking.  I have been
taking about restarting router when it receives PA with hold time set as
specified in 2.2.3 (re-read my original question).
  OK, let me ask this differently:
  You added the first 2 events to the 5306 table in section 3.2
as shown below. But I didn't see "RX PA" event. Perhaps you need to specify
what you would do based on the newly added text in 2.2.3.

   Also specify:
   What is the impact on restarting router when the hold time
value received in PA and RA are the same/different values?

   Unlike receiving RA would cause T3 to be set to prepare for
the worst; describe the actions of a restarting router has to when
receiving PA.

   You ought to be doing something with hold time you received
with PA, what is it?


3.2.  Restarting Router


  Event  | Restarting | ADJ Seen  | ADJ Seen  | SPF Wait

 ||RA |   CSNP|

 ===

  Restart| Send PR|   |   |

planned  ||   |   |

 ++---+---+

  Planned| Send PR clr|   |   |

   restart   ||   |   |

canceled ||   |   |

 ++---+---+

  Router | Send IIH/RR|   |   |

   restarts  | ADJ Init   |   |   |

 | Start T1,T2,T3 |   |   |

 ++---+---+

  RX RR  | Send RA|   |   |

 ++---+---+

  RX RA  | Adjust T3  |   | Cancel T1 |

 | Goto ADJ Seen RA   |   | Adjust T3 |

 --- ++---+---+





*No offense intended – but your question is bizarre – I really don’t
> understand what logic leads you to ask it. **J*
>

>

[Uma1]: You said an obvious statement above that "Tx timers do not apply to
neighbors of the restarting routers.." while I am asking about restarting
router who received PA with holding timer value set.  No offence intended,
but it's the bizarre response I never expected from you! :)



*We could have been more prescriptive – similar to
> https://tools.ietf.org/html/rfc3623#section-3.2
>  – but I think that is
> sub-optimal. It is possible for a topology change to occur which does not
> affect forwarding via the restarting node – in which case it isn’t helpful
> to bring the adjacency down.*
>

[Uma1]: Precisely. This is what I am looking for and I am not sure why
describing this won't help to have a consistent behavior  on neighboring
node implementing this feature..  You gave a very good example where it is
described (no sub-optimal).



*Rather than try to detail all possible cases, we have left it as an
> implementation decision as to how “smart” an implementation wants to be. *
>

[Uma1]: There is no rocket  science here; any implementation should avoid
bringing down the ADJ for unrelated topology changes in a remote place
which has no bearing or involvement of the restating router. For the
record, IMO this need to be  clarified (but that's up to you if you choose
not to specify and keep this for only smart implementations!).


Cheers!

--

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

Re: [Lsr] draft-ietf-lsr-isis-rfc5306bis-01

[Uma Chunduri]

Hi Acee,

On Wed, May 29, 2019 at 7:06 AM Acee Lindem (acee)  wrote:

> Hi Les, Uma,
>
>
>
> Excuse the top-post but Outlook doesn’t do well with inline response for
> messages such as this one. AFAIK, no implementation defaulted to aborting
> graceful restart due to any topology change as recommended by RFC 3623.
>
>
> Np. For IS-IS/RFC 5306  (base) yes no implementation defaulted to aborting
GR due to topology changes. If one wants to capture topology changes
during restart yes they have to do beyond GR(NSR?).
However, in the bis document with planned restart indication this is being
introduced (i.e., exiting GR if "any" topology change is detected by the
neighbor of restating router).

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

Re: [Lsr] draft-ietf-lsr-isis-rfc5306bis-01

[Uma Chunduri]

On Mon, Jun 3, 2019 at 12:06 AM Les Ginsberg (ginsberg) 
wrote:

Uma –
>

>
V2 of the draft has been published addressing your comments.
>

>
Les,

Saw the updates and it addresses more than what I asked for (oh yes, other
than topology change prescription).  Looking good.

Ship it!


--

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

[Lsr] draft-ietf-lsr-isis-rfc5306bis-01

[Uma Chunduri]

As asked by chairs I was trying to write the shepherd report on this doc.

Have few quick questions on this work:

1.

Observation: The new text added in 2.2.3 (PR and PA bits) is almost similar
 to section 2.2.1 (RR and RA bits)

Now is there any relation of the timer here with T3 (which would have been
set by restarting router with the value received with RA bit set, assuming
it is lower than the initialized value  65535).

There is no description or guidance on how these values are related and how
the restarting router handle this.


2.

On the text below

"a.  If additional topology changes occur, the adjacency which is in
   planned restart state MAY be brought down even though the hold
   time has not yet expired.  Given that the neighbor which has
   signaled a planned restart is not expected to update its
   forwarding plane in response to signaling of the topology changes
   (since it is restarting) traffic which transits that node is at
   risk of being improperly forwarded. "

Is this any topology change ? Not related to the restarting router in
question?

Need clarification text here or point me if I miss something.



Have few more questions/comments overall and shall come back.

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

[Lsr] draft-ietf-isis-mpls-elc-07

[Uma Chunduri]

Can anybody tell what was the conclusion (if any) in previous discussions in 
various WGs on why the readable label depth in an LSR has to be entropy label 
specific ?

IOW can we just modify this as "readable label depth" as opposed to "entropy 
readable label depth" ?
This would allow any other special purpose label inserted in the stack and 
would be at par with current MSD type "Base MPLS Imposition MSD" ( 
https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml ).


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

Re: [Lsr] Working Group Last Call for "Signaling Entropy Label Capability and Entropy Readable Label-stack Depth Using OSPF" - draft-ietf-ospf-mpls-elc-08

[Uma Chunduri]

>Because the intra-area link topology is not exposed across areas or to other 
>protocols.

Agreed Acee.

But just looking this again then:


  1.  Not really clear why ELC is required in Section 4, when it’s confirmed 
from Stephane’s email (Sept 4th 2019) ERLD covers both reading + doing and 
action.
  2.  Section 4 extending RFC 7794, with E bit, which is defined for prefix 
attributes for inter-area purposes (no  ERLD value obviously). Same thing can 
be achieved simply if router capability with ERLD value itself is propagated 
(per RFC 7981).

Overall, I am more confused here than earlier. But feel free to ignore my 
comments.


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

Re: [Lsr] Working Group Last Call for "Signaling Entropy Label Capability and Entropy Readable Label-stack Depth Using OSPF" - draft-ietf-ospf-mpls-elc-08

[Uma Chunduri]

Support.


One question to authors:

On E bit in section 4:  The motivation seems to extend this in Prefix 
attributes is for inter-area consideration and advertised per every local host 
prefix (link) .
   Is there any specific reason why link 
MSD is not considered instead ? ( https://tools.ietf.org/html/rfc8491)


--
Uma C.


From: mpls  On Behalf Of Acee Lindem (acee)
Sent: Friday, August 30, 2019 12:42 PM
To: lsr@ietf.org
Cc: m...@ietf.org; lsr-...@ietf.org; draft-ietf-ospf-mpls-...@ietf.org
Subject: [mpls] Working Group Last Call for "Signaling Entropy Label Capability 
and Entropy Readable Label-stack Depth Using OSPF" - draft-ietf-ospf-mpls-elc-08

We’ve gone through a number of iterations with these ELC drafts and I believe 
they are ready and meets all the use case requirements. Note that “Entropy 
Label for Spring tunnels” – draft-ietf-mpls-spring-entropy-label-12 is on the 
RFC editor’s queue.
This begins a two week last call for the subject draft. Please indicate your 
support or objection on this list prior to 12:00 AM UTC on Sept 14th, 2014.
Thanks,
Acee
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] draft-ietf-isis-mpls-elc-07

[Uma Chunduri]

Though 
[I-D.ietf-mpls-spring-entropy-label<https://tools.ietf.org/html/draft-ietf-isis-mpls-elc-08#ref-I-D.ietf-mpls-spring-entropy-label>]
 is been referred in the introduction of this draft the point of dual semantics 
(readable depth + action) for this MSD is not coming out clear in this document.


It would be useful to specify the same.


--
Uma C.

From: Les Ginsberg (ginsberg) 
Sent: Wednesday, August 28, 2019 1:59 PM
To: Acee Lindem (acee) ; Uma Chunduri 
; lsr@ietf.org
Subject: RE: [Lsr] draft-ietf-isis-mpls-elc-07

Point taken…

  Les

From: Acee Lindem (acee) mailto:a...@cisco.com>>
Sent: Wednesday, August 28, 2019 1:56 PM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; 
Uma Chunduri mailto:uma.chund...@futurewei.com>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Subject: Re: [Lsr] draft-ietf-isis-mpls-elc-07

Les,

Then what you meant in your response was, “generic RLD” as opposed to “generic 
MSD”.

Thanks,
Acee




From: "Les Ginsberg (ginsberg)" mailto:ginsb...@cisco.com>>
Date: Wednesday, August 28, 2019 at 4:46 PM
To: Acee Lindem mailto:a...@cisco.com>>, Uma Chunduri 
mailto:uma.chund...@futurewei.com>>, 
"lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>
Subject: RE: [Lsr] draft-ietf-isis-mpls-elc-07

Acee –

I do understand the question – and I believe the reference I cited provides the 
answer. You need to read the referenced draft.

If you have a cogent argument why it is safe to assume that the combination of 
actions required to support EL translate to any other type of activity that 
might be required on a label stack, please make it. Then Uma’s suggestion might 
make sense.

   Les

From: Acee Lindem (acee) mailto:a...@cisco.com>>
Sent: Wednesday, August 28, 2019 1:34 PM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; 
Uma Chunduri mailto:uma.chund...@futurewei.com>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Subject: Re: [Lsr] draft-ietf-isis-mpls-elc-07

Hi Les,
I think the question is whether there can be a single RLD depth MSD rather than 
a RLD solely for entropy label discovery.
Thanks,
Acee

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of "Les 
Ginsberg (ginsberg)" mailto:ginsb...@cisco.com>>
Date: Wednesday, August 28, 2019 at 4:29 PM
To: Uma Chunduri 
mailto:uma.chund...@futurewei.com>>, 
"lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>
Subject: Re: [Lsr] draft-ietf-isis-mpls-elc-07

Uma –

Please read 
https://tools.ietf.org/html/draft-ietf-mpls-spring-entropy-label-12#section-4<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-mpls-spring-entropy-label-12%23section-4=02%7C01%7Cuma.chunduri%40futurewei.com%7Cff6dd7fc7f384fa669f808d72bfa923b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637026227508613167=jN5BbkqK3%2FuLOyfIf7nhm4cX8wKxy%2FudEDUMR6NX9ag%3D=0>

In short, we do not assume that EL Load Balancing can be performed for generic 
MSD.

Thanx.

   Les


From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Uma 
Chunduri
Sent: Wednesday, August 28, 2019 11:38 AM
To: lsr@ietf.org<mailto:lsr@ietf.org>
Subject: [Lsr] draft-ietf-isis-mpls-elc-07

Can anybody tell what was the conclusion (if any) in previous discussions in 
various WGs on why the readable label depth in an LSR has to be entropy label 
specific ?

IOW can we just modify this as “readable label depth” as opposed to “entropy 
readable label depth” ?
This would allow any other special purpose label inserted in the stack and 
would be at par with current MSD type “Base MPLS Imposition MSD” ( 
https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Fassignments%2Figp-parameters%2Figp-parameters.xhtml=02%7C01%7Cuma.chunduri%40futurewei.com%7Cff6dd7fc7f384fa669f808d72bfa923b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637026227508623162=GYeLpP05mnwKBOxC2tJJ1wxkwcm%2Bip401xzFgIdE1ME%3D=0>
 ).


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

[Lsr] Fwd: New Version Notification for draft-chunduri-lsr-isis-mt-deployment-cons-03.txt

[Uma Chunduri]

Dear LSR WG,

Any comments, suggestions or feedback is welcome.

--
Uma C.


-- Forwarded message -
From: 
Date: Sun, May 17, 2020 at 9:16 PM
Subject: New Version Notification for
draft-chunduri-lsr-isis-mt-deployment-cons-03.txt
To: Uma Chunduri , Jeff Tantsura <
jefftant.i...@gmail.com>, Shraddha Hegde 



A new version of I-D, draft-chunduri-lsr-isis-mt-deployment-cons-03.txt
has been successfully submitted by Uma Chunduri and posted to the
IETF repository.

Name:   draft-chunduri-lsr-isis-mt-deployment-cons
Revision:   03
Title:  IS-IS Multi Topology Deployment Considerations
Document date:  2020-05-17
Group:  Individual Submission
Pages:  9
URL:
https://www.ietf.org/internet-drafts/draft-chunduri-lsr-isis-mt-deployment-cons-03.txt
Status:
https://datatracker.ietf.org/doc/draft-chunduri-lsr-isis-mt-deployment-cons/
Htmlized:
https://tools.ietf.org/html/draft-chunduri-lsr-isis-mt-deployment-cons-03
Htmlized:
https://datatracker.ietf.org/doc/html/draft-chunduri-lsr-isis-mt-deployment-cons
Diff:
https://www.ietf.org/rfcdiff?url2=draft-chunduri-lsr-isis-mt-deployment-cons-03

Abstract:
   This document analyzes IS-IS Multi Topology (MT) applicability in
   various IS-IS deployments.  This document explores the nuances around
   the terminology and usage of various IS-IS address families,
   topologies with different considerations, for choosing the right
   combination for a specific deployment scenario.

   This document also discusses various ways one can deploy IPv6 only
   IS-IS topology.





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 WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

[Uma Chunduri]

Support.

--
Uma C.

On Tue, Aug 18, 2020 at 7:17 AM Acee Lindem (acee)  wrote:

>
>
> Based on the discussions in the last meeting and on the mailing list
> regarding draft-chen-isis-ttz-11, the chairs feel that there are enough
> differences with draft-ietf-lsr-isis-area-proxy-03 and in the community to
> consider advancing it independently on the experimental track.
>
>
>
> These differences include abstraction at arbitrary boundaries and IS-IS
> extensions for smooth transition to/from zone abstraction.
>
>
>
> We are now starting an LSR WG adoption call for
> draft-chen-isis-ttz-11.txt. Please indicate your support or objection to
> adoption prior to Tuesday, September 2nd, 2020.
>
>
>
> Thanks,
>
> Acee and Chris
>
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Request WG adoption of TTZ

[Uma Chunduri]

Acee,

In-line ..

On Wed, Jul 15, 2020 at 10:14 AM Acee Lindem (acee)  wrote:

> Speaking as WG member…
>
>
>
> See inline.
>
>
>
> *From: *Lsr  on behalf of Uma Chunduri <
> umac.i...@gmail.com>
> *Date: *Wednesday, July 15, 2020 at 12:52 PM
> *To: *Henk Smit 
> *Cc: *"lsr@ietf.org" , Huaimo Chen <
> huaimo.c...@futurewei.com>
> *Subject: *Re: [Lsr] Request WG adoption of TTZ
>
>
>
>
>
>
>
> On Wed, Jul 15, 2020 at 5:22 AM Henk Smit  wrote:
>
> Huaimo Chen wrote on 2020-07-14 06:09:
>
> >  2). IS-IS TTZ abstracts a zone to a single node. A zone is any target
> > block or piece of an IS-IS area, which is to be abstracted. This seems
> > more flexible and convenient to users.
>
> I don't agree that this convenience is really beneficial.
>
> I actually think this convenience is a downside.
>
>
>
> I actually think not  having more configuration across the network to
> enable a new feature is more useful even if
>
> you don't do this operation every single day (especially if you want to
> roll back).
>
>
>
>
>
> Link-state protocols are not easy to understand. And we already
> have the misfortune that IS-IS and OSPF use different names for things.
> Adding the new concept of a "zone", while we already have the
> concept of an area makes things only more complex.
>
>
>
> Agree in general.
>
>
>
> I would say this is no more complex than what has been adopted already or
> the slew of proposals we have been seeing here.
>
>
>
> I too think as some other said we should have ideally adopted only one
> proposal by merging whatever possible.
>
> As  that is not the case and 2 parallel proposals have already been
> accepted as WG experimental track, and given the interest/support on this
> particular topic
>
> I would think it's reasonable to continue this experiment in IS-IS too as
> is done in OSPF.
>
>
>
> I think that the two proposals that have already been adopted as
> experimental are VERY different in the way they solve the problem of better
> LSDB scalability across an IS-IS routing domain.
>

You are right, of course. IS-IS TTZ draft focuses on abstracting a zone
(i.e., block) of an IS-IS area to a single node.

RFC 8099 is for abstracting a zone of an OSPF area to its edges full mesh.
So, afais, IS-IS TTZ is much better than RFC 8099 regarding improving
network scalability.


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

Thanks for pointing this;


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

I would leave this to folks who want to deploy, if these advantages matter
for them or not matter much.

Thank you!

--
Uma C.


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

Re: [Lsr] Request WG adoption of TTZ

[Uma Chunduri]

Dear Chris,


On Sat, Jul 11, 2020 at 4:44 AM Christian Hopps  wrote:

>
>
> > On Jul 10, 2020, at 7:07 PM, Uma Chunduri  wrote:
> >
> >  I would support the IS-IS TTZ solution for WG adoption.
> >
> > Of course, obviously not with OSPF encodings or concepts only relevant
> to OSPF (thx for the updated version).
> > Thanks for the good work which was started way back on TTZs with OSPF
> protocol first (RFC 8099).
>
> Has RFC8099 been deployed by anyone?
>

The simple answer is I don't know. I would let the authors of 8099 speak up
who might know about the deployment status and how this experimental RFC
helped.

I also believe this question is more relevant if there is a BIS document
for the same as discussed in the list for further enhancements and
possible deployment experience (as it's possible who is using this and
might not be active here).

--
Uma C.


> I would be very interested in hearing from operators who have experience
> with TTZ since RFC8099 has been around for over 3 years now.
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Request WG adoption of TTZ

[Uma Chunduri]

On Wed, Jul 15, 2020 at 5:22 AM Henk Smit  wrote:

> Huaimo Chen wrote on 2020-07-14 06:09:
>
> >  2). IS-IS TTZ abstracts a zone to a single node. A zone is any target
> > block or piece of an IS-IS area, which is to be abstracted. This seems
> > more flexible and convenient to users.
>
> I don't agree that this convenience is really beneficial.
>
I actually think this convenience is a downside.
>

I actually think not  having more configuration across the network to
enable a new feature is more useful even if
you don't do this operation every single day (especially if you want to
roll back).


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

Agree in general.

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

I too think as some other said we should have ideally adopted only one
proposal by merging whatever possible.
As  that is not the case and 2 parallel proposals have already been
accepted as WG experimental track, and given the interest/support on this
particular topic
I would think it's reasonable to continue this experiment in IS-IS too as
is done in OSPF.

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

Re: [Lsr] Request WG adoption of TTZ

[Uma Chunduri]

 I would support the IS-IS TTZ solution for WG adoption.


Of course, obviously not with OSPF encodings or concepts only relevant to
OSPF (thx for the updated version).

Thanks for the good work which was started way back on TTZs with OSPF
protocol first (RFC 8099).


I will send my specific comments/suggestions a bit later.

--

Uma C.



On Thu, Jun 18, 2020 at 8:38 PM Huaimo Chen 
wrote:

> Hi Chris and Acee, and everyone,
>
>
>
> I would like to request working group adoption of
> "Topology-Transparent Zone"
>
> (TTZ for short) https://datatracker.ietf.org/doc/draft-chen-isis-ttz/ .
>
>
> This draft comprises the following solutions for helping to improve
> scalability:
>
> 1) abstracting a zone to a single pseudo node in IS-IS,
>
> 2) abstracting a zone to a single pseudo node in OSPF,
>
> 3) abstracting a zone to zone edges' full mess in IS-IS, and
>
> 4) transferring smoothly between a zone and a single pseudo node.
>
> A zone is a block of an area (IS-IS L2 or L1 area, OSPF backbone or
>
> non-backbone area).
>
>
>
> When a network area becomes (too) big, we can reduce its size in the
> sense
>
> of its LSDB size through abstracting a zone to a single pseudo node or
>
> abstracting a few zones to a few pseudo nodes.
>
>
>
> While a zone is being abstracted (or transferred) to a single pseudo
> node,
>
> the network is stable. There is no or minimum service interruption.
>
>
>
> After abstracting a few zones to a few pseudo nodes, if we want to
> reconstruct
>
> them, we can transfer (or roll) any of the pseudo nodes back to its zone
> smoothly
>
> with no or minimum service interruption.
>
>
>
> We had a prototype implementation of abstracting a zone to zone
> edges' full
>
> mess in OSPF. The procedures and related protocol extensions for
> transferring
>
> smoothly from a zone to zone edges' full mess are implemented and tested.
>
> A zone (block of an OSPF area) is smoothly transferred to its edges’ full
> mess
>
> without any routing disruptions. The routes on every router are stable
> while
>
> the zone is being transferred to its edges' mess. It is very easy to
> operate
>
> the transferring.
>
>
>
> There are two other drafts for improving scalability: "Area Proxy for
> IS-IS"
>
> (Area Proxy for short) and "IS-IS Flood Reflection" (Flood Reflection for
> short).
>
>
>
> "Area Proxy"
> https://tools.ietf.org/html/draft-li-lsr-isis-area-proxy-03
>
> abstracts an existing IS-IS L1 area to a single pseudo node.
>
>
>
> "Flood Reflection"
> https://tools.ietf.org/html/draft-przygienda-lsr-flood-reflection-01
>
> abstracts an existing IS-IS L1 area to its edges' connections via one or
> more
>
> flood reflectors.
>
>
>
> We believe that TTZ has some special advantages even though
>
> Area Proxy and Flood Reflection are very worthy. We would like
>
> to ask for working group adoption of TTZ.
>
>
>
> Best Regards,
>
> Huaimo
> ___
> 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] LSR meeting comment on draft-acee-lsr-ospf-transport-instance

[Uma Chunduri]

Dear Authors,

Just want to quickly clarify my comment today on this draft.

We know there was a significant discussion many years ago when similar work
was done during  RFC 6822 (ISIS-MI) and RFC 6823 (GenInfo).  The usefulness
of this is evident with the more recent publication
https://datatracker.ietf.org/doc/rfc8202/. I am certainly not in the group
and would not question 'why' this is needed in OSPF.

However, section 3.1 use cases are difficult to understand and quite
frankly either through the reference (ETSI-WP28-MEC) or the cases listed.
As long as there is overlay in those networks (with the 3GPP preferred
option expanded rapidly for multiple interfaces beyond N9, F1, W1 etc after
REL16+) the usefulness of this core network and application info into the
underlay and routing layer is limited and even more so for UEs.

So please either expand the use case (sec 3.1) to see how this is
applicable or leave it out for future scenarios.

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