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

["Parag Jain (paragj)" <[e-mail]>]

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

    
    
    On 19/06/2017 19:12, Suresh Krishnan wrote:
    > 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)?
    
    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
    > explicitly and add some validity checking and error handling for values other
    > than 4 and 16.
    
    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
    
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

    >
    >
    > ----------------------------------------------------------------------
    > 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.
    >
    >
    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