|
Hi, Please
refer to my answer inline to your comments. Thanks, Pranjal From:
l2vpn-bounces at ietf.org [mailto:l2vpn-bounces at ietf.org] On Behalf Of Jiang Yuan-long Hi Dutta, I have a few comments on this draft: 1. From the description in the draft, it
seems only one PE-ID is needed for your mechanism. But in the definition
of PE-ID TLV in section 4, a list of one or more PE-ID may be
included, but do we really need more than one PE-ID element? Can you give some
clues on its usage? "The PE-ID TLV carries the unique
identifier of a generic PW endpoint". [Pranjal] Yes, that’s
correct. PE-ID TLV can accommodate a LIST of PE-ID Elements. Today
implementations can send
a list of FEC Elements within a FEC TLV sent in the MAC flush message. A common
network event
may trigger failure of primary PWs for a set of VPLS instances together, which
requires to send mac flush for
all those instances. Sending an individual LDP MAC flush message per VPLS
instance is sub-optimal and so
MAC flush for a set of VPLS instances are bundled in a single message. Same
applies to optimized MAC
flush with PE-ID as well. 2. The length of the FEC-128 specific
PE-ID element is given as 2 octets, should the correct length be 8? [Pranjal] That’s
right. It’s a typo. It should have been 8 octets. We will correct it in
the next revision. 3. Maybe the FEC-129 specific PE-ID
Element needs another extra field for PE address, as AII TLVs can only be
null according to RFC 4762 in section 6.1.1, while AGI TLV can only
give you information on VPLS instance. [Pranjal] RFC 4762 also
specifies that use of non-null SAII and TAII would be addressed in future
revision. Today, FEC 129 is
used in VPLS provisioned with BGP-AD where SAII/TAII always carry valid end-point
identifiers (VS-ID) as per l2vpn signaling draft below. http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-signaling-08.txt RFC 4762 kept a provision
for NULL SAII/TAII if FEC 129 is used non BGP-AD deployments to replace FEC 128.
But if you see
AGI definition in RFC 4446 (that carries vpls-id as per RFC 4762), only one
type is allocated to be used in BGP-AD provisioned
VPLS from L2 VPN signaling draft. 4. I think this mechanism only works
properly in a scenario where the MTU-s, PE-1 and PE-2 all play in harmony,
otherwise, if MTU-s sends out a RFC4762 compatiable flushing msg,
while PE-1 sends out a flushing msg with PE-ID, then other PEs in the
VPLS will process both msgs and the result is flushing all MACs. So maybe
this should be pointed out in the applicability section. [Pranjal] Following is stated in the section 5. Application of PE-ID TLV in Optimized MAC Flush
However the inclusion of the FEC-TLV should be based on what would be the desired effect should the PE-ID not be understood by the receiver. In cases where the desired action when the PE-ID is not understood would be to behave as described in [RFC4762], then the FEC TLV SHOULD be included. In cases where the desired action when the PE-ID is not understood is to take no action, then the FEC TLV SHOULD NOT be included. Are you suggesting for more explanation in that section?
5. Some random corrections: page 6, "...So the MAC addresses
that require flushing and relearning at PE-2 are only the MAC addresses those
have been learned on the PW connected to PE-1." is redundant,
maybe it is better to say "...So the MAC addresses that require flushing and
relearning at PE-2 are only those MAC addresses learned on the PW connected
to PE-1.". [Pranjal] Sure, we would address this in
the next revision. Thanks Yuanlong Jiang |