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

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

Don,

then two things are missing that this new xSC is not resulting in a
control plane departing from RFC 3945 and this xSC is not part
overlapping with L2SC. 

you are thus in the alternative: GMPLS for Y architecture, where Y is
not compatible with the existing definition of Eth frame processing per
L2SC ? is that correct.

thanks,
-d.




 

> -----Original Message-----
> From: Don Fedyk [mailto:dwfedyk@nortel.com] 
> Sent: Tuesday, January 22, 2008 10:35 PM
> To: PAPADIMITRIOU Dimitri; BRUNGARD, DEBORAH A, ATTLABS; 
> ccamp@ops.ietf.org
> Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
> 
> Hi Dimitri
> 
> The text you quote was put in the architecture/ framework, not to
> exclude L2 Switch Capable (L2SC) but to prevent redefining L2SC, which
> has been there for many years and may be in use. 
> 
> Perhaps the working needs to be adjusted but I don't think it 
> is a major
> issue.
> 
> Regards,
> Don 
> 
> > -----Original Message-----
> > From: owner-ccamp@ops.ietf.org 
> > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of PAPADIMITRIOU Dimitri
> > Sent: Tuesday, January 22, 2008 4:16 PM
> > To: BRUNGARD, DEBORAH A, ATTLABS; ccamp@ops.ietf.org
> > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
> > 
> > All,
> > 
> > > We received a couple of comments in the meeting, we would 
> > > appreciate additional feedback on the list.
> > 
> > The document states:
> > 
> > "The L2SC Interface Switching Capabilities MUST NOT be used 
> > to represent
> > interfaces capable of supporting Eth-LSPs. Interface Switching
> > Capability specific TE information may be defined as needed 
> to support
> > the requirements of a specific Ethernet Switching Service Type."
> > 
> > [...]
> > 
> > "It is expected that there will be no case where an Eth-LSP will be
> > signaled, or an Eth-LSP supporting interface will be 
> > represented, using
> > the L2SC switching type/capability. A new switching 
> type/capability is
> > required to avoid any potential current usage of the L2SC switching
> > type/capability in support of Ethernet."
> > 
> > This is explicit statement that GMPLS per RFC 3945 is not 
> applicable.
> > So, it is much more than just an additional codepoint, as 
> the control
> > plane behaviour is to be defined for this codepoint. So, it 
> > is the open
> > door for a new control plane behaviour. 
> > 
> > so, let's have a more basic questioning before jumping into 
> the single
> > alternative resulting from this doc.:
> > 
> > - either it is GMPLS for Ethernet architecture and then 
> what exist in
> > current RFCs should be applicable (because i do not see any 
> rationale
> > for L2SC def. departure for Ethernet frame processing);
> > 
> > - or not it is X for Y architecture, where X is an IP 
> control protocol
> > based some potentially on some existing GMPLS blocks and Y is not
> > compatible with the existing definition of Eth frame processing.
> > 
> > In the latter case, i do not know how this WG can deal with 
> such case
> > (from the control plane perspective).
> > 
> > -d.
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: owner-ccamp@ops.ietf.org 
> > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of BRUNGARD, 
> > > DEBORAH A, ATTLABS
> > > Sent: Tuesday, January 22, 2008 8:28 PM
> > > To: ccamp@ops.ietf.org
> > > Subject: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
> > > 
> > > CCAMP,
> > >  
> > > The DT proposed in their meeting presentation for their 
> > > architecture and framework document to be accepted as a WG draft:
> > > 
> http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt
> > >  
> > > We received a couple of comments in the meeting, we would 
> > > appreciate additional feedback on the list. Please express 
> > > your support (or otherwise) for this I-D to become a WG draft.
> > >  
> > > Thanks,
> > > Deborah
> > > 
> > 
> > 
>