RE: Moving right along ...

["Mannie, Eric" <[e-mail]>]

Hello Juergen,

Your comments are addressed hereafter. Note that you didn't raised any
technical problem or mistake in your comments (i.e. the draft "works" very
well as it is).

- the first comment is not about a technical issue but an "editorial" issue.
- the second comment is about a change that will not bring any new
capability.

>Concerning the SDH/Sonet documents I want to raise a formal issue.
>We have now two documents, a document that covers ITU/ANSI standard
features (draft-ietf-ccamp-gmpls-sonet-sdh-02.txt) and a document that
covers non-standard features
(draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt). However in Appendix 1
of the standard feature document a non standard feature (Group signals) is
listed. It is even mentioned that the use of groups (AUG, STSG, ...) is not
described in standards. So this feature should be moved to the non-standards
document. Otherwise the split of the documents doesn't make sense.

We spend a considerable amount of time speaking about this particular issue
and I still don't see any technical justification for what you said.

For those who are not SDH/SONET experts some quick explanation:

We call a "super-circuit" a set of physical circuits in the transport plane
all belonging to the same LSP in the signaling plane. We defined two kinds
of super-circuits: "group circuits" and "multiplicative circuits".

Multiplicative circuits are setup using the multiplier field that we defined
(e.g. to say "I want 5 STS-1 circuits in my LSP"). Juergen has no objection
about these ones.

Group circuits are setup using the SDH/SONET naming for groups, i.e. AUG,
TUG, VTG (we defined the equivalent signal type in the signaling). The
comment of Juergen is about these group circuits. A group circuit represents
some bandwidth at a given place in the SDH/SONET multiplex. The advantage of
such a super-circuit is that the customer can re-structure its content as
he/she likes. The operator doesn't care.

Such an application is possible and is already implemented. SDH/SONET is
self-describing, i.e. by looking at the signal one can understand how it is
structured (like Juergen explained on the mailing list), so one can setup a
circuit without describing the content (very very cool).

The transport plane ignores that the signaling plane uses an "abstraction"
(i.e. an LSP) representing several physical circuits. Note that restoration
and management belong respectively to the signaling plane and to the
management plane in the IETF view (not to the transport plane like in the
ITU-T view).

>From that point of view, group circuits are a GMPLS signaling plane feature
and not a transport plane feature. We put the comment on the fact that this
is not defined (like GMPLS LSPs, etc) by ITU-T to make some guys happy.

I could say clearly at the beginning of the draft that the signal types that
we are defining in this document are not ITU-T signal types but GMPLS signal
types (of course) whose have in some cases a direct relationship with the
ITU-T signal types.

Any objection ?

>For the Sonet and SDH labels in draft-ietf-ccamp-gmpls-sonet-sdh-02.txt I
prefer to have the same coding for Sonet and SDH. That makes the
implementation for Sonet and SDH simpler. Furthermore ITU and T1 have tried
over the last years to align Sonet and SDH as much as possible. The
definition of different labels for Sonet and SDH contradicts these
activities.

We discussed this one since a long time as well. Let me be clear:

- labels are local to an interface (we all agree).
- a link (interface) is operated at one point in the time as either SDH or
SONET.
- your proposal will require to re-evaluate many things.
- and it took us a lot of time to fine-tune and to validate the current
label structure.
- we could have technical issues with your proposal that would impact more
than this draft (Dimitri saw some of them, please see with him).
- you never provided a complete analysis of your proposal.

But more important: your proposal doesn't bring any additional functionality
to the draft.

At this very late stage, since this not bringing any new functionality, and
since the label structure is very stable since a long time, I would prefer
not to restart a long technical discussion to change and re-validate the
draft.

Kind regards,

Eric


 
> -----Ursprüngliche Nachricht-----
> Von: Kireeti Kompella [mailto:[e-mail]]
> Gesendet: Mittwoch, 17. Oktober 2001 11:25
> An: [e-mail]
> Betreff: Moving right along ...
> 
> 
> Despite the energetic subject line, we the WG chairs have been
> lax in our duties.  So, here goes:
> 
> Lou has submitted the latest versions of the generalized
> signaling documents quite some time ago (thanks, Lou):
> 
> draft-ietf-mpls-generalized-cr-ldp-04.txt
> draft-ietf-mpls-generalized-rsvp-te-05.txt
> draft-ietf-mpls-generalized-signaling-06.txt
> 
> Also, Eric has posted the SONET/SDH documents (merci, Eric):
> 
> draft-ietf-ccamp-gmpls-sonet-sdh-02.txt
> draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt
> 
> All of these should have addressed the issues raised in the earlier
> versions.  Please read the new versions, and send your comments to
> the list by Tuesday Oct 23.  At that point, when the final round
> of comments have been addressed, these docs will go to IESG Last
> Call.  If any one objects to sending these docs to IESG Last Call,
> raise your issues now.
> 
> I see that the GMPLS architecture document is a CCAMP WG doc, but
> the minutes say that we should look for consensus on the list.  So,
> if you think this doc *shouldn't* be a WG doc, let us know.  (If we
> arrived at a consensus, remind me :-))  If nothing is heard, the doc
> will progress to WG Last Call.
> 
> The docs draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt and
> draft-fontana-ccamp-gmpls-g709-00.txt were under consideration to be
> CCAMP WG docs; consensus at the meeting was Yes.  Please let the
> list know what your thinking is on these.  (BTW, both these docs
> were to have some edits done.  If the authors could do that before
> the next IETF, we can try to make more progress then.)
> 
> The MIB overview doc was recently posted.  Please read and comment
> to the list.
> 
> The doc draft-bms-optical-sdhsonet-mpls-control-frmwrk-01.txt
> was generally thought to be useful; it will be published as a
> CCAMP informational doc.  This begins a two week Last Call on
> the doc, ending Tuesday Oct 30.
> 
> There was no consensus on whether the GMPLS framework should be
> a CCAMP WG doc.  Please indicate your pleasure.
> 
> draft-ietf-ccamp-lmp-01.txt has been posted.  The thought was
> raised that this draft is close to ready for WG Last Call.  Please
> review it, and let us know if you disagree.
> 
> The OLI requirements doc was broadly accepted.  Please let the
> list know if you think this doc should be a WG doc.
> 
> It's still open whether we (the IETF) should be working on
> LMP-WDM.  I urge the authors to keep on working on the doc, and
> keeping it in sync with LMP; however, we will postpone making it
> a CCAMP WG doc until the issue is resolved.  Hopefully that will
> happen in Salt Lake City.
> 
> There was reasonable interest in the tunnel trace requirements
> doc.  Let's formalize this: do you think this should be made a
> CCAMP WG document?
> 
> Summary:
> 
> 1) Final comments and IESG Last Call readiness for:
> draft-ietf-mpls-generalized-cr-ldp-04.txt
> draft-ietf-mpls-generalized-rsvp-te-05.txt
> draft-ietf-mpls-generalized-signaling-06.txt
> draft-ietf-ccamp-gmpls-sonet-sdh-02.txt
> draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt
> 
> 2) Should the following documents be CCAMP WG docs?
> draft-bonica-tunneltrace-02.txt
> draft-fontana-ccamp-gmpls-g709-00.txt
> draft-ietf-ccamp-gmpls-architecture-00.txt
> draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt
> draft-many-ccamp-gmpls-framework-00.txt
> draft-many-oli-reqts-00.txt
> 
> 3) Comment on MIB overview.
> 
> 4) Two week Last Call comments on
> draft-bms-optical-sdhsonet-mpls-control-frmwrk-01.txt
> 
> 5) Last Call readiness of
> draft-ietf-ccamp-gmpls-architecture-00.txt
> draft-ietf-ccamp-lmp-01.txt
> 
> Thanks,
> Kireeti.
>