[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: draft-fedyk-gmpls-ethernet-pbt-00.txt
Hi Lucy Yong,
PBT is almost the data plane of Ethernet, with some modifications, as
follows:
1. Flooding is disabled for the range of PBT VIDs.
2. Broadcast and multicast are disabled for the range of PBT VIDs.
3. Unknown frames are discarded.
4. PBT VIDs must be related to an STP instance and the STP state of the
port must always be enabled to allow data plane forwarding of frames.
Please note that this must be done, because with the current
specifications any VID must relate to an STP instance.
Best regards,
Nurit
-----Original Message-----
From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On
Behalf Of Lucy Yong
Sent: Friday, June 30, 2006 18:31
To: 'Don Fedyk'; 'Igor Bryskin'; ccamp@ops.ietf.org; gels@rtg.ietf.org
Subject: RE: draft-fedyk-gmpls-ethernet-pbt-00.txt
Don,
Thank you for writing this draft. It is very informative.
PBT is simply the data plane of Ethernet (802.1Q and 8021.ah) without a
Spanning tree control plane. As a result, this data plane does not have
knowledge of how to forwarding the traffic anymore. The purpose of the
draft is to suggest building a new control plane which can build
forwarding path for all kinds of service requests as mentioned in
document.
Building a new control plane for Ethernet network sounds great!! The
draft mentions in several places a desire of some level of
administrative management in building forwarding path. I would like to
ask a basic
question:
The network with this new control plane should have the intelligence of
routing and traffic engineering to allow the network building forwarding
path automatically; or The network should not have that intelligence,
forwarding path should be selected by the network management system,
network only needs signaling capability to build forwarding path.
Which model do you pursue for PBT, why?
Best Regards,
Lucy Yong
-----Original Message-----
From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On
Behalf Of Don Fedyk
Sent: Monday, June 26, 2006 10:50 AM
To: Igor Bryskin; ccamp@ops.ietf.org; gels@rtg.ietf.org
Subject: RE: draft-fedyk-gmpls-ethernet-pbt-00.txt
> -----Original Message-----
> From: owner-ccamp@ops.ietf.org
> [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Igor Bryskin
>
> Thanks Don,
>
> See in-line.
>
> Igor
>
> ----- Original Message -----
> From: "Don Fedyk" <dwfedyk@nortel.com>
>
<snip>
>
> So you have two questions: Do we need Auto-discovery; and if so should
> it be IGP based or BGP based.
> In the simple mode we have specified so far MAC Learning on the edge
> is all we need. So no auto discovery.
>
>
> IB>> Well, MAC Learning tells edge switch which port an
> Ethernet packet
> destined to a particular D-MAC should be sent out. However, it does
> not tell the TE name of the edge switch (on the opposite side of the
> network) supporting this D-MAC. So how the ingress switch can tell
> (without auto-discovery or configuration) which of (new or existing)
> Eth-LSPs could be used for the packet forwarding?
>
> Thanks,
> Igor
>
To be clear on this the association is made statically up front in the
current document. No new Eth-LSPs are set up due to the arrival of an
new D-MAC. There is a static binding of a Customer Port to a Ethernet
LSP. There is a static binding of the Eth-LSP to a destination switch.
At the ingress provider node and a destination provider node typically a
PW identifier or a PPB I-SID is used to mux/demux the packet on the
Eth-LSP. You could also have a dedicated Eth-LSP with no multiplexer.
Regards,
Don
(text below is consistent with this if we do what you are alluding to in
the future)
> However if we ever get to on demand
> signaling on the connections from the customer space then an auto
> discovery function would be desirable.
>
> As to IGP or BGP, very similar to the L1VPN case. We have discussed
> keeping the Optical code base and the Ethernet code base development
> based on the same architecture. I don't see much difference here we
> could develop either it depends on customer demand for such a feature.
> Currently out of scope for us.
>
> Regards,
> Don
>
> >
> > It would be good if your draft would provide some of your views on
> > such mechanism and, more generally, on which routing protocols
> > should be supported by GMPLS controllers managing Ethernet switches.
> > Obviously, IGP-TE is going to be required to enable path
> > computation. But how about BGP?
> >
> > Thanks,
> > Igor
> >
> <snip>
>
>
>
>