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

From: Xuxiaohu <[email-masked]>
Date: Fri, 4 Mar 2016 08:15:48 +0000

Hi Les,

I wonder whether the End Point sub-TLV as described in Section 5.3 can address your concerns.

Best regards,
Xiaohu

> -----Original Message-----
> From: Xuxiaohu
> Sent: Monday, February 29, 2016 5:07 PM
> To: 'Hannes Gredler'; Les Ginsberg (ginsberg)
> Cc: [email-masked] list; Christian Hopps
> Subject: RE: [Isis-wg] WG Adoption Call for draft-xu-isis-encapsulation-cap
> 
> 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:[email-masked]] On Behalf Of Hannes
> > Gredler
> > Sent: Monday, February 29, 2016 4:21 PM
> > To: Les Ginsberg (ginsberg)
> > Cc: [email-masked] 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:[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

---

From: Hannes Gredler <[email-masked]>
Date: Fri, 4 Mar 2016 10:31:53 +0100

that sounds sufficient to me for tunnel end-point discovery;

/hannes

On 2/29/16 10:06, Xuxiaohu wrote:
> 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
>> Subject: Re: [Isis-wg] WG Adoption Call for draft-xu-isis-encapsulation-cap
>>
>> hi les,
>>
>> Discovering tunnel endpoints obviously is useful - as is identifying endpoint
>> addresses - but this draft will help us do neither.
>>
>>>> |    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
>>>> |    - anything that becomes a WG document proceeds to become an RFC.
>>>>
>>>> IMO the generic ability to discover tunnel-endpoints is something desireable.
>>>> somewhere (perhaps in RTGWG ?), but we can do that after WG adoption
>>>> as well.
>>>>
>>>> |    The draft is straightforward enough in terms of the protocol extensions
>>>> |    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.
>>>> |
>>>> |
>>>> |    administrative domain it does not seem to provide any information that
>>>> |    information but it's about if it is possible to configure/manage
>>>> |
>>>> |    configuration of tunnels I presume that the network operator would
>> want
>>>> |    to limit what is advertised - not simply accept what the implementation
>>>> |    supported and capabilities that are being advertised by an egress node
>>>> |    which brings me to my second concern. This is advertising information
>>>> |    protocols. For example RLFA- computation of PQ nodes done after
>>>> primary
>>>> |    what prompted the creation of GENAPP (RFC 6823) as the appropriate
>>>> |    that WG adoption (which almost always indicates an intent to progress
>>>> |    [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-cap
>>>> | /
>>>> |
>>>> |

---

From: Marc Binderberger <[email-masked]>
Date: Sun, 6 Mar 2016 12:56:30 -0800

Hello Xiaohu,

thanks for the detailed reply and my apology for the delay in response.

As I said, personally I think RFC5512 is "uber-engineered", i.e. they do more 
than the minimum they need to. I would actually disagree with the section 10 
you quoted from the new draft. For eBGP setups - peerings, VPNs with 
endpoints under customer control - I see a reason, that is when crossing 
administrative boundaries. But that's the BGP/IDR area and they solve 
different problems.

For IS-IS what I propose (and Les, if I understand him right :-) is not ...

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

... a manual configuration of the tunnel endpoints. What you configure are 
the parameters of a tunnel, except the endpoint address.

What is proposed is this:

(1) you configure your IS-IS to use tunnels, if needed. This knob should 
exist anyway, to give full control to the operator, even with your proposal.

(2) you configure: "administrative tag X means a GRE tunnel for IPv4, IPv6 
and MPLS over IPv4/v6". Preference/weight is W. Your own IP address for this 
is A.

You may add more tunnel technologies if needed.
What IS-IS does with the configuration is:

(a) announce A with an administrative tag of X
(b) if native forwarding is not possible, check if we are allowed to use 
tunnels and if the router on the other side of the zone announces an IP 
address A' with one of the configured administrative tags, e.g. X. If so, use 
a tunnel with the parameters as configured, source address A and destination 
address A' for forwarding.

In reality, as the number of vendors/platforms is limited, you won't have 
many of these config lines. Likely you will have one on all machines.

Even in your proposal I still would need something like (2) for 
administrative purpose:  you may restrict the tunnel technologies in use, 
because you know there is a bug or just to limit the operational burden. Or 
your GRE encaps is preferable as your ASIC does it in a single pass while 
VxLAN-gpe requires a 2nd loop; you offer/use both but you have a preference.

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

See above. To summarize:

* we are _not_ talking about configuring every tunnel manually when we say 
"use an administrative tag". The ability to use a tunnel is learned via IS-IS 
updates.

* we actually get the tunnel functionality with administrative tags, without 
adding new TLVs.

* For administrative purposes your proposal will end up with similar 
configurations. In your case to restrict/prefer, in the tag case to 
define/allow/prefer.

The tag proposal is following the idea of going with the least amount of 
protocol changes and that the operator ensures the necessary tunnel types are 
available/configured. Your proposal (and RFC5512) follows more the idea that 
things automagically work.

Regards, Marc

On Tue, 1 Mar 2016 01:58:01 +0000, Xuxiaohu wrote:
> Hi Marc,
>> From: Isis-wg [mailto:[email-masked]] On Behalf Of Marc
>> Binderberger
>> Sent: Monday, February 29, 2016 6:42 PM
>> To: Les Ginsberg; Hannes Gredler; Uma Chunduri
>> Cc: Christian Hopps; [email-masked] list
>> 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).
> 
> 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.
>> (Three gets you a call from the Ops manager)
> 
> 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?
> 
>> 
>> 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?
> 
> Manual configuration is workable. However, it would be more convenient if 
> the tunnel encapsulation capability could be automatically discovered.
> 
> Best regards,
> Xiaohu
> 
>> 
>> Regards, Marc
>> 
>> 
>> 
>> 
>> On Mon, 29 Feb 2016 05:33:47 +0000, Les Ginsberg (ginsberg) wrote:
>>> 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
>>>> 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?
>>>> 
>>>> 
>>>> that is a generic statement, so I agree :-)
>>>> 
>>>> 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 -
>>>>> 
>>>>> 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
>>>>> 
>>>>> 
>>>> as
>>>>>> well.
>>>>>> endpoints
>>>>>> is
>>>>>> not desired at all ?
>>>>>> |    being advertised. The introduction to the draft discusses a 
>>>>>> variety
>>>>>> of
>>>>>> |    It is clear that the information is not at all useful to IS-IS
>>>>>> itself
>>>>>> -
>>>>>> |    that has nothing to with IS-IS. Router Capabilities is not meant 
>>>>>> to
>>>>>> be
>> wrong
>>>>>> | [7]https://datatracker.ietf.org/doc/draft-xu-isis-encapsulation-cap/
>>>>>> |
>>>>>> |

---

From: Marc Binderberger <[email-masked]>
Date: Sun, 6 Mar 2016 17:24:53 -0800

Hello Philip,

that is interesting!

> or it is defining something entirely different?

I would say this is very much the same, with the only difference that the new 
draft is more about current protocol gaps and not so much about CLNP. But the 
principle seems the same.

> might fit in with, or cause problems with this
> https://tools.ietf.org/html/draft-ietf-isis-auto-encap-03
> https://www.itu.int/rec/T-REC-G.7712-201009-I/en
> is it dangerous to have two mechanisms to advertise the same thing?

Good question to the authors of the new draft. Do they want to go for an 
exclusive either-or?  Should IS-IS implementations be able to support both?

We should have known there is nothing really new under the sun (anymore) :-)

Regards, Marc

On Mon, 29 Feb 2016 11:30:18 +0000, Philip Christian wrote:
> Please can people explain how
> 
> https://datatracker.ietf.org/doc/draft-xu-isis-encapsulation-cap/
> 
> 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
>> 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,
>> 
>> The authors have requested the IS-IS WG adopt:
>> https://datatracker.ietf.org/doc/draft-xu-isis-encapsulation-cap/
>> <https://datatracker.ietf.org/doc/draft-liu-isis-auto-conf/>
>> 
>> as a working group document.
>> 
>> Please indicate support or no-support for taking on this work.
>> 
>> Thanks,
>> Chris.
>> 
>> 
>>

---

From: Xuxiaohu <[email-masked]>
Date: Tue, 8 Mar 2016 07:09:06 +0000

Hi Marc,

> Sent: Monday, March 07, 2016 4:57 AM
> To: Xuxiaohu
> Cc: Les Ginsberg; Hannes Gredler; Uma Chunduri; Christian Hopps;
> [email-masked] list
> administrative boundaries. But that's the BGP/IDR area and they solve different
> problems.
> 
> 
> > 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?
> 
> ... a manual configuration of the tunnel endpoints. What you configure are the
> parameters of a tunnel, except the endpoint address.
> 
> (1) you configure your IS-IS to use tunnels, if needed. This knob should exist
> anyway, to give full control to the operator, even with your proposal.
> 
> (2) you configure: "administrative tag X means a GRE tunnel for IPv4, IPv6 and
> MPLS over IPv4/v6". Preference/weight is W. Your own IP address for this is A.
> 
> (b) if native forwarding is not possible, check if we are allowed to use tunnels
> and if the router on the other side of the zone announces an IP address A' with
> one of the configured administrative tags, e.g. X. If so, use a tunnel with the
> parameters as configured, source address A and destination address A' for
> forwarding.
> 
> 
> In reality, as the number of vendors/platforms is limited, you won't have many
> of these config lines. Likely you will have one on all machines.
> 
> 

Your understanding is correct that this draft follows the idea of RFC5512. That's to say, it allows automatical discovery of the tunnel decapsulation capability of tunnel egress nodes). The tunnel decapsulation capability includes but not limited to tunnel types, tunnel parameters (e.g., GRE key, L2TP session ID and cookie) and encapsulated protocols. In contrast with the tag proposal, there is no need for operators to manually configure many mappings between tags and tunnel decapsulation capabilities on each router. The manual configuration of such mappings is error-prone and therefore should be avoided if possible, IMHO.

Best regards,
Xiaohu

> adoption
> adoption
> on
> would
> after

---

From: Philip Christian <[email-masked]>
Date: Tue, 8 Mar 2016 11:09:27 +0000

Please can you explain why you are proposing a new protocol extension to
do this when there is an existing extension which already achieves
exactly the same thing? i.e. the Encapsulation capability TLV described
in ITU-T G.7712 and in draft-ietf-isis-auto-encap-03.

thanks, Philip

> 
> Your understanding is correct that this draft follows the idea of
> RFC5512. That's to say, it allows automatical discovery of the tunnel
> decapsulation capability of tunnel egress nodes). The tunnel
> decapsulation capability includes but not limited to tunnel types,
> tunnel parameters (e.g., GRE key, L2TP session ID and cookie) and
> encapsulated protocols. In contrast with the tag proposal, there is
> no need for operators to manually configure many mappings between
> tags and tunnel decapsulation capabilities on each router. The manual
> configuration of such mappings is error-prone and therefore should be
> avoided if possible, IMHO.
> 
> Best regards,
> Xiaohu
>

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 9 Mar 2016 02:00:11 +0000

Hi Philip,

> From: Philip Christian [mailto:[email-masked]]
> Sent: Tuesday, March 08, 2016 7:09 PM
> To: Xuxiaohu; Marc Binderberger; [email-masked] list
> Cc: Les Ginsberg; Christian Hopps
> Please can you explain why you are proposing a new protocol extension to do
> this when there is an existing extension which already achieves exactly the same
> thing? i.e. the Encapsulation capability TLV described in ITU-T G.7712 and in
> draft-ietf-isis-auto-encap-03.

First, these two drafts are intended to address different problems. draft-ietf-isis-auto-encap is only used to address the IPv4-IPv6 co-existence issue. My draft is intended to address the issues as mentioned in the Introduction section.

Second, the approaches as described in these two drafts are different. For example, draft-ietf-isis-auto-encap proposes to include an "Encapsulation Capability" TLV in LSPs that have LSP number 0. In addition, it has impact on the IP routing calculation process, see the following text quoted from this draft:

"   If an IS finds that the next hop does not support the type of packet
   that it is attempting to forward, then it MUST search along the
   shortest path from itself to the destination, and MUST inspect the
   "encapsulation capability" TLV of LSP 0 of each IS until it finds an
   IS that it is able to send the packet to in an encapsulated form.
 " 
My draft proposes to use a Encapsulation Capability sub-TLV of the Router Capability TLV and it has no impact on the IP routing calculation process at all. The only thing in common that I can see is the name (i.e., encapsulation capability).

Third, draft-ietf-isis-auto-encap has been expired 13 years before. Therefore, I think it should be safe to reuse the name (i.e., encapsulation capability). 

Best regards,
Xiaohu 

> > encapsulated protocols. In contrast with the tag proposal, there is no
> > need for operators to manually configure many mappings between tags
> > and tunnel decapsulation capabilities on each router. The manual

---

From: Philip Christian <[email-masked]>
Date: Wed, 9 Mar 2016 09:44:15 +0000

Hi Xiaohu,

On 09/03/16 02:00, Xuxiaohu wrote:
> 
> First, these two drafts are intended to address different problems.
> draft-ietf-isis-auto-encap is only used to address the IPv4-IPv6
> co-existence issue. My draft is intended to address the issues as
> mentioned in the Introduction section.

This is not true.  G.7712/isis-auto-encap only defines one sub-TLV out
of 255 for GRE tunnelling.  This sub-TLV can be used to describe any
protocol in any other protocol which has an ITU-T X.263 NLPID defined.
Therefore it is not limited to IPv4 and IPv6 (and CLNP).

If mechanisms other than GRE are wanted such as L2TPv3 or IPSec, then
there are 254 sub-TLVs left to define them, this is why we went for a
sub-TLV approach.

> Second, the approaches as described in these two drafts are
> different. For example, draft-ietf-isis-auto-encap proposes to include
> an "Encapsulation Capability" TLV in LSPs that have LSP number 0. In
> addition, it has impact on the IP routing calculation process, see the
> following text quoted from this draft:
> 
> My draft proposes to use a Encapsulation Capability sub-TLV of the
> Router Capability TLV and it has no impact on the IP routing calculation
> process at all. The only thing in common that I can see is the name
> (i.e., encapsulation capability).

The IP routing calculation process is in Annex rather than the main text
for this reason.  It was given as an example to show that the solution
is actually workable.  If you remove the Annex then the two documents
become two incompatible ways of achieving the same thing.  Moreover for
your draft to be an actual working solution there must be a way to
calculate routes for the encapsulated packets.  It seems to me to be a
partial solution as it does not describe this.

> Third, draft-ietf-isis-auto-encap has been expired 13 years before.
> Therefore, I think it should be safe to reuse the name
> (i.e., encapsulation capability).

auto-encap is (was :-) ) quite clear that it is communicating a solution
adopted by another standards body, the ITU-T.  ITU-T G.7712 most
definitely has not expired and there is evidence of possible
implementations in existence.  I don't think that the problem is the
name; I think that the problem is having two incompatible standards for
achieving essentially the same thing.

I don't speak for the ITU-T; and so I don't know if they have a problem
with this.  I do think that it would be wise to liaise with them, and to
find out if anyone actually installed a G.7712 auto-encap solution into
a live network.

regards, Philip

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 9 Mar 2016 12:03:17 +0000

Hi Philip,

> Sent: Wednesday, March 09, 2016 5:44 PM
> This is not true.  G.7712/isis-auto-encap only defines one sub-TLV out of 255
> for GRE tunnelling.  This sub-TLV can be used to describe any protocol in any
> other protocol which has an ITU-T X.263 NLPID defined.
> If mechanisms other than GRE are wanted such as L2TPv3 or IPSec, then there
> are 254 sub-TLVs left to define them, this is why we went for a sub-TLV
> approach.

What about MPLS-in-IP?

> > Second, the approaches as described in these two drafts are different.
> > For example, draft-ietf-isis-auto-encap proposes to include an
> > "Encapsulation Capability" TLV in LSPs that have LSP number 0. In
> > Router Capability TLV and it has no impact on the IP routing
> > calculation process at all. The only thing in common that I can see is
> > the name (i.e., encapsulation capability).
> 
> The IP routing calculation process is in Annex rather than the main text for this
> reason.  It was given as an example to show that the solution is actually

I would have to remind you that the above text is quoted from the main text (see section 3.3) rather than the annex.

> workable.  If you remove the Annex then the two documents become two
> incompatible ways of achieving the same thing.  Moreover for your draft to be
> an actual working solution there must be a way to calculate routes for the
> encapsulated packets.  It seems to me to be a partial solution as it does not
> describe this.

> > Therefore, I think it should be safe to reuse the name (i.e.,
> > encapsulation capability).
> 
> auto-encap is (was :-) ) quite clear that it is communicating a solution adopted by
> another standards body, the ITU-T.  ITU-T G.7712 most definitely has not
> expired and there is evidence of possible implementations in existence.  I don't

It's great to hear that the auto-discovery of tunnel capability is really needed within the scope of a single ISIS domain (oh no, a single area). Thanks:)

> think that the problem is the name; I think that the problem is having two
> incompatible standards for achieving essentially the same thing.

Is the approach as described in draft-ietf-isis-auto-encap workable in the inter-area/inter-level scenario? In other words, could a router advertise its encapsulation capability across levels? If the answer is no, then they are not the same thing since the approach as described in my draft is workable in both intra- and inter-area scenario.

Best regards,
Xiaohu

> I don't speak for the ITU-T; and so I don't know if they have a problem with this.
> I do think that it would be wise to liaise with them, and to find out if anyone
> actually installed a G.7712 auto-encap solution into a live network.
> 
> regards, Philip

---

From: Philip Christian <[email-masked]>
Date: Wed, 9 Mar 2016 16:45:45 +0000

Hi Xiaohu,

>> are 254 sub-TLVs left to define them, this is why we went for a sub-TLV

It would be simple to define a new sub-TLV for MPLS-in-IP in the
existing G.7712 auto-encap TLV.  There is no need to define an entire
new way of advertising encapsulation capability.  It would basically
consist of taking your RFC5512 sub-TLVs out of Router Capability TLVs
and putting them into the auto-encap TLVs instead.  All you would need
to do is avoid sub-TLV 1.

> I would have to remind you that the above text is quoted from the main
> text (see section 3.3) rather than the annex.

The main text can be changed.  In the end these are both standards for
flooding of encapsulation capabilities.  Provided that it doesn't break
G.7712 it can be changed but remain compatible.

> Is the approach as described in draft-ietf-isis-auto-encap workable in
> the inter-area/inter-level scenario? In other words, could a router
> advertise its encapsulation capability across levels? If the answer is no,
> then they are not the same thing since the approach as described in my
> draft is workable in both intra- and inter-area scenario.
> 

This is the most difficult aspect.  Router Capability TLVs have the
flags to control whether features are advertised out of area or not.
When the auto-encap feature of G.7712 was written this was not
considered.  An auto-encap TLV can be using in either L1 or L2 but the
flooding of the information across the boundary was not considered.  At
the time this seemed dangerous, and the idea really was that the L1-L2
router should natively support all protocols which means that no tunnels
would ever need to cross the boundary, and so no leaking of encap
capability across the boundary would be needed either.  This feature
would have to be replicated with a new sub-TLV to tell the L1-L2 router
whether to flood the information in/out of an area, with the default
being to not flood it I suppose.

Because G.7712 auto-encap was written from the beginning with sub-TLVs,
just like Router Capability, it can expanded to contain any feature you
wish, including all of the ones present in draft-xu-isis-encapsulation-cap.

regards, Philip

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 10 Mar 2016 04:14:06 +0000

> Sent: Thursday, March 10, 2016 12:46 AM
> It would be simple to define a new sub-TLV for MPLS-in-IP in the existing G.7712
> auto-encap TLV.  There is no need to define an entire new way of advertising
> encapsulation capability.  It would basically consist of taking your RFC5512
> sub-TLVs out of Router Capability TLVs and putting them into the auto-encap
> TLVs instead.  All you would need to do is avoid sub-TLV 1.

It's not that simple as you imagined.

> The main text can be changed.  In the end these are both standards for flooding

The whole document can be changed:)

> of encapsulation capabilities.  Provided that it doesn't break

Remain compatible? See below.

> > advertise its encapsulation capability across levels? If the answer is
> > no, then they are not the same thing since the approach as described
> > in my draft is workable in both intra- and inter-area scenario.
> >
> 
> This is the most difficult aspect.  Router Capability TLVs have the flags to control
> whether features are advertised out of area or not.
> When the auto-encap feature of G.7712 was written this was not considered.
> An auto-encap TLV can be using in either L1 or L2 but the flooding of the
> information across the boundary was not considered.  At the time this seemed
> dangerous, and the idea really was that the L1-L2 router should natively support
> all protocols which means that no tunnels would ever need to cross the
> boundary, and so no leaking of encap capability across the boundary would be
> needed either.  This feature would have to be replicated with a new sub-TLV to
> tell the L1-L2 router whether to flood the information in/out of an area, with the
> default being to not flood it I suppose.

It seems that you wanna reinvent a new instance of router capability TLV:). Even so, how do you ensure that " it doesn't break G.7712 it can be changed but remain compatible."

> Because G.7712 auto-encap was written from the beginning with sub-TLVs, just
> like Router Capability, it can expanded to contain any feature you wish, including
> all of the ones present in draft-xu-isis-encapsulation-cap.

According to the following text from RFC4271:

"   This document defines a new optional IS-IS TLV named CAPABILITY,
   formed of multiple sub-TLVs, which allows a router to announce its
   capabilities within an IS-IS level or the entire routing domain.  The
   applications mentioned above require the specification of new sub-
   TLVs carried within the CAPABILITY TLV defined in this document.

   Definition of these sub-TLVs is outside the scope of this document."

It's straightforward to use a sub-TLV of the Router Capability TLV to advertise a certain capability of a router.

Anyway, even there was some implementation of G.7712 which in turn depends on an expired I-D, it should not prevent the IETF to define a more reasonable solution. The relationship between RFC5512 and https://tools.ietf.org/html/draft-ietf-idr-tunnel-encaps-01 is a good example.

Best regards,
Xiaohu