Subject: [Pals] Suresh Krishnan's Discuss on draft-ietf-pals-p2mp-pw-lsp-ping-03: (with DISCUSS and COMMENT)

From: Suresh Krishnan <[email-masked]>
Date: Mon, 19 Jun 2017 11:12:33 -0700

Suresh Krishnan has entered the following ballot position for
draft-ietf-pals-p2mp-pw-lsp-ping-03: 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-p2mp-pw-lsp-ping/

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

I think the P2MP Pseudowire Sub-TLV in Section 4.1 is a bit under-specified. It
is unclear how the address family of the originating router's IP address is
communicated. Is this purely derived from the IP Addr Len (i.e. Len is 4 =>
IPv4, Len is 16 => IPv6)? If so, I think it would be useful to state this
explicitly and add some validity checking and error handling for values other
than 4 and 16.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Are there no alignment requirements for the IP address in "Originating Routers
IP Addr" inside the sub-TLV? I would think that alignment on a 4 byte boundary
might be needed.

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 19 Jun 2017 21:17:31 +0100

On 19/06/2017 19:12, Suresh Krishnan wrote:
> IPv4, Len is 16 => IPv6)?

Suresh

Whilst I have some sympathy for your point, it does say "The Originating 
Router's IP address is the
IPv4 or IPv6 address of the P2MP PW root." So only two address families 
are allowed, and
I doubt that the IETF will have much stomach for a third mainstream 
family. Those two
families are clearly distinguishable by length, so there really is no 
ambiguity.

> If so, I think it would be useful to state this

RFC4379 which is a base document has section 3.7 on what to do if there 
is an error in the
TLV, so technically the draft is complete, although on a P2MP I am not 
sure that is the
right way forward since a lot of error traffic may be returned. It might 
be better to log
the error via the NMS.

- Stewart

Why? It may not be aligned by the time we take into a/c the MAC header 
etc no matter what
we do to the TLV.

- Stewart

---

From: "Parag Jain (paragj)" <[email-masked]>
Date: Mon, 19 Jun 2017 20:44:56 +0000

On 2017-06-19, 4:17 PM, "Stewart Bryant" <[email-masked]> wrote:

    
    Suresh

    
    
    - Stewart
    
Thanks Stewart!

Please also see section 7 of the draft which talks about employing procedures to reduce the congestion of echo responses and limiting the echo reply to a single egress node.

Thanks
Parag

    - Stewart