Subject: [mpls] Meaning of sub-TLVs for TLV 21 in Return Path Specified

From: "George Swallow (swallow)" <[email-masked]>
Date: Tue, 21 May 2013 16:22:52 +0000

Mach, et al. -

In section 4.1. Sending an Echo Request, it is stated:

The Reply Path TLV includes one or several reply path sub-TLV(s) to
identify the return path(s) the egress LSR should use for its reply.

It would appear that the semantics of TLV 21 are very different than the semantics of TLV 1.  Since TLV 1 defines a FEC stack which maps to a single LSP.  Why do you want the NIL FEC which only makes sense as part of a FEC stack?

Under what circumstances would you ever use one of the multicast FECs (sub-TLVs 17, 18, 19, 20)?

What is the meaning of a return path to a VPN IPv4 prefix, or  VPN IPv6 prefix?  Note that if the prefix is multi-homed it may not even return to the originating PE!

What is the meaning of a return path to an L2 VPN endpoint?

George

---

From: Mach Chen <[email-masked]>
Date: Wed, 22 May 2013 05:38:16 +0000

Hi George,

I guess your question is that why TLV 21 have to apply all the sub-TLVs of TLV 1.

For TLV 21, there are at least two usages, one is for specifying the return path of the echo reply, and if just for specifying the return path of echo reply, yes, it may not necessary to use all sub-TLVs of TLV 1. The other is for testing and validating the specified return path by carrying TLV 21( just as the FEC Stack TLV for forward path). For usage 2, the TLV 21 should have the same semantics as TLV 1, thus applying all sub-TLVs of TLV 1 is reasonable.

Many thanks,
Mach

From: [email-masked] [mailto:[email-masked]] On Behalf Of George Swallow (swallow)
Sent: Wednesday, May 22, 2013 12:23 AM
To: [email-masked]
Cc: [email-masked]
Subject: [mpls] Meaning of sub-TLVs for TLV 21 in Return Path Specified

Mach, et al. -

George

---

From: "George Swallow (swallow)" <[email-masked]>
Date: Wed, 29 May 2013 13:01:32 +0000

Mach -

Sorry for the delay.

So you have two different uses for one tlv. That in itself is not all that bad. But apparently what you have is two uses where;

1. The semantics of the sub-tlvs change completely depending on which way you are you are using the tlv.

2. The allowable sub-tlvs vary with the usage of the tlv.

Further, on re-reading the draft these two uses are not clearly delineated.

It would be a much better protocol design to have two tlvs. In what you call case 2 below, the Tlv could reuse the sub-tlvs of tlv 1. In what you call case one, the sub-tlvs would go into a registry specific to the tlv for case 1.  This would list only those sub-tlvs of tlv 1 that are valid for this case.  By list I mean explicitly list (not reference). It would also list the new tlvs you have defined.

George

On May 22, 2013, at 1:39 AM, "Mach Chen" <[email-masked]<mailto:[email-masked]>> wrote:

Hi George,

Many thanks,
Mach

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of George Swallow (swallow)
Sent: Wednesday, May 22, 2013 12:23 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [mpls] Meaning of sub-TLVs for TLV 21 in Return Path Specified

Mach, et al. -

George

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

---

From: Mach Chen <[email-masked]>
Date: Thu, 30 May 2013 06:13:14 +0000

Hi George,

Thanks for your reply!

I just re-read the draft,  and compare the two usages, the only sub-TLV that may not suitable for specifying (in echo request) return path is the Nil sub-TLV.  And you still can find in the IANA registry page, it did explicitly list some of the sub-TLVs of TLV 1 for TLV 21, this is proposed in the early version of this draft, just as you suggested below.

But eventually found TLV 21 could actually apply all the sub-TLVs (of cause, Nil sub-TLV should be excluded) of TLV 1, and also found there is a precedent of such usage (TLV 16), this will largely reduce the redefinition of sub-TLVs. In addition, if we list sub-TLVs one by one, it may lose sub-TLVs and cannot automatically inherit future defined sub-TLVs. These are the reason and motivation for current choice.

So, if just to solve the allocation issue TLV 21 faced,  I am personally fine with each way of those proposed solutions.  But I still believe that draft-pac is a better way, it makes the allocation easier and clearer.

Best regards,
Mach

From: George Swallow (swallow) [mailto:[email-masked]]
Sent: Wednesday, May 29, 2013 9:02 PM
To: Mach Chen
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls] Meaning of sub-TLVs for TLV 21 in Return Path Specified

Mach -

Sorry for the delay.

George

Many thanks,
Mach

Mach, et al. -

George