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

[Hannes Gredler <[e-mail]>]

hi les,

<wg-chair hat off>

On Sat, Feb 27, 2016 at 05:18:39PM +0000, Les Ginsberg (ginsberg) wrote:
|    From my POV the draft currently defines how to advertise new
|    information without defining why it is necessary to do so.

agree - "discovery of tunnel endpoints" should be explicitly spelled out.

| 
|    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. Knowing that the
|    endpoint is capable of supporting RLFA is insufficient. Further, folks
|    (including you if I recall correctly) have indicated that they want
|    more than just knowing RLFA capability - they also want to know what
|    endpoint address to use. 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.

guess the RLFA example refers to non-MPLS (IP-only deployments)

|    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.

IMO the generic ability to discover tunnel-endpoints is something
desireable. agreed that the actual use-cases should be (better) documented 
somewhere (perhaps in RTGWG ?), but we can do that after WG adoption as
well.

- or is it that you want to make a case that discovery of tunnel
endpoints is not desired at all ?

/hannes

|    From: Uma Chunduri [mailto:[e-mail]]
|    Sent: Friday, February 26, 2016 12:09 PM
|    To: Uma Chunduri; Les Ginsberg (ginsberg); Christian Hopps;
|    [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 [[1]mailto:[e-mail]] On Behalf Of Uma
|    Chunduri
|    Sent: Thursday, January 14, 2016 4:51 PM
|    To: Les Ginsberg (ginsberg); Christian Hopps; [2][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 [[3]mailto:[e-mail]] On Behalf Of Les
|    Ginsberg (ginsberg)
|    Sent: Tuesday, January 12, 2016 5:25 PM
|    To: Christian Hopps; [4][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 [[5]mailto:[e-mail]] On Behalf Of
|    Christian Hopps
|    Sent: Monday, November 30, 2015 11:45 PM
|    To: [6][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:
| 
| 
|    [7]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.
| 
| References
| 
|    1. mailto:[e-mail]
|    2. mailto:[e-mail]
|    3. mailto:[e-mail]
|    4. mailto:[e-mail]
|    5. mailto:[e-mail]
|    6. mailto:[e-mail]
|    7. https://datatracker.ietf.org/doc/draft-xu-isis-encapsulation-cap/

| _______________________________________________
| Isis-wg mailing list
| [e-mail]
| https://www.ietf.org/mailman/listinfo/isis-wg