|
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?
IMO, this definition is also in contradiction to the prior sentence "The PE-ID TLV carries the unique
identifier of a generic PW endpoint".
2. The length of the FEC-128 specific
PE-ID element is given as 2 octets,
should the correct length be
8?
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.
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.
5. Some random
corrections:
s/ignored/ignored by/ 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.".
Thanks
Yuanlong
Jiang
|