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

From: Veerendranatha Reddy Vallem <[email-masked]>
Date: Wed, 16 Dec 2015 02:32:05 +0000

Hi,
Can you please help me understanding processing of BGP-LS messages by 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.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 16 Dec 2015 22:16:39 +0000

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 <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Example Topology:

                                                                                                        Controller
                                AS1                                          AS2                        |

Regards,
Veerendraanath

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

---

From: Veerendranatha Reddy Vallem <[email-masked]>
Date: Thu, 17 Dec 2015 06:44:11 +0000

Dear Acee,
Thanks for the reply.
While validation of sub TLVs,  whether we can skip the sub TLVs from validation which are not understand/ unknown,
if the Sub TLV length is not exceeding the remaining length of the NLRI and process next sub TLV.

Thanks & Regards,
Veerendranath

From: Acee Lindem (acee) [mailto:[email-masked]]
Sent: 17 December 2015 06:17
To: Veerendranatha Reddy Vallem; Adrian Farrel
Cc: [email-masked]; [email-masked]
Subject: Re: [Idr] [idr] draft-ietf-idr-ls-distribution

Hi Veerandraanath,

      this document?

Thanks,
Acee

Hi,

Example Topology:

                                                                                                        Controller
                                AS1                                          AS2                        |

Regards,
Veerendraanath

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 17 Dec 2015 12:43:12 +0000

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" <[email-masked]> 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,
>>
>> 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
>>> <[email-masked] <mailto:[email-masked]>>
>>>wrote:
>>>
>>> Hi,
>>> Can you please help me understanding processing ofBGP-LS messagesby
>>> transit nodes.
>>> 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                        |
>>> 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.
>>> [email-masked] <mailto:[email-masked]>

---

From: Hannes Gredler <[email-masked]>
Date: Thu, 17 Dec 2015 08:10:21 +0100

hi acee,

/hannes

On 12/16/15 23:16, Acee Lindem (acee) wrote:
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>> Hi,

---

From: Veerendranatha Reddy Vallem <[email-masked]>
Date: Fri, 18 Dec 2015 03:59:01 +0000

Hi Acee,
Thanks for the clarification.

Regards,
Veerendranath

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

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" <[email-masked]> wrote:

>and i agree, some clarification that this only applies to the 'known' 
>would not hurt.
>
>/hannes
>
>> 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
>>
>>
>>> 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.