[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: AD-review comments on draft-ietf-ccamp-sdhsonet-control
Sounds good Alex. But please advise us if there seems to be a consensus
against having this go forward. Eric, Vishal and myself have published
papers in several IEEE magazines on these topics (though not all this
info in any one place and definitely not at this level of detail due to
page count limitations).
On the other hand the document is a very nice reference/companion for
anyone trying to understand this stuff (kind of a prerequisite to making
it work or using it) and hence very convenient to have it archived at
the IETF. But, I still think it could hurt my book sales so on second
thought.... ;-)
Greg B.
Dr. Greg M. Bernstein
Grotto Networking
-----Original Message-----
From: Alex Zinin [mailto:zinin@psg.com]
Sent: Wednesday, March 10, 2004 5:38 PM
To: Vishal Sharma
Cc: Adrian Farrel; Greg Bernstein; Eric Mannie; ccamp@ops.ietf.org; Bert
Wijnen
Subject: Re: AD-review comments on draft-ietf-ccamp-sdhsonet-control
Vishal,
To clarify the process, here's the list of stages a document usually
goes
through:
1. WG discussion
2. WG Last Call
3. AD review (may include directorate <-- You are here now
and expert reviews)
4. IETF LC (generally not needed for INFO)
5. IESG review
6. RFC Editor
I received the doc back in Sep 2003 and asked one of the Routing Area
directorate members for an expert review, which resulted in a long
list of
comments. We had a long (and admittedly slow) discussion between the
reviewer,
me, and the WG chairs in an attempt to distill it to a set of most
significant
technical comments and editorial suggestions, which is what I brought
back for
consideration by the WG.
On a related note: please do not assume that work is done once a
document has
passed the WG LC. It is normal to receive comments from the ADs and
IESG.
Regards.
--
Alex
http://www.psg.com/~zinin/
Sunday, March 7, 2004, 1:41:10 PM, Vishal Sharma wrote:
> Adrian,
> I am still very confused about what the debate is about at this point.
> In any case, I would like to defer to my co-authors on this matter.
> As for the enhancements/edits, I think we already stated that we
> could do those.
> -Vishal
>> -----Original Message-----
>> From: Adrian Farrel [mailto:adrian@olddog.co.uk]
>> Sent: Sunday, March 07, 2004 3:24 AM
>> To: Vishal Sharma; Greg Bernstein; Eric Mannie
>> Cc: ccamp@ops.ietf.org; Alexey Zinin; Bert Wijnen
>> Subject: Re: AD-review comments on draft-ietf-ccamp-sdhsonet-control
>>
>>
>> Thanks for your thoughts Vishal.
>>
>> The debate occurs now.
>>
>> Are the current authors willing and able to make the changes
>> requested by the AD?
>>
>> Thanks,
>> Adrian
>> ----- Original Message -----
>> From: "Vishal Sharma" <v.sharma@ieee.org>
>> To: "Adrian Farrel" <adrian@olddog.co.uk>; "Greg Bernstein"
>> <gregb@grotto-networking.com>;
>> "Eric Mannie" <eric_mannie@hotmail.com>
>> Cc: <ccamp@ops.ietf.org>; "Alexey Zinin" <azinin@psg.com>; "Bert
Wijnen"
>> <bwijnen@lucent.com>
>> Sent: Sunday, March 07, 2004 12:48 AM
>> Subject: RE: AD-review comments on draft-ietf-ccamp-sdhsonet-control
>>
>>
>> > Adrian,
>> >
>> > Thanks for the clarification. Our (the authors) understanding is
>> > that the draft had passed (quite a while back, in May 2002
>> > actually, after we had addressed the very last round of comments
from
>> > Kireeti), all of the processes in the WG needed to advance it to
>> > informational RFC.
>> >
>> > Its purpose is really to provide an overall view and framework for
>> > SDH/SONET control using an IP/MPLS control plane.
>> >
>> > So it would be useful for us to know exactly where the debate
occurred,
>> > since we were not aware of it.
>> > (As far as the WG is concerned, the draft was approved such a
while
>> > back that it has been a completed item for over one-and-a-half
years.)
>> >
>> > At the last discussion on it in Sept. 2003, we were told that the
only
>> > reason it had got delayed was because it somehow missed being
>> sent to the
>> > ADs on time.
>> >
>> > -Vishal
>> >
>> > > -----Original Message-----
>> > > From: owner-ccamp@ops.ietf.org
[mailto:owner-ccamp@ops.ietf.org]On
>> > > Behalf Of Adrian Farrel
>> > > Sent: Saturday, March 06, 2004 3:11 PM
>> > > To: Vishal Sharma; Greg Bernstein; Eric Mannie
>> > > Cc: ccamp@ops.ietf.org; Alexey Zinin
>> > > Subject: Re: AD-review comments on
draft-ietf-ccamp-sdhsonet-control
>> > >
>> > >
>> > > Vishal,
>> > >
>> > > The process is that the WG hands the draft off to the AD to take
>> > > it to the IESG. At this
>> > > point the AD performs a review before taking the draft to the
>> > > IESG and this is what we are
>> > > seeing the results of.
>> > >
>> > > Note that this particular draft has been under "AD watch" for a
>> > > while. Alex may want to
>> > > clarify the reason for this, but my understanding is that there
>> > > was some debate as to
>> > > whether the draft had served its purpose already (that is, as a
>> > > design document for the
>> > > other drafts on SONET/SDH) or whether it should continue and
>> > > become an RFC. This review is
>> > > the next step towards becoming an RFC.
>> > >
>> > > Cheers,
>> > > Adrian
>> > >
>> > > ----- Original Message -----
>> > > From: "Vishal Sharma" <v.sharma@ieee.org>
>> > > To: "Adrian Farrel" <adrian@olddog.co.uk>; "Greg Bernstein"
>> > > <gregb@grotto-networking.com>;
>> > > "Eric Mannie" <eric_mannie@hotmail.com>
>> > > Cc: <ccamp@ops.ietf.org>; "Alexey Zinin" <azinin@psg.com>
>> > > Sent: Saturday, March 06, 2004 8:41 PM
>> > > Subject: RE: AD-review comments on
draft-ietf-ccamp-sdhsonet-control
>> > >
>> > >
>> > > > Adrian et al,
>> > > >
>> > > > We will work on the document and make the appropriate
modifications
>> > > > to incorporate the comments.
>> > > >
>> > > > BTW, Alex could you please clarify whether this is an IESG
review
>> > > > or some other review?
>> > > >
>> > > > Our understanding after the last communication with Kireeti on
this
>> > > > subject, sometime
>> > > > in July last year, was that this draft (after having passed
several
>> > > > last calls), was being sent to the IESG for completing the
process
>> > > > of advancing to informational RFC.
>> > > >
>> > > > Thanks,
>> > > > -Vishal
>> > > >
>> > > > > -----Original Message-----
>> > > > > From: Adrian Farrel [mailto:adrian@olddog.co.uk]
>> > > > > Sent: Saturday, March 06, 2004 4:16 AM
>> > > > > To: greg@ciena.com; Eric Mannie; Vishal Sharma (E-mail 2)
>> > > > > Cc: ccamp@ops.ietf.org
>> > > > > Subject: Re: AD-review comments on
>> draft-ietf-ccamp-sdhsonet-control
>> > > > >
>> > > > >
>> > > > > Greg, Eric, Vishal,
>> > > > > Are you willing and able to pick this draft up again and make
the
>> > > > > changes from Alex?
>> > > > >
>> > > > > Thanks,
>> > > > > Adrian
>> > > > >
>> > > > > ----- Original Message -----
>> > > > > From: "Alex Zinin" <zinin@psg.com>
>> > > > > To: <ccamp@ops.ietf.org>
>> > > > > Cc: <Rtg-dir@ietf.org>
>> > > > > Sent: Thursday, March 04, 2004 12:48 PM
>> > > > > Subject: AD-review comments on
draft-ietf-ccamp-sdhsonet-control
>> > > > >
>> > > > >
>> > > > > > Folks-
>> > > > > >
>> > > > > > Please find below comments from the RTG area directorate
>> > > that I would
>> > > > > > like the WG to consider.
>> > > > > >
>> > > > > > Thank you.
>> > > > > >
>> > > > > > --
>> > > > > > Alex Zinin
>> > > > > >
>> > > > > > Technical:
>> > > > > > ----------
>> > > > > >
>> > > > > > Section 3.2:
>> > > > > >
>> > > > > > 1. Figure 1 misses the STM-0 branch
>> > > > > >
>> > > > > > Section 3.4.3:
>> > > > > >
>> > > > > > 2. In comparison table, PNNI word appears for the first
>> time in this
>> > > > > > document, any specific reason to mention PNNI in a
>> > > GMPLS context ?
>> > > > > >
>> > > > > > Section 3.5
>> > > > > >
>> > > > > > 3. "New simplified encapsulations could reduce this
>> > > overhead to as low
>> > > > > > as 3%, but the gain is not huge compared to SDH and
SONET,
>> > > > > which have
>> > > > > > other benefits as well.)" any reference available
>> for these new
>> > > > > > simplified encapsulation(s) ?
>> > > > > >
>> > > > > > 4. "Any encapsulation of IP over WDM should at least
>> provide error
>> > > > > > monitoring capabilities (to detect signal
>> degradation), error
>> > > > > > correction capabilities, such as FEC (Forward Error
>> > > Correction) that
>> > > > > > are particularly needed for ultra long haul
>> > > transmission, sufficient
>> > > > > > timing information, to allow robust synchronization
>> (that is, to
>> > > > > > detect the beginning of a packet), and capacity to
transport
>> > > > > > signaling, routing and management messages, in order to
>> > > control the
>> > > > > > optical switches."
>> > > > > >
>> > > > > > The first part refers to data plane capabilities,
>> however the
>> > > > > > requirement: the "encapsulation of IP over WDM"
>> should deliver
>> > > > > > the capacity to transport IP based control plane
>> information -
>> > > > > > why is this the case ? an out of band network would
>> also do the
>> > > > > > job and this statement makes thus the implicit
>> assumption that
>> > > > > > data and control plane topology is congruent
>> > > > > >
>> > > > > > Section 6:
>> > > > > >
>> > > > > > 5. "Due to the increase in information transferred in
>> the routing
>> > > > > > protocol, it may be useful to separate the relatively
static
>> > > > > > parameters concerning a link from those that may be
>> subject to
>> > > > > > frequent changes. The current GMPLS routing extensions
>> > > [12],[13],
>> > > > > > [14] do not make such a separation, however."
>> > > > > >
>> > > > > > it may be thus worth asking the question was the
>> dissemination
>> > > > > > of these quasi-static "link capabilities" using the
>> same rules
>> > > > > > as for any other TE LSA Type 1 sub-TLV the right
approach ?
>> > > > > >
>> > > > > > Section 6.1:
>> > > > > >
>> > > > > > 6. what does the following sentence brings in the scope of
>> > > this control
>> > > > > > plane framework (and this is even not necessarily true
>> > > when vcat is
>> > > > > > provided over different line cards):
>> > > > > >
>> > > > > > "Note that this inverse multiplexing process can be
>> > > significantly
>> > > > > > easier to implement with SONET/SDH signals rather
>> than packets."
>> > > > > >
>> > > > > > Section 6.3:
>> > > > > >
>> > > > > > 7. "However, if only standard concatenation is supported
>> > > then reporting
>> > > > > > gets trickier since there are constraints on where the
>> > > STS-1s can be
>> > > > > > placed. SDH has still more options and constraints,
>> > > hence it is not
>> > > > > > yet clear which is the best way to advertise
>> bandwidth resource
>> > > > > > availability/usage in SONET/SDH. At present, the
>> GMPLS routing
>> > > > > > protocol extensions define minimum and maximum values
>> > > for available
>> > > > > > bandwidth, which allows a remote node to make some
>> > > deductions about
>> > > > > > the amount of capacity available at a remote link and
>> > > the types of
>> > > > > > signals it can accommodate. However, due to the
>> > > multiplexed nature
>> > > > > > of the signals, the authors are of the opinion that
>> reporting of
>> > > > > > bandwidth particular to signal types rather than as a
single
>> > > > > > aggregate bit rate is probably very desirable."
>> > > > > >
>> > > > > > -> the authors do not explain from which perspective
>> > > and the reasons
>> > > > > > this particular bw accounting report is desirable
>> > > (sections 2.4.3 &
>> > > > > > 2.4.8 of GMPLS routing explains how these values are
>> > > used to take
>> > > > > > into account the multiplexing capability of a SONET/SDH
>> > > interface),
>> > > > > > there is no real determination of the missing
>> > > information at remote
>> > > > > > nodes for the establishment of an LSP with a certain
>> > > amount of bw
>> > > > > > (note that it is not an issue of flexible vs standard
>> > > concatenation
>> > > > > > issue but a control plane issue)
>> > > > > >
>> > > > > > Section 7.3:
>> > > > > >
>> > > > > > 8. "This information is specified in three parts [17],
>> each of which
>> > > > > > refers to a different network layer."
>> > > > > >
>> > > > > > The description of the signaling elements shall mention the
>> > > following:
>> > > > > > (section 7.3 refers to [17] but the latter does not
>> > > correspond to the
>> > > > > > description given in this section)
>> > > > > >
>> > > > > > 1. GENERALIZED_LABEL REQUEST (as [RFC3471/3])
>> > > > > > which contains three parts: LSP Encoding Type,
Switching
>> > > > > Type, G-PID
>> > > > > >
>> > > > > > 2. SONET/SDH TRAFFIC_PARAMETERS (as [17]) used as
>> > > > > SENDER_TSPEC/FLOWSPEC
>> > > > > > which contains 6 parts: Signal Type, (RCC,NCC,NVC),
MT,
>> > > > > Transparency,
>> > > > > > Profile
>> > > > > >
>> > > > > > 3. UPSTREAM_LABEL for Bi-directional LSP's (as
[RFC3471/3])
>> > > > > >
>> > > > > > 4. Local Link Selection e.g. IF_ID_RSVP_HOP Object
>> (as [RFC3473])
>> > > > > >
>> > > > > > ----
>> > > > > >
>> > > > > >
>> > > > > > Editorial:
>> > > > > > ----------
>> > > > > >
>> > > > > > Section 3:
>> > > > > >
>> > > > > > 1. Sometimes this document refers to GMPLS other to MPLS
and
>> > > > > > sometimes as above as "extending IP technology"
>> > > > > >
>> > > > > > Section 3.1
>> > > > > >
>> > > > > > 2. "When a packet reaches a core packet LSR, this LSR uses
>> > > the label as
>> > > > > > an index into a forwarding table to determine the next
>> > > hop and the
>> > > > > > corresponding outgoing label (and, possibly, the QoS
>> > > treatment to be
>> > > > > > given to the packet), writes the new label into the
>> packet, and
>> > > > > > forwards the packet to the next hop. "
>> > > > > >
>> > > > > > -> replace "core packet LSR" by "packet LSR"
>> > > > > >
>> > > > > > Section 3.2:
>> > > > > >
>> > > > > > 3. "SDH and SONET are two TDM standards widely used by
>> operators to
>> > > > > > transport and multiplex different tributary signals
>> over optical
>> > > > > > links, thus creating a multiplexing structure,
>> which we call the
>> > > > > > SDH/SONET multiplex. SDH, which was developed by the
>> > > ETSI and later
>> > > > > > standardized by the ITU-T [4], is now used worldwide,
>> > > while SONET,
>> > > > > > which was standardized by the ANSI [5], is mainly used
>> > > in the US.
>> > > > > > However, these two standards have several similarities,
>> > > and to some
>> > > > > > extent SONET can be viewed as a subset of SDH.
>> Internetworking
>> > > > > > between the two is possible using gateways.
>> > > > > >
>> > > > > > Should be rather as "ITU-T SDH (G.707) includes both
>> > > the European
>> > > > > > ETSI SDH hierarchy and the USA ANSI SONET hierarchy
>> > > (T1.105)." [...]
>> > > > > > "The ETSI SDH and SONET standards regarding frame
>> structures and
>> > > > > > higher order multiplexing are the same. There are
>> some regional
>> > > > > > differences on the terminology, on the use of some
>> > > overhead bytes,
>> > > > > > and lower order multiplexing. Interworking between
>> the two lower
>> > > > > > order hierarchies is possible using gateways."
>> > > > > >
>> > > > > > Section 3.2
>> > > > > >
>> > > > > > 4. "In addition, a pointer (in the form of the H1, H2
>> and H3 bytes)
>> > > > > > indicates the beginning of the VC/SPE in the payload of
>> > > the overall
>> > > > > > STM/SDH frame."
>> > > > > >
>> > > > > > -> replace "STM/SDH frame" by "STM/STS frame"
>> > > > > >
>> > > > > > Section 4.1
>> > > > > >
>> > > > > > 5. "The SONET case is a bit difficult to explain since,
>> > > unlike in SDH,
>> > > > > > SPEs in SONET do not have individual names." they are
>> > > > > simply referred
>> > > > > > to as VT-N SPE
>> > > > > >
>> > > > > > Section 6:
>> > > > > >
>> > > > > > 6. Since this document distinguishes between "optical
>> > > networks", TDM,
>> > > > > > and WDM it would advisable to avoid the "optical TDM"
>> > > as mentioned
>> > > > > > in the below sentence (it has another meaning than
MSn/RSn
>> > > > > switching)
>> > > > > >
>> > > > > > Section 6.1:
>> > > > > >
>> > > > > > 7. Table 2, misses the equivalence between VC-4 and STS-3c
SPE
>> > > > > >
>> > > > > > > Section 6.1:
>> > > > > >
>> > > > > > 8. "Standard and flexible concatenations are network
>> services, while
>> > > > > > virtual concatenation is a SONET/SDH end-system
>> service recently
>> > > > > > approved by the committee T1 of ANSI and ITU-T." remove
>> > > "recently
>> > > > > > approved by the committee T1 of ANSI and ITU-T." and
>> > > add the corr.
>> > > > > > reference.
>> > > > > >
>> > > > > > 9. "In one example of virtual concatenation, two end
>> > > systems supporting
>> > > > > > this feature could essentially "inverse multiplex" two
>> > > STS-1s into a
>> > > > > > virtual STS-2c for the efficient transport of 100 Mbps
>> > > > > Ethernet traffic."
>> > > > > >
>> > > > > > -> STS-1-2v instead of "virtual STS-2c"
>> > > > > >
>> > > > > > 10. "Section layer: Preserves all section overhead,
>> > > Basically does not
>> > > > > > touch any of the SONET/SDH bits."
>> > > > > >
>> > > > > > -> replace last part by "Basically does not modify or
terminate
>> > > > > > any of the SONET/SDH overhead bits"
>> > > > > >
>> > > > > > left column of the table misses the SDH overhead
equivalent
>> > > > > >
>> > > > > > 11. Multiplexing of (?) in the following sentence "To
perform
>> > > > > > multiplexing, a SONET network element should be line
>> > > terminating."
>> > > > > >
>> > > > > > Section 6.2:
>> > > > > >
>> > > > > > 12. In the following "Standardized SONET line level
protection
>> > > > > techniques
>> > > > > > include: Linear 1+1 and linear 1:N automatic
>> > > protection switching
>> > > > > > (APS) and both two-fiber and four-fiber bi-directional
>> > > > > line switched
>> > > > > > rings (BLSRs). At the path layer, SONET offers
>> > > uni-directional path
>> > > > > > switched ring protection." the same applies to SDH (to
>> > > be adapted
>> > > > > > using the corr. terminology)
>> > > > > >
>> > > > > > Section 7:
>> > > > > >
>> > > > > > 13. "This VC-4 LSP can, in fact, be established between two
non-
>> > > > > > adjacent internal nodes in an SDH network, and later
>> > > > > > advertised by a routing protocol as a new (virtual)
link
>> > > > > > called a Forwarding Adjacency (FA)." -> add
>> MPLS-HIERARCHY as
>> > > > > > reference
>> > > > > >
>> > > > > > 14. The following paragraph
>> > > > > > "For instance, the payload of an SDH STM-1 frame
>> does not fully
>> > > > > > contain a complete unit of user data. In fact, the
>> > > user data is
>> > > > > > contained in a virtual container (VC) that is allowed
to
>> > > > > float over
>> > > > > > two contiguous frames for synchronization purposes. A
>> > > > > pointer in the
>> > > > > > Section Overhead (SOH) indicates the beginning of the
>> > > VC in the
>> > > > > > payload." mixes SDH with SONET - pointers in SDH
>> in H1/H2/H3
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > >
>> > > >
>> > > >
>> > > >
>> > >
>> >
>> >
>> >