Subject: [PWE3] VCCV BFD

From: "Vishwas Manral" <[email-masked]>
Date: Wed, 10 Sep 2008 19:05:44 +0530

Hi,

I had raised the issue in the BFD list too for a different draft, but
I wanted to state that IPv6 address as stated in the draft as
0:0:0:0:FFFF:127/104 is hard to be called an IPv6 address. IPv6
addressing architecture RFC4291 document clearly gives the exact
example of what is wrong with the address. I guess the intention is to
probably have the address as 0:0:0:0:FFFF:127::/104. Ming you the 127
is in Hex and not integer.

That said I had one more doubt about exchanging VCCV CV type in the
LDP - PW ID FEC TLV. The CV capabilities "Fault detection only" is a
subset of "Fault detection and AC/ PW Fault Status signalling". Do we
need to consider the case that in case one is advertized the other is
implied by itself?

Thanks,
Vishwas
_______________________________________________
pwe3 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pwe3

---

From: Carlos Pignataro <[email-masked]>
Date: Wed, 10 Sep 2008 20:30:14 -0400

Hi Vishwas,

Thank you for the comments, please see inline.

> 0:0:0:0:FFFF:127/104 is hard to be called an IPv6 address. IPv6

Note that that text intends to represent a prefix and not an address,
and note the initial 80 bits (0:0:0:0:0:F...) of zeros (and not 64 bits).

Thanks for raising this issue!!! I just saw your posting in rtg-bfd and
was comparing with vccv-bfd as well. Please note that both drafts
carry-over the same propagated prefix misrepresentation from RFC4379,
perhaps you could raise an errata item for RFC4379 about this mistake
you found.

> probably have the address as 0:0:0:0:FFFF:127::/104.
                              ^
                             0:

No; it intends to represent the IPv6 address prefix with IPv4-mapped
127/8 (loopback) prefix (and not 1.39.0.0). The intention is to have
0:0:0:0:0:FFFF:127.0.0.0/104.

Which of these two representations do you think is more clear for the
purposes of this document?

a. ::FFFF:127.0.0.0/104
b. ::FFFF:7F00:0/104

I think that possibly a) because it shows the standard IPv4
representation explicitly?

>  Ming you the 127 is in Hex and not integer.
> 

IMHO, there should not be implications, but exact matches (i.e., a
capability should not imply another capability, each has their bits).
The document says:

   That is, only BFD CV Types that were both advertised and
   received are available to be selected.
...
   considering the intersection of advertised and received BFD CV Types

And paraphrases this concept in a couple of places. Advertising "PW
Fault Detection and AC/PW Fault Status Signaling" does not mean that "PW
Fault Detection only" is automatically supported. If a PE supports
(i.e., is capable and willing to run) both, then I think it should
advertise both; Section 4 enumerates the precedence for multiple
matching (advertised and received) CV Types, prioritizing "PW Fault
Detection and AC/PW Fault Status Signaling" if available.

Thanks,

--Carlos.

-- 
--Carlos Pignataro.
Escalation RTP - cisco Systems
_______________________________________________
pwe3 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pwe3

---

From: Carlos Pignataro <[email-masked]>
Date: Wed, 10 Sep 2008 20:59:11 -0400

> perhaps you could raise an errata item for RFC4379 about this mistake

Apologize for the self-reply, for completeness, this errata was already
submitted <http://www.rfc-editor.org/errata_search.php?eid=1418>.

Thanks,

--Carlos.

---

From: "Vishwas Manral" <[email-masked]>
Date: Thu, 11 Sep 2008 08:26:13 +0530

Hi Carlos,

As you have seen (in a private mail) I have updated Brian Carpenter on
the issue with the Errata.

I wanted to point out that
::FFFF:127.0.0.0/104 is the best representation.

Regarding the RFC, I think the issue is so critical (because the
address meant is different from the address actually written for a
critical portion) I would ideally think that the RFC should be
re-spun. I do not think an errata for the very basic going wrong is
appropriate.

Let me raise the issue with the authors of the document and get back to you.

Thanks,
Vishwas

---

From: Carlos Pignataro <[email-masked]>
Date: Thu, 11 Sep 2008 12:56:36 -0400

Hi Vishwas,

> re-spun. I do not think an errata for the very basic going wrong is

My 2¢, the context makes it clear on what the intentions were (IPv6 with
the same IPv4 prefix mapped):

  "IPv4 addresses are drawn from the range 127/8; IPv6 addresses
   are drawn from the range 0:0:0:0:0:FFFF:127/104."

Thanks,

--Carlos.

---

From: "Busschbach, Peter B \(Peter\)" <[email-masked]>
Date: Wed, 17 Sep 2008 12:27:36 -0500

Carlos,

The latest version of the oam-msg-map draft refers to
draft-nmcgill-l2tpext-circuit-status-extensions-01. Do you think it is
possible to move this to WG-draft status and subsequently to RFC status
in the near term? If not, the oam-msg-map draft will be held up due to
this dependency.

Peter

---

From: Carlos Pignataro <[email-masked]>
Date: Wed, 17 Sep 2008 17:15:43 -0400

Peter,

Yes, we asked the chair to consider WG adoption of the draft last June,
and there was a WG poll in l2tpext; this was followed by another WG poll
due to lack of responses, and we are waiting on the chair's call for
this; I can follow-up.

However, I think that, since the circuit-status-extensions is not part
of the base specification for L2TPv3, oam-msg-map should probably say
something like "for L2TPv3 PWs, this is the procedure; if the
circuit-status-extensions are available, then additional/alternative
procedure". Currently the draft is listed as an Informative reference,
so would not hold up as a hard dependency.

Thanks,

--Carlos.