RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt

["PAPADIMITRIOU Dimitri" <Dimitri.Papadimitriou@alcatel-lucent.be>]

ben 

> -----Original Message-----
> From: Ben Niven-Jenkins [mailto:benjamin.niven-jenkins@bt.com] 
> Sent: Thursday, January 24, 2008 3:40 PM
> To: PAPADIMITRIOU Dimitri; Lou Berger
> Cc: Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS; ccamp@ops.ietf.org
> Subject: Re: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
> 
> Dimitri,
> 
> I find your mail somewhat puzzling.
> 
> You appear to be saying that GMPLS as per RFC 3945 is set in stone and
> nothing should modify/enhance the behaviour as specified in 
> RFC3945 which
> implies that when RFC3945 was produced the crystal ball was working
> extremely well and all possible future applications of the 
> technology had
> been correctly envisaged.  I don't believe that was the case.

this is not what i say. i am concerned in stating beforehand
RFC 3945 (GMPLS Arch.) is not applicable to Ethernet. Why the
doc. does not deliver any tangible explanation.

> > the question triggered by this poll is the following: if GMPLS for
> > Ethernet is not inline with the existing stacks what is the value of
> > GMPLS re-use ? what's the value to borrow the term GMPLS without its
> > substance ? and in practice, the issue is, if it is not 
> GMPLS per RFC
> > 3945, what's the value compared to any other native control 
> stack that
> > would be developed at IEEE for inst. for these techno's.
> 
> If we ignore the peer model (which is unworkable in reality 
> IMO), the value
> is obvious - significant reuse of existing code, techniques, 
> knowledge,
> skills, etc.
> 
> So, we should develop the control plane from scratch because Ethernet
> requires a few modifications/enhancements (which I believe 
> are backwards
> compatible) to RFC3945 - that IMO is ridiculous.

so you seem to agree with me. departing from RFC 3945 makes
little sense. it would have been interesting to see the doc
delivering a FIT of the GMPLS protocol arch. blocks and, in
particular, label allocation and distribution for Ethernet.

thanks,
-dimitri.
> Ben
> 
>