Subject: Re: [mpls] AddressList TLV in MAC Address Withdraw message

From: Kishore Tiruveedhula <[email-masked]>
Date: Tue, 29 Mar 2011 09:55:34 -0400

Egor,
Regarding including the empty AddressList TLV while withdrawing the MAC addresses, I think It doesn't make sense to add empty address List TLV as it doesn't convey any information.  It is not mentioned about including the empty AddressList TLV in addition to MACList TLV in this RFC 4762.  Can authors of RFC 4762 clarify this?

And the empty address TLV is not defined in the RFC 5036, So, this would be treated as Malformed TLV due to short TLV length as there are no addresses present in the TLV.  I think this is valid for any other TLVs also. For example, if you receive the FEC TLV with no fecs, do you accept empty FEC TLV? Do you think accepting empty TLVs valid?

Thanks,
Kishore

----- Forwarded Message ----
From: Egor Zimin <[email-masked]<mailto:[email-masked]>>
To: Ina Minei <[email-masked]<mailto:[email-masked]>>; Bob Thomas <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Sent: Sun, February 27, 2011 4:23:15 AM
Subject: [mpls] AddressList TLV in MAC Address Withdraw message

Hi Ina,

Few days ago we had a deal with an interesting case of LDP interoperability. The root cause of our problem was the presence of empty "AddressList" TLV in LDP MacWithdraw message.
Vendor "C" inserts this TLV in every MAC Withdraw message even if there are no addresses to withdraw.
Their explanation:
---
"RFC 4762 introduces the MAC List TLV as an optional TLV to the Address Withdraw message, used to withdraw MAC addresses.  The addition of this optional TLV to the Address Withdraw message does not replace the Address List TLV.  While it would be perfectly acceptable to withdraw both IPV4 addresses as well as MAC addresses in the same Address Withdraw message, it's not always the case that there is a need to withdraw IPV4 addresses at the same time that there is a need to withdraw MAC addresses.  Also, given that the Address List TLV can not be omitted when sending an Address Message that withdraws MAC Addresses, the logical conclusion is to send an empty Address List TLV in the Address Withdraw message, along with the MAC List TLV. The empty address list TLV, while not explicitly specified, is not explicitly prohibited either. It would have been better had the RFCs been explicit on this subject, but the above logic is the best solution given the way that the RFCs are written."
---

Vendor "J" implies, that "AddressList" TLV is not mandatory in MACWithdraw message. They omit this TLV in their messages. However, in addition, they perform a strange check for minimal TLV length in all incoming messages. Because of this check empty AddressList TLV  (with length=2) considered as "Malformed TLV" and the session goes down.

I haven't found any mention about checking for "too short TLV" in RFC 5036. However, point #11 in chapter "7. Changes from RFC 3036" states:
---
      11. Added case for TLV length too short in the specification for handling malformed TLVs.
---
It would be great to know your opinion about these questions:
1. The presence of empty AddressList TLV in MACWithdraw message. Is it mandatory or optional?
2. Checking incoming TLVs for minimal length. Is it correct behavior ?  IMHO, it should be remembered about Jon Postel's law: "Be liberal in what you accept, and conservative in what you send"

-- Best regards,
Egor Zimin

_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls

---

From: Egor Zimin <[email-masked]>
Date: Tue, 29 Mar 2011 23:23:48 +0400

Kishore,

Probably yes. Probably it doesn't make sense to add empty address List TLV.
And - yes, it would be great if authors of 4762 clarified this.

However, what we have right now:
1. MAC Address Withdraw Message and Address Withdraw Message use the 
same message type (0x0301)
2. Address List TLV is mandatory in Address Withdraw message 
(http://tools.ietf.org/html/rfc5036#section-3.5.6)
3. However, we have no ipv4 addresses to withdraw
So, in this case the only way to meet all three conditions mentioned is 
to include empty AddressList TLV in MAC Address Withdraw Message.

Next.
Why you decide, that empty AddressList TLV is Malformed ? Are there any 
mentions about "too short TLV length" checking in 5036 ?
If no, is it liberal behavior ?
So: yes, I think, accepting empty TLV is valid in this case.

Regarding your question about FEC TLV:
FEC TLV is also mandatory in Label Mapping Message. If we have no FECs 
to advertise, we shouldn't send Label Mapping Message iirc. However, if 
there is any _other_ reason why we must send Label Mapping Message, than 
YES, we should include empty FEC TLV in this message. And this Message 
must be accepted. Because there is no any mention about "too short TLV 
length" check in 5036. And we should be liberal in what we accept.

P.S. By the way, this question was already asked by Vivienne(wanglixing 
at huawei.com):
http://www.ietf.org/mail-archive/web/mpls/current/msg01708.html
And there is still no answer.

And what is the most terrible thing:
Two leading vendors break absolutely legitimate design - pseudowire 
redundancy, where pseudowire has "C" as the first PE and "J" as the 
primary_second_PE and backup_second_PE. Just because of this "room for 
interpretation".

29.03.2011 17:55, Kishore Tiruveedhula ?????:
>
> Egor,
>
> Regarding including the empty AddressList TLV while withdrawing the 
> MAC addresses, I think It doesn't make sense to add empty address List 
> TLV as it doesn't convey any information.  It is not mentioned about 
> including the empty AddressList TLV in addition to MACList TLV in this 
> RFC 4762.  Can authors of RFC 4762 clarify this?
>
> And the *empty address TLV* is not defined in the RFC 5036, So, this 
> would be treated as Malformed TLV due to short TLV length as there are 
> no addresses present in the TLV.  I think this is valid for any other 
> TLVs also. For example, if you receive the FEC TLV with no fecs, do 
> you accept *empty FEC TLV?* Do you think accepting empty TLVs valid?
>
> Thanks,
>
> Kishore
>
> *From:* Egor Zimin <[email-masked] <mailto:[email-masked]>>
> *To:* Ina Minei <[email-masked] <mailto:[email-masked]>>; Bob Thomas 
> <[email-masked] <mailto:[email-masked]>>
> *Cc:* [email-masked] <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> *Sent:* Sun, February 27, 2011 4:23:15 AM
> *Subject:* [mpls] AddressList TLV in MAC Address Withdraw message
>
> Hi Ina,
>
> Few days ago we had a deal with an interesting case of LDP 
> interoperability. The root cause of our problem was the presence of 
> empty "AddressList" TLV in LDP MacWithdraw message.
> "RFC 4762 introduces the MAC List TLV as an optional TLV to the 
> Address Withdraw message, used to withdraw MAC addresses.  The 
> addition of this optional TLV to the Address Withdraw message does not 
> replace the Address List TLV.  While it would be perfectly acceptable 
> to withdraw both IPV4 addresses as well as MAC addresses in the same 
> Address Withdraw message, it's not always the case that there is a 
> need to withdraw IPV4 addresses at the same time that there is a need 
> to withdraw MAC addresses.  Also, given that the Address List TLV can 
> not be omitted when sending an Address Message that withdraws MAC 
> Addresses, the logical conclusion is to send an empty Address List TLV 
> in the Address Withdraw message, along with the MAC List TLV. The 
> empty address list TLV, while not explicitly specified, is not 
> explicitly prohibited either. It would have been better had the RFCs 
> been explicit on this subject, but the above logic is the best 
> solution given the way that the RFCs are written."
> ---
>
> Vendor "J" implies, that "AddressList" TLV is not mandatory in 
> MACWithdraw message. They omit this TLV in their messages. However, in 
> addition, they perform a strange check for minimal TLV length in all 
> incoming messages. Because of this check empty AddressList TLV  (with 
> length=2) considered as "Malformed TLV" and the session goes down.
>
> I haven't found any mention about checking for "too short TLV" in RFC 
> 5036. However, point #11 in chapter "7. Changes from RFC 3036" states:
> ---
> 2. Checking incoming TLVs for minimal length. Is it correct behavior 
> ?  IMHO, it should be remembered about Jon Postel's law: "Be liberal 
> in what you accept, and conservative in what you send"
>
> -- Best regards,
> Egor Zimin
>
> [email-masked] <mailto:[email-masked]>

-- 
Best regards,
  Egor Zimin