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

From: Xuxiaohu <[email-masked]>
Date: Wed, 4 May 2016 07:57:01 +0000

I think Uma's explanation is clear and reasonable. Les, would you please explain how to use admin tags to achieve the same goal of encapsulation cap sub-TLV (i.e., advertise the encapsulation capability of tunnel egress nodes)? 

Best regards,
Xiaohu

> -----Original Message-----
> From: Isis-wg [mailto:[email-masked]] On Behalf Of Uma Chunduri
> Sent: Thursday, April 28, 2016 8:03 AM
> To: Les Ginsberg (ginsberg); Marc Binderberger; Hannes Gredler
> Cc: Christian Hopps; [email-masked] list
> Subject: Re: [Isis-wg] WG Adoption Call for draft-xu-isis-encapsulation-cap
> 
> It's been notified that this particular mail below is not responded to. Let me
> re-clarify some of the points discussed on this topic.
> In-line [Uma]:
> --
> Uma C.
> 
> 
> -----Original Message-----
> From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
> Sent: Sunday, February 28, 2016 9:34 PM
> To: Marc Binderberger; Hannes Gredler; Uma Chunduri
> Cc: [email-masked] list; Christian Hopps
> Subject: RE: [Isis-wg] WG Adoption Call for draft-xu-isis-encapsulation-cap
> 
> 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,
> 
> [Uma]: Each node has to advertise what de/encapsulation capabilities it can
> support. It does not need to advertise all the listed capabilities in the draft.
> Tunnel type sub-tlv  has a new registry and I am not quite sure what's the
> concern here with advertisement space.
> 
> will require more config knobs to control what is advertised,
> 
> [Uma]: Much more configuration is required if we were to provision all potential
> egress end points that can be possible from ingress pov. Here the only
> configuration knob needed is supported encapsulation capabilities and an
> operator  preference (it seems this was discussed at last IETF offline).
> 
> and won't tell us anything that we could not determine using existing
> infrastructure and/or additional use of admin tags.
> 
> [Uma]: I don't see how one can use admin tags to specify associated tunnel
> parameters through tags and this has been discussed multiple times on this
> thread.
> 
>    Les
> 
> > -----Original Message-----
> > 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
> > 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:[email-masked]]
> > >> Sent: Saturday, February 27, 2016 9:52 AM
> > >> To: Les Ginsberg (ginsberg)
> > >> Cc: Uma Chunduri; Christian Hopps; [email-masked] 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:[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-c
> > >> | ap/
> > >> |
> > >> |
> > >> |    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
> > >
> > > _______________________________________________
> > > Isis-wg mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/isis-wg
> > >
> 
> _______________________________________________
> Isis-wg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isis-wg

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 6 May 2016 17:53:05 +0000

Using admin tags for this is easy. One possible config is:

"rlfa tag 100"

This indicates that any endpoint address advertised with tag 100 can be used for the specified technology ("rlfa" in this example).

The receiver of such an advertisement then knows two things about the advertising node:

1)It supports the tunnel type
2)It wants the specified address to be used as the tunnel endpoint

   Les

> From: Xuxiaohu [mailto:[email-masked]]
> Sent: Wednesday, May 04, 2016 12:57 AM
> To: Uma Chunduri; Les Ginsberg (ginsberg); Marc Binderberger; Hannes
> Gredler
> I think Uma's explanation is clear and reasonable. Les, would you please
> explain how to use admin tags to achieve the same goal of encapsulation cap
> sub-TLV (i.e., advertise the encapsulation capability of tunnel egress nodes)?
> 
> Best regards,
> Xiaohu
> 
> > It's been notified that this particular mail below is not responded
> > to. Let me re-clarify some of the points discussed on this topic.
> > In-line [Uma]:
> > --
> > Uma C.
> >
> >
> > 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,
> >
> > [Uma]: Each node has to advertise what de/encapsulation capabilities
> > it can support. It does not need to advertise all the listed capabilities in the
> draft.
> > Tunnel type sub-tlv  has a new registry and I am not quite sure what's
> > the concern here with advertisement space.
> >
> > [Uma]: Much more configuration is required if we were to provision all
> > potential egress end points that can be possible from ingress pov.
> > Here the only configuration knob needed is supported encapsulation
> > capabilities and an operator  preference (it seems this was discussed at last
> IETF offline).
> >
> > [Uma]: I don't see how one can use admin tags to specify associated
> > tunnel parameters through tags and this has been discussed multiple
> > times on this thread.
> >
> >    Les
> >
> > > 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.
> > >
> > >
> > > tunnel encapsulations - otherwise the draft may not be necessary.
> > > For the start Node
> > > I'm guessing that the draft does not differentiate between egress
> > > and ingress tunnel capability, i.e. if you support tunnel X you can
> > > 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.?
> > >
> > >
> > > > 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
> > > >
> > > >
> > > >> |    Yes, multiple tunnel types may be in use in the network -
> > > >> | that does
> > > >> not
> > > >> |    types . In most cases, the support of a given tunnel type
> > > >> | can be
> > known
> > > >> |    more than just knowing RLFA capability - they also want to
> > > >> | know
> > what
> > > >> |    be done BEFORE this becomes a WG document as - almost
> > > >> | without
> > > >> exception
> > > >> |    tunnel types which might be used in a network but does not
> > > >> | offer an
> > y
> > > >> |    node; as asymmetric connections can be made dynamically
> > > >> | based on
> > > the
> > > >> |    network topology; using the tunnel capabilities or
> > > >> | parameters of
> > > >> egress
> > > >> |    node  from ingress.
> > > >> |
> > > >> |
> > > >> |    supported and capabilities that are being advertised by an
> > > >> | egress
> > node
> > > >> |    It is clear that the information is not at all useful to
> > > >> | IS-IS itself
> > > >> -
> > > >> |    [It seems due to some sneaky cut and paste error, the URL
> > > >> | was wrong
> > > in
> > > >> | [7]https://datatracker.ietf.org/doc/draft-xu-isis-encapsulation
> > > >> | -c
> > > >> | ap/
> > > >> |
> > > >> |
> > > >> | https://datatracker.ietf.org/doc/draft-xu-isis-encapsulation-ca
> > > >> | p/
> > > >>

---

From: Uma Chunduri <[email-masked]>
Date: Fri, 6 May 2016 20:01:36 +0000

Les,

        >2)It wants the specified address to be used as the tunnel endpoint

[Uma]: But this will not give any information if that particular tunnel type needs some parameters  of the sender at the receiver.
              Say for L2TPv3 Over IP, Session ID and optional Cookie and for GRE, you need GRE Key in some cases, for IPSec tunnel mode options etc.
             Some more tunnel specific information need to be exchanged is specified in Section 5 of the current version of the draft.
            I don't see a way tags help here and I alluded this on this thread and earlier.

--
Uma C.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 9 May 2016 08:36:19 +0000

Uma -

First of all, I answered the question that was asked. :)

As regards additional tunnel parameters, you are correct that for some tunnel types there are additional parameters required - and both Marc and I have acknowledged this earlier in the thread. However, many of the use cases cited in the draft Introduction do not require additional parameters to be advertised i.e. use of admin tags as I have described would be sufficient - so this lessens the strength of your argument.

My position is that:

a)The additional advertisements themselves require local configuration to control what is advertised - so at least some of the potential config savings you hope for is reduced by the need to configure what is advertised (IS-IS itself knows nothing about tunnel encaps)
b)You are using the IGP as a transport for configuration information - not the direction I would like to see us go in general
c)From a real world deployment standpoint it would be helpful to have validation that this proposal solves a real problem - not just a theoretical one. In doing so you need to consider that admin tags suffice for many use cases.

Hope this clarifies things - even if we still do not agree.

   Les

From: Uma Chunduri [mailto:[email-masked]]
Sent: Friday, May 06, 2016 1:02 PM
To: Les Ginsberg (ginsberg); Xuxiaohu; Marc Binderberger; Hannes Gredler
Cc: Christian Hopps; [email-masked] list
Subject: RE: [Isis-wg] WG Adoption Call for draft-xu-isis-encapsulation-cap

Les,

--
Uma C.

---

From: Xuxiaohu <[email-masked]>
Date: Mon, 9 May 2016 09:10:37 +0000

Hi Les,

In your example, how could the receiver know what type of tunnel technology is supported by the originator? In other words, how could the receiver know what tunnel type a given tag indicates? Are you planning to configure mappings between tags and tunnel types on each routers? If so, it seems error-prone and an unnecessary burden on network operators.

Best regards,
Xiaohu

From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Monday, May 09, 2016 4:36 PM
To: Uma Chunduri; Xuxiaohu; Marc Binderberger; Hannes Gredler
Cc: Christian Hopps; [email-masked] list
Subject: RE: [Isis-wg] WG Adoption Call for draft-xu-isis-encapsulation-cap

Uma -

My position is that:

   Les

Cc: Christian Hopps; [email-masked]<mailto:[email-masked]> list

Les,

--
Uma C.