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

[Xuxiaohu <[e-mail]>]

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:[e-mail]] On Behalf Of Uma Chunduri
> Sent: Thursday, April 28, 2016 8:03 AM
> To: Les Ginsberg (ginsberg); Marc Binderberger; Hannes Gredler
> Cc: Christian Hopps; [e-mail] 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:[e-mail]]
> Sent: Sunday, February 28, 2016 9:34 PM
> To: Marc Binderberger; Hannes Gredler; Uma Chunduri
> Cc: [e-mail] 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:[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-c
> > >> | ap/
> > >> |
> > >> |
> > >> |    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