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

[Uma Chunduri <[e-mail]>]

Les,

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