RE: FW: Layer 2 Switching Caps LSPs

["Don Fedyk" <dwfedyk@nortel.com>]

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. 

> 
> > 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. 

> 
> 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>