[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: FW: Layer 2 Switching Caps LSPs
Hi Don,
Refer below for my responses (db)-
Thanks-
Deborah
-----Original Message-----
From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On
Behalf Of Don Fedyk
Sent: Thursday, February 10, 2005 9:41 AM
To: dpapadimitriou@psg.com; dimitri.papadimitriou@alcatel.be
Cc: ccamp@ops.ietf.org
Subject: RE: FW: Layer 2 Switching Caps LSPs
Hi Dimitri
> -----Original Message----- From: dimitri papadimitriou
> [mailto:dpapadimitriou@psg.com] Sent: Wednesday, February
> 09, 2005 6:33 PM To: Fedyk, Don [BL60:1A00:EXCH] Cc:
> ccamp@ops.ietf.org Subject: Re: FW: Layer 2 Switching Caps
> LSPs
>
>
> don,
>
> Don Fedyk wrote:
> > Resending, ccamp list message never came through
> > ------------------------------------------------
> >
> > Hi
> >
> > I read through this draft and the thread and I don't see
> > that much detail. Dimitri your statements are more about
> > what this draft is not
> > about. While they would be useful additions in the draft
> > for clarification, how does this draft differ from one
> > that just says: "Lets define some code points for TLVs
> > for future signaling of packet
> > technologies, ATM, FR and Ethernet"?
>
> the document details RSVP-TE processing (beside
> introducing rationales) and does not limit to a list of
> codepoints, at the end and when looking at the additional
> code-points (beside new C-Types) this constitute a small
> part of this document (section 5.1) for the LSP encoding
> type
Yes but without a picture like:
ATM UNI-[gmpls controlled ATM i/f]-ATM PNNI etc
I'm left guessing where this is really headed. The processing is in the
context of the new code points.
Db> The draft was intended as a discussion of RFC3945 with respect to
L2LSP. From the discussion, there does seem to be confusion on the
current descriptions in 3945/3473, including concerns on why L2 was
included under GMPLS, why GMPLS and not MPLS (or Ethernet), so the draft
has been successful. It's a first cut, and it's hoped there's group
interest in adding the details.
>
> > This is very similar to another SDO just asking for a
> > few code points IMHO.
>
> i don't see what differs in terms of approach from other
> technologies currently being more detailed as part of the
> GMPLS coverage
You have a point. GMPLS was/is defined to a level of abstraction such
that
we need to describe it to people
beyond what is in the documents today. GMPLS is so large we had to
start
somewhere, but do we continue just refining
or do we drill down to bedrock with a few select technologies? I would
prefer if we could drill down. I
think that is what the debate is really.
Db> Yes, some do prefer to limit it to one layer/technology at a time.
And it seems as each technology has been tackled, there has been great
resistance;-) Others of us are hoping it will do it's original premise
of providing a consistent control plane for multiple technologies:
ftp://ftp.isi.edu/internet-drafts/draft-oki-ccamp-gmpls-ip-interworking-
04.txt
ftp://ftp.isi.edu/internet-drafts/draft-shiomoto-ccamp-gmpls-mrn-reqs-00
.txt
>
> for the technical rationale, it comes from the definition
> introduced in LSP-hierarchy document that introduces
> classes of resources (in terms of switching capability)
> and LSP regions, however at some point in time there is a
> need to distinguish between the common part and the
> technology specific part (in particular when the target is
> a unified TE model) that needs only to be supported by
> nodes capable to initiate LSPs across the corresponding
> region (L2SC in the present context)
>
> > Would it not be better to detail one technology and
> > transport mode in detail, rather than slowly refining
> > the signaling for multiple technologies?
>
> what do you mean by "detail one technology and transport
> mode" ? clarification would be helpful in order for me to
> understand this comment
Really it was the point above if we continue to specify abstractly we
raise
a lot of questions particularly where active standardization is going on
like Ethernet. If we cannot drill down to a particular usage scenario
is
the work really needed at this point in time?
Regards,
Don
>
> thanks,
> - dimitri.
>
> > Regards,
> > Don
> >
<snip>