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

[Xuxiaohu <[e-mail]>]

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

> -----Original Message-----
> From: Isis-wg [mailto:[e-mail]] On Behalf Of Hannes Gredler
> Sent: Monday, February 29, 2016 4:21 PM
> To: Les Ginsberg (ginsberg)
> Cc: [e-mail] list; Christian Hopps
> Subject: Re: [Isis-wg] WG Adoption Call for draft-xu-isis-encapsulation-cap
> 
> hi les,
> 
> On 2/27/16 19:28, 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.
> 
> 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
> 
> >
> >> -----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