[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
> -----Original Message-----
> From: Ben Niven-Jenkins [mailto:firstname.lastname@example.org]
> Sent: Thursday, January 24, 2008 3:40 PM
> To: PAPADIMITRIOU Dimitri; Lou Berger
> Cc: Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS; email@example.com
> Subject: Re: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
> 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,
> 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.