Re: [Idr] [idr] draft-ietf-idr-ls-distribution

Hi Acee,
Thanks for the clarification.

Regards,
Veerendranath

-----Original Message-----
From: Acee Lindem (acee) [mailto:acee@cisco.com] 
Sent: 17 December 2015 20:43
To: Hannes Gredler; Veerendranatha Reddy Vallem; Adrian Farrel
Cc: idr@ietf.org; draft-ietf-idr-ls-distribution@tools.ietf.org
Subject: Re: [Idr] [idr] draft-ietf-idr-ls-distribution

Hi Hannes, Veerendranatha,

This seems sensible. In essence, the BGP Speaker validation is confined to assure the Link-State NLRI and nested TLVs are not malformed including validating the lengths of known TLVs. Validation and interpretations of any values is left to the consumers of the NLRI.

Thanks,
Acee 

On 12/17/15, 2:10 AM, "Hannes Gredler" <hannes@gredler.at> wrote:

>hi acee,
>
>the fixed length check is only applied when the TLV is known.
>
>and i agree, some clarification that this only applies to the 'known' 
>would not hurt.
>
>/hannes
>
>On 12/16/15 23:16, Acee Lindem (acee) wrote:
>> Hi Veerandraanath,
>>
>> Section 6.2.2 lists the mandatory checking.
>>
>>>     If an implementation of BGP-LS detects a malformed attribute, 
>>>then it
>>>     MUST use the 'Attribute Discard' action as per [RFC7606] Section 2.
>>>
>>>     An implementation of BGP-LS MUST perform the following syntactic
>>>     checks for determining if a message is malformed.
>>>
>>>     o  Does the sum of all TLVs found in the BGP LS attribute 
>>>correspond
>>>        to the BGP LS path attribute length?
>>>
>>>     o  Does the sum of all TLVs found in the BGP MP_REACH_NLRI 
>>>attribute
>>>        correspond to the BGP MP_REACH_NLRI length?
>>>
>>>     o  Does the sum of all TLVs found in the BGP MP_UNREACH_NLRI
>>>        attribute correspond to the BGP MP_UNREACH_NLRI length?
>>>
>>>     o  Does the sum of all TLVs found in a Node-, Link or Prefix
>>>        Descriptor NLRI attribute correspond to the Node-, Link- or 
>>>Prefix
>>>        Descriptors 'Total NLRI Length' field?
>>>
>>>     o  Does any fixed length TLV correspond to the TLV Length field in
>>>        this document?
>> The last one is questionable since it is TLV code-point specific. As 
>> we enhance BGP LS, we certainly don’t want BGP speakers to drop LS 
>> NLRI identifiers or attributes that they don’t understand. However, 
>> we are probably too late to remove this check... ;^) Authors?
>>
>> Thanks,
>> Acee
>>
>>
>>> On Dec 15, 2015, at 9:32 PM, Veerendranatha Reddy Vallem  
>>><veerendranatharv@huawei.com <mailto:veerendranatharv@huawei.com>>
>>>wrote:
>>>
>>> Hi,
>>> Can you please help me understanding processing ofBGP-LS messagesby 
>>> transit nodes.
>>> Once BGP speaker receives the Update message with BGP Link state (it 
>>> may be intermediate/transit node), Whether BGP speaker need to 
>>> validate each  sub TLVs present in LS NLRI and Attributes before 
>>> sending the update to neighbor peers, even the speaker is not using 
>>> that data for processing?
>>> Example Topology:
>>>
>>>                
>>>                           Controller
>>>                                 AS1
>>>                                          AS2                        |
>>> BGP speaker1--------------BGP speaker 2--------------------------BGP 
>>> speaker 3 Now BGP speaker will send update information to BGP 
>>> speaker 2, intern forward the Update to BGP speaker 3, BGP speaker 
>>> will send that information to controller.
>>> Whether SGP speaker2, and BGP speaker 3 need to validate the Sub 
>>> TLVs present in LS-MPNLRI and LS-Attributes (even they will not 
>>> process the data, the data is opaque for those ), before sending 
>>> update to its peer or Only controller is enough to validate the 
>>> data, since controller is the consumer for the data present in LS information.
>>> Regards,
>>> Veerendraanath
>>> This e-mail and any files transmitted with it are for the sole use 
>>> of the intended recipient(s) and may contain confidential and 
>>> privileged information. If you are not the intended recipient(s), 
>>> please reply to the sender and destroy all copies of the original 
>>> message. Any unauthorized review, use, disclosure, dissemination, 
>>> forwarding, printing or copying of this email, and/or any action 
>>> taken in reliance on the contents of this e-mail is strictly 
>>> prohibited and may be unlawful. Where permitted by applicable law, 
>>> this e-mail and other e-mail communications sent to and from 
>>> Cognizant e-mail addresses may be monitored.
>>> _______________________________________________
>>> Idr mailing list
>>> Idr@ietf.org <mailto:Idr@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/idr
>>