Subject: [PWE3] Solicit comments on draft-chen-mpls-ipv6-pw-lsp-ping

From: Mach Chen <[email-masked]>
Date: Thu, 24 Nov 2011 02:46:55 +0000

Hi,

We presented the draft in IETF 82th meeting (both in MPLS and PW3 WG) and did not receive technical comments there. Although the authors think that the draft is quite straightforward and stable, we'd like that you could spend some time to read the draft and give your comments. 

Any comments and feedbacks are appreciated!

Here is the pointer: http://tools.ietf.org/html/draft-chen-mpls-ipv6-pw-lsp-ping-02 .

Many thanks,
Mach

---

From: Spike Curtis <[email-masked]>
Date: Thu, 24 Nov 2011 12:22:02 +0000

Hi Mach,

I agree that the draft is straightforward, so I only have comments intended to improve the clarity, rather than the technical details.

In the introduction and abstract you state that there is ambiguity in the currently defined sub-TLVs that is resolved by looking at the sub-TLV length.  Really, it isn't the sub-TLV length itself that determines this, but the length of the address fields.  I think what you are getting at would be more clearly stated with something like the following.

"Although the sub-TLVs defined for pseudowires in RFC 4379 are not explicitly restricted to IPv4 LDP sessions, this restriction is clearly inferred by examining the lengths of the Sender/Remote PE Address fields.  These sub-TLVs cannot be used for pseudowires signalled in IPv6 LDP sessions since the addresses will not fit."

Cheers,
Spike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mach Chen
Sent: Thursday, November 24, 2011 2:47 AM
To: [email-masked]
Cc: [email-masked]
Subject: [mpls] Solicit comments on draft-chen-mpls-ipv6-pw-lsp-ping

Hi,

Many thanks,
Mach
_______________________________________________
mpls mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 24 Nov 2011 07:54:54 -0600

Spike,

I think this clarification sounds reasonable. Thank you.

-- Carlos.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Spike Curtis
Sent: Thursday, November 24, 2011 7:22 AM
To: Mach Chen; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls] Solicit comments on draft-chen-mpls-ipv6-pw-lsp-ping

Hi Mach,

I agree that the draft is straightforward, so I only have comments
intended to improve the clarity, rather than the technical details.

In the introduction and abstract you state that there is ambiguity in
the currently defined sub-TLVs that is resolved by looking at the
sub-TLV length.  Really, it isn't the sub-TLV length itself that
determines this, but the length of the address fields.  I think what you
are getting at would be more clearly stated with something like the
following.

"Although the sub-TLVs defined for pseudowires in RFC 4379 are not
explicitly restricted to IPv4 LDP sessions, this restriction is clearly
inferred by examining the lengths of the Sender/Remote PE Address
fields.  These sub-TLVs cannot be used for pseudowires signalled in IPv6
LDP sessions since the addresses will not fit."

Cheers,
Spike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Mach Chen
Sent: Thursday, November 24, 2011 2:47 AM
To: [email-masked]
Cc: [email-masked]
Subject: [mpls] Solicit comments on draft-chen-mpls-ipv6-pw-lsp-ping

Hi,

We presented the draft in IETF 82th meeting (both in MPLS and PW3 WG)
and did not receive technical comments there. Although the authors think
that the draft is quite straightforward and stable, we'd like that you
could spend some time to read the draft and give your comments. 

Here is the pointer:
http://tools.ietf.org/html/draft-chen-mpls-ipv6-pw-lsp-ping-02 .

Many thanks,
Mach

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 24 Nov 2011 11:13:10 -0600

iLya,

I would thing that such an provision is not specific to the Target FEC
Sub-TLVs for IPv6 PWs, and consequently out of scope of this document.
Note also that this is not a "v6 LSP Ping" spec as it does not cover
'LDP|VPN|BGP labeled|Generic IPv6 prefix' or 'RSVP IPv6 LSPs'.

There's also potentially the use of Reply Modes in RFC4379, as well as
other more generic solutions to that, which should be applicable to v4
and v6 LSP Traceroute.

Thanks,

-- Carlos.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
iLya
Sent: Thursday, November 24, 2011 10:58 AM
To: Mach Chen; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls] Solicit comments on draft-chen-mpls-ipv6-pw-lsp-ping

Mach,

I wonder if v6 lsp ping specs could be ammended to specify that if
intermediate node needs to return "TTL expired" and do not have route
back to the source they SHOULD send "TTL expired" along the same path as
original packet would have taken. I know v4 lsp ping specs doesn't have
such point, but since that creates problem in Inter-AS MPLS Option C
environment while plain IP traceroute doesn't have such problem (due to
above described ICMP
tunneling) it would be nice if v6 lsp ping could fix the issue.

Cheers,
iLya

--------------------------------------------------
From: "Mach Chen" <[email-masked]>
Sent: Thursday, November 24, 2011 3:46 AM
To: <[email-masked]>
Cc: <[email-masked]>
Subject: [mpls] Solicit comments on draft-chen-mpls-ipv6-pw-lsp-ping

> and did not receive technical comments there. Although the authors 
> think that the draft is quite straightforward and stable, we'd like 
> that you could spend some time to read the draft and give your
comments.

---

From: "iLya" <[email-masked]>
Date: Thu, 24 Nov 2011 16:57:57 +0100

Mach,

I wonder if v6 lsp ping specs could be ammended to specify that if 
intermediate node needs to return "TTL expired" and do not have route back 
to the source they SHOULD send "TTL expired" along the same path as original 
packet would have taken. I know v4 lsp ping specs doesn't have such point, 
but since that creates problem in Inter-AS MPLS Option C environment while 
plain IP traceroute doesn't have such problem (due to above described ICMP 
tunneling) it would be nice if v6 lsp ping could fix the issue.

Cheers,
iLya

> Hi,
>
> We presented the draft in IETF 82th meeting (both in MPLS and PW3 WG) and 
> did not receive technical comments there. Although the authors think that 
> the draft is quite straightforward and stable, we'd like that you could 
> spend some time to read the draft and give your comments.
>

---

From: Mach Chen <[email-masked]>
Date: Fri, 25 Nov 2011 01:21:57 +0000

Hi Spike,

Many thanks for your comments!

I thinks your text is great and we will incorporate it into the next version. 

Best regards,
Mach

> From: Spike Curtis [mailto:[email-masked]]
> Sent: Thursday, November 24, 2011 8:22 PM
> Subject: RE: Solicit comments on draft-chen-mpls-ipv6-pw-lsp-ping
> 
> Hi Mach,
> 
> I agree that the draft is straightforward, so I only have comments intended to
> improve the clarity, rather than the technical details.
> 
> In the introduction and abstract you state that there is ambiguity in the
> currently defined sub-TLVs that is resolved by looking at the sub-TLV length.
> Really, it isn't the sub-TLV length itself that determines this, but the length of
> the address fields.  I think what you are getting at would be more clearly
> stated with something like the following.
> 
> "Although the sub-TLVs defined for pseudowires in RFC 4379 are not explicitly
> restricted to IPv4 LDP sessions, this restriction is clearly inferred by examining
> the lengths of the Sender/Remote PE Address fields.  These sub-TLVs cannot
> be used for pseudowires signalled in IPv6 LDP sessions since the addresses will
> not fit."
> 
> Cheers,
> Spike
> 
> did not receive technical comments there. Although the authors think that the
> draft is quite straightforward and stable, we'd like that you could spend some
> time to read the draft and give your comments.
>

---

From: Mach Chen <[email-masked]>
Date: Fri, 25 Nov 2011 03:04:46 +0000

Hi iLya,

Thanks for the comments!

Since this draft mainly focuses on IPv6 PW FEC sub-TLVs, as Carlos said, your suggestion should be out of the scope of this draft. IMHO, there should another generic LSP Ping update draft to solve the issue you pointed out.

Best regards,
Mach

> From: iLya [mailto:[email-masked]]
> Sent: Thursday, November 24, 2011 11:58 PM