Re: [Isis-wg] WG Adoption Call for draft-xu-isis-encapsulation-cap

[Uma Chunduri <[e-mail]>]

Ok, couple of e-mails let me respond to clarify as much as I can.
In-line [Uma]:


--
Uma C.

From: Les Ginsberg (ginsberg) [mailto:[e-mail]]
Sent: Saturday, February 27, 2016 9:19 AM
To: Uma Chunduri; Christian Hopps; [e-mail] list
Subject: RE: [Isis-wg] WG Adoption Call for draft-xu-isis-encapsulation-cap

Uma -

>From my POV the draft currently defines how to advertise new information without defining why it is necessary to do so.
[Uma]: Why question has been answered in Section 1, see my subsequent responses...

Yes, multiple tunnel types may be in use in the network - that does not in and of itself lead to a requirement to advertise supported tunnel types . In most cases, the support of a given tunnel type can be known today by other means. You give the example of RLFA - but today LDP reachability to an endpoint is something a router already knows - and this is the real requirement to setup an RLFA tunnel.

[Uma]: Incorrect.
LDP/T-LDP tunnel is one variant to reach PQ node. RLFA computation is agnostic to the tunnel type to reach the computed PQ node; in pure IP deployments it's non-LDP based tunnel and as advertised by the node decapsulation capabilities as specified in this draft.

Knowing that the endpoint is capable of supporting RLFA is insufficient.
[Uma]:  No.  What is "supporting RLFA??" an egress node doesn't not need to support RLFA to decapsulate the packet (MPLS/IP etc..) and forward. Well, egress node can support RLFA to offer protection in the other direction (as an ingress node then).

Further, folks (including you if I recall correctly) have indicated that they want more than just knowing RLFA capability -
[Uma]:  What is "RLFA capability???"  there is nothing like RLFA capability I am aware of.

they also want to know what endpoint address to use.
[Uma]: By the above sentence I am trying to understand what you meant. Ok, if T-LDP tunnel were to be used to reach the computed PQ node, yes ingress node ought to know which IP address need to be used for establishing the targeted session. And for that we have mechanisms now.. there is more to it. But RLFA is  completely agnostic  to how to reach to the computed repair node and doesn't mandate you to use MPLS always.

This logically leads to the use of admin tags which will not only indicate support for the tunnel type but also what endpoint address is preferred/required.
[Uma]: Admin tag is insufficient in multiple levels as it can either say anything but decapsulation capabilities of the egress node much less its parameters (Destination address, GRE key etc..).

I think more thought and discussion is required before deciding that this is something that should be supported.
And I think this needs to be done BEFORE this becomes a WG document as - almost without exception - anything that becomes a WG document proceeds to become an RFC.


   Les


From: Uma Chunduri [mailto:[e-mail]]
Sent: Friday, February 26, 2016 12:09 PM
To: Uma Chunduri; Les Ginsberg (ginsberg); Christian Hopps; [e-mail]<mailto:[e-mail]> list
Subject: RE: [Isis-wg] WG Adoption Call for draft-xu-isis-encapsulation-cap

Dear Les et. al,

Please post any further comments you might have on this document.

--
Uma C.

From: Isis-wg [mailto:[e-mail]] On Behalf Of Uma Chunduri
Sent: Thursday, January 14, 2016 4:51 PM
To: Les Ginsberg (ginsberg); Christian Hopps; [e-mail]<mailto:[e-mail]> list
Subject: Re: [Isis-wg] WG Adoption Call for draft-xu-isis-encapsulation-cap

Les,

Thanks for your comments, see in line [Uma]:
--
Uma C.

From: Isis-wg [mailto:[e-mail]] On Behalf Of Les Ginsberg (ginsberg)
Sent: Tuesday, January 12, 2016 5:25 PM
To: Christian Hopps; [e-mail]<mailto:[e-mail]> list
Subject: Re: [Isis-wg] WG Adoption Call for draft-xu-isis-encapsulation-cap

Apologies for the very late response on this...

I have a couple of concerns regarding taking on this work.

The draft is straightforward enough in terms of the protocol extensions defined, but I am not at all clear on the usefulness of the information being advertised. The introduction to the draft discusses a variety of tunnel types which might be used in a network but does not offer an y reason why advertising the tunnel types supported is of benefit.

[Uma]: Lot of use cases have been described where there is no configuration possible for all possible egress nodes at a given ingress node; as asymmetric connections can be made dynamically based on the network topology; using the tunnel capabilities or parameters of egress node  from ingress.

Given this information is only advertised within a single administrative domain it does not seem to provide any information that is not already known to the network operator.
[Uma]: This is not about whether network operators know all the information but it's about if it is possible to configure/manage

a.       all options supported by possible egress nodes from ingress nodes perspective or

b.      one option of all "possible" egress nodes from ingress nodes pov.

It also logically leads to requiring a configuration for what tunnel types to advertise. If this information is meant to drive automatic configuration of tunnels I presume that the network operator would want to limit what is advertised - not simply accept what the implementation is capable of supporting. So it seems we have simply traded one configuration for another.
[Uma]: I don't see, we have traded any configuration here. An in-line ingress application/feature  running as part of IS-IS ought to know what kind of tunnel capabilities the egress node is capable of accepting and associated parameters thereof for that tunnel.  Network operator can always limit enabling  capabilities that are being supported and capabilities that are being advertised by an egress node as part of ISIS through configuration.

I would like to see more detail on this before deciding whether it is worth doing.

It is clear that the information is not at all useful to IS-IS itself - which brings me to my second concern. This is advertising information that has nothing to with IS-IS. Router Capabilities is not meant to be used as a vehicle to advertise information not of direct use to the protocol.
[Uma]:  I am not sure why you see it is not all useful to IS-IS ; most of the features/applications listed in  section 1 are related to  ISIS protocols. For example RLFA- computation of PQ nodes done after primary SPF and as part of RLFA  SPFs (neighbor SPF, neighbors rSPF) and PQ nodes are computed dynamically on the current topology. It's not conceivable to provision an ingress node with one/all tunnel capabilities of egress nodes (essentially where ever this feature is enabled and potentially all eventually).  Similarly for Spring/Bier nodes dynamic tunnels can be supported based on the neighboring non-spring/non-bier node capabilities advertised.

In fact, the existence of a couple of exceptions to this guideline is what prompted the creation of GENAPP (RFC 6823) as the appropriate place to advertise such information.

I would like to see further discussion of the above before deciding that WG adoption (which almost always indicates an intent to progress to RFC) is appropriate.

    Les


From: Isis-wg [mailto:[e-mail]] On Behalf Of Christian Hopps
Sent: Monday, November 30, 2015 11:45 PM
To: [e-mail]<mailto:[e-mail]> list
Subject: Re: [Isis-wg] WG Adoption Call for draft-xu-isis-encapsulation-cap

[It seems due to some sneaky cut and paste error, the URL was wrong in the original email, I've corrected in this message]

Hi Folks,

The authors have requested the IS-IS WG adopt:

https://datatracker.ietf.org/doc/draft-xu-isis-encapsulation-cap/

as a working group document.

Please indicate support or no-support for taking on this work.

Thanks,
Chris.