Subject: [Pals] Suresh Krishnan's Discuss on draft-ietf-pals-endpoint-fast-protection-04: (with DISCUSS)

From: "Suresh Krishnan" <[email-masked]>
Date: Tue, 13 Dec 2016 20:36:30 -0800

Suresh Krishnan has entered the following ballot position for
draft-ietf-pals-endpoint-fast-protection-04: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-pals-endpoint-fast-protection/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Sections 6.4.1 and 6.4.2

The Ingress and Egress PE Addresses are encoded as 4 byte fields. How is
this expected to work with IPv6 addresses for the PEs?

---

From: Yimin Shen <[email-masked]>
Date: Wed, 14 Dec 2016 18:57:08 +0000

Hi Suresh,

Thanks very much for your review and the question about section 6.4.1 and 6.4.2.

This document does not define any new encoding. Instead it is using the definitions of RFC4447, as noted in 6.4 for intro to 6.4.1 and 6.4.2. Specifically, the “Protection FEC Element TLV” uses the encoding and semantics of PWid FEC and Genercalize PWid FEC defined in RFC 4447. These FECs carry IPv4 addresses, and there is currently no IPv6 encoding defined for these FECs by IETF.

Hope this clarifies it for you.

Thanks,

-- Yimin

On 12/13/16, 11:36 PM, "Suresh Krishnan" <[email-masked]> wrote:

    
    
    Sections 6.4.1 and 6.4.2

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 14 Dec 2016 20:51:27 +0000

Yimin,

I think these IPv6 encodings should be defined (like RFC 6829 did for example) instead of saying “they are not in RFC 4447”. But, specifically, where in RFC 4447?

Thanks,

—
Carlos Pignataro, [email-masked]<mailto:[email-masked]>

“Sometimes I use big words that I do not fully understand, to make myself sound more photosynthesis."

On Dec 15, 2016, at 3:57 AM, Yimin Shen <[email-masked]<mailto:[email-masked]>> wrote:

Hi Suresh,

Thanks,

-- Yimin

On 12/13/16, 11:36 PM, "Suresh Krishnan" <[email-masked]<mailto:[email-masked]>> wrote:

   Sections 6.4.1 and 6.4.2

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

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 15 Dec 2016 03:55:55 +0000

Hi Yimin,

> This document does not define any new encoding. Instead it is using the definitions of RFC4447, as noted in 6.4 for intro to 6.4.1 and 6.4.2. Specifically, the “Protection FEC Element TLV” uses the…

I have a hard time understanding how this document does not define a new 
encoding. The title of the section 6.4.1. is "Encoding Format for PWid" and 
the TLV type is 0x83 which is *not* defined in RFC4447. Can you please 
clarify what you mean? I think the proposal by Carlos to resolve this seems 
to be reasonable to me.

Thanks
Suresh

---

From: Yimin Shen <[email-masked]>
Date: Thu, 15 Dec 2016 13:17:14 +0000

Hi Suresh, Carlos,

After rethinking of this, yes, I think you’ve made a good point, and I agree with you on that proposal. We will add encodings for IPv6 PE addresses for PWid and Generalized PWid in sections 6.4.1 and 6.4.2, respectively. This will be in a manner similar to RFC 6829.

Thanks again for your review and this valuable comment!

Thanks,

-- Yimin

On 12/14/16, 10:55 PM, "Suresh Krishnan" <[email-masked]> wrote:

    Hi Yimin,

    
    Thanks
    Suresh

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 15 Dec 2016 19:01:09 +0000

Hi Yimin,

> Thanks again for your review and this valuable comment!

Sounds good. I will clear once the new version is posted.

Thanks
Suresh