Re: [Teas] I-D Action: draft-ietf-teas-actn-framework-02.txt

HI Michael, all,

1. One of the sources for misunderstanding is the fact that the MMI is actually already defined, but in the wrong document, it is in (draft-zhang-teas-actn-yang-03), I'm now adding it to the fwk too. The image that Young sent on the list and that you said is clearly explaining the recursion issue is already there and it's Figure  4, I think that is enough, I'm just adding the I/F names to it.

2. Regarding:
> Note one root cause of my confusion is this sentence in draft-ietf-teas-actn-
> framework-01:
> 
>    A key requirement for allowing recursion of MDSCs is that a single
>    interface needs to be defined both for the north and the south
>    bounds.
You're looking at an old version of the document, the statement was removed already in v02.

3. Finally regarding:
> It is this sort of discussion that is missing in the document. But, one question
> on this specific suggestion: So, a CMI will *never* need access to technology-
> specific parameters in a ONC within what the ACTN framework standardizes?
> Is this what implementations would do?
>
I'm adding some text to each interface description saying that the MPI and MMI can be technology specific or technology agnostic while the CMI needs to technology agnostic (as there is where you see the VN concept). I'm planning to add the nice statement below (I'm copying it from one of the emails on the list:

"When technology specific information needs to be included, this info will be add-ons on top of the general abstract topology. As far as general topology abstraction standpoint, all interfaces are still recursive in nature"

Thanks
Daniele  

> -----Original Message-----
> From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]
> Sent: martedì 24 gennaio 2017 22:49
> To: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; Leeyoung
> <leeyoung@huawei.com>
> Cc: teas@ietf.org
> Subject: RE: [Teas] I-D Action: draft-ietf-teas-actn-framework-02.txt
> 
> > -----Original Message-----
> > From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com]
> > Sent: Tuesday, January 24, 2017 6:29 PM
> > To: Scharf, Michael (Nokia - DE); Leeyoung
> > Cc: teas@ietf.org
> > Subject: RE: [Teas] I-D Action: draft-ietf-teas-actn-framework-02.txt
> >
> > > As I wrote earlier in the thread: Let's assume that there is an MDSC
> > > dealing with DWDM PNCs and another one dealing with MPLS-TE PNCs.
> > > Would the ACTN framework foresee that the DWDM MDSC and the MPLS-
> TE
> > > MDSC can be used recursively in any combination?
> >
> > Yes
> 
> As I said, I can see how this would hypothetically work for entirely technology
> agnostic interfaces.
> 
> > > For what it is worth, I think I understand how reclusiveness could
> > > work if
> > the
> > > scope of the ACTN framework is (1) limited to a single technology or
> > protocol
> > > layer, or (2) if CMI and MPI are strictly technology-neutral. But if
> > > one of
> > these
> > > constraints are not true, I get lost how recursion would work in reality.
> >
> > ACTN is NOT limited to a single technology or protocol layer. The MPI
> > can be technology agnostic or technology specific and I don't
> > understand what is the problem of having an MDSC on top of that.
> 
> Which interface would be used between two MDSC? The MPI? The CMI?
> Either one? A third class of interface?
> 
> And is the interface between two MDSC technology-specific or technology-
> neutral?
> 
> Sorry, this is not at all clear from the document and the architecture therein.
> 
> Note one root cause of my confusion is this sentence in draft-ietf-teas-actn-
> framework-01:
> 
>    A key requirement for allowing recursion of MDSCs is that a single
>    interface needs to be defined both for the north and the south
>    bounds.
> 
> I see case where the south interface of an MDSC is technology-specific but
> possibly the north interface would be technology neutral. How can this be a
> single interface? What do I miss?
> 
> > Regarding the CMI I'd say that it HAS to be technology agnostic, hence
> > the technology complexity would be hidden to the parent MDSC from the
> child MDSCs.
> 
> It is this sort of discussion that is missing in the document. But, one question
> on this specific suggestion: So, a CMI will *never* need access to technology-
> specific parameters in a ONC within what the ACTN framework standardizes?
> Is this what implementations would do?
> 
> Michael
> 
> 
> 
> >
> > BR
> > Daniele
> >
> > > -----Original Message-----
> > > From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]
> > > Sent: martedì 24 gennaio 2017 17:40
> > > To: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; Leeyoung
> > > <leeyoung@huawei.com>
> > > Cc: teas@ietf.org
> > > Subject: RE: [Teas] I-D Action:
> > > draft-ietf-teas-actn-framework-02.txt
> > >
> > > As I wrote earlier in the thread: Let's assume that there is an MDSC
> > > dealing with DWDM PNCs and another one dealing with MPLS-TE PNCs.
> > > Would the ACTN framework foresee that the DWDM MDSC and the MPLS-
> TE
> > > MDSC can be used recursively in any combination?
> > >
> > > For what it is worth, I think I understand how reclusiveness could
> > > work if
> > the
> > > scope of the ACTN framework is (1) limited to a single technology or
> > protocol
> > > layer, or (2) if CMI and MPI are strictly technology-neutral. But if
> > > one of
> > these
> > > constraints are not true, I get lost how recursion would work in reality.
> > >
> > > Even more in general, it is not easy to understand how the ACTN
> > > framework deals with TE engineering in multi-layer networks. For
> > > instance, Figure 7 is confusing in this case. I don't think that
> > > these are questions specific to solutions.
> > >
> > > Michael
> > >
> > >
> > > > -----Original Message-----
> > > > From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Daniele
> > > > Ceccarelli
> > > > Sent: Tuesday, January 24, 2017 4:49 PM
> > > > To: Scharf, Michael (Nokia - DE); Leeyoung
> > > > Cc: teas@ietf.org
> > > > Subject: Re: [Teas] I-D Action:
> > > > draft-ietf-teas-actn-framework-02.txt
> > > >
> > > > This is a framework document, not a solution one. To me saying
> > > > that the ACTN hierarchy should allow for recursion is enough
> > > > within the context
> > > of this ID.
> > > > How it works is in the scope of the solution documents.
> > > > What we could discuss is what makes you think that, from an
> > > > architecture perspective, recursion is not possible.
> > > >
> > > > Thanks
> > > > Daniele
> > > >
> > > > > -----Original Message-----
> > > > > From: Scharf, Michael (Nokia - DE)
> > > > > [mailto:michael.scharf@nokia.com]
> > > > > Sent: martedì 24 gennaio 2017 15:25
> > > > > To: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>;
> > > > > Leeyoung <leeyoung@huawei.com>
> > > > > Cc: teas@ietf.org
> > > > > Subject: RE: [Teas] I-D Action:
> > > > > draft-ietf-teas-actn-framework-02.txt
> > > > >
> > > > > Not all of the concerns listed below are on references and terms only.
> > > > > Specifically, I have raised the question how recursion can work,
> > > > specifically for
> > > > > multiple technologies (example: IP and Optical - or is this not
> > > > > in
> > scope?).
> > > > And I
> > > > > have raised the question why the document assumes that
> > > > > "applications" talk "directly" to the CNCs, which seems quite
> > > > > strange e.g. in a carrier-carrier scenario. And so on.
> > > > >
> > > > > These are not minor issues to me.
> > > > >
> > > > > Michael
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Daniele
> > > > > > Ceccarelli
> > > > > > Sent: Tuesday, January 24, 2017 2:51 PM
> > > > > > To: Scharf, Michael (Nokia - DE); Leeyoung
> > > > > > Cc: teas@ietf.org
> > > > > > Subject: Re: [Teas] I-D Action:
> > > > > > draft-ietf-teas-actn-framework-02.txt
> > > > > >
> > > > > > HI Michael,
> > > > > >
> > > > > > The update aims at solving the major issues, once we agree on
> > > > > > those we can easily move to the minor ones like references and
> terms.
> > > > > > Could you start focusing on them?
> > > > > >
> > > > > > Working group,
> > > > > > since this is a WG draft since a while and since it has
> > > > > > already been reviewed by some of you, we'd like to hear more
> > > > > > opinions and know whether the suggested changes are ok with
> > > > > > everyone, don't care or someone prefers the actual version. If
> > > > > > you speak now before the WG LC we can avoid further duplications of
> efforts.
> > > > > >
> > > > > > Thanks
> > > > > > Daniele
> > > > > >
> > > > > >
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of
> > > > > > > Scharf, Michael (Nokia - DE)
> > > > > > > Sent: martedì 24 gennaio 2017 11:44
> > > > > > > To: Leeyoung <leeyoung@huawei.com>
> > > > > > > Cc: teas@ietf.org
> > > > > > > Subject: Re: [Teas] I-D Action:
> > > > > > > draft-ietf-teas-actn-framework-02.txt
> > > > > > >
> > > > > > > Hi Young,
> > > > > > >
> > > > > > > I don't understand how many of my questions in
> > > > > > > https://www.ietf.org/mail-
> > > > > > > archive/web/teas/current/msg01861.html are
> > > > > addressed.
> > > > > > >
> > > > > > > Examples (not a comprehensive list):
> > > > > > >
> > > > > > > - Reference [ONF-ARCH]
> > > > > > > - Term NMS/OSS
> > > > > > > - PCE vs. PNC
> > > > > > > - Explanation how recursiveness would actually work
> > > > > > > (specifically for
> > > > > > multiple
> > > > > > > technologies)
> > > > > > > - Terminology issues on "application", "forwarding state", ...
> > > > > > >
> > > > > > > Thanks
> > > > > > >
> > > > > > > Michael
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Leeyoung [mailto:leeyoung@huawei.com]
> > > > > > > > Sent: Monday, January 23, 2017 10:25 PM
> > > > > > > > To: Scharf, Michael (Nokia - DE)
> > > > > > > > Cc: teas@ietf.org
> > > > > > > > Subject: RE: [Teas] I-D Action:
> > > > > > > > draft-ietf-teas-actn-framework-02.txt
> > > > > > > >
> > > > > > > > Hi Michael,
> > > > > > > >
> > > > > > > > We thank you for providing good comments and input in this
> thread.
> > > > > > > > Co-authors of this draft have discussions to make sure to
> > > > > > > > incorporate your comments/concerns in the last week. And
> > > > > > > > here's the summary of our proposal and the diff file is
> > > > > > > > enclosed with a
> > > > proposed
> > > > > revision.
> > > > > > > >
> > > > > > > > 1. In Section 1.1, we rid of two terms: service-aware
> > > > > > > > connectivity service and NFV services.
> > > > > > > > 2. We rid of all "orchestration" term from the document.
> > > > > > > > 3. We rid of all NFV/VNF terms from the document.
> > > > > > > > 4. We re-wrote Section 6 so that any NFV/VNF nuances are
> deleted.
> > > > > > > > 5. In Section 8, we rid of section 8.1 (which is
> > > > > > > > application to CNC security
> > > > > > > > implication) as you pointed out, this is not the scope of ACTN 6.
> > > > > > > > In Section 3, we added a few words to make sure interfaces
> > > > > > > > A and D are not in scope of ACTN:
> > > > > > > >
> > > > > > > > Old: The interfaces within the ACTN scope are B and C.
> > > > > > > > NEW: The interfaces within the ACTN scope are B and C
> > > > > > > > while interfaces A and D are out of the scope of ACTN and
> > > > > > > > are only shown in Figure 5 to give a complete context of ACTN.
> > > > > > > >
> > > > > > > > I believe most of your concerns/comments are incorporated
> > > > > > > > in the proposed revision. Please let us know if there are
> > > > > > > > still any major issues. We look forward to hearing from you soon.
> > > > > > > > We'd like to submit the revision as a sable one to the WG
> > > > > > > > so that the LC can
> > > > proceed
> > > > > soon.
> > > > > > > >
> > > > > > > > Thanks & Best regards,
> > > > > > > > Young
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > Teas mailing list
> > > > > > > Teas@ietf.org
> > > > > > > https://www.ietf.org/mailman/listinfo/teas
> > > > > >
> > > > > > _______________________________________________
> > > > > > Teas mailing list
> > > > > > Teas@ietf.org
> > > > > > https://www.ietf.org/mailman/listinfo/teas
> > > >
> > > > _______________________________________________
> > > > Teas mailing list
> > > > Teas@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/teas