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

From: Uma Chunduri <[email-masked]>
Date: Fri, 26 Feb 2016 20:08:40 +0000

Dear Les et. al,

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

--
Uma C.

From: Isis-wg [mailto:[email-masked]] On Behalf Of Uma Chunduri
Sent: Thursday, January 14, 2016 4:51 PM
To: Les Ginsberg (ginsberg); Christian Hopps; [email-masked] 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:[email-masked]] On Behalf Of Les Ginsberg (ginsberg)
Sent: Tuesday, January 12, 2016 5:25 PM
To: Christian Hopps; [email-masked]<mailto:[email-masked]> 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:[email-masked]] On Behalf Of Christian Hopps
Sent: Monday, November 30, 2015 11:45 PM
To: [email-masked]<mailto:[email-masked]> 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.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sat, 27 Feb 2016 17:18:39 +0000

Uma -

>From my POV the draft currently defines how to advertise new information without defining why it is necessary to do so.

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.

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:[email-masked]]
Sent: Friday, February 26, 2016 12:09 PM
To: Uma Chunduri; Les Ginsberg (ginsberg); Christian Hopps; [email-masked] list
Subject: RE: [Isis-wg] WG Adoption Call for draft-xu-isis-encapsulation-cap

Dear Les et. al,

--
Uma C.

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

Les,

    Les

Hi Folks,

Thanks,
Chris.

---

From: Hannes Gredler <[email-masked]>
Date: Sat, 27 Feb 2016 18:51:34 +0100

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

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

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sat, 27 Feb 2016 18:28:10 +0000

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:[email-masked]]
> Sent: Saturday, February 27, 2016 9:52 AM
> To: Les Ginsberg (ginsberg)
> Cc: Uma Chunduri; Christian Hopps; [email-masked] list
> IMO the generic ability to discover tunnel-endpoints is something desireable.
> agreed that the actual use-cases should be (better) documented
> - or is it that you want to make a case that discovery of tunnel endpoints is
> not desired at all ?
> 
> /hannes
> 
> |    7.
> | https://datatracker.ietf.org/doc/draft-xu-isis-encapsulation-cap/
>

---

From: Marc Binderberger <[email-masked]>
Date: Sun, 28 Feb 2016 19:43:14 -0800

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 :-)

> somewhere (perhaps in RTGWG ?), but we can do that after WG adoption as

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:
> 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
> 
> 
>> desireable.
> _______________________________________________
> Isis-wg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isis-wg
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 29 Feb 2016 05:33:47 +0000

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

> From: Marc Binderberger [mailto:[email-masked]]
> Sent: Sunday, February 28, 2016 7:43 PM
> To: Les Ginsberg (ginsberg); Hannes Gredler; Uma Chunduri
> Cc: [email-masked] list; Christian Hopps

---

From: Uma Chunduri <[email-masked]>
Date: Mon, 29 Feb 2016 06:51:35 +0000

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:[email-masked]]
Sent: Saturday, February 27, 2016 9:19 AM
To: Uma Chunduri; Christian Hopps; [email-masked] 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:[email-masked]]
Sent: Friday, February 26, 2016 12:09 PM
To: Uma Chunduri; Les Ginsberg (ginsberg); Christian Hopps; [email-masked]<mailto:[email-masked]> list
Subject: RE: [Isis-wg] WG Adoption Call for draft-xu-isis-encapsulation-cap

Dear Les et. al,

--
Uma C.

Les,

    Les

Hi Folks,

Thanks,
Chris.

---

From: Uma Chunduri <[email-masked]>
Date: Mon, 29 Feb 2016 07:08:14 +0000

Hannes,

Thanks for your comments.

Hannes, 

Thanks.

In-line [Uma]:

--
Uma C.

...
|Further, folks

[Uma]: Precisely.

---

From: Uma Chunduri <[email-masked]>
Date: Mon, 29 Feb 2016 07:18:20 +0000

Les,

        >Discovery of tunnel endpoints is not what this draft is about.

[Uma]: Discovering tunnel-endpoint is beyond the scope of this document.
              Let me give you 2 examples.

1.      In-line loop free alternate application like RLFA:  Each IS-IS node capable of RLFA with provisioned  protection requirements (Link/node/SRLG) would compute
        Tunnel-endpoints (PQ-node/Repair node) so that packets can be encapsulated to that end point  to reach the eventual destination. So, here discovering  the loop free  tunnel end point is described in  RFC 7490 - https://tools.ietf.org/html/rfc7490 .
               2. For segment routing:  If an immediate neighbor doesn't support SR (no SRGB), the advertising node's node SID can't  be used to compute the outgoing label. In this        case your tunnel endpoint is the node which advertises the node SID (nothing to discover). Here, knowing the egress node decapsulating capabilities through this
           draft help encapsulating packets to the end point (node  which advertised the node-SID). This is clearly explained in
                     https://tools.ietf.org/html/draft-xu-spring-islands-connection-over-ip-04   (this has been referred in section-1 of the draft)

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

[Uma]: I can't begin to comprehend  on how to respond here...

        A. This is draft just advertises the decapsulation capabilities and associated parameters for particular tunnel types.
                B.  "discovering tunnel-endpoints" is done differently for each application differently as referred in section-1 and it's out of the
                       scope for this document as explained above.

--
Uma C.

---

From: Uma Chunduri <[email-masked]>
Date: Mon, 29 Feb 2016 07:41:09 +0000

Hi Marc,

Thanks for your review of the draft and comments below.
Comments in-line [Uma]:

--
Uma C.

-----Original Message-----
From: Marc Binderberger [mailto:[email-masked]] 
Sent: Sunday, February 28, 2016 7:43 PM
To: Les Ginsberg; Hannes Gredler; Uma Chunduri
Cc: [email-masked] list; Christian Hopps
Subject: Re: [Isis-wg] WG Adoption Call for draft-xu-isis-encapsulation-cap

desireable.

[Uma]:  As just replied (http://www.ietf.org/mail-archive/web/isis-wg/current/msg04509.html ) discovering tunnel end points depends on the application and it's beyond the scope of this document.

          Zone 1            Zone 2              Zone 3

[Uma]:   If R2's immediate  neighbor is not capable of MPLS/SR for example R2 is your ingress and R4 is your egress. In one use case, R2 uses the signaled decapsulation 
                capabilities of R4 and 	with its associated  parameters as specified in this draft to encapsulate packets to R4.
	Hope this clarifies.  
	Section-1 references multiple applications. For a quick use case, I would suggest to go through one of the reference in section-1 for example 
               https://tools.ietf.org/html/draft-xu-spring-islands-connection-over-ip-04 

               Perhaps the title of the draft should be draft-xu-isis-encapsulation-cap ==> raft-xu-isis-decapsulation-cap! 
               This is been discussed in IETF92/93 while this draft was presented and subsequently title was changed on 05 version (but not the draft name).

---

From: Hannes Gredler <[email-masked]>
Date: Mon, 29 Feb 2016 09:20:53 +0100

hi les,

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

agreed - IP prefix info is missing ...
i can see two ways to fix this:

1. explicitly state that the tunnel-encaps-cap refers to a particular
    IP prefix
2. move the tunnel-encaps-cap underneath an IP prefix TLV

we should be good the, right ?

/hannes

---

From: Xuxiaohu <[email-masked]>
Date: Mon, 29 Feb 2016 09:06:50 +0000

Hi Hannes and Les,

The End Point sub-TLV as described in Section 5.3 is just used to indicate the tunnel endpoint address(es).

Best regards,
Xiaohu

> From: Isis-wg [mailto:[email-masked]] On Behalf Of Hannes Gredler
> Sent: Monday, February 29, 2016 4:21 PM
> Discovering tunnel endpoints obviously is useful - as is identifying endpoint
> addresses - but this draft will help us do neither.
> 
> >> somewhere (perhaps in RTGWG ?), but we can do that after WG adoption
> >> as well.
> >>
> >> | [7]https://datatracker.ietf.org/doc/draft-xu-isis-encapsulation-cap
> >> | /
> >> |
> >> |

---

From: Marc Binderberger <[email-masked]>
Date: Mon, 29 Feb 2016 02:42:08 -0800

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:
> 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
> 
>> as
>> as
>>>> endpoints
>>>> is
>>>> |    It is clear that the information is not at all useful to IS-IS 
>>>> itself
>>>> -

---

From: Philip Christian <[email-masked]>
Date: Mon, 29 Feb 2016 11:30:18 +0000

Please can people explain how

might fit in with, or cause problems with this

https://tools.ietf.org/html/draft-ietf-isis-auto-encap-03

which was adopted by the ITU-T and appears to be still very much part of 
IT-T G.7712.
The PDF of that document is available here

https://www.itu.int/rec/T-REC-G.7712-201009-I/en

and you probably want to go to page 46.

or it is defining something entirely different?

The ITU-T version defines an "Encapsulation capability TLV" with code 16 
decimal, whereas draft-xu-isis-encapsulation-cap says "routers 
advertises their supported encapsulation type(s) by advertising a new 
sub-TLV of the IS-IS Router CAPABILITY TLV"

is it dangerous to have two mechanisms to advertise the same thing?

also it seems a shame when TLV 16 is already defined as using subTLVs 
and so could easily be used for the new purposes that 
xu-isis-encapsulation-cap suggests.

Apologies if I have misunderstood something; I have been away from this 
for a long time.

regards, Philip Christian

On 01/12/15 03:53, Shah, Himanshu wrote:
> /You are right the hyperlink is WRONG../
>
> //
>
> /I support
> https://datatracker.ietf.org/doc/draft-xu-isis-encapsulation-cap/   (the
> right link)/
>
> //
>
> /Thanks,/
>
> /Himanshu/
>
> //
>
> *From:*Isis-wg [mailto:[email-masked]] *On Behalf Of *Wunan (Eric)
> *Sent:* Monday, November 30, 2015 10:21 PM
> *To:* Christian Hopps; [email-masked] list
> *Subject:* Re: [Isis-wg] WG Adoption Call for
> draft-xu-isis-encapsulation-cap
>
> Hi Chris,
>
> Is it only for me or other people also same that I was redirected to
> auto-cfg draft using link below? Or this is the implication for your
> crush on that draft?J
>
> Anyway, I think the scenario described in [5512] is still valid in IS-IS
> networks and It would be useful, so I support it.
>
> Regards
>
> Eric
>
> *发件人**:*Christian Hopps [mailto:[email-masked]]
> *发送时间:* 2015年11月27日 22:35
> *收件人:* [email-masked] <mailto:[email-masked]> list
> *主题:* [Isis-wg] WG Adoption Call for draft-xu-isis-encapsulation-cap
>
> Hi Folks,
>
> <https://datatracker.ietf.org/doc/draft-liu-isis-auto-conf/>
>

---

From: Xuxiaohu <[email-masked]>
Date: Tue, 1 Mar 2016 01:58:01 +0000

Hi Marc,

> From: Isis-wg [mailto:[email-masked]] On Behalf Of Marc
> Binderberger
> Sent: Monday, February 29, 2016 6:42 PM
> Cc: Christian Hopps; [email-masked] list
> 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, RFC5512 is more applicable in the case where tunnels are used within a single administrative domain rather than across multiple administrative domains. Of course, a single administrative domain could consist of multiple ASes.

BTW, RFC5512 is to be replaced by https://tools.ietf.org/html/draft-ietf-idr-tunnel-encaps-01. It said clearly in the latter draft that 

"10.  Scoping

   The Tunnel Encapsulation attribute is defined as a transitive
   attribute, so that it may be passed along by BGP speakers that do not
   recognize it.  However, it is intended that the Tunnel Encapsulation
   attribute be used only within a well-defined scope, e.g., within a
   set of Autonomous Systems that belong to a single administrative
   entity.  If the attribute is distributed beyond its intended scope,
   packets may be sent through tunnels in a manner that is not intended."

In other words, it's desirable to automatically discover the tunnel encapsulation capability in a single administrative domain.

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

Let me give you an example, you have 100 nodes in a single administrative domain, do you want to configure on each of them the encapsulation capability of the other 99 nodes?  And when you add one router to the administrative domain, do you hope to configure the tunnel encapsulation capability of that new router on those 100 routers?

> 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

Manual configuration is workable. However, it would be more convenient if the tunnel encapsulation capability could be automatically discovered.

Best regards,
Xiaohu

> >>>> |    [It seems due to some sneaky cut and paste error, the URL was
> wrong
> >> in