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

[Marc Binderberger <[e-mail]>]

Hello everyone,

Uma, thanks for the replies and clarifications. After reading them and 
looking again at RFC5512 I understand better. But I also understand Les 
better ;-)


IMHO even RFC5512 is uber-engineered but for BGP I can at least think of one 
case where you need a dynamic learning of tunnel parameters (route servers, 
where you have peerings without explicitly configuring them).

For IS-IS, which is under one administrative domain, having a manual config 
that maps administrative tags to a tunnel config seems reasonable. At the end 
how many tunnel types would one have in the whole network? One, maybe two. 
(Three gets you a call from the Ops manager)


I guess it is more convenient (or we are more used to) defining new TLVs than 
defining what seems an implementation aspect - that IS-IS is able to map 
admin tags to a tunnel forward behaviour.  But is it useful?  My guess is 
implementations do the minimum as mentioned in section 3 of 
draft-xu-spring-islands-connection-over-ip:

   As for which tunnel encapsulation type should be used by X, it can be
   manually specified on X or learnt from Y's advertisement [...]

I.e. they use a manual configuration. Maybe we should consider defining this 
first, so we can build simple, interoperable implementations?


Regards, Marc




On Mon, 29 Feb 2016 05:33:47 +0000, Les Ginsberg (ginsberg) wrote:
> Let me try to clarify my concerns...
> 
> To use a tunnel endpoint you have to know it is reachable (IP/IPv6 
> Reachability TLVs already do this), you have to know it is reachable using 
> the underlying tunnel transport (implementations today get this from 
> internal communication (e.g. LDP), and you need to know it is the address 
> of choice. For the last, admin tag is a much more efficient means of 
> advertising this. For the first two this draft does not add value.
>  
> In summary, I think what is proposed in this draft  is bloating the 
> advertisement space, will require more config knobs to control what is 
> advertised, and won't tell us anything that we could not determine using 
> existing infrastructure and/or additional use of admin tags.
> 
>    Les
> 
>> -----Original Message-----
>> From: Marc Binderberger [mailto:[e-mail]]
>> Sent: Sunday, February 28, 2016 7:43 PM
>> To: Les Ginsberg (ginsberg); Hannes Gredler; Uma Chunduri
>> Cc: [e-mail] list; Christian Hopps
>> Subject: Re: [Isis-wg] WG Adoption Call for draft-xu-isis-encapsulation-cap
>> 
>> 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
>>> 
> 
> _______________________________________________
> Isis-wg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/isis-wg
>