[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
FW: resend on draft-ietf-ipo-framework
Alex/Scott,
this doc is back on IESG agenda.
Did Scott (or Alex) indeed check with ITU and T1X1 folk if
they reviewed and are OK. I ask, cause there is layer 1
discussion in this doc... and often we seem to be stepping
on ITU and/or T1X1 toes ....
Alex, some section numbers have changed compared to what they
were in the email exchanges belwo.
Alex, are you happy with Sect 5.2.2.1
I thought we (IESG) were not in favor of using BGP for all
these sorts of things. Maybe I am not clear on this, so if you
say it is OK, then fine. My question specifically was:
> > > - I wonder if and how sect 6.2.2.1 relates to our recent discussion
> > > on the use of RPs (BGP in this case, 2547) in the area of VPN.
> > > There is more on the possible use of RPs in sect 7.7.2
> >
> The above piece may indeed not be "understandable" to them. This was
> my question to other IESG members, where we had discussed use of RPs
> for VPN etc. Alex/Randy were driving that discussion if I remember well.
> If they think the doc is OK in that respect, then I am fine with that.
Thanks,
Bert
-----Original Message-----
From: Bert Wijnen [mailto:bwijnen@aaa-views.com]On Behalf Of Wijnen,
Bert (Bert)
Sent: maandag 27 januari 2003 10:40
To: Scott Bradner (E-mail)
Subject: FW: resend on draft-ietf-ipo-framework
This is my latest on that document, and I don't
think this has had follow up yet.
We should send an email to Steve and Debora (ITU and T1X1).
Not sure whom of OIF we can check with (they did UNI).
Thanks,
Bert
-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
Sent: donderdag 19 december 2002 13:32
To: Scott Bradner; iesg@ietf.org
Subject: RE: resend on draft-ietf-ipo-framework
W.r.t. my comments that they answered to:
- They claim it is OK to talk about layer 1 and about OIF specific
stuff like UNI, E-NNI etc. Well... if they claim so... should we
maybe check with some ITU, T1X1 and/or OIF folk.
We could ask Steve Trowbridge and Debora Bungard for a review
to check if we're stepping on anyone's toes?
- Some comments inline as well !!
- there are comments from others (Thomas, Steve... ) that I
leave up to thenm to answer
Thanks,
Bert
> -----Original Message-----
> From: Scott Bradner [mailto:sob@harvard.edu]
> Sent: dinsdag 17 december 2002 22:10
> To: iesg@ietf.org
> Subject: resend on draft-ietf-ipo-framework
>
>
>
> I sent this message back in sept but never followed up
> I'd like to close the look on this - could whoever had issues please
> comment on this response
>
> tnx
>
> Scott
>
> -------
>
> From sob Tue Sep 10 21:28:08 2002
> To: iesg@ietf.org
> Subject: response from the IPO WG to comments on
> draft-ietf-ipo-framework
>
>
> From jluciani@crescentnetworks.com Tue Sep 10 18:04:49 2002
> From: "James V. Luciani" <jluciani@crescentnetworks.com>
> To: "Scott Bradner" <sob@harvard.edu>
> Cc: "Bala Rajagopalan" <BRaja@tellium.com>,
> "Awduche, Daniel" <awduche@movaz.com>
> Subject: FW: IESG comments on draft-ietf-ipo-framework
> Date: Tue, 10 Sep 2002 18:03:28 -0400
> MIME-Version: 1.0
> Content-Type: text/plain;
> charset="iso-8859-1"
> Content-Transfer-Encoding: 7bit
> X-Priority: 3 (Normal)
> X-MSMail-Priority: Normal
> X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
> Importance: Normal
> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
>
> Scott,
> Please see our replies inside.
> Thanks,
> --Jim
> > -----Original Message-----
> > From: Scott Bradner [mailto:sob@harvard.edu]
> > Sent: Saturday, September 07, 2002 4:50 PM
> > To: awduche@isocore.com; james_luciani@mindspring.com
> > Subject: IESG comments on draft-ietf-ipo-framework
> >
> >
> > the IESG has dicusssed the current version of
> draft-ietf-ipo-framework and
> > has these comments
> >
> > Scott
> > ----------------------------------------------------------
> > Bert:
>
> Fine. I think Bala, Dan and I are sufficient. We can perhaps
> mention the
> others inside.
>
> > - the ID has 6 authors which exceeds RFC Editor guidelines
>
> A framework builds out a high level description of the
> problem space as it
> is defined at the time of the writing. It further constrains
> the work that
> is relevant to the group. I believe that both of these are adequately
> covered in the text and thus would be happy to keep the title as is.
>
> > - I wonder if this is a "framework" or rather a "overview of
> > IPO Networking aspects".
>
> This layer 1 stuff is the basis for discussion of what the
> Layer 3 stuff is
> conrolling. Without the discussion of the layer 1 stuff the
> remainder of
> the material could be misleading since it would have no context.
>
> > - It talks a whole lot about all the layer 1 stuff. Is that
> > a space where we feel comfortable publishing docs?
>
> Again, this detail is necessary to framework the problem.
> The document is
> not comprised only of that material and without it there is a loss of
> context.
>
> The network model and interface terminology as mentioned is
> commonly used in ITU-T and OIF, and the informational drafts coming
> into IETF. As Jim said, this being a framework draft, we're
> presenting information and models being considered for IPO.
> We're not inventing these in the draft.
> The draft also says that with the peer model, these interfaces
> may not be distinguishable.
>
> > - It speaks even more about UNI, I-NNI and E-NNI, a space
> > that we deliberately did not go into when we started
> > SUB-IP area, and a space that is basically being worked
> > by the OIF. So should we be publishing docs in that space?
>
> I did not quite understand the question. Without the
> discussion of routing
> protocols there is no basis for frameworking the IP over
> optical space.
>
> > - I wonder if and how sect 6.2.2.1 relates to our recent discussion
> > on the use of RPs (BGP in this case, 2547) in the area of VPN.
> > There is more on the possible use of RPs in sect 7.7.2
>
The above piece may indeed not be "understandable" to them. This was
my question to other IESG members, where we had discussed use of RPs
for VPN etc. Alex/Randy were driving that discussion if I remember well.
If they think the doc is OK in that respect, then I am fine with that.
> Framework documents often include areas of hot debate. Sometimes they
> include areas that are shown to be not relevant too. In both cases, it
> behoves the authors of a framework document to include this material in
> order to show what was considered and subsequently accepted or not because
> otherwise the same questions as to why this or that was not included in a
> framework will continue to come up.
>
The above sounds like Dan Awduche again. He used similar arguments
when we renamed the title of a TE document that he called "Framework"
and that we renamed to "Overview of".
I think Dan just wants to claim more than what it actually is.
But I won't loose sleep over it if you/we let it pass.
For me it is consistency with what we have done to other WGs
> We are fine with not mentioning LMP but just talk about the neighbor
> discovery functionality.
>
OK, that sounds good then
> > - It talks about the use of LMP for neighbor/service discovery
> > (sections 5.1 and 7.2), and I see some debate on that on the
> > CCAMP mailing list as to wether that is good or bad.
> >
Bert
> > ----------------------------------------------------------
> > Thomas
> > Under the unified service model, optical network services are
> > obtained implicitly during end-to-end MPLS signaling.
> Specifically,
> > an edge router can create a lightpath with specified
> attributes, or
> > delete and modify lightpaths as it creates MPLS
> label-switched paths
> > (LSPs). In this regard, the services obtained from the optical
>
> It is possible that another label switching protocol could be
> relevant here
> but at the moment MPLS is the only one being considered in
> the IETF for the
> IPoO problem space.
>
> > reads like MPLS is assumed/required part of framework. Is this the
> > case?
>
> You do not need to form an FA. The LSP could be strictly dataplane.
> However, it could be, particularly in the VR case, that
> either an FA or
> something like an FA could be used. We should probably
> mention something to
> that effect.
>
> > The notion of "forwarding adjacency" (FA) described in [3] is
> > essential in propagating existing lightpath information to other
> > routers. An FA is essentially a virtual link advertised
> into a link
> >
>
> Don't know status.
>
> > 3. K. Kompella and Y. Rekhter, "LSP Hierarchy with MPLS TE,"
> > Internet Draft, Work in progress.
> >
> > Is reference to this document normative? What is its status?
> >
> > nits:
>
> Agreed. (M-x query-replace-regexp 'vendor' 'vendor'''s')
>
> > may be expected that each sub-network will consist of a single
> > vendor switches. In the future, as standardization
> efforts mature,
> >
> > s/vendor/vendor's/ ??
>
> Is this a bug or a statement? :-)
>
> > connectivity service offered by the optical network. For example,
> >
> > missing rest of sentence.
> >
> > control planes over the UNI. As described in Section 6,
> the optical
> >
> > this is section 6. Is the reference right? or say "in this section"?
> >
> > recommendation \xfb even choice \xfb within this
> framework document,
> >
> >
> > funny characters
> >
> > also be established specifying only which SRLGs to
> AVOID in a
> >
> > AVOID (upper case)?
> >
> > 2. The primary path and the back-up path are comptuted
> together in
> >
> > spelling
> >
> > setup would be to quickly pre-provisioned paths based on some
> >
> > pre-provision
> >
> > (NMS) for static connection management is prevelant in legacy
> >
> > prevalent
> >
> > well), or updrade the NMS software in order to introduce
> some degree
> >
> > spell
> >
> > ----------------------------------------------------------
> > Steve
> > Section 3:
> > The notion of a "trust domain" is very dangerous,
> even without
> > the extension to multiple administrative domains.
> >
> > (Nit on 4.1: speaking of "*coherent* end-to-end provisioning" is
> > slightly ambiguous...)
>
> Polarization Mode Dispersion: distortion caused by
> impairments in a fiber
> causing dispersion of a mulit-chromatic source
> Dispersion: a process by wavelengths in a multi-chromatic
> source travel at
> different speeds and thus the overall signal is widened at
> the base in the
> time domain and less peeked in terms of amplitude
>
> > (Serious nit: what is PMD?)
>
> Agreed
>
> > The second paragraph of 10.1 is generic and should be deleted.
> > (And the notion that TCP sequence numbers can be trusted, in the
> > absence of stronger anti-replay mechanisms, is wrong.)
>
> I realize that IESG is adament about this sort of thing but
> threat sections
> in framework docs are odd to me. In any case, we will comply.
>
> > The document is missing some threat concepts:
> >
> >
> > Even within a "trust domain",
> > *any* subverted node can send control messages,
> > since the control plane is IP -- it doesn't have to be a
> > misbehaving optical element.
> >
> > Optical routing is strictly more dangerous than IP routing,
> > since attacks on the former show up via traceroute and the
> > like. But optical elements are invisible (so to speak)
> > to IP nodes. Thus, the output of RPSEC should be considered
> > in eventual protocols.
> >
> > Requests from client networks must be filtered
> against policy,
> > to guard against excess resource consumption. (There's some
> > discussion of that, but not enough.) There's another
> > possible denial of service attack that might be
> worth thinking
> > about: could requests for improbable paths (i.e., paths for
> > which the network wasn't heavily provisioned) consume all of
> > the ports on internal OXCs? If so, global co-ordination of
> > service requests might be needed.
> >
> > I recall some document (I can't recall which) mentioned the
> > need for confidentiality for SRLG information.
> >
> >
> >
> >
>