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

[Marc Binderberger <[e-mail]>]

Hello Les, Hannes, Uma & IS-IS experts,

when I was reading the document for the first time I had a similar reaction: 
what is the actual problem this draft tries to solve?


> IMO the generic ability to discover tunnel-endpoints is something 
desireable.

that is a generic statement, so I agree :-)

> agreed that the actual use-cases should be (better) documented
> somewhere (perhaps in RTGWG ?), but we can do that after WG adoption as
> well.

That's where I have a problem. I prefer to have at least one use-case at the 
time when a proposal is under discussion. Looking at RFC5512 the Introduction 
chapter is more detailed. I'm not saying the list of "partial deployment of 
X" in the draft's section 1 is not convincing - but there are no details for 
at least one the items on the list.


E.g.: I assume that not every node in the IS-IS network support a tunnel 
encapsulations - otherwise the draft may not be necessary. For the start Node 
R1 to reach the end Node R4 and realizing there is an MPLS/BIER/IPvX gap in 
between, R1 must find an egress tunnel node R2. R2 needs to find an ingress 
tunnel node R3

          Zone 1            Zone 2              Zone 3
    R1 -----/.../---- R2 -----/.../------ R3 -----/.../---- R4
         has MPLS,         misses MPLS,        has MPLS,
         BIER, IPvX        BIER or IPvX        BIER, IPvX

(beware of proportional fonts - they are evil :-)


I'm guessing that the draft does not differentiate between egress and ingress 
tunnel capability, i.e. if you support tunnel X you can encapsulate and 
decapsulate. Fine with that - but it's nowhere mentioned.

Then there is the matter of borders, here between Zone 1 and 2, and between 
Zone 2 and 3. For RFC5512 this concept may be more natural as BGP is made for 
it. What are the expectations for IS-IS though? Do all routers bordering two 
zones need to be tunnel-capable?  Do we want to support a limited number of 
tunnel-capable border routers?  What impact does this have on the required 
TLV information, distribution etc.?


Long story short: I find it difficult to discuss the draft without more 
context. 


Regards, Marc 






On Sat, 27 Feb 2016 18:28:10 +0000, Les Ginsberg (ginsberg) wrote:
> Hannes -
> 
> Discovery of tunnel endpoints is not what this draft is about. 
> 
> I am saying that I do not see that announcing tunnel capabilities is 
> useful. Discovering tunnel endpoints obviously is useful - as is 
> identifying endpoint addresses - but this draft will help us do neither.
> 
>    Les
> 
> 
>> -----Original Message-----
>> From: Hannes Gredler [mailto:[e-mail]]
>> Sent: Saturday, February 27, 2016 9:52 AM
>> To: Les Ginsberg (ginsberg)
>> Cc: Uma Chunduri; Christian Hopps; [e-mail] list
>> Subject: Re: [Isis-wg] WG Adoption Call for draft-xu-isis-encapsulation-cap
>> 
>> 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
> 
> _______________________________________________
> Isis-wg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/isis-wg
>