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

[Uma Chunduri <[e-mail]>]

Hi Marc,

Thanks for your review of the draft and comments below.
Comments in-line [Uma]:

--
Uma C.


-----Original Message-----
From: Marc Binderberger [mailto:[e-mail]] 
Sent: Sunday, February 28, 2016 7:43 PM
To: Les 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 :-)

[Uma]:  As just replied (http://www.ietf.org/mail-archive/web/isis-wg/current/msg04509.html ) discovering tunnel end points depends on the application and it's beyond the scope of this document.

> 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 :-)


[Uma]:   If R2's immediate  neighbor is not capable of MPLS/SR for example R2 is your ingress and R4 is your egress. In one use case, R2 uses the signaled decapsulation 
                capabilities of R4 and 	with its associated  parameters as specified in this draft to encapsulate packets to R4.
	Hope this clarifies.  
	Section-1 references multiple applications. For a quick use case, I would suggest to go through one of the reference in section-1 for example 
               https://tools.ietf.org/html/draft-xu-spring-islands-connection-over-ip-04 

               Perhaps the title of the draft should be draft-xu-isis-encapsulation-cap ==> raft-xu-isis-decapsulation-cap! 
               This is been discussed in IETF92/93 while this draft was presented and subsequently title was changed on 05 version (but not the draft name).